Tweakeroo

Tweakeroo

2M Downloads

Strange Behavior of Block Rotations on Spigot

spacewulf opened this issue ยท 8 comments

commented

I know that this is already a documented issue, but I've noticed some strange behavior of the block rotation function. I've found that obviously, some of the placement is limited, but works in other scenarios. I've found so far that pistons do not work, however stairs, rails, and shulker boxes do work. What is happening here, and is there any hope to a way around this?

commented

This is known and basically same as on a vanilla server. Without server-side support the Flexible Placement rotation basically only works with blocks that are placed based on the block side that you click on.

I don't remember if stairs and rails have such behaviour if you click on an adjacent block side instead of the top of the block, but if they work they I assume they do. But at least Shulker Boxes, End Rods, all logs, Quartz Pillars etc. are such blocks that only care about the block side you click on.

Pistons, Observers, Droppers/Dispensers in 1.12.x and below were based vertically depending on the player's position in relation to the clicked position (and if the rotation should not be vertical, then it would depend on the player's yaw facing, so between the horizontal rotations the orientation was able to be spoofed by a faked player rotation packet before and after the item use packet). But in 1.13+ this changed, and now they are placed based on the player's head rotation on the server, and the head rotation is only set from the player's tick method based on the main rotation, so it's not possible to instantly spoof it from the client anymore, there would need to be at least a one tick delay between the spoofed rotation packet and the item use packet being handled on the server.

So basically what this comes down to, is that in 1.13+ it would be possible to spoof the rotation for all blocks, but it would need a delay between the rotation packet and the item use packet. I just haven't implemented this (yet?), as the needed delay would also depend on the network delays and the server tick rate (and lag spikes), and also the mod would then need to prevent normal vanilla rotation packets from being sent between the spoofed rotation packet and the item use packet. it's possible I might implement this after I do the placement code rewrite at some point.

commented

Do you by any chance know of the coding that is in spigot/paper that would interfere with the placing event? I'm trying to create a custom jar to work my server. I've found that craftbukkit does allow it, but spigot/paper do not.

commented

I think spigot/paper somewhere have a check that prevents clicking on air blocks, which is how the flexible placement mode works - it clicks on the target air block instead of the block behind like you would normally in vanilla. But I have no idea if this is configurable, I think someone said it works on paper or there is an option in paper to disable that check.

commented

Huh. That's strange, because the tweak where you are able to place a block above the one you're looking at still works. I'll see if I can look into it.

commented

Sorry to bump this, but it seems like I'm having stranger behavior with piston rotations on a singleplayer world as well. Oddly enough, observers seem to work fine. The center square for pistons is the only one that doesn't seem to work; it always results in the piston "facing away" from the target block, which is usually the default behavior. Observers will always face the opposite direction of the default; the only block that doesn't seem to work in my testing are pistons.

commented

@maruohon thanks for the response! It seems you're right that other blocks behave the same way. Stairs, hoppers, and observers will be reversed but pistons, dispensers, and droppers don't change their orientation. It seems a bit odd to me that the center of the interface depends on the direction you're facing but the sides don't. I think if you do end up rewriting the code for this it might be a good idea to make it consistent between all of these.

In my opinion it makes sense to reverse it since if you're using the overlay you're probably trying to do something that is not part of vanilla behavior. In any case, thanks for clearing it up! I'll use accurate block placement in the meantime.

commented

These only depend on the player facing when used on the top and bottom side of a block, if I remember right? As nothing else really makes sense in that case. When used on the side of a block, then the rotation is basically "left/right or up/down".

But if you are on a server that does not have a mod handling the carpet accurate placement protocol (currently only CarpetExtra and skyrising's QuickCarpet do that, with the accurateBlockPlacement Carpet rule enabled), then only blocks that only care about the block side you click on will work at all currently. So the intended behavior can be observed in single player, but note that you need to keep the carpet protocol option (currently at the top of Tweak Toggles) enabled, even in single player, for things to work properly.

commented

@devmattrick The center region in the rotation mode of Flexible Placement I believe is set to "opposite/reverse", but the flexible placement rotation being used first select the facing to be the clicked block side's opposite. So the observer is actually the outlier here, due to how the direction value is defined for it... I think.

Usually with pistons, observers and droppers/dispensers, you want to use the Accurate Block Placement tweak (which does not have any visual overlay) instead of the Flexible Block Placement tweak, as in most cases you want to place those block either facing into the clicked block, or away from it, or just reversed from the normal vanilla placement behavior. Sometimes there are situations where you are standing such they you want to place them "sideways" relative to your location, so the flexible rotation can also occasionally be useful.

Also note that there are currently many bugs in certain situations in the placement code, as it grew by several features after the first feature which was just the flexible placement tweak alone. For example I believe accurate placement + flexible offset used together is bugged atm, at least in certain orientations. I basically need to fully rewrite all the placement related code, it's not fixable or maintainable in its current, messy state.