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.
Previously, synchronization for strike enchantments was partially broken because it triggered the sending of ITEM_MAGIC attack packets, which are only supposed to be sent when a spell is cast from a magical inventory item.
Whenever an item is added to or removed from the player's ContainerStore, that player sends a PlayerInventory packet with just that addition or removal.
This eliminates all the unnecessary packet spam related to oversized PlayerInventory packets that had existed in one form or another since the initial implementation of inventory sync in 1b259e2d33
Additionally, move booleans from BasePlayer to LocalPlayer when they are only needed on the client, and make the usage of the isReceivingQuickKeys boolean consistent with the new isReceivingInventory boolean by having them both in the processors of their associated packets.
For a long time, whenever a PlayerInventory packet was sent, it contained all the items in the player's inventory, because that's how Koncord originally implemented it and I always had too many other priorities to go back and rework it.
From now on, clients only send PlayerInventory packet with the one item added or removed, with the single exception being trading with merchants, where the entire inventory is still sent for the time being.
When LocalActors briefly become DedicatedActors as the result of a server script, the DedicatedActors are immediately uninitialized to avoid bugs like them jumping in place or rotating slightly.
Additionally, the playing of animations and sounds received in packets for DedicatedActors is no longer done during their next update, but is instead done instantly when the packets are received.
The variable equipmentItem is identical to currentItem, so it should not have been added in commit 58a6a8c3bc
Addditionally, use a more descriptive variable name than "a" for item Ptrs.
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.
Spell, potion, enchantment, creature, NPC, armor, book, clothing, miscellaneous and weapon record data can now be sent in a RecordDynamic packet. Additionally, the packets include data related to associated magical effects (for spells, potions and enchantments), data related to default inventory contents (for creatures and NPCs) and data related to body parts affected (for armor and clothing).
The server now has associated script functions for setting most of the details of the above, with the main exception being individual creature and NPC stats.
Records can either be created entirely from scratch or can use an existing record (set via the baseId variable) as a starting point for their values. In the latter case, only the values that are specifically set override the starting values. Creature and NPC records also have an inventoryBaseId that can be used on top of the baseId to base their inventories on another existing record.
The client's RecordHelper class has been heavily expanded to allow for the above mentioned functionality.
When players create spells, potions and enchantments as part of regular gameplay, they send RecordDynamic packets that provide the server with the complete details of the records that should be created. When they create enchantments, they also provide the server with armor, book, clothing and weapon records corresponding to the items they've enchanted.
This functionality added by this packet was originally supposed to be exclusive to the rewrite, but I've gone ahead and tried to provide it for the pre-rewrite in a way that can mostly be reused for the rewrite.
This makes it possible to "reload" the Ptrs in active cells when changes happen to the ESM record that they are based on. In practice, the old Ptrs are deleted, their RefNums and MpNums are blanked out, and new Ptrs are created that use the same RefNum and MpNum as before.
The above has required me to also add a method called setRefNum() to CellRef to allow setting a RefNum on the fly.
There may be a more elegant implementation available for updatePtrsWithRefIds(), but it requires additional research.
Previously, attempts to reuse the same reference for multiple creature disguises led to movement animation issues, as well as a dynamic_cast error in Creature::getInventoryStore() that made a DedicatedPlayer vanish completely when they first lost their creature disguise, then disguised themselves as a creature that could not hold weapons and then disguised themselves as a creature that could hold weapons.
The usage of const_cast has been replaced with usage of MWWorld::getModifiableStore() and ESMStore::overrideRecord()
Methods whose names started with "update" now start with "override", for consistency with ESMStore's overrideRecord()
New methods have been added for "overriding" enchantment, potion and spell records, which actually leads to them being created with their already set refIds if they haven't been created yet, as per the description of ESMStore::overrideRecord(): "Insert a record with set ID, and allow it to override a pre-existing static record."
Usage of RecordHelper methods has been updated in DedicatedPlayer.
Actors who are on the ground have their inertial force ignored, so they are now made to not be regarded as being on the ground in World::setInertialForce()
I originally added rotation animation sync as part of commit 068a45be87. Unfortunately, it meant the PlayerPosition packets were now twice as large as they had been before, which was less than ideal for such a frequently sent packet, which is why Koncord switched to a more optimized approach in commits 5f30dfd5db and d67db1a9bd.
Recently, there have since been some rotation animation problems in OpenMW, which have broken the way Koncord's approach looks. My original approach still looks somewhat okay, so I'm switching back to it until we can figure out how to reuse it under the current circumstances.
David Cernat
Koncord
Marc Zinnschlag
Andrei Kortunov
Capostrophic
Capostrophic
Koncord