[2.0.24] Blueprint parameter value is not applied to tokens in currently-disabled control behavior settings
Posted: Wed Dec 11, 2024 4:41 pm
by Hares
If you have {0}, {1}, or other tokens in your blueprint and you deploy it with values for these tokens set, ones behind disabled control behavior are not applied.
Token values not set
12-11-2024, 19-20-23.png (155.13 KiB) Viewed 398 times
Token values set
12-11-2024, 19-20-40.png (166.95 KiB) Viewed 398 times
So I was right thinking that behaved diffrently on previous versions...
I still would treat the current behaviour (described in topic) as:
visually annoying
inconsistent
counter-intuitive
potentially-breaking (see below)
I would suggest hiding (or not-parameterizing) only signals that are invisible on current UI, or if a parameter is a parameter template, always render its value despite wherever it is.
Why so?
Imagine you have a train stop template. You are selecting item type in the pop-up, and deploy it. The train stop is currently configured:
Name: "{0} Load"
Enabled condition: Active; {0} > 0
Train limit (static): Active; 1
Train limit (dynamic): Disabled; {0}
Priority (static): Disabled
Priority (dynamic): Active; {0}
12-11-2024, 22-17-17.png (50.99 KiB) Viewed 341 times
12-11-2024, 22-17-31.png (36.84 KiB) Viewed 341 times
After deploying a train stop, you can check one box to enable dynamic train limit (because this one is located far enough so restricting it with one approaching train will reduce throughput significantly. And that how it worked on 2.0.23. However, on 2.0.24, after deploying, for example, it with {0}="iron ore" you end up with:
Name: "<iron ore> Load"
Enabled condition: Active; iron ore > 0
Train limit (static): Active; 1
Train limit (dynamic): Disabled; "{0}"
Priority (static): Disabled
Priority (dynamic): Active; iron ore
12-11-2024, 22-17-43.png (40.56 KiB) Viewed 341 times
So the use-case I described above is no longer working. Yes, you could argue that you can instead use any other static signal, like N, or L, but that only masks the problem, and does not solve it.
Re: [2.0.24] Blueprint parameter value is not applied to tokens in currently-disabled control behavior settings
Posted: Wed Dec 11, 2024 8:26 pm
by boskid
It is working as intended to avoid noise on the parametrisation gui with unrelated signals. I will not be adding any weird exceptions based on visibility in the gui to have "not collect, not apply" (for not visible signals), "not collect but apply" (for disabled but visible), "collect and apply even if disabled" or "collect and apply when parameter but do not collect nor apply when not a parameter". There are no bugs in this report so there is nothing to fix, if you want to suggest some changes, there is ideas and suggestions subforum.