coolAlias

Yes, it absolutely does. EntityPlayerMP is the server player, and the skin / game profile is client side only, which means you can only access it on the client. Pretty much everything to do with rendering is all client side only stuff. What you can do is send a packet to the client player requesting their skin location, then send that information back to your server-side doppelganger, then resend that information to all tracking players so they can render the doppelganger with the correct skin. It may seem like a lot of packets, but that is the only way to pass information between the clients and the server.

Where do you register it? Show that entire class, not just the single line. Also, are you still testing on a server with the mod only on your client? Because this very likely isn't going to work if you don't have the mod on the server, too.

You should really parameterize (by that I mean specify a type) your Collections: List<EntityPlayerMP> players = ...; Then use the foreach loop syntax which is much simpler to write and easier to read: for (EntityPlayerMP player : players) { // do stuff with player } If you really want to use an Iterator, then it should also be parameterized (is that even a word?). As to your issue, post the full stack trace along with the full class using pastebin or something similar so we can see line numbers - the line you claim has the NPE doesn't strike me as one that could possibly be null.

That's the same error, but caused because when you right click, you aren't sending a packet and thus not sending the slot index (well, hopefully you're sending '0'). You can fix the issue by sending player.inventory.currentItem, or you can also do a check for the player's held item in the IGuiHandler code and use that if it is correct, or you can pass a 'flag' such as -1 as the slot index when right-clicked which you can check for to know that you need to use the held item instead of the inventory slot.

Are you using your main mod class as the event handler? Probably not the best of ideas, but if that's really what you want, use the mod instance that should already exist,e.g. Main.instance. That all said, we can't help you if all you say is 'it doesn't work' and don't show us any other code. Show us the entire class that contains your mis-named LivingHurtEvent handler, as well as the entire class containing your registration of that event handler. And again, keep in mind that LivingHurtEvent only fires on the SERVER except under very specific circumstances, so if you are trying to make a client-side only mod, you are probably going to have to come up with a different solution.

That's strange that it requires a copy to be made, but that still doesn't negate the fact that you are reducing a stack of unknown size to a size of 1 for no apparent reason. Why not just return the copy directly? @Override public ItemStack getContainerItem(ItemStack itemStack) { return itemStack.copy(); }

If I recall from my own testing, LivingHurtEvent only fires on the server UNLESS the hurt entity is a player. So you will not be able to do what you want with a client-side only mod.

You're passing the slot index so that you can retrieve the ItemStack from the inventory rather than using player.getHeldItem(), since you're not requiring the item to be held. So replace 'player.getHeldItem()' with: ItemStack stack = player.inventory.getStackInSlot(x); // where 'x' is a method parameter passed via IGuiHandler // maybe check again if the stack is correct, just to be safe // then pass it into your inventory constructor when returning the GUI or Container, e.g.: return new GuiCelestialKeyPouch((ContainerCelestialKeypouch) new ContainerCelestialKeypouch(player, player.inventory, new InventoryKeyPouch(stack)));

I don't recognize BlockHelper as a Forge class, but I don't have the code to check right now - are you sure it wasn't from a 3rd party library or something? Show the imports for your ore gen class from 1.8.

It looks like somehow you have created an invalid ItemStack. Show the code that is removing the item. Also, why are you sending a packet every update tick? The Container can sync variables for you via a few methods such as #detectAndSendChanges - that's how the furnace burn time is updated in the client-side GUI, for example. It's better because it only sends packets when needed, e.g. when displaying the information in the GUI. Of course, if you need temperature for rendering the block or something, then yeah, you'll want to send that packet.

Might I recommend you ask this on StackOverflow or some Java support forum (or search 'accessing MySQL from Java' on Google)? It's not really related to Minecraft or Forge. That said, you are opening up a whole can of worms as far as code complexity goes. What are you trying to accomplish by involving a database? Why would you allow clients to write to it? This sounds like the wrong approach to me.

Okay, so your problem is that your IGuiHandler code expects the player to be holding the backpack, but you are opening it from a key press so that is not necessarily true. The player might not be holding anything - i.e. NULL - but still have the backpack somewhere in their inventory. So you have 2 options: 1. Restrict opening of the backpack to when it is in the player's hand by checking that condition when receiving the packet server side. This makes it pointless to use a key press, however, as the player may as well just right-click use the item and open the GUI from there. 2. Loop through the player's inventory again to find the backpack ItemStack instance so you can use it to create the inventory. To avoid looping, you could pass the inventory slot index of the backpack from your packet: for (i = 0; i < player.inventory.size(); ++i) { if (inventory[i] is backpack item) { player.openGui(MainRegistry.modInstance, message.id, player.worldObj, i, 0, 0); } } In your IGuiHandler, 'x' will now contain the slot index, so you can easily retrieve the ItemStack you need.

It looks like you are passing NULL rather than a valid ItemStack to your IInventory constructor. Show your IGuiHandler class. Also, you don't need to pass the player's position when opening a GUI unless you need them for some reason; those last 3 parameters are usually used for Block-based GUIs to pass the BlockPos coordinates. As for checking things on the server side, that's what you do when you handle your packet - recall it was sent from the client to the server and you should know or be able to check which side you are on when you receive it. Then, just loop through the player's inventory and check each slot for your special inventory item. If you find it, go ahead and open the inventory, otherwise don't. Simple as that.

Why aren't you using the SimpleNetworkWrapper?

Where did you get your 'player' instance from you use in your condition? You should use the one provided by the Event parameter, like you did when trying to add the item to the inventory.

Have a BOOLEAN property for BURNING - check out any of the vanilla toggleable blocks such as doors, levers, pressure plates, etc. All of them have some sort of boolean property. Do the same.

While I don't know the answer off-hand, I do know that there have been many threads about this exact topic here that you could probably find the answer in if you searched. There is some kind of trick to getting a painting to render correctly that isn't really obvious as it is not handled the same way that most other rendering is in Minecraft. EDIT: Here is a thread with a potential solution.

Where do you register your projectile entity? It should be done during pre-init: // increment the index for each entity you register int modEntityIndex = 0; // last 3 parameters are tracking range, tracking frequency, and whether to send tracking updates or not // check the vanilla EntityList (I think) to find a similar entity class and use the same values // in this case, throwable entities all use '64, 10, true' so I recommend you do the same EntityRegistry.registerModEntity(YourEntityClass.class, "Your Entity", ++modEntityIndex, this, 64, 10, true);

If vanilla XP is kept in sync by vanilla Minecraft, then no, you don't need any additional packets for that particular aspect of your code, but if you are displaying the cost of spells or whatever like it seems you are doing with your arrays, and those values are configurable, then you will most definitely need to send that data to the clients when they connect or they will likely have incorrect values displayed to them in the GUI. Same goes for any other data that is not kept in sync for you by Minecraft, so pretty much everything you add via your mod and a hefty portion of vanilla fields if you want to use them client side.

if (target instanceof EntityPlayerMP && !target.worldObj.isRemote) { ((EntityPlayerMP) target).playerNetServerHandler.sendPacket(new S12PacketEntityVelocity(target)); }

This is all from memory, so it may not be entirely accurate: when the player takes damage, there is a field that gets set to true - something like #velocityChanged - that acts as a flag for the server to notify the client of specific motion changes. You can accomplish the same thing by sending a motion packet to the client or running your code on both sides.

Yes. Extend EntityThrowable and override #getGravityVelocity to return 0.01F or some such - I don't recommend negating gravity entirely, however, or going much below that threshold unless you plan to limit the flight time in some way; otherwise your projectiles can travel forever. As for the time on the ground, you could spawn it as an EntityItem with a custom lifespan, or do the much more difficult but cooler effect of figuring out how to place your projectile in an immobile state at the point of impact and render it correctly on that side of the block hit, in which case you have complete control over when the projectile entity despawns.

When #isRemote is true, that means your code is currently on the logical client side, and is NOT when you want to open container-based GUIs. Entity#interact is called on BOTH client and server side during the interaction process - first on the client during the initial mouse-click, then again on the server after the server receives a packet. You should open the GUI when the world is not remote, i.e. on the server side, since the GuiHandler will open both the Container (server side) and the GUI (client side) automatically when invoked on the server. If you were in a situation that didn't have Minecraft automatically sending packets for you, say you wanted to open your Container-based GUI by a key press instead of entity interaction, then you'd have to do as Ernio said and send your own packet from the client requesting the server to open the GUI. The only time you should open a GUI directly on/from the client side is when there is only a GUI component (no Container) and there are not any important conditions to the GUI being opened. If, for a non-Container based GUI, it is important to know for sure the player is e.g. close enough to the entity, then you should send a packet from the server to the client to open the GUI.

Full mod jars should go in the /mods folder, I believe, e.g. /eclipse/mods/. If you had the deobf jar, you would put that in /libs (iirc, might be just /lib).

This is exactly the type of situation that PlayerLoggedInEvent was made for - send the packet from there. Do keep in mind that the client-side values are for display purposes only - any time you use them that will have a real effect, such as casting a spell or crafting something, you should only use the values on the server side.