Does not work for all sand dupers about gravitycontrol HOT 8 CLOSED

Even more simple, here is my test world I use. It includes both type of duper: https://cdn.discordapp.com/attachments/914215994908639273/941902303324168192/sand_generator_test_world.zip

from gravitycontrol.

Can you share building details (e.g. tutorial youtube videos) for the two setups to ease replication ?

from gravitycontrol.

Well, if you want to be rather hacky you could abuse https://github.com/PaperMC/Paper/blob/master/patches/server/0674-Fix-dangerous-end-portal-logic.patch which is included in paper 1.16.5 till latest.

As the movement logic is executed first in the FallingBlockEntity implementation, the falling block entity (when it is passed to the EntityChangeBlockEvent) does have both portalBlock and portalWorld set to non-null values as it entered the end portal block previously in the method call.

You could hence force a dupe at exactly that point, however this solution requires NMS usage. Should be rather straight forward however for at least 1.17/1.18 with paperweight userdev.

from gravitycontrol.

E.g. https://pastebin.com/aBEn64pF as a super hacky examples properly duplicates the sand for both dupers in the test world you linked.

from gravitycontrol.

Another possible solution to this issue is a partial replication of mojangs logic to determine teleportation. More specifically by checking if the entities hitbox is inside the end portal block on the change block event (which, in the case of a dupe, it is). E.g.

@EventHandler(priority = EventPriority.HIGHEST)
public void onEntityChangeBlock(final EntityChangeBlockEvent event) {
    if (!(event.getEntity() instanceof final FallingBlock falling) || event.getTo() == Material.AIR) return;
    final var effectiveBB = falling.getBoundingBox().expand(-0.001D);

    for (final BlockFace face : DUPE_ALLOWED_PORTAL_FACES) {
        final Block relative = event.getBlock().getRelative(face);
        if (relative.getType() != Material.END_PORTAL) continue;

        if (relative.getBoundingBox().overlaps(effectiveBB)) {
            // Dupe it here
        }
    }
}

The method also passed the two dupers and did ignore normal blocks moving into the portal properly however would need more testing compared to the NMS method (which by definition only catches dupe cases).

from gravitycontrol.

Thank you very much for your comment! The solution with nms is very clever, I would not have thought of that because I thought it worked in reverse order.

Your other suggestion of checking if the hitbox collides is what I first did before I thought of using the velocity, but for some reason it was not sufficient. I do not remember why though, but I think it had false positives. so I will have to look again and see if I can reproduce.

In an ideal world my plugin would not use NMS, but I think here the NMS solution is the most reliable as it is internally what causes dupe, just reversed by paper. what I will probably do is have the NMS solution you suggest, with configurable fallback to the solution I have now.

Thank you again for looking! This is very helpful.

from gravitycontrol.

Happy to help 👍 Yea looking into the hitbox overlaps and it detecting false positives is definitely a good idea imo. It should be rather close to the server impl that checks if the entity is inside the portal block as well and obviously does not rely on a pretty aggressive hack into the server software's implementation detail 👍

from gravitycontrol.

done some testing and talked to sulu of paper discord. this should work. thank you again ❤️

from gravitycontrol.