Physics/AI error after staying too long on a map (q2rtxded 1.6.0)

[RoLex]

Hi.

I have exactly the same issue as mentioned in Q2Pro > https://github.com/skullernet/q2pro/issues/185

I should mention that this happens on my dedicated server, which is running q2rtxded 1.6.0 (latest). After exactly 1 day of uptime on same map (q2dm1) and no time limit, both lifts are starting to glitch, going above and below the initial levels.

You don't have to stay in the game for one day, newly connected players have same issue. The ploblem lies in the server itself. Tested even with Quake 2 original client with same results. I'm not sure who (server, client or game mod) that is calculating this nextthink frame things.

Another thing to mention, is that I run 3ZB2 game. Not sure if it's the one that actually brings trouble. I'm using this mod: https://www.moddb.com/mods/3zb2-bots-for-q2rtx

If needed for testing, server host is: q2rtx.feardc.net (not spam)

Regards.

[res2k]

This is a bug in the game DLL, and since 3BZ2 uses a different game DLL, the issue needs to be fixed there.
To that end you could try reaching out the author on the moddb page you linked and/or the 3zb2 project found here on GitHub: https://github.com/yquake2/3zb2

The appropriate fix for the issue can be found in the Q2PRO (and now Q2RTX) repos in the commits with messages like "Convert to frame numbers."

[RoLex]

@res2k

Thank you, again! 👍

[RoLex]

Finally I got some time to compare the q2pro/src/baseq2 and 3ZB2 0.97 original source and try to rewrite as much as possible when it comes to frame calculations. Changes can be found in this commit: RoLex/feardc-3zb2@131d636

But I got a few issues where I could not find similar code in Q2PRO, so I marked those lines with // todo comment. I'm not yet 100% of what is actually happening in the game with current code, this project is very new to me for now. I would need some help on this. Could anyone who have some free time take a look? They are really few left.

Else I have re-added the original Id Software copyrights to all the files, because this code was initiated by Id Software, so all respect to them, and then modified by other people like ponko. Also I translated all the japanese comments from ponko in order to understand what he is trying to do in the code. Special thanks goes to @Axonimpulse who provided with his Visual Studio project files, because I could absolutely not create one myself.

So the game DLL compiles successfully, with alot of warnings ofcourse, but I will try to fix them all aswell when I get more free time (most of them are already fixed in Q2PRO). The game DLL is running properly with Q2RTX, but I can not yet see the glitches that unchanged code should be causing. Probably it's not visible to a human eye, or I have played to little with the recompiled game. If anyone is interested, my commit contains bin directory, in there you can find compiled game DLL itself and the 3ZB2 base configs and PAK.

To be continued ... and please help someone! There is very little to do on part 1.

=)

[RoLex]

@skullernet

I was looking at the https://github.com/skullernet/openffa source today, I see you use different approach, atleast the definitions are different. For example decel in g_local.h is still a float. In 3ZB2 there is trap_time and spawncycle for example, those are compared to level.time. Do I have to change those to int + level.framenum aswell?

I saw you helped https://github.com/packetflinger/opentdm with similar modifications, so you seem to know exactly what you are doing. Your help would be very much appreciated!

[res2k]

Hey @RoLex, since this seems to be an issue in some other code and not directly Q2RTX' fault, perhaps this particular GH issue could be closed then?

[RoLex]

Hi. Yes, ofcourse. Thank you for all help given so far!