# Description Just Enough Dimensions (after this referred to as JED) is a mod that allows registering new custom dimensions to the game, **or** it can also be used to just tweak and configure some properties of existing dimensions. A few examples of tweaks that can be done to existing dimensions: * Use per-dimension World Borders (i.e. all dimensions would not be forced to have the same border as the overworld) * Use per-dimension difficulty(\*), Game Rules, day time, day length, world seed, sky and/or fog and/or cloud colors or the cloud render height \* Per-dimension difficulty is problematic in single player due to how some of the vanilla code works. But it should work no problem on a multiplayer server. As of version `1.6.0-dev.???` it's also possible to use JED to force certain settings for the world when the world is first being created. These include for example the WorldType of generator settings (for example making a superflat world or a void world \[which is also just a form of superflat\]), or setting some Game Rules. (This did work before `1.6.0` as well, but not quite the same way and not as cleanly.) **Note:** Due to the way that dimension IDs (and WorldProviders) are handled in vanilla and Forge, and also due to the rendering related customization options, this mod is also required on the client side and not only on the server. # Config file locations All dimension registration and configuration is done via a simple(?) JSON config file located at `config/justenoughdimensions/dimensions.json`. There are also a number of "global" configs and toggle options to enable certain functionality, these are configured via the config file located at `config/justenoughdimensions/justenoughdimensions.cfg`, which will be referred to as the `JED main config` from now on. There is also support for per-world-save configs (to allow using different settings in different worlds within the same game instance or mod pack). In that case the config files would be inside the world, at `/justenoughdimensions/dimensions.json` and `/justenoughdimensions/justenoughdimensions.cfg`. If these files exist, and the per-world configs are enabled in the "global" JED main config (inside the normal config directory), then these ones take precedence over the normal configs inside the config directory. # Config file structure overview This section describes the rough overview of the config file structure. More detailed descriptions are further down. Tip: There are **a lot** of various different example configs on my pastebin, here: [masa's pastebin](https://pastebin.com/u/masa-). ## JED main config `justenoughdimensions.cfg` The JED main config has a few toggle options to enable certain functionality and overrides, some of which (like `B:enableOverrideWorldProvider=true`) are very important for many of the configuration options the mod has to actually work. Another important (or at least extremely useful) option is `B:enableLoggingInfo=true`. I would recommend you to **always enable this during mod pack development or JED config testing**. With this option enabled JED will be printing lots of (not super spammy though...) useful debug information to the game console/log, which will help you see what JED is doing (or not doing) and when and using what values. The main config also has the options to enable the per-world-save config functionality. These need to be enabled in the "global" JED main config for the mod to try to read the configs from the per-world location. ## Dimension config `dimensions.json` The `dimensions.json` config file is the (only) config file JED uses to know what to do with dimensions and how. Every dimension you want to register or configure in some way needs to be defined and described in this config. The main structure of this config is that there is just one JSON array of dimension definitions, called `dimensions`, plus the optional `config_version` object which is related to the per-world-save config handling, and which you can ignore and leave out in most cases. Each entry in the `dimensions` array should be a JSON object, which describes what to do for that given dimension. The most common and most important keys (config value names) inside each dimension entry are: * `dim` (int) - the (Forge) dimension ID this entry is fo * `dimensiontype` (object) - This defines what type of dimension **to register**. * `override` (boolean) - Enable overriding an existing dimension * `worldinfo` (object) - All the values stored in the `level.dat` file * `worldinfo_onetime` (object) - Same as `worldinfo`, but only applied once on the first load of the dimension * **Note:** In most cases you want to use `worldinfo_onetime` instead of `worldinfo`! * `jed` (object) - This object holds most JED-specific options See below for more detailed descriptions, and a full list of the rest of the options. # Detailed config descriptions

dimensions.json top level keys

This section describes the "top level" keys/options inside a dimension config object (which are not nested inside other objects). Some of these are objects themselves, some (read: `jed`) with numerous possible contained keys/options themselves, and those will be described separately further down. Note that all of the `boolean` type options here default to `false`, and you don't need to specify them if you don't wan to use them. And it's basically the same with all other options - you don't need to specify any options you don't want to use. One particular note is that if either of the `worldinfo` or `worldinfo_onetime` values exists, even as an empty object, then that enables the "WorldInfo override" feature for that dimension (see further down for more info about that). ## Most common options * `dim` (int) - the (Forge) dimension ID this entry is for. This is an integer value, and is unique for each dimension. This value should always exist for every dimension config entry, otherwise the entry won't do anything as it doesn't target any dimension. The vanilla dimension IDs are `0` for the Overworld, `-1` for The Nether, and `1´ for The End. * `dimensiontype` (object) - This defines what type of dimension **to register**. * If you want to register a new dimension, or replace/override an existing dimension, then the dimension entry should have this value * If you are just overriding some settings for an already existing (vanilla or other mod) dimension without overriding the entire dimension, then this value is not needed * This `DimensionType` object (as it's called in the MCP mappings) defines only a small number of basic settings for the dimension: * `id` (int) - The "Dimension Type ID" (in vanilla it's the only dimension ID, but under Forge this is separate from the "actual dimension ID", and this "DimensionType ID" doesn't need to be unique) * `name` (string) - The dimension's name. This isn't that important for many things, it's mostly just visible for teleportation related items and things. * `keeploaded` (boolean) - Whether the dimension's spawn chunks are **allowed to unload**. * Note that this is **not** a chunk **loading** option. This controls the vanilla spawn chunks behavior (think overworld spawn chunks). * Basically if this is `true`, then the spawn chunks are *not allowed to unload* after *something has laoded them*. * This option will not automatically load them. Nor does this keep the chunks ticking with no players in the same dimension (for block entities) or nearby (for entities). * `worldprovider` (string) - This is the most important option here. It's the class name of the WorldProvide to use. In many cases you want to use one of the three JED WorldProvider variants, and those are needed for *most* (but not all) of the config options inside the `jed` object to work. * `require_exact_match` (boolean) - This is a JED option, which controls whether an exact match of all the values is required, or whether JED can use pre-registered common `DimensionType` instances that have a different `name` and `id`. * The name and id aren't usually that important, so re-using those pre-registered instances can avoid some issues with `DimensionType` entries registered later after game start not actually working properly. * Apparently one cause for such issues is having Optifine installed. This is because the `DimensionType` in the vanilla code is a Java enum, and isn't supposed to be modified at run-time. So adding new entries to it might not work if the JIT has already optimized away the `values()` method to return the earlier fixed list of values. And apparently Optifine calls the `values()` method a lot, which causes the JIT to optimize it away pretty quickly. Which means that trying to register new dimensions some time after game start does not work anymore. For this reason JED pre-registers a small number of `DimensionType` values early on, and uses those when possible (the important thing is that the `worldprovider` value and `keeploaded` both match, as those change behavior significantly.) * `override` (boolean) - If `true`, and a dimension already exists by this ID, then that dimension will be overridden by this dimension. Use the `dimensiontype` option to define what type of dimension to register. * `worldinfo` (object) - This can set any of the values that vanilla keeps in the `WorldInfo` class (MCP name). * If this value (or `worldinfo_onetime`) exists, that also enabled the "WorldInfo override" feature for this dimension. Without the override these would have no effect on most dimensions except for the overworld. * These values are stored in the `level.dat` file in vanilla, or by JED in the `jed_level.dat` file. * These values include: the dimension's spawn point, the world seed (`RandomSeed`), the WorldType (`generatorName`) and the world generator settings (`generatorOptions`), the difficulty, game rules, game type (game mode), time settings, weather counters, world border settings and a few others. A full list of the options is provided further down. * `worldinfo_onetime` (object) - Same as `worldinfo`, but the values are only applied once, when the dimension is loaded for the very first time. * In most cases you should use this instead of `worldinfo` * The only cases where you need to use `worldinfo` instead of `worldinfo_onetime` are: * If you actually want to reset these settings every time the dimension is loaded * If the server is running Sponge, then the `generatorName` and `generatorOptions` values will (for some reason) get reset on subsequent dimension loads, so you need to use `worldinfo` to set them every time * `jed` (object) - This object can hold a *lot* of different JED-specific options to configure the behavior and properties of the dimension. See further down for a full list of the possible options. * Most (but not all) of the options inside this object will require the dimension to be using one of JED's WorldProvider variants. This is because many of the configs are implemented by overriding the vanilla methods in the `WorldProvider` class with variants that check if the value was defined in the JED dimension config, and if not, then continue with the vanilla behavior. ## The rest of the options (which might be used less often) * `biome` (string) - If this option exists, then JED will force the dimension to use the vanilla single biome `BiomeProviderSingle`. * The dimension will only have a single biome everywhere. And no, you can't specify multiple biomes here. I know many users want that functionality, but the vanilla single biome provider is exactly just that - the same single biome everywhere. * `biomeprovider` (string) - Force using the given BiomeProvider class. * Note that this may be of limited use, as modded BiomeProviders might use custom constructors, meaning that JED doesn't know how to create the instance. * This was mainly added for better compatibility with the Painted Biomes mod. For that, use the value `fi.dy.masa.paintedbiomes.world.BiomeProviderPaintedBiomes`. * `chunkgenerator` (string) - Overrides the ChunkGenerator using the given class. * `disable_teleporting_from` (boolean) - If `true`, then the Forge teleport event is used to cancel any teleports *from* this dimension. * Note that all mods might not use/respect the event, and teleport commands will still work. * `disable_teleporting_to` (boolean) - If `true`, then the Forge teleport event is used to cancel any teleports *to* this dimension. * Note that all mods might not use/respect the event, and teleport commands will still work. * `load_on_start` (boolean) - If this is `true`, then the dimension will be registered earlier than than usual, so that the dimension will get loaded by vanilla/Forge during server start. * Usually you don't want the dimension to get loaded for no good reason. There are some special cases when you might need this, but by default leave this out. * `normal_biomes` (boolean) - Force the dimension to use the normal vanilla overworld biome provider. * This would allow you to get the overworld biomes (as in the biome value saved in the world) in the Nether or the End, however those dimensions use their own ChunkGenerators which don't care about the biome for the terrain generation. * A more useful example is using this in a "superflat" dimension, which normally uses the single biome provider. So you can get normal biomes in a flat world with this option. * `post_deletion_command` (string) - A command to run after a temorary dimension is deleted (see below). * `spawn_structure` (object) - Place a structure/schematic to the world when the dimension is first loaded * `temporary_dimension` (boolean) - If this is `true`, then the dimension is intended to be a "temporary dimension", and it will get deleted as soon as all players leave the dimension, and it's allowed to unload (i.e. no chunks are force loaded). THis might be useful for some type of resetting quest dimensions and such. * `unregister` (boolean) - If `true`, then an existing dimension will be unregistered. * **Note:** It's not possible to unregister the overworld. So many things in the vanilla and mod code assume the overworld to always be loaded, that doing so would break the game entirely. * Also be careful with unregistering the other vanilla dimensions. Some mods also break if you unregister the Nether or the End. * If you want to disable access to the vanilla dimensions, then instead of unregistering the dimension entirely, it might be better to just override it to be a void dimension, use the `disable_teleporting_to` option, and maybe also set up the void/sky teleport option to immediately teleport out any player that manages to enter it anyway. * `world_template` (string) - Allows using a template world (shipped via the mod config directory) that gets copied to the save location for this dimension when the dimension is loaded for the first time. * Note however that you can't "just do it" for any random dimensions due to how in 1.12.2 and earlier the game still uses per-world-global block IDs, which can and will be different in every modded world. That basically means that you would need to take every such template dimension from the same source world so that they all have the same block IDs, and you would need to also ship a template for the overworld i.e. dimension 0, which includes the source world's `level.dat` file, which contains the Forge block registry (along with all other registries). But then you would need to also have some `worldinfo_onetime` overrides, you would most likely at least want to reset the world time back to zero, and probably randomize the world seed so that all worlds won't be the same. And you should probably manually edit the `level.dat` file to delete the player data tag, so that the player in single player won't always spawn in the same place with the same inventory they had in the original template world. * So as a summary: This feature is problematic. In most cases you probably don't want to use it.

dimensions.json -> spawn_structure

The `spawn_structure` option allows you to specify a vanilla Structure Block template file or a schematic file that will be placed to the world relative to the dimension's spawn point when the dimension is loaded for the first time. The schematic file sould be placed at `config/justenoughdimensions/structures/name.`, so for example `config/justenoughdimensions/structures/spawn_house.nbt`. The schematic can be created with one of the following options: * The `/worldprimer create-structure` command from the [World Primer](https://modrinth.com/mod/world-primer) mod * With the [Litematica](https://modrinth.com/mod/litematica) mod * Vanilla Structure Blocks (these have a 32 block limit per side when saving though) * The Schematica mod I would recommend either World Primer or Litematica, but maybe I'm a bit biased in that... But the vanilla Structure Blocks do have the above mentioned size limit, and I don't remember if the Schematica mod has that or is able to save in the vanilla format or not. Actually neither of these schematic formats is the best option for this. But I haven't added support for the Sponge schematic format or the Litematica schematic format (yet?). The vanilla format is extremely memory-inefficient, and you can't really go beyond something like 100x100x100 blocks volume before you run into some serious issues with memory usage and server crashes with it. And the old `*.schematic` format doesn't really scale with large number of blocks in the game, and it still relies on the old "magic metadata". That format doesn't work if you use NEID or JEID or something else to extend the number of block IDs beyond the 0..4095 range. So as a short summary, use the vanilla `*.nbt` format if your structure is small-ish, let's say around 100x100x100 blocks volume or below, or if you use NEID or JEID or something else to extend the block ID range. Otherwise you can use the `*.schematic` format for far better memory efficiency and performance. Below is a sort of "pseudo-json" example showing the possible keys and values (mostly for the rotation and mirror options). ```json "spawn_structure": { "name": "spawn_house.nbt", "rotation": "", "mirror": "", "centered": , "offset": [0, -4, 0], "load_around": 16 } ``` Both `rotation` and `mirror` options default to `none`, so you don't need to specify them if you don't need to rotate the structure. `centered` defaults to `false`, but it's quite often a useful option, as it will center the structure **horizontally** to the dimension's spawn point (plus the specified `offset`). The `offset` option allows you to move the structure relative to the dimension's spawn point. The `load_around` option specifies how many blocks (scaled up to full chunks) should be pre-loaded around the structure's area before starting to place the structure. This is useful to avoid terrain generation ripping through the just placed structure, when an adjacent chunk is loaded forming the 2x2 loaded chunk area that triggers generation in the middle 16x16 blocks of those chunks. Here is an actual valid example. The `mirror` option has been omitted, as it's not being used. ```json "spawn_structure": { "name": "spawn_house.nbt", "rotation": "cw_90", "centered": true, "offset": [12, -9, -8], "load_around": 16 } ```

The jed options

Note that most of these options need one of the custom JED WorldProviders to be used to work. TODO: Add a list of the options that work without a JED WorldProvider. * `AverageGroundLevel` (int) - ? * `CanDoLightning` (boolean) - Enable/disable lightning (and also skeleton trap horses) * `CanDoRainSnowIce` (boolean) - Enable/disable water freezing, plus snowing and blocks (like Cauldrons) filling with water while raining. * The snowing and blcoks filling with water also depend on `HasSkyLight` for weather/rain to happen in the first place. * `CanRespawnHere` (boolean) - Whether the player can respawn in this dimension after dying * `CanSleepHere` (string) - One of `allow`, `deny` or `bed_explodes` * `CanSpawnHostiles` (boolean) - Override the normal difficulty-based mob spawning behaviour (peaceful vs. others) with this value * `CanSpawnPeacefulMobs` (boolean) - Override the normal value, which is `true` in hardcore mode and single player, and on servers it's the `spawn-animals` setting in `server.properties` * `CelestialAngleMin` (float, 0.0 .. 1.0) - Use a customized celestial angle range (needs both min and max set to take effect) * `CelestialAngleMax` (float, 0.0 .. 1.0) - Use a customized celestial angle range (needs both min and max set to take effect) * `ChunkGenFactoryWorldProvider` (string) - A temporary World Provider override during dimension load, which is just used to create a `ChunkGenerator` from a mod, that will then be used with some other World Provider later on * `CloudColor` (hex color string) - The color for the clouds * `CloudHeight` (int) - The render height for the clouds * `CloudRenderer` (string) - The fully qualified class name of a custom cloud renderer class * `CustomDayCycle` (boolean) - Enable a customized day cycle length. Set the day and night lengths in `DayLength` and `NightLength`. * `DayCycleIncrement` (int, default = 24000) - The amount of ticks the world time is incremented per day cycle when using the `DayTimeMin` and `DayTimeMax` options. * `DayLength` (int) - The custom day length, if `CustomDayCycle` is `true` * `DayTimeMin` (int, 0 - 23999) - Use a customized world time range. This may work weirdly with things... Needs both min and max set to take effect. * `DayTimeMax` (int, 0 - 23999) - Use a customized world time range. This may work weirdly with things... Needs both min and max set to take effect. * `DisableDawnDuskColors` (boolean) - Disables the sunrise and sunset sky/fog coloring at the horizon * `DisableEnderDragon` (boolean) - Overrides the `DragonFightManager` with a dummy class, disabling the Dragon related stuff. Needs `WorldProviderEndJED`. * `DisableEndSpikes` (boolean) - Uses `ChunkGeneratorEndJED`, which disables the End Spike (obsidian towers) generation. Needs `WorldProviderEndJED`. * `DontAdvanceWeatherWhenSleeping` (boolean) - Prevents clearing the weather when players sleep to pass the night * `FogColor` (hex color string) - The color for the fog effect. * `FoggyBiomes` (object) - Defines which biomes either have or don't have fog. See further down for more details. * `ForceGameMode` (boolean) - * `GenerateFallbackSpawnBlock` (boolean) - If `true` and the spawn position JED found is in mid-air (void dimensions), then a glass block will be placed right under the spawn point * `HasSkyLight` (boolean) - Affects things like weather and light calculations * `HasXZFog` (boolean) - (Thick) fog will be rendered around the player * `Horizon` (float) - The height of the horizon (used for sky rendering) * `IgnoreSpawnSuitability` (boolean) - If `true`, doesn't check the biome's spawn suitability or try to search for a grass block to spawn on when finding a spawn point for the dimension (in the `overworld` spawn point search type) * `IsSurfaceWorld` (boolean) - Compass & clock models, enables cloud & sky rendering, enables (vanilla) sleeping, enables pigmen spawning from portals * `LightBrightness` (array of exactly 16 floats) - * `MoonColor` (hex color string) - The color for the moon * `MoonScale` (float) - A scaling factor for the moon rendering * `MovementFactor` (float) - The Nether Portal scaling factor * `MusicType` (string) - The ambient music type that should be used in this dimension. You can get a list of the available values with the musictype dump in the [TellMe](https://modrinth.com/mod/tellme) mod. * `NightLength` (int) - The custom night length, if `CustomDayCycle` is `true` * `PlayerInventoryGroup` (string) - The inventory group this dimension should use, if the JED player inventory swapping is enabled. * `RespawnDimension` (int) - The dimension to respawn in, if `CanRespawnHere` is `false` * `ShouldClientCheckLight` (boolean) - Whether the client should check/re-calculate the light data in the received chunks * `SkyBlend` (float) - ? * `SkyColor` (hex color string) - The color of the sky * `SkyDisableFlags` (int) - A bitmask to disable the sun, moon or stars, if using `SkyRenderType` ??. (0x1, 0x2, 0x4) * `SkyLightBlend` (float) - Allows controlling the sky color blending with the light level, allowing to have a colored sky at night too. Range: 0.0 - 1.0, default = 1.0 (normal light blending). * `SkyRenderer` (string) - he fully qualified class name of a custom sky renderer class * `SkyRenderType` (int) - * `SpawnPointSearchType` (object) - Allows customizing the spawn point search code behaviour, and the algorithm to use for it * `SunBrightness` (float) - ? * `SunBrightnessFactor` (float) - ? * `SunColor` (hex color string) - The color for the sun * `SunScale` (float) - A scaling factor for the sun rendering * `VoidTeleportInterval` (int) - The interval in game ticks how often entities are checked if they need to be teleported from the void or the sky with the `void_teleport` and `sky_teleport` options. Default is 40 ticks (2 seconds). * `WaterVaporizes` (boolean) - Overrides whether water should vaporize (on bucket use and ice melting, like in the Nether) * `WeatherRenderer` (string) - The fully qualified class name of a custom weather renderer class * `WorldBorderCenteredOnSpawn` (boolean) - If `true`, and the dimension is using WorldInfo overrides, then the World Border will be centered on the dimension's spawn point * `WorldProviderOverride` (string) - Allows "manually" overriding the WorldProvider, without using a custom `DimensionType` entry with the correct provider

jed -> SpawnPointSearchType

This option allows you to specify the spawn point search algorithm and the allowed y-range for the spawn point. The spawn point search automatically happens for any dimensions that use WorldInfo override. This is so that if the player is teleported to the dimension's spawn point, that position would hopefully be a safe location. If you don't want this search to happen, then use the type `none`. * `type` (string) - One of `overworld`, `cavern` or `none`. The `cavern` type is used for Nether dimensions by default. `none` skips the spawn point search for that dimension, and uses the spawn point of the overworld. * `min_y` (int) - The lowest y-coordinate to search in. Defaults to `30` in the `cavern` type and `1` in the `overworld` type. * `max_y` (int) - The highest y-coordinate to search in. Defaults to `120` in the `cavern` type and the chunk's highest filled section's top + 1 in the `overworld` type. Example: ```json "SpawnPointSearchType": { "type": "cavern", "min_y": 40, "max_y": 100 } ```

jed -> sky_teleport and void_teleport options

The sky teleport and void teleport features allow you to teleport away any entities from the dimension when the entity goes above or below the specified y height limit. The sky teleport variant will trigger when the entity goes **above** the configured `trigger_y` y-height. The void teleport variant will trigger when the entity goes **below** the configured `trigger_y` y-height. Here is a "pseudo json" example showing the available options: ```json "_teleport": { "dimension": 10, "trigger_y": -10, "find_surface": , "remove_fall_damage": , "fall_distance": 4.5, "min_health_left": 1, "teleport_type": "", "scale": [8, 1, 8], "fixed_location": [256, 64, 256], "relative_location": "~ 256 ~+32" } ``` * `dimension` (int) - The target dimension where the entity will be teleported to * `trigger_y` (int) - The trigger y height limit for teleportation. (sky = above this, void = below this) * `find_surface` (boolean) - If `true`, then the teleport code will place the entity on the ground (either above or below the configured position), instead of putting it exactly at the configured position. * `remove_fall_damage` (boolean) - Whether to completely remove fall damage when teleporting. (How did this work again? What if the entity falls after the teleport?) * `fall_distance` (float) - If `remove_fall_damage` doesn't exist, but this key/value does, then this value will be used as the fall distance when dealing fall damage on teleport * `min_health_left` (int) - If this value exists, then the maximum fall damage/distance will be limited such that this amount of health will remain * `teleport_type` (string) - One of `same_location`, `fixed_location`, `spawn`, `scaled_location`, `relative_location`, `scaled_relative_location` * `same_location` - the entity will be teleported to the same coordinates in the target dimension (when the teleport triggers) * `fixed_location` - The entity will be teleported to the given exact fixed location in the target dimension * `spawn` - The entity will be teleported to the dimension's spawn point in the target dimension * `scaled_location` - The entity will be teleported to a location that is scaled from its current coordinates by the given scale factors in `scale`. * `relative_location` - The entity will be teleported to a location that is relative to its current location. You can specify the vanilla command style relative offset in `relative_location`. * `scaled_relative_location` - The entity will be teleported to a location that is both scaled and relative to its current location. (TODO: scaling happens first, before relative offset, right?) * `scale` (array of 3 floats) - For `scaled_location` and `scaled_relative_location`. This is the coordinate scale factor from the entity's position in the current dimension to the position in the target dimension. * `fixed_location` (array of 3 ints) - The teleport position in the target dimension for the `fixed_location` type. * `relative_location` (string) - The vanilla command style relative position specifier for the `relative_location` and `scaled_relative_location` types. Here is a real example: ```json "void_teleport": { "dimension": 123, "trigger_y": -50, "find_surface": true, "fall_distance": 7.5, "teleport_type": "relative_location", "relative_location": "~ 256 ~" } ```

All possible options for worldinfo and worldinfo_onetime

* `generatorName` (string) - The WorldType for the dimension * Vanilla values: `default`, `default_1_1`, `flat`, `amplified`, `largeBiomes`, `debug_all_block_states` * Biomes 'O Plenty: `BIOMESOP` * `generatorOptions` (string) - The generator settings. This is where your "superflat" settings string would go, or the vanilla customized overworld generator settings, or BoP config json strings etc. * `generatorVersion` (int) - Certain WorldTypes may be versioned. In vanilla the `default` WorldType must use `1` here, otherwise it will use `default_1_1` type instead. * `GameType` (int) - The default game mode for joining players. `0` = survival, `1` = creative, `2` = adventure, `3` = spectator * `GameRules` (object) - An object of string-to-string key-value pairs for all the game rules you want to set/override from the default values * `MapFeatures` (int) - Use `0` to disable most structure generation. (No mineshafts, witch huts, ocean monuments, mansions, nether fortresses etc. will generate in this dimension) * `RandomSeed` (int or string) - The world seed. Either the numeric seed directly, or a string which will get converted into a numeric seed. If not specified, then the same seed from the overworld will be used. * A special case is an empty string, which JED will use as indication to generate a new randomized seed for this dimension. * `SpawnX` (int) - The dimension's spawn point's X coordinate. You don't need to specify all three coordinates. The ones you leave out will... ??? TODO * `SpawnY` (int) - See above * `SpawnZ` (int) - See above * `Time` (long) - The total world time in this dimension. Note that you should never change this after the dimension is created, as it's used in various blocks and things for timing and delays, and changing it will break some stuff quite badly. * `DayTime` (long) - The current day time in this dimension. Sleeping will advance it t othe next morning, and using `/time set xxx` will set/reset the value. * `LastPlayed` * `LevelName` * `clearWeatherTime` * `rainTime` * `raining` (`0` | `1`) - Whether it's currently raining * `thunderTime` * `thundering` (`0` | `1`) - Whether it's currently thundering * `hardcore` (`0` | `1`) - Whether hardcore mode is enabled in this dimension * `allowCommands` (`0` | `1`) - Whether commands are allowed in this dimension * `Difficulty` * `DifficultyLocked` (`0` | `1`) - Whether chaging the difficulty is allowed (this is mostly for single player menu difficulty button) * `BorderCenterX` (int) - World border center point X coordinate * `BorderCenterZ` (int) - World border center point Z coordinate * `BorderSize` (int) - The size of the world border * `BorderSizeLerpTime` * `BorderSizeLerpTarget` * `BorderSafeZone` * `BorderDamagePerBlock` * `BorderWarningBlocks` * `BorderWarningTime`

Just Enough Dimensions

1.6.0-dev.20180514.212017

Changelog

Files

Metadata

Release channel

Version number

Loaders

Game versions

Downloads

Publication date

Publisher

Version ID