Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

Zeno410

Members
  • Posts

    6
  • Joined

  • Last visited

Converted

  • Gender
    Undisclosed
  • Personal Text
    I am new!

Zeno410's Achievements

Tree Puncher

Tree Puncher (2/8)

0

Reputation

  1. I seem to have solved my own problem. I added acceptedMinecraftVersions = "[1.9.4,1.11]" to my @Mod annotation, and the mod attempts to run on all three versions. (The mods are a range, not a list, which tripped me up for a while). Since this mod (Geographicraft) interacts only with the GenLayer stack, which is very stable over Minecraft versions (it hasn't changed since 1.8 ) it actually can run on all three versions.
  2. I have a mod, originally compiled in 1.9.4, which is still usable in 10.2 (which is great, one less version to maintain). However, when I try to run in 1.11, I get a "does not wish to run in Minecraft version Minecraft 1.11" error, without a reason. There are no explicit version requirements in the mod code. How is Forge deciding which mod jars are runnable in 1.11, and is there any way to share a jar across that range?
  3. The problem is that it's not protecting against recursion, it's "protecting" against decorating two *different* chunks at the same time. Sure, that occasionally catches a recursion, but from managing all the bug reports that came up, it's less than 10% of the time. Plus, if you get a problematic recursion, it leads to infinite recursion and you get a stack overflow, so it's caught anyway. Recursion without infinite recursion doesn't cause problems - I expect performance is an issue but the chunks come out right, for my mods anyway. If you really want to protect against recursion, you need a completely different procedure where you keep a HashSet of chunks being processed and skip calls to redo ones that are being done (or something similar). I actually ended up doing this, to catch the genuine infinite recursions that came up. I don't think the current check is catching much actually, because any mod with complicated decoration is basically forced to shut the check down. As I said, I was clearing the vars. Highlands has apparently wrapped its calls in a try-catch because I see the stack trace for the call in my console logs. I suspect a lot of other mods are also try-catching their calls but not logging the stack traces.
  4. In the decorateChunk method of BiomeDecorator, there's this little check. if (this.currentWorld != null) { throw new RuntimeException("Already decorating!!"); } This check isn't usually correct, but it causes a lot of trouble in complex world generation code. It's very natural for decoration of one chunk to set off decoration of another chunk, and this goes off even though everything is working just fine. The variable should really be passed to the method rather than being an instanceVar, and maybe that's why this check is in (to deal with re-entrant code). I can manage this in my own code, but I have chronic problems with bugs from other mods which aren't really bugs because if this code wasn't there everything would work. For a long time my solution was simply to erase the currentWorld variable of ALL the biome decorators whenever I ran my procedure, which runs in a post-decoration event, after all the uses of currentWorld are done. This worked nearly perfectly, just to indicate how useless that check is. But, now I'm doing some things in ore generation, and erasing the variables isn't an option, because now some things are using it. So, can Forge code edit out this check? If there's enough of a need for a check against improper re-entrance into the generate chunk routine, then maybe add in a check that's correct.
  5. Underground Biomes replaces all stone, and gets acceptable performance. I have two techniques, although both tend to have incompatibilities with other mods. The original one (originally written by exterminatorJeff) acts during decoration by intercepting BiomeDecorateEvent.Post and replacing the stone there. This method requires only routine Forge calls. It is noticeably slower than vanilla, but quite tolerable if you do your coding right (don't create objects in your innermost loops). However, it's prone to get caught up in the horrible tangle that results from multi-chunk changes in Minecraft chunk-at-a-time generation, and I used to get a never-ending stream of mod interaction crashes. Recently I've tried an ad-hoc system of keeping track of which chunks I'm already modifying and if I get a call to modify one I'm currently modifying I just skip it. Somewhat to my surprise, it worked (I wasn't sure which of the multiple chunks would "count") and it's really cut down on the problems (but not completely abolished them). The other method is to write a wrapper for ChunkProviderGenerate which runs the replace on chunks right after they're made (bypassing the world and neighbor block checks). This is really fast and you can't tell it's there. You have to use reflection to install wrappers onto the ChunkProviderGenerate objects in various worlds, and it is hard sometimes to figure out what to modify. This also creates a interaction problem in that you have to specifically code to manage alternatives to ChunkProviderGenerate used by other mods.
  6. I've signed my main mod file to the Forge event bus, and annotated the handler routine with @EventHandler, but even though the client log says "Sending event FMLModIdMappingEvent to mod UndergroundBiomes", I don't get it. The 1.6 -> 1.7 conversion is simply erasing all my blocks, and I need to look to see what's going on. I've had the same problem with FMLMissingMappingsEvent.
×
×
  • Create New...

Important Information

By using this site, you agree to our Privacy Policy.