[1.7.10] Crash on Starting an RTG World

Question

[1.7.10] Crash on Starting an RTG World

GregoriusT opened this issue 7 years ago · 9 comments

GregoriusT commented 7 years ago

Affected Mod Versions:

GregTech 6: Developer Test Version, aka absolute latest, because I am Greg.
Forge version: 1614
RTG version: 1.1.1.6

Issue Description:

So I wanted to test out RTG and see where a different Issue related to GregTech and RTG, that got reported to me, came from. More to that special Issue below the StackTrace.

When I first started an RTG World (before the Singleplayer even logged into the "Server") I got thrown a nondescript RuntimeException that had to come out of RTG itself (there was no Caused By: section for that Stacktrace at all).

When I loaded that World again after the first Crash, it did Crash again, so it is not a one time Crash. Also I looked at the RTG Code and it somehow crashes on Village Generation. Note: The FML and latest Logs don't say more than this StackTrace, no additional Info to be had.

java.lang.RuntimeException
at rtg.world.gen.ChunkProviderRTG.doPopulate(ChunkProviderRTG.java:945)
at rtg.world.gen.ChunkProviderRTG.func_73153_a(ChunkProviderRTG.java:575)
at net.minecraft.world.gen.ChunkProviderServer.func_73153_a(ChunkProviderServer.java:279)
at net.minecraft.world.chunk.Chunk.func_76624_a(Chunk.java:1055)
at net.minecraft.world.gen.ChunkProviderServer.originalLoadChunk(ChunkProviderServer.java:190)
at net.minecraft.world.gen.ChunkProviderServer.loadChunk(ChunkProviderServer.java:131)
at net.minecraft.world.gen.ChunkProviderServer.func_73158_c(ChunkProviderServer.java:101)
at net.minecraft.server.MinecraftServer.func_71222_d(MinecraftServer.java:265)
at net.minecraft.server.integrated.IntegratedServer.func_71247_a(IntegratedServer.java:78)
at net.minecraft.server.integrated.IntegratedServer.func_71197_b(IntegratedServer.java:92)
at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:387)
at net.minecraft.server.MinecraftServer$2.run(MinecraftServer.java:685)

Now you might wonder what the Issue that got reported with GT6 is.

When GT6 is installed and the Generation of Streets along the World Axis is enabled, every bit of Biome related Worldgen such as Trees, gets disabled for some reason (ignore the GT6 Trees and Stuff, they generate with the normal WorldGenerator that is used for Ores etc).

https://forum.industrial-craft.net/thread/7156/?postID=212031#post212031
https://forum.industrial-craft.net/core/attachment/7167-screenshot-png/

The only reason why I could see this issue coming up is if you somehow pass Decoration/Population Events that all have "0" as X and Z Coordinate, because I disable Decoration and Population based on Coordinates, so that the Streets won't be screwed up by Vanilla Worldgen.

The Events that I catch and then set to DENY, if they are within 48 blocks of the Streets, (that screenshot shows way more than 48 Blocks due to the bug) are as follows:

DecorateBiomeEvent.Decorate
DecorateBiomeEvent.Pre
DecorateBiomeEvent.Post
PopulateChunkEvent.Populate
PopulateChunkEvent.Pre
PopulateChunkEvent.Post

I hope I get an explanation of what exactly happens with the Crash mentioned at the beginning, and that the Event thing maybe gets a fix despite being on an older MC Version.

srs-bsns · Answer 1 · 2018-01-11T20:58:31.000Z

I can think of two cases in which only checking if RTG is loaded would not be fully sufficient:

RTG is loaded, but the RTG world type is not used. (Not sure why anyone would load RTG and not choose the RTG world type. There wouldn't be a reason to even load RTG in that case, but it happens!)
Generation is taking place in any dimension that isn't the Overworld. (RTG is restricted to Dim 0, so even if someone created a custom dimension with the RTG worldtype, an instance of ChunkProviderGenerate would be returned when the WorldProvider requests a new IChunkProvider).

In both of those cases you should be safely able to, and probably should, DENY the decoration and population events, regardless if RTG is just loaded, in order to maintain your current functionality.

What I would do is set a static boolean somewhere (let's call it ModCompat.rtgLoaded) that is initialised during FMLPreInitializationEvent with cpw.mods.fml.common.Loader.isModLoaded("RTG");, and then in your world gen event handlers:

    public static void yourEventHandler(DecorateBiomeEvent.Decorate event) {
        if (ModCompat.rtgLoaded && (event.world.provider.terrainType instanceof WorldTypeRTG)) { return; }

        // Your Result.DENY code...
    }

Also, There's no point in DENYing these events...

DecorateBiomeEvent.Pre
DecorateBiomeEvent.Post
PopulateChunkEvent.Pre
PopulateChunkEvent.Post

...as they are just markers and don't have Results.

You can accomplish what you need with just:

DecorateBiomeEvent.Decorate
PopulateChunkEvent.Populate

GregoriusT · Answer 2 · 2018-01-11T21:46:35.000Z

The Streets thing is Overworld only for GT6, so that part isnt needed. And yeah I just took all Events and denied them to make sure that everything works fine. So I will just get the Source from your GitHub to be able to access that one Class for the instanceof (compiling reasons etc) and fix the issue like you just said. I'm not dumb enough to include foreign API Files in my jars so dont worry about that ;)

srs-bsns · Answer 3 · 2018-01-11T18:24:51.000Z

RE: The exception being thrown.

This is a duplicate of #906, which was fixed in 1.10.2 (Though I'm not sure why it wasn't also fixed in 1.7.10/1.8.9, but probably because it was never reported for earlier versions).

The code throwing the exception is debuging code that was left in by mistake, which throws an exception if the PopulateChunkEvent$Populate event of EventType.ICE is ever Result.DENYed, which, according to what you have said, you are doing in GT. (This likely only happens in cold biomes that have ice in them.)

RE: The decoration issue.

This issue is a bit more ominous, and is likely related to RTG's 'delayed decoration system' in which new chunks are not decorated until existing adjacent chunks have finished decorating.

The point of the system is to reduce/eliminate cascading chunk generation caused by decorations that spill over into adjacent chunks during the decoration process (large trees, etc..), which is a huge problem in older versions of Minecraft and can result in a large amount of world gen 'lag' that will last until the cascading stops. (Terrible in biomes like RoofedForest and Jungle, or with mods that add decoration routines with bad chunk offsets.)

I think what is happening in this case is new chunks that border the chunks which are being DENYed through DecorateBiomeEvent.Decorate events are not being decorated because those existing adjacent chunk are not getting decorated, and then the adjacent chunks to those new chunks are not decorated for the same reason, and it cascades from there in a completely opposite fasion to the problem the system is trying to fix.

I wasn't the one that wrote that code and it's not fully clear to me exactly how it works in every situation, so I'm not 100% sure that this is the case. This system in use can have strange side-effects and there have been similar issues when running it with SpongeForge (large areas of biomes undecorated) which I believe are the same, but that seems like the most plausible explanation.

Solutions:

The exception can easily be fixed by removing the debug code (the else clause)

Unfortunately, fixing the decoration issue would be quite a large task, as it would require having to discover exactly what is going on in order to fix it properly while also keeping our system in place, if possible. Thus, regretfully, this is unlikely to be fixed in 1.7.10 because of the fallowing:

It's a version of RTG that is 'retired'. Although we have said we would still put out new releases to fix critical bugs, we only meant it for simple fixes, which this decoration issue is not.
Due to time constraints, (as I am currently the only dev maintaining RTG and only have limited free time,) I only want to focus on porting the mod to 1.12.
Due to how far behind the 1.7.10 version of RTG is from current and the very limited amount of people that have shown an interest in using RTG with GT (my perception, anyways), it doesn't seem like there is a very good work-to-reward ratio to address this for 1.7.10.

On the lighter side, cascading chunk genertion shouldn't be much of an issue in recent versions of Minecraft, and since Forge has added detection for such cascading generation, all of our code to mitigate it is scheduled for removal in the next release for 1.12, so if you ever manage to update GT to 1.12+ in the future, this issue probably won't exist then.

I'll try to get a fix released for the exception this weekend for anyone that still wants to use RTG with GT regardless.

If anyone else has any suggestions for a possible solution to the decoration problem, it should probably be done in a separate issue, and if a solution is devised that requires changes in RTG, I'll be willing to accept a PR to fix it.

GregoriusT · Answer 4 · 2018-01-11T19:00:34.000Z

Good to see that at least the tiny fix is being done to prevent crashes. Dont worry abotu the bigger one, I probably will just detect if RTG is loaded and then not deny the results. Since RTG will probably not be so stupid and somehow generate ontop of my Roads (due to the Code you mentioned earlier), like vanilla Code does (Its still impossible to fix dark forests messing up Roads despite cancelling that event). I have had to fix a similar issue by generating both chunks where the roads are in, twice (so I generate both sides of the road despite there only being one chunk with the road generated). It fixed most of the "corrupted chunks" that somehow appeared to not be saved properly at times (as the roads are split on 2 different region files because along X and Z Axis). Im sure that just detecting RTG being loaded on my end and then not cancelling the Events will then fix the Issue mostly. ^^ And yeah I am not going to update past 1.7.10 anymore, I'm gonna make my own Game after I am mostly done with GT6. I really need full engine control, because stuff always gets messed up in MC. ;)

GregoriusT · Answer 5 · 2018-01-12T13:53:09.000Z

Okay apparently adding the RTG detection and the instanceof check also fixed your Crash Bug without people needing an RTG Update. Also the Worldgen is fixed too now.

But I would still like to know if there is a way for me to mark a Chunk as already populated, since it kindof lets stuff look "slightly bad" at times.

(and because I have focussed on other stuff when reading your post, yes ofcourse there is a static variable for the Mod being loaded being used, just like I do for all the COmpat I do for other Mods, so I only check isModLoaded once per Mod.)

GregoriusT · Answer 6 · 2018-01-12T12:11:26.000Z

Back again, question, is it possible to just mark the Chunks as populated so that your check works? If so, which variable inside the Chunk do you check for "is it populated or not?" ?

srs-bsns · Answer 7 · 2018-01-18T17:04:33.000Z

Crash fixed in: 545d01b

srs-bsns · Answer 8 · 2018-01-18T17:19:42.000Z

@GregoriusT Sorry it's taken me so long to respond... kind of a busy week.

I just released a fix for the crash you were experiencing, which you can find in this repo's release section. The new release is also out on Curse.

Back again, question, is it possible to just mark the Chunks as populated so that your check works?

The system is more complicated than just checking surrounding chunks to see if they are populated. It involves keeping track of chunk load events and storing events in custom maps and are acted on at a later date, or something. That code gives me a headache to look at it.

Okay apparently adding the RTG detection and the instanceof check also fixed your Crash Bug without people needing an RTG Update.

Yes, because the check to see if the RTG chunk generator is the generator for the world returns before the events get DENYed, and the RuntimeException will only be thrown if they are.
This issue, however, needed to be fixed regardless, as well as releasing another similar fix for #1216.

I'm not sure, exactly, what you can do about the decoration issue on your side. I think, unfortunately, you will have to keep the instanceof check.

GregoriusT · Answer 9 · 2018-01-18T17:54:49.000Z

Yeah I was just asking if there was an easy solution, but if its that complicated then its okay too. ^^ The issue with Deco isnt that Big with RTG for some reason, maybe your Worldgen Code isn't as "fucked up" as Vanillas. No worries, I'll keep the instanceof check ofcourse. ;)

Share to

Affected Mod Versions:

Issue Description:

RE: The exception being thrown.

RE: The decoration issue.

Solutions: