This bug still has not been patched in the dev branch.
If an if () block has multiple branches as shown below, and the definition of the if () primitive gets edited, or the Blocks all the way setting gets toggled, all of the branches other than the initial one get collapsed.
if <> {
} else if <> {
} @<>
Yes, the conditions and the contents of the affected branches pop out orphaned without being completely erased, but in custom block definitions, this is not the case, so conditions and scripts have to be reconstructed. Nonetheless, whether this is the case or not, I do not think this is intentional that a variadic block refuses to keep its state.
I know, Blocks all the way is an experimental setting, but settings should not damage projects just by merely toggling it. I assert not one other setting damages projects irreversibly (not even Sprite nesting which disabling prevents one from attaching sprites without detaching existing anchors), so this will somehow hook inexperienced users into exploring every setting. Don’t get me started on that editing primitives is not clearly labeled as experimental.
blocks always revert to their defaults when their definitions are edited, this is definitely intentional
i also don’t think the devs are expecting people to turn on Blocks All the Way after they’ve already built scripts, collapsing blocks are all on you
I’m not promising this will be fixed any time soon, but we do want this feature to be usable for teaching purposes, so I wouldn’t want to discourage bug reports about it. But you don’t have to repeat the same bug report; the forum will remember your original one.
This topic is about the actual bug. The other topic is about the bug damaging a Tamagotchi project by da-ultimate-creater. The solution of the other topic was not messing with experimental settings, which to me, never is it a real solution.
So if I edit a set [ V] to [] block, both the inputs would be reset even after they have been placed into the scripting area? That should only be the case for the blocks in palette.
Please, please, do not lead another tautological litany of “just don’t fiddle with the Blocks all the way setting” complaints, reassurances or stories. Also, Blocks all the way is not the only one triggering this, but simply editing the if () block does too.
I am not expanding my if () blocks unless this bug gets squashed and they are stable enough to not succumb to yet another bug. If I make a library that makes use of these blocks no matter how heavy, I want it to still function no matter how much the user tampers with primitives.
This part has completely thrown your bug report off course. Blocks All the Way is not required for the problem you are encountering. In fact, it isn’t even the root cause… at all. As a reader of your bug report, upon reading the above quoted paragraph, I start think that the bug only has to do with Blocks All the Way, and begin to formulate a response about hidden options only meant for developers.
However, I will still now address what you and others said about Blocks All the Way. Options that are hidden in the settings menu are hidden for a reason. This doesn’t necessarily mean they are experimental per se either (and so need to be fixed for deployment); some of them are just for the developers to use in debugging and experimentation (to my understanding). They just simply are not meant for the end user. If Blocks All the Way is the only setting that can “irreversibly” break someone’s project, then that is a bonus, not a requirement. You reference inexperienced users exploring every setting. Firstly, inexperienced users likely would not know about the hidden settings. Secondly, if they do, the first thing they probably try is the top of the list, which is “Blocks All the Way”. So even if they were the type to become overconfident in the safety of the hidden settings, they won’t because they’ll try “Blocks All the Way” first. When I myself was fiddling with those settings for the first time, I did so on an empty project or one with no modifications at all times.
Editing primitives is not experimental. Selecting “Blocks All the Way” from the hidden settings menu is “experimental” (see rant above).
Now on to the rest of the bug report:
Reading this, I thought you were saying that in custom blocks the conditions and scripts don’t just pop out but vanish entirely. However, after some testing, I found that they actually stay in the variadic input which doesn’t collapse.
Here I would like to provide some additional clarification: the if block only collapses when it gets edited for the first time; that is when it makes the transition from primitive to custom, and also when it gets deleted; that is when it makes the transition from custom to primitive. All other modifications do not cause this issue.
In conclusion, I do think that it is a bug, or maybe a misfeature. Most importantly, it has and needs nothing to do with Blocks All the Way (emphasis for those like myself who initially hyperfixate on that part).
this, I think, is supposed to avoid problems with variadic inputs.
look, at this point i am getting more annoyed than trying to explain this “bug”. It feels like:
“I need this issue to be fixed.”
“It isn’t something you should be dealing with.”
“don’t say that again.”
As @mark4sisb said,
It’s not that they will eventually be mainstream features, because if that was the case they would be in dev mode. The reality is, devs have more important things to add - -if they create an undo feature that works, your problems go all away.
It only stays if you keep the Block Editor open. At first glance the script remains, but once you exit the Block Editor without saving and reopen it you will come back to the block being collapsed.