Stacker not persisting layers as expected

[dmruczek]

It appears that the stacker is not persisting layer information. Specifically with the level 25 shape (see attached image). This is happening with the 1.2.0 release.

[dmruczek]

When I reloaded my save a couple hours later, the same exact configuration was producing the desired shape.

[EmeraldBlock]

This also happened with a virtual stacker a while back, as can be seen here (not mine): https://cdn.discordapp.com/attachments/728322907629027479/761665734479970324/Screenshot_545.png It later fixed itself for some reason as well.

[Dimava]

This is apparently this bug Since stacker recipe id is saved as stacker:{key1}:{key2} it will be same as long as shapes have same layers, such as A:B+C:D vs A:B:C+D, which gets saved peoducing wrong result

[EmeraldBlock]

A simple way to test it: Quit the game, reload save, and turn on the buttons in either order. Both will output the same result: the shape resulting from the first stack.

[beetree]

To chime in on this around "expected behavior", the right fix here may be more complex.

RuRuRu-- + ------Ru = RuRuRuRu => This makes sense, and is necessary to be able of building everything

Now: RrRrRrRr:RuRuRu-- + ------Ru = RrRrRrRr:RuRuRuRu

One could argue that the "expected" outcome in a case like this is: RrRrRrRr:RuRuRu-- + ------Ru = RrRrRrRr:RuRuRu--:------Ru

With the current behavior, it is very hard (theoretically possible, but in practice "impossible") to create true "anything machines", as handling sparse cases (e.g. Ru--Ru--:--Ru--Ru:Sr------:--CyCy--) requires a logic setup that is very extensive.

[EmeraldBlock]

I find that to be part of the challenge! (And freeplay only has easy shapes anyway.)

About those shapes, notice that stack 2 is the same as stack 1, except with an extra layer as a base. It would make more sense for both to result in the same thing (the layers merge).

[beetree]

I think that's a fair stance to take, but effectively disabling the ability of doing "anything machines" kind of takes the game in a different direction than I was hoping for. As such, it's a consequential decision that should be carefully thought about.

There are other fixes as well, like introducing a toggle to the Stacker that disables "layer collapsing".

And, there are already inconsistencies around the collapsing. For example, the cutter is currently doing collapsing of layers, for example this:

--RuRu--:----Ru--:Ru--RuRu is cut into --Ru----:Ru------, but one could have expected it to fully collapse into RuRu----.

I think the right solution to this cutter layer collapsing would be to allow for the shape --Ru----:--------:Ru------. Either way, having the cutter collapse levels seems problematic.

To ensure the end-game lands well, I really think that thinking through the layering, and what the truly expected behavior is, will prove to be crucial in making this game even greater (e.g. not only best puzzle game of 2020, but best puzzle game possibly ever).

[EmeraldBlock]

I can definitely see how layer collapsing is weird, though I think this quirk allows for cool shapes like the logo and the compass. Personally, I feel the no empty layers mechanic makes sense, since it both makes hard shapes hard and also makes cutters and stackers behave a little more like each other (both making things fall).

[linvogel]

I ran into the same problem. I agree with the no empty layers part, but in the original image, no layer was actually empty, and the requested shape would actually be impossible to build. And as someone already found out, it fixes itself with a restart of the game.

[santa-klaus]

I agree that the behaviour shown in https://github.com/tobspr/shapez.io/issues/806#issuecomment-706370358 is buggy.

About the wider question of layer collapsing and stacker behaviour: for me figuring out how to build the logo and the compass shape was great, and as soon as I got the "no empty layers" rule the behaviour also made size. It might be worth though to introduce users to that rule.

As an option for late game and to facilitate the building of make-everything-machines, unlocking a layer-preserving version of the stacker (or a switched version) as @beetree suggest sounds like a good compromise for me.

[Toastgeraet]

When can we expect the fix to be released in the steam version? Currently i cannot pass Level 26 because of this...

[EmeraldBlock]

The "curse" can be reverted by removing all stackers that use the wrong recipe, then quitting and rejoining.

Or, just rotate the input shapes, and un-rotate the result.

[Toastgeraet]

Thank you my hero.

[forsaken-hero]

The "curse" can be reverted by removing all stackers that use the wrong recipe, then quitting and rejoining.

Or, just rotate the input shapes, and un-rotate the result.

Help!!! I also don't understand how this works. So, empty layers are collapsed, I get this. Then, how to counter this? Why does rotating the input shapes work? How much do I need to rotate them?

[Toastgeraet]

it is just a workaround the bug.

for the last part, where the layers incorrectly collapse:

1. put a 90degree clockwise rotator in front of each input (doesnt need to be directly in front)
2. put a counterclockwise rotator behind the Machine to get the original orientation

i have no explanation as to why this works, because it does not make any sense.

but it works.

On November 19, 2020 7:46:36 AM GMT+01:00, forsaken-hero notifications@github.com wrote:

The "curse" can be reverted by removing all stackers that use the wrong recipe, then quitting and rejoining.

Or, just rotate the input shapes, and un-rotate the result.

Help!!! I also don't understand how this works. So, empty layers are collapsed, I get this. Then, how to counter this? Why does rotating the input shapes work? How much do I need to rotate them?

-- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/tobspr/shapez.io/issues/806#issuecomment-730166531

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

[santa-klaus]

@forsaken-hero Please note that empty layers collapsing is not a bug, but desired behavior. This issue (and the workaround) is about the bug displayed in https://github.com/tobspr/shapez.io/issues/806#issuecomment-706370358, i.e. when layers collapse incorrectly.

[Toastgeraet]

Well yes, without collapsing layers in general, one would not even get this far.

I thought it was clear, that we were talking about the case where they collapse, when they should not.

On November 19, 2020 8:49:45 AM GMT+01:00, santa-klaus notifications@github.com wrote:

@forsaken-hero Please note that empty layers collapsing is not a bug, but desired behavior. This issue (and the workaround) is about the bug displayed in https://github.com/tobspr/shapez.io/issues/806#issuecomment-706370358, i.e. when layers collapse incorrectly.

-- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/tobspr/shapez.io/issues/806#issuecomment-730193882

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

[forsaken-hero]

it is just a workaround the bug. for the last part, where the layers incorrectly collapse: 1. put a 90degree clockwise rotator in front of each input (doesnt need to be directly in front) 2. put a counterclockwise rotator behind the Machine to get the original orientation i have no explanation as to why this works, because it does not make any sense. but it works. … On November 19, 2020 7:46:36 AM GMT+01:00, forsaken-hero @.***> wrote: > The "curse" can be reverted by removing all stackers that use the wrong recipe, then quitting and rejoining. > > Or, just rotate the input shapes, and un-rotate the result. Help!!! I also don't understand how this works. So, empty layers are collapsed, I get this. Then, how to counter this? Why does rotating the input shapes work? How much do I need to rotate them? -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: #806 (comment) -- Sent from my Android device with K-9 Mail. Please excuse my brevity.

Thank you! I will try

Well yes, without collapsing layers in general, one would not even get this far. I thought it was clear, that we were talking about the case where they collapse, when they should not. … On November 19, 2020 8:49:45 AM GMT+01:00, santa-klaus @.***> wrote: @forsaken-hero Please note that empty layers collapsing is not a bug, but desired behavior. This issue (and the workaround) is about the bug displayed in #806 (comment), i.e. when layers collapse incorrectly. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: #806 (comment) -- Sent from my Android device with K-9 Mail. Please excuse my brevity.

I agree. I can see cases where collapsing layer would make sense. For example, if CuCu---- is stacked with ----CuCu, then it makes sense NOT to create ----CuCu:CuCu---- and instead, the put both items in the same layer. And when ----CuCu:CuCu---- is cut, I think it is logically still acceptable to see the layer collapsing and producing the originals CuCu---- and ----CuCu. But then, when we are talking about empty layers in the middle of other layers, one can argue that it is unexpected to see the inside layers to collapse, because visually, the shape has been set. Also, one would expect collapsing of layers only to happen on the outermost layer. I attach an example on the picture here. The second and third cutters produce layer collapse. I am still having difficulty to produce this shape and was trying different ways as trial and error.

In addition, this collapsing of the middle layer(s) might make things difficult because it is logically exhausting to find ways to 'trick' the game not to collapse the layer.

[tobspr]

Should be fixed by now