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.
Previously, a script changing a player's cell and position at the same time would end up sending a position packet first and then a cell change packet that overrode the former, with the player ending up at the center of the destination cell instead of at the correct position.
Add getSkillIncrease() and setSkillIncrease() script functions to get and set the attribute bonuses received at the next level up as a result of skill increases.
Previously, getSkill() and setSkill() attempted to return and set the attribute bonuses, respectively. However, they mistakenly used a skill ID as a parameter for the attribute bonuses, when in fact npcStats.mSkillIncrease is an integer array of size 8 where the key stands for an attribute's ID. As a result, setSkill() had the unexpected side effect of messing up a player's major and minor skills because of the invalid values it was setting for npcStats.mSkillIncreases.
Previously, trying to send a level packet after base info and character class packets in a script actually led to the level packet being sent first and then being overridden by the others, with the player ending up at level 1 on their client.
Previously, the fact that a character class packet got sent after a dynamic stats packet caused the dynamic stats to get overridden on the client by the class change.
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.
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.
