[2.50.2] Game->Generic[] -> As Unfloored Floats

[ZoriaRPG]

One thing that would, or should, be easy to add to 2.50.2, is a conversion of the values stored in Game->Generic[], so that the user may utilise them as floats. I noticed that, Game->Generic[GEN_MAGICDRAINRATE], if set to '0.5', returns as '0'. This is interesting, as if you wanted to make all magic costs higher, you could set the value of that index to '3', or more; but you cannot actually lower costs below 1/2 (an index value of '1').

Changing it to a float, would mean that a value of '0.5' in that index spot, would quarter magic costs. I see some other possible uses for this array, but that is the most prominent.

[Anarchy_Balsac]

A double would be better. Floats sometimes have weird, unintended side effects, which is why I NEVER use them.

[Tamamo]

I pretty sure do to the way the engine handles numbers everything is a fixed point number.
Why cause ALLEGRO was written in the 90s! :upyours:

[ZoriaRPG]

I pretty sure do to the way the engine handles numbers everything is a fixed point number.
Why cause ALLEGRO was written in the 90s! :upyours:

I wouldn't think that there is any reason that floats wouldn't work, but I really doubt it: It shouldn't matter, because the internal value is ZScript * 10000.

Thus, if Link->X/Y/Z was a float in ZScript, the input would still be an int, for Allegro, but it wouldn't change the position of Link's object, until the value was 10,000, 20,000, ... .

e.g., You could write Link-X += 0.01 in ZScript, which would add +100 to the internal variable. Once those cumulative +100s reached 10,000, Link's position would change. At least, that seems logical.

P.S. For whatever reason, Link->Jump is a float when you Trace() it to allegro.log. It's supposed to be a pixel value, but I also know that it as a bug that Saffith only recently resolved, so I'm unsure if the behaviour there, is related to that. The internal variable for Link's XYZ coordinates, may be declared as a fix.