LexManos

Dont use MCPatcher

We dont support going back to older versions as a option as they have issues. If you use Forge along with a compatible optifine version (the C series, and whatever version works on your computer) then it will work.

Ah, you should look into how minecraft does it, go look at the Crafting table's Container class.

Learn to run the normal game from the command line, if its truly an error you can always get a stack trace. And yes, those ids are unused in vanilla, but may be used by other mods. So ya, get a stacktrace, or we cant do anything.

Ah for keeping data synced post spawn, you would have to use the datawatcher inside your entity. Or do it manually.

Forge does not do ID resolution, whatever tutorial you used was wrong or you misunderstood it. You need to pick ids that are not in use. Hence why configurations and initializing your items properly is a good idea. http://www.minecraftwiki.net/wiki/Data_values#Item_IDs Remember to add 256 to your id to get the id on that chart. As for the exception, show a proper stack trace and we could prolly help.

.... http://lexmanos.no-ip.org:8080/job/Forge/changes

Update/try a different optifine version.

You would find how that custom crafting table stores it's recipe list, and then add to it.... Cant really help much on such a vague question.

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.