Reduce weariness instability (includes tests); clarified

[actual-nh]

Summary

Bugfixes "Alter weary.tracker, weary.intake changes to be smoother; add tests for illogical fluctuations in weary level"

Purpose of change

This PR is to help avoid situations with unexpected fluctuations of weary levels, such as - during the same activity - the weary level reversing direction. (For instance, going from 2 to 3 during rest.)

These changes were mostly worked out in #47273. They reduce the current jumps in weary.tracker (and partially in weary.intake); these jumps, as demonstrated in test results (see #47273 and #47590), are partially responsible for weary level fluctuations. (Note that the test results for #47590 were without any modifications to try_reduce_weariness().)

It also adds tests for these fluctuations, although two are commented out since this PR does not completely fix the problem. (That will require more significant alterations in weary.intake - probably going to an exponential moving average (see #46906 for a bit on this) - which will take only a bit more work but require significantly more testing.) (See also #46384 and #48009; this PR is not a full fix for these, but should reduce the frequency of problems.)

Describe the solution

Decrement weary.tracker on a more frequent basis but - to compensate - reduce it by a smaller amount. (This will be every 5 minutes, which is how often try_reduce_weariness() is called.)

Also do this - decrementing more frequently but by a smaller amount - to weary.intake. Unlike with weary.tracker, this has not been done as much as it theoretically could be. This process involves a multiplication that is likely to result in more significant roundoff errors if done in much smaller amounts than the current PR. (By "more significant" is meant frequently having no reduction in weary.intake. The purpose behind the exact multiplier in use is also rather unclear.)There is some possibility of such roundoff errors happening with this PR's adjustments, but rather less so than if one tries multiplying by the 1/12th power of something at or above 0.95. (Note in this regard #47791's most recent results - specifically, the consistency across architectures and compilers, provided the testing seed is the same. Given that #47791 incorporates this PR's changes, this suggests that roundoff is not a significant problem with this PR.)

Describe alternatives you've considered

As noted above, this PR could go all the way to changing weary.intake completely. It could also try reducing weary.intake jumps further, at the risk of significant roundoff error.

The have_weary_increase() test function is not currently used; it can be deleted if desired. Done.

One could also stabilize the weary level by implementing hysteresis - as in, increase weary level at, say, 125% of the current threshold, but only decrease it at, say, 75%. This would be rather complicated due to the frequent threshold changes.

Testing

Test functions have been added to activity_scheduling_helper.cpp/h, and used in weary_test.cpp, to check for illogical fluctuations. (As noted above, these have been commented out in two instances since this PR is not a complete fix.) For other testing, see #47273.

Testing just the weary tests in a different order (with the 24-hour tests first, for instance) results in errors from both the new tests and existing tests. However, the same thing - with just the existing tests, of course - happens with the current master.

Additional context

Ping: @anothersimulacrum, @I-am-Erk?

[actual-nh]

@BrettDong: Thanks! Mechanics: Character/Player is another appropriate label.

[actual-nh]

The Travis error was due to a fields problem (see #47218 for one way this might be decreased).

[actual-nh]

@anothersimulacrum: Is it a feature, or a bugfix? I can admittedly see arguments for it being both...

[anothersimulacrum]

You're making mechanical changes, so that was my reasoning.
We have tests making assertions about how this works though, so I suppose with the size of the changes and that, it's probably pretty safe.

[actual-nh]

If you'd like to have more time to review over it first, feel free to do the Feature Freeze; as I said, I can see arguments for both - and I'd feel horrible if something somehow did go wrong with it for a stable release (OTOH, players are unlikely to be terribly happy with their weariness levels jumping around...).

[actual-nh]

Anticipating a request to remove unused code.

[actual-nh]

The LGTM failure was due to "There is not enough space on the disk"... sigh. (See #44598 for an earlier episode of this.)

[actual-nh]

@anothersimulacrum: I have just noticed that the expected timing numbers differ for the first 8 hours of the 8-hour and 12-hour digging tasks. I regret not having spotted this at the time of the metabolism de-randomization PR. I've just corrected the numbers for this PR's alterations (those I have lots of data for, thanks to #47791 - in particular, data for the weary tests done without any others).

EDIT: Now doing for 12 and 24-hour, and double-checking some of the 24-hour using new data. (The failure for the last one was with a sunburn test, which does not appear to be related.)

[actual-nh]

The Travis failure was the grenade lethality test... 🙄

[actual-nh]

GCC 7 General Build Matrix failure - fields test... sigh 🙄 .

[actual-nh]

@I-am-Erk: Could you take a look at this one? Thanks!

[anothersimulacrum]

I like it, especially that it's decreasing the lag between starting to rest and actually recovering.

Once my reviews are resolved, I think this is good.

[actual-nh]

Travis failure is due to a fields test:

 ../tests/field_test.cpp:359: FAILED:
(~[slow] ~[.])=>   CHECK( fields_test_turns() < time_limit_turns )
(~[slow] ~[.])=> with expansion:
(~[slow] ~[.])=>   300 (0x12c) < 300 (0x12c)
(~[slow] ~[.])=> with message:
(~[slow] ~[.])=>   Terrain should be irradiated under 300 turns

I've seen this one previously (enabled by wapcaplet's very helpful PR) - <= looks like it would be a good idea here... may put in a PR for this. EDIT: Done; see #48121.

[actual-nh]

Since #45316 has been committed, I'll need to do some conflict-fixing - probably tomorrow. EDIT: Done.

[actual-nh]

Checking on optimal predicted values to use in weary_test.cpp (changes as a result of #45316) - see #47791.

[actual-nh]

A rewritten version of the above commit description:

Unlike some of the other tests, for which one can figure out things
like consistency from test to test (8-hour vs 12-hour vs 24-hour) or
simply the weariness level not going down when it should be going up,
this one is currently close to impossible to figure out what SHOULD
result from it. It is more a check on whether the numbers are a lot
different than they have been. (There would be some justification in
changing the margins for this one to 10.) Thus, small adjustments in
it are sometimes needed; this is an example, with the value used
being from tests of multiple examples of it (see #47791).