Add setting to reduce impact of expired moments

[tmedwards]

Add a boolean Config.history setting for expired moments to either:

• Drop them outright rather than recording them in an Array.
• Change their storage to a Map and record the previous passage seperately.

NOTE: Both options would be irreversible—i.e., saves made with either enabled would be unable to be properly loaded with it disabled.

Rationale

Even with Config.history.maxStates set to a low value, games with a massive amount of turns can still begin to experience slowdown due to searching through the massive expired moments Array.

Option 1: Drop Expired Moments

Add a boolean Config.history setting to drop expired moments rather than recording them—e.g., Config.history.dropExpired.

Enabling this setting should:

• Change how the previous passage is recorded so that the previous() function continues to work as intended.
• Make dependent code throw an error so that end users never depend upon code that cannot work as intended with the setting enabled—e.g., the <<back>> & <<return>> macros, the visited family of functions, etc.

Option 2: Change Storage To Map

Add a boolean Config.history setting to record expired moments within a Map—e.g., Config.history.expireToMap.

Enabling this setting should:

• Change how the previous passage is recorded so that the previous() function continues to work as intended.
• Make dependent code throw an error so that end users never depend upon code that cannot work as intended with the setting enabled—e.g., the <<back>> & <<return>> macros, the lastVisited() function, etc.

[david-donachie]

Presumably this would affect how hasVisited() (still works with a map, not with a drop), visited() (can only ever return 1, unless the map stores a counter?) and visitedTags() (presumably reliable with a map, and not a drop), work.

What would you think about something like a State.history.trim(maxVisits) method, which just cuts the history to have no more than X instances of a given passage? That might not really be a gain over using a map to record the number of visits per passage

[tmedwards]

To clarify, and assuming that the previous passage is recorded separately. Simply dropping expired moments will break the (entire) visited family of functions and the <<return>> macro. Switching to a Map([[name, visits]]) would only break the lastVisited() function as it's the only one that depends upon order.

The <<back>> macro and Jump To dialog are affected simply by expiring moments. Changing how expired moments are treated doesn't further affect them.