Ernio

Just look at callbacks In GuiMultiplayer: private void connectToServer(ServerData server) { net.minecraftforge.fml.client.FMLClientHandler.instance().connectToServer(this, server); } You could assume that you need GuiMultiplayer.

As my predecessor, to clear it up: Particles are "special" entities that are for client ONLY. You can spawn them only from client thread. To spawn them for all player - use Packets (SimpleNetworkWrapper), DataWatcher, or anything that can perform action (TileEntity, Block, whatever). SNW tutorial: http://www.minecraftforge.net/forum/index.php/topic,20135.0.html

This is typical "try over and over again util you succed" case. 1. Setup ClientTickEvent and ClientDisconnectionFromServerEvent. 2. Create some static boolean "shouldAutoReconnect". 3. When you get DC, in your ClientDisconnectionFromServerEvent you can set boolean to true. 4. Use ClientTickEvent to check that boolean, then check current screen (instanceof GuiSomething). 5. Make whatever if statements you need and create some incrementation - make client try to reconnect every e.g 2sec (if conditions are met and you are not ingame) or whatever. 6. Done. If you would need to directly know the moment when client faild to connect you can check if current screen displays error msg. Again - you need to do that per-tick with ClientTickEvent. At least that''s what I'd do.

As for Herbalism - I belive the "age" of crop (includes wheat) is its metadata. EDIT "I belive..." == "It is"

Srsly m8. #jokesOn 1. Think what you are doing. 2. "Oh! I am modding minecraft!" 3. "I wonder where else i can find such 'action'?" 4. "Well, would you look at that! Chat and commands!" 5. Magic happens.... 6. *GuiScreen.class public void sendChatMessage(String msg, boolean addToChat) { if (addToChat) { this.mc.ingameGUI.getChatGUI().addToSentMessages(msg); } if (net.minecraftforge.client.ClientCommandHandler.instance.executeCommand(mc.thePlayer, msg) != 0) return; this.mc.thePlayer.sendChatMessage(msg); } 7. Profit. #jokesOff Yes, executeCommand method.

Not really, EntityPlayer is a "base" of player that is on both logical sides (client and player), then server will use 'MP' and client 'SP' which both have some side-specific methods. There is NO need to cast player to 'MP'/'SP' if you are not using those specific methods. In this case (to get server-side stats) you indeed have to do that. Keep in mind that to cast player to 'MP' you will need to do check: !world.isRemote to make sure yo uare running on server side. As to 'SP' - the class is actually @SideOnly(Side.CLIENT). That means - Dedic.jar doesn't have it (it only exists for Client.jar). Logically - you cannot have ANY reference to in in class that will be ran on server. That's why you need to use proxy if you need 'SP' in e.g tick events (it all really depends on your design, but proxies are common in those cases). Each player has its own "forever" UUID. Yes - basing on UUIDs is data-safe - meaning once you save something with UUID it will always point on one player or entity or whatever. As to "is it good idea?" - no it's not. UUIDs are string-like objects - they are simply slow to compare (like any string). If you can - always pick player instance, if you can't do that - yes, you can use UUID.

UUID, indeed. Save it as two longs into NBT. (not a string).

As a coder working with Forge/MC for years, here's my opinion: NOT gonna happen. This is not ment to be "case closed" saying, but serious, honest opinion. Scripting mods is like, I don't know... making fries from bananas? It might look like a fry, but it is not even a potato. (I know, sick phrasing).

1. setBlockName - now that's a method I haven't seen in a long time, what are you pre-1.6? * block.setUnlocalizedName(name); * In-game name is done by lang files. 2. ISimpleBlockRendering net.minecraftforge.client.model - everything you need For block: ISmartBlockModel most likely. 3. Tess is there and it's working. What changed (long time ago) is that drawing methods got moved to WorldRenderer. e.g Tessellator tess = Tessellator.getInstance(); WorldRenderer wr = tess.getWorldRenderer(); wr.startDrawingQuads(); 4. Damn - that is very old. Anyway - no matter what - it seems you are so outdated that you will have to rewrite most of your rendering code. 5. There are plenty of different collision methods. Depends what do you need and from where? 6. IItemRenderer is deprecated and will never be back again. You WILL have to use new model system. Just to be clear - EVERYTHING that was possible with IItemRenderer IS POSSIBLE with new model system. It's just much more complicated (...or is it? Seriously - once you learn it's easy). Deal with models is pretty clear - you simply pre-generate everything before you render it. Once, sometimes few times. Clear as that. If you need ANY real-time changes there are plenty of model loaders that allow you to bake quads in runtime and edit model in any way you want. Again look - net.minecraftforge.client.model. 7. There is no "onBlockRendering" As stated before - EVERYTHING in existance is now using models. You can pre-generate those models and edit them in runtime. net.minecraftforge.client.model - look.

Particles are client-side.

Do you even know how to start game in eclipse? In (probably) top bar you have "Run" and "Debug" Scroll it down and pick "Server". If it's not there, you most likely setup your workspace wrong as mentioned before. Then (if not): Go to "Run Configurations" and choose "GradleStartServer" as Main class.

Yeah, just start the server. Same for LAN - just launch it like you normally would. If you can't find it (it SHOULD be there by default, if it's not, you might have messed up setup) search for GradleStart and GradleStartServer

http://www.minecraftforge.net/forum/index.php/topic,14048

No, there is no such event. It is possible tho. You can use KeyboardEvent to track if client pressed "enter" && "currentScreen instanceof GuiChat" That way you can pull out textfield with String typed and edit it before performing "enter". You might need reflection to access textfield, I don't remember.

I am not sure where and when you need those, so I'll note everything you need to know: While Client.jar runs client and server logical sides, the Dedic.jar runs only server one. Client connected to some other server (dedic or non-self LAN) will only have client logical side. Classes in client packages are client only. That includes Minecraft.class Using Minecraft.class in ANY PLACE that should be ran on server logical side will break your mod when run on Dedic.jar. And no - simple IF check is NOT enough. You have to setup proxies, you simply cannot have any reference to client classes in server classes. If you need to access stats on server and based on them - modify player's inventory you will need: * Cast entity to EntityPlayerMP, and use this. playerMp.getStatFile() Then you can do whetever you want on server side. You shouldn't bother with client in this case - stuff like items is set on SERVER, so server check will suffice.

Lemme hint some "basics" 1. When you have instance, you don't use class comparing. event.entityPlayer.openContainer.getClass().equals(ContainerPlayer.class) use openContainer instanceof ContainerPlayer 2. As said - for items use "item == item2" 3. Back to issue. Code (tho very messy) seems it should work. The only issue that can actually be there is slot "number". I was digging in containers some time ago - have GOOD look at those slot "IDs" and "numbers" or whatever you call it. You will notice that slot has actually TWO indexes. one is set for slot one for container. You might have messed them up - make sure to fix that if it's the issue. To add more: those 2 "numbers" are "n" and "n+1" - one start from 0 other from 1. I don't really remember, just sayin it is there. EDIT Also, this is wild guess - remember that there are 2 containers - for client and for server. Make sure event and replacing slot is called on both sides, or if not - send packet to do so.

One world can have one WorldProvider. You need to extend it (abstract as diesieben said) and replace normal one ("surface") with yours. To do replacement you use DimensionManager, code needs to be ran in init or post. DimensionManager.unregisterDimension(0); DimensionManager.unregisterProviderType(0); DimensionManager.registerProviderType(0, MyWorldProvider.class, true); DimensionManager.registerDimension(0, 0); Note that this will break compatybility with any world that uses provider overrides.

I will note out all "bad" things in your code and ofc the issue with packets. 1. First things 1st - Java Name Convention (don't use capitals on non-static stuff, etc.) 2. In your player tick event ("public void onPlayerTick(TickEvent.PlayerTickEvent event)"); You are not setting phase - Every tick even has 2 phases - START and END - pick one, otherwise code runs twice per tick. Also - you used static 500 ticks globally, but then you are using them for every player (player tick even is for every player), therefore faster decrementstion ("tick --;") Don't forget to settle that (I know it's beta). 3. EntityPlayerExtended.get(player).sync(); if(!player.worldObj.isRemote){ You could put sync() after check (and remove sync's check) jsut saying 4. if(FMLCommonHandler.instance().getSide() == Side.CLIENT){ BetaManager.doBetaCheck(); network.registerMessage(PacketUpdateClientIEEPData.Handler.class, PacketUpdateClientIEEPData.class, 0, Side.CLIENT); MinecraftForge.EVENT_BUS.register(new OverlayInGame()); } This will not work on dedic, but I guess it is supposed to be that way? (I was checking if you registered msg). 5. I'd also like to note out: "playerLoginEvent(EntityJoinWorldEvent" - don't confuse those - there is separate PlayerLoggedInEvent. Just pointing out. 6. In packet's code: (not static) private static int XP, Level, difficulty; I have no idea for 1.7.10, if it was 1.8 it would be threads problem (thread safety with netty). I had a glance on those ServerPacketManager and events - you are doing some packet reading there, but I don't really get what's the point, could you explain? YOu might be breaking something somewhere where I don't (can't) see it.

You can NEVER EVER use client side classes (including Minecraft.class) in any code that runs on server logical side. Now - I am not sure if server even has resource manager. Most likely - it doesn't. Therefore you would need to load/read you input on your own or from config file.

Not the issue. == compares objects and in this case it literally checks "is this stack the one I am holding right now" so if it true - onUpdate() will only run form item when held. As to issue - I have no bloddy idea i know one thing tho - when you are spawning particles use world.isRemote (particles are client-side).

Nope. 1. Throwables are not LIVING entities. LivingUpdateEvent will not be called on them. 2. You DON'T use events when working with your own code. There is probably only one case when you can make exception ("flattening" code to apply on all entities, not just yours). 3. This is not an event. This is eventually a method inside EntityLiving. Finally: To spawn particles let's say around given bullet you will need to extend EntityThrowable and override: public void onUpdate() Don't forget to call super. Spawnin particles SHOULD happen on CLIENT side only! If your particles are occuring always - you don't need any kind of packets. If you want server to decide about them - you need either DataWatcher applied on Throwable, or dynamic packets. Other way is to use #writeSpawnData to send additional data about entity to client (sent only on spawning/loading entity).

In you Item you override getSubItems method. There you add new ItemStack to a list of subItems that will be then displayed in tab this item is assigned to. ItemStack can be whatever you want - you can add ench, NBT, metadata

Damn, this one was out of the box! Props, will be useful.

There is always only one Block instance per client. Think of Block.class as a "description" of given block, not a block itself. A block in world has 4 bits of data. That gives you 16 possible values, called metadata, which you can set per-block. If you need more you will need to use TileEntity. So if you need one boolean, it will be meta=0 for false, meta=1 for true. Google on how to use metadata, hella lot of it. Also: 1.6.4 is ancient and we don't and can't really support you without you giving any code, so you'll have to figure it on your own.

Alredy told you: xSize and ySize are LITERALLY the width and height of your gui in gui.png. You HAVE TO set them in constructor. Then, GuiContainer.class in its initGui() has this code: public void initGui() { super.initGui(); this.mc.thePlayer.openContainer = this.inventorySlots; this.guiLeft = (this.width - this.xSize) / 2; this.guiTop = (this.height - this.ySize) / 2; } Which will nicely set the position guiLeft and guiTop which are EXACT starting position of your gui.png on screen. If you are overriding initGui() , first thing you do - you need to call super.initGui(). Then you DO NOT use any of your values regarding x/y. You use only guiLeft and guiTop (and maybe others) - I told you, everything is there, internally. As to slots: When adding slots insie your Container class you use x/y (as shown on picture). GuiContainer will place your slots in x/y coords, starting from guiLeft and guiTop - this it's important that you use them and not write your own coordinate handlers.