Posts by meiadm

    2012-09-27 02:14:07 [INFO] [STDOUT] [IC2] WARNING: gregtechmod.common.tileentities.GT_TileEntity_AESU@2995209a didn't implement demandsEnergy() properly, no energy from injectEnergy accepted although demandsEnergy() returned true.


    Getting log spam on 1.17a for the AESU, I currently have 1 full and 4 trying to fill it, following a trio getting the output from a fusion reactor in a test setup.
    The 1 full is trying to fill a IDSU. AESU pictured below as MFSU, and IDSU as a HV transformer.



    :MFS-Unit: :MFS-Unit: :Glass Fibre:


    :Glass Fibre: :Glass Fibre: :MFS-Unit: :Glass Fibre: :HV-Transformer:


    :MFS-Unit: :MFS-Unit: :Glass Fibre:



    EDIT:
    After fixing the bottleneck caused at the center AESU, the log spam stopped. So it would appear it has some issues dealing with a full storage unit, and how that gets reported back to IC2.

    2012-09-27 00:29:53 [INFO] [STDOUT] [IC2] WARNING: gregtechmod.common.tileentities.GT_TileEntity_Centrifuge@4807229a didn't implement demandsEnergy() properly, no energy from injectEnergy accepted although demandsEnergy() returned true.


    got that a few million times when I throw something in the centrifuge on my server. ;)


    -edit- I see it's been mentioned before, and will test new version :P


    Downside is that your modification costs +4 Gold and doesn't really change anything. A reactor running with 0 heat and a reactor running with 4 heat are the same thing. Good change for people with OCD maybe. ;) I would have never noticed it was running with 4 heat vs 0 heat though.


    Edit: Although this reminds me of the first time I made a reactor in the 1.2.5 Minecraft. I found a good 0 heat reactor... and turned it on, and immediately started to panic because the thing started to heat up. I couldn't understand why a heat neutral reactor was gaining heat. So I spend a lot of time looking at the design, looking at my setup etc until I finally realized that I guess all the previous reactors had a sort of minimum "operating" temperature. Once the heat got to that level, it stayed at that level though.

    I wondered about that, as well. Would take quite a few times running that reactor before that heat would do anything. Just doing a balancing act really ;)

    I found this golden nugget when doing such a random thing as placing a block of cobble in a lava lake way off from my base:


    This mod throws an exception and crashes the server, when attempted to recharge the electronic thermometer in 1.337. Yet to find any other issues with the new IC version.


    Edit: found the exception:

    Code
    2011-12-05 00:40:59 [SEVERE] Unexpected exception
    java.lang.AbstractMethodError: ItemToolDigitalThermometer.giveEnergyTo(Lhm;IIZ)I
    	at ic2.common.TileEntityElectricBlock.h_(TileEntityElectricBlock.java:127)
    	at eh.e(World.java:1121)
    	at net.minecraft.server.MinecraftServer.h(MinecraftServer.java:366)
    	at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:287)
    	at ce.run(SourceFile:417)

    Last I heard the alphabetical loading only really happened on windows machines. I think removing the file and adding another copy in will force it lower on the list in a *nix environment but i'm not 100% sure there.

    Well, given that java ultimately is the one loading it, I'd hazard a guess at it indexing the mod_modname.class files, which is required for modloader to accept the mod. Java does a system call to get the information iirc, which in windows always is sorted by caps insensitive and alphabetically. Unix systems should always be caps sensitive alphabetically, altough I've not done enough work with java to verify if it returns this in other ways.
    Regardless... a class file must always be named the same as the main class name, and thus a recompile is necessary to test it out.
    doing it this way, if it works, should fix the problem across the board.
    The sad thing is I've yet to find out exactly how modloader sorts it, and can only guess. The reordering by file names on unix seems odd as it occurs to me that it's the same. Only the mod_pluginname.class seems to make up for the discrepancy, hence me asking for a test. I'd love a way to get modloader to load in an order that I decide, possibly through a config file of sorts.


    Edit: bucketfiller did not load in a different order even with a new class name... so much for that idea. Anyone know the developer well enough to ask how this can be ?


    Edit: Well, as I guessed, it has to do with the way the filesystem call returns the list to java. In good news, there is a way to get mods to load after another mod. The bad news ofc, being that it is implemented in the 1.9 version of modloader only. Thus all mods involved needs to be updated to 1.9, and possibly release version before we can use it. However it should fix this issue in the future, if the mods get the appropriate code. :thumbup: :( :love:

    I'm still having issues with loading this on the server. It still gets loaded prior to buildcraft causing severe crashes, and that despite renaming the zip file.
    I got pigalot to try renaming the class of his bucketfiller mod to have an extra z before the name, as it actually got loaded between core and transport. I'm not sure exactly how modloaderMP loads, but it seems that on some systems, a simple rename of the zip is not enough, but possibly forcing the mod_modname-of-choice to be mod_z-modname-of-choice might work. At least, logically, it seems to make sense.


    any chance we could test that theory ?


    Edit: The issue is only on smp, btw, my client loads it fine.

    *headdesk*
    My bad, strongly missread that one.
    Yes, one could make it config-toggleable I guess. and while on it, i will add a hook to always-enable it in SSP (unless Notch implements a thiev-NPC).

    This reminds me of those people stealing ATM's with heavy machinery, taking part of the wall along... Let's hope endermen keep their hands off my safe :P - the sheer picture of one walking off with the safe is hilarious at best :)


    Cheers, that solution seems to solve every scenario :)

    Hmmm...
    Guess either the code itself ore the MCForge oredic is having a problem there.

    That or the oredic isn't implemented in redpower2 yet, thus metadata doesn't exist until Pr3, where it is. Similar issue with the duplicate copper and tin ores.


    Edit: altough it doesn't explain the dust - that is from IC2... I can still only smelt the RP2 ores in regular forges, as well as make wafers. a combination perhaps.