Feature: remapping mod apis

[solonovamax]

This is a feature I just randomly thought of while working on smth for Silk.

The issue is that it wraps the minecraft api, and some of its functions/classes/etc. are named such that they reflect the mappings used. Silk uses mojmap. However, I have a project where I wish to use yarn and I would like if the functions/classes/etc. reflected the yarn names.

Take a function such as this one:

fun creativeModeTab(displayName: Component? = null, builder: CreativeModeTab.Builder.() -> Unit): CreativeModeTab {
    val itemGroupBuilder = FabricItemGroup.builder()
    if (displayName != null)
        itemGroupBuilder.title(displayName)

    return itemGroupBuilder.apply(builder).build()
}

In yarn, CreativeModeTab is instead named ItemGroup. I would like to be able to use a function named itemGroup instead of creativeModeTab, as it reflects the yarn class name.

So, a theoretical system could look something like this:

@RemapName(
    mappings = [
        Mapping(mappings = "net.fabricmc:yarn", name = "itemGroup"),
        Mapping(mappings = "foo:bar", name = "someOtherName"),
    ]
)
fun creativeModeTab(displayName: Component? = null, builder: CreativeModeTab.Builder.() -> Unit): CreativeModeTab {
    val itemGroupBuilder = FabricItemGroup.builder()
    if (displayName != null)
        itemGroupBuilder.title(displayName)

    return itemGroupBuilder.apply(builder).build()
}

this essentially says

• By default, this function is named creativeModeTab.
• When the net.fabricmc:yarn mappings in use, rename this function to itemGroup.
• When the foo:bar mappings are in use, rename this function to someOtherName.

Then, for consumers of the api, the mod would be remapped and have creativeModeTab changed to itemGroup if they're using yarn mappings. Then, if they used itemGroup anywhere, it would be remapped to creativeModeTab as part of the remapping process.
So, creativeModeTab would be the "binary" name of the function, and the remapping would just be sugar for people consuming an api using different mappings.

The annotation can also be applied to classes, fields, and also possibly parameters. It would work the same for each of those.

[jpenilla]

You can publish a mappings file to maven and then let users consume it using layered mappings.
You would have creativeModeTab as intermediary and itemGroup as named with your example, iirc.

[solonovamax]

You can publish a mappings file to maven and then let users consume it using layered mappings.
You would have creativeModeTab as intermediary and itemGroup as named with your example, iirc.

How would you go about doing this?

Is there any semi-easy way to do such a thing?

Also, an alternative to the annotations could be creating an additional source set only for storing the mappings, which loom would then auto-include if the dependent mappings are present.

[modmuss50]

I think this is a good idea, and should be quite easy to do if not already possible with layred mappings. I dont think there is anything stopping a 3rd party creating a set of mappings for common FAPI API classes. If this is to become a first party thing most of the work will likely be around finding a good way for people to contriubute and maintain this set of mapping.

I dont think it needs to be over complicated by annotations or anything.

[Juuxel]

For what it's worth, Enigma is pretty easy to set up to do this. Let's say the mod is in Yarn and you want Mojmap-flavoured mappings for it.

• Remap the mod classes to Mojmap and set that as the "obfuscated" jar.
• Make the mapping layer using Enigma like you would for Minecraft itself.
• Export it as Enigma/Tiny mappings (both work for this) and use them as a Loom mapping layer.

[solonovamax]

I dont think it needs to be over complicated by annotations or anything.

tbh I was just proposing annotations as a convenient way to define them, while also having it tied to the method itself (so you won't end up like refactoring smth and you end up with a mapping for a method that doesn't exist)

I think this is a good idea, and should be quite easy to do if not already possible with layred mappings. I dont think there is anything stopping a 3rd party creating a set of mappings for common FAPI API classes. If this is to become a first party thing most of the work will likely be around finding a good way for people to contriubute and maintain this set of mapping.

also, my main usecase was actually remapping other libraries to fit in more with fabric-api/yarn, but remapping fabric-api to be more like mojmap could also be a usecase for other possibilities

[modmuss50]

To get you started try creating a mappings file like so:

tiny    2    0    intermediary    named
c    com/exmple/OldName    com/example/NewName

And then you should be able to use this in loom like so:

mappings loom.layered {
   mappings "net.fabricmc:yarn:${project.yarn_mappings}:v2"
   mappings file("override.tiny")
}

Using Enimga should work to make this much easier in theory, but writing it by hand is a quick way to test the concept.