[2.0.15] Logistic groups do not function properly in parameterized blueprints when the logistic group is named

[Novalith]

What happened and in what context: Logistic groups do not function properly in parameterized blueprints when the logistic group is named.

Describe the problem by answering these questions.
What did you do? - Created a parameterized blueprint using parameters on a requester chest to set these parameters to be ingredients of the produced item.
What happened? - It works fine when you do not name the group, but when you add a logistic group name the parameterization settings no longer detect the parameters in the group name.
What did you expect to happen instead? I expected it to let me create a group name with parameters in it and then allow me to set those parameters in the blueprint. This way I could set a 5x multiplier on the logistics group to request more ingredients than the default "read ingredients" response.
Does it happen always, once, or sometimes? I can consistently reproduce this.

*Note* I have several workarounds, but this works in what seems like an unintuitive way.

Here it is working with "no group assigned."

Screenshot 2024-11-06 100125.png (528.05 KiB) Viewed 452 times

Here are the parameters in a named group and an unnamed group.

Screenshot 2024-11-06 100530.png (560.23 KiB) Viewed 452 times

Here is me trying to set the parameters. Note that only 4,5,6 shows which was in the unnamed group.

Screenshot 2024-11-06 100618.png (273.65 KiB) Viewed 452 times

[atomizer]

Named logistic groups belong to the save, not to blueprints. A named group inside a blueprinted entity is only a reference to the group as a whole, so there is nothing to parametrize.

[Novalith]

Fair enough when you explain it that way. However I don't know that it is intuitive in it's function. Perhaps the current contents of that named group could be copied to the blueprint on view or use and that would circumvent the problem.

[Intangir_V]

We still need to be able to use/refer to these like global variables, even if its only in the formula somehow

i want to define a number of train cars 'globally' in a named section which is shared map wide, and reference that number in formulas even if we cant change them in the blueprint parameters

[atomizer]

You can reference groups from constant combinators.
None of this is a bug, feel free to make a thread in the ideas board if you think the current functionality is insufficient.

[Intangir_V]

you can't reference constant combinator signals in a train interrupt formula though

it might not be a bug i guess its more of a limitation, a gap in the feature

[robot256]

you can't reference constant combinator signals in a train interrupt formula though

it might not be a bug i guess its more of a limitation, a gap in the feature

Then have the train interrupt reference a circuit signal fed to the train stop by a combinator with the group you want?

After the blueprint is placed, the train interrupt condition can't read the logistic group to update when it changes, so I don't see the value of having it copy the value in the group just when you place it (or when you create the blueprint).

[boskid]

Thanks for the report. Logistic sections were intentionally made to ignore named sections since their placement would be annoying: by placing one blueprint, would you expect the logistic section to ignore parameters and borrow settings from map or apply parameters and propagate to other existing sections on the map wherever they are under the same name?

[Novalith]

That's a good question. I would think that the variables would be copied to the blueprinted object once they are selected and it is placed. So to summarize if I make a logistics section with 4 parameters, when I place a blueprint containing it copies my answers to the object it self under the unnamed section. I hope I communicated that well.

[Intangir_V]

I think interrupts and logistic groups and group train definitions should OVERRIDE existing ones when there is a same name siutation, so blueprints can be upgraded more easily

otherwise we have to add a version string to all of those things, which is doable, so there is a workaround either way