Jump to content

How to alter a vanilla BiomeDecorator?


ziggurism

Recommended Posts

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.

Link to comment
Share on other sites

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

VANILLA MINECRAFT CLASSES ARE THE BEST RESOURCES WHEN MODDING

I will be posting 1.15.2 modding tutorials on this channel. If you want to be notified of it do the normal YouTube stuff like subscribing, ect.

Forge and vanilla BlockState generator.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Please don't PM me to ask for help. Asking your question in a public thread preserves it for people who are having the same problem in the future.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Please don't PM me to ask for help. Asking your question in a public thread preserves it for people who are having the same problem in the future.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

VANILLA MINECRAFT CLASSES ARE THE BEST RESOURCES WHEN MODDING

I will be posting 1.15.2 modding tutorials on this channel. If you want to be notified of it do the normal YouTube stuff like subscribing, ect.

Forge and vanilla BlockState generator.

Link to comment
Share on other sites

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.

Please don't PM me to ask for help. Asking your question in a public thread preserves it for people who are having the same problem in the future.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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

.

Please don't PM me to ask for help. Asking your question in a public thread preserves it for people who are having the same problem in the future.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Apparently I'm a complete and utter jerk and come to this forum just like to make fun of people, be confrontational, and make your personal life miserable.  If you think this is the case, JUST REPORT ME.  Otherwise you're just going to get reported when you reply to my posts and point it out, because odds are, I was trying to be nice.

 

Exception: If you do not understand Java, I WILL NOT HELP YOU and your thread will get locked.

 

DO NOT PM ME WITH PROBLEMS. No help will be given.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Please don't PM me to ask for help. Asking your question in a public thread preserves it for people who are having the same problem in the future.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Announcements



  • Recently Browsing

    • No registered users viewing this page.
  • Posts

    • That looks pretty cool, nice!   Sure, so looking at that JSON file I posted, I pretty much made a record class for each "custom" data type in that JSON. The Input is a good example of why ``` "inputs": [ { "ingredient": { "item": "relativedimensions:aberrant_shard" }, "count": 8 } ], ``` So here's the inputs, it's an array, which we can use the Codec builder's builder.listOf to define an array. Each Item is of some arbitrary object with keys "ingredient" (which we know is an Ingredient) and a "count" which is an int. You don't have to have an intermediate class to map this to necessarily but I found that it's just easier to see the data that way, hence the 'ParticleReboundIngredient' represents one of these inputs.   Let me know if that makes sense or not. 
    • Pretty much, although all the recipes im planning to make on it are shapeless. The idea is that the chamber uses energy to "fuse" the items in each of the center slots together, in this case an ingot. The two slots at the sides are fuel. (A special kind of wood in this case). Here is an image of the interface just for reference (The center slot is the output)   As for the code- Can you elaborate a little bit on it? Seeing three different record classes has confused me a lot. (Elaborate as in why make them in three different records. I understand the code itself more or less)
    • Hello im trying to make a mod and the past few days GSON has almost killed me, when i export the mod and then launch it through minecraft launcher i get java.lang.NoSuchMethodError: com.google.gson.JsonParser.parseString(Ljava/lang/String;)Lcom/google/gson/JsonElement; i have literally tried everything here is my build config   dependencies { minecraft("com.mojang:minecraft:1.8.9") mappings("de.oceanlabs.mcp:mcp_stable:22-1.8.9") forge("net.minecraftforge:forge:1.8.9-11.15.1.2318-1.8.9") compileOnly("cc.polyfrost:oneconfig-1.8.9-forge:0.2.2-alpha+") shadowImpl("cc.polyfrost:oneconfig-wrapper-launchwrapper:1.0.0-beta+") { isTransitive = false exclude(module = "gson") } shadowImpl("org.spongepowered:mixin:0.7.11-SNAPSHOT") { isTransitive = false exclude(module = "gson") } annotationProcessor("org.spongepowered:mixin:0.8.5-SNAPSHOT") shadowImpl("org.javassist:javassist:3.15.0-GA") { isTransitive = false exclude(module = "gson") } shadowImpl("com.neovisionaries:nv-i18n:1.28") { isTransitive = false exclude(module = "gson") } shadowImpl("org.apache.commons:commons-lang3:3.4") { isTransitive = false exclude(module = "gson") } shadowImpl("org.apache.httpcomponents:httpcore:4.4.5") { isTransitive = false exclude(module = "gson") } compileOnly("com.google.code.gson:gson:2.8.6") { isTransitive = false } configurations.all { resolutionStrategy { force("com.google.code.gson:gson:2.8.6") } } shadowImpl(fileTree( mapOf( "dir" to "libs", "include" to listOf("*.jar"), "exclude" to listOf( "asm", "asm-commons", "asm-tree", "gson", "unspecified", "nv-i18n" ) ) )) }  
    • @chxr Looks like you're making some sort of a crafting table / furnace hybrid? Are the inputs needing arranging like a shaped recipe, or is it shapeless? I'll assume it's shapeless since that just adds a lot more complexity. In that case I'd probably do something like this { "type": "relativedimensions:particle_rebound", "inputs": [ { "ingredient": { "item": "relativedimensions:aberrant_shard" }, "count": 8 } ], "fuel": { "tag": "relativedimensions:block/aberrant_fuel" }, "output": { "Count": 1, "id": "relativedimensions:aberrant_ingot" } } inputs: A list of ingredients and how many are needed. The count among each input adds up to 8. Since there's only 1 ingredient, the count is set to 8. fuel: Same thing as before but remove the list and just make it an object with a tag. output: Kept the same.   In this case the Codec I would make is public record ParticleReboundIngredient(Ingredient ingredient, int count) { public static final Codec<ParticleReboundIngredient> CODEC = RecordCodecBuilder.create( builder -> builder.group( Ingredient.CODEC.fieldOf("ingredient").forGetter((i) -> i.ingredient), Codec.INT.fieldOf("count").forGetter(i -> i.count) ).apply(builder, ParticleReboundIngredient::new) ); } public record ParticleReboundFuel(String tag) { public static final Codec<ParticleReboundFuel> CODEC = RecordCodecBuilder.create( builder -> builder.group(Codec.STRING.fieldOf("tag").forGetter(f -> f.tag)).apply(builder, ParticleReboundFuel::new) ); public boolean isFuel(ItemStack stack) { // TODO: Check if fuel item matches the tag } } public record ParticleReboundRecipe(List<ParticleReboundIngredient> inputs, ParticleReboundFuel fuel, ItemStack output) { public static final Codec<ParticleReboundRecipe> CODEC = RecordCodecBuilder.create( builder -> builder.group( ParticleReboundIngredient.CODEC.listOf().fieldOf("inputs").forGetter(r -> r.inputs), ParticleReboundFuel.CODEC.fieldOf("fuel").forGetter(r -> r.fuel), ItemStack.CODEC.fieldOf("output").forGetter(r -> r.output) ).apply(builder, ParticleReboundRecipe::new) ); }   There might be a more proper Codec for the fuel and the tag that's built into minecraft / forge, but I didn't look
    • Tested with 5900X, 64GB 3200 MHz, 3070 Ti, driver 551.86 GPU clock range: 200 - 1950 MHz, usually 210 MHz with 10-30% utilisation on desktop idle use Render settings: Vsync ON, Framerate unlimited, Render distance 32, Fullscreen ON (60hz monitor, so 60 fps with vsync) Vanilla minecraft: Main menu: 210mhz idle clock always, ingame clock around 400 - 1000 mhz with ~30% utilisation and after alt+tab stays at same. Modded install with curseforge app, only said forge added: Main menu: 210 mhz idle clock always, ingame clock around 400 - 1000 mhz with ~30% utilisation, but after alt+tab gpu clock shoots up to 1950 mhz and utilisation is at 50-60% After disabling all render and chunk related stuff in config, after alt+tab it goes up to 1500 mhz. So game turns gpu into space heater when its not even seen. GPU usage returns to expected when game comes back on top. If instead of unlimited fps, fps is set to ~60, then during alt+tab gpu stays at same range as vanilla, but minecraft has horrible limit logic and framerate limit causes lot of tearing, so its not an option. So it seems that when alt+tabbing, for some reason logic no longer takes vsync toggle into account. So expected behaviour would be for it to work like vanilla does. keep rendering in same manner, no matter if its seen and use same amount of resources. Essentially noticed this behaviour while playing Supersymmetry and after elimination testing, result was that only Forge was enough to cause it. And also confirmed it by doing fresh pack with only Forge added, so no other mods even in disabled state. Also happened with both singleplayer and remote multiplayer. Other offender was "Universal Tweaks" which introduced same effect to main menu with its # Removes the hardcoded 30 FPS limit in screens like the main menu B:"Uncap FPS"=true setting, meaning when game was on top, it still worked in limits of vsync cap, but after alt+tabbing even in main menu gpu usage shot up to max.
  • Topics

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.