Sequentially fired click handlers that don't make sense

[wind geyser]

I have the following server side events:

BlockEvents.rightClicked('minecraft:dragon_head', (e) => {
  ...
  e.item.shrink(1)
  e.player.give('minecraft:glass_bottle')
  ...
})

ItemEvents.rightClicked('minecraft:glass_bottle', (e) => {
  if (e.hand !== 'main_hand') return
  ...
  console.log('fired')
})

If I right click a dragon head with a different item that triggers the item replacement code, the item event right click event ALSO fires. This doesn't not seem to make sense because the original right click was triggered with an item that was not a glass bottle. I don't think this should be able to chain across like that. Is there a way to prevent this?

[scenic pollen]

Once your ticket has been resolved, please close it with </ticket close:1054771505520717835> command!

[proud depot]

delay the give by a tick, or pop the item rather than give it directly

[wind geyser]

Hmm thought about doing a delay, it just seemed roundabout, was wondering if there was a way to avoid that

[proud depot]

i dont believe you can prevent sequential firing like that without weird external variables to store state

[wind geyser]

yeah ok, thanks for confirming, just wanted to know if there was an alternative

i dont want to pop the item because then this right click interaction wont work with create deployers

[proud depot]

wat

[wind geyser]

If I pop the item, it'll pop into the world, whereas with a create deployer it'll change the item in the deployer hand to a glass bottle

which is what I want to happen for consistency

[proud depot]

sounds like more of an automation challenge

[wind geyser]

In some ways yeah, but I don't want that particular challenge in this part of my pack specifically

[proud depot]

fair

[wind geyser]

Thanks for confirming, I just went with

server.scheduleInTicks(1, () => {
  player.give('minecraft:glass_bottle')
})

[proud depot]

how does that play with spam clicking > 20cps?

[wind geyser]

That's a good question, I'm not sure it's easy to test since the item to click is a potion of regen, which doesn't stack. Let me change it to test

[proud depot]

ah,if its unstackable then its probably not a problem

[wind geyser]

Doesn't seem to be an issue with spam clicking, the sequential trigger issue doesn't happen

I guess since the item is added next tick

it doesn't matter if you have multiple in one tick, they all get deferred to the next tick

Thanks for the help, much appreciated