I just loaded JED up for the first time (ignoring other times from crashes with other mods, unrelated to jed), and I had the config set up to spawn me in the Nether initially.
Config (without comments):
B:enableForcedGamemodes=false B:enableInitialSpawnDimensionOverride=true B:enableLoggingInfo=false B:enableOverrideBiomeProvider=false B:enableReplacingRegisteredDimensions=true B:enableSeparateWorldBorders=false B:enableSeparateWorldInfo=true B:enableUnregisteringDimensions=true I:initialSpawnDimensionId=-1

Well, I spawned in the air something like 5 blocks above a massive lava lake. Luckily, I had a mod enabled that stops the player from taking any damage for 60s when first loading in. I believe another person had an issue with spawning inside the ground, perhaps this is similar in cause?

Version 1.4.1, btw.

I erased and created a world 5 more times. 2 of the 5 I spawned above massive lava lakes, and 1 of the 5 I spawned on bedrock, so above the roof.

To clarify: You can't unregister the overworld, but you can override it, and use a JED WorldProvider if needed. You can also unregister the other vanilla dimensions (nether and/or end) and that will disable the portal teleportation too. But it sounds like you want to spawn in the nether and not have an overworld available at all?

The top of the nether is normally y = 128. And due to the fact that you were essentially using the overworld spawnpoint (and thus my algorithm wasn't even used for anything, currently it is only used when searching for a spawn point for a nether type world when it loads for the first time, when using worldinfo overrides), if the overworld spawnpoint happened to be at y >= 128, then you would end up that high when you spawned in the nether.

Bingo. I'm trying to keep the player from being able to access the overworld, as dumb as that may sound.

Ah that makes sense, my mistake

Well you can simply override the overworld with a nether... :P
Like so: https://pastebin.com/YiC1GEEv

Then the question is, do you want to still have the regular nether as well? You would then have two nether worlds. I guess it depends on whether or not some mods need the dimension to be ID -1 to recognize it as a nether. And whether you think this would have some other issues.

I guess I could also add an option to disable portal teleportation per-dimension. That way you could have a low-performance-impact void world as the overworld (since its spawn always loaded). Although the performance difference of an unbuilt/empty spawn should be negligible anyway...

This could probably work except I'm not entirely sure Biomes o plenty would play nice, with their nether Biomes. So only Id=-1 would get the special biomes, but that could work out somehow. Unless.. I wonder if you could force a dimension other than id=-1 to use one of the nether Biomes as it's only biome. Then I could set up a bunch of dimensions, each for just one biome from the nether, and the overworld could stay as an overriden version of the nether (since Biomes o plenty also still includes the original biome "hell"). But then I'd have to figure out a relatively simplistic teleportation method. Not only that, while that would add lots of depth (literally!), It may be Overkill. Still, it sounds like a fun idea I might try just to see what happens :D

And no no it's okay! I don't want to put my.. Challenges.. on you, the mod maker! You've already helped me a lot, and your mod creates enough customization to fuel my creative needs xD besides, I think disabling the teleportation methods between dimensions may be a tad out of the scope of your mod, but then again, that's up to you. If there were an option to disable portals, I'd just switch that on and leave the overworld as is, since the player won't be traveling there anyway, so I imagine, like you suggest, it probably won't be a big impact performance-wise.

I have now uploaded version 1.4.2. It might take a few hours to get approved because of Curse shifts on Tuesdays... This version:

• searches for a suitable spawn position on initial spawn dimension override if WorldInfo override is not enabled for the target dimension, and thus the spawn point would be from the overworld
• adds an optional "disableteleporting": true option to the top level of each dimension's entry to prevent all teleportation (which respects the Forge event) from that dimension

Edit: Now that I think about it, I should have added two separate options though... Both "to" and "from" separately. I'll probably add/change that later.

Edit 2: Then again, the only use case for a "disableteleportingto" are either 1) disable teleporting to the overworld specifically, or 2) some private dimension that only an admin could access. In other cases, if it shouldn't be accessible, then why is it even registered? :P

As soon as it'll let me download, I'll do so and see if I can break anything else >:3

Edit in response to your edits: No even I could use that, so instead of locking the Nether so no one can leave, I can specify which dimensions are locked from being accessed. In my specific case, this means I could allow access to the End, but not the overworld. But again, I'm not here to push you :P I'll make do with whatever options I have available.

And here is the important question: do you have (at least an empty) worldinfo or worldinfo_onetime object in your dimensions.json config for the nether? If not, then the nether will not be using its own worldinfo, but rather it will inherit everything from the overworld. This includes the spawnpoint, and the /tpj command uses the exact world spawnpoint, it doesn't do any adjustments on teleport. And I think the initial spawn code also uses the exact world spawn, I'll need to check that.

I think I'll need to make at least the initial spawn code actually search for a suitable position if the worldinfo override is not currently enabled for the target dimension, to avoid this issue in normal play. And I guess the same logic applies to the /tpj command.

When I tested it (in the previous comment), I didn't even have a dimensions.json, but since then I have created one and populated it with data, including giving it a worldinfo_onetime. So does that mean things like fog color, grass color, settings for sun/moon visibility, day/night length, etc will be inherited from the overworld too, unless I set them in dimensions.json? Also, where does it inherit from if I were to unregister the overworld?

After populating dimensions.json, the spawns seem better but I'll have to test some more later. I've only tried maybe twice but both were in very appealing locations. The first one was on the very edge of a cliff of netherrack overtop a lava lake, but at least I wasn't IN it. The second was in a little cave-like area with a few pockets that led out into the more open sections of the Nether.

The color settings, sky render things etc. JED-specific customization are not inherited. They are only applied to any dimension that specifically has them added in the config. And that in many/most cases requires using a JED-variant of a WorldProvider.

Unregistering the overworld is not possible. Countless things in vanilla code assume the overworld to always be loaded, so unregistering it would break things BAD.

The custom spawn point search code in JED for Nether-like dimensions does indeed check for only three conditions:

• there must be a block that "blocks movement" below
• the spawn block itself must be air
• the block above the spawn block must be air

(spawn block here is the block inside which the player's feet are). So it is indeed possible to even spawn on a single floating block above a lava lake, if the random x/z coordinates it searches for happen to be at such a location :D

Basically the algorithm currently starts at x = 0, y = 110, z = 0, and it searches downwards until y = 10 at each x-z column until it finds a suitable location per the criteria listed above. If there isn't one, then it chooses a new x-z location randomly within 32 blocks on both axes, and repeats this process up to 100 times. If it still hasn't found a suitable location after those 100 iterations, then it will give up and use x = 0, y = 70, z = 0 as the spawn point. If that happens, you might be in trouble :P (While fixing the initial spawn issue, I now changed the y limits to start y = 120, end y = 30.)

Ab, so custom fog and the sun/moon/star rendering would probably need a JED worldprovider.

Dammit xD time to search for a mod to turn off the nether portals.

Spawning on a single block in a lava lake would give me so much anxiety, that'd be intense! But I'm still confused how I ended up on TOP of the nether, if your algorithm only checks up to a height of y=110 (now 120). The top of the nether is like 280-something.

Okay I think I got it here
Does a section for the overworld even need to be there if I'm not altering it in any way?

The examples were helpful, thank you.

And muchas gracias, meine freinde! If you need suggestions, I could provide some, but I should probably wait til you finish the [re]spawning code. Take your time!

That config is still a bit wrong. The first entry should be fine, but the overworld and end entries are nested inside each other, and you are missing a comma after the nether entry. And no, if you are not doing any customization for the overworld, then there is no point in having it in the config.

I'm going to re-use a reply I sent someone else a little while ago, just some generic things about json:

I actually get the general gist of a json, I must have forgotten to erase commas, and double check that every bracket had it's closing pair. In the config, it likes to not line up with tabs. I didn't think of using notepad++, thanks for the tips!

Back from testing, spawns are perfect. I had some really scary ones right next to lava and stuff but nothing I couldn't get out of.

I also tried the disableteleporting but I was able to teleport in the portal to the overworld with no problems. Perhaps I put it in the wrong place?
"dim": -1, "disableteleporting": true, "worldprovider": "WorldProviderHellJED", "JED": { "DayLength": "30", "NightLength": "30", "SkyDisableFlags": 7 },
Feel free to inform me if I'm using any of those wrong.

I also ran across another bug while testing. If I set my initial spawn dimension, I won't spawn in that dimension when I die. In my case, I died in the Nether and respawned in the overworld.

That config snippet looks wrong. The worldprovider value should be inside a dimensiontype object, and that dimensiontype then should also have the other values that are in the examples (name, suffix, keeploaded). And the JED tag must be inside a worldinfo object (note: worldinfo_onetime won't work either), or it won't work. Those day and night lengths... are you just testing, or do you actually want 1.5 second long days and nights? ;D (the values are in game ticks).

And yes, the initial spawn dimension is exactly that - initial spawn dimension. It only takes effect when a player logs in for the very first time. The way it is implemented, is that JED checks if the player doesn't have their player data file yet, then it will move them to the specified dimension's spawn. I guess (perhaps a separate?) config for respawn dimension would be needed?

Does the worldinfo object need to be inside the dimensiontype object as well?

To be completely honest... I really wanted to see how solar panels and stuff would react to such a short day/night cycle, but I'm considering keeping it, so the solar panels are still viable without being overpowered in any way. Yes, I knew they were in in-game ticks ;D Originally, I had it shorter (like 15 ticks or something).

And, oh, I misinterpreted. Again, you don't have to, I can search around for another mod to pick up the slack, or I can attempt some less-than-preferred method, like giving the player waystones or something. But it still creates an issue in that the overworld is accessable.. hmm...

No, the worldinfo object is at the top level of the dimension entry, just like the dimensiontype object is as well. Example: https://pastebin.com/GakmHRvm

One note about the config (which I don't think is really mentioned in the documentation atm, I need to fix that...): When a dimensiontype object is present for a dimension config entry, only then will JED actually try to register that dimension. Which means that without it, you can have for example the worldinfo object to only enable separate WorldInfo, or you can have the colors object to customize those for an existing dimension. But when you add the dimensiontype object, then JED will actually try to register that dimension itself. If there is an existing dimension already by that ID, then you would also need to add the "override": true for that existing one to get replaced. This overriding would be needed for example if you want to change the WorldProvider type of a vanilla dimension to one of the JED types.

There are a few other example configs for various use cases here: https://pastebin.com/u/masa-

And as to (re-)spawning... I'd like JED to be a somewhat fully-featured "tweak mod" for "all things dimensions", so that in my books does definitely fall into JED's territory. I'll take a look at it shortly (I'm currently finishing up a certain feature for Ender Utilities).

I just released JED version 1.5.0. It adds that separate disableteleportingto option (and note that it also renames the old/other option to disableteleportingfrom). It also adds CanRespawnHere and RespawnDimension JED-options, that are (only) usable with JED WorldProviders. Basically, if CanRespawnHere is false, then the RespawnDimension determines the dimension to respawn in. CanRespawnHere in by default true in WorldProviderSurfaceJED, and false in the Hell and End providers (just like in vanilla).

And here is a ready made config that might be close to what you want. It also has the overworld as a void world: https://pastebin.com/bcNxkHCB

Thanks for your help!

I copied and pasted the raw paste data from your pastebin link and new worlds don't load. It just sits at the loading world screen forever. I've tested it up to 5 mins. I usually have to CtrlAltDelete my way to task bar to get the screen to close. To check that it was in fact some issue with Jed, I used curse's disable feature (and double checked that the file was in fact disabled) and when I started up a new world, it started up just fine. I added maybe 2 mods since I've tested starting new worlds so it's possible it's some issue with the other mods. I'll test when I get a chance.

Huh. Do you get any errors in the console? Does the game keep using all of the CPU, or does it just basically stop? Could you pastebin the fml-client-latest.log (if this is in single player, otherwise the server one) from such a start.

Here's the pastebin for what appears in the console leading up to the point where it loads forever (start reading from [17:07:03] [Client thread/INFO] [journeymap/]: Cached colors from TextureAtlasSprites: 2411, as that line prints at the menu screen). I don't really understand a lot of what it says, but I see that it switches the server over to the state "stopped", which as far as I'm aware, only happens when the game crashes. The instance of minecraft also continues using 4k MB/ 76% of my total memory, fluctuating very slightly by ~10MB, and drops down to an avg of .2-.3% cpu usage with a minimum of 0%.

Here's the pastebin for the fml-client-latest.log. I couldn't post the whole thing cuz pastebin has a limit and the log was absolutely massive.

Edit: Just did a quick reread through the first pastebin, I think the issue is explained in this line: Caused by: java.lang.ClassCastException: fi.dy.masa.justenoughdimensions.world.WorldProviderHellJED cannot be cast to net.minecraft.world.WorldProviderHell (Line 37). Here's the crash report it references in-line.

Okay that crash happens in Extra Utilities 2, it seems to assume (and not check) that the WorldProvider of the nether is the vanilla WorldProviderHell class. I guess I'll need to change mine to extend the vanilla WorldProviderHell instead of extending from the base WorldProvider class. It means a little bit of more duplicated code but... what can you do.

For now you should be able to prevent the crash by changing the nether dimension's world provider to WorldProviderHell, but it means that the respawning won't work there anymore. I'll try to get a new JED version out tomorrow to fix this.

Edit: Another possible fix/workaround would be to use a dimension id other than -1 for your nether, that way ExU2 shouldn't assume the WorldProvider type to be the vanilla nether provider.

If I needed a fix immediately, I'd try either of those options. Since time isn't an issue currently for me, I'll just temporarily disable JED while I wait for the fix. Should I post this as an issue on ExU2's github too, or are you just gonna fix it on your end and not worry about it? Their github seems filled with issues (926 between 1.11.2 and 1.10.2) anyway so I don't know if they'd actually get to it for a while.

This is a bit of a grey area, I guess you could argue that in this case (as in the config I pasted) it was JED's fault for using a different WorldProvider for the traditional nether dimension (as in using the vanilla dimension id). But then again, you could also argue that in this case it's simply a configuration error. As you could also override dimension -1 with an overworld or end type dimension, and ExU2 would likely in those cases crash with the same error again, even if I were to change the class hierarchy of my WorldProviderHellJED. And now that I have thought about it this way, I don't know if it even makes sense to "fix" it (or rather make that change in JED).

So, as vanilla doesn't allow any teleportation directly between the nether and end anyway, you would have to use modded teleporters in any case. Which then means that the dimension ID of the nether should be irrelevant. So I guess I'd suggest simply using a different ID for your nether dimension. That way ExU2 shouldn't make that kind of an assumption about the WorldProvider. (not sure what it even uses that for/is doing when it crashes...)

I'm not here to point fingers, just trying to help avoid any other potential issues in the future.

As for finding a solution to my problem, I changed the dim-1 section in the json to:
{ "dim": -2, "override": true, "dimensiontype": { "id": -2, "name": "JED Nether", "suffix": "_dim-2", "keeploaded": false, "worldprovider": "WorldProviderHellJED" }, "worldinfo": { "generatorName": "biomesoplenty", "GameRules": { "doDaylightCycle": "true" }, "JED": { "CanRespawnHere": true } } }, and everything works perfectly (natura's trees and worldgen spawn, along with ores from ore core, etc) except none of the biomes o plenty biomes spawn. I tried using the exact words from the main JED page ("BIOMESOP") but that didn't work either. I guess I just don't understand how to format it properly. I looked at a few of your examples such as the Mining Dimension example and I thought this was right.

Are you talking about the BoP nether biomes (as you are creating a nether type dimension)? You most likely need to be using the BoP nether WorldProvider for those to work. From one of the first spoiler tags on the JED page I found the name for that to be biomesoplenty.common.world.WorldProviderHellBOP. Although I think you then can't respawn in that dimension, since the respawn support in JED (for being able to respawn in hell or end type dimensions that is) depends on a JED WorldProvider I believe.

Yes I was but good news! I found out the reason biomes o plenty biomes weren't spawning is due to a compatibility error between BoP and Natura, where Natura's generation spawns in place of BoP's nether generation. I just tested:
{ "dim": -2, "override": true, "dimensiontype": { "id": -2, "name": "JED Nether", "suffix": "_dim-2", "keeploaded": false, "worldprovider": "WorldProviderHellJED" }, "worldinfo": { "generatorName": "biomesoplenty", "GameRules": { "doDaylightCycle": "true" }, "JED": { "CanRespawnHere": true } } }

and the world loads up perfectly, with the BoP biomes, which means your world provider can be used instead (which means JED functions such as CanRespawnHere can be used!). Now I just gotta wait for a fix between Natura and BoP...

Edit: So when I died in the Nether (dim -2), I respawned in the overworld (and promptly fell into the void, as my overworld is a void world) instead of respawning in the Nether (dim -2).

Is that paste correct? The generatorName for Biomes O' Plenty is supposed to be biomesop.

And to the respawning: hmm, are you able to reproduce that every time? is this in JED 1.5.0?

I figured the generatorName would be the MODID, and biomesoplenty worked, unless it's defaulting? which is completely possible.

Just tested, yeah it's just defaulting. I can erase that line and it'll still spawn with nether biomes.

For the respawning, yes, every single time I die (v1.5.0) it takes me back to the overworld and I fall into the void. On one of the tests, MC actually crashed before loading into the overworld. Here's the pastebin.

Hmm strange. I was just testing, and the respawning works for me every time. However I don't get BoP nether biomes... Unless those weren't in 1.10.2 where I'm testing atm, you seem to be on 1.11.2. So I'll test this there too...

Edit: That crash is from Optifine... I have seen that several times in relation to JED (probably could happen in any custom dimension?). Not sure what is going on there.

Yeah BoP didn't add back the Nether Biomes (previously 1.7.10) until 1.11.2, which is where I'm testing.

Alright, I'll report this to optifine and see if they can help me on that front.

Edit: It appears that this Optifine issue report is that crash I had (except it's on 1.10.2 and I'm on 1.11.2).

"The line which crashes is switch(dimensionType), which is very strange. Looks like JED is extending the DimensionType enum at run time.
This seems to be a known limitation of Forge when extending enums: MinecraftForge/MinecraftForge#2787
To fix this JED should extend the enum as early as possible, for example in a static block in the main mod file."

BTW do you use Discord? It would be easier to talk on my server than here in the issues...
If you do, here is an invite: https://discord.gg/2FgywHj