#GUI or CLI
graceful orchid
I must admit that I did not know your mod is just an information displayer while providing buttons to rotate the inserters.
I agree that:
- clicking buttons are better than having to rotate inserters;
- GUIs are pretty and people like them.
However, my arguments for CLI (or a command-heavy based interface) in this analytical situation still stand - a codified command that can start a simulation with the required configuration embedded in the codified command is still easier than having to click buttons.
Generally for a simulation analysis situation like this, nerdy me will want the following:
- reproducible test/simulation
- configurable outputs - some people only want the average value, some are into details like standard deviation, range
- ability to store a set of data to perform external analysis (that means the game only need to provide the raw data from the simulations and need not calculate the statistics in (2))
- easily modify or improve the testing method/scenario through modifying the codified commands - there might not be too many parameters for the simulation as of now, I am just anticipating for the testing methodology to improve in the future
By all means I do not mean to degrade your work on providing a GUI for this testing scenario. It is definitely a huge upgrade from rotating inserters and reading the result from signals.
I am just trying to highlight the potential of CLI-based tools for analytical purpose.
https://github.com/simulationcraft/simc/wiki/Features
This is a simulation tool for the popular MMORPG World of Warcraft. You can see from this part of the guide (https://github.com/simulationcraft/simc/wiki/StartersGuide#configuration) that there is a lot of tabs to configure the simulation.
But textual commands (https://github.com/simulationcraft/simc/wiki/StartersGuide#unleash-the-full-power-of-simulationcraft) can achieve the same. In my opinion, it is easier to use than the GUI when you want to make sure you are running the correct simulations, for comparable results.
If you still think there is no place for CLI in this situation, so be it and let's move on.
eager vigil
I can definitely see how CLIs are useful in that sense, however for the throughput testbench there are hardly any parameters to work with. currently the only interaction someone can have is "pressing" the inserter buttons, and the rest of it is all display.
I'll go over the points that you provided:
- reproducible test/simulation
the testbench already has that, by simply stopping and starting the test again. if you want to test different intersections and then come back to one later, you have to place the blueprint and hook up all the rails to it manually, so that's where any potential optimizations for repeating tests would be found.
- configurable outputs
there's really only one output for this, and that's TPM. maybe there could be something like WPM if you're comparing different train sizes, but that's about it (you can just multiply the tpm by the number of wagons). I can imagine some statistics like "average time spent in intersection" and "average time waiting" could be generated, but they are marginally useful at best.
- ability to store a set of data to perform external analysis
TPM is the raw data, and that's about the only thing people care about. same point as 2, there's not that much extra data to be generated and even if there was more it's not really that useful
- easily modify or improve the testing method/scenario through modifying the codified commands
I realize that this is meant for future proofing, however I don't think there's really that much for us to improve on.
the testbench is not meant to be configurable in every way possible for a bunch of different scenarios, it's meant to do one thing and one thing well:
measure throughput of intersections as consistently as possible.
it's also showing you the values in real time, as it's being measured, so I can't really imagine a better solution that either displaying it in world or in a GUI.
(running out of characters)