Previously, each client chose its own attack animations for DedicatedPlayers and DedicatedActors based on the direction they were walking in, which however led to desyncs for players with "Always Use Best Attack" enabled and for creatures which pick their attack animations randomly.
When Koncord implemented spellcasting, he made it so only the act of initiating a spellcast was synchronized, leaving it to other clients to actually cast a spell for a dedicated player or actor once their spellcasting animation was over. This had led to a lot of desyncs and has always been inconsistent with the handling of attacks, so I've belatedly gone ahead and prevented the end of a spellcasting animation from having any effect for dedicated players and actors, making them cast a spell when an appropriate Cast packet is received from them instead.
Additionally, the logged messages in MechanicsHelper's handling of attacking and casting have been moved around slightly.
Enchanted inventory items continuously recharge their enchantment charges, which getItemPtrFromStore() should account for.
Additionally, prevent framelistener errors caused by PlayerItemUse packets about non-existent items.
Previously, the player's currently selected weapon was being used in ranged attacks as in the original melee-oriented attack sync, which meant that shooting one type of projectile and then equipping another while the old projectile was still in the air turned the old projectile into the new projectile upon impact.
Additionally, avoid running most of the code in MechanicsHelper::assignAttackTarget() for non-hitting melee and ranged attacks.
Projectile hits now send Attack packets with RANGED attacks, and their success or failure is now synchronized.
Strike enchantments no longer require a valid victim to be synchronized.
Additional debug messages have been added for attacks.
Players can no longer unilaterally use items on themselves in their inventory. When they try to use an item, they send a PlayerItemUse packet to the server with the item's details. A serverside script can then check the item and either send the packet back to make the item use go through or drop it.