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


  • Posts

  • Joined

  • Last visited

Posts posted by keybounce

  1. This happened with Forge 1208. I am aware that this is not latest. This is not repeatable reliably -- I have run this same setup many times without problems, and do not know why it decided to die on me now. EDIT: Potentially, the crash happened in single player when the client ran out of memory.


    Again: My block/item ID mapping was wiped. All ID numbers in the region files were claimed by a different block, so anything not vanilla became something else. Opening a chest resulted in a client D/C. Restoring a copy of level.dat from a backup did recover blocks properly (* but NOT their orientations *) in the overworld and most ages, but the most recently used mystcraft age had horrific wrong blocks.


    This is sufficiently catastrophic (loss of ID map destroying everything) that I felt it should be reported even though it's not latest.




    First, starting up the world in SMP mode. No problems -- everything worked just fine.




    Then, I realized that I was planning on doing long-term chunk profiling -- and trying to run my client by itself will result in a random d/c after somewhere from 30 minutes to 2 hours. (This happens when minecraft falls 25-30 seconds or more behind, and skips ticks to catch up -- the client complains, D/C's, and on reconnect the player's position is far, far away from any place the minimapper remembers getting data for from the server. I don't think this is a forge error; I think this is just chunk generation slowness.)


    So, I stopped the server, and restarted in single player. Startup was no problem. Logs:




    Again, at this point, no problem.


    So now, I start up again, set flight mode, fly off in a diagonal, and plan to come back in the morning with many hundreds of thousands of chunks profiled overnight while I slept.


    After about 30 minutes, the client ran out of memory, and shut down.




    The crash happened at 1 am. level.dat from that timestamp has a broken set of ID mappings in it.

    level.dat from 11:58 pm the previous day has proper ID mappings.

    (no copy between those two timestamps is available)


    ... reviewing that log, I had been under manual control until about 12:40 am, put it on auto-pilot at that point, and it ran out of memory 20 minutes later.


    Again: At this point, the level.dat saved and in Time Machine shows a broken set of block ID mappings, while the one from the previous night just before midnight has a good set of block ID mappings.


    World sharing: The client has a symbolic link from the save directory into the server's directory. Other than getting a different inventory/location when logging in single player than server, everything works fine in both setups.


  2. Where can I find instructions on submitting a pull request to forge?


    (I'm serious: I don't know how to fetch the source, compile it, test it, make changes, and then get those changes sent back to you. What little I understand is that forge is not quite the same as normal mods and has a different behavior, and I have enough trouble getting a github pull request for mods I play around with a lot.)

  3. Additional flaws:


    1. Ice Mountains, despite the name, has the same base height 0.45 and variation 0.3 as all the hills. It should have the hills tag, not the mountains (it is not in the same category with extreme hills).

    2. Mesa Plateau F M and Mesa Plateau M also have the same 0.45 and 0.3. Yet "FM" has no height tag, and "M" has the "plains" tag. (biomes 166 and 167)

    3. "Savanna Plateau M" has the biggest heights in the game -- base 1.05, variation 1.2125, can get really high, yet is only "hills" -- that's like calling the Himalayas "hills".


  4. BiomeDictionary.java has the following registration:

            registerBiomeType(extremeHills,        MOUNTAIN, HILLS                              );


    In MakeBestGuess(), Hills and Mountain are exclusive; all the other extreme hills variants are either hills or mountains.


    Equally, Extreme Hills + (162) and Extreme Hills M (131) are marked as hills, not mountains.




    MakeBestGuess() is using a comparison of height variation against 1.5F. This value being tested used to be the max height (in 164 and earlier); none of the vanilla biomes have a height variation that large in 1.7. Even the savannah variants at 163/164 don't hit that, and they are the largest in vanilla 1.7. I think this test is definitely bugged.


  5. I want to update a mod from 164; the old author is no longer doing modding.


    It's currently working in 164/965; the first step in updating is getting it to work in gradle 164/964. But I can't find what I thought would be a simple set of instructions.


    (At the moment, my mod experience is simple maintenance and patching in 164. Now I want to do a 1710 update).

  6. I want to get the source to a mod (Mystcraft). The mod in question's official policy is: "Decompile it yourself if you want the source".


    But I don't actually know how to decompile / deobfuscate a mod for use with Forge. (Heck, I've actually got access to the dev testing jar, which is non-obfuscated -- but I don't even know how to just plain decompile).


    I figure there must be a tutorial on this, yet I can't seem to find it. Help please?


  7. Right now, for the basic categories in the biome dictionary -- temperature, vegetation, moisture, tree type, nature, and just being land (instead of ocean or river) -- "normal" cannot be queried directly, but has to be a case of excluding everything known.


    That's painful at best, and error-prone (and fails to update) at worst.


    Can entries for "normal" / "default" be added so that there are no more "tag defined by no tag" for the base types?


    In other words, add:







    as tags. And yes, a few of those could use better names.


    ("nature_normal" in particular is painful to test for).

  8. How would you handle biomes such as "beach", or "mushroomhills shore"? Would they be classified as rivers?


    What about swampland -- lots of water surface, for example.


    Where is the distinction between river and ocean -- would it be "Depth of 50 to 58 = river, depth of 49 and lower = ocean"? (I think that excludes swamps and otherwise has reasonable behavior)

  9. Aha. In the system console log:


    Jun 17 19:43:41 keybounceMBP [0x0-0x62062].com.Mojang Specifications.Minecraft.Minecraft[4753]: [19:43:41 INFO]: Finished downloading /Users/michael/Library/Application Support/minecraft/libraries/net/java/jinput/jinput/2.0.5/jinput-2.0.5.jar for job 'Version & Libraries': Local file matches local checksum, using that
    Jun 17 19:43:41 keybounceMBP [0x0-0x62062].com.Mojang Specifications.Minecraft.Minecraft[4753]: [19:43:41 INFO]: Finished downloading /Users/michael/Library/Application Support/minecraft/libraries/com/paulscode/codecwav/20101023/codecwav-20101023.jar for job 'Version & Libraries': Local file matches local checksum, using that
    Jun 17 19:43:41 keybounceMBP [0x0-0x62062].com.Mojang Specifications.Minecraft.Minecraft[4753]: [19:43:41 INFO]: Finished downloading /Users/michael/Library/Application Support/minecraft/libraries/com/paulscode/soundsystem/20120107/soundsystem-20120107.jar for job 'Version & Libraries': Local file matches local checksum, using that


    There's a LOT of lines of "Starting to download ...", followed by these "Finished downloading ...: local file matches checksum". And some interleaving -- after a few checksums are matched, it starts looking at other files as well.


    So, as much as it looks like it is trying to download, it's really just listing each file in turn as it does a checksum validation. UI could be clearer, but it isn't actually downloading after all.

  10. I am using 164, forge 965. Vanilla launcher.


    Every time I want to play, it wants to download files. It works; but it's annoying.


    I cannot tell all of the files it downloads; I can't even find where the vanilla launcher logs its actions. It looks like it is downloading native jars.


    Mac os 10.7.5. Forge 965.


    It does work if I'm offline and nothing can be downloaded.

    It just seems to be downloading even if there should not be a reason to.

  11. I am looking to update a mod from 1.6.2 single player to 1.6.4 multiplayer. Right now, it has a number of cases of attempting to make rendering calls, and makes no attempt to separate server sided from client sided.


    Naturally, this works fine in single player. Less so on a server.


    What do I need to know to stop rendering calls on the server? Other than playing until a crash occurs, and then patching the code that triggered the crash, is there a good way to locate render calls? And is adding @Sided() annotations where needed the best way, or is there a better way to do this?


    Mod in question: Draco's More Decays for Mystcraft: https://github.com/Draco18s/Decaying-World


  12. For 1.6.4, you need Forge in order to use Gradle (which I highly recommend).


    If you have an existing mod, the easiest way to switch to Gradle is to follow Lex's tutorial to create an empty example mod folder, then delete the example mod and just copy your existing source code into the /src/main/java/YourCode folder, and assets into /src/main/resources/assets/your_mod_id/Folders folder. Once you've done that, import it into Eclipse as an existing project and it should work great (make sure to change the values in the build.gradle file for when you export your mod).


    Now for the $128 question: If I'm working with an existing 965 mod, can I turn it into a 964 Gradle mod? Will it load at runtime if the user has 965 and other 965 mods?


    My first project is a tweak to an existing mod (Veo's "Linking Tweaks".).

    My planned next project is a pair of symbols for worldgen options for Mystcraft.


    After that ... comes some choices.

  13. If you are using Gradle, you can easily set up multiple projects in the same workspace; check Lex's tutorial:



    Also, after getting tons of help from GotoLink on using one of his APIs and then writing one of my own, I put together this little piece that you may or may not find helpful:




    Hope that helps!


    I am not using Gradle; this is for 164.


    Hmm ... looking over your tutorial, it seems that Gradle can be used in 164. So ... I've only seen 17x tutorials for Gradle. And none of the mods that I'm working with are Gradle.

  14. Alright, how do I set up a library?


    For a specific example, lets say I wanted to use the Mystcraft API.



    If you have multiple mods at once that you are working on - I've never done this but I imagine you just have different top-level packages for each.

    The goal is multiple small, independent mods. For example, the current (finished) is a tweak to reduce the OP teleportation effect of Mystcraft. Next will be a terrain generator to replicate various vanilla worldgens in mystcraft ages (read: perfect ability to import old worlds, seamlessly, into ages, by calling the appropriate worldgen based on the generator-settings, level-type, and generator-options strings.)


  15. So I'm trying to understand the best practices for organizing code for a mod.


    I'm starting with something simple. I took an existing add-on for another mod, made a change to it, and got it to run happily in Eclipse. Now I'd like to compile it for use in normal Minecraft.


    In the process, as far as I can tell, the recompile/reobfuscate scripts require that all the source code live in one place, underneath forge/mcp/src/minecraft (and typically in the net or org folders under there -- java package names).


    All of my source stuff is going to be elsewhere -- in my case, I'm using one git repository per "thing" (in this case, Linking Tweaks), or one directory per API package (in this case, the Mystcraft API). And, Eclipse is putting all the .class files right next to the .java files (and note that the minecraft .class files are separate from the minecraft source files).


    What is considered "best practices" for organizing the source code for mods, on the assumption that you'll be working on multiple mods, some of which are yours, some are API's of other people, etc., to permit easy compiling, without accidentally modifying stuff you are not supposed to (I already accidentally had a refactor alter the copy of the Mystcraft API I'm using, so this isn't a pointless question.)


    (The tutorials I've seen are all at the "Here's how to make a block", or "here's how to make a recipe" level -- nothing on "Here's how to organize code to keep multiple mods separate and clean".)

  16. I would like help/a tutorial on getting started with modding in 164, for forge 965.


    The tutorial on using forge gradle starts with this:


    This tutorial assumes you have some previous knowledge of Minecraft modding and have gotten all the initial stuff done (PATH variables whatnot).


    I have done nothing with modding before.

    The last time I tried using Eclipse it was difficult (one giant window, with 6 sub windows, all displaying tiny text), and I couldn't even find a tutorial on "how to use Eclipse" -- and I've had people tell me that IntelliJ is better, and I've seen people with much more sensible window/subwindow setups in Eclipse. So I know that E can be made better than 6 tiny subwindows (but I don't know how, or what's a good choice), and I know that there's an alternative.


    But that's the entire state of my minecraft modding exposure.


    I've got a few decades of programming experience; I know java. I don't know forge / fml / gradle. I want to learn how to get started, and what will continue to be good practices into the future (assuming my next target will be 1.8 and skipping 1.7.)


    Where do I start? How do I learn gradle if I've never done anything? Do I need to hunt down a 953 tutorial and start there, and then unlearn what I have learned?

  17. There is a huge difference between knowing how to code, and knowing how to set up a forge development environment and how to make a pull request.


    And even then, this is the suggestions board, not the "here's a proposed improvement to the codebase" area.


    Frankly, the issue gets even better with 174. Imagine regenerating chunks, finding that it's generating a hilly colored clay biome, and in the middle of the mesa there are sandstone buildings 30 or 40 meters down inside the hillside with some airgaps around the edges and the buildings themselves buried... all the more reason to wipe out the old structure data for the chunk before regenerating the chunk.


  18. So tonight, I located an annoying bug. I have been going crazy on this for a few days. It turns out to be a vanilla bug.


    When chunks regenerate, they don't regenerate structures properly. The issue appears to be with entities.


    Specifically, in villages, neither villagers, nor chests in the smithy, nor lecterns in mystcraft huts, will be regenerated. Towns become ghost towns. And while I have not checked temples/pyramids/mineshaft chests/fortress blaze spawners (all of which are entities or tile entities), I do have concerns.


    Yet if the structure file is removed, then everything is regenerated just fine.


    So the idea: Since this appears to be some sort of vanilla bug -- when generating the chunks that have structure information, not everything gets regenerated -- perhaps forge can come up with some way to either fix this (unlikely; it would mean patching every generation routine), or else a way to remove structure entries for a chunk before regenerating that chunk (might be a simple and universal fix).

  19. The problem with macs, J6, and the forge installer leave no traces in the log files.


    The best answer is to update java to J7.


    To do this on the mac: You need to download the JDK -- the development kit. When I attempted to update only the JRE on my mac, it only set itself up for web applets and webstart programs, not for command line, or double clicking.


    With the JDK installed, you can run java 7 with a "standard" java command of "/usr/bin/java". At that point, the forge installers, and minecraft, work just fine.


    Tested with java 7_45; that's what I am now using on my system. And yes, I ran into this issue with Java 6 myself.


    Again: The JRE was not enough for desktop apps on the mac for me. You need the JDK.


  • Create New...

Important Information

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