Is your feature request related to a problem? Please describe.

This is my /config/OpenTerrainGenerator/Config.yaml, and it works absolutely perfectly when the player uses the vanilla world gen. However, if they decide to use one of the OTG presets instead, the dimensions don't exist, which breaks everything.

Describe the solution you'd like

A way to make it use the dimension settings regardless of the chosen profile

Describe alternatives you've considered

A way to force a specific preset to be used, though I would rather the other option. This one would make it so you can't generate your regular overworld with Biome Bundle, and you'd only be able to use it for your base pretty late in the game.

Description aka Additional context

I'm using Advanced Rocketry to make planets out of the dimensions. Link to its config here.

Hey @aaronhowser1 , I'm not sure I understand what you intend to do. You can include config yaml's in the config/OpenTerrainGenerator directory. For each config, if a user creates a new world via the world creation menu, if the preset chosen as the overworld is equal to the preset for the overworld in the config, that config's dimensions are added by default in the world creation menu for the new world.

This way, you can package one or more configs with a modpack, so that when players create a vanilla world (and overworld preset is null in one of the configs), it automatically adds any dimensions from that config. When a player creates a new world via the OTG world creation menu and selects a specific preset, it checks the configs to see if there's one with the preset defined as the overworld, and automatically adds the dimensions in the UI.

That should allow you to do what you want I hope? If not, please join us on the OTG discord so we can discuss how configs work atm and if what you want should be possible.

*Need to confirm btw if multiple .yaml files work, or you have to combine them in 1 yaml.

For posterity

*By the way, should you want to disable the OTG world creation menu (and only have the vanilla world creation UI for SP), you can add "ShowOTGWorldCreationMenu": false to the root node of your config.yaml. This only works if the config is targeting a vanilla (non-OTG) overworld.

Hmm, here's a problem. If you start with a BBOP world, for instance, you cannot make another BBOP dimension. That means the BBOP planet wouldn't work, since it doesn't have an associated dimension.

That is a limitation atm, you can only add each preset as a dimension once. The OTG world creation menu has a clone function for presets though. You could also include the same preset twice, and name one xxx-Overworld and the other xxx-Dimension, if you like. Ofcourse I wonder if anyone would really need the same preset in 2 dims. If someone starts with a BBOP world, shouldn't that technically "be" the BBOP planet? Anyway, may be better to talk on Disc, cheers.

Hey @aaronhowser1 , you can add as many Config.yaml's in the config directory as you like, each targeting a different preset as the overworld, so you could make one for each preset included in your modpack. You can name the config.yaml files however you like (only in the world save dir it has to be called Config.yaml). So say BiomeBundle.yaml, BBOP.yaml, Vanilla.yaml etc. Sorry if this isn't documented properly, I've also informed the mods on the Disc.

Oh I had no idea you could rename it! That solves my problem perfectly, thank you so much!

Cheers, and be sure to show off your creations on the Disc! :D

So the two main problems that are stopping me from doing this:

1. Non-predictable, variable dimension

• Could be fixed with a static ID option in the Config.yaml

2. Cannot have two dimensions using the same preset, even if one is the Overworld

• Could be fixed if it was Dimension(preset) rather than Preset(dimension)

Keeping in mind that I am mostly shit at mod-dev, so there's likely reasons to not use these fixes

Since you didn't respond ;)

Also, talking on here removes the requirement of an instant answer, we can speak on our own times I think.

Hmm, another nother problem.

The dimension isn't assigned an ID until you teleport to it with commands or the OTG panel. Also, they aren't always the same. BBOP was dimid 115 earlier, but on a new world it's 5. They're generated in order of which you teleport to, rather than specified to a number. I think I'm going to have to shelve this idea again, unfortunately.

Thanks for the feedback! I point to the discord because it's intended for questions and support. I try to keep the git about confirmed technical issues and focus on coding while the mods and community help people on the disc. In this case though, even the mods hadnt been updated about the features :P.

About your suggestions:

• Static id's configured in the config.yaml could be made to work, but I wonder how many edge-cases it would create when adding/deleting/editing dims and dim mods, and how much polishing it would need before it actually works properly. By the way, OTG should assign dimension id's at world creation, it should create the dimensions right after the overworld and then unload them, only to be loaded again when a player goes there. When creating a dimension, OTG finds the next available dimension id in the registry, so with the same dimensions setup and mods, the dims should always have the same id's (with a different dims setup, you would get different id's, yes). If you were getting id 115, it sounds like you've added/deleted a lot of dimensions during a session and it's not clearing the dimension registry properly and isn't reusing id's. Are you using the latest dev version? It should re-use dim id's after deleting/recreating dims (or joining/leaving worlds in SP).

• Multiple dimensions using the same preset isn't possible atm since biomes can't be shared across dimensions, and identical dimensions would lead to duplicate biomes being registered. The dimension/preset name is currently used in some of the code to create dimension-specific identifiers for the biomes, and has to be unique for some of the logic to work. That would have to be changed, unfortunately MC/Forge doesn't always expose the information or handles we'd need to make that work properly, hence the use of the dim/preset name (I admit it is hacky and should be improved tho).

Unfortunately it would be a lot of work to change these mechanics, and we're trying to focus on updating to newer MC versions, so I don't think I'll have time for changes on this scale for 1.12.2 .

We could think of some workarounds that don't cost too much effort though, fe there's already a feature where if you name your preset DIM-xxx, it won't appear in the world creation menu when selecting a preset for the overworld, only when creating dimensions*. I could add another feature where you can call a preset "Overworld-xxx", so it would only appear in the presets list when creating a new world/overworld. That way, you could at least package presets targeted for use as either overworld or dims. I suppose you would still have dimension id problems though if you want your users to be able to customise the dims setup on world creation or during a session, would need to think of a workable solution for that.

*Unfortunately atm the preset also doesn't appear in the presets list when creating a dim, it should ofc ><. Will see if i can fix that for the next dev version.

@aaronhowser1 after some poking from the mods and community on Disc, I'll take a look a look at setting dimension id's via the modpack config, so we can have AR and OTG working together properly.

Thank you very much, I really want to be able to do this. A lot of modpacks could be made massively better if this is completed

for 1.12.2 v9_r10:

• Added DimensionID field to .yaml / world creation UI for dimensions. Set to 0 for dynamic. If a dimension id is taken, the dimension is not created and OTG logs/shows an error message.
• Removed all existing behaviours for hiding presets in the ui (depending on which presets are listed in modpack configs, or which presets are called DIM- etc).
• Added ShowInWorldCreationGUI (true/false) field to DimensionConfig (invisible in UI). Set to false for dimensions to hide them from the SP world creation UI when creating a new world. Any presets used for the overworld in any .yaml are always shown. All presets are always shown in the O menu when adding/deleting dimensions after world creation (presets already used as dimensions are greyed out).

to be released asap on the disc

Super excited to test this out

Any update?