Feature Removing or changing preferences in the future

[c2t]

If preferences that people could be using are going to be changed or removed in the future, at least give people a heads up in the commit summary. It is the very least one could do.

I do not appreciate having to waste a bunch of time trying to figure out why my scripts are behaving so strangely, just to find out after much troubleshooting that preferences that mafia has been using for more than a month are no longer being used.

If it was something that could have been caught at runtime easily, like function removal or CLI command removal, it probably would not have been so irksome. But because they were preferences, there is no feedback for that. Just scripts suddenly doing (or not doing) things inexplicably.

 

[Veracity]

Care to be more specific about what bothered you this time and what you wish had happened instead?

 

[c2t]

Sure.

What bothered me: shadowRiftLastNC and shadowRiftTotalTurns preferences were removed from mafia use without a mention anywhere, least of all in the commit summary.

What I would have wished would happen instead: mention of their removal in the commit summary the very least to let people know preferences that they might be using are just suddenly no longer used by mafia.

Or maybe even something like this: https://kolmafia.us/threads/feelnostalgicmonster-pref-renamed-to-lastcopyablemonster.26116/
Or this: https://kolmafia.us/threads/since-r...ired-please-use-crystalballpredictions.26970/

 

[Veracity]

Yeah. shadowRiftLastNC and shadowRiftTotalTurns were internal properties used is a particular implementation to calculate encountersUntilSRChoice.

There is literally no reason a user program should need to look at the two intermediate values when the calculated value was public.

We changed the implementation to not need (or maintain) the internal values, never considering that user programs were using them rather than the calculated value, since doing so made the scripts more complicated for, literally, zero value.

In retrospect it was a mistake to publicize the internal intermediate properties since changing the implementation - as we did - would obsolete them. We'll have to avoid that kind of trap in the future.

I'm sorry you got trapped into using properties that were always prone to become obsolete - and did, in fact, become obsolete.

 

[c2t]

I would not say they are entirely obsolete. shadowRiftTotalTurns was a superior version of _shadowRiftCombats, simply because it does not reset on rollover. But the worst version of the two remains.

Personally, I was using shadowRiftTotalTurns in particular to track NC-force things in the shadow rift. I would use an altogether separate preference to mark that the next turn in the shadow rift would be a forced-NC when a skill/item/etc of that sort would be used. In that way, it is basically set and forget, as shadowRiftTotalTurns would increment past the mark preference automatically so I wouldn't have to unset or change anything after it happens. _shadowRiftCombats does not work for that purpose, because it resets on rollover, and because NC-forces persist through rollover.

However, since those preferences have been removed, I have already genericized NC-force handling so I have no use for them either. It just would have been nice to get a heads up instead of having to waste time trying to figure out what was going on when a simple "these preferences are no longer being used by mafia:" in the commit summary, or really anywhere, would have saved time and headache.

The core issue is that removing or changing preferences does not error out at all like the removal of a function or CLI command would. Scripts will happily continue reading and using bad data from dead preferences. So a heads up when changes to established preferences (both of them had been in mafia over a month) would be nice in the future.

 

[Veracity]

_shadowRiftCombats has literally nothing to do with the other properties. That one is used to track how the monsters scale, the more you fight of them the same day.

 

[c2t]

It is almost as if people might use properties in ways you may not be able to imagine, so that can be added to the pile of reasons why the greater community should be informed when user-facing properties are changed or removed.