coolAlias

PlayerLoggedInEvent, though Ibelieve this event is fired only on the server side; if so and you absolutely must have an event that is fired on the client side (i.e. your mod is a client-side only mod), you can use EntityJoinWorldEvent and check for EntityPlayer before sending the message.

That would be the case on the server, but GUIs are client-side only, and there is only ever one player per client I'm not sure about the hotbar situation - perhaps the hotbar has a backup or override in cases where the alpha value is too low?

It's a NullPointerException. Check for null at the line specified in the crash report.

I wouldn't use IEEP to store the alpha values or focus time (unless you really need to save it between sessions... but most games the HUD elements reset to default when you reload) - all of that stuff is explicitly for rendering purposes, so you can store it directly in the HUD class. As far as the issue itself, have you tried using different alpha values as the stopping point, such as 0.5F instead of 0.1F?

That's because the fields have obfuscated names in the live environment - there should be some methods in ReflectionHelper that take both the deobfuscated and obfuscated names as arguments. You can look up the obfuscated name using MCPBot. Another option is to not use named fields but to instead fetch it by index, e.g. 2. It's not as robust, but it does work.

You can store a reference to the Field say in your Main class, for example, and then use that to fetch the value using the current EntityArrow instance. This is waaaaay more efficient than getting the Field each time.

Part of the problem you've been having is that many of these fields are not synced to and/or are unreliable on the client which is where you need them to draw hit boxes. The easiest way is to use Reflection to set the private #inGround field to public and then use Reflection to fetch the value - #inGround should be correct on both sides as vanilla uses it to render the arrows in the ground.

I have a vague memory of #onItemUse being the method called when you right-click on a block, and #onItemRightClick being called only when you clicked in the air... but it's been more than 6 months since I've messed with it, so I could be completely mis-remembering that. But, if it's not your Item class but someone else's (e.g. vanilla item), then yeah, diesieben is right - use PlayerInteractEvent. There are lots of event tutorials online that cover how to do it in detail, more detail than anyone would want to type here.

In PlayerEvent.Clone you copy over the old player's data that you need to the new player. This is on the server. Now when the new player respawns on the server, which is after the clone event, you send what you need to the client.

You probably shouldn't be using the FML logger as your mod's logger. Instead, create your own: // Add this field to your main class public static final Logger logger = LogManager.getLogger(ModInfo.ID); // You can use it from anywhere: YourMod.logger.warn("Warning!"); That way, your mod has its own logger. Note that levels below info do not show in the console by default, but they ARE logged in the saved log files.

Caused by: java.lang.NoSuchMethodException: worldtools.message.WTMessageSendPlayerData.<init>() Make sure your message class has an empty constructor. Also, you shouldn't send a packet to the client from the clone event - do so from the player respawn event instead.

What's strange is that your #getUpdatePacket method is not being called at all according to the log, and thus #onDataPacket is not, either... but #writeToNBT and #readFromNBT are both called... Can you show where you register your TileEntity and the related Block class? Perhaps some more context will help track down the issue. Another thing you can try if you haven't already is updating Forge - sometimes things get broken temporarily, and though I don't have any reason to believe that's the case here, it's worth a shot.

If you're only using it for the TileEntity's position on the client, that information is already embedded in the TileEntity class - no need for a separate List<Integer> to store it: int posX = this.entityMerchant.xCoord; // same for yCoord and zCoord If that's NOT what you are using the List<Integer> for, then as diesieben asked, what are you using it for???

Ah yes, I remember that confusing me as well. You can set your username in the run-time configuration so that it is always the same - it doesn't have to be your real Minecraft account, though you can use that, too.

I pass the entity ID as the 'x' parameter and know based on the GUI ID that it is an Entity and not a TileEntity. switch (id) { case 0: // you set the IDs, so you know what this GUI expects e.g. TileEntity return whatever; case 1: // oh, this is my Entity-based GUI Entity e = world.getEntityByID(x); return new Whatever(e); } Not that passing some random magic-value number via 'y' as a flag is bad, just unnecessary in most cases. If you do find that you need it e.g. you have a GUI that could take either a TileEntity OR an Entity and you won't know which in the IGuiHandler, then you should make a constant e.g. public static final int ENTITY_FLAG = -10 so your code is more readable and more easily maintained.

Also, PlayerTickEvent is most definitely NOT client-side only. Please read this post on @SideOnly. As for movement, there is no interpolation at all (built in, at least) if you use any kind of #setPosition-type functionality, but there is if you set player motion. Adding / setting player motion is probably the best way.

If the TileEntity update packets are anything like they used to be pre-1.9, you need to pass 1 as the second parameter for an NBTTagCompound-based packet: // change 'this.getBlockMetadata()' to 1: return new SPacketUpdateTileEntity(this.pos, 1, tagCompound);

You need to create your own IRecipe class and register that. GameRegistry.addRecipe(new YourCustomIRecipeImplemenation());

No, you shouldn't be sending ANY data at all to the server... the server should already know about needing to add or subtract mana as the server is the only place that should ever happen. Basically all the client should ever do is display the current value of the mana. If you have a key press responsible for activating magic spells or whatever, the answer is not to have the client change the mana value but to send a packet to the server saying 'hey player A wants to activate magic spell B, is that okay?' and the server goes through all the logic of determining if the player can do that, which involves checking and then modifying the current mana value and ultimately sending a packet back to the client with the new current mana value.

The second constructor is only called on the server whereas the single-World argument constructor is used on the client. There is no way to change which constructor is used on the client, but you can implement IEntityAdditionalSpawnData in your Entity class to send additional information to the client side when your entity spawns. However, if the mob is actually losing the owner when you logout and not just missing it on the client, then you are not correctly saving to or reading from NBT. Show those methods.

No, that's completely backwards. NEVER send values to the server - the server is the one that should be sending values to the client. Why are you controlling mana values from the client? Also, it'd be simpler to send the packet from #setMana which I assume is the centralized method for actually modifying mana values. Finally, your #addMana and #removeMana methods are very weird - you don't actually modify the mana value, you just send a packet?

Most events are only posted on the server so if you find you need any of them to make your mod, then the only solution is to not make a client-side-only mod.

Every time the mana value changes on the server, you need to send a packet to the client with that value and set it accordingly. The easiest and most logical place to send the packet is from the one or few methods that are directly involved in modifying the mana value.

Interesting. Well, one thing that may help and you should do anyway is to remove that static #get method you have and replace it with a method in your Proxy classes to retrieve the player; I also do the same thing for retrieving the main thread: /** * Returns a side-appropriate EntityPlayer for use during message handling */ public EntityPlayer getPlayerEntity(MessageContext ctx) { return ctx.getServerHandler().playerEntity; } /** * Returns the current thread based on side during message handling, * used for ensuring that the message is being handled by the main thread */ public IThreadListener getThreadFromContext(MessageContext ctx) { return ctx.getServerHandler().playerEntity.getServerForPlayer(); } // CLIENT PROXY implementations // note that yes, that ctx.side check IS necessary during single player specifically @Override public EntityPlayer getPlayerEntity(MessageContext ctx) { return (ctx.side.isClient() ? Minecraft.getMinecraft().thePlayer : super.getPlayerEntity(ctx)); } @Override public IThreadListener getThreadFromContext(MessageContext ctx) { return (ctx.side.isClient() ? Minecraft.getMinecraft() : super.getThreadFromContext(ctx)); } This way you can call YourMod.proxy#getPlayerEntity or #getThreadFromContext which keeps Minecraft.getMinecraft() out of your handler classes. Other than that, you can try switching to EntityJoinWorldEvent instead of PlayerLoggedInEvent, and if THAT doesn't work (but it should, well, so should the logged in event - I've used both just fine)), since that event is fired on both sides, you can wait until the client player joins the world and send a packet to the server requesting the synchronization packet be sent to the client. Lame but much much better than Thread.sleep

So you are getting the exact same error even after changing your message handler code to wait for the main thread? Post your updated code and the error log, if you would.