I think there is a requirement that when KoLmafia encounters a choice adventure it has never seen it should first do not harm and then, if possible, do something reasonable if that is obvious. If it can go a step further and record data so the next encounter is not considered new or unseen that would be good. If it could emit text or files that could be given to a dev to merge into existing files so the choice is known for everyone after commit and build (or equivalent) that would be great. The obvious example of this is data files that can have local overrides.
Gausie has his "Excavator" spading script. A hook could be added to it that spades unknown choices and options.
If the choice adventures information is code-driven, an unknown choice/option would be seen as such at best once per session.
If the information is data/text-driven, unknown choices/options would be seen as such at best once per person, period.
This would be a point in favour of going data-driven.
Whether we can create a generic choice adventure thingie, populate it with data from a file and then use it as a specific choice adventure is not clear to me yet. I am also not clear what fraction of choice adventures could be represented in this way. I don't expect a file to support choices that have situationally dependent responses given that I would rather the complexity b in the code and not in the file format.
This was also my main concern when the suggestion of having it all be data-driven was raised.
Later on, it was established that only the "default" state of each choice adventure would go there, but even then, not only was I still questioning the feasibility of such thing, which was still not addressed, this would also mean a subsequent issue in which the location of the default state of a choice adventure (the text file) is different/far from the location of where this state is modified (the code), making it hard to tell if you're making a mistake.
Is the location of item triggered choices a code issue or a missing or incorrect data issue?
main.php?comb=1, using the lock picking skill, using the "seek a bird" skill your 7th time, using the force in combat... there's a lot of "item-based" noncombats that don't start with a request to inv_use.php.
The answer would really be to note in which location the NCs happen.
As a dev I am unlikely to look at code to determine whether a choice consumes a turn or not so I am not sure how having that info is beneficial. I am more likely to use experience, the wiki or just assume it doesn't until informed otherwise
The default is definitely that it doesn't until proven otherwise.
A choice adventure ('s option) that costs a turn when we thought it didn't won't break anything. It will only cause some minor de-sync with features relying on it (which there is currently none, obviously. There
is one incoming feature waiting for this kind of information to be added, though).
To be honest, that very information (whether a choice adventure ('s option) costs a turn) is what initially drove me to do this refactor. However, at this point, it's not like I'd "do anything to keep it in".