[2.0.47] Pasting space platform hub cancels enabled requests

[Hares]

Steps to Reproduce

1. Have a space platform with enabled requests via groups, named or anonymous
2. Copy space platform hub
3. Paste space platform hub onto itself

Expected:

• Nothing changes

Actual:

• All active requests group become disabled, regardless of being named or anonymous
• Undoing does not revert that change

Click to expand the recording

[Hares]

To clarify, in case this is working as initially designed: I am OK with the fact new request groups from pasted blueprint are added in a disabled state. However, groups those do already exist in both old state and new state (and especially when having the same multiplier) should remain enabled.

How I discovered this issue -- I copied space platform hub into a blueprint, copied it into a string, and duplicated interrupts via terrible Python code, then pasted updated blueprint on top of that platform. After a few hours I discovered the satellite platform stopped supplying resources because all imports were suspended.

[Rseding91]

What's the desired outcome with pasting an entity onto itself? Theoretically - do nothing? "it already has the exact settings of the source entity"?

[Hares]

What's the desired outcome with pasting an entity onto itself? Theoretically - do nothing? "it already has the exact settings of the source entity"?

Yes.
Also, as I wrote above, I initially discovered this problem when pasted blueprint with schedule being changed, all other settings were kept the same.

However, the different behaviour is observed.

[Hares]

How I discovered this issue -- I copied space platform hub into a blueprint, copied it into a string, and duplicated interrupts via terrible Python code, then pasted updated blueprint on top of that platform.

If you are curious, this is exactly how blueprint was changed:

Code: Select all

def update_schedule(bp: Blueprint) -> Blueprint:
    assert len(bp['entities']) == 1, "Expected to contain exactly one entity being space platform hub"
    hub = bp['entities'][0]
    assert hub['name'] == 'space-platform-hub', "Expected to receive a space platform hub."
    assert len(bp['schedules']) == 1, "Expected to contain exactly one schedule being space platform hub's schedule"
    interrupts: List[InterruptRecord] = bp['schedules'][0]['schedule']['interrupts']
    # Path('blueprints/data/schedule.json').write_text(json.dumps(interrupts, indent=4))
    
    base_planet = PLANETS[0]
    for route in ROUTES:
        base_route_file = Path('blueprints/data/src/schedule-interrupts') / f'{route}-{_as_id(base_planet)}.json'
        base_route: InterruptRecord = json.loads(base_route_file.read_bytes())
        for planet in PLANETS:
            target_route = replace_planet_in_record(base_route, from_planet=base_planet, to_planet=planet)
            for item in interrupts:
                if (item['name'] == target_route['name']):
                    print(f"Route '{item['name']}' already exists, skipping.")
                    break
            else:
                print(f"Adding Route '{target_route['name']}'...")
                interrupts.append(target_route)
    
    return bp

[tinker9]

What's the desired outcome with pasting an entity onto itself? Theoretically - do nothing? "it already has the exact settings of the source entity"?

There are two typical use cases here:
- pasting a platform over an empty hub: the goal building the platform. So building ghosts should be prioritised over any requests, or requests should be off.
- pasting a platform over an existing hub: the goal is not to break anything that's already working. So requests that are already on the platform should stay enabled.

There's two ways to satisfy both these goals:
1. when pasting, new requests should be off
2. when pasting, requests should match the settings in the source (like requester chest pasting). But this only works if building ghosts are prioritised.

Number 2 seems more intuitive, because it matches requester chest copy-paste, and it is useful to be able to copy-paste enabled requests.

[Rseding91]

Ok, so I just watched the attached video and need to make some corrections. When you said "Copy space platform hub" and then "Paste space platform hub onto itself" I was reading that as "shift + right click" -> "shift + left click" which it's not. You're doing "activate copy hotkey which puts a blueprint in the cursor" and "build blueprint over top of the existing entity".

That doesn't change much except I looked at the wrong logic (copy-paste onto itself already does nothing). Building a blueprint over top of an entity will always do the paste logic because the two are never the same entity - one is in a blueprint - and one is in the world - even if the blueprint originated from the world entity.

With that in mind: looking at the code - it was specifically programmed to function exactly as it is now. Pasting settings onto a space platform hub always leaves it paused with all sections disabled - regardless of the source entity.

It was done this way on purpose so when copying settings the platform doesn't immediately start requesting items from the planet and or start flying away to some other location. The player has to make a conscious choice to enable what sections they want enabled and then set the platform in motion.

[Hares]

It was done this way on purpose so when copying settings the platform doesn't immediately start requesting items from the planet and or start flying away to some other location. The player has to make a conscious choice to enable what sections they want enabled and then set the platform in motion.

As I (and tinker9) wrote above, this makes updating existing platform scenario extremely wierd. Also, as was discussed in this topic (128416: [2.0.45] Inserter's settings not applied when copying), pasting via Shift+LMV and pasting via Ctrl+V behaving differently is a complete design mistake for me. Otherwise, these actions should NOT be called via the same word:

04-30-2025, 18-10-04.png (120.94 KiB) Viewed 172 times

Also, beacause in 1.1 remote actions were not a thing, there's old habbit to always transfer settings on individual entities via Ctrl+V.

[tinker9]

That doesn't change much except I looked at the wrong logic (copy-paste onto itself already does nothing). Building a blueprint over top of an entity will always do the paste logic because the two are never the same entity - one is in a blueprint - and one is in the world - even if the blueprint originated from the world entity.

With that in mind: looking at the code - it was specifically programmed to function exactly as it is now. Pasting settings onto a space platform hub always leaves it paused with all sections disabled - regardless of the source entity.

It was done this way on purpose so when copying settings the platform doesn't immediately start requesting items from the planet and or start flying away to some other location. The player has to make a conscious choice to enable what sections they want enabled and then set the platform in motion.

Thanks, this makes sense as a design choice, but it's not easily discoverable.

I assumed that copy blueprint (control-C) and copy settings (shift-right-click) would always operate the same way. Is there some way to show users they're different?

Maybe you could add an "are you sure?" dialog like the delayed undo dialog when using blueprints on a populated hub/space platform, with a note to use copy settings if they want the "copy exactly" behaviour?

This design choice also misses a use case:
- I changed a platform's settings, and also buildings (or wires) on the platform, and I want to copy to all the other platforms of the same kind

To do that now, I need to:
- copy entities using a copied blueprint onto the platform
- copy settings exactly onto the hub

This is a bit counter-intuitive, and also hard to discover.