Hi Nick, hope uni is treating you well! Here is a giant unreviewable mass of code - I intended to open a separate PR from the progress one but I clearly don't know what I'm doing with Mercurial. Still work to do here, but wanted to get your feedback on general directions. I'm about to head away for a week so won't be working on it.
Replaced homebrew LinearSolver with the one from Google's OrTools. This fixes all the bugs I could find on this tracker, as well as a few others I found while testing edge cases, primarily around multiple nodes with the same recipe/input/output.
Use a more comprehensive set of constraints for modelling flow, which has the side-effect of moving link flow calculations into the solver. Removes a heap of code. Also means under-supply is no longer possible. Instead, if two fixed constraints are in conflict one will be "relaxed" and it will be shown to the user by drawing a thick red line around the box that is conflicting. I also slightly changed the semantic meaning of actual vs desired rate. Actual = what the solver said, desired = what you fixed it to, only valid if RateType.Manual. This simplifies things I think.
Added test coverage to the solver, including a fluid builder for setting up test cases.
Support arbitrary speed and productivity bonuses, including saving/loading them. The first to model beacons, the second as a hack so I could calculate flows including them without needing to fully support modules (but will still be needed until rocket-as-assembler is modeled for rocket parts - I think there's another ticket about that).
Support for productivity modules, with a caveat that I removed multi-assembler types (discussion on #57)
Added some folders into the project hierarchy for better organization. I thought they would be tracked as renames, but in hindsight looks to be screwing over the diff :(
With all these changes, I have sufficient features to model a full yuoki rocket flow that includes beacons, productivity, cycles, and duplicate nodes (my initial goal).
There are still a few TODOs in the code as well I need to address (such as handling Big Numbers gracefully).
Interested in your thoughts on these directions, and anything in particular that's hard for you to wrap your head around so I invest more time preparing a more review-able version.
Thank you for this tool, it's very useful :)
I moved data loading to the background and added a progress bar. Otherwise the UI locks during the load, which is particularly noticeable when many mods are loaded (10+ seconds).
The progress bar is modal, so still effectively synchronous. Making it properly async (so the user could interact with the app while loading) would require a much bigger rethink of the data model, since it currently assumes DataCache is consistent.
I haven't written C# in over a decade, and even then never professionally, so style guidance welcome!
Thanks for putting in the time to do this, it's very impressive.
Unfortunately, I won't be working on foreman for several weeks because I'm focusing on my final year uni project for the moment. I'll definitely get around to it (and the other pull requests I've been neglecting) once that's done though.
Some quick notes: The revamped production solver does not seem to handle stuff like oil processing when using pass-through nodes. If you combine light and heavy oil cracking the latter is ignored. It shows an oversupplied heavy oil input but does not produce anything since all light oil demands are already met by the refinery.
Please do not use BackgroundWorker for asynchronous stuff. It should be considered obsolete (especially on .NET 4.5 and above). async/await and tasks are a much better solution.
That's desired behaviour I think? What were you expecting? [can you screenshot me?] If you have oversupply in the system it's undefined where that oversupply will accumulate (you see this in big cyclic recipes). You can "siphon off" excess production using an infinite consumer node if you like.
Thanks, I had no idea! This is the first time I've written C# in a decade...