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.
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.
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.
This should clarify the real meaning of the packet and its associated event.
The event itself has been renamed from OnPlayerKillCount to OnWorldKillCount.
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.
Add serverside script functions for determining the killers of both players and actors.
Use unsigned ints for script functions returning an object or actor's refNumIndex or mpNum.
Remove updateDeadState() from LocalPlayer and make its code part of updateStatsDynamic() for simplicity.
Since the beginnings of TES3MP, equipment packets have only been sent whenever an item has been replaced by an item with a different refId, with changes in an item's charge or count not sending a packet (but being included in the next packet sent as a result of a refId change). The reason for this was ostensibly the fact that every single equipment packet always included the details for all 19 equipment items (as per Koncord's original design decision), which would have led to massive packet spam if such a packet was sent every time you shot an arrow or lost a little bit of your armor's condition.
With minimalist equipment packets, it is now viable to send equipment packets whenever any item changes in some way, by having the equipment packet contain only that one item.
Previously, the index changes were not cleared at the start of their corresponding update functions, which in turn meant that an Attribute/Skill/StatsDynamic/Equipment packet received by a player from the server made that player send back the same packet, as the index changes from it were retained.
Additionally, exchangeFullInfo was not set to false, thus sometimes leading to constant full exchanges of information.
Previously, whenever a single attribute value changed for a player, that player then sent a PlayerAttribute packet with all values for all 8 attributes.
This did not cause anywhere as much packet spam as PlayerSkill used to, but there was no good reason not to fix it as well.
(cherry picked from commit b0965f094a)
Previously, whenever a single skill value changed for a player, that player then sent a PlayerSkill packet with all values for all 27 skills, plus the player's progress towards the next level and the bonuses to each attribute on the next level up as the result of sklll increases thus far.
This commit makes PlayerSkill contain only the values of specific skills, moves the player's progress towards the next level to PlayerLevel packets, and moves the bonuses to each attribute on the next level up to PlayerAttribute packets.
Players now also send a PlayerSkill packet whenever their progress towards a new point in a skill changes. This was previously avoided so as to not have massive packet spam.
(cherry picked from commit ef79a98544)
Previously, an attempt by the server to simultaneously change a player's cell and skills (as you'd expect when a player file is loaded) led to:
1) The server sending the cell packet first and the skill packet afterwards
2) The player receiving the cell packet and sending their own skill packet as part of the client's forced skill update
3) The player receiving the skill packet from the server
4) The server receiving the skill packet from the player
The result was that, if the player then left the server without sending another skill packet, the server's memory retained the skills the player had sent instead of the skills it had sent to the player.
This is the first step in a solution to that situation and similar ones.
(cherry picked from commit cac4684986)
Note: In 0.6.x, this was only a problem if a player's cell was set by the server first and their skills were set next, i.e. this was not a problem in the default CoreScripts because the opposite order used there masked the problem. It was a more significant problem in 0.7 because all packets were queued for a player and sent in a specific hardcoded order.
Previously, charGenStage.end was doing double duty as both the variable indicating the number of CharGen stages and – when set to 0 – the variable indicating that CharGen was over. The latter role is now filled by a new boolean.
(cherry picked from commit 926106cf8c)
Previously, initial cell states were sent in LocalPlayer::processCharGen() and were ignored by the server because the player was not yet regarded as loaded. The result was that existing players logging in could not see each other until they went through at least one cell change.
(cherry picked from commit b4e8560698)
# Conflicts:
# apps/openmw/mwmp/LocalPlayer.cpp
This avoids the following error when receiving repeated PlayerBaseInfo packets: "Error in frame: Invalid slot, make sure you are not calling RefData::setCount for a container object"
Additionally, only re-equip items as the result of a PlayerBaseInfo packet if resetStats is true (because of its side effect of auto-equipping items for the player).
Previously, throwing weapon sync was completely broken for players, as the count for their equipped throwing weapons was never set and – as a result – defaulted to a count of 1 on other clients. As a result, any time a player threw a dart, they would then appear as having switched to hand-to-hand for other players.
Moreover, the count of equipped items was mistakenly based on the total count of items with that refId in the inventory. As a result, if – for example – I equipped 1 Daedric Longsword and had 4 others in my inventory, my DedicatedPlayer on other clients would equip a Daedric Longsword with a count of 5. If I was overencumbered by having that many Daedric Longswords on me and then dropped 4 of them, allowing myself to move again, my DedicatedPlayer would still walk around with 5 Daedric Longswords and lack animations due to still being overencumbered on the other clients.
These problems were less prevalent for actors, but their equipment updating code has also been changed to match that of players.
Certain servers do not want the players to have debug information about the locations and actions of other players, so a client's log level can now be enforced by the server via the GameSettings packet.
