I am working on a new tree for my dimension. I copied these two classes from the original Minecraft 1.7.2:
WorldGenHugeTrees and WorldGenMegaJungle
to --->
WorldGenHugeCustomTrees and WorldGenMegaCustomJungle
Its working but I want to increase the treetop leaves width. So I changed the number 2 to 4 in these parts of code inside WorldGenMegaCustomJungle:
public boolean generate(World par1World, Random par2Random, int par3, int par4, int par5)
{
int l = this.func_150533_a(par2Random);
if (!this.func_150537_a(par1World, par2Random, par3, par4, par5, l))
{
return false;
}
else
{
this.func_150543_c(par1World, par3, par5, par4 + l, 2, par2Random);
to this --> this.func_150543_c(par1World, par3, par5, par4 + l, 4, par2Random);
Removed code bellow (wrong modification, sorry) And at this code:
private void func_150543_c(World p_150543_1_, int p_150543_2_, int p_150543_3_, int p_150543_4_, int p_150543_5_, Random p_150543_6_)
{
byte b0 = 2;
I ready a lot of topics that this error can occur when you change a block using SetBlock in a non-generated chunk. But, where is the part of tree generation code that checks for this?
I ran into this problem before as well, and the solution I found (from someone else's code, don't recall whose) was to simply surround your call to generate with a try / catch statement such that it can ignore the already decorating error, but still allow it to throw other errors. That solved the problem for me at that time.
Now, however, I avoid the decorate biome events altogether and use the various PopulateChunkEvents for my world gen stuff, and those never seem to have any problems.
I ran into this problem before as well, and the solution I found (from someone else's code, don't recall whose) was to simply surround your call to generate with a try / catch statement such that it can ignore the already decorating error, but still allow it to throw other errors. That solved the problem for me at that time.
Now, however, I avoid the decorate biome events altogether and use the various PopulateChunkEvents for my world gen stuff, and those never seem to have any problems.
Good luck,
coolAlias
yeah, I see.
In fact, I solved before reading your post with this line before putting leaves blocks:
if (world.checkChunksExist(j1,posY, l1,j1,posY, l1)) {
...
}
But I was looking for something inside the code to avoid this.
Anyways, thank you again coolAlias!
There's two levels to this problem. First, Minecraft is storing a method variable for the world in the decorator object when it should be, well, a method variable. The crash is to avert problems when it's decorating two chunks at once.
The second level is that the crashes come when Forge is sending generation events at the end. It happens after all the decoration code has been run, so the decorator can be cleared. Forge passes the world so the event handlers don't need it, not that they should be pawing around in the biome decorator for the world anyway. Forge *could* clear the world variable and stop the crash, but it doesn't.
I had the problem come up in that *another* mod was setting off the crash after my mod had done its work. I fixed it by erasing all the world variables in all the biomes (which is computationally simple compared to what the mod does.) That fixed the problem.
There's two levels to this problem. First, Minecraft is storing a method variable for the world in the decorator object when it should be, well, a method variable. The crash is to avert problems when it's decorating two chunks at once.
The second level is that the crashes come when Forge is sending generation events at the end. It happens after all the decoration code has been run, so the decorator can be cleared. Forge passes the world so the event handlers don't need it, not that they should be pawing around in the biome decorator for the world anyway. Forge *could* clear the world variable and stop the crash, but it doesn't.
I had the problem come up in that *another* mod was setting off the crash after my mod had done its work. I fixed it by erasing all the world variables in all the biomes (which is computationally simple compared to what the mod does.) That fixed the problem.
Thanks for sharing that info man - this particular problem has annoyed the crap out of me for some time. If I'm understanding you correctly, the crash is caused from the World object passed by Forge from the decorator? I mean, I've seen the exception code:
public void decorate(World par1World, Random par2Random, int par3, int par4) {
if (this.currentWorld != null) {
throw new RuntimeException("Already decorating!!");
}
}
But I've never understood why the heck the world object has this strange condition set upon it. So the world object needs to be null each time a chunk decorates, but it can't be null when Forge hooks it, otherwise no one would be able to use it for anything. Would you mind going in to a little more detail?
Just as an example of what I've had to do in some of my code:
@ForgeSubscribe
public void onDecorate(DecorateBiomeEvent.Post event) {
try {
if (event.world.provider.isSurfaceWorld()) {
for (int n = 0; n < Config.getJarClustersPerChunkSub(); ++n) {
if (event.rand.nextFloat() < Config.getJarGenChanceSub()) {
int i = event.chunkX + event.rand.nextInt(16) + 8;
int j = event.rand.nextInt(48) + event.rand.nextInt(48);
int k = event.chunkZ + event.rand.nextInt(16) + 8;
if (j < 60) {
(new WorldGenJars()).generate2(event.world, event.rand, i, j, k, Config.getJarsPerClusterSub(), true);
}
}
}
}
} catch (Exception e) {
Throwable cause = e.getCause();
if (e.getMessage() != null && e.getMessage().equals("Already decorating!!") ||
(cause != null && cause.getMessage() != null && cause.getMessage().equals("Already decorating!!")))
{
;
} else {
e.printStackTrace();
}
}
}
Thanks for sharing that info man - this particular problem has annoyed the crap out of me for some time. If I'm understanding you correctly, the crash is caused from the World object passed by Forge from the decorator? I mean, I've seen the exception code:
public void decorate(World par1World, Random par2Random, int par3, int par4) {
if (this.currentWorld != null) {
throw new RuntimeException("Already decorating!!");
}
}
But I've never understood why the heck the world object has this strange condition set upon it. So the world object needs to be null each time a chunk decorates, but it can't be null when Forge hooks it, otherwise no one would be able to use it for anything. Would you mind going in to a little more detail?
No, Forge isn't doing anything wrong, really, they're just not fixing the Minecraft problem, which they could. The problem is that when Minecraft handles that decorate call, it sets an instance variable in the Decorator object which is used 70 times in the code. It doesn't actually seem to be needed otherwise, so it could be left as a passed method var, with a few additional passings. If two chunks are being decorated at once then they can conflict over that world variable. So Minecraft crashes if the Decorator gets called with that variable set. It may be that they used this crude method to catch a bug or to observe the decorator at work.
Having multiple decorators going is a pretty natural outcome of multiblock decorations in Minecraft which is why it comes up for so many of us. I don't know how Minecraft itself dodges the problem, which it obviously does. I actually expected clearing the var would cause some kind of problem, but it hasn't so far. The big concern I have is that each BiomeDecorator has its own var and - somewhat oddly - it's not easy to figure out which one just called me. So I clear them all. If *that* causes problems someday I'll come back here and look at you guy's solutions. ;-)
Forge doesn't have my problem, because the Forge code edit to send a decorator event occurs after the decorator has done all of its work and right before it clears the world var. So Forge could clear it before sending the event without causing any trouble for Minecraft itself or for the event handlers, which get the world in the event. And Forge knows which one to clear, if indeed there is ever more that one active.
Rollback Post to RevisionRollBack
Geographicraft (formerly Climate Control) - Control climate, ocean, and land sizes; stop chunk walls; put modded biomes into Default worlds, and more!
RTG plus - All the beautiful terrain of RTG, plus varied and beautiful trees and forests.
Thanks again for explaining in more detail. Guess I'll have to look into more than I have, since I never noticed these shenanigans except when they crashed my game xD Cheers!
I thought the answer for vanilla was that it would generate chunks without decorating them. On the edge of the map of my world, I see chunks that have no decorations -- no trees or snow covering if cold -- so the idea is that neighboring chunks get generated (stone ground, then biome tops), and no actual decorations until later.
The easiest way to see something like this seems to be to have a mineshaft generate at the edge of your map -- it will force generation (without population) of lots of chunks.
(In regard to a mod that gives realistic animal genetics):
Would you really rather have bees that make diamonds and oil with magical genetic blocks?
... did I really ask that?
I thought the answer for vanilla was that it would generate chunks without decorating them. On the edge of the map of my world, I see chunks that have no decorations -- no trees or snow covering if cold -- so the idea is that neighboring chunks get generated (stone ground, then biome tops), and no actual decorations until later.
The easiest way to see something like this seems to be to have a mineshaft generate at the edge of your map -- it will force generation (without population) of lots of chunks.
Looking at the code, I think you're right. There are flags being passed around that stop chunk population and a separate routine that populates (re-populates?) the chunk. I can't figure out how it's being controlled, but something like that must be going on, based on your observations and the code.
Rollback Post to RevisionRollBack
Geographicraft (formerly Climate Control) - Control climate, ocean, and land sizes; stop chunk walls; put modded biomes into Default worlds, and more!
RTG plus - All the beautiful terrain of RTG, plus varied and beautiful trees and forests.
I am working on a new tree for my dimension. I copied these two classes from the original Minecraft 1.7.2:
WorldGenHugeTrees and WorldGenMegaJungle
to --->
WorldGenHugeCustomTrees and WorldGenMegaCustomJungle
Its working but I want to increase the treetop leaves width. So I changed the number 2 to 4 in these parts of code inside WorldGenMegaCustomJungle:
to this --> this.func_150543_c(par1World, par3, par5, par4 + l, 4, par2Random);
Removed code bellow (wrong modification, sorry)
And at this code:
to this --> byte b0 = 4;
================================================================
I ready a lot of topics that this error can occur when you change a block using SetBlock in a non-generated chunk. But, where is the part of tree generation code that checks for this?
Want real chalenge and cool mods? My mods:
Amazing Minecraft Mods
†GnR† Slash - Can one man truly make a difference?
I ran into this problem before as well, and the solution I found (from someone else's code, don't recall whose) was to simply surround your call to generate with a try / catch statement such that it can ignore the already decorating error, but still allow it to throw other errors. That solved the problem for me at that time.
Now, however, I avoid the decorate biome events altogether and use the various PopulateChunkEvents for my world gen stuff, and those never seem to have any problems.
Good luck,
coolAlias
yeah, I see.
In fact, I solved before reading your post with this line before putting leaves blocks:
But I was looking for something inside the code to avoid this.
Anyways, thank you again coolAlias!
Want real chalenge and cool mods? My mods:
Amazing Minecraft Mods
†GnR† Slash - Can one man truly make a difference?
Heh, that's probably a better solution anyway, nice work!
The second level is that the crashes come when Forge is sending generation events at the end. It happens after all the decoration code has been run, so the decorator can be cleared. Forge passes the world so the event handlers don't need it, not that they should be pawing around in the biome decorator for the world anyway. Forge *could* clear the world variable and stop the crash, but it doesn't.
I had the problem come up in that *another* mod was setting off the crash after my mod had done its work. I fixed it by erasing all the world variables in all the biomes (which is computationally simple compared to what the mod does.) That fixed the problem.
Geographicraft (formerly Climate Control) - Control climate, ocean, and land sizes; stop chunk walls; put modded biomes into Default worlds, and more!
RTG plus - All the beautiful terrain of RTG, plus varied and beautiful trees and forests.
Thanks for sharing that info man - this particular problem has annoyed the crap out of me for some time. If I'm understanding you correctly, the crash is caused from the World object passed by Forge from the decorator? I mean, I've seen the exception code:
But I've never understood why the heck the world object has this strange condition set upon it. So the world object needs to be null each time a chunk decorates, but it can't be null when Forge hooks it, otherwise no one would be able to use it for anything. Would you mind going in to a little more detail?
Just as an example of what I've had to do in some of my code:
No, Forge isn't doing anything wrong, really, they're just not fixing the Minecraft problem, which they could. The problem is that when Minecraft handles that decorate call, it sets an instance variable in the Decorator object which is used 70 times in the code. It doesn't actually seem to be needed otherwise, so it could be left as a passed method var, with a few additional passings. If two chunks are being decorated at once then they can conflict over that world variable. So Minecraft crashes if the Decorator gets called with that variable set. It may be that they used this crude method to catch a bug or to observe the decorator at work.
Having multiple decorators going is a pretty natural outcome of multiblock decorations in Minecraft which is why it comes up for so many of us. I don't know how Minecraft itself dodges the problem, which it obviously does. I actually expected clearing the var would cause some kind of problem, but it hasn't so far. The big concern I have is that each BiomeDecorator has its own var and - somewhat oddly - it's not easy to figure out which one just called me. So I clear them all. If *that* causes problems someday I'll come back here and look at you guy's solutions. ;-)
Forge doesn't have my problem, because the Forge code edit to send a decorator event occurs after the decorator has done all of its work and right before it clears the world var. So Forge could clear it before sending the event without causing any trouble for Minecraft itself or for the event handlers, which get the world in the event. And Forge knows which one to clear, if indeed there is ever more that one active.
Geographicraft (formerly Climate Control) - Control climate, ocean, and land sizes; stop chunk walls; put modded biomes into Default worlds, and more!
RTG plus - All the beautiful terrain of RTG, plus varied and beautiful trees and forests.
Thanks again for explaining in more detail. Guess I'll have to look into more than I have, since I never noticed these shenanigans except when they crashed my game xD Cheers!
The easiest way to see something like this seems to be to have a mineshaft generate at the edge of your map -- it will force generation (without population) of lots of chunks.
* Promoting this week: Captive Minecraft 4, Winter Realm. Aka: Vertical Vanilla Viewing. Clicky!
* My channel with Mystcraft, and general Minecraft Let's Plays: http://www.youtube.com/user/Keybounce.
* See all my video series: http://www.minecraftforum.net/forums/minecraft-editions/minecraft-editions-show-your/2865421-keybounces-list-of-creation-threads
(In regard to a mod that gives realistic animal genetics):
Would you really rather have bees that make diamonds and oil with magical genetic blocks?
... did I really ask that?
Looking at the code, I think you're right. There are flags being passed around that stop chunk population and a separate routine that populates (re-populates?) the chunk. I can't figure out how it's being controlled, but something like that must be going on, based on your observations and the code.
Geographicraft (formerly Climate Control) - Control climate, ocean, and land sizes; stop chunk walls; put modded biomes into Default worlds, and more!
RTG plus - All the beautiful terrain of RTG, plus varied and beautiful trees and forests.