Config to disable hardcoded NPC terminal velocity

[MrDoubleA232]

Currently, all NPCs (except for 259 and 260) are hardcoded so that they cannot move more than 8 pixels down per frame, even if the nogravity config is set. This adds a config, "noterminalvelocity", which disables this behaviour.

Replaces this line with a hook that checks the config. NPCs 259 and 260 have it set by default.

The hook does not push and pop any registers to save them. As far as I can tell this is safe here, but I could have missed something.

[Supermario1313]

I don't notice any issue with registers. Sure, __stdcall functions are allowed to overwrite eax, ecx and edx but the code after 0xa10170 doesn't need their value so there's no need to backup them.

[Bluenaxela]

Yeah, the registers should be fine.

So, I was checking old discord logs for reference to this stuff, and it turns out 6 years ago I had brought up considering implementing exactly this hook.

At the time, one thing I had considered was, rather than making this simply a boolean, it could be implemented as a double value, to use as a the limit. Could make NaN (and maybe numbers <= 0) mean no limit. Or could make 0 mean default and negative mean no limit... I'm unsure. I do think being able to set specific limits rather than disabling the limit could be convenient for some uses though.

Any opinion about making it a configurable limit rather than boolean?

[Supermario1313]

Making the limit configurable is a good idea imo. In that case, isn't it enough to just use floating point infinity to mean no limit?

[MrDoubleA232]

Ah, I just made it a boolean because it's pretty trivial to add a speed cap. But thinking about it now, letting you set a terminal velocity would be handy for if you're just using a txt file to modify an NPC rather than making a custom one. Should be able to do it soon.

[Bluenaxela]

Making the limit configurable is a good idea imo. In that case, isn't it enough to just use floating point infinity to mean no limit?

Oh yeah, infinity works, though, do the txt files parse that currently? Because if not it could be an argument for giving special meaning to a value that is < 0 or something.

[Supermario1313]

Seems like infinity is not handled by configfilereader.lua, but adding support for it should be pretty trivial.

(between line 40 and 41)

elseif value == "inf" then
    value = math.huge
elseif value == "-inf" then
    value = -math.huge

This implementation should be backwards-compatible since tostring(math.huge) and tostring(-math.huge) return respectively "inf" and "-inf".

[MrDoubleA232]

Finished adding the configurable limit. I went with 0 meaning default speed (8) and negative numbers or infinity meaning no limit.

[Supermario1313]

Seems like infinity is not handled by configfilereader.lua, but adding support for it should be pretty trivial.

(between line 40 and 41)

elseif value == "inf" then
    value = math.huge
elseif value == "-inf" then
    value = -math.huge

This implementation should be backwards-compatible since tostring(math.huge) and tostring(-math.huge) return respectively "inf" and "-inf".

I've just realized that luajit can parse inf, -inf and nan with tonumber. Therefore, this addition to configfilereader.lua and using negative numbers to represent infinity are redundant.