Previously, creatures with fast attack animations would have their attack updated right after being started, which happened so quickly that it prevented the attack start from actually being sent by the client.
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.
This means the server scripts are now required to send a WorldKillCount packet as a reply to ActorDeath packets sent by clients. This gives the server full control over which kills are counted, while also solving the previous problem of kills being counted only for actors that had finished their death animations.
Rename the old WorldKillCount that was a Player packet into PlayerPlaceholder. Rename the unused CellCreate that was a Worldstate packet into WorldKillCount. On the server, move kill count-related script functions from QuestFunctions to WorldstateFunctions.
Previously, using CellController::getCellStore() to get an unloaded CellStore would make its references get loaded in the process, with the CellStore's loadRefs() then running updateMergedRefs(), which in turn – before getting as far as setting the CellStore's state to State_Loaded – would call CellController::hasLocalAuthority() on its accompanying ESM::Cell, which would then run CellController::isActiveWorldCell(), which would then run CellController::getCellStore() to get the CellStore again, which – still being marked as unloaded – would run the whole loop again... and again.
For starters, the new packet can set which client scripts have all of their variables synchronized between players. The previous hardcoded list of IDs for synchronized scripts has been removed.
Previously, creatures with fast spellcasting animations would cast their spells before their success had actually been calculated, causing them to fail.
Dead players will now show up at the correct cell and position for living players, making server scripts that allow players to revive each other much more functional.
Originally, the PlayerSkill packet contained skills, attribute increases and level progress. In 78441c769a, the attribute increases were moved to the PlayerAttribute packet and the level progress was moved to the PlayerLevel packet, but – due to an oversight – attribute increases and level progress were still being applied to the local player only when a PlayerSkill packet was received, based on whatever values were stored from the last PlayerAttribute and PlayerLevel packets.
Previously, multiple stacks of the same item ID could overwrite data in each other because of how the logic in ContainerStore::add() works. For example, a stack of 5 grand soul gems with no souls would get added to the player, then the attempt to add a grand soul gem with a particular soul would retrieve the previous stack first before setting all of it to that soul, resulting in 6 grand soul gems with that soul.
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, client mods adding packet-sending scripts to the spawn area made clients send the associated packets as soon as they inputted their character name when joining a server using those mods. This made the clients either get disconnected for not replying to a handshake first, or it made them get kicked for sending object packets that are disallowed for players who are not logged in.
To fix this, LocalPlayer's hasFinishedCharGen() has been replaced with isLoggedIn(), because the former was already returning true when players inputted their names.
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.
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.
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.
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.
Although weather sync was added by Koncord to the rewrite in fd721143e2 in a way that used surprisingly few lines of code, it relied on the server requesting weather states every second from authority players and sending them to non-authority players, while also allowing only very sudden weather transitions across regions, i.e. if there was one player in the Ascadian Isles who had stormy weather, and another player with clear weather in the Bitter Coast Region walked across to the Ascadian Isles, that player was instantly made to have stormy weather with no kind of transition at all.
My approach solves both of those problems. It solves the packet spam by only sending weather updates to the server when weather changes happen or when there are new arrivals to a weather authority's region, and it allows for both sudden weather transitions when players teleport to a region and for soft, gradual transitions when players walk across to a region. It is inspired by my previous actor sync, and uses a WorldRegionAuthority packet to set players as region authorities in a similar way to how ActorAuthority sets players as cell AI authorities. Weather changes are created only by the region authority for a given region, and weather packets are also only sent by that authority.
However, it should be noted that gradual weather transitions are used by default in this implementation. To use sudden weather transitions, the serverside Lua scripts need to forward WorldWeather packets with the forceWeather boolean set to true. That is, however, already handled by our default Lua scripts in situations where it makes sense.
This should clarify the real meaning of the packet and its associated event.
The event itself has been renamed from OnPlayerKillCount to OnWorldKillCount.
The server can now make actors activate players and objects, at least in theory. In practice, OpenMW''s AiActivate package needs to be worked so it allows specific objects as targets instead of just refIds.
Previously, all crime witnesses stopped being hostile to a respawning player for as long as the player's diedSinceArrestAttempt was true. That meant that, in an area with no guards to arrest the player, crime witnesses did not enage in combat with the player at all ever again until diedSinceArrestAttempt became false.
This commit makes it so the time of the last crime is recorded for each witness, and that is then compared with the time of the LocalPlayer's last death for a one-time crime forgiveness during that player's current life.
This is essentially a gameplay adjustment for "singleplayer with respawns," and will have to be reworked to make sense for every player in multiplayer, though that requires reworking the crime system as a whole and is thus on hold.
