Recommended Build v7.1.9 released

Recommended Build v7.1.9 released
@dualspiral wrote:

Hello everyone.

What, another recommended build, I hear you cry? Why yes, today we are pleased to bring you another recommended build! This build brings more stability over custom data and the long awaited Mixin 0.8 update. We recommend that plugin developers that use Custom Data have a read through this in its entirety, we apologise for any confusion caused.

Player-based Custom Data


You’re probably wondering why we needed to fix Custom Data again in this build. It all comes back to persistence.

In the previous RB annoucement, I originally stated that to persist data, you would have to override the toContainer method, as that was my general view of the intent of custom data. However, some of you noticed that actually, this wasn’t the case and after internal discussions, I altered my announcement accordingly. But, as we discussed this further, we ended up having a long (and productive!) discussion about what we need to do in API 7.x builds, and to make sure we make any invasive corrections for API 8 builds once we start producing those.

We are sorry for the trouble that this may have all caused, but we’re now settled on what will happen.

The Technical Explanation - Why This Was Such A Problem


This is mostly background reading - you may want to skip this and go to the solution.

The centrepiece of the entire problem is to do with how Minecraft handles players when they die (and on the occasional teleport). When you die, the server creates and spawns in a new you. This new you is a blank slate, as if you’ve just joined the server. Forge mods have had to deal with this for a while now and generally copy over any old data it wants to keep, and that is what we were asking you to do from 7.1.8. It makes sense from an entity standpoint, all other custom data holders that were entities were the same. Data has generally been regarded as bound to an entity (it disappears when you break a sign, for example), when you recreate a player, you are recreating the entity and so to be consistent, it would make sense for the data to disappear.

However, this did not work out nearly as well as we’d hoped, and we uncovered another serious issue. When you override the toContainer method in DataManipulators, we use this to save this data to your player’s NBT data store when the server does a save. That’s good, you want the data to persist. When we create and spawn the new player in, we read the NBT data store and retrieve the data manipulators.

The problem is that creating the player on login and creating the player after a death are effectively the same thing. As a result, we were reloading the data manipulators from NBT, which may have been old. Our implementation of how we handle custom data was broken any way you looked at it, the issues had just been papered over by various small fixes and, when we took one of the fixes away (which we needed to do to fix a very severe issue), all the problems of custom data were suddenly exposed.

There was also the consideration of user expectation. It was pointed out to me that we haven’t actually fully documented how persistence was meant to work, leaving it open to interpretation. Nearly all expected persisted data to remain across deaths. That burned us and I can only deeply apologise for the inconvenience that this has caused. We are now putting it right and we will be ensuring that it is crystal clear as to what will happen with data persistence in API 8 and beyond.

The Solution (for 1.12.2 builds/API 7.x)


After much discussion, we’ve decided that in order to fix this in the least invasive, least resistive way possible, we now will copy all custom data across from old player to new player automatically in the future, whether or not you’ve overrided toContainer. The amount of work that we would need to do to fix this to depend on toContainer would inevitably require API changes (possibly breaks) to do properly and we would much rather be focussing on getting 1.14.4 builds out of the door.

Plugin Developers: If you are currently copying your data across now, that’s fine, that doesn’t actually need to change because all it really is doing is duplicating what we have already done for you. If you want the data to drop off after death, then you should take steps to ensure it’s removed.

Mixin 0.8 Upgrade


We have now updated the Mixin library that we use in SpongeForge and SpongeVanilla to 0.8 from 0.7.11. If running SpongeForge with mods, you may find you need to rename your SpongeForge jar to start with aaa if other mods use an older version of Mixin to ensure Mixin 0.8 is loaded. This will fix some of the class loading errors you may have experienced - including one I kept seeing for net/minecraft/command/EntitySelector.

If you are a user of the Mixin platform and want to know what Mixin 0.8 is all about, Mumfrey has written release notes for 0.8, explaining the changes and what you may need to do for this update: https://github.com/SpongePowered/Mixin/wiki/Release-Notes---Mixin-0.8

A Note on Tile Entities and Mod Compatibility


One of the other things we attempted to fix during this cycle was to fix our interactions with mods when they change the game world and then immediately inspect the state. However, our fixes to this behaviour first introduced disappearing furnaces, then introduced a serious dupe bug that impacted Vanilla. I therefore reverted these changes in order to ensure that the latest builds did not have this break in as there were many of you looking to use the latest builds for their other fixes.

We will be fixing this for the next recommended build, which may come soon if we solve these issues. Thank you for your understanding.

Recommended Build v7.1.9


So, with that out of the way, we have our next RB available for your server needs. The changes are:

• Fixed Custom Data persistence (as described above)
• Updated Mixin to 0.8
• Fixed some Subjects not implementing getSubjectReference
• Fixed some command invocations that were executed from a sign not being recognised as a SignSource
• Fixed issues with CraftItemEvent mutation/cancellation causing item deletions or incorrect outputs
• Fix async scheduled tasks stalling

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

A Note on Future Recommended Builds


Something that I also didn’t mention in the last update announcement is that I’m taking over handling the RB process for our LTS builds - that’s 1.12.2 right now! This is to free up @Zidane and @gabizou to manage the 1.14.4 update process more effectively and not worry about 1.12.2 so much. With a bit of luck, it’ll go more smoothly as time goes on!

My plan is to release RBs on about a monthly timescale. Of course, there will be times where we skip a build (if there hasn’t been much in the way of commits to the API 7 builds), and times where we release one because of significant fixes and updates. My aim is to release a recommended build at least once a month, targetting the end of each month, with interested server owners wishing to test builds for us being notified of new builds a week before or so. My process here is not yet set in stone and we are still working out the finer details on such processes, but expect slightly more regular RBs as we move forward.

If you wish to be notified in Discord when we need help testing an RB, please request to join the Release Candidate role. There are instructions in the #roles channel, but if they don’t work, please just ask us to add you in there. Similarly, if you are in the Release Candidate role, but no longer want to be part of it, ask us to remove you.

The other side to this is that just after an RB, I will be authorising riskier changes to hit the stable-7 codebase if the need arises - this happened with the Mixin 0.8 upgrade where we found a few issues after merging. This will allow us time to test and fix any glaring problems well before we start looking at releasing an RB. RBs therefore represent stable releases that production servers will run, the “latest” builds may contain destabilising changes that have hit stable-7 to get some testing in.

There will be more from me in the coming weeks and months.

Until next time - thanks all!
​

Posts: 2

Participants: 1

Read full topic