Numbered Steps to Reproduce Problem:
Use 1.#IND or -1.#IND as a literal.
Receive zero.
Code Snippet (if applicable) to Reproduce Problem:
/world/New()
var/nan = -(1.#INF/1.#INF) // make a true NaN value
world.log << nan // "1.#IND", or "nan" on Linux
world.log << 1.#IND // "0"
world.log << (nan == 0) // "0" (false)
world.log << (nan == 1.#IND) // "0" (false)
world.log << (nan == nan) // "0" (false)
world.log << (1.#IND == 0) // "1" (true)
world.log << (1.#IND == 1.#IND) // "1" (true)
Expected Results:
NaN literals would produce a NaN value when used; above code would print:
1.#IND
1.#IND
0
0
0
0
0
Actual Results:
NaN literals produce zero; above code prints:
1.#IND
0
0
0
0
1
1
Does the problem occur:
Every time? Or how often? Every time
In other games? N/A
In other user accounts? Unknown
On other computers? Yes
When does the problem NOT occur? Unknown
Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? Unknown.
Workarounds: Don't use NaN literals?
var nan = -(1.#INF/1.#INF)This is actually giving me a value of 1.#QNAN which is new - I thought that only happened on Windows 8 or 10; I'm running Win7.
var nan = 1.#INF-1.#INFThis gives me -1.#NAN though, but it's still not equal to the compile time -1.#NAN.