Direct control is triggered if dropping the pilot tool is cancelled

[Nikkilectric]

Describe the bug
Direct control is triggered if pilot tool drop event is cancelled

To Reproduce
Steps to reproduce the behavior:

1. 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

2024-06-23.23-03-28.mp4

[Nikkilectric]

Appears as if this is a spigot/paper bug, unrelated to movecraft. Closing the issue.

[Nikkilectric]

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

[Intybyte]

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

[Altylectric]

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!~

[Intybyte]

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?

[Altylectric]

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