QuiltMC
move QM onto a mojmap base
description and motivation
as previously suggested by @LambdAurora, we will be moving QM onto a mojmap base to improve the mappings and compensate for the small size of our team. this means that all entries in QM will be mojmap unless they are manually mapped by our team. this will have a couple benefits:
- will help us maintain faster and higher completion
- will reduce the divergence between QM and mojmap, as we will always see the mojmap version before mapping an item
- this will make QM better for devs who are used to mojang names, and keep us more in line with mojang intent (permanently resolve the
BedrockBlockproblem)
- this will make QM better for devs who are used to mojang names, and keep us more in line with mojang intent (permanently resolve the
- will resolve #396 by obseleting layering with moj
we will also be enforcing mojang's package structure on QM, which has the benefit:
- access remapping will no longer be needed with QM, simplifying usage on neoforge
implementation
this implementation will come in three parts:
- [ ] downloading mojmap in this repository to be passed into https://github.com/QuiltMC/quilt-enigma-plugin for name proposal. i will be implementing this after #645 is merged
- [ ] package name proposal. we will create a name proposal service that proposes a name that is a combination of the mojang package and the QM class name. eventually, we will make sure that the directory structure of this repository matches mojang's packages, but the implementation details of this are not yet decided.
- [ ] base name proposal. a name proposal service will be created that proposes mojang names for all fields, classes, and methods. it will have the lowest priority of any proposer
simple! we want to focus on our own names, while her project is aimed at fixing problematic mojmap names.
one more unsolved tech consideration here: ideally, the package names would be saved in the main mappings, unlike all other proposers. this would keep the file structure of the repo matching the package structure for the mappings. my idea for this is simply to add a false-by-default boolean in the service for whether to ignore writeProposedNames in MappingSaveParameters
one more unsolved tech consideration here: [...]
after putting some thought into this, I've decided the best method is simply to add a bypassChecks boolean to allow setting the token type of proposed mappings to deobf. i've implemented this in https://github.com/QuiltMC/enigma/pull/240, and made sure to include javadoc telling you to under no circumstances use it.
