Ernio

DO THE NULL CHECK! As to other stuff: You know that you can use InputEvent.KeyInputEvent and do all that you are doing in ClientTickEvent, just more efficient. Also: MinecraftForgeClient.registerItemRenderer(Mitems.g17, new Renderg17Aim()); WHAT THE HELL. Registering stuff happens ONLY in Mod#init() !!! Make ONE renderer with two cases. 3rd: message.value = 2; What's the point of this? 4th: EntityPlayer player = ctx.getServerHandler().playerEntity; EntityPlayerMP playermp = ctx.getServerHandler().playerEntity; Why? Bro, there is so much bad coding in there I can't comprehend it!

So... where is the problem? You save counter in IEEP and set it to "-1", use LivingHurtEvent to "if (counter < 0) { counter = 0; OPEN-GUI } else DO-NOTHING". Subscribe to PlayerTickEvent - do: "if (counter >= 0) ++counter;" then: "if (counter >= 200) counter = -1;". Done.

You can't do this: heldItem.stackTagCompound.getInteger("zoomed") Without 1st checking if ItemStack has NBT. Default is NULL. Item only has NBT if you assign one. Btw - you know about IExtendedEntityProperties right? Holding data in IEEP would be better (considering you need to know if player is aiming) than in ItemStack, just saying.

You guys sure that IRecipe implementation won't allow that? How about shapeless stuff? (Last time I did recs was in like 1.3 lol)

player.inventory.mainInventory[player.inventory.currentItem] = null; Note: This should be done on server side, so you wll have to update client by settin update boolean to true. player.addChatComponentMessage(new ChatComponentText("Message"));

Question is rather famous "why?". Per-player lag? Client or server side (meaning: which one can you access)? Global lag?

Why do you need tutorial for that? (you can always use google). Task is simple af. You just place additional surrounding blocks in onBlockPlaced of central block. You use few different blocks and their metadata to make proper partial blocks (their orientation). Then in onBlockBreak you check surroundings and also break blocks connected to it.

X and Z dimension of block above 1.0 is not supported. There is no way (without asm) to change that. Y on the other hand allows a little bit expanding (example: fern). How to eal with it? - create multi-block structure with full 1x1 block in middle, 1x0.5 blocks on sides and 0,5x0,5 block in corners.

What did I just write? ( ͠° ͟ʖ ͡°)

If you haven't found it yet: https://github.com/TheGreyGhost/MinecraftByExample/tree/master/src/main/java/minecraftbyexample I don't know why I didn't post it earlier... Should resolve all your basic problems. More info: http://greyminecraftcoder.blogspot.co.at/p/list-of-topics.html

Create Item, implement IInventory. Customize your implementation. Since Item is only "description" of what you are holding - it cannot hold data itself (singleton). What holds data is ItemStack. You can assign NBT with any kind of data to any ItemStack. Save your equipment per-itemStack inside its NBT. For examples (and util methods) lookup vanilla's code (player's inventory for one).

Keys are client-side. Client can't spawn anything. You need to send packet to server telling "this player clicked button". Packet can only contain button id or even noting is button would be static. On server (handler side) you will get player from packet itself (server knows who sent packet) and spawn entity there. http://www.minecraftforum.net/forums/mapping-and-modding/mapping-and-modding-tutorials/2137055-1-7-x-1-8-customizing-packet-handling-with Short: http://www.minecraftforge.net/forum/index.php/topic,20135.0.html

Proper way of handling such stuff is to extend EntityItem with CustomEntityItem (you can also use it do anything else you want, not just rendering). For vanilla items: Subscribe to EntityJoinWorldEvent - check if event.entity instanceof EntityItem, if so - cancel normal spawning and spawn your own CustomEntityItem. Note that while you can cancel joining on both sides (doesn't matter really), the spawning occurs only on server side. For your own: Item#hasCustomEntity and Item#createEntity to spawn a custom EntityItem Next: Extend RenderEntityItem / RenderItem and edit it with what you require. In ClientProxy#init() (NOT preInit), call: RenderingRegistry.registerEntityRenderingHandler(CustomEntityItem.class, new RenderCustomEntityItem()); As of now you can use custom rendering implementation to all items in world replaced by your CustomEntityItem. (You can/don't have to even use model system).

1. So the block is bound (which needs TileEntity) or it displays different things to different players (by using Minecraft#thePlayer)? 2. How many party members there can be? And why do you still call it "party" (confusing), there are much better/cooler words to call your stuff. 3. How advanced will the rendering be?

Since you mentioned: Main data types in minecraft are: Singletons: Item - description of what you hold in hand, Items DON'T hold data, they just "act" on data provided. Block - similar to Items - those just act on data based on their instance, BlockState and TileEntity. "Per-instance": ItemStack - object that is actually being in your hand. ItemStack hold info about what Item it is, along with internal NBT data. internal NBT data consists of stackSize, metadata and CustomNBTData. CustomNBTData is something you can put your stuff into. BlockState - 4 bits of data assigned to position in world. BlockState, often called metadata, can be used to e.g add facing sides to block (like furnace). TileEntity - non-mobile object in world. TileEntity can exist in some BlockPos - you could call it "a layer over position". E.g when you place block you can also make it place TileEntity in its position. TileEntity can hold any data you want. Entity - quite like TileEntity but moving-living. Basically, that's all you need to know. Then there are more events, more packets and extended data (WorldSaveData, IExtendedEntityProperties).

Not quite. 'isRemote' is logical check, @SideOnly is, let's call it "code-check". Anything annotated with @SideOnly will ONLY exist on provided .jar. Minecraft.class is @SideOnly(Side.CLIENT) - that means that Forge will NOT LOAD whole Minecraft.class into Java VM if it somehow appear in Dedicated.jar file (known as minecraft_server.jar). Same goes other way around. If you run a Client.jar - anything marked with Side.SERVER will NOT be present in your environment. Generally - don't use it... like at all (almost no point). Example of when there is a point in doing it: Say you want server to use external SQL database. Why would client do it? In this case you could proxify access - make client use @SideOnly(Side.CLIENT) method that would return data from e.g local .json and server use Side.SERVER methods/classes that would setup SQL database interaction (for dedicated server only). Whole @SideOnly is not needed, but will save you some pointless class-loading.

Yes, most of events are called on both logical sides, isRemote decides which logical side can pass the test. All of data manipulation should happen on server. true = client false = server I am pretty sure I gave good explanation in link provided. (Might take some questions to get it tho )

Apply this to your code (!world.isRemote) - this is one of most important things about MC code design. Block.getBlockById(2) As of 1.7+ - NEVER refere to blocks on per-ID besis. IDs are being assigned on WORLD creation, not on game startup. Each world has its own dictionary, in one world 500 can be something and in other - something else. You should never, ever, in any case, use Item/Block IDs, always instances (e.g.: Blocks.apple). Note that while vanilla IDs are actually static - so no harm here, it's still bad practice (and slower).

event.player.worldObj.setBlockState(state) // figure it out. All code that SETs data should be ran on server side: http://www.minecraftforge.net/forum/index.php/topic,33918.msg178740.html#msg178740 Note: Point 5 applies ONLY if you know java.

PlayerInteractEvent is for interaction, it would be useful if you would need to perform one-time task when clicking on block. In this case - mining in MC is a continuous task. It is being called every tick when you are mining. Also - breakSpeed is player-related (calculated during task) so using this event you could make one player not be able to mine wool, and ther would do that easily. Oh and if you don't know: -1.0F comes from Block#setIndestructible (or something like that), lookup bedrock.

@SubscribeEvent public void onPlayerBreakSpeed(PlayerEvent.BreakSpeed event) { if (event.state.getBlock() == Blocks.wool) { event.newSpeed = -1.0F; } } // Wool is now +/- like bedrock.

Yes indeed, but that only when Item is your custom one (I totally forgot to write that).

This method doesn't solve all cases. EntityItem can be in world without it being tossed, it also is a waste of memory/bandwidth. (EDIT - To post below: I was talking about NBT itself - it is just pointless to use it if you don't have to). Proper way of handling such stuff is to extend EntityItem with CustomEntityItem (you can also use it do anything else you want, not just rendering). Subscribe to EntityJoinWorldEvent - check if event.entity instanceof EntityItem, if so - cancel normal spawning and spawn your own CustomEntityItem. Note that while you can cancel joining on both sides (doesn't matter really), the spawning occurs only on server side. Extend RenderEntityItem / RenderItem and edit it with what you require. In ClientProxy#init() (NOT preInit), call: RenderingRegistry.registerEntityRenderingHandler(CustomEntityItem.class, new RenderCustomEntityItem()); As of now you can use custom rendering implementation to all items in world replaced by your CustomEntityItem. (You can/don't have to even use model system).

I sometimes wonder if people have any level of creativity. Just because I said "You can probably use EntityConstructing event" doesn't mean you have to do it and it's the only way. Yes you can do replacement whenever you want, but you can't do it in EntityConstructing - java won't allow you (seems like it's too soon ). Anyway: public class ExtendedFoodStats extends FoodStats { FoodStats wrapped; public ExtendedFoodStats(FoodStats wrapped) { this.wrapped = wrapped; } @Override public void onUpdate(EntityPlayer player) { // Wrapping allows you to refere to parent stats with not only super, // which would only refere to super-class, but to ANY class that you've replaced. // So if there are two mods modifying FoodStats you (or other mod) would actually wrap around its predecessor. // Which wraps which depends on order of calling. // Eg. this.wrapped.onUpdate() will call object that was there previously. It can be vanilla one, or custom one you've replaced. System.out.println("FOOOOD"); } } What is so hard to understand about object wrapping? And yes - you shouldn't use it in your case - too big of a mod, won't work well with anything else so why bother. public void onEntityJoined(EntityJoinWorldEvent event) { if (event.entity instanceof EntityPlayer) { FoodStats foodStats = ((EntityPlayer) event.entity).getFoodStats(); if (!(foodStats instanceof ExtendedFoodStats)) { foodStats = new ExtendedFoodStats(foodStats); ObfuscationReflectionHelper.setPrivateValue(EntityPlayer.class, (EntityPlayer) event.entity, foodStats, "foodStats", "field_71100_bB"); } } } EDIT: Also, lol me - I didn't read second page of thread, seems like it was resolved

That is what happens when you don't understand how Java (or programming) works. (I wasn't expecting this from you really ) Just making class won't do anything. You need to actually replace FoodStats object in EntityPlayer field. In EntityPlayer there is a field: protected FoodStats foodStats = new FoodStats(); Basically - you need to replace it whenever it is not set yours. Init in Java goes like this: (refresh my memory if not) Static initalization. Instance initialization. Constructor executed. So You can probably use EntityConstructing event to access player#foodStats with reflection and set value to your own. ObfuscationReflectionHelper.getPrivateValue(EntityPlayer.class, event.player, "foodStats", "findSrgInFiles"); Mentioned before object wrapping is passing previous FoodStats (no matter the extension) into your new one. So e.g you can have FoodStatsOfModOne inside FoodStatsOfYourMod.