Open faceboogle opened 5 years ago
So the solution here would be to check desert progress when the script starts, rather than relying on its own progress trackers.
Why does sl_ascend use its own progress tracking for quests, anyway? It should really use existing KoLmafia properties whenever possible.
If there isn’t a reason, I might submit a pull request to rework the simpler cases.
If you can remove any sl_ascend specific progress trackers without things breaking (ie I would expect a large amount of testing before I accepted a pull request) I'm all for it. Those are all carry-overs from cc_ascend, I'm pretty sure.
If you can remove any sl_ascend specific progress trackers without things breaking (ie I would expect a large amount of testing before I accepted a pull request) I'm all for it. Those are all carry-overs from cc_ascend, I'm pretty sure.
I’m not sure how to test this sort of thing extensively without a bunch of ascensions, but I was thinking along the lines of reading through all of the code related to a given property (i.e. by searching for it in the source code), then replacing the ones I completely understand the nature of with the built-in equivalents. That’d cover most of them, I imagine (most of them seem to be practically booleans), and I could leave the rest for the moment.
I have 20+ recent HC ascensions with all property changes logged. Should help sanity check the state transitions. Happy to comb through and identify properties for removal (sl_* properties that always change in sync with a Mafia quest tracking property)
At least, I did it manually and now it seems to be trying to do it again. HC 2CRS ascension
Cheers E