Code Generation

[Machine-Maker]

Currently includes generated key holder classes for types used in the Registry Modification API

- [x] Add TypedKey type that has a generic for the api type, has a Key and RegistryKey field
- [ ] https://github.com/PaperMC/paperweight/pull/197
- [x] ~~Hide generated classes from javadocs?~~ **No**
- [ ] Should `TypedKey` be interned like nms `ResourceKey`?

I think its acceptable that this is a manual thing, and the generated code just goes into a patch file, rather than being created for each applyPatches. Once we have source in repo, it won't be a large patch. Its also just one less build step

---

The reason why this is needed, and really should only be used in conjunction with the Registry Modification API, is that you have to specify the key of any value you want to modify, but you cannot use the API object itself to get the key, like for GameEvent. If you wanted to modify the range of a specific GameEvent, you can't get the key from GameEvent.BLOCK_OPEN.getKey(), because the Registry Modification API runs before those objects can be created. So doing that will throw an exception. So we have GameEventKeys which will hold some sort of TypedKey object that you can use instead. Of course for custom ones, you can create your own keys.

[Owen1212055]

I'm curious, is there any better way to have auto-generated files in some sort of their own module that can be merged with the API one, therefore doesn't need to use the patch system? Not sure tho.

[MiniDigger]

dependencies are gonna be fun if we do that we could have a different source set tho I guess and commit the files from that source set? generally agree that this is a bit meh

[electronicboy]

Looking at this so far, no real qualms against it, and generally looks like what I'd expect in regards to output, etc; only thing is the create methods, I'm guessing that there is still a bit of wiring up to do there