LexManos

Or you can use server texture packs like you should and be done with it

java -jar {jar name, including .jar extension} Open terminal, navigate to the folder the jar is in, and run it like so.

If that's the case we may be able to optimize some things it shouldn't be that long. The stitching is mostly file io time in all my tests which we can't really fix unless we thread it... but baking the models relies on those stitching... accurate profiling is nessasary.

You have A LOT of different errors listed in there. All of which stem from a sponge function call. MOST of them look like they are simply passing in the incorrect world location which is causing things to freak out. I'm not at home right now so I cant actively dig into the stack, but yes, from the traces and what I know about those functions is that they are passing in the wrong values.

No, its not possible, it's a fundamental break of the entire render engine which was the entire point of the 1.8 update. I care about other devs, I do not care about lazy people who jump on bandwagons instead of applying a small amount of effort and accepting that the world of Minecraft modding is ever evolving. I have answered the question adequately, just because it isn't what you wanted to hear doesn't mean it isn't right.

Long story short, the guy you're talking about is a lazy idiot and jumping on the "I fear change because I don't understand it!" IItemRenderer was removed because a better system was implemented, and modders like him used the old system to SCREW UP end users and cause a hell of a lot of issues because they were to dumb to use it correctly. We're not going to get into another debate on this as its been done to death. He needs to stop blaming others, do his research, everything {literally, even if not 'proper'} that he did with the old system is still possible in the new. And there are tons of PROPER ways to do it in the new system. And on the EXTREMELY RARE chance that it's not able to be done properly {Seriously in the 2 years I have not seen a SINGLE thing you could do with the old stuff that you can't do with the new} He can talk to us and we can help him figure something out. People just like to bitch because they are lazy. End of story.

Back in those days you had 2 mods that added 3 new features now you have 400 mods and 10,000 new features. That takes time to setup

It has nothing to do with compiling, there is no 'compiling' involved in starting mods. Its nearly impossible to save the 'launchable state'. Well technically we could by making a snapshot of the JVM but that would make the game take up like 40GB on disc, and then you'd have 20 mins loading the snapshot. So it's not useful. Its all on modders not doing stupid/slow things at start there isn't much we can do about it.

The question is, why do you think it would be on the classpath? Nothing adds it? Pretty sure that Sponge/Bukkit hide all plugin classes from all other plugins/whatever. You'll have to ask whoever you're using for your Bukkit API on the server. As for the 'Dependancy hell' yes... Minecraft is a dependancy of Mods... that's how it works... And you can't depend on minecraft code from Bukkit plugins that's the entire point. The reason the 'net.minecraft.world.World' class doesn't exist in your server is because it isn't named that. Bukkit uses their own mappings for classes, methods, and fields. When we get Minecraft from Mojang, everything is obfusicated, class names like 'a', 'b', 'aba', We translate them into useable names.

Something on your network is blocking and malforming the mirriors list on our site. I should probably add a user friendly/debug message to that, however if you get an error on this you'll probably get an error on other things. Check your firewalls/whatever.

Also you need a internet connection for the install to work.

Side not why are you writing this for 1.7.10-?

You don't have to change all the settings, just enabled, that being false disables the entire thing. As for whats wrong, a few drivers don't like multi-threaded graphics access. And just dies instead of throwing something useful we can catch and recover from. The loading screen is optional, and is just a nice progress screen instead of a blank window. It's not needed, so disabling it is fine if you have issues. Also, don't necro old threads.

We don't write those mods.. we can't update them.. talk to the author..

You installed a 1.7.10- coremod in 1.11.2, remove them from your mods folder and try again.

And update to at least 1.8.9 there is literally no reason to not be on 1.8.9 as 1.8 mods are compatible with 1.8.9 with very little work if any by the modder.

"Can not perform the specified operation on a file whose user-mapped section open " Some other process on their system has the file held open. This is bad, and most likely a anti-virus or something. HOWEVER Stop using 1.7.10, if you do use it as per the forums rules you're on your own for solving any issues that arise. If you're making a mod pack just freaking update the pack -.-

We will not help you make backdoors into your own mods.

Why? Dont skip over this question like you did twice. Mods shouldn't be phoning home or anything to need users information.

Its float[] https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.html#jvms-4.3.2 Float[] != float[]

its not the same problem so it would not be the same fix. I've just tested 1.10.2 and it works just fine. You have something else wrong in your installation.

No, translations are uppercase in 1.10, so this fix is not needed.

Vanilla only supports vanilla english translations. Obviously it'd be our job to inject modder's english translations. This was area that cpw had written and I didn't know how it was implemented until about 5 mins ago. 1.11 forced lcasing, sorta {big PITA}, hence the simple fix.

Nothing is being used 'wrong' Just a area we missed when doing 1.11''s update: https://github.com/MinecraftForge/MinecraftForge/commit/7c9b67b574836729dd73f04fd49d800a67dd121f Should fix it.

https://github.com/MinecraftForge/MinecraftForge/commit/6ae39ac027146edc9a73d0b22412ee87ec82a9e1