Skip to content

First pass at allowing addons to register/remove ore veins#173

Merged
serenibyss merged 12 commits intomasterfrom
worldgen-addition
Dec 15, 2021
Merged

First pass at allowing addons to register/remove ore veins#173
serenibyss merged 12 commits intomasterfrom
worldgen-addition

Conversation

@ALongStringOfNumbers
Copy link
Copy Markdown
Contributor

@ALongStringOfNumbers ALongStringOfNumbers commented Oct 3, 2021

What:
This PR attempts to add method for addon mods to register/remove ore vein definitions and easily add/remove files to the gregtech worldgen folder.

For this, a few new helper variables were introduced:

  • definitionMap is a Map<String, OreDepositDefinition> with the keys being the relative path from the worldgen folder in the gregtech config folder to a registered definition, with no leading separator. This is essentially OreDepositDefinition.getDepositName(). The values in this map are the registered ore definitions
  • removedDefinitions is a list of all definitions that have been marked for removal by addon mods.
  • addonRegisteredVeins is a list of all definitions registered from addon mods via addVeinDefinitions()

Removing existing veins

To remove existing veins, addon mods simply need to call removeVeinDefinitions(OreDepositDefinition definition) after Gregtech has initialized its own ore veins and the ore definition at the existing path will be removed if there is a matching definition in registeredDefinitions.

The addon mod then needs to call WorldGenRegistry#reinitializeRegisteredVeins() to delete the file from the existing world gen folder.

An example of this would be adding the following lines in GregTechMod.java after the WorldGenRegistry has been initialized at line 160.

   WorldGenRegistry.INSTANCE.removeVeinDefinitions(definition);
   try {
       WorldGenRegistry.INSTANCE.reinitializeRegisteredVeins();
   }
   catch (IOException e) {
       //log possible error here
   }

It should be noted that this should and will fail if a modpack maker removes the existing definition, or changes the filename away from what the addon mod expects the name to be.

I am considering making registeredDefinitions public, so that addon mods can easily get to the list of all registered definitions so that they can easily pass the definition to the remove method. I would like some feedback on this.

Adding new veins

To add new veins, addon mods will have to pass the OreDepositDefinition to WorldGenRegistry#addVeinDefintions(OreDepositDefinition definition) either before GTCEu does its vein initialization (This needs testing, it is just my hypothesis right now), which should not require a call to WorldGenRegistry#reinitializeRegisteredVeins(), or after GTCEu has initialized its veins and then call WorldGenRegistry#reinitializeRegisteredVeins().

The approach that I took for this method does enforce that OreDepositDefinition.depositName needs to be the relative path from the worldgen folder to the definition file with no leading separator.

As a note, addon mods will not be able to add veins to the same file location as existing ore definitions.

This does bring up a point that I want to try and enforce as a bit of organization however. Addon mods registering veins should add all the veins that they register to a new folder in the worldgen folder in the gregtech config file named after their mod id, and then with subfolders for the different dimensions. This will make it much easier for modpack makers to see which veins are being added by the various addon mods.

Outcome:
Allow addon mods to easily register their own ore veins and provide a method for addon mods to remove existing ore vein definitions.

Comment thread src/main/java/gregtech/api/worldgen/config/WorldGenRegistry.java Outdated
@serenibyss serenibyss merged commit 17ffcb8 into master Dec 15, 2021
@serenibyss serenibyss deleted the worldgen-addition branch December 15, 2021 06:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants