Add 1.18 support as well as support for other versions

[DalekCraft2]

Also, added a translucency tag to blocks.json.

1.14.4 and 1.15.2 do not have completely functional category dumpers yet, but it is fine for now because I doubt that anyone is going to use them soon.

[octylFractal]

Sorry for the delay in reviewing this. Would it be possible to make this more DRY, e.g. having all the dumpers in a common project, with an interface implemented by each version-specific package? That way we don't need to replace things in a million files if we change them,

[DalekCraft2]

Sorry for my late response. How should I handle the common project dumpers, since the existing dumpers each rely on imports from different Minecraft versions?

[octylFractal]

I would add some kind of Identifier-like type, and use that for the RegistryClassDumper/RegistryDumper. Then you can just map to that type in each project. I don't know if it would be worth making the logic for the dumpers also generic by adding more types that act like MC's types.

[DalekCraft2]

Could I ask for an example of what you are describing so I have a better idea of what to do? What I am understanding so far is that you want for me to make the dumpers from each module implement common interfaces, and to not use generics.

[octylFractal]

Yes, I'm using the word "generic" here as the non-technical term. I don't really know what example to show that wouldn't just be doing the refactor, since it should be pretty simple? The main point is to just not have a separate RegistryDumper/RegistryClassDumper in every version.

[DalekCraft2]

But Dumper, RegistryDumper, and RegistryClassDumper all use imports from net.minecraft. How do I separate them without causing errors?

[octylFractal]

That's why I said

I would add some kind of Identifier-like type

By adding types like what is needed, you don't need the MC type anymore.

Seems like you probably need a Registry interface as well, but you can limit that to what we use, and implement it in each version by delegating to that version's Registry.

[DalekCraft2]

So I would create interfaces in the common module, and create classes in the version-specific modules which implement the interfaces and delegate the methods to the net.minecraft classes?

[octylFractal]

It's not strictly necessary for Identifier, since it's really quite simple (you could even copy ResourceLocation from WorldEdit), but yes that is the idea.

[DalekCraft2]

Things have become complicated now as I realize that Registry is an abstract class and is extended several times, so I can not easily delegate to it by extending it unless I was to make delegates for each subclass, and, even then, I am unsure of how I would convert the native Minecraft class instances into delegate instances.

[octylFractal]

I think you're making this too complicated -- we only need a small bit of the API that Registry provides, we don't need to clone its hierarchy. In fact, taking a closer look, we only use registry.get(v), and immediately pass it to getProperties -- so there's no need to even have a Registry type, you could just modify public abstract List<Map<String, Object>> getProperties(Identifier resourceLocation, V object); to instead be public abstract List<Map<String, Object>> getProperties(Identifier resourceLocation); (with the non-MC Identifier, of course), and do the registry lookup in the implementation.

[DalekCraft2]

We also use Registry#getIds() in that same line. What should be done about that?

Oh, wait, I can just replace getRegistry() with getIds().

And I can remove the Identifier delegate by returning the IDs as Strings instead of as delegates.

[DalekCraft2]

I have finished what you asked, though I still need to update the 1.18 module from 1.18.1 to 1.18.2, and I need to get the 1.14.4 and 1.15.2 modules' category dumpers to work.

I need to merge the latest commit on the master branch into it, too.

[DalekCraft2]

I have now noticed that the newer commits of this repository have removed the category dumpers. May I ask about why that was done, and should I remove them from the older ones as well?

Update: I figured out that they were actually consolidated with their respective -TypesDumper classes, but I am keeping them as separate classes for now until I figure out how to make the single-class system work with the core module. In other words, I need to make RegistryClassDumper from the core module use the code from this repository's current revision of RegistryClassDumper without using Minecraft imports at all.