qan Posted April 4, 2005 Report Posted April 4, 2005 Hi guys, Working on the new release of TWCore, and I'm running into a problem with the position packets that I'm sure many here are familiar with. SS has two different versions of the player position packet, a short and a long or "weapons" version of the packet. The short packet saves on space, the long one provides verbose details as needed. A nasty difference, though, that becomes acutely painful on zones that routinely have over 255 players, is that the short version only sends playerIDs as bytes, whereas the full ID is actually a 2-byte/16-bit shortint. So if you rely on the short version's ID to tell you what player it's talking about, you stand a chance of grabbing the wrong player, or even more likely, no player at all. (Player X is ID 0, or "0000000000000000"; player Y is ID 256, or "0000000100000000". If you remove the first byte, as the short packet does, you get Y = "00000000" = X = "00000000." This sucks terribly.) So my question is, being the packet newbie that I am, when is the short version sent versus the long version? Long I'm !@#$%^&*uming is sent when a weapon's fired, but any other times? Certainly the Cont client doesn't seem to suffer from the problems !@#$%^&*ociated with one-byte IDs... does it have a way of always requesting the long version of the position packet? Or somehow coping with the short version's obvious limitations? The reason I ask this is because we recently made some efficiency changes in the core, not "overstoring" parsed packet data in containers two or four times too large. PlayerID used to be a 32-bit int, and now it's a shortint. However, we now end up throwing all kinds of null pointer exceptions on our dev core from IDs that can't be retreived, whereas before with int storage we had no such problem. This raises a big "what the !@#$%^&*?" about packet presumptions... what was the int able to store that the short wasn't? Is it some other related change that's causing this instead? Or were the NPEs simply repressed beforehand? Confusing, to say the least. Any information about the differences between these two packet types, or any intuition on a possible solution to resolve this problem would be of course greatly appreciated. Excessively yours,qan
»SOS Posted April 4, 2005 Report Posted April 4, 2005 As far as I know, the long version is sent when a weapon is fired. In all other cases, the short one is sent. No idea how to solve the problem though... one should test this with an ASSS build where all IDs are above 255 and see how Continuum acts. If it acts perfectly fine... that's suspicious Well, you could do some sort of guestimation algorithm... find the player who had similar bounty and similar location and similar rotation and then you've got your player (within a wobbly margin of error).
»Maverick Posted April 4, 2005 Report Posted April 4, 2005 Not that I like to say it, but you should also post this at forums.minegoboom.com . The guys there now about this stuff.
»D1st0rt Posted April 5, 2005 Report Posted April 5, 2005 No solid proof on this, but I think it has to do with the ExtraPositionInfo that can be requested from the person such as energy, item and weapon status, and S2C Weapon latency. The stuff you see when staff spectates on a person flying around in gray text at the top-center portion of the screen. EDIT: After further review, the ruling on the field stands. SOS appears to have the correct answer. I direct your attention to the definitions for S2C Packets 0x05 0x28 (Coincidentally also written by SOS). It even addresses the problem in 0x28: 0x05 Large Position Packet (Weapons Packet) Offset Length Description 0 1 Type Byte 0x05 1 1 Direction (0 ... 360) 2 2 Time Stamp 4 2 X Pixels (0 ... 16384) 6 2 Y Velocity 8 2 Player ID 10 2 X Velocity 12 1 Checksum 13 1 Togglables *1 14 1 Ping 15 2 Y Pixels (0 ... 16384) 17 2 Bounty 19 1 Weapon Parameters 20 1 Weapon Type 21 2 Energy *2 *3 (Optional) 23 2 S2C Lag *2 (Optional) 25 2 Timer *2 (Optional) 27 4 Item Info *2 (Optional) *1 - Bit flags for the Togglables byte in bit order. Stealth : 1; Cloaked : 2; XRadar : 4; // XRadar calcs are done client-side Antiwarp : 8; // Ditto WarpFlash : 16; // Uncloaking, portaling, etc. UNKNOWN1 : 32; // ? UFO : 64; // *ufo - Illegal usage caught in sg9+ UNKNOWN2 : 128; // ? *2 - This data is only sent if the ExtraPositionData flag is set to true in the zone settings. *3 - This data is sent if either the ExtraPositionData flag is set to true, or if you are using the Energy password. 0x28 Small Position Packet Offset Length Description 0 1 Type Byte 0x28 1 1 Direction (0 ... 360) 2 2 Timestamp 4 2 X Pixels (0 ... 16384) 6 1 Ping 7 1 Bounty 8 1 Player ID *1 9 1 Togglables *2 10 2 Y Velocity *3 12 2 Y Pixels (0 ... 16384) 14 2 X Velocity *3 16 2 Energy *4 *5 (Optional) 18 2 S2C Lag *4 (Optional) 20 2 Timers *4 (Optional) 22 4 Items *4 *6 (Optional) *1 - Since the Player ID here is only one byte, this packet is only capable of addressing the first 256 clients in a zone. *2 - Togglables: Each value is one bit in a byte Bit 1 - Stealth Bit 2 - Cloak Bit 4 - XRadar Bit 8 - Antiwarp Bit 16 - Flash (Play the cloak/warp flash) Bit 32 - Safety (In safe) Bit 64 - UFO (Using UFO) Bit 128 - ? *3 - Velocities are measured in Pixels per 10 Seconds. *4 - These values are only received if the ExtraPositionData variable in the Settings is set to True. *5 - This value is sent if either the ExtraPositionData value is set to True in the settings or if you are using the Energy password. *6 - Item Info Unsigned Integer Values or Booleans Shields (Boolean) :1 bit Super (Boolean) :1 bit Burst Count :4 bits Repel Count :4 bits Thor Count :4 bits Brick Count :4 bits Decoy Count :4 bits Rocket Count :4 bits Portal Count :4 bits ? Unknown :2 bits Source: http://d1st0rt.sscentral.com/packets.html
»SOS Posted April 5, 2005 Report Posted April 5, 2005 I was thinking about TW... perhaps the server sends the longer version if pid > 255? I believe the "weapon fire" part of the packet can be disabled (there's a no-weapon weapon), so it should work. Has this been tested? I know ASSS does not do this but maybe subgame is very smart?
Recommended Posts