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 BedrockBlock problem)
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
[ ] 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
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:
BedrockBlock
problem)we will also be enforcing mojang's package structure on QM, which has the benefit:
implementation
this implementation will come in three parts: