LexManos

There is no crash there.

Due to a licensing issue some PRs had to be rolled back this is one of them. I'll be deleting the builds for 1.9.4 that were done on the 1.10.0 branch later tonight for now, it's suggested the modder updates or you revert.

Update to 1.9+

Is been fixed, just a small patch shift in the update.

It's been fixed, jsut a slight patch shift in the update.

[08:01:00] [Client thread/WARN]: Texture minecraft:textures/white.png with size 0x0 limits mip level from 4 to -1 That would do it, something is screwed with your texture... We create a generic white 16x16 texture here in code: https://github.com/MinecraftForge/MinecraftForge/blob/92914f82ae1e2ca007bdb9629611d120a4c58fe2/src/main/java/net/minecraftforge/client/model/ModelLoader.java#L865 It shouldn't be an issue. Unless you have a mod in your system that is screwing with rendering.

Just like EVERY fucking update we've ever done. We'll most likely finalize 1.9.4 with one final RB after we finish 1.10 and make it master.

That's not how subclasses and overrides work. Not trying to be insulting but this is a obvious case where you need to go learn some of the basics of java {or any programming} There are plenty of free resources such as MIT classes, Standord has some, and TONS of online tutorials. Going to lock this as there isn't anything more we can do to help you besides advise that you learn a bit more.

Umm, that's a standard java thing it means that the error, and the cause of the error share the same stack at that frame. So no need to display it again because it'll be displayed in the cause stack trace. Google jar signing. It's a method of signing the class files so that people can verify that they are from YOU and have not been modified by someone else. There is a SHIT ton different seriously do you know basic java? Your mod class is an entity what the hell!?! You're not gunna be able to do this right now.

Same Answer

Not sure what is going on here. It should be impossible for this to happen on our code in there. The only way this can happen in a Forge/Vanilla code base is if the mipmaps are set to -1 in one section of the code and > 1 at some other part. Which SHOULD be shown in your log... So ya... not sure what's going on in here...

We have no plans on backporting things to 1.8.9. We are moving forward on 1.10, you guys REALLY need to update. There is only so much time we can support old versions.

1) The Microsoft 'API' will never be a modding API. And will never give 1/10th the power that we have in the java version 2) Forge for 1.10 is done, however we are holding off until we get the last two stranglers for our re-licensing. Or we'll have to figure some other solution. See: https://github.com/MinecraftForge/MinecraftForge/issues/2789#issuecomment-227238452 3) Forge's update, tho a pain in the add on My end is rather small modder facing so there shouldn't be any reason for people to stay on 1.9.4 4) Modders who stay on old versions have their own reasons but mostly they are just lazy. 5) Bitching about updates doesn't make us go any faster. TLDR: Forge 1.10 is done just waiting on some house cleaning.

There is no way to 'compile' modpacks. Without a re-write of the entire mod loading system this will never be possible. As mod typically do thousands of things at startup. You'll just have to deal with it, go get a drink while it starts if your computer is that slow.

You have a coremod installed for an old version of Minecraft, don't do that.

Um, basic math: Left = Right-LengthOfString

No

We've made the error as clear as we can. If they dont understand 'this mod wants a different version of minecraft' then there is no hope for the user. Just use the mechanics we have in place.

Errors are good, if he wants to 'silently ignore' then write his mod class as a slim class and don't do anything if it's the wrong version.

https://github.com/MinecraftForge/MinecraftForge/blob/master/src/main/java/net/minecraftforge/fml/common/Mod.java#L104 You need to use a range notation, what you want is [1.9,1.9.4]

You're doing it wrong this is designed for the API provider to expose an interface. Simple as that. Sub-interfaces are separate capabilities. Deal with it. If the provider wants to support both your capability and some sub-cap of it they can simply do: if (CAP == PARENT_CAP || CAP == CHILD_CAP) return (T)MyCap; Whatever the hell you're doing {you still haven't explained why your consumers are creating sub-caps} is wrong, you should stop doing it. The flaw is not in the cap system it's in your understanding. And you need to stop just "fuck it i'll hack the system because i dont know what im doing and cant explain/understand why the system was designed as it is" Ya, looking at your 'MCIndicators' mod on github your concept is completely wrong, you're trying to wrap the capability system into something it isn't for. What you WANT is to make a IIndicatorList that gathers all the 'indecators' instead of having people go through the capability system.

Looking into it more I found the issue. The issue ISNT what the OP described it was simply that the display name was one career level higher then what they were. So 'Fisherman' was actually a 'Farmer' not that a 'Farmer' was everything else. If he had made that clear i would of known where to look.

I can definitly verify this is NOT a Forge issue, remove any mods your have or try the console command.

Testing locally it all works fine. They have different career levels so they have different names. What exactly are you seeing as your post makes it look like the names are lining up just fine...

Your log clearly states that it does :getFernFlower :decompileMc :fixMcSources :applySourcePatches 9s 529ms :remapMcSources :recompileMc If it's skipped them it means that it doesnt need to run because the result of it is in the cache.