Shoeboxam

My mod requires four dependencies, so I read the documentation for gradle and pulled a few lines from stackoverflow. Here is the relevant excerpt from my build file: configurations{ customCompile } dependencies { // http://mvnrepository.com/artifact/com.jcraft/jsch customCompile 'com.jcraft:jsch:0.1.53' // http://mvnrepository.com/artifact/org.eclipse.jgit/org.eclipse.jgit customCompile 'org.eclipse.jgit:org.eclipse.jgit:4.3.1.201605051710-r' // http://mvnrepository.com/artifact/org.slf4j/slf4j-api customCompile 'org.slf4j:slf4j-api:1.7.21' // http://mvnrepository.com/artifact/org.slf4j/slf4j-log4j12 customCompile 'org.slf4j:slf4j-log4j12:1.7.21' // http://mvnrepository.com/artifact/log4j/log4j customCompile group: 'log4j', name: 'log4j', version: '1.2.17' compile configurations.customCompile } jar{ from ( configurations.customCompile.collect { it.isDirectory() ? it : zipTree(it)}) { exclude 'META-INF/**' } manifest { attributes 'Main-Class': 'Test' } } My mod compiles with all of the classes for my dependencies bundled inside the jar, but when I actually use code that invokes the slf4j logger via jgit (from a server command while the game is running), I get the following error: Exception in thread "Thread-13" [23:38:03] [Thread-13/INFO] [sTDERR]: [java.lang.ThreadGroup:uncaughtException:1052]: java.lang.NoClassDefFoundError: org/slf4j/LoggerFactory [23:38:03] [Thread-13/INFO] [sTDERR]: [java.lang.ThreadGroup:uncaughtException:1052]: at org.eclipse.jgit.util.FS.<clinit>(FS.java:160) [23:38:03] [Thread-13/INFO] [sTDERR]: [java.lang.ThreadGroup:uncaughtException:1052]: at org.eclipse.jgit.api.Git.open(Git.java:99) [23:38:03] [Thread-13/INFO] [sTDERR]: [java.lang.ThreadGroup:uncaughtException:1052]: at shoeboxam.gitstream.GitManager.pull(GitManager.java:123) [23:38:03] [Thread-13/INFO] [sTDERR]: [java.lang.ThreadGroup:uncaughtException:1052]: at shoeboxam.gitstream.commands.CommandUpdateThread.remote_get(CommandUpdateThread.java:157) [23:38:03] [Thread-13/INFO] [sTDERR]: [java.lang.ThreadGroup:uncaughtException:1052]: at shoeboxam.gitstream.commands.CommandUpdateThread.run(CommandUpdateThread.java:31) [23:38:03] [Thread-13/INFO] [sTDERR]: [java.lang.ThreadGroup:uncaughtException:1061]: Caused by: java.lang.ClassNotFoundException: org.slf4j.LoggerFactory [23:38:03] [Thread-13/INFO] [sTDERR]: [java.lang.ThreadGroup:uncaughtException:1061]: at net.minecraft.launchwrapper.LaunchClassLoader.findClass(LaunchClassLoader.java:101) [23:38:03] [Thread-13/INFO] [sTDERR]: [java.lang.ThreadGroup:uncaughtException:1061]: at java.lang.ClassLoader.loadClass(ClassLoader.java:424) [23:38:03] [Thread-13/INFO] [sTDERR]: [java.lang.ThreadGroup:uncaughtException:1061]: at java.lang.ClassLoader.loadClass(ClassLoader.java:357) [23:38:03] [Thread-13/INFO] [sTDERR]: [java.lang.ThreadGroup:uncaughtException:1061]: ... 5 more The referenced file, org/slf4j/LoggerFactory.class, exists in my mod jar. Is slf4j failing to be included in the classpath? That's why I packed the jar. Please note, if I don't bundle the files via the customCompile, the Minecraft server errors on startup. Any help is appreciated.

Texture pack mod support for 1.4.7 is an insane amount of work to convert to 1.5. I've been looking for a better way to split the files up than breaking them with a script and renaming each file individually. Splitting just Forestry, IC2 and IronChests takes over eight hours and I'm dealing with a mod texture repository of over 100 mods. Aaand keep in mind all texture packs need to follow in the same process. My latest plan is to use and abuse a configuration feature in a third party unstitcher to create a name file for each and every mod sprite sheet. I am somewhat overwhelmed... Is there anything I can do to automate this?

Entoarox, First off, I've been convinced OptiFine and MCPatcher should not be added to Forge and will help kill future repeat suggestions for my penance. Also, you are right, mod support from TPs is not very common. However, mods are not the application of the additional graphics features.

LexManos, there is no need to be hostile. ----------------------------------------------------- I decompiled MCPatcher's code tonight, and I can see where you are coming from. Most of all, I want universal support for more advanced texture editing. Aesthetics are far too overlooked; I want to fix that. Judging by MCPatcher's use of byte code injection, fluff and crashing issues on a loaded client, Mojang is not going to adopt it. Forge is not going to adopt MCPatcher because Forge is only adding API for mods. Point taken. If more control over texture editing is going to be universal, it would have to be lighter. I have experience with programming and have been looking for a mod to make a worthwhile project out of. I will be making a new HD patch from scratch with cleaner code and fewer features to maintain. I'm thinking something Mojang would be comfortable with adopting. When Mojang does add HD support just like you guys here at Forge did, I'd rather TP artists not lose all their teeth. Grum mentioned plans for HD support in the dev chat a few weeks ago. I know there is no current need for another HD patch, so I don't really need to worry about compatability. I'll go ahead and edit base files to avoid bytecode injection. TP artists shouldn't worry about cross-compatability, so I'll likely keep it crippled to prevent popular use. Who knows. Regardless, this is going to be fun! EDIT: You will likely find holes in my plans, would you be kind enough to blast me on them even though this has gone off topic from forge?

*OptiFine doesn't work. -Custom connected textures are not supported -Randomized textures don't work -Custom Colors is missing its teeth, many of its applications do not work -Animations weren't working correctly last time I checked -Better skies is not going to be implemented for a long time -Overall, buggy and unreliable OptiFine as a fill for all this texturing support just doesn't cut it. What is it you don't like about MCPatcher? I am not looking for a flame war here.

Whoa, I was not looking for a fight, nor was I implying you are trying to take everything over. I only wanted to express my concerns about Forge's HD texture pack support. No harm intended.

LexManos, not that I have a problem with Forge just being about bug fixes, but that doesn't seem to be true. I am hearing Eloraam re-wrote the lighting engine for colored lights, is that not a new feature? Given the growing popularity Forge has, the HD features MCPatcher adds may no longer be supported by most clients. Also, consider MCPatcher this way. MCPatcher is the API for texture pack artists. It allows TP artists to edit the look of the game far beyond what was originally available, just like how Forge allows modders access to base classes via hooks. I know most of the people here consider texture packs curtains, but texture packs have a very large appeal in the community. Neglecting full support for them because you don't like MCPatcher would just not be right. Please consider including a kind of equivalent API for texture packs, not just mods. Disclaimer here, I love Forge and respect you, Eloraam and the other modders for the fine work you guys have done. I came here and wrote this to raise awareness that Forge could bring problems to the texture pack community.