LexManos

Look at MinecraftForge.registerEntity, and ISpawnHandler. Take a look at PlayerControllerMP.windowClick, it does all the normal things that clicking on a window does but it also sends to the server, that it clicked the window. Yup, in this particular case, it edits the inventory, which on the server signifies that it should send the new slot data to the client. Ever played on a server and gotten your damage values out of sync, had a item in your hand break, but then reappear? This is the exact reason why. However, there are some cases where the code should only be run on one side, and the event is fired on both. In such cases you should use world.isRemote, to determine if you are the authoritative side of the conversation or not. Droping items from blocks is an example, When a block drop is created, it checks world.isRemote, if that is true, it doesn't add it to the world. If it did, the client would see duplicate entities.

There is a ported server, cpw keeps up to date with forge quite quickely. And forge doesnt do a version check between client and server, beyond a few things. Such as the 4096 fix, client and server changes wouldnt matter.

We need to see your fertalize function. If you set the block's metadata properly with notify, then it should instantly show.

Of corse there is no forge on the title screen because you're freakin using a version before that function was added! Just drop everything and use 152, no ModLoader.

The screenshot link is not valid, and there should be no difference between running the error batch, and running normally.

There really sin't an equivalent for entites. But the reason the server sides uses Containers is because the bulk of Vanilla GUIs do exactly the same thing, they have a slot and you move item stacks around. All the container code is vanilla minecraft, nothing to do with forge. the openGUI is just a generic interface that deals with signaling the client that it should open a block related GUI, and signing the server that it should expect the client to have a block related GUI open. A couple of modders have hacked around with the openGui function to do some odd stuff, for example, the EnderStorage uses the X value to send the color code of the bag its opening, and ignores the Y/Z. The X/Y/Z are just ints that are transferred intact to the client without manipulation, so you can use them for whatever you want.

-.- You STILL fail to fucking get a stack trace, when i linked you to the damn tutorial on how to get one. And why the hell are you installing ModLoader or ModLoaderMP you shouldn't use any of those. If you crash, you ALWAYS get a stack dump. We CANT help you without it. If you post again without that dump, I'm going to ban you.

Well your Container on the server can have as much information as you want, as you can make your own subclasses of Container. As for things with the text related field, the server doesn't need to know that it is a GUI at all, it just needs to know that the client has pressed button XYZ. Your best bet would be to setup a communication system between the server and client using the internal messaging system. You can look at Forge's internal handlers in it's code and this. Not the best in the world, but should be able to point you in the right direction.

Well having a full blown file transfer system for your mod from the server isn't to bad of a idea, nor is it particularly difficult. Anyways, All server side GUIs are containers, you will probably have to write something quite special for some of your GUI's. It's been to long since I've played your mod to determine which specific types of GUIs you're referring to. What is your GUI needing to do?

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