Minecraft Version 1.12.2
Forge Version 14.23.4.2705
JED Version 1.6.0-dev.20180619.124018.jar
StellarSky Version 1.12.2-0.5.3.2

When I make a new world Stellar dose not work with JED dimensions. The Time icon dose shows up on the top right hand side of the screen but it shows this error "INVALID"

Would you please explain what is a JED dimension?

Just enough dimensions lets players make their own dimensions like the overworld for example. You can change block colours, change the day or weather cycle and much more. You can also turn off dimensions like the nether or the end and even override them with the setting you set up.

So when you override e.g. overworld, Stellar Sky does not work on Overworld?

I guess overworld with different ID is, actually, not a overworld - it's a copy of it. So that part isn't an issue.
Though, there is a problem with JED overriding overworld on settings change so it can't be detected on Stellar Sky side.
Stelllar Sky compares a dimension type with DimensionType.OVERWORLD to check if it's overworld. This is supposed to work, I think. But I have to hear about this issue on the other side.
Would you please post this issue on the JED side as well?

(Fixed typo for you)

Yes and the same for making a new dimensions like overworld just with a different ID.

So replacing DimensionType changes the instance as well? That sucks.
I'll try checking the id and apply other safety checks.

Not sure what you mean? But basically when I'm registering custom dimension in JED, I need to also first register new DimensionTypes for them, because the WorldProvider for a dimension gets created based on the class that the registered DimensionType refers to. So in order to be able to use my WorldProviderJED and the ones that extend it, I simply can't use the existing vanilla OVERWOLRD/NETHER/END DimensionTypes.

So I'm not overriding the vanilla DimensionTypes, I'm (in most cases) simply not using those when registering a custom dimension. And the same goes for other dimension mods, they almost always register a new DimensionType for each dimension, so usually the only dimension using the exact DimensionType.OVERWORLD instance, is the vanilla overworld in dimension 0. And if the overworld has been overridden by JED for some customizations, then no dimension would be using that, most likely.

I see. I personally think changing WorldProvider field in World is better, but that's not a necessity.
I'll switch to ID check.

Changing the field "manually" after the fact would be more hacky, and it would break the assumptions other mods are making of how stuff is supposed to work in vanilla/Forge, and thus possibly cause more compatibility issues is some cases.

I agree that it's hacky, but it caused less problems for me. And any case will break the assumption of how stuff is supposed to work as well. (Replacing DimensionType does not help with this problem)
Again, that's just me.

Posted it. I hope this is how you wanted me to post it. I'm still new to how github works.
maruohon/justenoughdimensions#32

The problem with comparing the DimensionType to that of the vanilla overworld's, is that then I wouldn't be able to use my own WorldProvider, making any JED dimension overrides pointless, because I wouldn't be able to use my configurable WorldProvider anyway...

There are some other ways to check for the "dimension's type", such as WorldProvider#isNether() and WorldProvider#isSurfaceWorld(), or maybe comparing the instance of the WorldProvider class with if (provider instanceof WorldProviderSurface). Granted, this is somewhat of a mess because there is no clear defined way to indicate what type it should be... or I'm assuming there at least isn't a clear one adopted way to handle this among all the affected mods. Also one additional way would be to just check if (provider.getDimensionType().getId() == 0) instead of checking directly against DimensionType.OVERWORLD, as this would allow me to use my own registered DimensionType entry, which points to my custom WorldProvider class.