Expansion to codec

[liach]

Now Datafixerupper introduced a type of thing called codec, which is encoder and decoder. They also have some sort of map codec, which start the encode/decode operations from object type (json object, compound tag) than from any type of data.

Imo we can start extending these codec from extending the map codec of vanilla objects. map codec themselves are immutable, but we can create new map codecs from existing codecs and add extra handled fields fairly easily, and then place our new codec objects to the vanilla fields. That would be compatible to all vanilla or even patcher users as long as we keep reference to the previous instance of that map codec field and delegate to it for fields we do not handle.

[sfPlayer1]

It is unclear what you are proposing, please provide a reasonable example use case.

[liach]

For example: Dimension has a few fields like

{
"convertsPiglins": true,
"ultrawarm": true,
"someOtherField": "Some value, etc."
}

Now mods may want to add extra values, like

{
"oilExplode": false
}

A new map codec can handle such extra fields.

We can create a new map codec that scan for mod-handled fields like oilExplode after we get a preliminary dimension object from delegating the input data to the original map codec. These fields will have default values in order to guarantee vanilla compatibility.

[haykam821]

How would multiple mods attempting to add oilExplode work? Maybe it could use a sub-object such as:

{
    "convertsPiglins": true,
    "ultrawarm": true,
    "someOtherField": "Some value, etc.",
    "fabric": {
         "modid": {
             "oilExplode": false
         }
    }
}

[liach]

The base api will just offer the ability to add extra fields to map codecs, so it won't enforce you to move to like a fabric subobject.

@haykam821 however, we won't use the base api directly. in my plan, we will have a base api that extends any map codec, and a secondary api that handles dimensions' codec field registry, etc. for different types of things with map codecs. It is the secondary api that create fabric subobject and prevent clashes, etc.

[i509VCB]

I am linking this gist which does have a proof of concept, however globally applying codec modifications everywhere would require a hard fork of DFU or some weird mixins using the prelaunch hacks. Ideally we could supply a sort of "optional field registry" for some objects that are created via codecs; but it would require us to pick and choose what to support there.

https://gist.github.com/kvverti/dec17e824922e1974313b8beadc621c5