Unfortunately, default values set in the C++ code for our script function parameters don't actually seem to work, and they always default to false because they receive a nil value from Lua. As a result, to not break compatibility with previous scripts, I've decided to use a skipAttachedPlayer argument instead so it can default to false while still providing the same benefits that sendToAttachedPlayer provided.
Previously, there was a confusing separation between script functions that had a "broadcast" argument and script functions that had a "toOthers" argument.
Those with broadcast sent the packet to all players on the server when broadcast was true. Those with toOthers sent the packet to all players other than the packet's attached player.
The former was based on the pattern of the original SendMessage() script function. The latter more closely resembled RakNet's own broadcast argument as seen here:
https://github.com/TES3MP/CrabNet/blob/master/include/raknet/RakPeer.h#L219
This commit makes it so all sending functions have a sendToOtherPlayers argument that is false by default and a sendToAttachedPlayer that is true by default. This should simultaneously allow sending to be more intuitive, while not breaking previous existing scripts to a significant degree.
Additionally, this commit also reduces some code repetition for all instances of packet-fetching in script functions.
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.
ActorDeath packets are sent for dead actors before their StatsDynamic packets. They contain the actor's deathReason in a manner similar to that of PlayerDeath packets.
A future commit will replace the deathReason with a variable named killer which will be an mwmp::Target.
Previously, turning off communication with the MasterServer from the server config and then attempting to use SetGameMode() or SetHostname() led to a server crash.
Previously, two players entering the same cell only sent and received their latest changes for dynamic stats, attributes, skills and equipment when they started sharing that cell.
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, 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)
Unfortunately, the handshake attempt limit implemented in 4ebfcc4a21 for 0.7 and then ported over to 0.6 in a3a341fee6 does not appear to work properly, which is why gathering more information on it is important.
A main priority in TES3MP development is to avoid making major changes to OpenMW code, so as to avoid merge conflicts in the future. Whenever avoiding potential conflicts seems especially difficult for the proper implementation of a particular multiplayer feature, that multiplayer feature is often put off until later or partially implemented with the intent of being revisited in the future.
Container sync is the perfect example. Previously, the OpenMW code for container actions was kept exactly as it was, with clients unilaterally accepting their own container changes as per singleplayer-specific code, with only the addition that clients sent container packets every time they made a change in a container, packets which were then forwarded unquestioningly by the server to other players. This meant that two players clicking on the same item in a container at the same time both managed to take it, thus duplicating the item.
Immediately after the packets were already forwarded, server scripts were able to check for incorrect changes, such as the removal of more items than should have existed in a container, but they had to send their own packets that attempted to fix what had already been accepted on the initial client and then forwarded to all clients, which was quite onerous in some scenarios, such as when a player on a slow connection immediately dropped items in the world after taking them from a container (which is why the default TES3MP serverside scripts made no attempt at sending corrective packets at all, preferring to expect the matter to be solved in a later C++ implementation).
This commit fixes item duping in containers by preventing container actions from initially running on clients and by ending the automatic forwarding of container packets by the server. Instead, clients now send container packets that act as requests for container actions, and serverside scripts have to forward these requests themselves. In other words, without a matching Container event in the server's Lua scripts, players are completely unable to affect containers for themselves or for others.
To forward a received Container packet, the following line must be used in a Container event in the Lua scripts:
tes3mp.SendContainer(true, true)
When an invalid action count is used in a container request, the serverside scripts can amend it using the following new function:
tes3mp.SetReceivedContainerItemActionCount(objectIndex, itemIndex, actionCount)
Thus, the serverside scripts are able to allow only container actions that are correct based on their own recorded contents for that container.
The OpenMW code allowing unilateral container actions in mwgui/container.cpp is now prevented from executing. When a player's container request is returned to them, code in mwmp/WorldEvent.cpp simulates those container actions instead.
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 allows the OnPCDrop variable to get set correctly even when object placements have to go through the server first in order to gain a unique multiplayer index (mpNum).
Among other things, this makes it possible to roll marijuana joints in the popular mod "Tribunal Code Patch".
There's no way SetAttributeModifier() was going to make sense if, say, a player had drunk 3 different potions fortifying the same attribute and was wearing equipment fortifying it as well. How would one change the sum modifier of those while accounting for each specific effect's duration and magnitude?
The only workable solution is to allow the server to clear the modifier.
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.
Add new initialization script functions to allow clearing all player changes vectors in a manner consistent with Actor and World functions
Add toOthers boolean to all methods that send packets with player changes vectors
David Cernat
Koncord
Unknown