[2.0.24] Blueprint parameter value is not applied to tokens in currently-disabled control behavior settings

[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 356 times

Token values set

12-11-2024, 19-20-40.png (166.95 KiB) Viewed 356 times

Click to expand the recording

Blueprint:

0eNrtV9tuozAQ/RXkx5VJwSFXbR92f2G1TylCDpjEKtisbdJGEf++YyCUpjRt0+0+VJUSxdjjMzNnzjj4gNZZyQrFhUHLA0qYjhUvDJcCLdHWmEIvr65Sqcpcj1IaG6m4HMUyv/JJQMaTG3EjfqSGKSdhRSb3XGwcs+XaueNm6ygW84Jdr9rfW7mjit27TCgeb3MmjFsoGTOtQ+wwQdcZS5xYioRb/442PMucLdXOihuWXxdU0ZyBL9cPwZ0uYNZZM+tSMS2zHew2sjUuFRW8zF2IMRzdCIQRB2SNlqsD0nwjaGbTFQAIecYQiuJpuWGoAkORsHu09CvcNzX7wpo2qQBcu/X5nHpQpAoxgiXIizUh1A/7SJT5minwhQdCwaiQmjelOCCAcf3FbDTBaA/DYDwdTcBDwiGixsYnGEGORsksWrMt3XGp7M6Yq7jkJuqYtZMpV9pET5jocWzjt5QZaqURePYpt+vGwqLv7boA95GRUSY3HCoWR4KZO6lu0dKokmHUzb/LPfG8wQAUo4lFNkCbblzWs3WR+ngeOk5Hf0qaAfmwLKTKwT/UCSTTFIYn/XCUTEpgdwfmbg7jjLkEzB8QFBS/LnQDAPtFxMUOopFq3wA+PAUYQToxUONZbQ2u+FVYwQc/kQjpJLIus1uXC80UJDaokvmDSoJaJSnPwLbNsJU3HiK9n1vHziPar9FgeOMOLqXanA9vdhpeT8TzAezgDalPz2Gf74/2BDoK9/O2TTXA8eQyeZGa4y9Wn2F12mM1TQEp3jJtXiJ1XJOq2J8SjKOud+HfqFHyaR//0+62E+WR5JzeR+3j3IO+h78xo6jeRkKaqA3wWNuh/GeXnQpWVQNo8w7t6PocobMPJ5S8jVC/ZnAoscVlBxwZOOA+/qT3vdeLevoZRe1f8rbmndYq+HpZ+ywvayCgOyisjWnlY4IDTEK8msAIpEJCWO5Sa+Ju7xIQfqekXyyD2jjHYHGd2wkl7aL7qDiv6GIbf9/lCbT/Dmh7xdkolnB78ZHpScgvOCb/w3Hbtfg4WKLAcglX2rzMqN3nRdxSABdYBueMFXCjzDMQVuG92hlZONSc9zof8Op8c8gbPftPYcgzMGGjdHtOd1d8aHG6ZtDF6Ge5cZs7/NL5LWhRZBzuzx2JYLkDudYFmUzJIlgsJvAN/LlfVX8BPZh7uA==

Copy blueprint

[boskid]

You are absolutely right. Works as intended.

-- edit:

Related 123321

[Hares]

You are absolutely right. Works as intended.

-- edit:

Related 123321

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 299 times

12-11-2024, 22-17-31.png (36.84 KiB) Viewed 299 times

0eNqdVE1v2zAM/SuCjoOcDzfuFgPbYdhxt22ntjAUm00I2JIg0d2CIP99pJM4QWegQw0YtiTy8enxSQe9aXsIER3p8qAbSHXEQOidLvWOKKRyPn/2se/S7NnW5CP6We27+TJf5XfFo3t03yC0fo9uq2iHSTUeknKeVATXQFQULTrVYoekau8o+lYl3DrbzrTRyFNJlw8HfZoTEs52wNWHxCyRD/rIgQz2R5fLo5kIDTbyD0HMFjex+fHJaHCEhHCqMQz2leu7DUQGMxeAJMW2O8r40zKt4BOeRDhoRsry+zuj95zxsTgKg1dAuZkgPYWyHFGMPotRbWBnX9BHiaox1j1SBc5uWmh0SbEHM05zSjMiPmNMVL2lhehLVrq7kEEnyyTF9BdZHvhWwjdAcwNG+yBgLxipt6LIRaghIvspuQmoYuewJWh/YXoZv8FLssmebfaABN3nm/Un9d3bhot21nH1aiCZqsFDZwu8asDdOzr5caqTq3cAraeAihHIsh473hnWGeu/QTfoP+mOWTFCTvvjinX1Qvp/MySQrOrqiXyxYFv4APHSjDkz8z2F/i00fvh4/cY4nK2H3OSmMKsnnhvDTofubCVsri76AS3UpKTvcgc0/zAds85ymstPqYUyj/lO6vrWSuaiSuqDWslsA0FuHdma+FEYDkXKm2vO6NZugPelv/bb7HSPleqXsyG0CI26oW/0C38GYYr7fL1arwt+V8tPy+PxL6UzxNI=

Copy blueprint

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 299 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.

[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.