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.
This will prevent the server from overwriting a player's human form stats with their werewolf form stats.
Additionally, share PlayerShapeshift packets last when exchanging data with another player.