gpGlobals->v_right is NaN sometimes with Linux

[markus_heiden]

Hi,

I got a strange problem with the hlsdk which only appears on Linux dedicated servers. With Epodbot sometimes the globals gpGlobals->v_right and gpGlobals->v_forward from the engine are NaNs. I did not figured out yet why this happens nor why it only happens with linux.

May this behaviour be caused by engine calls with wrong parameters?
Or needs the hlsdk special gcc compiler options?
Or does it only run stable with special versions of glibc etc.?

Has anyone ever heard of similar problems?

Markus

[Rick]

Are you using agressive cflags(O3, -ffast-math etc)?

[The Storm]

We tried both with the flags from HLSDK makefile and some standart ones. No luck.

[DrEvil]

Make sure the bot isn't passing those values to the engine. Division by zero can result in those I believe.

[KWo]

Make sure You "clamp" the angles in between -180 +180 range before calling MAKE_VECTORS(v_angles) which changes the gpGlobals->v_right and gpGlobals->v_forward (I believe You are using this method).

[The Storm]

Thanks KWo I will make checks this night.

[markus_heiden]

Yes it was MAKE_VECTORS. Thanks for your fast answer.

Markus

[KWo]

Originally Posted by markus_heiden

Yes it was MAKE_VECTORS.

So - it means You found it and it's already fixed?

[markus_heiden]

I fixed it now. But it had nothing to do with UTIL_MakeVectors(). I simply didn't know that v_forward etc. are the return values from UTIL_MakeVectors(). Nevertheless I fixed several errors in the math code of epodbot and ensured that only wrapped angles are passed to UTIL_MakeVectors(). So the code should be much more stable now at all.

The problem was that the index into the array with the skill dependant aim constants exceeded the array size. With gcc there were some nans values after the array, with msvc there were valid floats. So it seemed that this was a linux problem, but it wasn't.

[markus_heiden]

It's time for a new release, I think :-)