Suggestion For Station Build Order

[stooper88]

Can we get a build order adjuster ?

(...) However, which one makes it easier for the devs to do what I actually desire?

The remark seems to suggest that an unusual and/or unclear ask was being made. However, I don't think the OP request was particularly vague or unreasonable. There is clearly an existing "build order" display within the station build editor, and the ask was to allow users to adjust the order of the elements within it. The concept should not be so alien considering a similar interface (Ship Order Queue) is already present in X4 with the desired functionality.

Code: Select all

          C1
           |
C4 - C3 - C2 - C5 - C6

That is a station with six modules. If we could build them in any order, then there would be 720 ways to build the station. Nice, isn't it?
Now, we are limited to:
A: 1,2,3,4,5,6
B: 1,2,3,5,4,6
C: 1,2,3,5,6,4
D: 1,2,5,3,4,6
E: 1,2,5,3,6,4
F: 1,2,5,6,3,4
Six different orders for construction, since a module cannot be built before the previous module on its branch is ready.

the easiest fix would be adding arrows

Would it be enough to be able to switch between A, B, C, D, E, and F with arrow buttons, rather than just with the jiggle of already planned modules/sequences?

The premise of this line of thought is false. Barring "clearance restrictions", modules can be built anywhere and in any order without any dependency on "previous" modules or branches whatsoever. This is regardless of whether they are fully connected, partially connected, or entirely disconnected. Therefore, there are indeed 720 (6!) possible ways to order the construction of the hypothetical station in question. And as such, it's not enough to be able to switch between six contrived sequences nor is it enough to be able to jiggle any particular modules or "branches" of modules. I'm honestly dumbfounded at this effort to paint the enhancement request as redundant or as just another entitled whim.

To hopefully dispel this myth once and for all, consider the below station or "branch" consisting of five connected modules. The initial placement consists of an ordinary array placed from left to right: A, B, C, D, E.



Aside from the tedium of wrestling with the existing interface, there is absolutely nothing that prohibits players from rearranging the construction order of these modules into any arbitrary configuration. Any of the modules can be moved to the end of the queue by removing and re-adding it. For example, module C (standard dock) can be removed and re-added to allow modules D and E to be constructed before it, all while preserving the physical order (i.e. planned location) of each module.



This exercise can be repeated at any point and any number of times to achieve any arbitrary build order. As an additional example, modules B and D (cross connects) can be removed and re-added to force the new build order to be A, E, C, B, D. In other words, this station would be constructed first at the extreme ends, then at its disconnected center, before finally at the attaching cross connects (in complete violation of the false "module cannot be built before the previous module" premise).



It's important to realize that this already works within the game but is extremely difficult and unwieldy for any but the most trivial of use cases (such as the examples above). This method also tends to fail once there are numerous completed modules already present as the editor tends to behave non-deterministically, randomly rejecting or being unable to re-position modules back into their original places. Hence, it would be a massive improvement to not have to resort to this backwards technique but to instead have a built-in sequence rearranger.

I also want to clarify that this ability to re-order modules wouldn't merely be for only aesthetic or non-functional purposes (i.e. "fluff"). There are myriad situations when it makes sense to prioritize and/or re-prioritize specific modules for construction: defense modules at gate stations, scrap processors before recyclers, production modules needed to fill unanticipated shortages, etc.

(...)

Not sure, for I have have not tried that. IIRC, you can happily remove arbitrary existing modules and later add new.

Therefore, if we assume that repair does not require specific order, then the initial build should not require either.

What that is likely to mean -- technically -- is that there could/should be an additional list that is the order of build, and which is initialized from the order we add modules (the current list that we see). A list we can later reorder by some UI (for the yet unbuilt modules).

Yes, exactly.

[adeine]

I'm honestly dumbfounded at this effort to paint the enhancement request as redundant or as just another entitled whim.

To hopefully dispel this myth once and for all, consider the below station or "branch" consisting of five connected modules.

Thank you for taking the time and effort to make this post. If I could give you an upvote/+1, I would.

One caveat is how the game internally represents snap points/which modules are 'linked together'. This is only relevant for moving/rotating the final build plan, and is why I've been asking for the option to 'link' or shift select multiple modules at a time for movement and rotation regardless of whether they're snapped together or not.

[TheDeliveryMan]

To hopefully dispel this myth once and for all, consider the below station or "branch" consisting of five connected modules. The initial placement consists of an ordinary array placed from left to right: A, B, C, D, E.

Let's go into the station designer and export the construction plan:

Code: Select all

<?xml version="1.0" encoding="UTF-8"?>
<plans>
  <plan id="42B42337-116F-4B00-9837-057224CC0FC6_1745470519" name="Test_A-B-C-D-E" description="">
    <entry index="1" macro="dockarea_arg_m_station_01_lowtech_macro">
      <offset>
        <position y="-27.204"/>
      </offset>
    </entry>
    <entry index="2" macro="struct_arg_cross_01_macro" connection="connectionsnap003">
      <predecessor index="1" connection="connectionsnap003"/>
      <offset>
        <position x="400.044" y="-27.204" z="-0.04392"/>
      </offset>
    </entry>
    <entry index="3" macro="dockarea_arg_m_station_01_macro" connection="connectionsnap004">
      <predecessor index="2" connection="connectionsnap004"/>
      <offset>
        <position x="800" y="-27.205" z="-0.08781"/>
      </offset>
    </entry>
    <entry index="4" macro="struct_arg_cross_01_macro" connection="connectionsnap003">
      <predecessor index="3" connection="connectionsnap003"/>
      <offset>
        <position x="1200.044" y="-27.205" z="-0.1317"/>
      </offset>
    </entry>
    <entry index="5" macro="dockarea_arg_m_station_01_hightech_macro" connection="connectionsnap004">
      <predecessor index="4" connection="connectionsnap004"/>
      <offset>
        <position x="1600" y="-27.205" z="-0.1755"/>
      </offset>
    </entry>
  </plan>
</plans>

We have one sequence, built from left to right. I'll add numbers do indicate the build order:

Code: Select all

1A-2B-3C-4D-5E

Aside from the tedium of wrestling with the existing interface, there is absolutely nothing that prohibits players from rearranging the construction order of these modules into any arbitrary configuration. Any of the modules can be moved to the end of the queue by removing and re-adding it. For example, module C (standard dock) can be removed and re-added to allow modules D and E to be constructed before it, all while preserving the physical order (i.e. planned location) of each module.

Code: Select all

<?xml version="1.0" encoding="UTF-8"?>
<plans>
  <plan id="42B42337-116F-4B00-9837-057224CC0FC6_1745470695" name="Test_A-B-D-E-C" description="">
    <entry index="1" macro="dockarea_arg_m_station_01_lowtech_macro">
      <offset>
        <position y="-27.204"/>
      </offset>
    </entry>
    <entry index="2" macro="struct_arg_cross_01_macro" connection="connectionsnap003">
      <predecessor index="1" connection="connectionsnap003"/>
      <offset>
        <position x="400.044" y="-27.204" z="-0.04392"/>
      </offset>
    </entry>
    <entry index="3" macro="struct_arg_cross_01_macro">
      <offset>
        <position x="1200.044" y="-27.205" z="-0.1317"/>
      </offset>
    </entry>
    <entry index="4" macro="dockarea_arg_m_station_01_hightech_macro" connection="connectionsnap004">
      <predecessor index="3" connection="connectionsnap004"/>
      <offset>
        <position x="1600" y="-27.205" z="-0.1755"/>
      </offset>
    </entry>
    <entry index="5" macro="dockarea_arg_m_station_01_macro" connection="connectionsnap003">
      <predecessor index="3" connection="connectionsnap003"/>
      <offset>
        <position x="800" y="-27.205" z="-0.08781"/>
      </offset>
    </entry>
  </plan>
</plans>

We have two independent seuqences, connector D is the root node of the second sequence:

Code: Select all

1A-2B
5C-3D-4E

This exercise can be repeated at any point and any number of times to achieve any arbitrary build order. As an additional example, modules B and D (cross connects) can be removed and re-added to force the new build order to be A, E, C, B, D. In other words, this station would be constructed first at the extreme ends, then at its disconnected center, before finally at the attaching cross connects (in complete violation of the false "module cannot be built before the previous module" premise).

Code: Select all

<?xml version="1.0" encoding="UTF-8"?>
<plans>
  <plan id="3C8C7366-2805-4893-BA5E-68B795928DA5_1745472804" name="Test_A-E-C-B-D" description="">
    <entry index="1" macro="dockarea_arg_m_station_01_lowtech_macro">
      <offset>
        <position y="-27.204"/>
      </offset>
    </entry>
    <entry index="2" macro="dockarea_arg_m_station_01_hightech_macro">
      <offset>
        <position x="1600" y="-27.205" z="-0.1755"/>
      </offset>
    </entry>
    <entry index="3" macro="dockarea_arg_m_station_01_macro">
      <offset>
        <position x="800" y="-27.205" z="-0.08781"/>
      </offset>
    </entry>
    <entry index="4" macro="struct_arg_cross_01_macro" connection="connectionsnap003">
      <predecessor index="1" connection="connectionsnap003"/>
      <offset>
        <position x="400.044" y="-27.204" z="-0.04392"/>
      </offset>
    </entry>
    <entry index="5" macro="struct_arg_cross_01_macro" connection="connectionsnap004">
      <predecessor index="2" connection="connectionsnap004"/>
      <offset>
        <position x="1200.044" y="-27.205" z="-0.1315"/>
      </offset>
    </entry>
  </plan>
</plans>

The sequence info is almost lost:

Code: Select all

1A-4B
5D-2E
3C

Usually, I design my stations in such a way that I can easily extend it by copying a sequence and attaching it to the existing plan. With a rearranged construction order this will get really messy.

Although it might be technically possible to allow for rearrangeing the build order while preserving the sequence structure, I don't think this is easy to implement.

[stooper88]

Thank you for taking the time and effort to make this post. If I could give you an upvote/+1, I would.

One caveat is how the game internally represents snap points/which modules are 'linked together'. This is only relevant for moving/rotating the final build plan, and is why I've been asking for the option to 'link' or shift select multiple modules at a time for movement and rotation regardless of whether they're snapped together or not.

Thank you for the kind support and for the help in uncovering the truth behind the "f i c k l e" mystery. Truthfully, I really only care about having this beloved game improved, especially in areas that I really didn't consider to be controversial. I'm also familiar with the issues you describe regarding being able to adjust multiple modules together. As you note, this is an issue regardless of whether modules are snapped (or "sequenced") together as station modules do not have to ALL be connected together or EVEN AT ALL. Apologies for the emphasis as this point seems to be constantly overlooked. Hence, I think your suggestion to allow shift-selecting multiple modules for grouping makes sense. I would even argue for control-click-selecting and grouping, similar to what's commonly done in Adobe, PowerPoint, Visio, and other graphical editors. I do think, however, that ES should be able to achieve reordering of modules without breaking snap-to connections (see below).

Let's go into the station designer and export the construction plan:

(...)

The sequence info is almost lost:

Code: Select all

1A-4B
5D-2E
3C

Usually, I design my stations in such a way that I can easily extend it by copying a sequence and attaching it to the existing plan. With a rearranged construction order this will get really messy.

Although it might be technically possible to allow for rearrangeing the build order while preserving the sequence structure, I don't think this is easy to implement.

The plans generated using the workaround steps I outlined are not ideal since they involve operations (removing and readding modules) which should be unnecessary and are disruptive. The actual implementation should absolutely NOT reproduce those steps in their entirety. Instead, the steps merely demonstrate what the game already allows and disproves preconceived notions about what isn't allowed.

A more intelligent implementation should be able to handle reordering the construction while preserving other relationships/metadata. To illustrate this, I manually modified the original plan (see below) and tested it in game. This plan applied very minor revisions yet preserves a single movable, rotatable, and reproducible "sequence" while also fulfilling the requirement to arbitrarily reorder construction. I have full confidence that ES has the competence to accomplish something similarly within the game.

Code: Select all

<?xml version="1.0" encoding="UTF-8"?>
<plans>
  <plan id="player_1745478274" name="Sequence03" description="">
    <entry index="1" macro="dockarea_arg_m_station_01_lowtech_macro">
      <offset>
        <position x="-3277.07" z="1006.669"/>
      </offset>
    </entry>
    <entry index="2" macro="dockarea_arg_m_station_01_hightech_macro" connection="connectionsnap002">
      <predecessor index="1" connection="connectionsnap002"/>
      <offset>
        <position x="-1677.07" y="-0.0002797" z="1006.493"/>
      </offset>
    </entry>
    <entry index="3" macro="dockarea_arg_m_station_01_macro" connection="connectionsnap003">
      <predecessor index="2" connection="connectionsnap003"/>
      <offset>
        <position x="-2477.07" z="1006.581"/>
      </offset>
    </entry>
    <entry index="4" macro="struct_arg_cross_01_macro" connection="connectionsnap004">
      <predecessor index="3" connection="connectionsnap004"/>
      <offset>
        <position x="-2077.026" y="-0.0001574" z="1006.537"/>
      </offset>
    </entry>
    <entry index="5" macro="struct_arg_cross_01_macro" connection="connectionsnap005">
      <predecessor index="4" connection="connectionsnap005"/>
      <offset>
        <position x="-2877.026" z="1006.625"/>
      </offset>
    </entry>
  </plan>
</plans>

[TheDeliveryMan]

For me it is very important that I can copy a subsequence or branch and attach that copy to the existing construction plan. I use this to extend the production, storage and docking capacities of my stations. I am not against the ability to change the build order, but the physical tree structure must be preserved. If the devs can implement that, that would be great. I just fear that it's not as easy as some people seem to think.

A more intelligent implementation should be able to handle reordering the construction while preserving other relationships/metadata. To illustrate this, I manually modified the original plan (see below) and tested it in game. This plan applied very minor revisions yet preserves a single movable, rotatable, and reproducible "sequence" while also fulfilling the requirement to arbitrarily reorder construction. I have full confidence that ES has the competence to accomplish something similarly within the game.

Code: Select all

<?xml version="1.0" encoding="UTF-8"?>
<plans>
  <plan id="player_1745478274" name="Sequence03" description="">
    <entry index="1" macro="dockarea_arg_m_station_01_lowtech_macro">
      <offset>
        <position x="-3277.07" z="1006.669"/>
      </offset>
    </entry>
    <entry index="2" macro="dockarea_arg_m_station_01_hightech_macro" connection="connectionsnap002">
      <predecessor index="1" connection="connectionsnap002"/>
      <offset>
        <position x="-1677.07" y="-0.0002797" z="1006.493"/>
      </offset>
    </entry>
    <entry index="3" macro="dockarea_arg_m_station_01_macro" connection="connectionsnap003">
      <predecessor index="2" connection="connectionsnap003"/>
      <offset>
        <position x="-2477.07" z="1006.581"/>
      </offset>
    </entry>
    <entry index="4" macro="struct_arg_cross_01_macro" connection="connectionsnap004">
      <predecessor index="3" connection="connectionsnap004"/>
      <offset>
        <position x="-2077.026" y="-0.0001574" z="1006.537"/>
      </offset>
    </entry>
    <entry index="5" macro="struct_arg_cross_01_macro" connection="connectionsnap005">
      <predecessor index="4" connection="connectionsnap005"/>
      <offset>
        <position x="-2877.026" z="1006.625"/>
      </offset>
    </entry>
  </plan>
</plans>

Well, the root node of the whole structure is still the Basic Dock Area, so clicking on it and copying the sequence copies the whole sequence. But if you click on the Standard Dock Area and copy the sequence you get the Standard Dock Area and the two connectors to the left and right. This is not what we had with the original plan, there we got the Standard Dock Area and the connector and the Luxury Dock Area to the right. So your example does not preserve the tree structure.

[stooper88]

For me it is very important that I can copy a subsequence or branch and attach that copy to the existing construction plan. I use this to extend the production, storage and docking capacities of my stations. I am not against the ability to change the build order, but the physical tree structure must be preserved. If the devs can implement that, that would be great. I just fear that it's not as easy as some people seem to think.

This is perfectly understandable.

Well, the root node of the whole structure is still the Basic Dock Area, so clicking on it and copying the sequence copies the whole sequence. But if you click on the Standard Dock Area and copy the sequence you get the Standard Dock Area and the two connectors to the left and right. This is not what we had with the original plan, there we got the Standard Dock Area and the connector and the Luxury Dock Area to the right. So your example does not preserve the tree structure.

With all due respect, the reordered plan does preserve the "tree structure" albeit relative to the new build order (C-B-D). Otherwise, logical errors are bound to occur. If copying the "sub-tree" at the central standard dock instead resulted in the original C-D-E sequence, it would not be reconcilble against the prescribed build order. The solution in your case is to not reorder any of the modules as the implication is that their original state is the desired build order state.

[adeine]

For me it is very important that I can copy a subsequence or branch and attach that copy to the existing construction plan. I use this to extend the production, storage and docking capacities of my stations. I am not against the ability to change the build order, but the physical tree structure must be preserved. If the devs can implement that, that would be great. I just fear that it's not as easy as some people seem to think.

Being able to select multiple modules for copy and paste and movement/rotation would be more powerful than just relying on sequences for this. You'd just select the modules in your branch from the list of modules or shift/drag selecting and do what you're doing right now (right click -> copy modules -> paste modules -> rotate and position as a group). Except that now you could also do it with unconnected or free floating segments, which are common in more elaborate build plans, even for some vanilla stations.

I believe the only time snap point connections do anything outside of the editor is for walkable connected docking areas, but even then I'm unsure. If you do the remove/readd trick on them, does that stop you from being able to walk from one to the other?

[jlehtone]

Now we are onto something!

station modules do not have to ALL be connected together or EVEN AT ALL.

I bet that the "connections" do not affect the function of station at all.
They seem to exist only to implement the "sequence feature" for us in the station planner.

The sequences are very convenient, when they can be used. For some ways to plan stations.
We can clone/move/delete (sequence of) thousand modules with "one click".

Let say I have designed two tentacle monsters that hug each other -- branches interleaved.
Now I need to move one of them. It being "one sequence" makes that easy.
Multi-selection of all the hundreds of modules of one "statue of Boron" -- could it ever be as easy as with the sequence method?

Alas, as said, there are non-rare scenarios, where the sequences are more an inconvenience than useful. We cannot simply move a module from middle of sequence, can we? We can clone&delete though.


IMHO, the order of build ought to be totally unrelated, separate to all that. We have a list of modules to build. Its order should not by tied to the sequences, order of placement, or whatever.

The re-enumeration of connections is/needs probably an independent procedure. Could it be fully automatic, or should player be given UI/chance to meddle with connections? (We did already saw that we can export file, edit, and import. That is not a preferred workaround.)


The "connections" are linked to "snap to" points, which are to help 3D-placement of modules. The "snap to" surely does not require any connections to be made. Furthermore, when you move a sequence, are all exposed snap-to points of that sequence considered for snapping, or only the exposed snap-to points of the one and only module (the "root" of the sequence)? Looked like the latter to me. Easier for implementation, but inconvenient for user. (All I had was sequence of two vertical connectors and could not directly copy to the "other side" -- 180 turn was requested.)

"Outlook not good", if we could select multiple modules and only one of them could "snap" when we move the group.

[vvvvvvvv]

I bet that the "connections" do not affect the function of station at all.

It doesn't affect function at all, and modules can be connected withuot being physically next to each other. Connect a module and move it away with CTRL held. It'll remain parented to the previous module, but there will be a gap between them.

Multi-selection of all the hundreds of modules of one "statue of Boron" -- could it ever be as easy as with the sequence method?

Nope.

Alas, as said, there are non-rare scenarios, where the sequences are more an inconvenience than useful.

I would argue this is not the case. Convenience of sequences outweighs inconveniences. I can't think of a single scenario where sequences got in a way.

We cannot simply move a module from middle of sequence, can we?

You can by detaching children first. Clone and delete is faster.

IMHO, the order of build ought to be totally unrelated, separate to all that. We have a list of modules to build. Its order should not by tied to the sequences, order of placement, or whatever.

At the moment modules being linked is tied to sequences. If you build sequences out of order, modules will not be parented to each other properly. And that is a big deal. Yes, player should be given the UI, but UI is not here right now. So until that linking UI is implemented, better not break existing functionality. Exporting XML, fixing order, and importing it back does not fix linking for modules that are already built.