Ernio

Tooltip method in Item or ItemTooltipEvent. You could probably return randomly colored string.

Window -> Perspective -> Open Perspective... -> Java

This is proper output. Those are all libs used by MC/Forge. Forge src is in 1st one in list. You are probably in Java EE mode. Might wanna go to Java.

Since I have no idea what you are talking about: How did you setup MDK? Proper: 1. Download some version of Forge MDK from: http://files.minecraftforge.net/ 2. Unpack it to Folder 3. Use terminal, 2 commands: gradlew.bat setupDecompWorkspace ...wait... gradlew.bat eclipse 4. Launch eclipse and choose ./forgeDir/eclipse/ as workspace. 5. Everything is located in libs + you have example mod.

You say the mod has its history, it might be good to freshen some code. I'd just make new project and copy-update file after file. Starting from Main, Blocks and Items, through Entities, Tiles, Events, finishing at Rendering (making some helper methods and abstraction on the way).

I personally would recommend updating to 1.9 and then to 1.9.2. Changes between those two will not be THAT large and most certailny worthier (is it a word?) than doing 1.8.9 and then 1.9+. Between 1.7.10 and 1.8.x there is a hellish path through updating all rendering code. Then between 1.8.9 and 1.9 there is yet again - next model update which basically removes quite some things that Forge added for modders in 1.8.x, but vanilla added it later in 1.9 (basically just when you are done with updating to 1.8.9 Forge IBakedModel formats, you have to rewrite most of IModelBaked to new 1.9 vanilla format which "replicate" what forge did in 1.8.x). So yeah - if any, I'd go straight to 1.9. Perks: * 1.7.10 can be called ancient at this moment, sure it still has users, but there were a LOT of nice things added in 1.8+. * Model system is nice, very clean if you ask me. Keeps everything somewhat "flatter" (clearer) than old ways of rendering. * Code is kinda much more readable, you have generics, docs, "better" names. * New hooks for many things (most of old hacky ways can be now replaced with nice short code). * Forge Capabilities - hell, this is godly powerful. If you use ItemStack-dependend data handling - you will be pleased. E.g: You can have "IEEP-like" (IExtendedEntityProperties) on ItemStacks (load/save NBT only once and normally, e.g per tick, you can operate on anything you want). * Plenty more, really worth it. * Additional: 1.7.10 is not only ancient in terms of Forge. E.g: Bukkit is "dead" and now most ppl start going with Sponge - which is API based on Forge 1.8+. Future is bright for compatibility, clear non-hacky modding and server side mods.

Where are you setting it? Client or server? Are you calling setter method or changing field?

JarShadow. Same way you include APIs.

Okay then: Leave vanilla inventory alone. Just don't touch it. What you want to do is to change display and "some" of internals. Client: * Use GuiOpenEvent, check if gui is gui inventory and open your own GuiContainer instead. * Now you can just make your GuiCustomInv display whatever you want (make it extend vanilla one for convinience). Both sides: * PlayerTickEvent - event.phase == START. * Check if there are items in slots you don't want them to be - move them to possibly other or throw on ground. * Pick up events - check if you can pickup. Some might be useful if you didn't alredy come up with that.

To what end exacly? Vanilla has 27 normal and 9 hotbar slots. Do you want payers to have ONLY 2 hotbar slots and nothing else? I might have some hints for ya.

Removing vanilla hotbar or inventory LOGIC is like charging into goddamn sun with water hose. Just don't. Even if that was somehow possible without coremodding (ASM) I seriosly doubt that it will work anywhere near well. You need IEEP or Capability on your player that will hold your own inventory and then simply don't render vanilla one, but your own using RenderGameOverlayEvent. As to mechanics behind scrolling/buttons of hotbar - from events side (not coremodding) you can only fight that with some client input events (MouseEvent, Keyboard or Keybinding Event, etc.) to simply detect when player pressed proper stuff and not do it. Also - since that is not only way to change currently selected slot in hotbar - you need PlayerTickEvent that will reset current slot back to "desired" one. Seriously, modding something like this will break compatibility with most of inventory mods there are and probably some other. Can't you just leave hotbar alone and simply add additional hotbar on e.g right of screen? Then just make it use other input, like "<" and ">"?

You need !world.isRemote at beggining. Inventory should be only ever edited (in logical means, not syncing) from server. Since I don't have practical experience in manipulating vanilla inventory (because I have my own), I am unsure of this, but - you might have to set some flag affter changing inventory on server to make it sync to client. Some markDirty or something. Or just use inventory-provided method that should do it for you (lookup source). Read more: http://mcforge.readthedocs.org/en/latest/concepts/sides/

Dude... You have no idea what you are doing, do you? Just because it works doesn't mean is is written properly. Post your whole code. compound.getId() return integer-type of NBT where NBTTagCompound equals 10. compound.getTagList("list", nbtTypeOfListElements); - as you can see, yeah, it will cover with 10 since list is NBTTagCompound-based, but if the list was e.g: Strings, then what?

PlayerLoggedOutEvent is fired only by server (logical). If you are only client side you should (almost) never use server logic. Use ClientConnectedToServerEvent and event.isLocal(). If your mod is TRURLY client sided then I don't undertand why would you use SP/MP. SP is SAME as MP, it is STILL a server, just with one player. Also remember about integrated LAN server, which for connecting clients are treated like dedicated.

save/loadNBTData methods are called whenever Entity, IEEP is assigned to, is saved to NBT - that happens when world is dumped on disk, and that happens (actual saving) every "some" ticks or "special actions" - e.g: when on SP and you go to menu, world will be saved. So yes - IEEP is saved inside Entity which is saved inside World. Now, after actually looking at code: YOU DON'T call save/load yourself. Never ever. This is all you need: public class CustomPlayer implements IExtendedEntityProperties { public final static String EXT_PROP_NAME = "CustomPlayer"; private final EntityPlayer player; public CustomPlayerInventory inventory; public CustomPlayer(EntityPlayer player) { this.player = player; } public static void register(EntityPlayer player) { player.registerExtendedProperties(CustomPlayer.EXT_PROP_NAME, new CustomPlayer(player)); } public static CustomPlayer get(EntityPlayer player) { return (CustomPlayer) player.getExtendedProperties(EXT_PROP_NAME); } @Override public void saveNBTData(NBTTagCompound compound) { compound.setInteger("size", inventory.getSomeSize()); } @Override public void loadNBTData(NBTTagCompound compound) { this.inventory = new CustomPlayerInventory(compound.getInteger("size")); } @Override public void init(Entity entity, World world) { } } Obviously in "load" you need to also call inventory.loadFromNBT(parentCompound.getCompoundTag("invTag")). Same (reversed) goes for saving. Additional note: as of 1.8.9+ IEEP is no longer a thing, use Capabilities.

Everything is possible, but that doesn't mean it will work. Any outside ID manipulation will backfire hard on you. IDs are handled internally and are PER WORLD. Some cusomBlock can have different IDs in different worlds. Why do you need it?

What you want is not possible. 1. Mod can only work from time when it was installed. 2. You don't know who explored alredy generated terrain, so analizing dimension data (world's NBT) is not a way to go.

Nope. But that would be easy to do. Assign IEEP or Capability to EntityPlayer and @SubscribeEvent to PlayerTickEvent. Pick one of event.phase (in your case START would be better). Check position of player, get X/Y of chunk and check if entry is in Player's IEEP/Capability. You could save them as simple int[][]. Saving that to NBT is matter of for (map) { setInteger(Key.toString(), Value) }, reading with nbt.getKeySet() - and reading by key->value. Note: 1. Not sure method naming. 2. Link: http://mcforge.readthedocs.org/en/latest/datastorage/capabilities/ 3. I belive there is EntityJoinChunk event, but I might be mistaken (lookup forge event packages).

Anecdote: I remember when I stared coding stuff that heavily changed how mobs act. Since I "come from" performance-oriented programming I was packing literally everything into generic types and operated on some weird-ass ticking (e.g not 20/sec but every 5 or cache-based stuff). The mod itself was applying properties to every living enitity which on server reaches probably above 5000 spawned (depending on loaded area). Using generic data and those caching systems - sure that gave me few MB RAM and maybe little part of tick, but hell - never again. Seriously, as the mod expanded to current version I rewritten everything to object-oriented systems, also I no longer care about per-tick operations. You would have to do some pretty HEAVY stuff to actually slow the game. As of now I probably hold about more than few houdred objects per entity and do pre, mid and post tick on each of them, updating their effects, casting status, some party/guild stuff, literally everything. On top of that I have tons of world- and server-based operations handling quests and shitload of who-knows-what. Result? Hell - the mod takes next to nothing in means of performance (close to vanilla forge) and about few dozens of MB ram more. I hope this will give some view on "how to not care". Just note: I am not talking "don't ever care" - you should, just don't do too many micro-optimizations. EDIT: From all of bad pieces of code I've seen - most of them fail on: * Not caring what happens interanally (e.g: calling methods that have no idea what they "actually" do), just take setBlockState - it also updates light in world if you don't use it properly. * Recursion * Retarded usage of if statements (seriously, order is important).

You most certainly don't want LivingUpdateEvent - that fires per-tick. You need per-frame. Use one of rendering events. Probably RenderLivingEvent. Note that there is pre and post. If you want to edit model somehow you need to do it properly. As to rendering labels - yeah. you probably want Post, but idk. Note: Event is client side (needs to be registered by proxy I guess).

Hey, Long time no see. ItemStack can exist in more forms than just in-world one. But for in-world one: You need to make custom EntityItem (extend) and return it in Item#getEntityItem and mark Item#hasCustomEntity Big note: I have no idea if those are correct names, nor if they exist in 1.7.10. If they are 1.8+ only, you use events: You do the same, then instead of using Item hooks (mentioned) you use EntityJoinWorldEvent - check instance, itemStack and Item of joining Entity and kill it if it is proper item. Then you spawn your custom one with same itemStack. As to how make it indestructible: Just override some methods and make it not react to lava nor have update item-death timer (lookup vanilla src). As to ANY other forms (inventory, chests, mobs, etc.) Is is proven that it would be impossible to cover all cases of itemStack movement across world (meaning there is always a way that itemStack instance will disappear) - what I'm saying - tracking item is impossible.

As coolAlias (I think) mentioned sometime in other post - this is impossible using standard MC entity rendering / ray trace. Even with loads of math covering rotations and simply retrieving part of screen - this will simply not work. There is just too much factors involved. What you "need" to do: Stop thinking about rendering/entity as Minecraft thingy. You probably know those website skin editors? I strongly suggest looking up their code. You will need singular "pixels" (of model) to be represented by mini-entities and render all of them as singularities - only then ray trace has any point (and I don't mean minecraft's ray trace, you need to write whole system as a custom program - like those web editors). At least - that is how I see it.

Don't expect good answers to bad questions. Everything in java 7 or 8 is mostly design choice. Some are very useful (mentioned default and static in interface for making APIs). Don't force any java above 6 just because you think it is better. MC targets Java 6, You "should" too, but if you NEED (and I mean REALLY need) some special feature - nothing stops you from using 6+ (users just ahve to have it).

It would be MUCH better if you could describe what are you after. 1.a. Packets as in IMessage and PacketHandler can be used to do anything for any side. That includes GUI updaes, Tile updates, Entity update, etc. You can even send configs and global-like data (e.g on client connection). This covers how to deal with them: http://www.minecraftforge.net/forum/index.php/topic,20135.0.html 2.a. "Block Events" is a VERY wide term. There are "events" as in methods inside Block.class which you can override when making YOUR OWN blocks. Most of them will be called on both sides - you can use if(!world.isRemote) to execute them only on server. I higly recommend reading this, before continuing: http://mcforge.readthedocs.org/en/latest/concepts/sides As to "actual" Events - Forge Events - we are talking about @SubscribeEvent annotation. Those are fired for any blocks. Again - there are a LOT of different Block-based events. You need to be more specific. Most of them, again - fire for both sides. If you want to make them run only on server thread - you again use if(!world.isRemote). GENERALLY: All data manipulation can only ever happen on server. Client should only ever display stuff (eventually modify it for display purposes) or send requests/actions to server. 2.b. Values anywhere including GUI can be updated in literally any way. If the event is fired on both sides and you expect outcome to be exacly the same - you can freely use those actions to update gui. Just note - client has no access to actual data - what client only does is display, so if outcome of event will vary depending on side (server or client) you need to update client from server - and that you do with packets. 2.c. Well, this thingy has not very wide range of uses. Sure - whatever works for you. Again - remember that server is the one that should manipulate data. 3.a. Again - GUI values can be updated by anything. Most of dynamic updates will simply NEED you to have custom IMessage. Then you can (from handler class) access currently opened screen and change values. Big note: http://greyminecraftcoder.blogspot.com.au/2015/01/thread-safety-with-network-messages.html 3.b. What methods? Are you talking about those shits that seem like they are used for syncing? Well - they are not (at least not if you don't make them to). Generally - IInventory is quite useless for mods (it lacks compatybility and is really just failed interface in my opinion). Note: As of 1.8.9 Forge has new Capability system: http://mcforge.readthedocs.org/en/latest/datastorage/capabilities/ Use this is favor of any IInventory implementation (or actually any other). "So, what should I choose to sync values in the GUIs?" I recommend IMessages mentioned earlier. Lemme just stress this out: It would be MUCH better if you could describe what are you after.

That was a random example. Modifying as in changing values. Simple as that. E.g situation: Say you click button in GUI. Client sends packet that you clicked. Server handles pakcet, does something (logic) and then decides to send a response packet. Client receives response packet which essentially goes to Minecraft#currentScreen or player#currentScreen (I think) checks instanceof and if it is some GuiExample then changes some values based on packet data (e.g: add new entry to some list in gui). This is what I meant. P.S: Oh well... coolAlias was faster