LexManos

Well you should be able to toss your resources in anywhere along the class path, as long as java knows where it is. Having it in a zip in the mods folder is the simplest method to make sure its in the same configuration as it would be when you do the release. However, you would try making a resources linked folder in eclipse, and make sure that that is treated as a source folder and the files are copied to the bin folder when you debug. There are a bunch of ways to do it, just none to simple or intuitive. Meh, with the way MCP is setup, and everything, doing the repo management from inside eclipse is a pain. As for your languages, there are a few issues, You'll have to have the client tell the server what language it is. And then the server would have to translate in a per-player bases. You may want to write a system where when a player connects, it asks the server for the latest version of the translation file for it's language. And if they are out of sync, the client downloads it from the server. That would allow your admins to write custom phrases and translations, and the client would download it on the fly. Personally, I think that the server should have no concept of language and translation. Except for system messages aimed twards the server admin in the log. If you are wanting something displayed to the client it should only be known to the server as a key.

Toss your resources into a zip and toss them into the jars/mods folder, FML loads that into the class path so you should be able to access them just fine. As for the whole having to get linked folders and stuff into git or svn, just don't use the SVN stuff inside eclipse, Forge just uses a folder inside the MCP workspace as the git root. So you have MCP/Millénaire/{stuff in svn} For the languages, just send the client a key and have them translate it to the full string depending on there selected language. This has the added benefit of minimizing the length text sent to the client.

Thread locked for stupidity and not following rules: http://minecraftforge.net/forum/index.php/topic,20.0.html And if you HAD installed everything in the correct order, it'd work. Unless you're using something that you shouldn't

That's is some ugly ass code. Anyways, this shouldn't be happening and you shouldn't need to edit any classes to stop it. I can not reproduce your issues, I load things only once when they are in the jar. Give me your EXACTLY installed files, and your EXACT install order.

In eclipse you can have linked source files, and debugging in eclipse will pull all source files that are linked and compile them. It only because a issue when you go to reobf, in which case you do exactly what you said, Make copy of MCP/src to MCP/src-bak Copy Mod/Client -> MCP/src/minecraft Copy Mod/Common -> MCP/src/minecraft Copy Mod/Server -> MCP/src/minecraft_server Copy Mod/Common -> MCP/src/minecraft_server Recompile, reobf Del MCP/src Move MCP/src-bak -> MCP/src Small batch file to do that makes it simple.

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'