coolAlias

Who told you raytracing has to be done on the client? You can do it on the server just as well: Vec3 vec31 = Vec3.createVectorHelper(player.posX, player.posY + player.getEyeHeight(), player.posZ); Vec3 vec32 = Vec3.createVectorHelper(i, j, k); MovingObjectPosition mop = world.rayTraceBlocks(vec31, vec32); Use the player's look vector for the i/j/k coordinates. i would be (player.posX + (look.xCoord * 64)) for a range of 64 blocks, j would be the same for y, and k for z.

If you retrieve the NBTTagList from whatever NBTTagCompound you have and you know the index you want to change, you can use #tagAt(i) to retrieve the compound at that index in the list, changing whatever you need there.

Looking at how you registered your messages, you are sending them to the server, so why would any of your ClientProxy methods be getting called? Of course it is calling CommonProxy version - that's what it does on the server side. You do not want to do anything that changes the world from your client proxy - stuff like 'setBlock' should ONLY be done on the server (the client usually gets notified of the changes automatically).

You're using the ItemStack#addEnchantment method; diesieben is saying you need to use the one specific to ItemEnchantedBook - Items.enchanted_book.addEnchantment(...), because enchanted books handle enchantments differently, apparently.

No need to reinvent the wheel here: example bow renderer. You'll obviously need to remove any parts specific to my mod, and you may want to compare to the vanilla bow rendering. The arrow rendering section is from Battlegear2's code and is really slick - I highly recommend using that if you plan on being able to use multiple arrow types in your bow, but be sure to credit the BG2 team for it and not me

If a majority of those are leaf blocks, which it looks like they may be, then that would be a HUGE source of lag - consider how bad dense jungles lag, and then look at what you are doing there. Of course if those aren't leaf blocks, then my guess is simply that your generation code is not very optimized. It's very easy to write poorly optimized generation code, given the penchant for many recursive and looping calls.

All you have to do is move that logic to the client side - handle the modification of the player's motion there, and the rest of your logic (taking damage, etc.) on the server.

Basically just do what diesieben07 already told you: Use your main mod class' proxy reference (which is a reference to CommonProxy, which your ClientProxy should extend from) to access the method you want, and add the same method you need to your CommonProxy, but empty. This allows you to override it in the ClientProxy, just like all the 'registerRenderer' methods you see in people's code.

Yes, and it will probably be exactly what is needed - just thought I'd point out that depending on the requirements (up/down possibilities), it may not be enough

That facing method will fail (or at least not give expected results) if the player is looking up or down, though - if the item works at a distance greater than that of block-clicking, then you ought to use ray tracing to find the block hit by the player's look vector.

If you have an item class that you are using, override 'onItemUse' - it gives you the coordinates of the block clicked, the side that was clicked, and even more precise float coordinates for the exact position if needed.

Yes. World#playSoundEffect and #playSoundAtEntity will automatically notify all nearby clients, so you don't have to; however, they may only be used on the server. On the client, you can use player#playSound (which doesn't work on the server).

That is possible, but not likely if you use fairly normal motion values. The code for 'moving wrongly' on the server simply checks if the difference between the player's current and last position is greater than a certain value, so as long as you are within that, you are fine. If you need more than that, then yes, you will probably need to send a packet and handle the position change on the server, but I've never had to do that.

If you are only playing with the player's motion, you don't technically even need to tell the server about it, as the player's position is synced automatically from client to server each tick. You can get away with running that code you posted on the client side only.

You CAN NOT add parameters to event handling methods - they take one argument and one argument only: the event class for which they will fire. @SubscribeEvent public void whateverMethodName(Event event) {} That is the signature your method MUST have. Always use the most specific Event subclass that you can, e.g. LivingUpdateEvent instead of LivingEvent. If you need something that is not part of the event (such as a 'World'), then you must find another way to get it or use a different event. For world objects, it is very easy - every entity has a world object: event.entity.worldObj.

If your inventory is not being access via a Container, then you must notify the client manually of any changes to your TileEntity's data state; this is most easily done by using the combination of your TE's read/write NBT methods (provided you implemented them correctly) and overriding getDescriptionPacket and onDataPacket: @Override public Packet getDescriptionPacket() { NBTTagCompound tag = new NBTTagCompound(); this.writeToNBT(tag); return new S35PacketUpdateTileEntity(xCoord, yCoord, zCoord, 1, tag); } @Override public void onDataPacket(NetworkManager net, S35PacketUpdateTileEntity packet) { readFromNBT(packet.func_148857_g()); } If your TileEntity has a lot of data being saved to NBT, then you should consider only sending the information you require, e.g. writing only the one ItemStack to the tag compound being sent in the packet, and adjusting onDataPacket accordingly.

Or you can use the list of loaded tile entities (World#loadedTileEntityList) and iterate through that - it is certain to be a much shorter loop than iterating all of the blocks in every chunk.

@OP - Sorry, I'm about to go slightly off topic for a second. @Eternaldoom - you really ought to reconsider how you are doing that... horribly inefficient. A much better approach would be to Map the item you want to search for to the item you want to replace it with, and do something like this: @SubscribeEvent public void onTickEvent(PlayerTickEvent evt){ ItemStack stack; for (int i = 0; i < evt.player.inventory.getSizeInventory(); ++i) { stack = evt.player.inventory.getStackInSlot(i); if (stack != null && yourItemMap.contains(stack.getItem()) && evt.player.inventory.consumeInventoryItem(stack.getItem()) { evt.player.inventory.setInventorySlotContents(i, new ItemStack(yourItemMap.get(stack.getItem())); } } This is much more efficient and easy to manage than tons of if statements; at the very least, use chained if/else-if statements.

If that's the case, you should be able to use --stack.stackSize without any problems. Show us your code.

What about the stack doesn't update, the current number in the stack? This can be an issue depending on where you called consumeInventoryItem() from, or if you have multiple stacks of the same item in your inventory you may not notice if it was taken from the other stack. That being said, there have been times when I've had to manually check if the stack size is 0 and then set the slot contents to null, because the vanilla system somehow doesn't always update appropriately.

Yep, that's all it takes to make an event: create a class extending Event or any of its subclasses, then post it to the Forge event bus wherever you need it. Typically it only makes sense to create and post an event if you are expecting other people to be using your API, though there are some cases where it is useful to use events within your own code.

You shouldn't need packets if what you are doing is on the client side only (i.e., if your 'BendingActive' is meant for rendering or some such). If you need that information on the server for whatever reason, then yes, you will need packets. Your problem is more likely that you registered your KeyBinding class on both sides - register it in your ClientProxy to keep it isolated to the client side, and you should not crash with the exception given.

Your IMessage class needs to have whatever data you need to pass, and a constructor that allows you to pass them. Keys are tricky, because all of the keyboard information is client-side only, so sending the keyCode of the key pressed is pointless. Instead, I recommend you make separate packets for each action that you want to perform, or at least create some way to distinguish actions. A simple example: public class NewtMessage implements IMessage { private byte action; public NewtMessage(KeyBinding kb) { if (kb == YourKeys.yourKeyBindings.specialKey) { action = (byte) 1; } else { // whatever other actions action = (byte) 2; } } // write the 'action' byte to the buffer // read it back // in your IMessageHandler class' method: switch(message.action) { case 1: // do your special action # 1 case 2: // do special action # 2 default: // throw an exception } } Obviously that is not optimal code, but it should illustrate what you need. If you want to see some concrete examples, feel free to browse my code. EDIT: Keep in mind that my current code base is for Forge 1180; if you are using 1217+, you will need to also check Keyboard.getEventKeyState() to tell you if the key was pressed (true) or released (false), since KeyInputEvent is now fired for both presses and releases (yay!!!).

All of those things are possible. FML initialization events are supposed to go in your main mod class - they don't belong in your entity class. Once you have it in the right place, your spawn rates should work. You also should not be using global entity ID - use the EntityRegistry#registerModEntity method only, and if you need a spawn egg, create your own. Randomly assigned textures can be done through the entity class, by assigning each entity a random value when it is spawned, using either DataWatcher or IEntityAdditionalSpawnData to inform the client side what the value is so you can use it in rendering. Be sure to also save the mob's type to and from NBT, so it has the same texture when you re-load. For checking health - assuming you are using attackEntityAsMob method or something similar, you have an Entity parameter that is the entity being attacked; check if (entity instanceof EntityLivingBase), then you can cast to check its health: EntityLivingBase living = (EntityLivingBase) entity; float ratio = living.getHealth() / living.getMaxHealth(); Same for checking a player's inventory - check if the entity being attacked is an instance of EntityPlayer, then cast accordingly and run through the player's inventory until you find whatever you are looking for.

My stuff is open source for a reason, though it's always nice if people credit the source of the original code when using it. Re: Microjunk, no, I haven't heard from him in ages. He had some life crises that dragged him away from modding...