New Recommended Build Released!

Announcements
1

Hello everyone!

We have a released a new Recommended Build of SpongeVanilla and SpongeForge, with many fixes and changes to make your servers smoother and better for you and your playerbases! However, along with this, we have had to make a change that may affect an assumption that plugins may have been making for the past five months in order to fix a significant issue. Please read this carefully, and accept our sincere apologies for the issues this may have, and/or will, cause.

Changes to Custom Data on Players

The gist of the change is as follows:

Plugins that make use of Custom Data Manipulators on Players will no longer have this custom data copied over when the player respawns (after death or through world teleportion).

A Bit of Context - Why Has This Come About?

Approximately five months ago, I had reported an issue where the VANISH status was not being correctly copied across to players when they respawn and commented that I was unsure as to whether this affected other data, including custom data. A PR was created, and subsequently pulled, into the code base that attempted to fix this by copying all data manipulators that existed on the “old” player to the “new” player.

On world transfer, this was generally okay because the state of the player should not change as they travel through a portal. However, when a player died, this again happened - and a significant issue sometimes arose at this point.

In Sponge, much of the information about a player’s state is held in “data manipulators” and for performance reasons, we cache these. So, if a player is set on fire or is affected by a potion, this information is kept in a manipulator. When a player dies, some of this data, such as burning status or potion type, should also be removed from the player. The commit in question copied all data, whether it was custom data or not, from the old player to the new player - so if a player was on fire and died, when they respawned, they were still on fire - and you can probably guess that they shouldn’t be.

What We Are Doing About It

This was obviously a massive mistake on our part and I can only apologise for this being an issue. The fix is to revert this code, such that no data manipulators will be copied when the player respawns. While we could try copying custom data across, we will no longer be doing so. This is consistent with how this worked before, and this is how it will stay.

Note that this is consistent with how data will work upon player respawn in API 8.

What You Need To Do About It

Server Owners

In general, most plugins are expected to be unaffected, however if you find that some plugins lose data/information on players after they change world or respawn (for example, through death), update the plugin (if possible), then contact the author of the plugin concerned, and point them to this post. They should follow the instructions in the section below.

Plugin Developers

If you want them to remain on players during respawns:

  1. Listen to RespawnPlayerEvent
  2. get your old DataManipulator from the Player returned by getOriginalPlayer()
  3. offer this DataManipulator to the Player returned by getPlayer()

This will ensure any custom data transfers over. You can choose to not copy data manipulators over, of course, and the old Player may be inspected for any other state at this time.

Recommended Build 7.1.8 for SpongeForge and SpongeVanilla Released

With that out of the way, we are pleased to announce that a new Recommended Build has been released! As the name implies, we recommend that you update to this build at your earliest convenience. This release has the following changes:

  • Further attempt to mitigate level_sponge.dat file corruption;
  • Fixed tab completion of command that use child elements;
  • Fixed the keepInventory flag on players being set to false when respawning by quitting to title screen and logging back into a server (meaning that players could lose their inventory on death, even if a plugin has set otherwise);
  • Fixed player GameProfiles becoming desynchronised over repeated user sessions;
  • Fixed Sponge errors caused by advancements that are granted during server pre/post tick events;
  • Fixed being unable to create ExtentViews;
  • Fixes being unable to create small ArchetypeVolumes;
  • Fixed TileEntity user tracking;
  • Fixed ClickInventoryEvent.Drop.Primary not firing in some scenarioes;
  • Ensured that Vanilla/Mod set game rules affect all worlds, matching mod expectation;
  • Allows old world migration to be turned off using the java property sponge.world.migrate_old;
  • Fixed ordering of calls when recreating Players;
  • Removed copying of DataManipulators to recreated Players;
  • Fixed sweeping attack cause; and
  • Ensured that packets sent by dead players are not processed

You can download these builds from our Downloads page, https://spongepowered.org/downloads

Again, apologies for any issues caused by custom data on player changes. Thanks all!

EDIT: An earlier version of this announcement talked about overriding the toContainer method to avoid the requirement of copying data across during respawns. This was incorrect, and that was my mistake in stating that. All data that you wish to keep on a player over a respawn must be copied over as described. Sorry for the previously incorrect information.

9 Likes