Support encounter views #14
Merged
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Messages
EncounterUIScopeInandEncounterUIUpdatecontain data in format similar to the one seen in view update messages (msg id 1), described in the wiki.I grouped and added comments to bytes of few types of ScopeIn messages found in replay files in this gist file.
At the beginning, there's encounter id.
Length of header in bytes and string telling encounter type is next.
Then, ScopeIn message contains header with info about fields: index, type (similar to SincardFieldDataType), element count, name for each field.
Afterwards there's schema version that has to be equal to 2 in last version of client.
At the end there are values of previously mentioned fields, in both ScopeIn and Update messages.
Values of array fields are prefixed with indexes of both the field and the element within the array, so they take two bytes and not just one.
PR reuses methods created to work with views, and add bits specific to encounters, to simplify creating new types of encounters and working with their instances, so that they could be treated as views nested in EncounterUI messages.
Static class AeroEncounters is also added to be used by PacketPeep.