Total Members Voted: 51
ghost is clueless
Indeed. I don't feel it's right to drastically alter the game as R1Q2 has. Incompatible demos, new network protocol that alters game physics
I mean.. genuine improvements to the game are fantastic. But trying to snuff out other projects is lame..Case in point, someone posted on the R1Q2 forum that they wanted to get it running on BSD. I replied that someone had recently ported Quetoo to BSD, and I posted the relevent diff in order to help. I did not even post a link to the Quetoo project. R1CH deleted my reply, claiming it was not relevant..
To be fair, it's doubtful r1ch was trying to alter the physics. We already know standard q2 physics has characterstics that are framerate-dependent; so it's not surprisng to me that separating client network updates from the video framerate is going to have some impact on the physics.In other words, cl_async is a nice idea; but I don't use it either.
However I like protocol 35. R1q2 doesn't force me to use it (you can set cl_protocol 34) but I love the faster map downloads. I also like the faster movement in noclip mode--a small detail, but nice.
And I like protocol 35 from the server side, too. Here are some stats from vanilla: Protocol 35 netcode has saved 431075015 bytes. Protocol 35 compression has saved 224172036 bytes. R1Q2 playerstate quantization optimization has saved 267356057 bytes. R1Q2 entity quantization optimization has saved 1521093045 bytes. R1Q2 custom delta management has saved 158041528 bytes. Total byte savings: 2601737681 (2481.21 MB)...So I'm definitely appreciative of what r1ch has done for quake2. Not to mention the whole boatload of security fixes.
That is unfortunate. Well... he's young. (I know it took me awhile to figure out that helping users was always a better move than restricting their choices--even if helping them meant recommeneding some competitor's product.)