Ernio

If you want to do this using vanilla itself - you can. Look deep into AbstractClientPlayer. Since 1.7 there is whole skin-caching system so idk how to work with it directly, but I did that in 1.6 (changed skin-downloading page). Difference between 1.6 and 1.7 is literally one thing - caching. You will most likely need reflection to access skin fields. You can even change capes.

One thing 1st: When we ask what exactly you need - it will be better for you to answer exactly what you need. This doesn't say anything. Class can be entity, block, tile, player, server, world - tick are in EVERY aspect of game and for each of those aspects you do it more or less differently. Please describe where and why you need ticker - that is very important. If you want to go blindly: ServerTickEvent WorldTcikEvent PlayerTickEvent Overrid entity's onUpdate() or onLivingUpdate(), there is PLENTY of places. How to work with it? Google Forge Event tutorial.

So is there anything else you need? You said "it's not finished" but I don't see a question :C

I was more or less refering to this. Why would you have custom AI at all. ("ape" = old-timer, outdated, you know, stuff like that) You mentioned 1.7.2 so I assumed that in past it worked, and now after mc/forge updates it doesn't. My logic was and is simple: If something doesn't work after update - it is outdated. 1st thing I do in this case is look for replacement. Only later I do tricks. It keeps your code clean and compatibile. Basically what I mean: do not force implementing new systems if you have vanilla implementations.

As edited, I made mistake. As to problem - there are no means in java (outside ASM probably) that would allow you to override final method. What you should do: Stop being an ape and start using new stuff - MC changes, Forge changes - you should too (more compatybility and better code). What you can do: updateEntityActionState() is defined in EntityLivingBase EntityLiving extends EntityLivingBase. Therefore: you can make your own EntityLivingCustom and override EntityLivingBase's method (which is not final). Or, you can go with EntityLiving, but override onLivingUpdate() WITHOUT calling super (which is responsible for calling updateEntityActionState()) and copy super's code into your classe's overriding method. Edit - More info: EntityLivingBase is the first in hiererchy implementing #onLivingUpdate() which is called from its #onUpdate() Doing what was proposed above WILL be simple and NOT that bad.

Sorry, my mistake, I though it was a field.

More explanations: You probably looked (my guess) into repo I linked - it is using PlayerAPI - which provides additional player class hooks. Additional opinion: Do NOT use this API if you won't utilize its full potential. Most of it can be done with Forge directly. As to problem: TickEvents are FML events that occur: Player - server/client for each player (on client, it will be loaded by you players) Server - server for whole server World - server for each world Client/Render - obviously on client Each event has 2 phases (event.phase) - pick one phase, otherwise code runs twice. Minecraft.class is client only class: * You cannot reference it anythwere i common classes (only in client ones, common-class = one which is accesed by server-sided code). * mc.thePlayer is the player yo uare controlling, literally "you". To run code per-player you use PlayerTickEvent and use 'event.player' as your player.

Was about to write same thing. Anyway - how do you people find topics that old? Look into Forge's code before digging almost year old thread. Stuff changes over time. If you need help in implemeting this (TheEdenCrazy) post what you need (exactly) in Modder Support.

This is 1st time I see " :: " in any piece of java code posted on this forum since I've come here. Also - very nice post. I was doing it "slower" in past.

If you want you can call me (check your msg box). That is only because I simply loathe the need of moving my fingers, or so called "writing", while explaining my point. Anyway, my notes: 1. What your keyHandler code does: * Open gui on client * Open gui on server Why I don't like this: * You never know when server receives msg or even if. Unexpected stuff: server won't open container while your client would. * Ofc - that will proobably never happen, but just saying, I don't like this How it should look: * You send packet to server "PacketOpenGui" - on server handler you use player.openGui. #openGui(...) works pretty much like this: - When called on client - calls only client method. - When called on server - calls server method, if method will return valid container, it will send packet to client to open gui for it. Note that you will only use this for containers. 2. You started using static guiIDs (RecipeMod.GUI_CUSTOM_INV), yet: player.openGui(RecipeMod.instance, 0 // you use integer. 3. I don't think you need this check: !FMLClientHandler.instance().isGUIOpen(GuiChat.class) You MIGHT need this tho: FMLClientHandler.instance().getClient().inGameHasFocus 4. Just something that hurts my eyes: (I remind that those are my notes) new ContainerCustom(player.inventory, false, player) Why do people pre-get and pass params? Just pass player 5. You might wanna use switch in future (in GuiHanlder). 6. public boolean isLocalWorld; Don't. No need for additional fields. you have very fine player.worldObj.isRemote. 7. You copied most of container code from vanilla - please CLEAN it up. 8. new SlotCraftingCustom(playerInventory.player Wtf? As mentioned - pass only player to constructor and use it - you are making sphagetti there. 9. Mentioned before: public GuiCustomPlayerInventory(EntityPlayer p_i1094_1_) { super(p_i1094_1_.inventoryContainer); this.allowUserInput = true; } Gui is opened on client, you need to make new container for it: public GuiCustomPlayerInventory(EntityPlayer player) { super(new ContainerCustom(player)); this.allowUserInput = true; } 10. Again - cleanup your code.

http://www.minecraftforge.net/wiki/Creating_NBT_for_items Basically - Item is description of what an item is. Then there is ItemStack that holds data. It has Item, meta, stackSize and NBT. When stack is saved it saves all those fields (note that NBT can be null). You can use NBT to store any kind of additional data. If you look into Item.class you will notice that many methods have 2 version - one is not argumented, one ships ItemStack - that allows you to read properties from stack.nbtTag (there is getter).

Is that your own Item? If so: Use Item#onUpdate() - it runs always when item is in inventory. If that is not your: Don't use server tick. You want PlayerTickEvent. then: event.player.inventory and interate through itemstack. Then e.g : if(stack.getItem() == Items.stick) Note that tick events have 2 phases - pick one. event.phase.

It doesn't (directly). Registration must always happen in init phases. System simply won't allow you do that nicely. What you can do: Base everything about item on its NBT. You can make NBTItem that would pull its model, colors, properties, damage, attributes directly from NBT. For armour (vanilla) you would only have to make 4 pieces. For rest - one class. Lemme tell you - good design allows damn lot wiht NBT (that's what I do).

You need to use TileEntity and decrement timer, then do world.setBlock to air.

Callbacks. 1. Think if there is thing you want in vanilla 2. Think of a name it would have and relations 3. Look there 4. Find by callbacks To find this method you can look into e.g CommandOp.class. Diesieben actually knows most of forge code, so that's a different story

Fun fact: Sending additional data (tho possible) will still require you to actually have client-reader. Also - as mentioned - in-game updating is ridiculus. You would still have to restart the game. What you can do: * Make your own launcher or update-program (like forge installer). * Download updates on startup (preInit of mod) and then force game-restart (I doubt forge will even allow you to realod classes in runtime, I've tried it and it's too messy). * If update of modpack is server-dictated (server decides what client loads) you will still have to code some dynamic loading.

1st things 1st - why? To do what exactly?

You don't copy method. You use it with instance of ServConfMgr: This: (check for nulls) MinecraftServer.getServer().getConfigurationManager().canSendCommands(gameprofile) Or this: ((EntityPlayerMP) player).canUseCommand() // server-side only! Depending what you need - look at code. 1st one is more "internal".

http://www.minecraftforge.net/forum/index.php/topic,31300.0.html

I know of 3 methods of doing it. I personally use: (Player is also OP on single) public static boolean isOp(EntityPlayer player) { MinecraftServer server = MinecraftServer.getServer(); if (server != null) { if (server.getConfigurationManager().getOppedPlayers().getGameProfileFromName(player.getName()) != null || server.isSinglePlayer()) { return true; } } return false; } BUT - this one I coded by digging in deep MC code. People tend to use #canSendCommands() or something like that. Method is somewhere in command classes or server, idk. I will look it up and edit this post. EDIT In ServerConfigurationManager: public boolean canSendCommands(GameProfile profile) { return this.ops.hasEntry(profile) || this.mcServer.isSinglePlayer() && this.mcServer.worldServers[0].getWorldInfo().areCommandsAllowed() && this.mcServer.getServerOwner().equalsIgnoreCase(profile.getName()) || this.commandsAllowedForAll; } For GameProfile: player.getGameProfile()

Recommend? Welp, I've been modding since not-so-popular forge (mc beta, earlier) eveything i can recommend would be 2-3 years old. Only thing I ALWAYS link are those: All basics: http://www.minecraftforge.net/forum/index.php/topic,26267.0.html SimpleNetworkWrapper Packeting: http://www.minecraftforum.net/forums/mapping-and-modding/mapping-and-modding-tutorials/2137055-1-7-2-customizing-packet-handling-with http://www.minecraftforge.net/forum/index.php/topic,20135.0.html IExtendedEntityProperties (IEEP): http://www.minecraftforum.net/forums/mapping-and-modding/mapping-and-modding-tutorials/1571567-forge-1-6-4-1-8-eventhandler-and More info about MC (when updating to 1.8 look at thread-safety with packets): http://greyminecraftcoder.blogspot.co.at/p/list-of-topics.html EDIT Note: There is NO "official" docs. All are small-lacking and deprecated. Forge and MC updates too often. Any questions - I'd post right here.

I belive you wanted to use 1.5.2 because backthen it allowed jar-modding. That is not what forge does/supports now. Since 1.6 forge is a library that loads mods at startup, not pre-modifies jar like old jar-modding. Now to the issue: You will need to learn how to work with forge events. Look them up on google, no point in writing next tutorial in this post, there are plenty. You will be using them to modify behaviour of vanilla. That includes guis. Have look at 'GuiScreenEvent.InitGuiEvent' - you can use it to gain control over opened gui - you can modify button-list there. After adding new buttons, you can make actions with them using: 'GuiScreenEvent.ActionPerformedEvent'

When defining a model you are actually only baking it. It will be used for item-in-world and block-in-world. For the model to be used by item-held you need to register its "inventory version". HAve a look at this repo with base tuts: https://github.com/TheGreyGhost/MinecraftByExample Look into e.g Simple Block tutorial, into its resources (assets) and ClientProxy.

Add: acceptableRemoteVersions = "*" In @Mod annotation.