MinecraftDev
MinecraftDev copied to clipboard
minecraft-dev
Repo-based creator templates
Why?
The main motivation is to offload the templates to a separate repo, which are updated independently when opening the creator for the first time in the IDE session. This means templates can be easily updated and tested in real time, no IDE restart (thank goodness.)
Also the creator file template settings became really cluttered and the UI is quite clunky sometimes. Now the templates are stored in a flat dir (zip archives are also supported.)
This also opens the door for anyone to create their own templates, and makes maintaining our templates so much easier (well, I might be biased on that.)
Oh yeah and it also gets rid of some "magic" code gen that breaks embarrassingly often for obscure reasons, so the fabric creator won't have this nasty issue where the main class is incomplete.
Overview
The templates are still Velocity templates, but they are now put together by a JSON file describing a specific template. See the templates repo at https://github.com/minecraft-dev/templates.
Template descriptors mostly contain properties (most of which are displayed in the creator UI) and the template files.
All file templates have access to all the properties in the descriptor. Some string in the descriptor also have access to properties (file template, destination and condition.)
Properties cannot reference properties declared after them (they are setup one by one in a single step.) I chose this limitation so that we cannot easily cause recursion.
Some properties will be of a custom type, or expose an existing class of the plugin, all of those should be marked with @TemplateApi and we should pay attention to not break the source compatibility of those classes without a good reason.
~Used templates are remembered (only the path, not the files contents), there's no way to register them permanently (this could be added to the main settings eventually)~ Template repositories can be configured in the main configurable, recent templates are no longer remembered.
I've only spent about 5 minutes looking at it so far, but one immediate question I have, is how are you going to make the options and labels translatable?
Yeah I've been thinking about it, at least for strings in our resource bundle. Unsure what would be the best way to handle translations provided by the repository itself.
I also noticed that in the template repository, Fabric mod ids are validated to a minimum length of 1, whereas on Fabric mod ids have to be at least of length 2.
I'll look into improving the template selection, maybe split plugins and mods, and move the providers to the settings so we can have repos saved there and displayed in the creator.
This is a huge undertaking and I'm so grateful for the people contributing to making this happen. I'm looking forward to this PR being merged :)
Hi, I've just tried this out, but it's saying there's no templates available:
Do you have any idea why this might be?
@Earthcomputer Oh that's not supposed to be like that by default. In the settings page there should be a table of template repositories with a Built In default repo. I'll look into it.
Just a couple of things:
- Use Mixins should be enabled by default on the Fabric and Architectury platforms, and disabled by default on Forge and NeoForge. I've noticed that the value of this checkbox is connected on all platforms, maybe it should be disconnected (stored with a different key).
FabricApiandArchitecturyApishould not be in pascal case.- While fetching versions from the internet, there could be an
AsyncProgressIcon. In the old creator this is done insideAbstractLatentStep.
Fixed all of these.
Also I forgot to answer to your question about the old wizard. I plan on keeping it until the end of the year, so people who have issues with this new one have a "backup". Guess I should add a warning that it will be removed at some point in the future in the UI.