I tried to alter the BiomeDecorator by putting a line like

 

Biomes.ROOFED_FOREST.createBiomeDecorator().bigMushroomsPerChunk = 0;

 

in my mod's init method. Supposed to turn off big mushroom generation in roofed forest biomes.

 

If that seems too easy to work, well it is. It doesn't seem to stick. Is there something else I need to do to "register" this change to the biome decorator? I've seen the method BiomeManager.addBiome() for registering new biome instances. But I didn't see any corresponding method for updating existing biomes, and it seemed to me like that shouldn't be necessary.

 

It's MC 1.10.2 on Forge 12.18.1.2056, though I have also tried older versions and would accept answers for them. Thanks in advance, I welcome any tips on dealing with the BiomeDecorator class in particular, or troubleshooting and tracing Forge functionality more generally.

Try doing it in your preInit method, I will look more into this after you respond saying it doesn't work.

Thanks for the guidance, diesieben07. I suspected something like this was the case, but evidently I was looking at the wrong class to record the changes to the decorator (namely BiomeManager, instead of BiomeEvent).

 

Anyway, looking now at BiomeEvent, I am trying the following (still in my mod's main init method):

 

        Biome roofed_forest = Biomes.ROOFED_FOREST;
        BiomeDecorator roofed_forest_decorator = roofed_forest.createBiomeDecorator();
        BiomeEvent.CreateDecorator biome_event = new BiomeEvent.CreateDecorator(roofed_forest, roofed_forest_decorator);
        roofed_forest_decorator.bigMushroomsPerChunk = 0;
        biome_event.setNewBiomeDecorator(roofed_forest_decorator);

with still no effect on world generation. I feel like I'm still suffering from the same problem: I'm creating a BiomeEvent object and then promptly forgetting it and no one else knows about it. Does some event registry need to record the new event? The comment in the BiomeEvent class says "This event is fired on the {@link MinecraftForge#TERRAIN_GEN_BUS}" and some search results on github for this class contained a line like

 

MinecraftForge.TERRAIN_GEN_BUS.post(biome_event)

 

so I added this line also to my code, but there was no effect, mushrooms still generated. Do I have to put this code updating the BiomeEvent.CreateDecorator in the right place with event handling and such? Like I gather a new BiomeEvent.CreateDecorator object is created each time a new chunk has to be decorated, so my init code isn't being used? What is MinecraftForge.TERRAIN_GEN_BUS?

BiomeEvent.CreateDecorator

is an event, you need create an event handler that subscribes to this event and register it on the appropriate event bus.

 

coolAlias has a tutorial on event handlers here.

Thanks for the advice, Choonster, and thanks for that resource. I had hoped I didn't need to get into the event handler structure of Forge for this, that I could just piggyback off the existing biome decorator code, just with whatever minor tweaks.

 

But after you reply I went through the event handler tutorial and made an attempt at it that way. So now I have the line

 

MinecraftForge.TERRAIN_GEN_BUS.register(new BiomeDecoratorEventHandler());

 

in my mod init method (and have also tried it my CommonProxy) with the event handler class like

 

package com.example.examplemod;

import net.minecraft.world.biome.BiomeDecorator;
import net.minecraftforge.event.terraingen.BiomeEvent;
import net.minecraftforge.fml.common.eventhandler.SubscribeEvent;

public class BiomeDecoratorEventHandler 
{

@SubscribeEvent
public void onDecorateBiome(BiomeEvent.CreateDecorator e)
{
	BiomeDecorator biome_decorator =e.getNewBiomeDecorator();
	biome_decorator.bigMushroomsPerChunk = 0;
	e.setNewBiomeDecorator(biome_decorator);
}
}

 

Which is the event handler structure cited in the tutorial. It still seems to have no effect. Have I missed something obvious? Are there some easy ways to check that the event handler is being successfully registered, and if so, whether/why it's not changing the biome decoration parameters?

 

Thanks again for all the assistance, guys.

Does your init method have @EventHandler annotation?

Which is the event handler structure cited in the tutorial. It still seems to have no effect. Have I missed something obvious? Are there some easy ways to check that the event handler is being successfully registered, and if so, whether/why it's not changing the biome decoration parameters?

 

Put a breakpoint in your event handler method, run Minecraft in debug mode and generate some terrain. If the breakpoint is hit, your event handler is being called.

Hmm for some reason breakpoints don't seem to do anything in my setup. Is there something you need to do to turn on a breakpoint other than doubleclick in the line number gutter, or right-click and choose "toggle breakpoint"? I'm using Eclipse 4.5.1

 

Anyway, breakpoints aside, I can also test whether the method is being fired with some logging statements. The answer appears to be that the onDecorateBiome method is called several dozen times while Minecraft is on the title screen, but not at all during gameplay. In particular, while entering a new chunk and having new terrain get decorated, the method is not called.

 

And to Animefan8888, yes, my init method has the @EventHandler annotation. It was prepopulated there, presumably because of the FMLInitializationEvent...

 

I must be badly misunderstanding how the handling of an BiomeEvent.CreateDecorator is supposed to work. Thanks for the suggestions though.

If i am correct you need to run in debug mode for breakpoints to work, though i never use them much.

Forge does indeed force

BiomeEvent.CreateDecorator

to be fired in postInit for every registered

Biome

's

BiomeDecorator

if it's an instance of

DeferredBiomeDecorator

; I missed this before.

 

As far as I can see, modifying the

BiomeDecorator

returned by

BiomeEvent.CreateDecorator#getNewBiomeDecorator

should work.

 

You shouldn't need to call

BiomeEvent.CreateDecorator#setNewBiomeDecorator

with the

BiomeDecorator

returned by

BiomeEvent.CreateDecorator#getNewBiomeDecorator

, these methods are backed by the same field.

Just to test it a little more, I tried the same exact code but setting the variable biome_decorator.deadBushPerChunk and it worked perfectly. I tried 10 per chunk, 1 per chunk, 0 per chunk, all worked. The logging messages still don't show up as the player loads new chunks, which is weird. Somehow the code is not executing during gameplay? I don't understand. But the deadbushes are missing from my desert.

 

So what conclusion can we draw about biome_decorator.bigMushroomsPerChunk? The big mushroom generating algorithm somehow produces mushrooms even if biome_decorator.bigMushroomsPerChunk=0? But it's not that complicated, we can see the generation in BiomeDecorator.class line 178:

 

        if(net.minecraftforge.event.terraingen.TerrainGen.decorate(worldIn, random, chunkPos, net.minecraftforge.event.terraingen.DecorateBiomeEvent.Decorate.EventType.BIG_SHROOM))
        for (int k2 = 0; k2 < this.bigMushroomsPerChunk; ++k2)
        {
            int l6 = random.nextInt(16) + 8;
            int k10 = random.nextInt(16) + 8;
            this.bigMushroomGen.generate(worldIn, random, worldIn.getHeight(this.chunkPos.add(l6, 0, k10)));
        }

 

Clearly if bigMushroomsPerChunk == 0 then BiomeDecorator.bigMushroomsPerChunk#generate() will be called 0 times, unless I badly understand how loops work, right?

BiomeEvent.CreateDecorator

will only ever be fired in postInit unless someone does something weird. It's normal that it's not fired when generating chunks, I was mistaken in my first post.

 

Setting

BiomeDecorator#bigMushroomsPerChunk

to 0 should prevent any big mushrooms from generating, yes. If you want to stop a feature from generating, I'd recommend subscribing to

DecorateBiomeEvent.Decorate

, checking for

EventType.BIG_SHROOM

and setting the result to

DENY

.

BiomeEvent.CreateDecorator

will only ever be fired in postInit unless someone does something weird. It's normal that it's not fired when generating chunks, I was mistaken in my first post.

Would you be willing to explain in a little more detail? This goes against what I understood to be the whole point of an event-driven model. The code is executed on an "as needed" basis, in response to certain criteria being met. How will new chunks get decorated if this subroutine is not executed?

 

 

Setting

BiomeDecorator#bigMushroomsPerChunk

to 0 should prevent any big mushrooms from generating, yes. If you want to stop a feature from generating, I'd recommend subscribing to

DecorateBiomeEvent.Decorate

, checking for

EventType.BIG_SHROOM

and setting the result to

DENY

.

Yes, let me try this. Thank you for the tip.

BiomeEvent.CreateDecorator

will only ever be fired in postInit unless someone does something weird. It's normal that it's not fired when generating chunks, I was mistaken in my first post.

Would you be willing to explain in a little more detail? This goes against what I understood to be the whole point of an event-driven model. The code is executed on an "as needed" basis, in response to certain criteria being met. How will new chunks get decorated if this subroutine is not executed?

 

BiomeEvent.CreateDecorator is fired when a decorator is instanciated which happens once per decorator.

BiomeEvent.Decorate is fired for every chunk when the decorator.generate() is called.

BiomeEvent.CreateDecorator

will only ever be fired in postInit unless someone does something weird. It's normal that it's not fired when generating chunks, I was mistaken in my first post.

Would you be willing to explain in a little more detail? This goes against what I understood to be the whole point of an event-driven model. The code is executed on an "as needed" basis, in response to certain criteria being met. How will new chunks get decorated if this subroutine is not executed?

 

BiomeEvent.CreateDecorator is fired when a decorator is instanciated which happens once per decorator.

BiomeEvent.Decorate is fired for every chunk when the decorator.generate() is called.

 

Ok and the subscribed event method is triggered on decoriator instantiation, not on execution of

decorate()

, which we can infer because the event method has an argument of type

CreateDecorator

. Ok thanks for clarifying.

I have solved the mystery of why

biome_decorator.bigMushroomsPerChunk

is not stopping big mushroom generation. That loop in

BiomeDecorator#genDecorations

is not the only place that big mushroom generation is invoked. Also in

net.minecraft.world.biome.BiomeForest#decorate

 

    if(net.minecraftforge.event.terraingen.TerrainGen.decorate(worldIn, rand, pos, net.minecraftforge.event.terraingen.DecorateBiomeEvent.Decorate.EventType.SHROOM))
      if (this.type == BiomeForest.Type.ROOFED)
        {
          this.addMushrooms(worldIn, rand, pos);
        }

So I would assume that the loop in

BiomeDecorator

only applies to mushroom island biomes (although I cannot find any lines of code that check for mushroom biomes in this method), and the method in

BiomeForest

populates big mushrooms for roofed forests (here the biome check is obvious in the code). And in fact the code I've been complaining in this thread that it inexplicably doesn't work to remove big mushrooms... well I've only been checking roofed forests. I checked just now for mushroom islands, and it works fine there.

 

As for removing the mushrooms finally for roofed forests, I think Choonster's advice should apply here, since the method is checking the

DecorateBiomeEvent.Decorate.EventType

. Although there's a problem here... the event that should be triggered for big mushrooms is called

BIG_SHROOM

, but the event that's checked in the

BiomeForest

class is

SHROOM

, which is for small mushrooms. But the method

addMushrooms()

is definitely generating big mushrooms. For my purposes it doesn't matter, I'm fine to deny both events. But is this a bug? The big mushroom generation code is checking the wrong event. If this is a bug, whose bug is it, Mojang's or Forge's?

As for removing the mushrooms finally for roofed forests, I think Choonster's advice should apply here, since the method is checking the

DecorateBiomeEvent.Decorate.EventType

. Although there's a problem here... the event that should be triggered for big mushrooms is called

BIG_SHROOM

, but the event that's checked in the

BiomeForest

class is

SHROOM

, which is for small mushrooms. But the method

addMushrooms()

is definitely generating big mushrooms. For my purposes it doesn't matter, I'm fine to deny both events. But is this a bug? The big mushroom generation code is checking the wrong event. If this is a bug, whose bug is it, Mojang's or Forge's?

 

This does seem like a bug in Forge. It should probably be firing the event for both

SHROOM

and

BIG_SHROOM

and determining which mushroom types to generate based on this.

Progress!

 

I now have the following method:

 

	@SubscribeEvent
public void onDecorate(Decorate e)
{
	EventType event_type = e.getType();
	if (event_type == EventType.BIG_SHROOM || event_type == EventType.SHROOM )
	{
		e.setResult(Result.DENY);
		System.out.println("blocked mushroom event of type " + event_type);
	}
}

 

and I am happy to report that it is blocking big mushrooms from generating! In both roofed forests, and in mushroom island biomes, and even if the

biome_decorator.bigMushroomsPerChunk

is left at its nonzero default value. It's also generating logging statements during gameplay as chunks load, in a pleasing way. Thanks for helping me get here, Choonster.

 

There is some bad news however: now no trees at all generate in roofed forests. There are no dark oak trees, no big mushrooms, no trees of any kind, they are as barren as plains (more so, actually, plains come with some trees these days).

 

If you look at the code, this makes sense: the roofed forest dark oak trees are actually generated only after failing the check for large mushroom generation in

net.minecraft.world.biome.BiomeForest#addMushrooms()

line 102. If the

addMushrooms()

never gets called because the

Decorate

event is

DENY

ed, then the dark oak trees will also not generate. This seems like it would be hard to work around. Should I try invoke the tree generation methods myself? The various undeobfuscated variables about tree height and placement are somewhat off-putting. Further advice would be welcome.

I posted the issue to github about the SHROOM event blocking trees, and Lex fixed it the same day and now the mod works perfectly. Thank you everyone for your help.