[ModloaderMP] Mod load ordering issues

1st Official Post

    In my case the problem currently occurs before IC2 is even loaded; an addon module wants IC2 to load first, but everything I've tried (naming the files starting 0-9 then in alphabetical sections, and then re-uploading them in the order I want them loaded; etc) has failed to remove the problem that modules are not loaded in either the order I specify (to satisfy dependencies) or to automatically catch errors and retry the remaining modules in a subsequent pass.

    Posting logs of the problem is somewhat meaningless; the required solution is already known to me; I just don't know if there's a properly documented method that is known to always work (instead of behavior that /had/ worked in the past but now does not), or a proper place to report / obtain the loader's offending source and offer a patch (to sort the list of incoming filenames and operate on that).

    Quote from Alblaka

    Nameyour mainfile it something with mod_Z[name]
    Or at least a letter with something past I.

    Yeah wonderful tip I think a lot people been getting owned with this. I was loading advance machines before IC it was crying. So All I did was rename it. But even sometimes rebooting second time works really strange lol.

    Check out Our Brand New GT New Horizons Server .:Here:.
    Check out Our Brand New GT New Horizons Let's Play Series .:Here:.

    Quote from Alblaka

    Nameyour mainfile it something with mod_Z[name]
    Or at least a letter with something past I.

    I already told you I /was/ doing that. I tried letters AND numbers. Does this need to happen /inside/ the .zip file? I have to repack other people's mods instead of renaming their containers?

    Just to try /everything/ all over again....

    Oddly it seems to ignore the outward timestamps, the ctime on the files, the filenames of the files; yet is still repeatable.

    Filenames ls -lrt mods/

    Display Spoiler

    ls -lrt mods/
    total 1004
    -rw-r--r-- 1 root root 71368 Oct 30 22:27 010-buildcraft-server-A-core-2.2.4.zip
    -rw-r--r-- 1 root root 68199 Oct 30 22:27 011-buildcraft-server-B-builders-2.2.4.zip
    -rw-r--r-- 1 root root 60615 Oct 30 22:27 012-buildcraft-server-B-energy-2.2.4.zip
    -rw-r--r-- 1 root root 72911 Oct 30 22:27 013-buildcraft-server-B-factory-2.2.4.zip
    -rw-r--r-- 1 root root 102294 Oct 30 22:27 014-buildcraft-server-B-transport-2.2.4.zip
    -rw-r--r-- 1 root root 109994 Oct 30 22:27 020-RedPowerCore-Server-2.0pr3b.zip
    -rw-r--r-- 1 root root 32896 Oct 30 22:27 021-RedPowerLogic-Server-2.0pr3b.zip
    -rw-r--r-- 1 root root 19079 Oct 30 22:27 022-RedPowerWiring-Server-2.0pr3b.zip
    -rw-r--r-- 1 root root 4191 Oct 30 22:27 023-RedPowerLighting-Server-2.0pr3b.zip
    -rw-r--r-- 1 root root 7007 Oct 30 22:27 024-RedPowerArray-Server-2.0pr3b.zip
    -rw-r--r-- 1 root root 36862 Oct 30 22:27 025-RedPowerWorld-Server-2.0pr3b.zip
    -rw-r--r-- 1 root root 43254 Oct 30 22:27 026-RedPowerMachine-Server-2.0pr3b.zip
    -rw-r--r-- 1 root root 314204 Oct 30 22:27 030-industrialcraft-2-server_1.23.jar
    -rw-r--r-- 1 root root 4940 Oct 30 22:27 101_mod_IC2MobilePump_server.zip
    -rw-r--r-- 1 root root 4383 Oct 30 22:27 102_mod_IC2Thermometer_1.15_server.zip
    -rw-r--r-- 1 root root 8547 Oct 30 22:27 115-EnergyCoupler-0.19-Server.zip


    I removed everything in mods/ then copied the files back over one at a time, in order (via for x in * ; do cp "$x" "destination/$x" ; done)


    ModLoader.txt log

    Display Spoiler

    Oct 30, 2011 10:28:03 PM ModLoader init
    FINE: ModLoader Server Beta 1.8.1 Initializing...
    Oct 30, 2011 10:28:03 PM ModLoader readFromModFolder
    FINER: Adding mods from /home/minecraft/industrialcraft/mods/012-buildcraft-server-B-energy-2.2.4.zip
    Oct 30, 2011 10:28:03 PM ModLoader readFromModFolder
    FINER: Zip found.
    Oct 30, 2011 10:28:03 PM ModLoader addMod
    FINE: Mod Loaded: "mod_BuildCraftEnergy 2.2.4" from mod_BuildCraftEnergy.class
    Oct 30, 2011 10:28:03 PM ModLoader readFromModFolder
    FINER: Adding mods from /home/minecraft/industrialcraft/mods/024-RedPowerArray-Server-2.0pr3b.zip
    Oct 30, 2011 10:28:03 PM ModLoader readFromModFolder
    FINER: Zip found.
    Oct 30, 2011 10:28:03 PM ModLoader addMod
    FINE: Mod Loaded: "mod_RedPowerArray 2.0pr3b" from mod_RedPowerArray.class
    Oct 30, 2011 10:28:03 PM ModLoader readFromModFolder
    FINER: Adding mods from /home/minecraft/industrialcraft/mods/025-RedPowerWorld-Server-2.0pr3b.zip
    Oct 30, 2011 10:28:03 PM ModLoader readFromModFolder
    FINER: Zip found.
    Oct 30, 2011 10:28:03 PM ModLoader addMod
    FINE: Mod Loaded: "mod_RedPowerWorld 2.0pr3b" from mod_RedPowerWorld.class
    Oct 30, 2011 10:28:03 PM ModLoader readFromModFolder
    FINER: Adding mods from /home/minecraft/industrialcraft/mods/010-buildcraft-server-A-core-2.2.4.zip
    Oct 30, 2011 10:28:03 PM ModLoader readFromModFolder
    FINER: Zip found.
    Oct 30, 2011 10:28:03 PM ModLoader addMod
    FINE: Mod Loaded: "mod_BuildCraftCore 2.2.4" from mod_BuildCraftCore.class
    Oct 30, 2011 10:28:03 PM ModLoader readFromModFolder
    FINER: Adding mods from /home/minecraft/industrialcraft/mods/101_mod_IC2MobilePump_server.zip
    Oct 30, 2011 10:28:03 PM ModLoader readFromModFolder
    FINER: Zip found.
    Oct 30, 2011 10:28:03 PM ModLoader addMod
    FINE: Failed to load mod from "mod_IC2MobilePump.class"
    Oct 30, 2011 10:28:03 PM ModLoader addMod
    FINER: THROW
    java.lang.NoClassDefFoundError: ic2/common/ElectricItem

    Blah blah blah; it doesn't matter what else, the error is ic2 hasn't been loaded yet.

    I -believe- the error is in the ModLoader.class (part of the modloadermp server package, but from Ritsugami's modloader?)

    Display Spoiler

    public static void Init(net.minecraft.server.MinecraftServer);
    Code:
    0: aload_0
    1: putstatic #178 // Field instance:Lnet/minecraft/server/MinecraftServer;
    4: ldc_w #41 // class ModLoader
    7: invokevirtual #246 // Method java/lang/Class.getProtectionDomain:()Ljava/security/ProtectionDomain;
    10: invokevirtual #247 // Method java/security/ProtectionDomain.getCodeSource:()Ljava/security/CodeSource;
    13: invokevirtual #248 // Method java/security/CodeSource.getLocation:()Ljava/net/URL;
    16: invokevirtual #249 // Method java/net/URL.toURI:()Ljava/net/URI;
    19: invokevirtual #391 // Method java/net/URI.getPath:()Ljava/lang/String;
    22: astore_1
    23: aload_1
    24: iconst_0
    25: aload_1
    26: bipush 47
    28: invokevirtual #392 // Method java/lang/String.lastIndexOf:(I)I
    31: invokevirtual #393 // Method java/lang/String.substring:(II)Ljava/lang/String;
    34: astore_1
    35: new #65 // class java/io/File
    38: dup
    39: aload_1
    40: ldc_w #394 // String /config/
    43: invokespecial #395 // Method java/io/File."<init>":(Ljava/lang/String;Ljava/lang/String;)V
    46: putstatic #66 // Field cfgdir:Ljava/io/File;
    49: new #65 // class java/io/File
    52: dup
    53: aload_1
    54: ldc_w #396 // String /config/ModLoader.cfg
    57: invokespecial #395 // Method java/io/File."<init>":(Ljava/lang/String;Ljava/lang/String;)V
    60: putstatic #310 // Field cfgfile:Ljava/io/File;
    63: new #65 // class java/io/File
    66: dup
    67: aload_1
    68: ldc_w #397 // String ModLoader.txt
    71: invokespecial #395 // Method java/io/File."<init>":(Ljava/lang/String;Ljava/lang/String;)V

    74: putstatic #236 // Field logfile:Ljava/io/File;
    77: new #65 // class java/io/File
    80: dup
    81: aload_1

    This seems to be the general source of the error: The behavior looks like it's iterating over the /mods/ directory without any sorting or filtering; however this disassembly is too ugly for me to tell.

    82: ldc_w #398 // String /mods/
    85: invokespecial #395 // Method java/io/File."<init>":(Ljava/lang/String;Ljava/lang/String;)V
    88: putstatic #251 // Field modDir:Ljava/io/File;
    91: goto 114
    94: astore_1
    95: invokestatic #400 // Method getLogger:()Ljava/util/logging/Logger;
    98: ldc #18 // String ModLoader
    100: ldc_w #401 // String Init
    103: aload_1
    104: invokevirtual #20 // Method java/util/logging/Logger.throwing:(Ljava/lang/String;Ljava/lang/String;Ljava/lang/Throwable;)V
    107: ldc #18 // String ModLoader
    109: aload_1
    110: invokestatic #184 // Method ThrowException:(Ljava/lang/String;Ljava/lang/Throwable;)V
    113: return
    114: ldc_w #402 // class ek

    117: ldc_w #403 // String au
    120: aconst_null
    121: checkcast #404 // class "[Ljava/lang/Class;"
    124: invokevirtual #217 // Method java/lang/Class.getDeclaredMethod:(Ljava/lang/String;[Ljava/lang/Class;)Ljava/lang/reflect/Method;
    127: putstatic #405 // Field method_getNextWindowId:Ljava/lang/reflect/Method;
    130: goto 150
    133: astore_1
    134: ldc_w #402 // class ek
    137: ldc_w #406 // String getNextWidowId
    140: aconst_null
    141: checkcast #404 // class "[Ljava/lang/Class;"
    144: invokevirtual #217 // Method java/lang/Class.getDeclaredMethod:(Ljava/lang/String;[Ljava/lang/Class;)Ljava/lang/reflect/Method;
    147: putstatic #405 // Field method_getNextWindowId:Ljava/lang/reflect/Method;
    150: getstatic #405 // Field method_getNextWindowId:Ljava/lang/reflect/Method;
    153: iconst_1
    154: invokevirtual #221 // Method java/lang/reflect/Method.setAccessible:(Z)V
    157: ldc_w #402 // class ek
    160: ldc_w #407 // String ch
    163: invokevirtual #185 // Method java/lang/Class.getDeclaredField:(Ljava/lang/String;)Ljava/lang/reflect/Field;
    166: putstatic #408 // Field field_currentWindowId:Ljava/lang/reflect/Field;
    169: goto 185
    172: astore_1
    173: ldc_w #402 // class ek
    176: ldc_w #409 // String currentWindowId
    179: invokevirtual #185 // Method java/lang/Class.getDeclaredField:(Ljava/lang/String;)Ljava/lang/reflect/Field;
    182: putstatic #408 // Field field_currentWindowId:Ljava/lang/reflect/Field;
    185: getstatic #408 // Field field_currentWindowId:Ljava/lang/reflect/Field;
    188: iconst_1
    189: invokevirtual #180 // Method java/lang/reflect/Field.setAccessible:(Z)V
    192: goto 235
    195: astore_1
    196: invokestatic #400 // Method getLogger:()Ljava/util/logging/Logger;

    199: ldc #18 // String ModLoader
    201: ldc_w #401 // String Init
    204: aload_1
    205: invokevirtual #20 // Method java/util/logging/Logger.throwing:(Ljava/lang/String;Ljava/lang/String;Ljava/lang/Throwable;)V
    208: ldc #18 // String ModLoader
    210: aload_1
    211: invokestatic #184 // Method ThrowException:(Ljava/lang/String;Ljava/lang/Throwable;)V
    214: return
    215: astore_1
    216: invokestatic #400 // Method getLogger:()Ljava/util/logging/Logger;
    219: ldc #18 // String ModLoader
    221: ldc_w #401 // String Init
    224: aload_1
    225: invokevirtual #20 // Method java/util/logging/Logger.throwing:(Ljava/lang/String;Ljava/lang/String;Ljava/lang/Throwable;)V
    228: ldc #18 // String ModLoader
    230: aload_1
    231: invokestatic #184 // Method ThrowException:(Ljava/lang/String;Ljava/lang/Throwable;)V
    234: return
    235: invokestatic #312 // Method init:()V
    238: return
    Exception table:
    from to target type
    4 91 94 Class java/net/URISyntaxException
    114 130 133 Class java/lang/NoSuchMethodException
    157 169 172 Class java/lang/NoSuchFieldException
    114 192 195 Class java/lang/NoSuchFieldException
    114 192 215 Class java/lang/NoSuchMethodException

    Let me guess, Linux server? If so, modloader load order is kinda borked right now...
    There may be a work-around here if you're adventerous

    http://code.google.com/p/additional-p…ail?id=18&can=1

    Hi.
    The way people usually get this to work (assuming you are on Linux) is to put all mod-of-mods into the .jar of Minecraft itself. If you were running a Linux Minecraft server with IC2 and Advanced Machines, you'd put the contents of the advanced_machine_server.zip into the minecraft_server.jar. while leaving IC2 in the /mods directory. Minecraft loads everything that is in the .jar last, and since you have all of the mods requiring dependencies on other mods in your .jar they are guaranteed to load after their required mod, assuming their required mod is in the /mods directory still.

    This problem is caused directly my ModLoader and the way it reads load order. It loads files based on how the OS it's running on does it, so on Windows machines it's alphabetical. Linux is (I believe) creation date of the files.

    Quote from KakerMix

    Hi.
    The way people usually get this to work (assuming you are on Linux) is to put all mod-of-mods into the .jar of Minecraft itself. If you were running a Linux Minecraft server with IC2 and Advanced Machines, you'd put the contents of the advanced_machine_server.zip into the minecraft_server.jar. while leaving IC2 in the /mods directory. Minecraft loads everything that is in the .jar last, and since you have all of the mods requiring dependencies on other mods in your .jar they are guaranteed to load after their required mod, assuming their required mod is in the /mods directory still.

    This problem is caused directly my ModLoader and the way it reads load order. It loads files based on how the OS it's running on does it, so on Windows machines it's alphabetical. Linux is (I believe) creation date of the files.

    Worse, Linux is like DOS in that it lists them off in the order they happen to be found by the filesystem. If you want things to be a /sorted/ collection you're supposed to do that your self by whatever metrics matter to you. (This of course makes sense from a design perspective; it isn't the operating system's job to do un-necessary work; if you wanted it sorted the standard library has the same routines it would have used had that been the design; you're free to call them your self if it's desired.)

    So yeah, that'd directly be modloader being broken instead of sorting the results it's self (or at the VERY least allowing a static list of 'must load these first/in order' in it's config file).

    You're crazy. The ordering is static and repeatable; yet has no reliable correlation to file time or name. Having given my above explanation I can however make a slightly educated guess that it's most likely related to the /hash/ of the filename used as the key for storing the file's information. This would explain the observed behavior perfectly.

    Quote from MJEvans

    Worse, Linux is like DOS in that it lists them off in the order they happen to be found by the filesystem. If you want things to be a /sorted/ collection you're supposed to do that your self by whatever metrics matter to you. (This of course makes sense from a design perspective; it isn't the operating system's job to do un-necessary work; if you wanted it sorted the standard library has the same routines it would have used had that been the design; you're free to call them your self if it's desired.)

    So yeah, that'd directly be modloader being broken instead of sorting the results it's self (or at the VERY least allowing a static list of 'must load these first/in order' in it's config file).

    This is beyond my understanding but people I know that are smarter at this stuff put the blame squarely on ModLoader as you say. Unfortunately for us, the creator of ModLoader doesn't seem to care at all and has been asked by multiple people, especially the Forge team, if he can put in the fix for it. Time will tell if we can convince the Forge team to either alter ModLoader to put in an actual load order component in or if Forge does away with ModLoader entirely.