EverythingGames

Are you storing NBT in an itemstack? Itemstack NBT is updated by vanilla Minecraft (synced) with the server and the client automatically. You could try using IEEP (IExtendedEntityProperties) to save teleporting coords to the player when right clicking with your item and then syncing your data on the EntityJoinWorldEvent. Look it up on google if you choose to do it that way. As for the itemstack NBT I do not see why that wouldn't sync.

Return "this" in IPerspectiveAwareModel. Why not just "break" instead of returning the Pair for every transform type? Also, RenderItem.applyVanillaTransform will apply GL from the model you specify (watch for what you return there).

This is a horrible idea. Think again. Please elaborate. public class TestItem extends Item { //One use (decrements your stack upon use i.e destroying the item depending if your stack size is 1) @Override public ItemStack onItemRightClick(ItemStack itemStackIn, World worldIn, EntityPlayer playerIn) { playerIn.inventory.consumeInventoryItem(this); //You can use itemStackIn.stackSize--; here - this demonstrates using with the player instance return itemStackIn; } } EDIT: I see what you mean after some more testing - this will not work due to the fact that consumeInventoryItem decrements the itemstack's stacksize at the nearest stack in the player's inventory (meaning sometimes not the item you are holding i.e another stack of the same item located in your inventory). Sorry about that - misinterpreted what that method really does. @OP I would stick with the crafting table damage to get 1 use.

Just how? Like mentioned above, you would add / edit the armor layers / armor rendering. Try looking into the RenderPlayerEvent - all rendering for the player is done there, including armor rendering (pretty sure - look into ModelPlayer.class and RenderPlayer.class to find more info on the biped layers for the player). Also, look at LayerBipedArmor.class and LayerArmorBase.class. Maybe you could create a new player model with the player's skin, 3 / 4 pixel arms, and armor (except the armor is made red) and cancel the vanilla model in the RenderPlayerEvent. I've done similar, it can be done.

If you want your item to be destroyed upon one use, just listen for when you use your item (however you handle that), and if you did use it, you can destroy that item manually in code, giving you one use. entityPlayer.inventory.consumeInventoryItem(THEITEMYOUWANTTODESTROY);

You probably haven't dealt with reflection. This is exactly what you need here, as pointed out above, so read up on some tutorials. That should get rid of that nasty Access Transformer.

I would increment a ticker right after subscribing to the LivingDeathEvent. Check the instance of the entity in the LivingDeathEvent against the EntityPlayer, then increment your counter in ticks (use another event, such as the ClientTickEvent - remember to check the player instance and event.phase == Phase.Start or Phase.END, otherwise your code runs twice per tick). This way, you have complete control of when your counter increments and when it stops.

[23:56:05] [Client thread/INFO] [FML]: FML has found a non-mod file [1.8]DrVaders Robot Pet Mod-1.0.jar in your mods directory. It will now be injected into your classpath. This could severe stability issues, it should be removed if possible. Did you put anything in your Mods folder, found in your mod dev folder? I've seen this happen when you throw a mod (zip file / jar) into the mods folder (a non-deobfuscated file). Really, what have you in there?

This works when you return 0.0F - if you are in survival. My item does not need to be able to interact with blocks (or blocks with inventory / other capabilities on left / right click). diesieben07 gave the perfect solution, MouseEvents. This stops vanilla packets from being sent and rendering / particles from being spawned on the client. Perfect solution, considering the personal MouseListener I wrote for Forge is uninterrupted by canceling vanilla Mouse actions. Thanks for the help.

This couldn't make any more sense. Your saying have a Main class with the "@Mod" annotation, including its several parameters, yet Forge / FML is not recognizing your Mod as a Mod. What is happening in the console? Did you even look in the "Mods" button at the Minecraft Main Menu? That is very basic - check the mods button, post the log, and show us your code (Main class).

I need to be able to have an item that cannot break any blocks - that can be achieved with events or overriding the Item class' methods. However, the server is still telling the client to render the break animation (the block's break stages), and the client is also still spawning block-break particles. Is there a way to cancel everything before the block is broken (kind of like when the block is first clicked) so that it looks seamless as though the player had not clicked at all? I know ItemSword does this, although I cannot find any place where ItemSword is referenced in the Call Hierarchy (besides where instances of it are created for registration). If someone could please elaborate on how I would get this done, I would appreciate it Thanks.

I actually ended up writing listeners that you implement. Pretty much like an event (considering the Listener you implement event handles for you), except unlike an event, you extend the specific Listener class and it gives you a few methods (depending on the listener type) that you must override. For example, I have a ListenerClientMouse class extending ListenerClient (which ultimately extends Listener, except ListenerClient is client side only, obviously). The ListenerClientMouse listens for when the user is holding down the mouse, when the mouse is not being held down (not doing anything), when the mouse was clicked (semi-automatic mouse click), and finally when the mouse was released (semi-automatic mouse released). Using the 'MouseListener' that I wrote, I can now easily send a packet to the server once per click (regardless if user is holding, the method is called only once meaning only one packet is sent), and once per release (again, only called one, only one packet sent). A boolean is set upon click / release in IEEP and checked on the PlayerTickEvent. Everything worked like a charm, though it seemed like too much effort for a bit of optimization. The code is similar to the code shown above.

Wrong. EntityJoinWorldEvent is triggered by all entities joining the world, hence the name. Subscribe to the EntityJoinWorldEvent, check the instance of the AbstractClientPlayer against the event.entity, and then cast and do whatever you need. Remember, changing the skin with reflection during the EntityJoinWorldEvent will result in a NullPointerException (if you are changing NetworkPlayerInfo.locationSkin), so you will need to create a delayed runnable and schedule it to run on the main thread. Be sure to use ObfuscationReflectionHelper with SRG names.

Use the EntityJoinWorldEvent and check the instance of the entity there compared to the AbstractClientPlayer. Then cast the event.entity to AbstractClientPlayer and do whatever you need.

Techne, a tool used for modeling items, blocks, and entities in 1.7.10 (only entities in 1., uses .tcn files. The part that we use is exported to Java code in a .txt file, and should be used as a reference to get all the boxes / rotations / translations / scale right upon construction of your model class (initializing your ModelRenderer instances). Take a look at any of the mobs in Minecraft's source code, those are perfect examples of the similar code that Techne exports. You may also want to reference the render classes for the models / entities.

You are registering your renders on both the Client side and the Server side. You MUST register your renders in your ClientProxy, not your CommonProxy. Everything after that should work fine.

That makes more sense. My code does require that a packet is sent every tick (or every X amount of ticks depending on the item's delay). The reason that I did not just call the code in the ClientTickEvent and then sending the packet to execute on the server side was because of pure aesthetics in the code itself - I handled everything in one packet and kind of kept key / mouse input separate from everything excluding networking, which is foolish now that you mention that it would cut the packets in half...that will change. Minimizing networking traffic seems great and efficient, though sending a packet each tick, or every X amount of ticks, would cut down on implementing IEEP - saving time. For anyone who would want to not send a packet each tick, here is a bit on (untested) code that will allow you to do that: @SubscribeEvent public void onEvent(ClientTickEvent event) { boolean pressed = Mouse.isButtonDown(0); boolean packetSent = false; if(!event.phase.equals(Phase.START)) return; if(pressed && !packetSent) { //Send packet to change boolean to true packetSent = true; } if(!pressed && packetSent) { //Send packet to change boolean to false packetSent = false; } } EDIT: Above code needs a minor fixing - the concept works but the reset (setting the Boolean back to false is broken). I'm sure someone can figure something out and use it. One last question - if I need the code called on both sides while the player is actively in the world, and this check applies for any players with my item, why can't I just call the code in the PlayerTickEvent and check the Mouse button there and not have to send packets at all?

Pretty much irrelevant to the question - I am not learning how to read and write data from packets. - I am reading and writing an int (Mouse button pressed) and an ItemStack. 1. Yes, if you need to know exacly when player is holding down button/mouse the best way is to send packet containing key(int) and pressed(boolean). - ClientTickEvent is called once on client per tick, so using it would be "fine", but not entirely, because you would also have to know (on client) if previous-tick button/mouse state is different (and if so - send state-changed packet), which requires additional fields (check is needed so you don't send packet with button state every tick). - What you can utilize are input events, but I am not sure they work in all cases (might have to use ClientTick after all). - If you would have to do that - simply hold list of previous states and send apcket only if you know state is different than one from prev-tick. 2. Yes, PlayerTickEvent is called for both sides for each EntityPlayer (mening on client it will be called for every loaded-by-client player). It is also (like other TickEvents) called twice with Phase. 3. Pretty much point 1. Yeah, I was thinking along the same lines. I would like to be able to use the MouseEvent so that I would not need an additional check for the Mouse button being down and not down. Though, I see no way of actually checking is Mouse Button X is not down. Really what I need here is - if Mouse pressed Boolean=true, else if Mouse is not pressed Boolean = false. Send packet once each time to set Boolean to true / false. While Boolean is true, call code on both sides, else return. I'll get to work on it straight away and will post with further progress / questions.

Look around in your Model's mesh, where the texture is set - that is where you import textures to Blender - that is most likely where you must set your texture path - as I stated before, this is something that I would try first, considering this is what you had to do in 1.8 for B3D models until a recent Forge build. I would then look in your code and make sure you are binding your texture correctly with the correct MODID and texture path. After that, double check your texture location and again, your IItemRenderer type to make sure you are rendering your model and binding your texture correctly. *Also, Forge .OBJ implementation requires your mesh to be triangular, not in quadrilaterals*

I am currently using the client tick event to check mouse input so I can call a method every tick on both sides (so I can play sounds, spawn entities, manipulate ItemStack NBT, etc.). Yes, I absolutely need to call this method every tick - some items held will have a built-in delay for calling the method. Right now, I am sending a packet to the server in the client tick event, based on mouse input, to call the method and to also send the same packet to the client (Bi-Directional packet) to also call the method. This works well, it calls the method on both sides, however sending packets at that rate and size is a pretty bad idea. It was recommended that I send the packet once setting a Boolean to true, and to save the Boolean in IEEP. Would it be best to send the packet once in the client tick event and then check the IEEP Boolean on the player tick event? Is the player tick event called on both sides? What is the best way of reducing this network traffic while still being able to achieve the same results? Any input is greatly appreciated, thanks.

I'm guessing this would be correct: @SubscribeEvent public void onEvent(ClientTickEvent event) { if(event.phase.equals(Phase.START)) { if(Mouse.isButtonDown(0)) { UtilityMessage.sendMessageToServer(new MessageFire()); } } }

In previous version of Forge you had to set the texture path in Blender itself. I'm pretty sure you have to do this in 1.7.10 as well (previous versions of Forge 1.8 with B3D).

I need to be able to handle mouse input from the player and was wondering what the best way for that is - using the MouseEvent works well, but I need for the code to run every tick so long as the left click / right click is down. I also tried using the ClientTickEvent to check Mouse.isButtonDown() and event.phase, but that seemed too buggy and didn't send my packet every time. I would appreciate any input on this.

There are events such as ClientCustomPacketEvent, ServerCustomPacketEvent, and CustomPacketRegistrationEvent, but I'm not sure how useful these would be to you for intercepting packets.

Look at ModelBiped.class. The way it's done there is by checking an "aimedBow" boolean and rotating / translating the biped arms based on that. It will be complicated, using Trig functions, so I recommend copying vanilla's code and changing the biped arms to your own limbs or whatever you need to do.