SkriptLang
Add support for itemstacks in item cooldown expression/condition
Description
This PR aims to add support for itemstacks for the cooldown expression and condition. This change adds support for the cooldown group of itemstacks.
This PR does not add support for setting a cooldown group, that is left for when components are handled/when someone implements paper's components
With the implementation of itemstacks I've decided to change how they were grabbed and handled, in addition with the design of the system I was not 100% sure if using getMaterial properly support all x when people still had aliases
The new system runs them through a map for getAll and then follows it with a flat map to an itemstack list
Why no Test?
Test were not included in this PR as I am not sure how to go around implementing them, as I don't believe junit would be able to actually run a proper test on a fake player.
Target Minecraft Versions: 1.20.5+ Requirements: none Related Issues: #7429
Only concern I have with this is the possible breaking changes. If a user who is currently running a server that supports cooldown groups and is utilizing the current functionality, they would need to fix/update their code to retain how they're already using it. It's probably safe to assume that majority of users would prefer the itemstack+cooldown group over the item type. But, I think it would be nice if there was a way for users to use either or.
The only breaking change for servers is if they define cooldown groups and expect it to work with current functionality, if the component is not defined or no group is defined on the component there is no breaking change
The only breaking change for servers is if they define cooldown groups and expect it to work with current functionality, if the component is not defined or no group is defined on the component there is no breaking change
Ahh ok, so using #hasCooldown(ItemStack) internally checks if there is an assigned cooldown group and if not, defaults to itemtype?
The only breaking change for servers is if they define cooldown groups and expect it to work with current functionality, if the component is not defined or no group is defined on the component there is no breaking change
Ahh ok, so using
#hasCooldown(ItemStack)internally checks if there is an assigned cooldown group and if not, defaults to itemtype?
Internally it would check if there's a cooldown group if yes -> set cooldown for the group if no -> set cooldown for the material
