Where's Waldo "NaN"

[Baker]

I see comments in Quakespasm's source code about being surprised to get a "NaN" result. I see similar comments in the Remake Quake engine.

I have seen some forum posts about DirectQ players going through the floor when using the client in single player.

And recently the Mark V engine after making some revisions to the pr_*.c/*.h, I have encountered a collision problem which I suspect the wrong movetype function is being used or the wrong collision function perhaps.

I'm not so worried about my code --- I'm going to develop a test plan to track this down or somehow compare offsets.

But real question: And I guess this is for Spike unless someone else knows --- is unexpected NaN comments I see in the Quakespasm and the Remake Quake engine a problem in FTE or DarkPlaces, or does this indicate some sort of issue in those engines that can manifest itself in unpredictable ways?

I'm just asking because I'm trying to get a basis of what "normal" and "correct" results look like and if this NaN isn't supposed to exist in a correctly functioning progs interpreter, well ... that would be a "clue".

Thanks for any insight into this.

[Spike]

for me the biggest source of nans comes from bsp collision code.
stuff like 'd1 / (d2 - d1)' where all values are distances from a plane has an easy-to-trigger division by zero with a resulting nan. this is the formula used to determine eg traceline fractions.
Tracelines are NOT precise. They use epsilons and stuff. They really have terrible precision. They will follow the wrong node occasionally, and they will enter regions which are not meant to be empty by following tiny cracks between nodes.

regarding qc, the OP_IF / OP_IFNOT opcodes are defined to use integer comparisons. as a result they cannot test for -0, other than that they have no greater issue with nans than the engine does.

FTE attempts to correct the player's position each physics frame in case you enter a solid region. this means minor precision errors are automatically corrected each frame avoiding the player from entering the void.
In NQ, the engine only tests if the current position is valid and reverts the player to the 'oldorigin' position if they enter a wall. mods that set the oldorigin field for other any reason can prevent this NQ in-walls fix from working. Mods that call setorigin on the player/change the origin field directly can potentially result in the oldorigin value getting set to an invalid position.
This is then combined with a traceline that 'succeeds' if its already in a wall, and your player drops through the floor.

[Baker]

Thanks for the info. So it seems that NaN result is just business as usual for the normal behavior of the Quake engine.

[Spike]

all I can really recommend is to sanitize your traceline results, and not mess up the oldorigin field.

[r00k]