Pipes have bad textures again in 1.8 and pre-1.9 (got the build from svn)

[GoogleCodeExporter]

What steps will reproduce the problem?
Use the mod on Linux, with (hopefully) nothing messing with the minecraft 
rendering .class files (no HD textures, no opti-whatever).
For some reason, it worked for me in 1.7. No idea why.

Here's a stack trace:
java.lang.NullPointerException
        at mod_zAdditionalPipes.AddImageOverride(mod_zAdditionalPipes.java:230)
        at mod_zAdditionalPipes.ModsLoaded(mod_zAdditionalPipes.java:203)
        at ModLoader.init(ModLoader.java:832)
        at ModLoader.AddAllRenderers(ModLoader.java:186)
        at aam.<init>(aam.java:61)
        at aam.<clinit>(aam.java:10)
        at net.minecraft.client.Minecraft.a(SourceFile:259)
        at net.minecraft.client.Minecraft.run(SourceFile:629)
        at java.lang.Thread.run(Thread.java:662)
http://code.google.com/p/additional-pipes/source/browse/trunk/ClientCode/mod_zAd
ditionalPipes.java#230

So, looking at that, I'd assume that BuildCraftCore isn't there yet, so you 
can't get the texture filename used as a key for map lookup and it throws. 
Alternatively, the index isn't in the map? IDK. I can't get a debugger to look 
at it ... yet ~_~

I went poking around in the code and it's more of a design problem in 
buildcraft than anything else. The new API won't let you redefine the texture 
file for the pipe items and blocks, but only return a number when asked which 
texture to use, leading to the WTFy code needed for overriding the textures and 
problems with modloader not resolving dependencies between mods (can it resolve 
dependencies? is it possible to force mod init order?).

A quick fix could be to override the textures later, when buildcraft is inited 
properly. A proper fix would be to allow stuff derived from Pipe to provide the 
texture (and maybe even painting code/models) for the blocks and items.

Unfortunately, I have no clue about how to compile this stuff :) I've got MCP 
working, but no idea how to add existing mods to it.

What is the expected output?
Properly textured pipes of course!

What version are you using?
1.8 and the package from commit 14

Please provide any screenshots you feel would help demonstrate this
issue/feature.
The pipe blocks are pink and pipe items are invisible in inventory. Not much 
point making more screenshots :/

Original issue reported on code.google.com by pete...@gmail.com on 15 Oct 2011 at 12:40

Attachments:

• ModLoader.txt
• [terminal output.txt](https://storage.googleapis.com/google-code-attachments/additional-pipes/issue-18/comment-0/terminal output.txt)

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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:

• ModLoader.class
• ModLoader$1.class

[GoogleCodeExporter]

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

[GoogleCodeExporter]

Original comment by brutalvi...@gmail.com on 16 Oct 2011 at 5:13

• Changed state: Done

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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