Piston-breakable nodes don't fill up the push limit, items properly drop #3813

seventeenthShulker · 2023-06-20T17:30:23+02:00

2023-06-20 17:30:23 +02:00

Scenario 1

Details (outdated)

By keeping track of nodes with dig_by_piston separately from those which don't, mesecon.mvps_get_stack does not add piston-breakable nodes to the counter that stops anything over 12 blocks from moving. This way, Scenario 1 becomes possible (a piston moving 8 slime blocks into 8 sugar canes), as it is in Minecraft. The function still aborts when it reaches more than 12 'regular' solid nodes, since if nothing is going to move, nothing will break.

There are some minetest-side issues with dig_node, since it expects a player. The handle_node_drops wrapper was a good fit for this problem, and simulates the drops unless the block is not in the dig_by_piston group.

I also noticed that only one bamboo node (bamboo) could be piston-broken, and NOT bamboo_1, bamboo_2 or bamboo_3. This is because they were not added to the dig_by_piston group like the original node.

I reckon there are performance tweaks that could be made, although I do not notice any difference on my machine.

Testing

Probably needs quite a bit of testing to make absolutely sure there is no duplication.

All nodes with dig_by_piston properly work
Protected nodes cannot be moved by other players' pistons
Protected nodes cannot be replaced by other players' pistons (including air)
No noticeable performance hit

P.S.

Empty shulker boxes only drop in Survival Mode. This seems to be because they do not drop anything in Creative Mode.

### Scenario 1 ![8 slime blocks cannot be pushed into destructible sugar cane nodes, as the game thinks I am trying to move 16 nodes, the limit is 12.](/attachments/dea755d2-e801-437a-a489-bd2852114d83) ### Details (outdated) By keeping track of nodes with `dig_by_piston` separately from those which don't, `mesecon.mvps_get_stack` does not add piston-breakable nodes to the counter that stops anything over 12 blocks from moving. This way, Scenario 1 becomes possible (a piston moving 8 slime blocks into 8 sugar canes), as it is in Minecraft. The function still aborts when it reaches more than 12 'regular' solid nodes, since if nothing is going to move, nothing will break. There are some minetest-side issues with `dig_node`, since it expects a player. The `handle_node_drops` wrapper was a good fit for this problem, and simulates the drops unless the block is not in the `dig_by_piston` group. I also noticed that only one bamboo node (`bamboo`) could be piston-broken, and NOT `bamboo_1`, `bamboo_2` or `bamboo_3`. This is because they were not added to the `dig_by_piston` group like the original node. I reckon there are performance tweaks that could be made, although I do not notice any difference on my machine. ### Testing Probably needs quite a bit of testing to make absolutely sure there is no duplication. - [x] All nodes with `dig_by_piston` properly work - [x] Protected nodes cannot be moved by other players' pistons - [x] Protected nodes cannot be replaced by other players' pistons (including air) - [x] No noticeable performance hit ### P.S. Empty shulker boxes only drop in Survival Mode. This seems to be because they do not drop anything in Creative Mode.

image.png

949 KiB

seventeenthShulker commented

2023-06-20 17:48:14 +02:00

Whoops it didn't rebase..

seventeenthShulker force-pushed piston_digs_properly from e781bf7c31 to 42714bbbe1

2023-06-22 13:50:30 +02:00

Compare

chmodsayshello added the

nodes

redstone

labels 2023-06-27 11:49:45 +02:00

seventeenthShulker force-pushed piston_digs_properly from 42714bbbe1 to cdc1544aff

2023-06-30 18:17:00 +02:00

Compare

seventeenthShulker closed this pull request

2023-06-30 18:21:20 +02:00

seventeenthShulker reopened this pull request

2023-06-30 18:21:28 +02:00

seventeenthShulker commented

2023-07-01 20:18:19 +02:00

Found issues:

Sifting through all nodes in the dig_by_piston group, I discovered some nodes used to drop double, but only when in direct contact with the piston pushing them.

Cactus (difficult to test, since they break when solid nodes are next to them)
Ladder
Cobweb
Dragon Egg (why isn't this in the Creative inventory?)
Chorus Flower (also, pushing the stem does not update the rest of the plant)
Melon, Pumpkin, Carved Pumpkin and Jack o' Lantern
Mob Head
Waterlogged Mangrove Roots (these shouldn't be broken when pushed)
Signs
Buttons
Pressure Plate
Lever

Duplication was because of the mesecon.mergetable function from mesecons/utils outputting a table of length 2, when the inputs were of length 0 and 1 respectively. This is because if the dest table is shorter than the source table, some entries in source appear duplicated in the output. This was causing two calls to the bit that drops stuff, for the same node.

I don't know what other effects changing the original function will have, or if there is a reason for this weirdness, so I added an mesecon.join_table function to utils, which properly combines the two inputs. Another approach would have been to verify that #dest >= #source, but I didn't want to rely on mergetable as it is now.

Additionally:

Double tall flowers ~~do not drop anything, as they are~~ were set as buildable_to unlike regular flowers. Looking at https://minecraft.fandom.com/wiki/Tag#Blocks, under replaceable, double tall flowers are not listed. ~~This should be changed, unless they are still replaceable in Minecraft despite not being in the tag.~~
Weeping and Twisting Vines are not supposed to be buildable_to; removing this allows pistons to drop items when broken, but messes up the vertical placement logic. So I am leaving them alone.

### Found issues: Sifting through all nodes in the `dig_by_piston` group, I discovered some nodes __used to__ drop double, but only when in direct contact with the piston pushing them. - [x] Cactus (difficult to test, since they break when solid nodes are next to them) - [x] Ladder - [x] Cobweb - [x] Dragon Egg (why isn't this in the Creative inventory?) - [x] Chorus Flower (also, pushing the stem does not update the rest of the plant) - [x] Melon, Pumpkin, Carved Pumpkin and Jack o' Lantern - [x] Mob Head - [x] Waterlogged Mangrove Roots (these shouldn't be broken when pushed) - [x] Signs - [x] Buttons - [x] Pressure Plate - [x] Lever Duplication was because of the `mesecon.mergetable` function from mesecons/utils outputting a table of length 2, when the inputs were of length 0 and 1 respectively. This is because if the `dest` table is shorter than the `source` table, some entries in `source` appear duplicated in the output. This was causing two calls to the bit that drops stuff, for the same node. I don't know what other effects changing the original function will have, or if there is a reason for this weirdness, so I added an `mesecon.join_table` function to utils, which properly combines the two inputs. Another approach would have been to verify that `#dest` >= `#source`, but I didn't want to rely on `mergetable` as it is now. Additionally: * Double tall flowers ~~do not drop anything, as they are~~ __were__ set as `buildable_to` unlike regular flowers. Looking at https://minecraft.fandom.com/wiki/Tag#Blocks, under `replaceable`, double tall flowers are not listed. ~~This should be changed, _unless_ they are still replaceable in Minecraft despite not being in the tag.~~ * Weeping and Twisting Vines are not supposed to be `buildable_to`; removing this allows pistons to drop items when broken, _but_ messes up the vertical placement logic. So I am leaving them alone.

seventeenthShulker commented

2023-07-01 22:51:13 +02:00

I found what is likely the cause of 'random' nodes not dropping. From minetest's API docs, at https://minetest.gitlab.io/minetest/minetest-namespace-reference/#environment-access:

minetest.dig_node(pos)

Dig node with the same effects that a player would cause

Returns true if successful, false on failure (e.g. protected location)

Since no player is taking the action, maybe it assumes the 'player' is using their hand, so it drops nothing for most nodes?. I then found handle_node_drops (line 246) in https://git.minetest.land/MineClone2/MineClone2/src/branch/master/mods/ENTITIES/mcl_item_entity/init.lua. This is an override of the default minetest logic for determining whether a node can drop item(s), that specifically "allows digger to be nil". I am looking into whether re-using this could be a more elegant fix than hacking together a fake dig_node.

I found what is likely the cause of 'random' nodes not dropping. From minetest's API docs, at https://minetest.gitlab.io/minetest/minetest-namespace-reference/#environment-access: > - minetest.dig_node(pos) > > - Dig node with the same effects that a player would cause > - Returns true if successful, false on failure (e.g. protected location) Since no player is taking the action, maybe it assumes the 'player' is using their hand, so it drops nothing for most nodes?. I then found `handle_node_drops` (line 246) in https://git.minetest.land/MineClone2/MineClone2/src/branch/master/mods/ENTITIES/mcl_item_entity/init.lua. This is an override of the default minetest logic for determining whether a node can drop item(s), that specifically "allows digger to be nil". I am looking into whether re-using this could be a more elegant fix than hacking together a fake dig_node.

seventeenthShulker commented

2023-07-02 15:11:40 +02:00

If this thing is working now, as it seems to be, it hopefully also fixes #3547, and I have no idea how to work with protected areas but I'm fairly certain #1598 will not be affected as it doesn't know who activated the piston, nor does it pass that information on.

This is out of scope for this PR:

After the more difficult part of determining the player behind the push/pull interaction, someone could try passing the player into handle_node_drops (mods/ITEMS/REDSTONE/mesecons_mvps/init.lua, line 288) as a third argument.

If this thing is working now, as it seems to be, it hopefully also fixes #3547, and I have no idea how to work with protected areas but I'm fairly certain #1598 will not be affected as it doesn't know _who_ activated the piston, nor does it pass that information on. #### This is out of scope for this PR: After the more difficult part of determining the player behind the push/pull interaction, someone could try passing the player into `handle_node_drops` (mods/ITEMS/REDSTONE/mesecons_mvps/init.lua, line 288) as a third argument.

Michieal commented

2023-07-04 18:53:15 +02:00

This uses a workaround discussed in MineClone2/MineClone2#3547. The replaceable nodes with the group dig_immediate = 3 (e.g. sugar_cane) are the only ones to drop items when calling minetest.dig_node() on them, so for the others (e.g. bamboo), a 'fake' dig is performed by removing the node, spawning its drop item, and calling its minetest.registered_on_dignodes function (for example, so all the bamboo above the broken one is destroyed).

I wrote the bamboo that way, because of how it breaks, and the fact that it can drop two items on a specific random chance. (And, well, it was easier and more accurate to do it that way, than with minetest's drop_table.)

I also noticed that only one bamboo node (bamboo) could be piston-broken, and NOT bamboo_1, bamboo_2 or bamboo_3. This is because they were not added to the dig_by_piston group like the original node.

The variants are copies of the original node, and the group should have propagated, like the other groups. Where it might be an issue is in the actual piston code (because I had to add it to there, too, to make it pushable.)

P.S.

Empty shulker boxes only drop in Survival Mode. This seems to be because they do not drop anything in Creative Mode.

Shulker Boxes should always drop in survival, regardless of contents. And, should be pushable unless open. Creative mode, iirc, pistons should cause them to drop. It's only when broken by the player, does it destroy the item in creative. However, I can see that being an issue, as the engine interferes based on gameplay type (dig node). So, for pistons, may have to write a special dig / destroy/ etc.

> This uses a workaround discussed in https://git.minetest.land/MineClone2/MineClone2/issues/3547. The `replaceable` nodes with the group `dig_immediate = 3` (e.g. `sugar_cane`) are the only ones to drop items when calling `minetest.dig_node()` on them, so for the others (e.g. `bamboo`), a 'fake' dig is performed by removing the node, spawning its drop item, and calling its `minetest.registered_on_dignodes` function (for example, so all the bamboo above the broken one is destroyed). I wrote the bamboo that way, because of how it breaks, and the fact that it can drop two items on a specific random chance. (And, well, it was easier and more accurate to do it that way, than with minetest's drop_table.) > I also noticed that only one bamboo node (`bamboo`) could be piston-broken, and NOT `bamboo_1`, `bamboo_2` or `bamboo_3`. This is because they were not added to the `dig_by_piston` group like the original node. The variants are copies of the original node, and the group *should* have propagated, like the other groups. Where it might be an issue is in the actual piston code (because I had to add it to there, too, to make it pushable.) > ### P.S. > Empty shulker boxes only drop in Survival Mode. This seems to be because they do not drop anything in Creative Mode. Shulker Boxes should *always* drop in survival, regardless of contents. And, should be pushable unless open. Creative mode, iirc, pistons should cause them to drop. It's only when broken by the player, does it destroy the item in creative. However, I can see that being an issue, as the engine interferes based on gameplay type (dig node). So, for pistons, may have to write a special dig / destroy/ etc.

seventeenthShulker commented

2023-07-04 20:12:05 +02:00

and the group should have propagated

They were all manually set after shallow copying (table.copy) the table, just some were missing the dig_by_piston. There is a recursive 'deep copy' utility function at mods/ITEMS/REDSTONE/mesecons/util.lua, but it isn't used outside of REDSTONE (module reasons?) and it creates an entirely new table. In other parts of the ~~spaghetti bowl~~ codebase, I have seen table.copy used to copy groups between nodes, this might be a good separate change request?

Shulker Boxes should always drop in survival, regardless of contents. And, should be pushable unless open. Creative mode, iirc, pistons should cause them to drop. It's only when broken by the player, does it destroy the item in creative. However, I can see that being an issue, as the engine interferes based on gameplay type (dig node). So, for pistons, may have to write a special dig / destroy/ etc.

Yep, there might need to be an override or something for empty shulker boxes. It might be better if the on_destruct checked if the 'player' inventory already has (an empty shulker box) before deciding to drop/give one. (Currently it just checks if your inventory is empty...) Something like:

Already have an empty {color} shulker box? Breaking one drops nothing.
Don't have an empty {color} shulker box? Breaking one will drop.
Not a player? Breaking one will drop.

Also, I don't know how to check if the box is open. Barrels have a 'blockstate' for open/closed. Currently pushing open shulker boxes just closes the formspec and breaks the box.

But I might leave shulker boxes alone because the PR is getting a bit broad.

> and the group should have propagated They were all manually set after shallow copying (`table.copy`) the table, just some were missing the `dig_by_piston`. There is a recursive 'deep copy' utility function at `mods/ITEMS/REDSTONE/mesecons/util.lua`, but it isn't used outside of REDSTONE (module reasons?) and it creates an entirely new table. In other parts of the ~~spaghetti bowl~~ codebase, I have seen `table.copy` used to copy `groups` between nodes, this might be a good separate change request? > Shulker Boxes should always drop in survival, regardless of contents. And, should be pushable unless open. Creative mode, iirc, pistons should cause them to drop. It's only when broken by the player, does it destroy the item in creative. However, I can see that being an issue, as the engine interferes based on gameplay type (dig node). So, for pistons, may have to write a special dig / destroy/ etc. Yep, there might need to be an override or something for empty shulker boxes. It might be better if the `on_destruct` checked if the 'player' inventory already has (an empty shulker box) before deciding to drop/give one. (Currently it just checks if your inventory is empty...) Something like: * Already have an empty {color} shulker box? Breaking one drops nothing. * Don't have an empty {color} shulker box? Breaking one will drop. * Not a player? Breaking one will drop. Also, I don't know how to check if the box is open. Barrels have a 'blockstate' for open/closed. Currently pushing open shulker boxes just closes the formspec and breaks the box. But I might leave shulker boxes alone because the PR is getting a bit broad.

Michieal commented

2023-07-04 23:44:45 +02:00

TBH, the Bamboo module was a nightmare to keep track of, especially while doing other requests for everyone and helping out in both discord and in here. I'm happy that it's readable, and it put bamboo into the game before Mojang/Microsoft had it.

The shulkers... completely different issue, and I advise knocking out one issue at a time. Losing track of scope makes things a nightmare for everyone... reviewers, testers, YOU... lol.

TBH, the Bamboo module was a nightmare to keep track of, especially while doing other requests for *everyone* and helping out in both discord and in here. I'm happy that it's readable, and it put bamboo into the game before Mojang/Microsoft had it. The shulkers... completely different issue, and I advise knocking out one issue at a time. Losing track of scope makes things a nightmare for everyone... reviewers, testers, YOU... lol.

Michieal commented

2023-07-04 23:47:28 +02:00

Also, you should copy the image back to your computer or clipboard, and upload/paste it into the original comment. (if it's on your clipboard, you can Ctrl-V or Shift-INS it in.)

That way, it's there 3 yrs from now, and some poor ~~sucker~~ Dev trying to figure things out has it for reference.

Also, you should copy the image back to your computer or clipboard, and upload/paste it into the original comment. (if it's on your clipboard, you can Ctrl-V or Shift-INS it in.) That way, it's there 3 yrs from now, and some poor ~~sucker~~ Dev trying to figure things out has it for reference.

👍 1

seventeenthShulker changed title from ~~WIP: Piston-breakable nodes no longer fill up the push limit, and items properly drop~~ to WIP: Piston-breakable nodes no longer fill up the push limit, items properly drop

2023-07-06 14:49:43 +02:00

seventeenthShulker changed title from ~~WIP: Piston-breakable nodes no longer fill up the push limit, items properly drop~~ to WIP: Piston-breakable nodes don't fill up the push limit, items properly drop

2023-07-06 14:49:52 +02:00

seventeenthShulker commented

2023-07-06 16:05:47 +02:00

Should be protection-sensitive now. Examples of when an action is not permitted (ticked boxes completed):

Extending a lone piston into a protected area
Moving protected nodes
Pushing nodes into a protected area
Pulling nodes out of a protected area (piston still retracts)

Even if part of a connected (by slime or honey) series of blocks is outside a protected area, pushing/pulling will not occur.

If someone else's piston was already there before it was protected by you, it will not push unless it only affects nodes outside the protected area, but it can retract if it was extended in the first place.

This is all assuming the placer of the piston does not match the owner of the protected node(s).

If the owners match, pistons work like normal.

Should be protection-sensitive now. Examples of when an action is not permitted (ticked boxes completed): - [x] Extending a lone piston into a protected area - [x] Moving protected nodes - [x] Pushing nodes into a protected area - [x] Pulling nodes out of a protected area (piston still retracts) Even if part of a **connected** (by slime or honey) series of blocks is outside a protected area, pushing/pulling will not occur. If someone else's piston was already there before it was protected by you, it will not push unless it only affects nodes outside the protected area, but it can retract if it was extended in the first place. This is all assuming the placer of the piston does not match the owner of the protected node(s). If the owners match, pistons work like normal.

seventeenthShulker force-pushed piston_digs_properly from ab88ec4219 to 23bff89cfa

2023-09-16 18:49:01 +02:00

Compare

seventeenthShulker changed title from ~~WIP: Piston-breakable nodes don't fill up the push limit, items properly drop~~ to Piston-breakable nodes don't fill up the push limit, items properly drop

2023-09-16 18:51:34 +02:00

seventeenthShulker force-pushed piston_digs_properly from 23bff89cfa to 0ebaefefc3

2023-09-16 18:57:25 +02:00

Compare

seventeenthShulker commented

2023-09-16 19:02:18 +02:00

Um forgot to rebase cleanly the first time...
Picked this up again and fixed a conflict as there were no further bugs discovered on my end. Hence, no longer in WIP.

Um forgot to rebase cleanly the first time... Picked this up again and fixed a conflict as there were no further bugs discovered on my end. Hence, no longer in WIP.

the-real-herowl added the

Testing / Retest

label 2023-10-07 09:56:28 +02:00

the-real-herowl requested changes 2023-10-08 20:58:46 +02:00

the-real-herowl left a comment

Signs are destroyed by pistons and don't drop anything.

Cactus is destroyed by piston putting a block next to it (as it should), but doesn't drop anything.

Walls don't update their orientation when moved by pistons, or when neighboring blocks are moved by pistons. In the same time, fences and bars (and glass panes) work correctly.

Signs are destroyed by pistons and don't drop anything. Cactus is destroyed by piston putting a block next to it (as it should), but doesn't drop anything. Walls don't update their orientation when moved by pistons, or when neighboring blocks are moved by pistons. In the same time, fences and bars (and glass panes) work correctly.

mods/ITEMS/REDSTONE/mesecons_mvps/init.lua Outdated

					
				@ -560,3 +571,3 @@

				mesecon.register_mvps_unsticky("mcl_cake:cake_6")

				mesecon.register_mvps_unsticky("mcl_cake:cake")

				-- Carpet

				-- Carpet - pullable in MC but breaks when pulled downwards. At the moment, it just cannot be pulled.

the-real-herowl commented

2023-10-08 20:55:35 +02:00

While you are at it, could you make it so that it is pullable in any direction but upwards?

the-real-herowl commented

2023-10-09 04:13:36 +02:00

Crying obsidian and lodestone are pushable by pistons. They shouldn't be.

seventeenthShulker changed title from ~~Piston-breakable nodes don't fill up the push limit, items properly drop~~ to [WIP] Piston-breakable nodes don't fill up the push limit, items properly drop

2023-10-16 18:51:54 +02:00

seventeenthShulker commented

2023-10-16 20:34:48 +02:00

Signs are destroyed by pistons and don't drop anything.

Can confirm, and this is only when a block is being pushed into a sign.

Cactus is destroyed by piston putting a block next to it (as it should), but doesn't drop anything.

Could not reproduce (drops as expected) - any particular block?

Walls don't update their orientation when moved by pistons, or when neighboring blocks are moved by pistons. In the same time, fences and bars (and glass panes) work correctly.

More complicated. Panes and bars will sometimes refuse to connect, but will usually connect if they are pushed/pulled next to another pane/bar with an edge pointing the same direction.

> Signs are destroyed by pistons and don't drop anything. Can confirm, and this is only when a block is being pushed into a sign. > Cactus is destroyed by piston putting a block next to it (as it should), but doesn't drop anything. Could not reproduce (drops as expected) - any particular block? > Walls don't update their orientation when moved by pistons, or when neighboring blocks are moved by pistons. In the same time, fences and bars (and glass panes) work correctly. More complicated. Panes and bars will sometimes refuse to connect, but will usually connect if they are pushed/pulled next to another pane/bar with an edge pointing the same direction.

seventeenthShulker commented

2023-10-16 21:41:10 +02:00

Turns out walls and panes/bars don't use the connected nodebox type like fences do. This might be because they were added before late 2015 when this became a thing https://github.com/minetest/minetest/pull/3503. Fences were updated at some point to use the connected type, but I don't know if this is why only fences reconnect on move. I can't find anything telling fences to check adjacent blocks, so it might be a Minetest thing.

Turns out walls and panes/bars don't use the `connected` nodebox type like fences do. This might be because they were added before late 2015 when this became a thing [https://github.com/minetest/minetest/pull/3503](https://github.com/minetest/minetest/pull/3503). Fences were updated at some point to use the `connected` type, but I don't know if this is why only fences reconnect on move. I can't find anything telling fences to check adjacent blocks, so it might be a Minetest thing.

seventeenthShulker force-pushed piston_digs_properly from 6806e5f627 to 86942970db

2023-10-16 22:09:28 +02:00

Compare

the-real-herowl referenced this pull request

2023-10-16 23:19:57 +02:00

Walls not updating connections properly #3968

the-real-herowl commented

2023-10-16 23:22:41 +02:00

Signs are destroyed by pistons and don't drop anything.

Can confirm, and this is only when a block is being pushed into a sign.

Cactus is destroyed by piston putting a block next to it (as it should), but doesn't drop anything.

Could not reproduce (drops as expected) - any particular block?

Walls don't update their orientation when moved by pistons, or when neighboring blocks are moved by pistons. In the same time, fences and bars (and glass panes) work correctly.

More complicated. Panes and bars will sometimes refuse to connect, but will usually connect if they are pushed/pulled next to another pane/bar with an edge pointing the same direction.

Now nothing can be pushed into a sign... it is normal Java behavior. Similarly to bedrock, we have no reason to do that. But can we? Absolutely. Accepted behavior.

For cactus, try with a single cactus block. It seems it is destroyed also when placing a block next to it, so not related to this PR.

For walls, great catch! Not only fences, but panes also use the "connected" nodebox from what I've seen, and I've seen both work correctly with pistons. So walls need to be updated. Not for this PR either. I created an issue for that already.

Now, the only thing remaining is that carpet behavior. Do you think you can implement it? Or you would like it to stay the way it is?

> > Signs are destroyed by pistons and don't drop anything. > > Can confirm, and this is only when a block is being pushed into a sign. > > > Cactus is destroyed by piston putting a block next to it (as it should), but doesn't drop anything. > > Could not reproduce (drops as expected) - any particular block? > > > Walls don't update their orientation when moved by pistons, or when neighboring blocks are moved by pistons. In the same time, fences and bars (and glass panes) work correctly. > > More complicated. Panes and bars will sometimes refuse to connect, but will usually connect if they are pushed/pulled next to another pane/bar with an edge pointing the same direction. Now nothing can be pushed into a sign... it is normal Java behavior. Similarly to bedrock, we have no reason to do that. But can we? Absolutely. Accepted behavior. For cactus, try with a single cactus block. It seems it is destroyed also when placing a block next to it, so not related to this PR. For walls, great catch! Not only fences, but panes also use the "connected" nodebox from what I've seen, and I've seen both work correctly with pistons. So walls need to be updated. Not for this PR either. I created an issue for that already. Now, the only thing remaining is that carpet behavior. Do you think you can implement it? Or you would like it to stay the way it is?

Michieal commented

2023-10-18 04:08:40 +02:00

Cacti are weird in MC. If an item drop touches them, the item drop is destroyed. Also, if a block is placed next to a cactus, the cactus breaks. Kinda just sounding it out, for myself... As, I ~~am confused here~~ was confused here.

Cactus is destroyed by piston putting a block next to it (as it should), but doesn't drop anything.

gotcha. That's probably an update issue. (I recognize that this is not related to this PR.)

Cacti are weird in MC. If an item drop touches them, the item drop is destroyed. Also, if a block is placed next to a cactus, the cactus breaks. Kinda just sounding it out, for myself... As, I ~~am confused here~~ was confused here. > Cactus is destroyed by piston putting a block next to it (as it should), but doesn't drop anything. gotcha. That's probably an update issue. (I recognize that this is not related to this PR.)

the-real-herowl added this to the 0.85.0 - Fire and Stone milestone 2023-10-21 02:25:24 +02:00

seventeenthShulker commented

2023-10-23 11:54:25 +02:00

(I hope the images uploaded in the right order)

So, it turns out removing the carpet nodes from the mesecon.register_mvps_unsticky block resulted in what seems like ideal behavior.

First image; lever starts as off.
Second image; lever is now on.
Third image: lever is now off.

Pulling carpet down will break the carpet since it is no longer supported (for a split second) by any supporting block.
Pulling/pushing it onto a supporting block (even a lever or another carpet) does not break it (as expected).
Trying to pull it up off the ground will break it (expected, probably)

Also, carpet placement doesn't check if the position is unsupported, so if you spam carpets on the side of a pillar they immediately drop. Separate issue, anyway.

(I hope the images uploaded in the right order) So, it turns out removing the carpet nodes from the `mesecon.register_mvps_unsticky` block resulted in what seems like ideal behavior. First image; lever starts as off. Second image; lever is now on. Third image: lever is now off. Pulling carpet down will break the carpet since it is no longer supported (for a split second) by any supporting block. Pulling/pushing it onto a supporting block (even a lever or another carpet) does not break it (as expected). Trying to pull it up off the ground will break it (expected, probably) Also, carpet placement doesn't check if the position is unsupported, so if you spam carpets on the side of a pillar they immediately drop. Separate issue, anyway.

Screenshot_20231023_114023.png

262 KiB

Screenshot_20231023_114042.png

230 KiB

Screenshot_20231023_114054.png

270 KiB

seventeenthShulker commented

2023-10-23 12:02:57 +02:00

This is likely not possible in MC, but should probably be a feature anyway since we (currently) don't have an issue with carpet duping. The same arrangement with a horizontal piston is also stable.

Screenshot_20231023_115402.png

377 KiB

the-real-herowl commented

2023-11-03 01:11:23 +01:00

Are you going to make any further changes to this PR? Why is this still WIP?

seventeenthShulker commented

2023-11-04 17:01:17 +01:00

No, that should be it, as long as there aren't any more blocks I've missed. Will remove the WIP.

seventeenthShulker changed title from ~~[WIP] Piston-breakable nodes don't fill up the push limit, items properly drop~~ to Piston-breakable nodes don't fill up the push limit, items properly drop

2023-11-04 17:01:28 +01:00

seventeenthShulker force-pushed piston_digs_properly from 3675652c0c to 00cfca5947

2023-11-04 17:02:02 +01:00

Compare

the-real-herowl requested review from the-real-herowl 2023-11-06 20:48:55 +01:00

the-real-herowl commented

2023-11-06 20:50:10 +01:00

I'm approving this, can't formally approve due to Mesehub not working properly again.

the-real-herowl referenced this issue from a commit

2023-11-06 20:50:35 +01:00

Merge pull request 'Piston-breakable nodes don't fill up the push limit, items properly drop' (#3813) from seventeenthShulker/MineClone2:piston_digs_properly into master

the-real-herowl merged commit 5a069af072 into master