Bug : Wind eventually becomes fixed forever at a high or low value

  • Analyzing your code for "update wind", I realized that mathematically it will eventually become fixed and stop changing.


    This is because the variables that allow for a change - i and j - decline over time as you hit the limits of the wind ranges (10 and 20).


    Nothing ever raises i or j, so eventually wind will become fixed at ~21 or ~9 and stop changing from then on until the map is reloaded.

  • It's bloody refreshing to see someone make an incorrect statement and not get flamed for it.


    Well done Al

    It is better to remain silent and be thought a fool than open your mouth and remove all doubt

  • Well, I think a lot depends on how it's stated - but yeah, I've taken my share of incoming fire because someone else didn't understand what I was after.
    I think it all comes down to the difference between "mistaken" or "stupid remark" - and the difference is usually pretty clear around here. :)

  • Quite true but if you've spent any time on other mod forums I'm sure you would have seen unnecessarily harsh responses to some reasonable questions. The fact that Al's response was refreshing is a little saddening as it indicates (on the whole) how infrequently it occurs. The IC2 forum seems to avoid this for the most part which is also a very welcome change from the norm.


    So I guess that's well done everyone!

    It is better to remain silent and be thought a fool than open your mouth and remove all doubt

  • Hey in analyzing the code I DID find an interesting result. Your mean wind is really 18.45 instead of 14 or 15 like you might think. A small difference, so unlikely to matter much for game balance, just thought you should know.

  • Hey in analyzing the code I DID find an interesting result. Your mean wind is really 18.45 instead of 14 or 15 like you might think. A small difference, so unlikely to matter much for game balance, just thought you should know.


    Yep, that's because if wind increases it cannot decrease in the same calculation. Hence why you always have an 11% chance of wind increase but to get a win decrease you have to NOT have a wind increase happen and then the 11% chance of the wind decrease.
    All this assuming you are in the 10 - 20 range of wind OFC. Otherwise it's 10% -> 11% or 9% -> 11% or say 11% -> 10% etc etc.

  • Having not seen this code my self (actually I don't even know where to find it... though I didn't look /really/ hard), are you sure that's 11% chance of increase and then 11% of the remaining time it will have a chance of decreasing? Or is this more like a single random-number which is compared and then 11% of the outcomes it goes one way and another 11% it goes the other with 78% of the time no change?

  • Having not seen this code my self (actually I don't even know where to find it... though I didn't look /really/ hard), are you sure that's 11% chance of increase and then 11% of the remaining time it will have a chance of decreasing? Or is this more like a single random-number which is compared and then 11% of the outcomes it goes one way and another 11% it goes the other with 78% of the time no change?


    The code is in mod_ic2.java and the function is updateWind() at line 1381.

  • Is there a repo somewhere that can be checked out, or do we have to set up the whole environment to decompile it?


    decompile, that's all i know of. Though i am sure Alblaka has a repo that is private to IC2 devs.

  • Which decompiler is popular these days? It's been years since I knew of a good one and the last google search I did returned a bunch of stale results of abandoned projects from others who've touched java and then ran for the hills.

  • I use MCP (Minecraft Coder Pack) which can be found here: http://mcp.ocean-labs.de/index.php/Main_Page


    To decompile IC2 you need to install ModLoader, ModLoaderMP, Forge and finally Industrial Craft into a 1.8.1 minecraft.jar and place it in the "jars/bin" folder. Then you run decompile.bat (or decompile.sh on linux) and all source files end up in the "src" folder.
    You WILL get a bunch of errors when you decompile. There will be a set of "HUNK FAILED" messages, for each of those there will be a file created like "classname.java#" where class name is the class that failed.


    I also include the IC 1.23 decompilation fixes: http://forum.industrial-craft.…page=Thread&threadID=1443
    This helps with some things when decompiling 1.337 but you have to manually patch the "mod_ic2.java" file.


    For instance, the patch meant to do this:


    "- public static Block blockCable = new BlockCable(getBlockIdFor("blockCable", 228));"
    "+ public static Block blockCable;"
    Pretty much removing the default value of the initialization. I figured out that doing that doesn't give you the expected results. You are better off commenting out the late assignments in the "static { ... }" clause further down in the file.


    If you don't intend to recompile, then making fixes is needless. Just be aware that if you don't make the fixes then you might have some inconsistent results.


    While i use the patched MCP 4.4 to decompile IC2 1.23 it's not recommended to use it for 1.337 and if you are going to make chances and recompile it's better to make all the fixes manually (and release a .patch file in the addons section if you want to)

  • you dont need MCP for this, all IC2 methods and classes have proper names, decompile class and check whatever you want.


    Yes, but MCP is easier for those who don't have JD-gui etc. It decompiles everything and it makes it easier to follow the source in eclipse since the eclipse workspace that comes with MCP is set up and ready to go.
    Plus, if you fix the decompile errors you can make changes and test them easily. Can't say the same about manually decompiling everything.
    Hence why i suggested MCP.


    EDIT: Oh and MCP de-obfuscates for you. So the few vanilla MC calls made from IC have readable names instead of aa.bb.xyz()

  • Yes, but MCP is easier for those who don't have JD-gui etc. It decompiles everything and it makes it easier to follow the source in eclipse since the eclipse workspace that comes with MCP is set up and ready to go.
    Plus, if you fix the decompile errors you can make changes and test them easily. Can't say the same about manually decompiling everything.
    Hence why i suggested MCP.


    EDIT: Oh and MCP de-obfuscates for you. So the few vanilla MC calls made from IC have readable names instead of aa.bb.xyz()


    That is the one annoying thing about JD-GUI.... It is generally fairly easy to figure out what they are though.