Ernio

So you want it to render ON screen, or NOT? Code i gave WILL render it on screen. If not - you are at fault, therefore POST GODDAMN CODE! I ain't helping until you give me something to work with (and yes, I am angry right now, but not at you).

Class: EventsClient @SubscribeEvent public void onOvelay(RenderGameOverlayEvent.Pre/Post event) // pick sub-event { if (event.type == ElementType.ALL) // pick ONE type, otherwise it is rendered few times. { Minecraft.getMinecraft().fontRendererObj.drawString(s, x, y, color); } } Registering: (in ClientProxy by preInit). MinecraftForge.EVENT_BUS.register(new EventsClient());

First of all - there is no "urgent", nor "non-urgent" stuff on this forum. You are not special and will be treated same (if not even worse than people who actually not use words like "urgent"). Second: What events are you using to render this stuff? Third: Why are you using setupOverlayRendering()? Fourth: If not - use RenderGameOverlay event. If you alredy are: post FULL code.

1. Save ghost INTO Entity's IEEP (no problem with that. I for e.g have IEEP on all LivingEntityBase). 2. "Ghost" entity will be save/loaded in some entity IEEP. You simply load that NBT. - If constructed entity is new (not loaded from world's NBT) - your IEEP's "ghost" field (NBTTagCompound of ghost) will be null. - If constructed entity is loaded - you can read Ghost data from entity's NBT. 3. Use EntityJoinedWorld event - there are 2 scenarios: - IEEP's Ghost field is null: ---> Spawn new ghost if needed (some boolean?) ---> Don't do anything, since entity doesn't have ghost. - IEEP's Ghost field is not null - therefore you can use createEntityFromNBT (something like that), and spawn ghost into the world. ---> Doing that you can auto-make entity-to-entity bind (via direct reference). 4. To be on a safe side - use ticking (LivingUpdateEvent) and: 4.1. Check if mentioned entity-to-entity reference is not null, and if it is - try to re-bind it by looking for entity by UUID (which will either find one, and if not - stop looking, there is no entity like that). Simple as that. Also (you alredy asked in other thread) - to make it work properly you need to NOT save ghosts to world, but to entity.

I am quite certain that this will require access to client side (meaning it can't be server mod). As to how to do it - FontRenderer can be extended and replaced (located in Minecraft.class) on startup. You could make extension that could e.g grab 1st character in string-to-render, and based on it - would change font. If you look at how text is rendered you should find how fonts are stored and how to use other fonts (e.g some languages/modpacks have different fonts). Can't be more precise (now) without IDE.

Well, if you know Java, the answer: "Class != Instance" should be enough. If you don't I can only say - learn what above answer means (google). You can't really write anything "nice" without Java As to config ores - you will need to use forge's Configuration. Load config on startup (preInit). Read some values and use them to change properties of new ore instances or their generators. Again - without java, learning to use Config can be hard.

Cauldron as of now is not officially supported. As to unofficial help - problem is in fact that old Forge is VERY different from current versions. Only few oldtime modders/users can help with old versions. In this particular case I doubt that you can do anything without coding fix on your own or hiring someone. Old Forge probably doesn't have those fancy events that would allow to quickly fix worlds, so that's next bad thing on your plate. As to error itself - "might" != "will". Removed stuff is simply represented by nothing, meaning anything that forge won't be able to load will be simply set to air/null. Data (world) once loaded with missing mods will be forever replaced by those "nothings". As long as the missing mod didn't do anything stupid or totally weird, you might be safe. Note: We can't really help without logs and symptoms. Even with that - 1.5.x is too outdated for you to expect good help from here.

All info you need is in code and nothing will explain it better if you want to code advanced stuff. Alike EntityItem (which is almost literally what you want) you will need to extend Entity class and modify it with needs. As to last questions - pretty much. Note that setSize needs to be called on both sides to work properly.

I'd rather pick IExtendedEntityProperties to do this. OP said he wants a per-player inventory accesible by given player (only?). You would want to save inventory of your ender pack inside player's IEEP and make that inventory openable via some item. IEEP tut: http://www.minecraftforum.net/forums/mapping-and-modding/mapping-and-modding-tutorials/1571567-1-7-2-1-6-4-eventhandler-and Else: Do what Drako said, save in itemstack, which is (in my opinion) bad idea (unless you want players to be able to have multiple backpacks). Also - whole idea of having fields in Item class is VERY BAD.

Minecraft.class is client-side class. Dedicated server doesn't have it. Read more: http://www.minecraftforge.net/forum/index.php/topic,33918.msg178740.html#msg178740 Aside from the fact that you cannot use client-side classes in common code, you are also doing everything wrong. You should be doing it rather this way: @SubscribeEvent public void playerDied(LivingDeathEvent e) { if(TobyModXP.keepXp) { if(e.entity instanceof EntityPlayer){ EntityPlayer p = (EntityPlayer) e.entity; total = p.experienceTotal; [b]<- Line 29[/b] lvl = p.experienceLevel; bar = p.experience; } } }

Question tho: Are you aware of the fact that anything not steered from server will cause all clients to see differently? Making any type of client cache and not saving directly on server will make different clients go out of sync after one e.g relogs. Since you are not storing animation states on server - you cannot even send them in spawn packets. Next thing is that even if you wanted to send packets client->server you cannot, without making per-player animation server storage (otherwise one client would override other's data). Then again - making per-player server animation cache would again cause different players to see different things. Solution: Make server perform tasks (goddamit!). EDIT: And yes - that is what you should do - config for server which sends data to clients how they should act on PlayerLoggedInEvent.

Create client NBT cache. Use Java IO (File) - make some cache.dat in your client/mod directory. Use CompressedStreamTools (CST) to write NBT into given file. You can use update events of entites to copy their UUID and animation states to some Storage.class with Map<UUID, AnimationState>. You can call CST's write method from ClientTickEvent every some time to dump data from Storage's Map to HDD. Performance note: Dumping AnimationState from entity to Storage.class can be done even per-tick, but CST's writing-to-file shouldn't be used more than on per-sec basis. Storage note: Without clearing, after some time of new entities (along with new UUIDs) your cache can be big. Be sure to nullify all of it once in a while OR use some smart system (which for client can be hard to write since client only knows about entities that he sees so it doesn't know which entries to remove, eg. entities that were killed when you were offline). BUT it is possible. Dev. note: I WOULD do like above. Also: To gain more precision when you quit game - you can also call CST's write with client's disconnection event or since you would use ClientTickEvent - simply check if game has been deconstructed (by reading Minecraft.class fields).

I just realized, while talking about it, that in a multiplayer environment, it will happen a lot that an entity will exist and will have some value set server side BEFORE a new client connects. Question. When a client connect, does ALL variables set server side will be fully synch with the brand new client side when it will connect? Was about to comment you before-edit post... As to current one: NO Setting stuff and sending it, will not magically tell server to auto-send it whenever it is needed. There are few things to look at here: PlayerEvent.StartTracking - fired on server whenever Player starts tracking some event.target entity. You can use this to instantly send data you need t obe synced. Situations: Some player logs i world where there are a lot of some fishes or whatever. Since this event fires for each entity being tracked you can send update about every singe fish that appeared in players area. PlayerLoggedInEvent - previous event fires when you start tracking other entities, not yourself. This event is precisely for that. There are also: RespawnEvent and ChangedDimensionEvent. Or you can go "fk this" and use EntityJoinWorld event to sent packets needed. EntityTracker - you can utilize it to send packet about some entity to all players currently tracking given entity. Think of it as a very sophisticated "sendToAllAround" which actually sends data to players who need it.

Well, I don't see anything that stops me from making my own world UUID. (WorldSaveData) Thanks for reassuring that those don't exist in vanilla.

What is the most persistent/unique data about world? E.g if I would have world with name X, then remove it, create new onw with same name X, and even same seed. Can I tell if that world is different (like, literally UUID, which I can't find, or probably will in next minutes)?

Comparing current to previous is the only option. Any other way would require either ASM or quite some replacements to vanilla inventory system. As to storin previous values: You need to implements IExtendedEntityProperties, use PlayerTickEvent (note: pick one event.phase, otherwise event is ran twice), make comprasion to previous stack and then refresh. You will probably have to save two fields: player.inventory.currentItem to check if "wheel" slot is same as before. - if it changed from prev pick, item changed. player.inventory.getCurrentItem() compare if previous ItemStack is same as new one (from current tick). I fortog you can just "==", no need to save currentItem. Links: IEEP tutorial: http://www.minecraftforum.net/forums/mapping-and-modding/mapping-and-modding-tutorials/1571567-1-7-2-1-6-4-eventhandler-and

Question tho: You want to recreate some virtual-chest plugin with Forge Mod? That is NOT simple. Asking because what you wrote could also mean that you want to lookup virtual-chests of other players or of that plugin.

entityID is something generated by "next iteration of global entityID", in simple words: "++entityId". It is generated by server whenever server spawns an entity, and then send to client (along with other data) inside spawn packet. That is how MC enstablishes connection between client- and server-side entities. Again: entityID is NOT persistent. And yes: UUIDs are persistent. UUID will be same for both client and server for all entities EXCEPT for EntityPlayer - UUIDs of players work properly on server-side only (at least from what I remember, correct me if this is false). Just because you can't find something doesn't mean you cannot make it. I could swear there was method for that in 1.8, but if not: Iterate over world.entityList and simply compare their UUID with input one until you find right entity. Note that comparing uuids is not super-cheap so you should try not using it milion times every tick. Conclusion: The ONLY was to store persistent link to some entity is to save its UUID.

1. One of possibilities: http://docs.oracle.com/javase/7/docs/api/java/io/File.html#listFiles%28%29 If this abstract pathname does not denote a directory, then this method returns null Is it possible that you made this mistake? (Sry, no time to look deep into code, but that is only null that can be returned there). 2. My guess: Your method has boolean return. Map are Object-oriented, "Boolean != boolean", therefore if you ask Map about something and return is null, null cannot be cast to generic type boolean - and: crash (NPE).

Just a note: It allows you to manipulate bounding box inside 1x2x1 dimension of block (e.g fences being 1x1.5x1). Minecraft is not designed to support bigger bounding box per-block-dimension. So yeah - if you want one block take up few blocks you need ASM (quite lot of it). How it should be done PROPERLY is to make multiblock structure simulating one block with few blocks. Almost anything that can be done with ASM can be done with multiblock in this case.

If you have only server side at your disposal (meaning no client input events), then normal approach allows you to only track "all" movements (with any cause) with PlayerTickEvent. However there is a way of tracking player input. You would have to catch incoming movement packets sent by client to server. http://www.minecraftforge.net/forum/index.php/topic,34566.0.html As said - client and server does it similar way. Note: Advanced modding.

Yes. If you need so much variety that it is not worth caching e.g 100000 different models on startup, you can generate them on-run. You have to dive quite deep into vertex data of BakedQuad format. You can literally generate BakedQuads and return them in ISmartItemModel inside List<BakedQuad>. Have a look at this: https://github.com/TheGreyGhost/MinecraftByExample/blob/master/src/main/java/minecraftbyexample/mbe15_item_smartitemmodel/ChessboardSmartItemModel.java And yeah - learning vertexes gonna take some time and is pain in the ass. You can also track down vanilla code responsible for generating models from textures - it uses similar methods.

Recently a lot of peps ask same question, so I just paste this: http://www.minecraftforge.net/forum/index.php/topic,33918.msg178740.html#msg178740 Hope first three points shed some light on things. As to events: Using: MinecraftForge.EVENT_BUS.register(new SomeClass()); Will grab all @SubscribeEvent methods in that SomeClass new instance and add them to Forge's BUS. Logically - if #register is ran by some proxy (server or client, which will be called only if mod is ran by Client.jar of Dedicated.jar), it will be registered on one side. Given that - you CAN have client-only events. Also note that there are some events that MUST be client-only (rendering events and stuff). Clarification: Registering event is per-game, not per-thread. Only check you can perform is if game it Client.jar or Dedicated.jar. If you want to have some event actually check logical side - you do it inside event with world.isRemote.

It is vanilla semi-bug. Not a thing you should be worried about, but rather a way they coded values back in 1.7.10. In 1.8 Box is adjusted (PLEASE update, cmon ppl, why stay in past?) You shouldn't worry about it.

Above is right, forgot to write that, but also - it DOES NOT mean that code I provided isn't working (beacuse it is). Therefore - if code I gave you didn't work, then the mistake is elsewhere, setting pos before spawning won't help you. Just saying. Post your other code.