DynamicSurroundings-1.10.2-3.4.5.0
Forge 12.18.3.2297

https://pastebin.com/qQ20yiSD

Aurora rendering crashing client on Galacricraft space station on login (though how he got there without crashing before i am not sure). Maybe aurora only display sometimes? Did not test just disabling aurora, but removal of dyn surround fixed issue temporarily at least.

Looks like Galacticraft is assuming something about the dimensions sky rendering provider. Have you reported to the Galacticraft devs?.

I'm going to be putting in code to blacklist the dimension for aurora processing.

Pushed v3.4.5.1 that should block hooking the sky renderer for the orbital dimension.

DynamicSurroundings-1.10.2-3.4.5.1
GalacticraftCore-1.10.2-4.0.0.100
ExtraPlanets-0.4.3-Beta-Build
Forge 12.18.3.2297

https://pastebin.com/V7Hy8Ryk

Client crashes on load now, instead of when in orbit dimension. Reverting to DynamicSurroundings-1.10.2-3.4.5.0 stops loading crash.

Turning off the aurora processing in config does not prevent the crash (in 3.4.5.0) either.

Could you post a link to the complete log? Need to get more of the stack trace that is given in the regular dump.

Try this JAR: https://github.com/OreCruncher/DynamicSurroundings/releases/tag/v3.4.5.2TEST

I changed things around a little bit.

@Gorgok Check out an updated release: https://github.com/OreCruncher/DynamicSurroundings/releases/tag/v3.4.5.2TEST2

It seems to work in my local sandbox. Let me know how it goes.

DynamicSurroundings-1.10.2-3.4.5.2 (test2)
GalacticraftCore-1.10.2-4.0.0.105
ExtraPlanets-0.4.3-Beta-Build
Forge 12.18.3.2297

https://pastebin.com/TYFsMXs0

It looks like the blacklist is hitting all the galacticraft dimensions now, but not the extra planets ones, and maybe extra planets is messing with the galacticraft space station dim preventing it hitting that one? Moon, Venus, Mars, and asteroids are all aurora:false, space station is true.

Trying without extra planets just to see if it indeed is messing with the station, and if it goes aurora:false without it but no luck. Extra planets removed left the station dimensions aurora:true.

Not sure if its by ID or name that you are blacklisting them, but stations can be made multiple times and end up at multiple IDs, mine seem to be 4 and 79 so far.

DynamicSurroundings-1.10.2-3.4.5.2
GalacticraftCore-1.10.2-4.0.0.105
ExtraPlanets-0.4.3-Beta-Build
Forge 12.18.3.2297

https://pastebin.com/GxCCF7nn

That build loaded fine, but crashed in orbit dimension again.

Posted in support forum of Galacticraft dev and linked to here, maybe they have some ideas. Linked here:
https://forum.micdoodle8.com/index.php?threads/crash-with-dynamic-surroundings-in-orbit-dimension.6740/

Can you post your client log? There should be additional trace information.

EDIT: Also, what is the dimension name/id?

Here is a chunk of it, i don't think there was relevant stuff before that point.

https://pastebin.com/1vNtzvZA

I just got this error when I created a station using creative mode:

[15:10:57] [Server thread/ERROR] [FML]: Exception caught during firing event net.minecraftforge.event.entity.living.LivingEvent$LivingUpdateEvent@b675ba0:
java.lang.ArithmeticException: / by zero
	at micdoodle8.mods.galacticraft.core.world.gen.dungeon.MapGenDungeon.directionToNearestDungeon(MapGenDungeon.java:99) ~[MapGenDungeon.class:?]
	at micdoodle8.mods.galacticraft.core.entities.player.GCPlayerHandler.sendDungeonDirectionPacket(GCPlayerHandler.java:1170) ~[GCPlayerHandler.class:?]
	at micdoodle8.mods.galacticraft.core.entities.player.GCPlayerHandler.onPlayerUpdate(GCPlayerHandler.java:1343) ~[GCPlayerHandler.class:?]

EDIT: Apparently this has been fixed in one of the bleeding edge builds of GC. Going to try those.

What I am looking for is "Aurora provider blacklist detected" or "Aurora provider unable to blacklist" in the log.

Top part:
https://pastebin.com/tPHXDi6N

[16:21:02] [Client thread/INFO]: Aurora provider blacklist detected [micdoodle8.mods.galacticraft.core.client.SkyProviderOrbit]

All other mentions of Aurora are in the worlds themselves, most of which are aurora:true and then the errors. Strange that some of the planets are aurora:false, but not all? I assume that means you are blacklisting them with the above but some of the planets (including the space station dim) are not obeying anyway?

Further searching the log, it actually looks like your blacklist is applying once to the galacticraft/extra planets dimensions.

[16:22:13] [Server thread/INFO]: -30/Asteroids: seaLevel:63 cloudH:256 skyH:256 haze:false aurora:false weather:false fog:false

But then all the following ones are not...

The blacklist is working - but there may be some circumstances where things fall apart (there may be sequencing issues). I have been working on Galacticraft specific config changes based on the work Ezer'Arch has done. I cannot repro this issue using *.105 version of GC with these configs. I will pull together and post another test JAR later today for you to try.

Are all the space station dimensions named "Space Station"? The config I have currently uses IDs to match dimensions, but I could also use names if they are reliable.

It does appear that they are named Space Station each time.

Is that config something internal? I didn't see a blacklist in the configs when i looked for it initially (thinking that would have been the quick fix).

The galacticraft config files I am adding are internal in the JAR, but new ones can be added externally. By providing them internally I can have "out of the box" compatibility with mods. You can find the file I am tweaking here.

OK - made another JAR that uses the dimension names instead of IDs for config matching. You can find it here: https://github.com/OreCruncher/DynamicSurroundings/releases/tag/v3.4.5.2TEST3

The current set of DS configs for Galacticraft use the dimension names instead of IDs. But yes, there is a risk of having name collisions between mods. I spent some time to see if there was a ResourceLocation associated with a dimension but there isn't. :\ This would be a good Forge enhancement.

Dynamic Surroundings does some fancy footwork with the sky rendering hook. I have made several attempts to get aurora rendering into the mod with max compatibility but kept running into rendering issues with OptiFine, Stellar Sky, or some other mod that wants to some fancy rendering. The current approach hooks sky rendering, remembering the existing sky render hook. During the render phase the aurora rendering will automatically invoke the previous sky rendering hook so it can do it's thing, and then the aurora renderer will do what it wants. This hook check occurs every render pass (which isn't too efficient) but it allows me to work around some mod compatibility issues. Unfortunately GC became the latest victim. :)

Prior to all these changes DS would always hook the sky renderer, and then apply rules as to whether aurora rendering should take place. With the current changes I am hammering out it checks the configuration first before any hooking.

An issue that I have with the blacklist is that someone may decide that it would be cool to have an aurora for a planet. The blacklist would prevent that from happening. I am not to familiar with the player base for GC or what percentage of them uses Dynamic Surroundings, so I am not sure how much this is a real worry or some made up straw man. In general I try to provide the most flexibility to allow a modpack author to do what they want to deliver on their theme.

Another thing I am considering is having things like Aurora and Weather off by default for a dimension, and require config to turn on rather than having them depend on "getHasSky".

If you can link to some lines or show me example code to access the previous sky renderer using that hook you mentioned, I can add a compat feature into Galacticraft for that for those times when we still need to access our own sky renderer...

I hear you on what people may decide - we have at least 7 different devs making add-ons for Galacticraft which add new planets - sometimes specific to one modpack - and I think some of them want to make "earthlike" planets so yes, I guess someone out there might want auroras!

My preferred solution:

We could add an IGalacticraftWorldProvider method, boolean hasAurora() which you can poll. It will do nothing if DynamicSurroundings is not present. Then the add-on makers can set that for their planets as needed, or even make it configurable I guess ... we are slowly moving towards a future where Galacticraft planet data will be configurable in jsons or something so that servers and modpacks can change stuff.

I don't know how many players play both our mods together. We only just launched for 1.11.2 so it's kind of early days to judge player numbers. For 1.7.10 I'd guess approx 20% of the mod-playing userbase played our mod (or at least had Galacticraft in an installed modpack), comparing our own mod download numbers with "essential" mods like NEI. On that basis at a rough guess it could be 20% of your userbase have both mods together.

Let me think a bit on the hook thing. For the immediate need I decided I will turn off auroras/weather for dimensions as a default. This shouldn't cause most of the existing DS users an issue and avoids throwing a design together quickly just so I can get my mod released. Part of me thinks that the hook provided by Forge should be reworked into a plugin based system where multiple mods can provide various aspects to sky rendering.

hey guys, I've been notified of this

@OreCruncher thank you so much for building in compatibility

Yes, you definitely should blacklist our space dimensions from the AuroraRenderer, we need to have control of our own SkyProvider for each dimension.

Is there any reason why AuroraRenderer needs to run on Moon, Mars, Venus, etc? If not then the easiest approach for you could be to blacklist / disable the AuroraRenderer on any dimension whose WorldProvider is an instanceof IGalacticraftWorldProvider

It's not safe to use dimension ID numbers, as those can change - they can be configured differently in configs, and for space stations they are generated dynamically.

You could use the unlocalised names of the dimensions (which will be OK for us but could conflict with another mod with the same names, for example moon), I can give you a list of those but it won't cover planets added in future by us or by Galacticraft add-ons.

You could detect the WorldProvider class, but again that won't be future-proof if we or add-ons create new planets with new WorldProvider classes in future.

The safest is to check if the WorldProvider class is an instanceof IGalacticraftWorldProvider, that should be future-proof. (We haven't changed the name or location of that API interface in over 3 years, and it's unlikely that we would ever change it in future, as other mods must be referencing it.)

Part of me thinks that the hook provided by Forge should be reworked into a plugin based system where multiple mods can provide various aspects to sky rendering.

It's doubtful that anything Forge can come up with would be usable by Galacticraft, as we make widespread changes to the SkyProvider for multiple effects, it's easier for us to replace the whole thing!

• different sun appearance and size; different sun movement in some cases
• different celestial bodies in sky depending on dimension - and I guess some could even have two suns :)
• large celestial bodies below the player, if it's an orbital dimension
• stars visible in daytime in airless dimensions
• a range of different fog, color, and horizon effects
• effects when the player is above height 256, he sees the world falling away below him
• gradual change of color and star visibility depending on player height
• the entire skybox rotates, if the Space Station is spinning

@Gorgok Try out TEST4. I changed the default behavior of dimensions and cleaned things up. This should do the trick.

DynamicSurroundings-1.10.2-3.4.5.2 (test4)
GalacticraftCore-1.10.2-4.0.0.105
ExtraPlanets-0.4.3-Beta-Build
Forge 12.18.3.2297

Good stuff, just tested test 4 and did not crash. Logs stilll show the aurora as true, but i suppose that is because you are avoiding the problem with the design change instead.

Can you post the snip from the log where you see it as true?

Snipped out all the dimensions that get listed for me, Space Station occurs twice near the bottom.

https://pastebin.com/1xw0yTk9

[15:31:57] [Server thread/INFO]: 79/Space Station: seaLevel:63 cloudH:128 skyH:256 haze:true aurora:true weather:true fog:false
[15:31:57] [Server thread/INFO]: 4/Space Station: seaLevel:63 cloudH:128 skyH:256 haze:true aurora:true weather:true fog:false

You wouldn't happen to have external config files for Dynamic Surroundings?

Do you mean the .minecraft\config\dsurround\dsurround.cfg file? It had been edited originally and left as is for all tests, but i tried deleting it just now.

I saw the external config thing in the config when checking for differences. It is blank, so no external config.

Hmmm....ok. Reason I ask is because the "Space Station" dimension should all be false as a default, but somehow haze, aurora, and weather got set true without any config to drive it. Gonna get my pickaxe and shovel and start digging...

EDIT: Example this is what it looks like from my log:

[09:48:05] [Client thread/INFO] [dsurround]: 2/Space Station: seaLevel:0 cloudH:256 skyH:256 haze:false aurora:false weather:false fog:false