We MUST handle them and we are not allowed to act on a stream after it failed, as i am to lazy to change the structure to ensure the client to be imeadiatly dropped i added a AtomicBool to it.
- we had the problem that Participants couldn't shutdown them self, only by scheduler, which was controlled by api.
it's needed e.g. to handle the Schudown Frame
- my initial solution did a full shutdown, which was a problem if in parallel a 2nd shutdown was requested, no possibility of getting the error
- new solution will only deactivate Participant and Stream. and then still functions correctly, till the api closes the participant and calls the scheduler which then calls the bparticipant again
- i experimented with a Mutex<oneshot> or 2 and a `select` but it didn't prove that well
- also adjusted the Error messages to now either Disconnected when gracefully shutdown or ProtocolFailed when some msg couldn't be delivered
(note later might not be 100% returned correctly yet)
- make it harder for the server to crash and also kill invalid sessions properly (instead of waiting for them to close)
- introduce macros to reduce code duplication
- added tests to check for valid handshake as well as garbage tcp
- voxygen abort when the server has a invalid veloren_network handshake, e.g. by outdated version instead of try again
- rename Network `Address` to `ProtocolAddr` as sugested by zest as it's a combination of Protocol and std::io::Addr
- remove the manual byte arrays in `protocols.rs` with something more nice
- API behavior switched!
- the `Network` no longer holds a copy of participant, thus if the return of `connect` (before `Arc<Participant>, now `Participant`) got dropped, the `Participant::Drop` is triggered!
- you can close a Participant async via `Particiant::disconnect()`, no more need to know the network at this point
- the `Network::Drop` will check and drop not yet disconnected Participants.
- you can compare Participants via PartialEq, if they are true they point to the same endpoint (it checks remote_pid)
- Note: multiple Participants are only supported in theory, wont work yet
Additionally:
- fix some `debug!`
- veloren-client will now drop the participant gracefully on shutdown
- rename `error` to `debug` when 2 times Bparticipant shutdown is called, as it is to be expected in a async runtime
If the mainhand slot is swapped out or dropped while the character is
wielding, the character will be set to idle (same behavior). However, if
an item is picked up or used; or a non-mainhand item is dropped; or two
non-mainhand items are swapped; the character state will not be set to
idle (new behavior).
Rationale for keeping the same behavior:
Swapping a weapon out while in a wielding state can put the player in a
barehanded wielding state, which would be inconsistent with the fact
that that state can't be entered by toggling wield while barehanded.
Rationale for setting the new behavior:
Setting character state to idle was originally added because "Interact"
was mapped to right mouse button, so picking up an item with RMB would
also activate secondary attack if the player was wielding during the
interaction. Now the default keybinding for "Interact" is E, so this
isn't a problem unless the player changes their keybinding to RMB.
In addition, setting character state to idle for any inventory
manipulation may cause players to fall out of glider unexpectedly.
