[Kovarex] [2.0.9] Blueprint parameters with same value are collapsed to one (MR)

[Inercia]

The problem

I created a blueprint with one constant combinator which outputs A with a value of 4, and B, also with a value of 4.

10-23-2024, 19-14-50.png (20.82 KiB) Viewed 622 times

I want to parameterize the blueprint in the following way:

• Signal A always has a value of 4.
• Signal B it's a parameter that has a default value of 4, meaning it can change when stamping down the blueprint.

When I try to parameterize the values, I only see one '4', related to BOTH signals, so I can't vary one without varying the other.

10-23-2024, 19-18-53.png (22.28 KiB) Viewed 622 times

I EXPECTED the values to be signal based, which it isn't.

Also tried

• Setting B to be 1000.
• Setting B to be a parameter and changing the value 1000 to 4 on the blueprint parametrisation screen.

It also didn't worked, it had the same effect as setting them both as 4 on the constant combinator.

10-23-2024, 19-24-17.png (20.91 KiB) Viewed 622 times

10-23-2024, 19-25-36.png (25.87 KiB) Viewed 622 times

[nova4x]

I also agree this should be remedied, it's not very intuitive to need to change two instance of 4 to separate numbers before blueprinting. A possible idea would be to allow players to select values that are the same (or even different since it would be intentional) to consolidate into a single value. You should also be able to split values are any time.

[DragonMech]

[2.0.10]Variation on the same bug/more details

To some extent I believe this is working as expected (more of an improvement request than a bug report), and it makes some more sense for the Signal Types to be combined (Eg changing an iron ore station with circuit stuff to be able to set the item, every instance of "iron ore" should be changed) but it makes less sense for the numbers. I agree with nova4x that it should preferably not consolidate the numbers initially but have the option to consolidate and split the parameters (signals too) at any time.

Where I feel this truly becomes a bug, rather than just a poorly designed feature, is that I thought I had found a way around this. I set all instances of numbers to different values, then when editing them as parameters changed the value to be the same (as a default). It appeared to work, the blueprint saved and even prompted for the different parameter numbers, but apparently they were consolidated in the background, despite what was displayed. In detail:

1 - plain blueprint

Working (blueprint of constant combinator with 3 signals set, values 1,2,3):

Screenshot 2024-10-25 180305.png (100.27 KiB) Viewed 549 times

0eNqVUdtOwzAM/Rc/Z1Mva6dG4kvQNKWdgUiJU5J0MFX5d5wAY/CANOXFOfY5x5cVRrPg7DVFkCvoyVEA+bhC0M+kTMZIWQQJORMVxc3k7KhJRechCdB0wneQdToIQIo6avwUKJ/LkRY7oucC8Z+QgNkF5jrKjqy36apq2wm4cNhW9bZjKyZG78xxxBd11szi0oBTZoXfMdt/9yXgSZuI/i/61cybcyd2f12U4W4ZIOctz53d7Kx86U7CQwGWvKQ6iatOczNUId2h09zotFedEB3hfUJtOvBL+QA6ouXkz0kFGDUinxFqjs+8hrLirm+G3TB0u2rf9/s2pQ8fEqsm

Copy blueprint

2 Values changed to be parameters

Screenshot 2024-10-25 180631.png (116.6 KiB) Viewed 549 times

Placing blueprint, prompt to change or use default values:

Screenshot 2024-10-25 180710.png (23.25 KiB) Viewed 549 times

Changed the values:

Screenshot 2024-10-25 180857.png (21.46 KiB) Viewed 549 times

Applied as expected:

Screenshot 2024-10-25 181011.png (90.09 KiB) Viewed 549 times

0eNqVUktvgzAM/i8+pxWPQlWknfYTdthhqqpAvS1SHiyEbgjlv89mLXSTVqni4jjfyzEj1LrH1isboBpBNc52UL2M0Kk3KzX3rDQIFfBNkDasGmdqZWVwHqIAZY/4BVUa9wLQBhUU/ghMh+Fge1OjJ4C4JSSgdR1xnWVH0lsVSbIuBAxU5km6LsiKiME7fajxXZ4UsQjaYcOs7ndN9pdcAl6VDuj/ds9hPp07kvtHLzWlpYZ13tDc7GZa6ad0FTxMjZ4fKY1i1smuhppId+hkVzr5rNMFZ/E+oTzu6Yu8AL43OE8bhpY1zysQl6KCFGbDRw7OUf4FZwv4aUp3E50v6Gd+W46lAho6L3+aAC1r1GfxE+WdNl+U2W6z2xWbZFuW2zzGb0LX2u0=

Copy blueprint

3 - changed so each parameter is set to value of 1

Appears to bet set:

Screenshot 2024-10-25 181401.png (114.08 KiB) Viewed 549 times

Prompt to change or use default values (as previously) but appear to have same default value:

Screenshot 2024-10-25 181514.png (19.43 KiB) Viewed 549 times

Changed values appear to be accepted:

Screenshot 2024-10-25 181645.png (19.91 KiB) Viewed 549 times

Values as applied, the parameter last in the list (Wood) is applied to each when the selected values are expected:

Screenshot 2024-10-25 181734.png (90.75 KiB) Viewed 549 times

0eNqdUktPwzAM/i8+Z1O7rp0aiRM/gQMHNE1pZyBSHiVJB1XV/45dtvI4oIFycWx/D8cZoTE9dkG7BHIE3XoXQT6MEPWTU4ZzTlkECVxJyqVV622jnUo+wCRAuyO+gcynvQB0SSeNHwTzZTi43jYYqEH8RiSg85Gw3rEi8a3KLFuXAgYKiyxflyRFwBS8OTT4rE6aUNQasWVU/B6T/MWXgEdtEoaf2bOZV++PpP7SK0NuKeF8sDQ3q9lOhdmdhJs50fMj5ZNYeDZfhppB/+QpFp6YvMO/Eu3pTLwArltcpk1Dx5znFYhLICGHRfCWjbOVa5rvZnfXdt/z27ItndDS/fOnCTCqQfpdUFB8Ir/z5stqU2/rutxmu6raFdP0Dj8G2ug=

Copy blueprint

4 - Attempt to fix the blueprint

Attempt to change values to be different again though hovering over the “Coal” parameter now shows it is used for all items and nothing shows if hovering over other values

Screenshot 2024-10-25 182309.png (142.97 KiB) Viewed 549 times

Confirming the changes, then opening the parametrise window now shows that only the “Coal” parameter remains and when used it is applied to the others as would be expected at this point. At least the blueprint is now in a form that works as expected.

0eNqdUttuwyAM/Rc/0yptLlWQ9rTPmKqKpN6GBCYD0i2K+PeZrM0uD5M28WJsn4sxM3RmxMFriiBn0L2jAPJhhqCfSJmcI2URJORKVBQ3vbOdJhWdhyRA0xnfQO7SUQBS1FHjB8FymU402g49N4jfiAQMLjDWUVZkvk1dFNtawMRhWey2NUsxMHpnTh0+q4tmFLcG7DMqfI9Z/uZLwKM2Ef3P7NXMq3NnVn8ZlWG3nCDnLc+d1eyg/OJOwt2SGPMjVUmsPPsvQy2gf/KUK0+IjvCvREc+KS8g1y2u08ZpyJzXFYhbIKGCVfA+G89YHdHy/fM7CDCqQ3NtvzDpsp662bdV29ZVcWiaQ5nSOwj+voM=

Copy blueprint
(had a couple more screenshots but it appears to be limited to 10)

[kovarex]

Hello.
This was a design choise, and I prefer it to stay this way.
The id parameters are also all merged into one place for a good reason, to be able to change them all at once.
With numbers, it would get all clunky and complicated having to somehow identify where the number came from and work with it separately, especially when you would have to have a tools to merge and unmerge them (as sometimes you want them merged).

For that reason, I would leave it as it is, and if you want to differentiate the numbers in the parametrised blueprints, you just have to give separate numbers, which is always possible.

[Skjolbir]

For that reason, I would leave it as it is, and if you want to differentiate the numbers in the parametrised blueprints, you just have to give separate numbers, which is always possible.

I disagree. I have just tried to create a blueprint for a train station where the user is asked upon placement if they wish for the station to fill a train either fully, or a custom amount. For a full cargo, I advise leaving the value as 0, which is what I want the default number to be. I then use some decider and arithmetic combinators to use the full capacity of a train, or the custom request to decide when to send the train a signal to tell it to depart.
One of these combinators checks if the custom request signal is 0 or not with "Q > 0" as a condition.
Now, I am forced to default the custom request amount to some other value than 0, because if the user does happen to set a custom request amount, then it will break this combinator.

0eNrNXFtv2zgW/iuCnnZm5Yx4lwJ0gZ22wPZhZ9tJsDvTJjBkm0mE2pJHkjNrFPnvS0q2pbiUTR623aIPYSjqO4ff4bmQYvopnC03cl3lRRNefgrzeVnU4eWHT2Gd3xfZUvcV2UqGl2GV5cvwKQrzYiH/G16ip8gw6C6rm0lTZUW9LqtmMpPLZvAOfrqNQlk0eZPLTkr7y3ZabFYzWSnQaA9UK5D8/qGZtGKjcF3W6q2y0LIU0gSTKNyqF2LypBU5wsEHnKzKm4eVbPL5ZF6uZnmRNWVlwksu2A6RKYUVDU1VLqcz+ZA95uoNNayHmqrHi/b1Wj+4y6u6mfZcNNu1Fv2YV80m08rv59SOmFxpRmqpMTRQ3WSaexZHYbmWVdZpFf5VvVdumvXGAfnX8EmxEa6X2VZW04Ws51W+3uHVsqmD5kEGq7zIV5tVoGxeqhltg6YMWHwRXAV5N+DwoEPVz2cyuM8fZaHbeojSWcNehAbuiTv36Tfj/qWRexIfkf8TgPyrE+Q3m6qog3s1PlBT+FgHf3n5g+ay00T9evWDiUrq7g7M5A7sgLOf82mDkPhgEH4xZhKl+8EKfVv59D5ARMo4y0ZWx71nTRSFf6gHagKqsyirVTtIKbzOqlbhy/BF27HRtkNPt+rfGPG/SLmQC021Xr9BVgRq9Te5XtXKDvvl3EIpogzU8YN6CznPF7KyDiNihLcdztE6Hv72wXlZ/zt8OmLob6GOtd0aPg7oZ8CuO7D1dtryMr2rytU0LxRQeHmXLWt5gu//PKggUUkVbILDjIIXQVNtZBR02gTXUUt6N2qnlYF54ch8+n9h/voz5l/AmVfR6QS31/sAPWTuImgpL8pnvXrkuiofc734Xwbzdt3PK7lSHF+ojh1Q6wO7xR/tPWO57V+dbXf+0UWNoLeAMfQnhwnN8vuJXKqoUKngvy6X0mSxQ4wxxazU0fx8b/w2YC3yqgtJqgt/r6th9+6yVG+UjYpPnfkNZKDYPRMIIxACe1X6Jb1qp0NelcVELfZGDvKyNdtvv2TUmz/I+UebyGdi1aveTGE1T1++IHfqXumZDiueCaDiea0rHhMdfQm4kot8szofCsSBDcWLEZO6U8wHkFYh4UtVmdfGKhM9Z/xHE+OmkGCkgwHDY/p9hUe/MmXMHbl7tEyNQMJjL4PQV97LvIfEzNfHjv8jwPHfjq3KxCMOfnW+3kH4evVV+XItcsRZsr6G2777km77CphjcQxOACj+1gngDWSpvT9eaj/5ZAiM4Hyhb83Xz0a+jEWib9Hy5sQxzZtJ3shVsJB3+TxvTDscjB2PUjDtXfZ7P0pJ9IT3R7XR+fMuJ3A6RCfR+ezueArUg9Po/HJzAicJjeOBAHZWwG+O3AzA+Vnw3x3Bh6qL6HwUciOex8+4SaLz2cRJQHzyfO/lpPPMoLwL1A6ubuqb4mpSL8umDlSg6PpuCo28ijvvruQfG9UpFzfF9WS+qZtyFegqsQiW+SpXg3+eNGWTLYPZ5u5OQ2TrTEWD7U3x20DYn9m9ctKgLLp3b4rfd1IVTtY9vSneTzrgHuLdXuJOiyBbtdM0hRr3XVQfa2LzLgq7nyirSsME1O8/2ilO1KTWJhR0pl6pZKZCvnp5LRfTFiq8bE8LO9zDI7ej0Fo2HVg9bY36DHPXdzqndhj7TyH79/e/u32SUVjNPmX9+vqXv//zdXD9jzdXwdX1v94aLd/vX0zf007WheQ4dScmAQIuAFsJSFwF8HEBCJskpHAJVhyR2FUAc5wCQa4SqKsEDJdAzBGEEDgtxE5pQIwyfgQmDL7KqdUS4fA1aCfgyE83KsdW95XKGAsLEewzEYfc3O23TBITd4nCT+KRI9drVRnoj3HjHwxa8kyfSz1clo1AInc+6BEfOwa6jYrxMy92X/FmbT2ck48QQOEhhFv5O2VwCWJEae5uNfYM1MZqwt1qxm8yNPEo9NIRBlI4qSMn8MzDuz47gacmAe63f5Dx2Jb1/jTbLD9OVMknq5GQcpg2RlY6Egh0bAU9zHtStl+k6tO84pEynzF3KDQC5X6Wjo07BuaTyzAezyzjHsoSH5EEkMxY6pE+QRJ57CMRRCtH9j7AnokygcFLVDxSonLikbN3lJylnXpkmJ2hz8pg7q5nLIQ5h3M8UmpxAYccKbV4As4vmNkEWJ4651l2jgfhfjEDm4FATsVtdhEClA6FVfEmiHumGSnaBPVxW25XtAmATxmLNsEhpCZ2pArIWhipBEXiQ2tqFalE6r4KRqrMBOBQxiIwQR7Jn8SQxJhgH5EIkP0T4pH9YRKpj0QYrfANIhkpkBMOzjXEqphPBDzXkJFSPEmcXYMYS/EEvjkkVse/KXyr+LkAE70pJFsSq3PfFHvESwIp4VPibldjnZdSQE4izConpQyCTe2wuXP6ICNFZCrcoUZKuxTgbmYgD3cTNksWxR7+Jmz8DcU+56CEQ8I+ijHEyUfOMVEM8DLzFeqY+qT5BMYF80m7QJncR2YKiIQo9jkkAopM4N6Z2nmnh/8nVhIGfx7gXm2MXbhGyOOIA2YL5P4hhJgv7iLIOS1FVukKIfeTWorGWGaAIEdju2XBPYI2jUEWdP8oQpGZmARiQWxpwRT+yYWOHDuiwQ1VB1OOoiH3RYbHsNz9ihIzks+GkzJQHsI++RYqk4ErKkqtKioMP5SlVpcHEIaf0RpYM0pIPFIE1DKp+1o2e4X7DZ9+VdnV5e43fHoJ3E4CBt9xsZ0DgUuwnAP8igG1u2KAiIc7W9IEP1GypUn4ZHMBcjbivgem5k0TSeHLyK7MPr79c+oikdgh25XXFH5Rz1Z3bK87d0MmzterbFlxv6dHzcW6+w2gQ5hkyE5X+I1aZnUvBFH4lVpmV81Tn9sMDFTNu98iYo6Gcb9URMclmGM/g3uvpWUY9iiDYJZh7qdZzLzPYhTufMTSAvCLuIzYWQBeTNtKEHBXIFYR5Pi2kkUOYNhOd/eSmZm3fzyGW9Ju08KRcxZndpsV7vN11qC9Tf3ECXxdWvJFnfO7LV/MJ6oB+XK/bcjMmzv3C0q9re3qcff7SsJVAvzg2FKCgH84spXgfqmXmXcQwv0Qi6l68zYK/1Q66r+c/YAjHJGI3kaqRSPlD1g1ieoUbSdrW/jQ0n1ctXYDuXqne5xELEIkYqqZ6udxO7Rt4nZA2sMjpLoRHrQ74K6d7Nv9eK0kSrt+rSbqZGp5Ee6EIqrHsG4MHbzLehX0a4M2PchKBvjJYMxAfTUh1UAdU/GgHx21VfHQtrVuqj7VuukfkVq5uq0fR6zTjbWcko5J9ThKRDtGtPynbb/+EaU7joUmGcUdy7x/0Lb1GXzHaNwO6+Shjhit2q2yu/5zT30Ye/gPLqPwUVZ1u1AYxylNU0ZxLATlT0//A0MDMLU=

Copy blueprint

This is one example where I could probably work around the issue, but as far as I can think, any blueprint where there are signal values which absolutely must remain static for the function of a larger circuit, which happen to be the same value that you want to provide to the user as a default value upon blueprint placement, will have issues.
Of course, I could set the default values to something very unique to avoid this question, such as using 10001 instead of 0 in the above example, but this means the user will have to change the value to 0 themselves probably very often, and will likely need some instruction to the user so they know that 10001 is just a dummy number, and actually they should be setting it to 0 for a specific type of behaviour.

If there was some way to tell a signal value to instead of being 0, be NULL, and then in the parameterisation menu, all NULL values remain separate and offer us a default value to offer the blueprint user without messing with other values that are the same number, that would be great.

[Skjolbir]

Okay, I found a work-around.
For the values that you NEED to remain static, set their value to something very unique, in this case 1000, 1001, then in the formula, write in what they actually should be. They will be initialised to the formula value no matter what.
So in this example, I want signal A to always be 0, signal B to always be 1, and signal C to present the user with the default value of 1, but if they change it to something else, then signal B should stay at value 1.

While I am happy this workaround exists, its a massive hassle, more so than I think not having values be bundled together would be sir Kovarex. I imagine this is BP behaviour a lot of blueprint designers would like to create, but this workaround is not intuitive as all, as you have to set values in circuitry to non-intuitive numbers like 1001, and then change them in the formula to 1 in the parameterisation menu. Esoteric workarounds that require a lot of hassle and effort are not good in my opinion.

10-28-2024, 21-03-20.png (1.82 MiB) Viewed 373 times

[Inercia]

This design choice makes default values impossible, it's limiting. Many players will (or did) try to implement it, only to realize it's impossible, and become frustrated of a feature that is, otherwise, awesome.

I love the circuit network because it's about building something complex out of simple units. When something is "not possible", or you know that you just have to throw more combinators at the problem, or you expected it to be impossible.

In contrast, we have blueprint parametrisation, this complex and powerful tool that you EXPECT will cover all the base use cases, but it then falls short.

[Skjolbir]

This design choice makes default values impossible

Please see the comment literally right above yours where I show it is not impossible, just unintuitive and a bit of a pain to set up. I still wish kovarex would let us break up combined values if we wish, but its not impossible. I can see his point though, being able to tie values together is a valuable tool. I simply think being able to split them up is also just as valuable.

[Inercia]

As far as I know, the method you presented breaks if you want a fourth parameter (D), also with a default value of 1. That's why I still consider "default values" something impossible.
I found this workaround a while ago and didn't manage to get it working with an arbitrary amount of parameters with the same default value.

[pindab0ter]

The workaround I use is to set unique arbitrary numbers in the value field to make sure they don’t collapse. I then set the actual desired value in the formula field.

I do think this should not be necessary, though.

[Loewchen]

If you want to discuss this further open a gameplay help topic or make a feature request please.