I was exploring in a new world and encountered this crash. Brand new 1.12.2 world.

To Reproduce:

1. Create a new world in MC 1.12.2 with the latest MysticalWorld (1.12.2-1.8.2)
2. Explore

Mystic Mods Versions

• MysticalWorld: 1.12.2-1.8.2
• MysticalLib: 1.12.2-1.7.0

Crash Report:
https://paste.dimdev.org/qatacowewi.mccrash

did you mean to close this one?

Yes, I forgot to mention it in the commit message.

Thanks for your work ^^

Goddamn this. 1.8.2 was specifically supposed to fix this completely.

Guess I missed some code. 1.8.3 of Mystical World will be out soon.

This is still occurring on 1.8.3.

https://paste.dimdev.org/cohuwoboto.mccrash

@noobanidus What is the issue though?
Why does this happen in the first place?

Thank you for the detailed explanation.
I do want to see into the inner workings of Minecraft, so it was a nice read.
I understand what you are talking about with the generation and that is quite interesting actually.

On the other hand, I really hope that this can be sorted out properly, because... random issues are never nice. I hate issues that are hard to reproduce as well :/
I'm a programmer as well, so I do know how something like this feels...

Best of luck to you ^^

@fkrisi11 Basically, when the burnt (charred wood) trees in Mystical World are generated, there is a chance that they are generated without having the "world" object refreshed from null. This is possibly because a) null is being passed in (unlikely), or b) due to some race condition, the tree generator's world object is being reset to null while it is in the middle of generating a tree.

The code I'm using is the basic Minecraft large tree generator with the leaves removed (unfortunately there was no real way to implement this as a derivative, so I had to copy it instead). Part of this copy involved the end of the generation function (i.e., once everything had theoretically been generated) resetting the world to null to prevent a vanilla "world leak" (where a copy of the world is stored and thus the world cannot be properly unloaded).

I don't know at which point this world object becomes null and it's not something that I've been able to replicate in a development environment.

However, a fuller awareness of the fact that the world object can be null has allowed me to preface all calls to the aforementioned world object with a null check -- simply cancelling out of the function instead of calling it and causing a crash.

In 1.8.3 I simply did this in the one function that had this crash being reported, as I thought that somehow it was only happening there, but @turabian-luvr 's further crash report indicated that it was actually happening at a variety of points throughout the process -- so many thanks to yourself & to them for helping to sort out the issue.

It could be that I'm failing to use the generator properly. I need to triple-check the code, but it's possible that reusing the generator is not an intended method. There is some mild concurrency (I think) to chunk generation, so it's possible two trees start to generate with the same generator, one finishes and sets it to null, while the other is still ongoing.

I'll try digging into it more in the future. Theoretically while this does mean "less charred trees" (if my hypothesis is correct), in reality it doesn't actually eventuate that way as the game would otherwise crash instead.

Hope that information helps and isn't too technical! Also, my understanding of the system is incomplete, as I mentioned above, so it's entirely possible I'm completely wrong about it.