Solver Rewrite

[ClaudeMetz]

This is a mammoth project, probably even bigger than the class rewrite, because of all the additional features/fixes that are attached. It also needs a different approach than the current one, because it has a lot of issues.

Not quite sure what that approach is, but the current way is too confusing. Especially the data storage and the way to hand back the data is too weird. I think the goal should be to have the interface do as much of the data wrangling as possible, meaning the stuff the solvers give back should be as basic as possible, basically only the stuff the solvers can do, and the interface figures out amounts, energy, satisfaction, etc. Hard to say what exactly it could do, will need to figure that out. To facilitate this, having a method to return results for individual lines will be easier than the solver having to collect it all itself, and probably allow the interface to do more of the work.

One big issue with it is that it would break the matrix solver, either requiring someone else to fix it or for me to understand and redo it myself. We'll see how that works out...

One big underlying improvement is to finally use a test framework to make sure the calculation results are correct. It is really hard to make changes if you don't know if you broke anything else. Really, tests should have been part of the classes rewrite, but they need to be part of this rewrite. For tests to be feasible then, the code needed a lot of refactoring (including the classes, ironically). Then, global variable usage needs to be minimal, using requires as much as possible. The test framework will be worked out alongside the rewrite, so it fits the what we need for that.

This rewrite will enable a ton of other improvements and fixes to finally be addressed. Some of them will be able to be incorporated as the rewrite it happening, others can be done afterwards, but still need to be kept in mind during it. This super-issue lists all of these below.

Additional ideas

• I should consider making power and pollution normal items. They are treated separately now, but if they were items (that are a bit special for sure), that would save horizontal space in the production table, make adding power-producing recipes much more straightforward, and more. I think I really should do this. Same idea for heat, actually. Will be tricky, as they won't follow many of the view states, among other problems.
• energy_consumption is called power everywhere else now, so do that rename.
• The aggregate should use prototypes as keys instead of the two-tier structure that exists now, will make things much simpler to handle. Will have to see if using prototypes as keys is totally safe or not.

Matrix solver ideas

• Make solver work with subfloors/allow enabling it only on certain subfloors
  • This could be done by first figuring out the total input/output items of subfloors (no solving really), then use that as a 'recipe' for the above floor matrix solver, then go back to the subfloor and solve it with the demands created above.
• Add the ability to split work over multiple ticks, especially for the matrix solver, with a potential progress bar etc.

Graph-based approach

As for what the technical approach for implementing this could be, there is this text:

• Thinking about topological ordering gave me big ideas. The solver could be graph-based as well potentially
• You would convert it into a topological graph always.
  • That has as a consequence that the factory will always be ordered topologically, which is actually great as it removes the need for the user to order recipes. It needs additional bookkeeping though, as cyclic and duplicate recipes break the factory and need addressing immediately. But that is probably a worthwhile tradeoff. Whether the user should still be able to reorder if they want to is to be decided, but probably yes. Maybe through a more cumbersome UI though.
• With that graph it would just go down the topological order and run the recipes associated with each
  • It would plug in the demanded product amount at the top, and then carry other amounts downwards through the graph
  • It would probably just set the production ratios on everything, and then a second pass calculates it all out and does the bookkeeping, which is the easy part and would also be cleaner this way.
• It is not clear what current features this could still support (machine limit, priority product, etc), so it's hard to say whether it'll end up better in the end. Obviating the need for ordering recipes would be great though.
• In addition, this would (I think!) also easily allow input-based calculations, which is sorely needed
  • The way to do it is to just go through the topological graph in reverse direction, and running the attached recipes that way (they would be the ones that consume the node, not produce it, but otherwise it'd be the same.)
  • This has other side effects, such as needing to decide whether a factory is input or output based, and the byproducts needing to be renamed to 'additional products/ingredients' or whatever. Lots of UI work but doable.
• If this turns out to work (big IF!), it would be an amazing way to clean up the solver code which introducing important features like input-based calculation and presenting a nicer interface by removing the need for ordering. win-win-win
• The matrix solver would just remain the same as previously (which is bad for UI complexity), but I think I won't avoid writing my own matrix solver (or simplex or whatever) at some point, just because the current situation is rough.