A way to upgrade old NBT data by plugins

[tal5]

Is your feature request related to a problem?

Before the PDC API was a thing, a lot of plugins stored data (such as custom item IDs) directly in the item's NBT/now the custom_data component.
Nowadays the PDC API would be the way to do this, but any plugin that used to store data directly in NBT wouldn't ever be able to migrate from that, as old items could be laying around anywhere.

Describe the solution you'd like.

An "NMS API" (like the connection one for example) to let plugins register DFU fixes for their custom data, so that they are able to properly switch to modern options like PDC.

Alternatively if you wouldn't want to directly expose the DFU (and seeing as most plugins' use cases will likely be stuff like a string for custom item IDs), a registerMove("oldNbtKey", "newPdcKey") sorta setup could also work if possible (and maybe even be in UnsafeValues instead of NMS).

Describe alternatives you've considered.

Less ideal, but if the API had any way to get & set the custom_data component (maybe with adventure-nbt in UnsafeValues or something), that would also help this case, as plugins wouldn't need direct NMS usage to manage their custom data anymore.

Other

No response

[electronicboy]

One general big issue is that DFU only applies to upgrades of a data version controlled by mojang; i.e. you wouldn't be able to apply it reliably to existing worlds unless you managed to get them to install it before they updated their server

[tal5]

One general big issue is that DFU only applies to upgrades of a data version controlled by mojang; i.e. you wouldn't be able to apply it reliably to existing worlds unless you managed to get them to install it before they updated their server

Yeah that's a downside sadly, but seeing as it's more-or-less the only solution I feel like people would be fine with adding it into their plugin and only making the actual code changes after an MC version change (unless I'm missing something and it doesn't work like that?)

[mbax]

As a plugin dev, if I were in this situation, I imagine I would be doing the following:

• My plugin already would be refusing to load on newer MC versions than it recognizes, because of NMS-poking being dangerous.
• On a new major release, such as 1.22 for our current time of talking, I would use this API to ensure all chunks migrate cleanly.
• I would then leave this migrator API usage present for at least several years before even considering removing it.

I only see this having downsides for devs who have code that recklessly assumes things behave the same across versions if the code still runs.

[electronicboy]

The problem is that we don't have a mechanism to say "this plugin requires X version of MC and we should blow up initialization if it doesn't", that means that your players are going to update their servers and anything that loads in between them starting on the new version and loading up the updated version of your plugin is going to basically be lost, so you'd still be maintaining logic to have to deal with the old data; The modding ecosystem is generally much more tightly defined against MC versions so has a real advantage there in terms of making sure that people upgrade properly

An API for moving custom_data stuff into the PDC does sound fine, it would just require somewhat fairly early registration support in oder to allow people to deal with data that might load before plugins have a chance to register