Update MSG_FOREVER to be much longer

[rawr51919]

Bumped up the time given to bots in MSG_FOREVER to the largest possible float value in the C language, as per https://docs.microsoft.com/en-us/cpp/c-language/type-float. This might need testing.
Basically a rehash of clover-moe/mint-arena#5.

[deathsythe47]

I would use the FLT_MAX macro.

[rawr51919]

@deathsythe47 I agree. I'll update that as soon as possible, and it can be tested from there.

[ensiform]

FLT_MAX is unlikely to exist in QVM code or if it does, it's defined in bg_lib.h

[rawr51919]

@ensiform I'll have to check and see if FLT_MAX is there or not before I do anything to this PR.
EDIT: No, it isn't there, so it'll need to be added into bg_lib.h as part of this PR. I'll get onto that when I get the chance to.
EDIT 2: Added the FLT_MAX macro to bg_lib.h. How much time does FLT_MAX give to MSG_FOREVER when it's in this state, anyway? Does it need the f at the end of the macro, or does it work as-is like it should?

[ghost]

Would this is explain this ?
https://www.forbes.com/sites/erikkain/2013/07/02/quake-iii-arena-bots-reportedly-stop-fighting-after-4-year-match/#1790ab2e6233

[rawr51919]

Would this is explain this ?
https://www.forbes.com/sites/erikkain/2013/07/02/quake-iii-arena-bots-reportedly-stop-fighting-after-4-year-match/#1790ab2e6233

Most likely, yes. I'll have to fix Travis builds on this PR before this can be merged.

[zturtleman]

The linked story is a hoax. Bots don't 'learn' in-game.

The Quake 3 server automatically reloads the map after 23 days to avoid milliseconds in 32-bit integer wrapping around to negative values. Bot data is reset then as well. Extending bot order duration of "forever" beyond the current value of ~3 years doesn't affect anything.

---

Changing the duration for MSG_FOREVER is an unnecessary (map can't run long enough) and using FLT_MAX is difficult to review side affects. I don't endorse this as a good idea.

For example float next_goal_time = goal_time + 10.0 will cause both goal times to be equal if goal_time is FLT_MAX. This could be an issue if comparing goal times to each other. Q3 bot AI doesn't appear to do this (no promises) but it should also be checked by derivative games. This seems like a lot of review and testing (with floating point exceptions enabled?) to not actually fix anything right now.

Regarding the pull request:

#define FLT_MAX       0x7f7fffff

This is the memory representation of IEEE float max. You can't assign it as float t = 0x7f7fffff because it is interpreted as a float, not memory. float t; *((int*)&t) = 0x7f7fffff; will set the memory to 0x7f7fffff but it would be best to change FLT_MAX to a float like standard system define.

Having MSG_FOREVER be t = FLT_MAX followed by FloatTime() + t may introduce new issues due to float overflow. (It clamps to FLT_MAX and is probably fine as long as floating point exceptions aren't enabled.) This could be fixed by changing it to return FLT_MAX assuming no code ever adds time to this (which I can't guarantee).

t = FLT_MAX; // 3.402823466e+38 minutes

This is seconds, not minutes. Not that it can be comprehended anyway.

[rawr51919]

The linked story is a hoax. Bots don't 'learn' in-game.

The Quake 3 server automatically reloads the map after 23 days to avoid milliseconds in 32-bit integer wrapping around to negative values. Bot data is reset then as well. Extending bot order duration of "forever" beyond the current value of ~3 years doesn't affect anything.

Changing the duration for MSG_FOREVER is an unnecessary (map can't run long enough) and using FLT_MAX is difficult to review side affects. I don't endorse this as a good idea.

For example float next_goal_time = goal_time + 10.0 will cause both goal times to be equal if goal_time is FLT_MAX. This could be an issue if comparing goal times to each other. Q3 bot AI doesn't appear to do this (no promises) but it should also be checked by derivative games. This seems like a lot of review and testing (with floating point exceptions enabled?) to not actually fix anything right now.

Regarding the pull request:

#define FLT_MAX       0x7f7fffff

This is the memory representation of IEEE float max. You can't assign it as float t = 0x7f7fffff because it is interpreted as a float, not memory. float t; *((int*)&t) = 0x7f7fffff; will set the memory to 0x7f7fffff but it would be best to change FLT_MAX to a float like standard system define.

Having MSG_FOREVER be t = FLT_MAX followed by FloatTime() + t may introduce new issues due to float overflow. (It clamps to FLT_MAX and is probably fine as long as floating point exceptions aren't enabled.) This could be fixed by changing it to return FLT_MAX assuming no code ever adds time to this (which I can't guarantee).

t = FLT_MAX; // 3.402823466e+38 minutes

This is seconds, not minutes. Not that it can be comprehended anyway.

So you're saying that, in order to use FLT_MAX here, it'd require some tweaking (and probably a bunch of testing, too). Also, that comment could easily be fixed.

Comment's fixed at least now, the testing will still need to be done on this PR.