Remove multibuild (Split and Merge multibuild tasks)

[theis999]

Multibuild is a complex mechanic, that reduces the total number of tasks. Making it easier to move tasks between each other. However it is hard to optimize the step order.
2 buttons to split or merge steps into larger tasks, could help.

[MortenTobiasNielsen]

It might be worth exploring if the multibuild feature can be remove entirely, expect for when the steps are created.

[theis999]

I don't think it is feasible to remove multibuild. As Zaspar does use it and the Step Planner can create tasks with it too.
Though i would have liked that it was never added as a feature 😶

Your idea, of creating the multibuild steps on creation, sounds similar to auto-put. Which is easier to deal with however also has its own issues. For instance updating the parent step doesn't change child steps.

[MortenTobiasNielsen]

I guess it could be handle as a checkbox where you enable that multibuild is split when added to the grid. It will though add even more complexity. It wouldn't be as easy to change multiple buildings, but template can be used for most things - like changing the amount of fuel. I find that it is very rare that I actually want to change all buildings to the same thing other than when I first build it.

It might though be that I am overthinking the complexity and it actually can be done relatively easy.

[theis999]

I use the TAS step planner to create most steps, so having multibuild step creation wouldn't affect me much. However if we got rid of it but still have to provide legacy support. That sounds to me like we have gained nothing.

It is not particularly hard to split a multibuild step. As most of the code for unrolling the substeps is already available. So i do have an implementation ready for this.

I think the simplest solution for merging: is to split all selected steps, then order them either by X or Y, and then check if they match. After all that we can start to merge the steps, but there are a non-trivial questions here.

• The first step might be in the middle of the multibuild, which makes it hard to determine the direction.
• Their might be selected 2 or more step blocks, and while a multibuild step can replace a block it is unclear what should happen with more.

[MortenTobiasNielsen]

The step planner and the template functionality have also made the multibuild obsolete for me. It only makes it more difficult to do things later in the run.

My thought was to add an unrolling step to the open TAS, so all step afterwards could be treated as one unit. I think that could remove a lot of complexity with validation, saving and in the future opening files.

Given that I think multibuild steps with the tooling currently available doesn't really provide any benefit but will make it more difficult to work with later, I don't see why we would want a merge functionality with all the potential complexity it will add.

[theis999]

I have a lot of thoughts on the subject of removing multibuild, so i'll try my best to unpack them:

Fundamentally i think multibuild was a good idea for it's time. However it has a many weaknesses. It simplifies interacting with multiple buildings, however usually in an unoptimized way due to the internal order.
The current implementation also has the problem that it takes up a lot of screen space. With 3 fields in the control row and 3 columns in both templates and step grid.
It is also one of the few higher abstraction level functions provided, and it would be sad to have fewer of those.

I think performance would overall be better without multibuild. While multibuild reduces the overall amount of rows in the grids and lines in the TAS file. It also makes each row / line longer, so overall those should balance out. However for generating the lua steps file, not having to unroll multibuild should make everything slightly faster.

Adding a migration step to opening old TAS files could work to remove multibuild. I feel like if we go down this route it might be nice to re-save the TAS file in a new format, that doesn't have to deal with compatibility.

I have been contemplating a new concept, that i call linked-steps. Where for instance you have task of Put X recipe into assembler. Lets say the recipe is burner mining drill, so the steps of the task is put [1 stone furnace, 3 iron gear wheel, 3 iron plate] multiplied by X. Then the linked-steps can be re-order within the overall task, or just have the no-order applied to them.

[MortenTobiasNielsen]

Agreed. I actually don't think it is a problem to not have higher abstraction functions due to the supporting tooling. When steps are gathered it makes it difficult optimize and reuse.

Yes, I am also pretty sure that it would be a performance gain if the code could just use the numbers instead of having to unroll and thereby compute the fragments of the multibuild.

Do we have a problem with the file itself having to deal with compatibility - isn't only open and save which has to? I would though be nice to be able to strip all of the compatibility code out of the codebase. I am just not entirely sure how we would do that.

Not entirely sure I understand. What would I as a user do in the UI and how would it differ from what I would do now?