[boskid][2.0.32] Crash if normal quality level is changed (AsteroidCollectorControlBehavior check fails)

[Aurilika]

What did you do?
A bug was reported for one of my mods, and upon testing it's a repeatable crash to desktop.

What happened?
Loading a space age save with the normal quality set to a level above 0 causes a crash to desktop related to the asteroid collector.

Replication steps:
Load provided save game and sync mods. Return to main menu, open mod settings for steeper quality, set normal quality level to 1. Then load that saved game again, it will crash to desktop mid-load.

What did you expect to happen instead? It might be obvious to you, but do it anyway!
For it to not crash

Does it happen always, once, or sometimes?
Always

Note: this post was edited to remove an unrelated unreleased mod from the save that didn't impact the crash.

[Stringweasel]

normal quality set to a level above 0

Pretty sure you cannot change this value (at the moment). The question is more if this is a hard crash or a well formatted crash.

Also, there's no crash in your log file.

[Aurilika]

normal quality set to a level above 0

Pretty sure you cannot change this value (at the moment). The question is more if this is a hard crash or a well formatted crash.

Also, there's no crash in your log file.

Oops, updated the log in the initial post. I added this because someone requested it and briefly tested it so not sure what you mean about not being able to change this value. The change seems to work normally if space age is disabled, but if it's enabled, there's a crash with the asteroid collector, presumably the logic for arms messes up by changing normal quality.

[boskid]

Thanks for the report. Issue is now fixed for 2.0.33.

Issue was that when a quality changes level, then asteroid collector of that quality had to rebuild its arms as the amount of arms has changed. This operation was not updating the total counter used by read contents in some cases. I already considered this case before so when asteroid collector control behavior is setup it recomputes the total counter from scratch but i failed to notice that arms are rebuilt after behavior does the recompute so it was effectively not working in this case.

I tried to reproduce this manually from scratch but i was unable however by investigating this save file carefully i found why the items were not accounted for by the control behavior: one of the hands when being deleted was over a space-platform-foundation tile so it was unable to drop held items so they remained in the collector's arm and when the arm was finally deleted, the stack of items held was simply removed from existence without notifying control behavior about the change in items count.