APDevTeam
Direct control is triggered if dropping the pilot tool is cancelled
Describe the bug Direct control is triggered if pilot tool drop event is cancelled
To Reproduce Steps to reproduce the behavior:
- Cancel the drop event for the pilot tool (In my case, via Skript, which then triggers /rotate left afterwards) Expected behavior It should not enter direct control.
Screenshots See attached video for this issue.
Versions (please complete the following information):
- Movecraft: v9557e6f999464f0f842e7624e8f862b3d1bd947 (Dev build)
- Addons: None
- Java JDK 21 (unsure which dist)
- Minecraft 1.21
Additional context
https://github.com/APDevTeam/Movecraft/assets/136409902/5b569fbc-3e6c-4a94-8c83-2693c98cdd20
Appears as if this is a spigot/paper bug, unrelated to movecraft. Closing the issue.
This can be solved with PlayerDropItemEvent, Here's another video of the issue:
https://github.com/user-attachments/assets/1dfc9a2e-76c4-4d5c-864c-c39644bec15c
As you can see, it does not trigger when looking at a block, but triggers when dropping the item facing air
This can be solved with PlayerDropItemEvent, Here's another video of the issue: 2024-09-05.17-55-23.mp4
As you can see, it does not trigger when looking at a block, but triggers when dropping the item facing air
This cannot be fixed in any vanilla server software, no matter if you are running paper, bukkit, let me explain why, What happens is that internally there are 2 packets, lets call it packet A and B Packet A is sent when dropping an item Packet B is sent to play the "hit" animation
When dropping an item A and B are sent When hitting something in general B is sent only
So the only way to check if the client player is hitting something is check packet B, which also is used when dropping item, and oacket B doesn't have information about the cause of the "hit" animation. Hence this is not fixable by us, by paper, by spigot, by bukkit. Maybe with a modded client implementing your own event & packet, but it is more pain than it is worth
This can be solved with PlayerDropItemEvent, Here's another video of the issue: 2024-09-05.17-55-23.mp4 As you can see, it does not trigger when looking at a block, but triggers when dropping the item facing air
This cannot be fixed in any vanilla server software, no matter if you are running paper, bukkit, let me explain why, What happens is that internally there are 2 packets, lets call it packet A and B Packet A is sent when dropping an item Packet B is sent to play the "hit" animation
When dropping an item A and B are sent When hitting something in general B is sent only
So the only way to check if the client player is hitting something is check packet B, which also is used when dropping item, and oacket B doesn't have information about the cause of the "hit" animation. Hence this is not fixable by us, by paper, by spigot, by bukkit. Maybe with a modded client implementing your own event & packet, but it is more pain than it is worth
Interestingly enough, the "hit"/PlayerInteractEvent (Packet B) packet does NOT trigger if the player is looking at a block and dropping! a fix can be implemented using packets or placing an invisible block in front of the player (if facing air), I have this in my own plugin, but I figured it may be useful to have in the main plugin hence the request!~
This can be solved with PlayerDropItemEvent, Here's another video of the issue: 2024-09-05.17-55-23.mp4 As you can see, it does not trigger when looking at a block, but triggers when dropping the item facing air
This cannot be fixed in any vanilla server software, no matter if you are running paper, bukkit, let me explain why, What happens is that internally there are 2 packets, lets call it packet A and B Packet A is sent when dropping an item Packet B is sent to play the "hit" animation When dropping an item A and B are sent When hitting something in general B is sent only So the only way to check if the client player is hitting something is check packet B, which also is used when dropping item, and oacket B doesn't have information about the cause of the "hit" animation. Hence this is not fixable by us, by paper, by spigot, by bukkit. Maybe with a modded client implementing your own event & packet, but it is more pain than it is worth
Interestingly enough, the "hit"/PlayerInteractEvent (Packet B) packet does NOT trigger if the player is looking at a block and dropping! a fix can be implemented using packets or placing an invisible block in front of the player (if facing air), I have this in my own plugin, but I figured it may be useful to have in the main plugin hence the request!~
hahahah gaslighting the client that sounds cool, why don't you PR the fix then? or is it another plugin that fixes said issue in such a way?
This can be solved with PlayerDropItemEvent, Here's another video of the issue: 2024-09-05.17-55-23.mp4 As you can see, it does not trigger when looking at a block, but triggers when dropping the item facing air
This cannot be fixed in any vanilla server software, no matter if you are running paper, bukkit, let me explain why, What happens is that internally there are 2 packets, lets call it packet A and B Packet A is sent when dropping an item Packet B is sent to play the "hit" animation When dropping an item A and B are sent When hitting something in general B is sent only So the only way to check if the client player is hitting something is check packet B, which also is used when dropping item, and oacket B doesn't have information about the cause of the "hit" animation. Hence this is not fixable by us, by paper, by spigot, by bukkit. Maybe with a modded client implementing your own event & packet, but it is more pain than it is worth
Interestingly enough, the "hit"/PlayerInteractEvent (Packet B) packet does NOT trigger if the player is looking at a block and dropping! a fix can be implemented using packets or placing an invisible block in front of the player (if facing air), I have this in my own plugin, but I figured it may be useful to have in the main plugin hence the request!~
hahahah gaslighting the client that sounds cool, why don't you PR the fix then? or is it another plugin that fixes said issue in such a way?
Because I'm not sure if my fix is good enough xD It's a fix in my own plugin that listens to the pilot tool drop & places a barrier (then removes it quickly), but I bet talented dev could do this via packets, removing the issue somehow without the chance to place permanent barrier blocks, as I have no experience with packets