coolAlias

... Come on man, learn some Java already. EntityItemPickupEvent has an even more obviously-named field for the EntityItem you need. Or you could switch events. Either way, your problem is NOT related to Minecraft per se, it's your lack of fundamental Java skills.

... what the hell is that supposed to be? PLEASE go learn Java. There is nothing we can do to help you at this point other than giving you the exact code, but it's such a very basic Java principle that you really shouldn't need it. Stop modding (for now). Learn Java.

... what? The 'request' is simply a packet, and whenever you process a packet you always have access to a player instance. I understand it can seem daunting, but packets are really really simple: create the packet on one side (by create I mean you store some data in the packet class), send it over the network, and then read the same data back and do whatever you need to do with it. There is nothing magical going on.

You need to make your recipe accept all damage values for the item - currently you only allow the undamaged version. Instead of 'ModItems.item_diamond_file' in your recipe, use: new ItemStack(ModItems.item_diamond_file, 1, OreDictionary.WILDCARD_VALUE)

Err, about that 'awesome' tutorial, the part about persisting data across death by storing in the proxy is outdated - I made a post about a better method here, but haven't gotten around to updating the actual thread due to the 'new and improved and almost completely unusable' forum editor on MCF. The gist of it is subscribe to PlayerEvent.Clone and use the previous player instance to copy the old IEEP data to the new player instance. Way cleaner than the old method.

Two things: 1. Did you override getContainerItem() to return an actual Item? 2. Why create a new ItemStack when you already have one? @Override public ItemStack getContainerItem(ItemStack itemstack) { // Assuming you want to damage it when used in crafting: itemstack.attemptDamageItem(1, this.itemRand); return itemstack; // then just return it }

Generally, you NEVER update the server from the client. What the client does instead is say, 'Hey, server, I want to do X' (i.e. send a packet to the server requesting some action) and the server then decides a) if that is allowed, and b) what the result is; once that is all done, if the client needs to know about the result then the server sends the result of the action back to the client (i.e. another packet). So if, in your GUI, you have a button that swaps party members, instead of having the client swap the party members, you tell the server that the client player pressed the 'swap party' button, then the server decides what happens from there. If whatever you are doing isn't very sensitive and you'd like to preview in the GUI (you can't wait more than a few milliseconds to see the results - this can be true when dealing with rendering), you can always swap the members on the client, too, in expectation of a successful transaction to the server, as long as the client data is overwritten by the results from the server.

Yes, it is possible - did you try searching the forums / Google? It has been asked several times already. IIRC, there is a method in World that should work; if not, take a look at EntityTameable, as that retrieves players by UUID.

Well. Yeah. They're dev builds. Reika does not supply dev builds of his mods, only universal. So that is no-go for me. Even if you got your hands on a dev build (which you're right, does not exist), you'd still need all of the 20+ something other mods that RotaryCraft depends on. Reika sent me links to all of them once, but I couldn't bring myself to saturate my workspace with so many dependencies. :\ Guess that makes me lazy or whatever, but holy hell, all I wanted to do was use a single f-ing interface from RC in several of my block classes. I wonder if I could simply pull that one class out and leave it in the correct package structure and use it that way...

Ernio's code is correct for 1.8, and when I saw it, I completely forgot the thread was marked 1.7.10 @OP You don't need to make a new thread. Use the code Draco showed you, but before you do that, follow diesieben's advice and LEARN JAVA.

Did you register your tile entity? GameRegistry.registerTileEntity(YourTileEntityClass.class, "yourTileEntityName");

Well, that's not a vanilla method, so you just have to make sure wherever you call it from is on the server.

Most methods in TileEntity (and most other classes) run on both the client and the server. However, I have no idea what you are asking about; please clarify your question and post the relevant code.

Just because you are not missing that one specific thing does not negate my statement: something in your code is wrong, and unless you post your code (not just little snippets of it), we cannot help you. Please use a service such as pastebin and post each of your classes separately, or better, if you have a Git repository, provide a link to that.

Where is this tryToAddMobToParty method located at, and where are you calling it from? If it is in your IEEP class, then you should already have a reference to the correct player needed as a class field; if it is in your Item class, you need to make sure you are calling the method on the server only (i.e. when the world is NOT remote), otherwise your method gets called both on the client and the server, and any information you print out on the client is likely to be all null. The point being that we need as much context as you can give us if you want to solve your issue anytime soon.

The code did not have errors - the errors were caused by you not importing the necessary class references. I'm not trying to put you down or anything, but had you more knowledge of Java or coding in general, you would have understood that immediately. The folks here help you out for free in their spare time, so the least you could do to reciprocate is to spend some of your time learning the basics so you don't waste their time. Re: your entity no longer rendering: the client side (when the world is remote) is responsible for rendering entities, and the server (when the world is NOT remote) informs the client when a new entity spawns. If you spawn an entity directly on the client, it will basically be a 'ghost' that cannot be interacted with and has no AI or anything, so you should always spawn only on the server. You must be missing something critical in your code, such as EntityRegistry.registerModEntity(args for your entity class). You should search for a basic entity tutorial.

You cannot cast Minecraft to Object and then expect to be able to call a Minecraft class method (e.g. getRenderItem). Please learn Java before posting anything further.

You need to extend ItemBlockWithMetadata for your block's item, not ItemBlock; also, the default implementation for Block#damageDropped simply returns zero - calling super for that method is pointless; instead, you should just return i directly, as that is the metadata.

... I really don't understand what your obsession is with using the client-side version of the player. That makes absolutely no sense, and is very likely part of your problem. There is a server-side version of every entity, including each player, and that is the one you want; the client side is purely for rendering and that kind of stuff - it is NOT where you want to manipulate / store data.

IEEP is by its very nature persistent for each player - it automatically calls your save and load NBT data methods for the correct player each time they log in. However, if you do not implement those two methods correctly, then you cannot expect your data to be correct - your save NBT code: for(int i=0; i < NUM_SLOTS; i++){ System.out.println("test equals " + test); if(partyNbt != null){ properties.setTag("Slot"+i, partyNbt); // <-- isn't partyNbt an array? } } Looks like you simply made a mistake there - your 'partyNbt' field is an array, but you try to save the array reference rather than the actual element. Needs to be 'partyNbt'. Might want to double-check everywhere else that you access this field, such as the load method.

Since you are using IWorldGenerator, I assume you are registering it to the GameRegistry and letting that handle it? In that case, you need to give it a higher 'weight' so it generates later, but I prefer to call my world gen code for structures personally from PopulateChunkEvent.Post rather than using the normal IWorldGenerator. The reason for that is that PCE.Post is called AFTER all other gen code, and the IWorldGenerator is, I think, mainly intended for things like ore gen, not necessarily structures. Another consideration is that you'll want to make sure you generate your structure entirely within the chunk that is currently generating - if you spill over into other chunks, it is possible that the chunk has not yet loaded and you will cause it to load, but since it didn't exist yet that entire portion of your structure may be missing or overwritten by the chunk as it loads.

What do you mean by ClientProxy render code? You register a custom renderer for your entity class, and inside of that renderer you can do anything you want, including using information from your entity (provided you send that information to the client) to determine what texture to use. If the texture does not change once the entity has spawned, implement IEntityAdditionalSpawnData in your entity class to add whatever information you need (such as a block ID) to the initial spawn packet. If the texture CAN change after it has spawned, use DataWatcher to track the current block ID (or however else you want to do it) so that the client always knows what the current texture should be.

How would I do that? http://en.wikipedia.org/wiki/Method_overriding @OP See what Draco did there? He used the power of the internet to find information. You, too, are capable of harnessing that power, should you choose to do so. Besides, Ernio already gave you all of the Minecraft-specific information you need to do what you asked, but your lack of Java knowledge is preventing you from implementing it. Please learn Java.

What we are trying to get at is 'Why save the entity twice?' Either tie the entity to the ItemStack, or tie it to the player, but not both. Example A: Tied to ItemStack - Save the entity into the ItemStack NBT - When the player uses the item or whatever and you spawn the entity, pass the player as an argument much like setting the 'owner' of the entity, and use whatever fields from player / your player's IEEP that you need within the entity class to determine its abilities. - Example: each player has a power level that increases as they gain experience; this is stored in the player's IEEP, and the entity uses the player's power level to modify its attack damage. Example B: Tied to Player - ItemStack is subtyped by ID, where each ID is mapped to an entity type - E.g. 1 = Pikachu, 2 = Charzard, etc. - The actual entity data is stored in the player's IEEP, probably as an NBTTagCompound until you actually summon it, at which point you should convert it into a real entity - When the player right clicks with whatever egg, it uses the item's damage value (the stack subtype) to fetch the correct entity data from the player, which then creates the entity There are advantages and disadvantages to each design, but you MUST figure out your design and explain EXACTLY what you are trying to do in plain English (i.e. no code). If you can't explain it in simple terms, you are going to have a very difficult time implementing anything that does what you want.

That's kind of diesieben's point - each entity already has all of that data, why make it again when you can just make a reference to that entity? That last part is the main point: don't store an NBT tag when you can store an actual value, e.g. the entity reference, integer, or whatever else. Anyway, see here for further information on persisting IEEP data through death and dismemberment.