This repository has been archived by the owner on Aug 31, 2019. It is now read-only.
forked from Yukon/spock
-
Notifications
You must be signed in to change notification settings - Fork 1
Optional kill signal handler registration #1
Open
spalanzani
wants to merge
85
commits into
OvercastNetwork:master
Choose a base branch
from
micropsi-industries:master
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
signal handler registration optional
Just a dumb typo I missed somewhere along the way
Fix typo in datautils.py
Added all the current biomes to mapdata.py
Conflicts: spock/mcmap/mapdata.py spock/mcp/mcdata.py
EmptyChunks with non-empty blocks at runtime
Fixed rep and selectedProfile not being defined for offline or demo accounts
Fixed off by one error in packet size, and datatype of keep_alive
ClientInfo should serve as a reference for how core and helper spock plugins should register for and handle raw packets. Wherever possible, plugins should depend on other plugins before falling back on raw packets. However, for many plugins this isn't possible, when packets are need their registers should prefer strings ident and their handlers should be well named and commented to specify what packet(s) they interact with. For excessively long handler/packet registration, or for registering multiple events to one handler (or vice-versa), simple loops are acceptable
(we can not check whether it's us who went to bed, for the moment we don't care though)
This reverts commit 23f08a3. We don't need this hack anymore
this will queue any packet other than the usual keep-alive and position packets during reconnect, when the client ist not in PLAY state. it will send them in their same order once the play state is regained.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I have a use case in which the spock event loop is not running in the main thread.
Spock currently assumes it's in the main thread by always calling signal.signal -- I have introduced a setting called "killsignals" for the Event plugin to avoid that registration in cases where spock is running within a larger application that performs its own thread management.
The change is meant to be non-invasive, so everything should be the same for people who run spock in the main thread.