search

CottonMC / CottonResources

Reference mod for ores, ingots, tools, liquids, and all you can imagine.
MIT License
17 stars 12 forks source link

Ore gen registration #12

Closed LemmaEOF closed 5 years ago

LemmaEOF commented 5 years ago

We should probably do something for mods to be aware of other mods' ore gen. I think it'd be better to not force mods to do gen through us, so maybe having a Map<String ore, String registrar> or something that mods can note to when they register ore gen would be good. Of course it'd be wrapped so that mods can't delete other mods' ore gen, and we could finally use the namespace preference in the cotton config so pack makers could specify which mods they want doing gen, but I think it would be the best option for the mix between unification and not being too hands-on.

cc @Pannoniae @NerdHubMC

Pannoniae commented 5 years ago

It ties into an important design decision -- what does cotton-resources trying to accomplish?

  1. providing a small, common set of ores and try to get mods to use them? (current situation) This method has the most standardisation, but perhaps a bit too much, and it may alienate mod developers, because they don't want to modify their mods

  2. provide a large set of common, similar-looking resources with default generation, so every mod can have its own things without having multiple similar, often different-looking ores, and worldgen with customisable values, but providing good defaults. This doesn't have any forced design direction, so mods use their resources, covering everyone's needs. This has a larger chance of wider adoption, so I support that.

falkreon commented 5 years ago

The system sketched out right now allows mods to passively have data, such as: /data/examplemod/oregen/oregen.json /data/examplemod/oregen/extra_gems.json /data/someothermod/oregen/foo.json I plan on widening the predicate to also accept .json5.

The ore generation enabled by these mods is additively combined. (so if two mods or two jsons from the same mod request the same resource, it generates as if one request was made). A server datapack can enable ores in the same way, and this is approached in the same additive manner.

However, if the server's cotton-resource config has an ore as enabled=false, it does not generate, period. cotton-resources.json5 is the final word.

I'm still considering what shape this json should take. It should be possible to enable a resource just by its ID, and if so, either another mod's configuration should be chosen, a builtin should be chosen, or a default should be made and chosen. But on the other hand, you should be able to specify detailed spawn info for a blockstate that we don't already know about.

falkreon commented 5 years ago

I could register a PrimitiveTypeAdapter for it but that'd require a lookup against potentially incomplete data, so I'd want to load in strings and then resolve them in a second step.

falkreon commented 5 years ago

Oregen / ore voting is live, so this is wrapped up I think.