[1.14.4] [SOLVED] Prevent Custom Configs From Being Removed

[saxon564]

The problem I am currently having is how to prevent the NightCore config system from over-writing config options the user enters that are outside the scope of the normal config options. I have several mobs which I offer spawning config options for, and would like to be able to offer the ability for people to set config options per biome.

 

By default this is what the config files will look like for most of my mobs.

[Spawning]
	Min_Spawn_Light_Level = 0
	Can_Spawn = true
	Min_Spawn_Temp = 0.0
	Spawn_Probability = 10
	Min_Spawn_Group_Size = 2
	Biome_List_Type = "Blacklist"
	Max_Spawn_Group_Size = 3
	Max_Spawn_Temp = 1.0
	Max_Spawn_Light_Level = 7
	Biome_List = "[List of Biomes mob may or may not spawn in]"

 

When someone adds their own options it would look more like this:

[Spawning]
	Min_Spawn_Light_Level = 0
	"Can Spawn" = true
	Min_Spawn_Temp = 0.0
	Spawn_Probability = 10
	Min_Spawn_Group_Size = 2
	Biome_List_Type = "Blacklist"
	Max_Spawn_Group_Size = 3
	Max_Spawn_Temp = 1.0
	Max_Spawn_Light_Level = 7
	Biome_List = "[List of Biomes mob may or may not spawn in]"

	[Spawning.minecraft_hell]
		Spawn_Probability = 5
		Min_Spawn_Group_Size = 1
		Max_Spawn_Group_Size = 1

 

The code I currently have to build the configs is this:

public static void loadConfig(ForgeConfigSpec spec, Path path) {
  final CommentedFileConfig configData = CommentedFileConfig.builder(path)
    .sync().autosave().build();

  configData.load();
  spec.setConfig(configData);
}

 

As far as I can tell, this is the basic most commonly used code for building the config files.

 

The problem is that with the current system when the game boots up it will remove everything that falls in 'Spawning.Biomes' unless it is set inside the code, which will only be the case for a few mobs. Currently, the only way I can think of around this is to iterate through each biome and set a blank area for the config options which would increase the server load considerably since it would cycle through all the biomes a total of 2 times for each mob. Once while setting up the configs, and once more while registering the spawns for each mob, which is something I don't want to do if I don't have to.

Edited November 4, 2019 by saxon564

[Drizzs]

When the game boots up. Do you mean in your dev instance? In your dev instance i believe it sets your configs to default every time because you build every time. So i suggest you try to load it up in a real environment. Also, where is the rest of it? There should be some kind of Config handler that has your builder and the actual variables being set by your configs.

[Animefan8888]

4 hours ago, Drizzs said:

In your dev instance i believe it sets your configs to default every time because you build every time.

No it doesn't because building doesnt include the config file that is only generated when the mod runs and it isn't there.

 

13 hours ago, saxon564 said:

he problem is that with the current system when the game boots up it will remove everything that falls in 'Spawning.Biomes' unless it is set inside the code, which will only be the case for a few mobs.

I think the only way around this is to make it an array that is there for all of your entities. Basically it cant look all fancy like it does now. Unless I'm missing something. Or of course you can always create your own system to load these.

[saxon564]

2 hours ago, Animefan8888 said:

I think the only way around this is to make it an array that is there for all of your entities. Basically it cant look all fancy like it does now. Unless I'm missing something. Or of course you can always create your own system to load these.

Thats what I'm afraid of as my best option. I can get it to generate the file to look like the second example, in fact the example is how I am currently generating my configs while testing. Only thing is that if I were to manually add [Spawning.minecraft_end] it would just remove it. There is one other potential issue to address after this, but that issue is dependant on being able to do the configs the way I want to do them.

 

I do see that there are different writing systems when building the files. But neither of the others sound like they would be a step in the right direction. One if them just overwrites the entire file and the other ands onto the end of the file.

[saxon564]

After some playing around with it, I have learned that forge rewrites every config file every time it boots up and will replace the internally supplied values with values from the previous file. Because of this, when a user adds something outside of the norm, what the user adds never gets read and put into the new file, therefore it ends up getting deleted. Now knowing this is making me wonder if there is a good way to check for the existence of those values and pass them into the new file...

 

My previous layout had an extra layer so it read 
 

[Spawning]
	Min_Spawn_Light_Level = 0
	"Can Spawn" = true
	Min_Spawn_Temp = 0.0
	Spawn_Probability = 10
	Min_Spawn_Group_Size = 2
	Biome_List_Type = "Blacklist"
	Max_Spawn_Group_Size = 3
	Max_Spawn_Temp = 1.0
	Max_Spawn_Light_Level = 7
	Biome_List = "[List of Biomes mob may or may not spawn in]"

	[Spawning.Biomes]

		[Spawning.Biomes.minecraft_hell]
			Spawn_Probability = 5
			Min_Spawn_Group_Size = 1
			Max_Spawn_Group_Size = 1

 

I am wondering on the possibility of checking if Spawning.Biomes is empty and if not, parsing through the sub-groups and values to pass them into the new file. I am not sure if this is possible or would work as it would mean I would need to be able to actually read the config file on demand instead of just reading values stored as variables inside my class.

 

Does anyone have any thoughts on how possible this may be? This leads into the second issue I mentioned in an earlier post, which is reading the config files on demand since I will not know what the user puts in therefore will not be able to save it as a variable with this format.

Edited November 1, 2019 by saxon564

[saxon564]

I found that what is causing my issue is within the code of forge itself. Inside ForgeConfigSpec is a private correct() method, and within this method lies this code:

// Second step: removes the unspecified values
for (Iterator<Map.Entry<String, Object>> ittr = configMap.entrySet().iterator(); ittr.hasNext();){
	Map.Entry<String, Object> entry = ittr.next();
  if (!specMap.containsKey(entry.getKey()))
  {
  	if (dryRun)
    	return 1;

    ittr.remove();
    parentPath.addLast(entry.getKey());
    listener.onCorrect(REMOVE, parentPathUnmodifiable, entry.getValue(), null);
    parentPath.removeLast();
    count++;
  }
}

Which removes all the user generated config values. On a personal level I feel that we should be able to pass a boolean on whether this should be used or not, but I do see the importance of cleaning up irrelevant information to limit the size of the file and improve load times.

 

EDIT: The only possible work around I can think of for this is to copy and paste most of the ForgeConfigSpec file and remove that section of code. (This is exactly what I did to confirm my suspicion) But I do not plan on actually doing that for a solution because it is bad practice and there isn't much of a change I would do to it that would allow me to make it my own.

Edited November 2, 2019 by saxon564

[saxon564]

I figured it out!  After lots and LOTS of digging, I was able to use to same type of system that was removing the configuration options to add them to the internal configuration. It isn't pretty and I am sure it could be done better, but this is the first way I could find to do it and until I am a little more comfortable with this system, unless someone else has suggestions it is probably going to remain the way it is for a while.

You can see my code on this github page.

 

What it is doing is cycling through the categories in the configuration files until it finds the "Spawning" category, then it cycles through everything in that category to fin the sub category "Biomes." From there it once again cycles through each biome in that category and adds them to the map I have to hold the values for reference and also adds them to the configuration file I am generating.