[ModloaderMP] Mod load ordering issues

MJEvans · Oct 30th 2011

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).

Alblaka · Oct 30th 2011

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

Kane Hart · Oct 30th 2011

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.

MJEvans · Oct 30th 2011

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?

MJEvans · Oct 30th 2011

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

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

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

McFistyBuns · Oct 30th 2011

Quote from MJEvans

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

Display More

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/addit…issues/detail?id=18&can=1

KakerMix · Oct 30th 2011

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.

MJEvans · Oct 31st 2011

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).

Kane Hart · Oct 31st 2011

I might be crazy but usually rebooting it from launch if it errors fixes it.

MJEvans · Oct 31st 2011

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.

KakerMix · Nov 1st 2011

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.

Geo Terra · Nov 1st 2011

TBH I wish that Forge would do away with ModLoader completely, no offense to the author though. I run Linux and this whole ordering problem is just plain annoying.

[ModloaderMP] Mod load ordering issues

Share

Users Viewing This Thread