When snow is placed on top of a snow node it dissapears.
Steps to reproduce:
Expected result:
Option A: stack snow (like the game that shall not be named)
Option B: don't remove snow from inventory (and don't play place sound)
Snow slab is 'buildable_to = true', done to avoid floating nodes placed above. So the placed snow destroys and replaces the existing snow, this happens with many nodes such as plants.
Stacked snow would need snow to be a 'levelled' node, with height determined by param2.
Not destroying snow would need some code to do, and would need to be done for all 'buildable_to' nodes to be consistent. However, 'buildable_to' means that the node is destroyed by a placed node, so it is intentional.
Snow being destroyed when placing a non-snow node is expected, so i'm not sure if this behaviour should change if a 'buildable_to' node is replaced by itself.
A problem with using levelled is that snow is placed during mapgen as a 'dust' node that cannot currently be given a param2 value. Mapgen is meant to be simple in that as many nodes as possible should not need a param2 value being set.
Instead perhaps if snow is placed to snow the node can be converted to a 'levelled' node. But this is a bit messy.
So currently i'm not keen on changing behaviour.
Not destroying snow would need some code to do, and would need to be done for all 'buildable_to' nodes to be consistent.
Are there downsides of preventing the node placement if the target position (node) is the same type (and buildable_to = true); For example: if you place snow on grass the grass is replaced, but if someone places grass on grass, or snow on snow it's ignored.
Sounds like much less work than leveled snow and would be (IMHO) more intuitive than the current behaviour (I think) or am I missing something?
For example: if you place snow on grass the grass is replaced, but if someone places grass on grass, or snow on snow it's ignored.
Yes this would be best, but requires code to be run on every node place and i don't feel it's justified.
Also this should possibly be in 'builtin' in the engine.
Adding this label because a Lua solution (on_rightclick) doesn't seem to be a gentle solution for changing the height of leveled nodes. It would be better to have such an option from the engine directly.
I still don't think this is worth doing. We have many nodes that are buildable to and disappear, snow is just another and is not valuable. Making snow levelled will complicate MTG and looks messy and inconsistent when mapgen doesn't level snow (making mapgen level snow is very non-trivial and unlikely).
Maybe there is some expectation here due to MC, as the request suggests, but that is irrelevant. Still 馃憥
I'm not expecting MC behaviour, but imo it's a bit weird if you place something and it's not (at least it wasn't for me) obvious what just happened.
I think option B from my first comment would feel more intuitive - but maybe that's just me.
Snow doesn't stay light and fluffy when you put stuff on top of it. It gets compacted, so to me it's not all that odd that you lose snow by building on top of it (even if what you build with is just more snow).
I'm not against it changing, but I don't think it should be a big priority if it's not going to have a very simple and clean solution.
Perhaps as you suggest above there is a more general minor issue here that 'buildable to' nodes should perhaps not be replaceable with identical nodes. But then that would be inconsistent behaviour and is an engine issue anyway. So feel free to suggest that in engine.
Most helpful comment
Snow doesn't stay light and fluffy when you put stuff on top of it. It gets compacted, so to me it's not all that odd that you lose snow by building on top of it (even if what you build with is just more snow).
I'm not against it changing, but I don't think it should be a big priority if it's not going to have a very simple and clean solution.