Open MauveCloud opened 3 years ago
Why XML? JSON\YAML\INI\Forge-style are more readable.
@Techlone @leagris I hadn't actually firmly decided on XML. The main consideration was to allow variable input and output lists for the recipes potentially including NBT tags, and names to distinguish between things like duration and EU/t without relying purely on argument order (I'm fairly sure there have been some bugs caused by that). XML has the advantage of already being supported by the standard Java API.
JSON is a good suggestion, since it is already used by vanilla Minecraft (for resource packs at least, data packs in newer versions, and possibly other places I'm less familiar with)
YAML might work, but would probably require adding extra libraries to the project.
I'm not so sure INI or Forge-style would be more readable in this case. If you want me to consider these, could you please provide some examples of what GT machine recipes would look like in these formats?
Update: I haven't actually started on the "read recipes from file/asset" part yet - first I want to make sure the change to the foundation to allow ore dictionary inputs (or even alternates that don't share an ore dictionary entry, and maybe even allow different stack sizes depending on which item is used, though I'm uncertain how well I'll be able to get the second half of that working) doesn't break things, and I'm having some difficulty with the Microwave, Printer, Recycler, and Large Chemical Reactor.
@Techlone @leagris I've opened a PR for this, #1583, though still WIP, in case you want to take a look at what I've got so far and maybe help test it.
Based on leagris's comment in #1546:
I plan to adapt from EnderIO's xml recipe system (note that Ender IO is public domain), which will: