Ernio

Are wa talking about one type of your block with tile entity? Or maybe you want to sign other/vanilla blocks? Well, anyway: You want to hold UUID in your TE and save it to NBT. UUID can be written as 2 longs (lookup vanilla examples where uuid is saved/loaded). Then based on loaded UUID you can retrieve EntityPlayer on server. Note that you can (should) find (by uuid) that player once and save it in WeakReference<EntityPlayer>. If you need player on client (display) - you need to ask yourself - how much data do you need to show, you can e.g send only name or whole reference (using entityId and World#getEntityById()). If you want to save such data for other blocks - well, you need to take different approach (still saving using UUIDs and probably NBT) but using some per-world position maps.

!event.getEntity().getEntityWorld().isRemote Is true for server. You should run fall events on server so basically what I am saying: (at start) if (event.getEntity().getEntityWorld().isRemote) return; This might not be the whole problem (part of it). Any changes?

No, not like this. Dude, modding is just another name for coding - and you my friend apparently know nothing about it. What you just did proves that you don't understand object oriented programming, what is a constructor, method or overriding it. You have no clue what you are doing and copying from examples won't help much. 1. Read "Modder Support" sub-forum description. 2. Google java tutorials on objects, constructors and inheritance - oracle has them plenty and nice. 3. Learn. 4. Come back and fix your mistakes. Additionally: There is plenty open sources - you can look up any of them. OR - look at vanilla code! EDIT As to what you want: 1. Like you pass "name", also pass (to constructor) list of information to display. 2. Save list in Item instance. 3. In addInformation do list.addAll(listSavedInItem).

There is server and there is client. Without even looking at code: 1. Do you actually know that NBT is not saving/loading? Meaning - have you printed it in those methods, is it empty? 2. If yes - Fix your NBT code, if no - you are out of sync. Why? Becaouse you don't send description packet. 1st one should return TE data packed in Packet (server), 2nd one should decrypt it. Look into vanilla.

The "commented out" code you were talking about is EXACTLY the code that is commented out in file you linked? If yes - could you narrow it down? If no - could you please mark lines which are the ones that change game experience (lag)? Also - how many such entities are in world when lag occurs (with AI code)? Is this actually server lag (meaning - have you checked with cmd /tps ?) or maybe some rendering (I don't think so, but still). Without looking too much at code (too long really) I can guess that your entity, by using dragon's AI (I assume that is vanilla AI, because if not, you would include it, and I can't get on IDE now), is doing some bat-shit crazy processing, especially ridiculus when having shitload of dragons where they shouldn't be. (This is only guess, provide more info).

Okay so basically some design stuff: There is server that saves/loads/holds ALL entities. There are some client that connect to server (dedicated or integrated SP) and ask for Entities that are in their range. Client only has one World (the one you are in) - Minecraft#theWorld, same for Minecraft#thePlayer which is your-client-side you. Now - the entities you see (in range) are "mirrors" of server ones so if you see them on client your client-side entities will most likely hold data same or close-to server's. So if you are asking about getting some player's name - if you see him, you can ask your client to return name: Entity#getName(). If you don't see an entity (on client) then you can't know anything about it (you don't have it, only server does). To get that data you MUST send separate custom packet with data you need and hold it somewhere on client. Now - the rule above is a little expanded for EntityPlayers - on client you don't always have all players that are on server (you only have those you see), BUT you do have their profiles which allow you to get some data about them, even if you don't see them.. That data can be pulled from.... (I don't remember, someone can finish my sentence). If you want to find it on your own - there is a tab feature in-game that shows you all logged in players - track down (in vanilla code) where that is rendered and check what it calls (I can't, no IDE).

If you want to understand resources as whole - look into GuiResourcePacks (naming may be different). In particular Minecraft.getMinecraft().refreshResources(); This allows you to "recreate" resources. They will be reloaded from Minecraft#defaultResourcePacks which to put it in simple words "contains all packs from which resources will be collected and will create all available resources". Now, in your case you will want to either: 1. Put your .png into your pack (your mod or texturepack) and reload resources, they will simply reload all .jar and .zip resources. * Here is a big note: I am talking partially hypothetically so you might have to remove pack from Minecraft#defaultResourcePacks and re-add it for the pack itself to detect "changes" (like you putting a .png file inside). I don't think so, but MAYBE. OR 2. Treat your resource as custom implementation of IResourcePack which can read input stream directly from /.minecraft/directory/file.png In that case - yeah, reloading will pretty much reload it form directory you want. * Note: Again - like before, you might have to re-add it. Other stuff: 1. I am not sure if this is still a thing in 1.9+ (was earlier), but to access Minecraft#defaultResourcePacks you will need reflection. Read up on Java tuts. 2. Synchronization WILL be a bitch here. Is this supposed to be client-only feature, or should server be able to set such .pngs (server resourcepacks) or maybe you want "admin" which will be able to change stuff for other players? That all can be done with some Java magic, but hell - lots of vanilla-code-reading and even more work with internals and this is like advanced (quite very) level of modding. EDIT

Where? (hint: server, client, what event or method)

No such thing. Every mod can use their own systems, so basically if they are not designed to support other mod interactions, they won't. If mod author doesn't provide (for 1.7.10) decompiled src or deobfuscated API, you will either have to decompile mod on your own or use massive Reflection hax to interact with other mod without it even knowing.

Do you even code, or you just randomly thought "Let's make a mod!" Referenced libs are literally those you see in picture. e.g: forgeSrc is lib that holds all mc and forge files. As to "seeing" what you want - change eclipse view to either "Java" or "Java EE".

if (isDeobf) get("someFieldName"); // the one you see in dev else get("someSRGName"); // the one from MCPBot SRG names are available in mentioned MCPBot: http://mcpbot.bspk.rs/ Additionally for very simple reflection stuff there is ObfuscationReflectionHelper.class which has some utils.

Dude... what version? In 1.9 you need factory, besides - why can't you just look into vanilla.

There is NO Forge for any other 1.9 version than 1.9 itself. Do NOT download from any other source than: http://files.minecraftforge.net/ Yes, you can only have 1.9 forge server to which you can connect only with 1.9 forge client. 1.9.4 is being worked on.

I mean the error is pretty much obvious. Debug your NBT code. What is the problem? Just put some breakpoints/prints there and wait for crash. Then again - why care about 1.8 when you alredy have 1.9 and we will have 1.9.4 soon.

Do you see vanilla throwables hitting throwers? I don't, and no - that is not a bug. If client doesn't need something - you don't force sending it. Yes, you can easily implement IAdditinalSpawnData (name of sorts) and send thrower within spawn packet as entityId. No, even if client would detect that thrown thing hit anything - client is NOT responsible for applying hit (meaning you don't call setDead() on client). What I am saying is basically this: If you don't need client to know thrower, you shouldn't care about what client does with that data. Server is the one who is supposed to kill throwable. Unless I didn't get your point.

You can't use == to compare strings in java. Use equals(). As to design - you should consider using class comprasions (isAssignableFrom() and EntityList.class from mc).

You can't code (mod) anything remotely cool without having Java experience. Don't even start touching this before reading tutorials on Java. Go to official oracle tutorials on basic stuff. No, you don't leave it like this, you implement its methods and modify code to actually use interface (saving/loading/syncing owner) like it happens in EntityTameable.

EntityTameable is an Animal, while Mobs are NOT. You would have to go on lowest possible level to create such hybrid and it couldn't fit the inheritance hierarchy chain (instanceof would become less informative). If this is supposed to be a Mob then you will need to extend mob and implement IEntityOwnable and make changes (copy) from EntityTameable. Since mobs are aggresive there will be quite some problems. You can always make you mob an animal (like wolf), look at its code.

PlayerEvent.Clone Is called ONLY on server and can be used to copy server data from dead player to new player. Then when new player joins (after respawn) you can send packet from EntityJoinWorldEvent to update client-side NEW player. It WILL work if you use thread safety, which was alredy pointed out.

This is impossible. You must be calling setter method from server. Method itself - it is used to return Capability attached to given thing (ItemStack, Entity, Tile, etc.) when you ask for it. Basically - you ask for "OFFHAND_CAP", it will give you instance of it assigned to thing you ask capability for. Pretty much whole point of CapabilityProvider class, which apparently is NOT even needed (I read it somewhere). Just look at callbacks bruh

If you know your way around Java, only thing Forge requires you to learn is its API. Block, Items, Tiles, Entities, etc. are ALL of vanilla origin - you can simply look into base classes and decide what you want to override. Tutorials will only show basics of doing so (some of methods) and ways of registering stuff to forge - which can also be easily learned just by looking at e.g GameRegistry class. As to tutorials: Some concepts: http://mcforge.readthedocs.io/en/latest/ Some examples (1.8, but still mostly valid, 1.9 introduced some new registration API): https://github.com/TheGreyGhost/MinecraftByExample Google dude - google will give you all the tutorials you need.

Can't you just look into Slot.class? isItemValid canTakeStack Names speak for themselves. Note that this is only for Container/Gui manipulation. There are other ways (direcly from code or hoppers) to insert stuff. You can simply not accept hoppers if that is a problem.

http://www.minecraftforge.net/forum/index.php/topic,31297.0.html If you need more.

Looks fine to me (You could rename AttachCaps method, since it is not exacly EntityConstructing event)

ItemStacks can be inserted by either Container or by world. For container youcan create custom Slot classes which accept proper stuff and sizes. Same goes for IInventory.