Untangle visibility, targetable, and other fields in spawn packets#1881
Merged
Haselnussbomber merged 1 commit intoJul 15, 2026
Merged
Conversation
These various fields are really strangely defined and were bothering me for a while. So I took the time to finally untangle them and hopefully they make more sense now. The first one is targetable status, this plugs into the GameObject field of the same name but is *not* the flag itself. The disassembly (from Ghidra) looks daunting but what it's actually doing is checking if the field is 0 - or false - and if so, setting two flags: Unk0 | IsTargetable. Higher values don't do anything, I confirmed by recreating the code in Godbolt. The next field is Visibility, it also plugs into the GameObject field of the same name but the name is somewhat confusing. On first glance, you would think every object spawned would have a Visibility of 1 - or true - but the field means the opposite! If you spawn an object with Visibility set to 0, its shown and vice versa. I renamed this field to something more suitable. I didn't bother changing the GameObject field for now. There's a couple of fields that were included in the struct but not read by the client, so I marked those to be removed at a later date. The final two fields are in SpawnObjectPacket, and are meant for general purpose across all types of objects. For example, the initial SharedGroupTimeline state is passed in Arg1 for EventObj. I renamed those fields as their actual purpose is already known in a way. The remaining changes is just helpers to make the functions these fields plug into more readable. A lot of the GameObject methods I stumbled upon use this strange update flag system, so I started detailing that but didn't put too much effort into that yet.
redstrate
force-pushed
the
work/redstrate/spawn-packets-galore
branch
from
July 15, 2026 00:23
2d74c40 to
73b1217
Compare
This file contains hidden or 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.
These various fields are really strangely defined and were bothering me for a while. So I took the time to finally untangle them and hopefully they make more sense now.
The first one is targetable status, this plugs into the GameObject field of the same name but is not the flag itself. The disassembly (from Ghidra) looks daunting but what it's actually doing is checking if the field is 0 - or false - and if so, setting two flags: Unk0 | IsTargetable. Higher values don't do anything, I confirmed by recreating the code in Godbolt.
The next field is Visibility, it also plugs into the GameObject field of the same name but the name is somewhat confusing. On first glance, you would think every object spawned would have a Visibility of 1 - or true - but the field means the opposite! If you spawn an object with Visibility set to 0, its shown and vice versa. I renamed this field to something more suitable. I didn't bother changing the GameObject field for now.
There's a couple of fields that were included in the struct but not read by the client, so I marked those to be removed at a later date.
The final two fields are in SpawnObjectPacket, and are meant for general purpose across all types of objects. For example, the initial SharedGroupTimeline state is passed in Arg1 for EventObj. I renamed those fields as their actual purpose is already known in a way.
The remaining changes is just helpers to make the functions these fields plug into more readable. A lot of the GameObject methods I stumbled upon use this strange update flag system, so I started detailing that but didn't put too much effort into that yet.