I have a rough idea of what might be causing this error. In one of the libraries I've developed, there is code that generates commands to immediately access elements in an array without checking for null references or bounds.

It's likely that this is the cause. In fact, such unchecked access is used because the JIT compiler sometimes fails to interpret my intentions correctly. To mitigate this, I have enforced strict conditions under which this potentially risky code can execute. However, it seems I might have overlooked some sections in this project.

Until I identify the exact cause, I will begin transitioning to safer code that sacrifices performance but allows for controlled, analyzable errors.

Thank you for your analysis and information. Please also take a look at my other projects and libraries :3

Oh, sorry. I just realized I haven't updated the git repository. LOL

What's terrible is that the error seems to be sporadic. Errors that aren't consistent are the worst to try and trace. I actually tried to get it to throw the error to collect more, but I wasn't able to get it to error out again.

Yeah, I saw some preprocessor directives I'm pretty sure were meant just for what you describe. I wish you luck with finding the cause.

Oh, I did forget to mention that while testing out your mod that, even when it didn't crash, the game wouldn't save. At least when I restarted and went to continue, after having started a new run previously, the game would load the previous run. It could have just been something isolated on my end, but figure I'd mention it anyway.

You probably won't have to worry too much about the performance. Hell, my current project is loaded with reflection calls and it runs without issue.

I more or less had the same idea as you in terms of end result but not execution. I created "Auto" versions of the production cards (like stove, oven, smelter, etc.). It takes advantage of the Modal input screen to get the user to submit a recipe name and a production limit. I then add that data to ExtraCardData so it saves and reloads with the card on start up. Each has a default recipe just in case and NaN is equal to 10. The user can enter the name off the card and there's a lookup dictionary for display name to id. The settings are also displayed in the card description panel.

What I like the most is that the "Auto" version will look for nearby ingredients and pull them onto itself. It refrains from targeting cards that are children of other cards like a farm. Once the limit is hit, I set StackUpdate to false and that stops the blueprint timer from starting. I mostly did this because after a while this game gets hard on the wrist... haha. Especially in late game. The cards, blueprints and subprints are all created dynamically during run time because no way was I gonna make that many JSON files.

Anyway, I'm rambling. I'm definitely looking forward to seeing this project grow. Got the GitHub projected starred so I can check it out as you update it. Also subscribed to the Bigger Capacity mod. Bigger storage is always welcome.

I really like the modal screen approach. I chose this method because I found screen design cumbersome and wanted something more intuitive.

I think the start of all these issues was my use of a little trick to reduce the load on network update operations.

In fact, I have also experienced inconsistent save-load issues and errors in several tests. What I've realized from the save-load issues is that the 'save' process works, which is terrifying. It's just the load that fails.

For now, I have reverted the code suspected to be closely related to these issues to safe code to avoid software crashes due to incorrect memory references.

If I had enough time, I would have tried to identify patterns through more testing, but unfortunately, I am busy with various tasks, so I hope to receive more feedback from many users.

I am also very interested in your ideas. It would be great if a good mod is developed.

Thank you once again for mentioning the issues and your analysis.

Hahaha, you're not lying about it not being intuitive. If I didn't have the ability to look at the disassembled assemblies I doubt I would have figured it out. The thing I like the least about this approach though is the lack of ability to let the user know if their settings were valid. Although, I suppose you could use the same window like a message box.

It's triggered by placing a human card on top of the card or the opposite. After verifying, you have to piece build the Screen layout. You can add multiple input fields which is nice, but then the validating is a bit cumbersome. I use a static class that holds lists I am likely to use repeatedly to avoid some overhead. When you finally add the confirm button, you follow it up with a delegate which acts as the confirm on click. I learned the hard way that you should kick the human card off the stack in that delegate. If you don't the modal screen immediately reopens and it essentially creates an endless loop, haha...

After writing that code a few times, I set it up so that the code body used variables which are conveniently placed at the top of the class so I don't need to search through the code to replace the references. After doing that creating the new classes was a breeze. I thought about using a central static class to do the validation, but I was worried about race conditions since there are just timers galore. The current way lets each class handle its own validation which is safer anyway.

Hahaha, that is a little crazy. The only thing I could think of is the WorldManager patch that tacks on an OnLoad OnSave member on to any object that has the IJsonSaveLoadable interface. But it's just a guess.

I totally get the too busy to do much of anything. I plan to tinker around with your mod too, so hopefully I'll make a useful discovery.

Thanks for the interest! I plan on making it available once I've tested it a bit more. I started on it a couple days ago and it's actually my first go at modding to this degree. I'm a lazy programmer/gamer. Problem was the mod I wanted didn't exist and then it just built momentum from there.

No problem at all! It was a learning experience for me too. Your implementation is stellar, especially for being one of many things your doing. And it's nice to see another programmer who emphasizes code organization. It's surprising how many programmers neglect that for speedier results.