LexManos

Stack trace or it didnt happen. And make sure you install everything int he proper order

Its not thrown.. which is why your compiler is telling you the catch isn't needed.

humm, why is ic2 in your jar? And cleanup your jar things may of gotten wonkey. Start with a fresh jar.

Odd. cuz the latest IS the recomended, but oh well

If you have the latest forge, it has 4096.

Just to note, it looks in the classpath for the file, when you use / it looks in the root of you mods zip folder. Without the / it looks relative to the class that's invoking it, which is the RenderEngine(?) if i recall correctly. So make sure you get your paths correctly.

Same thing.

FMLCommonHandler.instance().getMinecraftRootDirectory(); Will return either the .minecraft folder on the client, or the folder with the server jar in it on the server. I would HIGHLY recommend you append "mods/Millinaire" to that so that you have your data stored in the mods folder. One thing that bugged me about Mill was it sticking things in the root directory, no mod should do that. ROOT/mods/MODNAME/ should be used for data storage ROOT/config/MODNAME/ should be used for user configurations. That way the root directory doesn't get cluttered As for the world folder, I cant rememebr off the top of my head, but this should work: {note written off top of my head, may not compile} public File getWorldFolder(World world) { ISaveHandler save = world.getSaveHandler(); if (world.isRemote) return null; //In SMP no save folder, cuz we arnt server return ((SaveHandler)save).getSaveDirectory(); }

That is the FML log, which in most cases will have a stack trace, but in this case does not. So what you need to do is run MC from the command line and get the proper stack trace as described in the link I gave you.

/AbsoluteArmor.png

Stack trace or ban

What part of update forge didn't you get? http://lexmanos.no-ip.org:8080/job/Forge/136/changes

Humm, I can't seem to find any proper tutorials beyond this. I am not good at writing tutorials, so I leave it up to other people. However if you have specific things I can point you in the proper direction. Registering your entities: MinecraftForge.registerEntity Registering guis: IGuiHandler -> MinecraftForge.registerGuiHandler Sending keys, you'd have to write your own packet handler, and honestly, you'd prolly wanna do that for a lot of other things, so I suggest looking at IConnectionHandler, IPacketHandler. Like i said, give it a poke and if you get to specific parts, ask. One thing you really should remember though, is to separate your logic. So that you only do the real logic when you know that you are the definitive source. {AE: you only set blocks, or things when you're the server, or you're on SSP} As for the incompatibilities, for the most part, most major APIs are compatible with Forge. PAPI, GuiAPI, etc... If we are incompatible with certain apis, we can become compatible. And if its really something important, the author can submit a PR to Forge and get his API cleaned up and used by more users. The point of Forge is to be open source and allow for people to submit things, and have them incorporated. Forge strives for more compatibility and ease of use between mods. As well as keeping in development with what modders need to make there mods better and easier for the end user to use. An example of this would be ISoundHandler, which is a interface that lets you deal with sound events. This allows for many things such as accessibility mods, which allows deaf people to see sound cues. Or ease of use for the end user's by allowing modders to add there sounds directly from inside the mod's zip to remove the need for the end user to do anything more then drop the zip into the mods folder. This required editing the same class that AudioMod edited, so at first, we made it so that things worked properly if someone installed AudioMod alongside Forge, but after more research, found that AudioMod was actually almost completely PaulsCode and improperly attributed. So we incorporated it's opensource parts and gave proper attribution. Therefore giving more credit to the original authors, keeping compatibility, making the install easier for users, and allowing us to have more useful functionality. So ya, I would go to those 15-20% of your users, and ask them exactly which mods/apis are incompatible with Forge. And see if we can resolve the issues. All mods should be solely 'drop this zip in mods folder', and all APIs should strive to be compatible with anything they can and provide unique functionality. I am always willing to have modders come to me and discuss how we can make everything work together.

We determine the mod matching using the mod.toString(), which defaults to getName() + " " + getVersion(). So if you override toString() to only change when you want it to not match. I was thinking of expanding that to something a bit more complicated (NetworkMod.checkModMatch(String)), but nobody has shown any interest in this particular aspect. As for the issue of your users not using forge because it's compatibility issues, in most cases the mod they wish to use either 1) They arnt installing it correctly. 2) Doesn't really need to edit base classes, and the modder should update to Forge. or 3) Its not really a good mod or 4) The modder doesn't care about compatibility. If you're editing base classes, in your mod, you're honestly doing something wrong.

ModLoader.getPrivateValue(EntityEnderman.class, 0)[myBlock.blockID] = true

Disable IC2 sounds, this isn't a forge issue, its them. Jars are exactly the same as zips so they would not cause the issue.

You mean like this or this Not exactly like we're a closed source national secret

Its fairly straight forward: If you're a average user, use the recommended build unless a mod you use specifically tells you to use something higher. If you're a modder: Use the recommended build if you don't care about anything new, but if you do, to you're wanting to suggest something/report a bug. Verify that what you're suggesting/reporting hasn't already been fixed in the latest. How is that difficult to understand? As for flipping out, I'm just really getting tired explaining basic logic to you.

Not unless you're a moron.

Please understand the fucking basic release structure. You introduce a new feature You test it After being tested you release it EXA in forge: You introduce a new feature: 4096, marked as latest/build You test it: People download the latest, if bugs are found, you make new builds After being tested you release it: People test and find that it works, promote to recommended. If you build against something that isn't marked as the recommended build, you just tell your users, 'Get build ###+' That's why we use build numbers, instead of arbitrary numbers. And your excuse of 'Maybe you installed a part of my build.', that's just asinine, do you REALLY think i'm that stupid. do you REALLY think that I would install something of yours and then decompile it and run it in my dev env? And on top of that, mistake it for my own code? Really.. really.. you think i'm THAT stupid? You should be smart enough to understand that if you're suggesting something you should check the latest version to see if we are already doing it. It's like going to blizzard after seeing the cata announcements. And saying, 'Hey you know what you should do, add a dragon!' 'Oh you day you did, are you SRUE you did, cuz in my version you didn't'

Yes I have tried it, along with custom textures and a plethora of custom items/block. They all work fine. Also, thats some horrible design in that mod... And the fact that you even think that it would make a difference where the block is from shows you don't understand what you're talking about.

'it' being the entire project, the server backend, the support experience and experience designing the architecture that will be needed to run this type of thing.

It works perfectly fine, you're just being stupid.

Never said a web browser was hard to make, that is not the parts that i'm saying would be hard...

It is totally replaceable, go learn how!