Closed GoogleCodeExporter closed 8 years ago
Ok, kept poking at it and I have a quick and dirty fix!
In Modloader.java, look for line:
File afile[] = file.listFiles();
And add this below:
Arrays.sort
(
afile,
new java.util.Comparator<File>()
{
public int compare(File f1, File f2)
{
return Long.valueOf(f1.lastModified()).compareTo(f2.lastModified());
}
}
);
This sorts the mods by date modified. The mod will always be modified later
than buildcraft. Problem solved with a hack :)
Original comment by pete...@gmail.com
on 15 Oct 2011 at 2:22
This issue is caused by Linux not sending the mod loader an alphabetical list.
You need to make sure that my mod is loaded last. A quick way to do this is to
put it in the Jar as all mods in the jar are read last. Otherwise I have no
idea how to sort the items in the folder in linux (and force it to the
filesystem not a visual change). Maybe remove the mod and install it to the
folder last?
Original comment by brutalvi...@gmail.com
on 15 Oct 2011 at 2:53
It's not obvious what's used to sort the files... it looks completely random.
The method used to enumerate directory entries in Java unfortunately doesn't
guarantee any sort of ordering... it might be sorted by name on Windows, but
the docs certainly don't say that.
I talked to Risugami on IRC and he's considering adding some sort of dependency
checking or mod load ordering to ModLoader for whatever version comes next.
Anyway, the bit of code I posted fixes it for me for now. I'm attaching the two
files changed in ModLoader here. All that's added is the sort. Again, the
proper fix would be a way to tell buildcraft that you want to use texture X for
pipe Y and not having to tweak textures behind its back ~_~
Original comment by pete...@gmail.com
on 15 Oct 2011 at 5:05
Attachments:
That's what I do, but because Core isn't loaded when I go to add my textures to
BC's it fails
Original comment by brutalvi...@gmail.com
on 15 Oct 2011 at 5:41
Original comment by brutalvi...@gmail.com
on 16 Oct 2011 at 5:13
The easiest and quickest resolution is to load the modules in order sorted by
name, by date is good enough, while the most complex solution would be
automatic dependencies. If approached by trial and error (try,
rollback/commit) dependencies would often resolve within just two or three
passes since most mods have one or two layers, and other mods depend only on 'a
whole mod'.
The dependency system might also take advantage of the fact that (ideally) all
mods are trying to be loaded. Thus some kind of small list entry could be kept
that enumerated a mod's given name, and also it's dependencies. As they are
scanned any mods with all dependencies met could be actually loaded. Given
that there are usually only a few dozen mods at max a standard double-linked
list would easily suffice.
As for filesystems returning an ordered list; It is an error to presume that a
random filesystem will provide any ordering at all to the collection returned;
that's not the filesystem's job. Adding that work increases the overhead of
insertions and deletions and very frequently does not matter; either a specific
filename is wanted or the whole list is. If the list is selected it might be
filtered first and then the results sorted.
Original comment by mjevans1...@gmail.com
on 31 Oct 2011 at 7:36
I just added a whole bunch of z's (like 20) on the front of the zip name.
W0rked like a charm.
Original comment by giodamelio@gmail.com
on 11 Nov 2011 at 5:31
Original issue reported on code.google.com by
pete...@gmail.com
on 15 Oct 2011 at 12:40Attachments: