[DO NOT MERGE] Progress modal, new solver, beacon bonuses, productivity, etc...

#17 Open
Repository
xaviershay
Branch
default
Repository
Nicksaurus
Branch
default

Bitbucket cannot automatically merge this request.

The commits that make up this pull request have been removed.

Bitbucket cannot automatically merge this request due to conflicts.

Review the conflicts on the Overview tab. You can then either decline the request or merge it manually on your local system using the following commands:

hg update 
hg pull -r 69b2a92633d6 https://bitbucket.org/xaviershay/foreman
Author
  1. Xavier Shay
Reviewers
Description

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.

Binary download link if anyone wants to try without having to compile.

Changes herein:

  • Progress modal, per below/before.
  • 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 "pass through" nodes per #71
  • 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.

Thanks, Xavier

OLD DESCRIPTION

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!

Comments (14)

  1. Nick Powell repo owner

    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.

    1. Xavier Shay author

      Should do - all the code that was causing the divide by 0 etc errors has been completely replaced. Try the binary download link and let us know!

      1. Jackalope_Gaming

        Well, I downloaded the binary, unzipped it, ran the setup, and the UI showed up but it didn't have any language options nore could it read from the Factorio or mods folders. Not sure what's going on.

  2. nrieck

    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.

    1. Xavier Shay author

      Thank you!

      1. 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.

      2. Thanks, I had no idea! This is the first time I've written C# in a decade...

    2. Xavier Shay author

      I have fixed both of these issues. Thanks again for the review!

      Thoughts on adding CancellableProgress? It felt like I shouldn't need to do that but I didn't find a better way...