[2.0.28] Signals in constant combinator with description not parametrizable

[Yodo]

Steps to reproduce:
1. Import one of the provided blueprints.
2. Open the blueprint editor and select parameterize.

What happens:

This blueprint only allows the item in the description to be paramerized:

0eNqtk91uwjAMhd/F1wmCQplaiSdBCKWtC9HSJDgpgqG++9zCyn6kSWPctY7P55Pk5AKFadGTthHyC+jS2QD5+gJB76wyfc2qBiGHfiUqG2XpmkJbFR1BJ0DbCk+Qz7qNALRRR41XwPBz3tq2KZC4QfwGEuBdYK2z/UTmyWQ6zSapgDNL54tkkvIsVkZyZlvgXh01y7g3YNnLwtdvnv9hTECtTUT6Xr25CdFZlAXp8pVdHFpl2DXXraOG998PbbyiwWUOq6HQ9oc168SISz5vriSM+DhrPrL26k1RJf+PXIxIwlpbfAYz/cF8mt3liDbKVnx75nHWy/1mjK5riSdvOGlHDukfmZzvHbnWc32tIzarSMoG7yjKAk3cQLfpOKPeqDPStsJQkvbXRN8Ehd5JNJxRDpv0zmCv4RfEa9xzf4cCjhzXQZkuk2yRZWmapMt5Muu6d28pPF8=

Copy blueprint

This blueprint does not allow any parameterization:

0eNqtk91uwjAMhd/F1y2CQjtRiSdBCKWtC9HSJHNcBEN99zllg/1Ik8a4S1yfzyfNyRkq06MnbRnKM+ja2QDl+gxB76wysWZVh1BC/MLKclq7rtJWsSMYEtC2wSOUs2GTAFrWrPECGDenre27Ckkakt9ACXgXROtsnCi8NJtOi0mewEmk80U2yWWWKJmc2Va4VwctMukNWEdZ+LqW+R/GEmi1YaTv1Xc3gZ3FtCJdP4uLl14ZcS1166iT88ehnVc0uixhNRb6+LNmQ3LFZZ8PVxMy3s+aX1l79aqoSf+PXFyRhK22+Ahm/oP5MLvFFW2UbeT2zP2sp9vNGN22KR69kaQdJKR/ZEq+d+R6L/W1ZuxWTMoG74jTCg1vYNgMklFv1Alp22CoSftLooExMERCFMr+9uYSOEg0x668yJaL5TLPs7yYZ7NheAO09zTx

Copy blueprint

I expected items in the description and the signals to be parameterizable at the same time.

[boskid]

Not a bug.

General rule about logistic sections is that if they are named then they are not part of parametrization because they will get their content overriden immediately after placement to match other sections with the same name.

[Yodo]

Yep, I just realized the naming of the logistic sections was causing it. I was also trying to see if the name of the logistic section was parameterizable.

[majik1213]

Not a bug.

General rule about logistic sections is that if they are named then they are not part of parametrization because they will get their content overriden immediately after placement to match other sections with the same name.

Thanks for explaining this. You say parameters would get their content overridden immediately after placement to match other sections with the same name. To me, that means that, assuming you could label sections and maintain parameterization, if you did, by accident, label a section that already existed, no matter what you did, the parameters would be demolished when the game computed your blueprint because the section already exists elsewhere as concrete objects filling those indices. Am I correct in this interpretation of your explanation? If not, the following response does not apply.

If I am, by chance and chance alone, correct in my interpretation, why do that? If a player accidentally creates a new section with the same name, then the game should populate the already existing data and allow the player the opportunity to adjust the section that is already known with parameters. If the player makes a section that never before existed, the parameters should work. If the player later makes a section that accidentally uses the parameterized section previously made, the game should immediately show the parameters to remind them of their mistake so that they can rename the section, before they incorrectly overwrite these parameters with concrete objects.

Wouldn't that be easier and more intuitive? I for one struggle with accepting that I have to make parameterized blueprints without labeling sections, which can organize things a lot better. "InQm" could, for example, denote n inputs at quality level m. I can then spam this section all over the universe to create items that require n ingredients at whatever m quality I want rather than manually setting the parameters again.