-
Notifications
You must be signed in to change notification settings - Fork 9
Configuring the mod
Infinite Dimensions supports infinite configuration possibilities.
The randomiser used for generating dimensions calls for configs almost constantly, whenever it needs to select a random block, mob, fluid, feature, biome, etc. By changing the configs, you can fine-tune the probability of selecting each block (mob, fluid etc.), as well as add your own options to the mix, including ones from other mods.
The file /config/infinity/infinity.json is the master file for configuring gamerules and root chances of generation. Here i will walk you through them.
- runtimeGenerationEnabled - setting this to false will disable registration of dimensions and features in runtime, meaning you need to quit to title and enter the world again to access dimensions after tossing the book. Included for compatibility reasons.
- returnPortalsEnabled - leaving this as true means every time you go through a portal from a custom dimension and generate a new portal, it will link back to a dimension you came from. If changed to false, all portals created this way will be normal nether portals.
- seedDependentDimensions - leaving this as false means the dimension seed and features of the dimension depend entirely on the contents of the book used to generate it. So same books will generate similar dimensions for all users. Changing to true will add dependency from the world seed: you can do this if you don't want to go into the mod already knowing "oh, the dimension 90 has diamonds" etc.
The root chances control how likely it is for the dimension to possess a certain property or generate a certain type of feature.
- "dimension_type" chances control properties that are applied across the whole dimension, i.e. "ultrawarm" means water evaporates like in the Nether, "fixed_time" means if the Sun/Moon exist they won't move, etc. "fixed_time": 0.25 means 25% of dimensions will have fixed time. You can learn more on the listed properties here.
- "noise_settings" chances control properties of the world shape and how the blocks are assigned to it.
- randomise_blocks: the chance to have a random block instead of stone.
- randomise_biome_blocks: the chance to have random blocks instead of dirt and grass.
- solid_oceans, solid_lakes: the chance for oceans/lakes to be filled with a random solid block instead of a random fluid.
- rift_world_chance: the chance to generate a rift world. Rift worlds have 4 block gaps to the void on every chunk border.
- "biome" chances control properties that are applied inside a particular biome in a dimension.
- use_random_biome: the chance to make a new random biome instead of choosing one from /weighed_lists/.../misc/biomes.json.
- use_sparse_vegetation: the chance for a random biome to have individually standing sparse trees instead of being densely forested.
- "features_chances" chances control likelihood of generating a specific feature type. They are independent from one another, i.e. if "shape" and "lake" are both set to 0.5, it means half of all dimensions will have shapes; also half of all dimensions will have lakes; and since these halves are independent, a quarter of all dimensions will have both.
- "features_rules" chances control properties applied to a specific feature, i.e. "flood_geodes" is a chance for a geode to be filled with a random fluid instead of air.
Most config files you can edit come in the form of weighed lists. A weighed list is a pool of options for the generator to choose between, where each option is assigned a number called weight. The larger the weight is, the more likely it is for the generator to pick this option. The weight of 0.0 causes the option to be skipped entirely.
In any weighed list you can safely change all weights, add and remove entries. Just make sure to format your entries uniformly with the rest of the file, and if you're adding content from other mods, don't forget about the mod's namespace in the key (i.e. it should be "key": "create:andesite_casing", not "key": "andesite_casing").
This section will explain what list is used for what in the game itself.
There are five weighed lists of blocks in the mod, all of which have different purposes.
- all_blocks.json is used the least and contains literally all blocks in the game.
- blocks_features.json is used for small decorations on features (you know how huge nether fungi have shroomlights in the cap? that's a small decoration), as well as for ore veins.
- It can accept any blocks, but for stability I've only put blocks that, when floating in the air, won't break on a random tick update - for example, saplings i excluded, cause they can't survive in the air and will get a block update by themselves, popping off.
- top_blocks.json is used for covering the top layer of the world. The requirements here are:
- the block is able to survive attached to the top surface of any full block;
- the block does not spawn particles;
- the block does not use block entity rendering. This is needed because a large amount of, say, banners covering the ground just won't render.
- full_blocks.json is used to generate most small/rare features in the world: rocks, walls and floors of dungeons, etc. These blocks will appear in your world in hundreds, maybe thousands, but unlikely tens of thousands within render distance.
- The list is comprised of all full blocks.
- full_blocks_worldgen.json is the most used list, as it is used for all the blocks that can appear in tens of thousands and more: the "stone" of the dimension, tree caps, icebergs etc. The requirements for this list are:
- the block is full;
- the block can survive floating in the air (which also means it can't be a gravity block);
- the block cannot be destroyed by liquid flow;
- the block does not spawn particles;
- the block does not use block entity rendering.
The mobs subdirectory contains the list of all mobs (mobs.json, used when setting the mob in dungeon spawners) and the smaller lists of mobs separated by category. The latter are used in regular mob spawning.
In Minecraft, different groups of mobs are spawned by different algorithms and share different mob caps. For example, hostile mobs are spawned every tick, while passive mobs - much less frequently. The generator needs to know which mobs to spawn in which category, that's why the lists are separated.
Don't be afraid to put mobs that don't use the mobcap (i.e. shulkers) in here, there are additional measures to control their population taken already. Just don't ever let the elder guardians spawn. Please. You'll regret it.
Features are things like trees, ore veins, underwater clay disks, flower patches, monster rooms etc. Infinite Dimensions can generate its own randomized features, but it can also use predefined features drawn from configs.
These come split into several categories across two folders: /weighed_lists/.../features and /weighed_lists/.../vegetation. These categories are here because Minecraft itself splits features into categories to place them in the world in a predefined order. So the generator needs to know which feature belongs to which category.
Unlike other weighed lists, non-vegetation and some vegetation features are selected with a different algorithm: the generator can select any amount of features from each category, with the chance of each to be selected equal to its weight in the list and the chances being independent. (Values above 1.0 are treated as 1.0).
This does not apply to flowers, grass and seagrass: the generator picks one entry from each list under default weighed list rules to populate the biome. Same goes with trees: the generator picks 1-6 tree types, which, if it decides to use a predefined tree and not randomize a new one, are drawn from .../vegetation/trees.json under default weighed list rules.
If you want to play with another mod and add features from this mod to Infinite Dimensions, you can create what's called a compatibility pack. (I will probably make some of these for example later)
Let's say you are making a compatibility pack for Create. Start by making a directory /create/ in /config/infinity/weighed_lists/ (by default, it only has a /minecraft/ subdirectory). Now from the generator's perspective, any weighed lists you put in there will be merged with ones from the default directory, i.e. /create/blocks/full_blocks.json will be merged with /minecraft/blocks/full_blocks.json - if, of course, the former exists (which is optional for every file).
Make sure to format these lists uniformly with the respective lists in the /minecraft/ directory and don't forget about subfolders (it's create/blocks/full_blocks.json, not create/full_blocks.json).