In Control!

In Control!

96M Downloads

Datapacks that act like extension configs

SimulationOfMario opened this issue ยท 3 comments

commented

Hi! I like how useful this mod is!

I'm not sure this functionality exists, and it would be great to share any datapacks I want about this via modrinth.

Is there any way I could make it so that if I create a datapack, it's used to "extend/edit" the InControl configs?
I suppose it's better for them to act as an extension after what's written in the game configs, so as not to overwrite and thus stack multiple datapacks.

This would be really useful for 1.20.1. I have some spawn rules together that might be interesting pre-made datapacks for people.

commented

That's not really very easy to do as rules depend so heavily on each other. One set of rules might give zombies 10% chance to spawn on the surface and another one might give them 30% chance to deny them in caves and surface but only on plains biomes. How do you properly combine those? Also rules typically contain fallbacks to deny everything except the things that have been allowed. Those kinds of rules are not possible to combine like that. Remember that order of rule execution is important. How do you define that with datapacks? So in short, this is not really feasible

commented

Well, but you can make it so that if you create a spawn.json file inside a datapack, it is the extension of what is already in the normal config.

I'm not sure what rules could cause these problems you mention, but perhaps there is some correct way to handle this.

It's something like if each datapack you add + the original config act together with all the spawner, areas, spawn, event, etc.

I see a possibility that it can be done even if it has to follow an order/rules.

commented

That's the thing. It's extremely hard to make a set of config files that correctly extends another set of config files because they will always interact with each other in ways that are not intended. Let's give an example. A very common way to handle a spawn rule set that allows mobs to spawn in a certain biome but not in others is something like this:

[
  {
    "hostile": true,
    "biome": "minecraft:desert",
    "result": "allow"
  },
  {
    "hostile": true,
    "result": "deny"
  }
]

Then let's assume you add a datapack that (for example) wants to limit spawns to 20 hostile mobs in another biome. That's a totally different rule:

[
  {
    "hostile": true,
    "maxcount": 20,
    "biome": "minecraft:plains",
    "result": "allow",
  },
  {
    "hostile": true,
    "result": "deny"
  }
]

Both config files are perfectly valid but there is no consistent way to know for In Control in what order to execute these rules when you mix both. If you execute the first ruleset first then mobs will spawn fine in deserts but there will be no spawns in plains because the second rule denies that. The second ruleset doesn't have a chance to work. If you do the second ruleset first then you have the same problem with the first ruleset.

Because of the way these rules work it's really not possible to combine them like that