Jump to content

ziggurism

Members
  • Posts

    12
  • Joined

  • Last visited

Converted

  • Gender
    Undisclosed
  • Personal Text
    I am new!

ziggurism's Achievements

Tree Puncher

Tree Puncher (2/8)

0

Reputation

  1. 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.
  2. 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.
  3. 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?
  4. 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.
  5. 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? Yes, let me try this. Thank you for the tip.
  6. 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?
  7. 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.
  8. 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.
  9. 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?
  10. 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.
  11. I'd say more like 5-8 months. Jeb announced today on twitter that the new features for 1.11 won't be revealed until Minecon, which is Sept 24th. I guess there'll be some months of snapshots after Minecon. If they get the release out 2 months after Minecon, that's 5 months away. If it's more like last year's bigger release (remember they demo'ed end cities first at Minecon last year), then there will be 6 months of snapshots after Minecon and it'll be out in Feb 2017, which is 8 months away.
  12. In Eclipse, if you want to reorganize your filesystem, you cannot just move your Eclipse project's files on the filesystem. Instead you right-click your project in Package Explorer -> Refactor -> Move, and select the new path (which I learned from stackoverflow). However upon attempting this move with the Minecraft Forge Eclipse workspace, I get a "Move Problems" error dialogue with the error message Could not move /MDKExample Could not move C:\Users\user\forge-1.8.11.14-mdk Could not read from source when writing file C:\Users\user\forge-1.8.11.14-mdk\eclipse\.metadata\.lock The process cannot access the file because another process has locked a portion of the file After clicking through the dialogue, the source and destination of the moves are both left in an unusable state due to the half-completed move of files. Downloading fresh copy and rebuilding the Eclipse workspace with gradlew setupDecompWorkspace && gradlew eclipse, the move fails every time. And I tried with several different versions of Forge. What is the secret to moving a project's location in the filesystem in Eclipse? Windows Process Explorer shows that the only process with this file handle is eclipse itself, and after exiting Eclipse I am able to move the .metadata\.lock file (but not before). Why is Eclipse itself blocking the .lock file for a move? I tried creating a new blank Java project with a single Java class, and Eclipse moved it just fine, so is this problem something particular to Forge? I'm using Eclipse Mars.1 (4.5.1) on Windows 10 with Java 8.
×
×
  • Create New...

Important Information

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