coolAlias

Any event listener method that you write MUST be public for it to be called by Forge / FML event bus. TickEvents are only on the FML bus, so if your class contains only those events, you only need to register it on the one bus, not both.

I ran into a similar issue, and though I'm not 100% sure, I believe that lakes at least DO generate across multiple chunks at once. What I did is to deny lake generation if the chunk it is in or any immediate neighbor has my structure in it, and this seems to have solved the problem. I say 'seems' because while it fixed it in the one seed in which I found it, I haven't been able to verify for a fact that it will work in all circumstances. Haven't had an issue reported since, though.

Yeah, I saw that. For some reason, I thought it was intentional on your part, like you were debugging that part because the packet wasn't being received at all. In the future, it would be helpful to provide the console output, then it would have been immediately obvious what you were missing.

I think your problem is in your main class: FMLCommonHandler.instance().bus().register(instance); // why are you registering your main class to the FML bus?!?!?! MinecraftForge.EVENT_BUS.register(new EventManager()); PlayerLoggedInEvent is on the FML bus, but you do not register your event manager on that bus (you can register to multiple buses, if need be).

You're calling your sync method all over the place... you should only sync when the player actually joins the world, i.e. on PlayerLoggedInEvent + PlayerRespawnEvent, OR EntityJoinWorldEvent. Not in any constructors, not when copying the data, not in PlayerEvent.Clone. You CAN sync when data changes, such as your magic level, but then you should only be sending that specific information, not your entire extended properties. It looks like your packet should be sent and received fine, aside from the above issue. Do you not get any of your log output in the console?

I'm pretty sure AI tasks only run on the server, so the taskEntries list will never have anything in it on the client, thus its size is always zero.

Usually, each packet should be as specific as possible so you only send the exact information you need. If you just want to sync everything in your IEEP once when the player logs in, though, it's much simpler to send it as NBT data.

Or can we lock the thread? This has moved way beyond the initial issue (which is solved). @OP If you have a new problem (such as dealing with packets), it's better for everyone if you start a new thread.

There is no point to users setting specific block or item IDs, but Minecraft / Forge still use them internally. You don't need to bother with a config option for it nowadays.

Another example is in recipes, nearly everyone adds 'new Object[]{...}' when they can just list the parameters in order. Three cheers for copy/pasting of auto-boxing

There's also one specifically on custom player inventories (or see here).

Except it doesn't only happen in Creative Mode - this issue is not related to Game Mode at all; it happens because for whatever reason, the action bar is not continuously synced from the server despite the container being open, so when you run code only on the server side that affects the action bar, you have to send a packet as I described above, again regardless of what game mode you are in.

Its because they copied it from your tutorial. Copied, yet took the time to remove the comments which clearly say that it is not needed. I suppose that's what I get for expecting people to READ.

You'll also need to show your updated IRecipe code. Btw, you registered your properties twice in onEntityConstructing - you only need the first one, because it does exactly what the second one does: if (event.entity instanceof EntityPlayer && EntityPlayerExtended.get((EntityPlayer) event.entity) == null){ EntityPlayerExtended.register((EntityPlayer) event.entity); } // the following is totally unnecessary, as it does exactly what was just done above /* if (event.entity instanceof EntityPlayer && event.entity.getExtendedProperties(EntityPlayerExtended.EXT_PROP_NAME) == null){ event.entity.registerExtendedProperties(EntityPlayerExtended.EXT_PROP_NAME, new EntityPlayerExtended((EntityPlayer) event.entity)); } */ That's the second time today I've seen that exact same code - any particular reason people are duplicating it?

Lol. A picture's worth a thousand words; a video? Priceless.

Oh dear lord... 1. DO NOT use 'static' fields to store the player, extended properties, or anything else - clearly you don't know what it's for. 2. DO NOT use Minecraft.getMinecraft().thePlayer - that is CLIENT side only player. 3. You are still using a 'new ExtendedPlayer' - NEVER do that - the player already has an ExtendedPlayer instance created by Forge, which is why you use the ExtendedPlayer.get(player) method to retrieve it (which is just a wrapper for player.getExtendedProperties("YourProperties")).

You have to get it every time you want to use it, i.e. as a local variable in whatever method you happen to be in, or even a class constructor such as the Container / GUI combo for your GUI.

The problem looks to be that you are always creating 'new' instances of your extended player and inventory, when what you really want is the one that should already exist: ExtendedPlayer props = ExtendedPlayer.get(player); props.inventory.setStackInSlot(0, new ItemStack(Items.stick)); System.out.println("Stack in slot 0: " + props.inventory.getStackInSlot(0));

As Ernio mentioned, just put 'this.motionY = 0.0F' in your mob's onUpdate method. If that doesn't work, try onLivingUpdate method. If neither work, try putting it before or after the call to super in either one. It depends, of course, on how your mob's swimming is handled, for example if it has custom AI, but it should work (I can vouch for hovering in the air, at least).

You probably are aware of this, but you can use Minecraft.getMinecraft().gameSettings.keyBindJump, for example, to get the vanilla key and check its getKeyCode() is equal to the key firing the KeyInputEvent - this way you are not checking for space bar explicitly and your code will always work properly, even people with game pads and such.

Check Entity#handleLavaMovement() to return if in lava, and check if the player is pressing the space bar on the client side and send a packet to let the server know.

That's because the vanilla hotbar inventory is usually changed by packet from the client, or the code is run on both sides. When changing the inventory from the server side only, therefore, it is necessary to inform the client: // get the actual inventory Slot: Slot slot = player.openContainer.getSlotFromInventory(player.inventory, i); // send S2FPacketSetSlot to the player with the new / changed stack (or null) ((EntityPlayerMP) player).playerNetServerHandler.sendPacket(new S2FPacketSetSlot(player.openContainer.windowId, slot.slotNumber, invStack));

Use LogManager.getLogger("yourmodid") - it returns an Apache logger using your mod name, which is what the FML log does for itself. No need for a wrapper.

GUIs are client side only - potion effects are handled on the server, so you need to send a packet informing the server that the player clicked that specific button, then let the server decide what to do (e.g. remove poison).

1. In several places: net.minecraftforge.event and net.minecraftforge.fml.common.gameevent 2. MinecraftForge.EVENT_BUS (no E on the end...) is for the first mentioned above, FML bus for the second 3. PlayerLoggedInEvent, on the FML bus