[BUG]: ‘OnPlayerUsedItem’ does not trigger properly

[CCrous]

Before You Report

• I have searched for existing reports of this bug, and this bug report is unique.

Version

Game version: 14.1.1 & LabAPI version: 1.1.0.0

Description

The OnPlayerUsedItem event does not trigger properly. If a player uses an item (such as a Painkillers) and switches to another item before the usage animation ends, the event will not be triggered. This causes some plugins that rely on this event to not work correctly.

To Reproduce

1. A player starts using a consumable item (e.g. Painkillers).
2. Before the usage animation ends, they quickly switch to another item (e.g. a keycard).
3. Observe whether OnPlayerUsedItem is triggered.

Expected: The event should trigger upon successful use.
Actual: The event is not triggered if the player switches items before the animation ends.

Expected Behavior

The event should trigger upon successful use

Additional Information

nope

[xCynDev]

Bit of an odd request, but seeing as this will probably get fixed, is it possible to get an indicator when the event was fired regardless of the player switching items?

It's pretty much become a staple of Dr. Bright's servers, where players use it to cancel out custom effects granted by medical items. If this is fixed, we'll have to manually break it again.

However, if you could pass in some sort of boolean if it's something you can detect on your end (like bool WasBypassed for example), it would be much appreciated.

[Someone-193]

Bit of an odd request, but seeing as this will probably get fixed, is it possible to get an indicator when the event was fired regardless of the player switching items?

It's pretty much become a staple of Dr. Bright's servers, where players use it to cancel out custom effects granted by medical items. If this is fixed, we'll have to manually break it again.

However, if you could pass in some sort of boolean if it's something you can detect on your end (like bool WasBypassed for example), it would be much appreciated.

Do you really think NW will try to not make a breaking change fixing this :P

I think best solution is just another event, naming can be based on when and where it fires