Add PlayerUseBowWithoutProjectileEvent

[Chaosdave34]

#11669

(Still dont have a better name for the event)

[Owen1212055]

Because this event is only specific to bows, I think that this should be getBowItem() or something more specific

[lynxplay]

tries to draw a bow or load a crossbow

[lynxplay]

We might be able to find a better name I guess, but certainly not related to bows xD

[Owen1212055]

I meant bows, which applies to both crossbows/bow. But not sure, maybe leave as is then.

[lynxplay]

Guess something like weapon item?

[Leguan16]

Cant you use anything as "bow" now?

[Chaosdave34]

Maybe just getWeapon()?

[Chaosdave34]

Maybe ProjectileWeaponItem, because thats the superclass of both bow and crossbow, although that's a really long name.

PlayerMissingProjectileItem?
PlayerMissingProjectileItemForProjectileWeaponItem?
PlayerMissingProjectileItemForWeapon?

(And isn't PlayerReadyArrowEvent confusing then, because its fired for crossbows and firework rockets aswell?)

[Chaosdave34]

Using this event to set an arrow fails when the player looks at a block instead of air (it still gets called).
I don't find an obvious reason for that.

Edit: And the bow does not animate the pulling back of the string when holding a shield in the offhand but the arrow still gets fired.

[MrPowerGamerBR]

Using this event to set an arrow fails when the player looks at a block instead of air (it still gets called).
I don't find an obvious reason for that.

I'm toying around with the same idea, and what I've noticed is that, if you hold the bow on the off hand, the bow does pull back.

If you listen to PlayerInteractEvent while looking at a block, you'll notice that the hand is called first, then the off hand second, but this DOES NOT happen when pulling the bow in the air (in the air, only the main hand is called when you have a bow in your hand), so maybe the server is overriding the use state when the off hand interact is called.

However, for some reason, cancelling the off hand event sadly does not make the main hand bow work... Cancelling the off hand does make the off hand bow not work tho.

[MrPowerGamerBR]

Another thing that I have found out: If you slap a

    @Override
    public void handleUseItemOn(ServerboundUseItemOnPacket packet) {
        if (packet.getHand() != InteractionHand.MAIN_HAND)
            return;

the bow DOES get pulled when using the main hand, so theorically it is possible to fix the issue.

[MrPowerGamerBR]

After debugging, I found out that the issue lies within the this.player.stopUsingItem(); // CraftBukkit - SPIGOT-4706 line in handleUseItemOn, if you remove it, it works fine.

(not saying that it SHOULD be removed, but I wonder what's the SPIGOT-4706 issue is tho)

[MrPowerGamerBR]

For the sake of avoiding other server owners and developers banging their wall against the head trying to figure out how to do this: I wanted to create a plugin that uses the bow behavior to with a custom bow that does not require arrows (context: created a cue stick model for a bow, and I created a custom plugin to play billiards (more bow force = more ball velocity) without needing any weird hacks like spawning fake arrows in their inventory)

To do this, I needed to create this patch (similar to this PR's patch but calls before any of the other arrow related events)

Changing the server to say that "hey there's an arrow for your bow!" DOES work if you are aiming at the sky, but does NOT work if you are looking at a block, because the client knows that there isn't an arrow in the inventory, so it thinks "okay let's use Use Item On Block instead of Use Item!", and while that SHOULD also work fine, the server cancels the bow use event when interacting with the off hand, due to a stopUsingItem() in handleUseItemOn.

To """fix""" that in my plugin, I listen to the interact event and just change the player's active item if they are interacting with their off-hand while holding the cue stick. Not a great solution, but it does work pretty well.

[SoSeDiK]

Thoughts on expanding the scope of this event?
I like the idea of being able to provide/replace a projectile in any scenario, like the linked EntityGetProjectileForWeaponEvent from the patch above, and have a similar EntityLoadsProjectileEvent in my fork (and its feature patch), though I also feed the default projectile into the event.

[dawon]

Thoughts on expanding the scope of this event? I like the idea of being able to provide/replace a projectile in any scenario, like the linked EntityGetProjectileForWeaponEvent from the patch above, and have a similar EntityLoadsProjectileEvent in my fork (and its feature patch), though I also feed the default projectile into the event.

I would go with PlayerSelectProjectileForWeaponEvent or something along that way, but other than that, I also vote for calling this event generally when selecting a projectile regardless of whether you have any valid projectiles in your inventory or not...

[Chaosdave34]

@SoSeDiK Does your implementation suffer from the same bug as mine?

Using this event to set an arrow fails when the player looks at a block instead of air (it still gets called). I don't find an obvious reason for that.

(Setting an arrow when the player has none.)

Edit: And the bow does not animate the pulling back of the string when holding a shield in the offhand but the arrow still gets fired.

[SoSeDiK]

@SoSeDiK Does your implementation suffer from the same bug as mine?

Yea, sadly have to use interact event workarounds on plugin's side, basically same solution as yours

[lynxplay]

Nearly a year huh.

I think this PR reached the point in time where it has been feature creeped to death with the unfortunate realization that messing with player state like this in such a place does not work out well.

Using this event to set an arrow fails when the player looks at a block instead of air (it still gets called). I don't find an obvious reason for that.

breaks the main reason this PR is being proposed in my head (given people want to use this to supply projectiles when none are present).
I'll be closing this PR with a big thank you for all the people putting in effort into this. If anyone has the time and motivation to find out why the above roadblock exists, they are more than welcome to take the PR diff and reopen it once fixed + obviously credit Chaosdave as a co-author for their great work on this so far.

Thank you for everyone involved, I hope my decision is understandable.