Post

During another sleepless night, I tried to hack GoldSrc protocol into Xash3D FWGS. This isn't something I really want to implement and support in the engine, just want to see what could be improved in further Xash protocol extensions. There isn't so much to show off yet because client doesn't connect to HLDS yet. But I noticed a few interesting things. 1) In GoldSrc there are still remnants of old authentication with CD keys, which cannot even be used anymore. The only way to authenticate is the so-called "Steam protocol" in LAN mode, in which it doesn't validate the certificate cookie in Steam. I guess that's how networking works on pirated games? Honestly, I never looked into this. 2) To prevent protocol reverse-engineering, Valve tried to mangle the network data. This isn't a problem anymore, because the algorithm itself was RE'd a long time ago. It's a pure comedy of security through obscurity: github.com/dreamstalker/rehlds/b…. You tried (TM), Valve. 3) Xash and GoldSrc always send delta encoding information from server to client. But GoldSrc does it by delta encoding the delta tables themselves?.. It doesn't look struct encoding might change during the game, and it's even barely compressed, so #ValveWhy? 4) Delta packing itself is slightly. GoldSrc packing has a hard limit of 64 struct fields. Also, Xash is a bit more optimized, like sorting fields in delta.lst from frequently changed might help save a few bits. In GoldSrc this is limited by 1 byte boundary. 5) Start/EndBitWriting functions are idiotic. Valve wanted bit operations on network buffer and just hacked it on top of existing code of Quake. On Xash side, which natively supports bit ops, the offset needs to be realigned every time when GoldSrc does EndBitWriting call. Guess why. 6) Suddenly downloaded Barney model over the network. Thought it was a bug because I definitely have the Barney model, but it's just HLDS automatically mounted HD models dire