Page 1 of 1

[2.0.47] Pasting space platform hub cancels enabled requests

Posted: Tue Apr 29, 2025 8:42 pm
by 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

Re: [2.0.47] Pasting space platform hub cancels enabled requests

Posted: Tue Apr 29, 2025 8:47 pm
by 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.

Re: [2.0.47] Pasting space platform hub cancels enabled requests

Posted: Tue Apr 29, 2025 8:52 pm
by 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"?

Re: [2.0.47] Pasting space platform hub cancels enabled requests

Posted: Tue Apr 29, 2025 9:00 pm
by Hares
Rseding91 wrote: Tue Apr 29, 2025 8:52 pm 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.

Re: [2.0.47] Pasting space platform hub cancels enabled requests

Posted: Tue Apr 29, 2025 9:02 pm
by Hares
Hares wrote: Tue Apr 29, 2025 8:47 pm 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

Re: [2.0.47] Pasting space platform hub cancels enabled requests

Posted: Wed Apr 30, 2025 5:15 am
by 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.

Re: [2.0.47] Pasting space platform hub cancels enabled requests

Posted: Wed Apr 30, 2025 2:38 pm
by 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.

Re: [2.0.47] Pasting space platform hub cancels enabled requests

Posted: Wed Apr 30, 2025 3:12 pm
by Hares
Rseding91 wrote: Wed Apr 30, 2025 2:38 pm 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
04-30-2025, 18-10-04.png (120.94 KiB) Viewed 196 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.

Re: [2.0.47] Pasting space platform hub cancels enabled requests

Posted: Fri May 02, 2025 11:26 pm
by 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.