World crash upon exploring with pfaa

[31trainman]

Upon the creation of a new world with pfaa it takes along time to load and upon joining and exploring for a few chunks it crashes

Heres the error report http://pastebin.com/2hERabYQ

Mod list http://pastebin.com/RrrNfhL8

Forge 1614 Minecraft 1.7.10 Mac os x 10.11.4 Java 8 update 91

[lawremi]

Please remove mods until the error goes away, perhaps starting with Reika's mods and fastcraft, but it's probably something else.

[31trainman]

It's dragon API and something about block composition

[lawremi]

Could you please elaborate? How did you get the idea that it is "something about block composition"?

[31trainman]

From the crash report I see dragon API mentioned and block composition but I can't tell what's causing the crash

[lawremi]

Did you actually try removing DragonAPI (and its dependencies) to see if the problem goes away? Stack traces can be misleading.

[31trainman]

il copy my modpack test and try

[31trainman]

The crash doesn't happen when dragonapi etc isn't present

[lawremi]

Maybe @ReikaKalseki could lend a hand here. Somehow one of the Geologica blocks is being rendered with the wrong meta, though it's not clear how DragonAPI would be at fault.

[ReikaKalseki]

That stacktrace contains no reference to any of my code, and aside from a RenderBlockEvent (ASMed into WorldRenderer) DragonAPI has no interaction with the WorldRenderer or ISBRHs.

[lawremi]

Well according to 31trainman, removing DragonAPI and its dependencies avoids the error... so there is some sort of interaction.

[ReikaKalseki]

With no indications as to a source, I can neither explain nor offer a solution.

[lawremi]

@31trainman would you please try to establish a minimal set of mods for reproducing the issue?

[31trainman]

ok, Do you have discord or something @lawremi for making it easier to fix problems like this?

[31trainman]

iv created a test of pfaa custom ore gen and dragon api, rotary craft and reactor craft and am seeing massive lag. after awhile of digging I got this http://pastebin.com/qc2DkqPA

[ReikaKalseki]

Not even remotely related.

[31trainman]

Strange then as testing with only those mods hasn't resulted in a crash only lag and that error coming up

[lawremi]

There is some other mod causing the problem. Btw, chunk gen lag can be reduced with fastcraft.

[recalcitrantQ]

I have also encountered this crash.

My crash report is http://pastebin.com/9gT3y4Gk and my modlist is http://pastebin.com/ZRj1eKuG

If I'm not mistaken, the issue here would be that some other mod is setting metadata on a block without PFAA's knowledge?

List of common mods between my setup and the one in the first post:

BiblioCraft BiblioWoods[Natura] Biomes O Plenty Buildcraft Chisel Climate Control gasesFramework gases Mantle Natura Pam's Harvestcraft RTG PFAA CustomOreGeneration Fastcraft

[ReikaKalseki]

And that demonstrates not needing DragonAPI and thus it not being on my end.

[31trainman]

@lawremi its geologica interacting with Dragonapi in away its not supposed to. according to mod developers I know its a missing size check of size 4

[ReikaKalseki]

Do you even read what gets posted? recalcitrant does not even have DragonAPI installed. Unless you want to argue that DragonAPI is so bad that it breaks things even without being present, this has been demonstrated to be outside my doing.

[31trainman]

Yes I do @reika it's on geologica's side some interaction with dragonapi

[lawremi]

@31trainman please come up with a minimal list of mods that reproduces one of these crashes. There are semi-popular modpacks that combine Reika's mods with PFAA, without any known issue, so it's probably an interaction with one of the lesser known mods on your list.

[recalcitrantQ]

Crash reproduced with modlist of

fastcraft-1.23.jar gases-1.7.10-1.6.3.jar gasesFramework-1.7.10-1.2.0.jar PFAA-1.7.10-0.2.27.jar CustomOreGen-1.7.10-1.2.21.jar

[ReikaKalseki]

Yes I do @reika it's on geologica's side some interaction with dragonapi

OK, in that case you are just stupid, because you are arguing that a mod can trigger a crash without even being installed, and have insisted that you have understood what you are saying and yet you stand by it. Stop wasting people's time and learn either how to read or how to use basic reasoning.

---

The crash is renderer-related, so my first guess would be FastCraft, if it is in fact a mod interaction. But the stacktrace implies otherwise.

[recalcitrantQ]

The crash is related to block metadata. Geologica is expecting metadata value to be within a certain range, but it is beyond that range due to being set by another mod. That's my current understanding at least

[ReikaKalseki]

I have had people report similar issues with ElectriCraft, ReactorCraft, and ChromatiCraft ores. A year in, there is still no consensus or consistent cause.

[lawremi]

@31trainman would you please contact the maintainer of Glenn's Gases to see if he might have any clue.

[31trainman]

Sure @lawremi, perhaps pfaa is interacting with the gases from Glenn's gasses and somehow dragonapi is seeing this and trying to render fire and then fastcraft is somehow interacting with the rendering of said fire.

[ReikaKalseki]

perhaps pfaa is interacting with the gases from Glenn's gasses and somehow dragonapi is seeing this and trying to render fire and then fastcraft is somehow interacting with the rendering of said fire

The only thing in that even approximating accuracy is the possibility of the gases being involved, as they may be setting the metadatas of adjacent blocks as they flow.

dragonapi is seeing this and trying to render fire

And there you go accusing a mod of breaking things without being installed, this time also adding a bonus of thoroughly demonstrating that you lack an understanding of not only basic logic but of the code as well. No doubt this will have no effect on how sure you are of what you are saying.

[31trainman]

I have a fresh crash and clearly see DragonApi involved as I have it installed http://pastebin.com/BS271Kim

Mod list http://pastebin.com/FqxDFA4q

[recalcitrantQ]

DragonAPI being in the stacktrace doesn't mean it has anything to do with the crash, any more than fastcraft does.

What this looks like to me is incompatibility between Iocalfaeus Gas and Geologica. Iocalfaeus Gas increases the metadata value of adjacent stone blocks to track how much it's heated up, which would throw off Geologica's rendering when it tries to determine the GeoMaterial

[JamiesWhiteShirt]

Glenn's Gases dev here.

I'm fairly certain DragonAPI is not involved even though it appears in the stack trace, it's merely injected itself into block rendering but acts normally in most cases (https://github.com/ReikaKalseki/DragonAPI/blob/master/Instantiable/Event/Client/RenderBlockAtPosEvent.java#L51). There's still no reason to be an ass about it.

@recalcitrantQ is partially correct. Iocalfaeus gas uses metadata to track block temperature, but it's using it's own block ("gases:warmStone"). This block does inherit BlockStone. Could this perhaps make PerFabricaAdAstra assume it is a static type of stone? By the way, this mechanic is currently being reworked, so the issue might resolve itself soon.

While it doesn't resolve the issue, I found it useful to avoid fast-failing during rendering as it causes more problems than debugging material, so it might be useful to add a bounds check.

[flyingbanana]

Actually, DragonAPI being in the stacktrace means it's reika's fault. Case closed.

[recalcitrantQ]

@JamiesWhiteShirt I'm guessing a temporary workaround in the meantime would be to set the worldgen frequency of Iocalfaeus Gas to 0 in config?

[JamiesWhiteShirt]

If that is the actual problem, yes. @31trainman could you try that and see if it still happens?

[lawremi]

Just looked at the GasTypeLightSensitive.java in Glenn's Gases and found that it will replace vanilla stone with warmStone, but otherwise it will modify the metadata of the existing block.

The line

int otherMetadata = otherBlock == Blocks.stone ? -1 : world.getBlockMetadata(x1, y1, z1);

Should probably be:

int otherMetadata = otherBlock == Gases.blocks.warmStone ? world.getBlockMetadata(x1, y1, z1) : -1;

[JamiesWhiteShirt]

@lawremi Correct! I just noticed that just as you wrote this. This is very likely the cause of the issue.

[JamiesWhiteShirt]

I have probably just resolved this issue. It would be great if @31trainman could update to Glenn's Gases 1.6.5, just released on CurseForge, and verify that the problem is gone.

[recalcitrantQ]

@JamiesWhiteShirt I can confirm that crashing is no longer occurring, and that Iocalfaeus Gas is now nonreactive with PFAA stone types

[JamiesWhiteShirt]

Don't you just love when your bugs show up and bother other modders :sweat_smile:

[31trainman]

Its working @JamiesWhiteShirt and @lawremi except what does this mean for future compatibility of the 2 mods?

[Webzoner97]

So can we get reika to fix this? We found the cause, and I dont know why he's trying to render fire here either.

[31trainman]

Not sure reika will fix this odd bug as he may be doing who knows what else.

[JamiesWhiteShirt]

@31trainman It just means that there is no longer any incompatibility between the mods. The incompatibility was not supposed to be there in the first place, since it was all caused by a bug in Glenn's Gases that had a side effect causing this issue.

Reika is not involved in this. DragonAPI appears in the stacktrace merely because it's injecting itself into Minecraft's block rendering to intercept in rare cases. The issue was with Glenn's Gases all along, and this issue should be closed as it is confirmed there no longer is an issue.

[lawremi]

Thanks @JamiesWhiteShirt for the quick fix, sorry @ReikaKalseki for the noise, time to close this one before it goes off the rails.

[ReikaKalseki]

@JamiesWhiteShirt Now do you see why I react to these people? You can essentially hit them in the face with what amounts to a sign emblazoned with "YOU ARE WRONG" and they will still hold their position, convincing more people all along the way that I am somehow at fault.

@lawremi Please lock it before more idiots waste more time, and let them go eat dirt or chase rocks or something instead.

"In before" someone starts mouthing off on the FTB subreddit six days from now about how I refuse to fix this crash...

Also, @flyingbanana above is a troll:

https://github.com/ReikaKalseki/Reika_Mods_Issues/issues/106

[ReikaKalseki]

Note 2: This bug has been confirmed to be the cause of at least one of the other "metadata randomly changing to invalid values" reports on my end (referenced above), and I am attempting to confirm the others.

@1skandar: Remember some time ago you reported one of the CC lumen lamps randomly changing color (light blue to blue or something like that)? Does Modular Mayhem include Glenn's Gases, and if so, can you confirm the two to be linked? I would ask there, but I cannot find the issue.

[1skandar]

No it does not, and I have not seen the issue agaih. Sorry.

[TomeWyrm]

@flyingbanana I'm REALLY hoping that was sarcasm, because that level of hostility shouldn't be directed at any modder this baselessly. There are numerous examples of stack traces reporting uninvolved mods that I simply don't have the time to dig up and point out to you. Please quit spreading such malicious misinformation.

Oh, you're a troll that has a hate-on because of the, irrelevant to ANY pertinent subject, preferences and lifestyle of another person you will never meet. Right. Well consider the previous diatribe to be directed at anyone else that is considering this type of baseless accusation in the future: Don't. It just hurts your case.

@31trainman The issue can be reproduced without dragonAPI. That, quite logically makes it not the fault of DragonAPI in ANY WAY. The mod authors of this mod, and DraognAPI have informed you of why it was showing up in the error report, but you seem incapable of accepting this.

@Webzoner97 Can you not read? The bug is not Reika's to fix. It already HAS been fixed in fact, and had nothing to do with Reika. It was a simple mistake and @JamiesWhiteShirt has fixed the error.

Thank you @JamiesWhiteShirt and @lawremi for not falling victim to the drama machine that follows Reika around and tries to stir up trouble.