Ernio

Can't directly help you but if you know a mod that does something and you want to learn to do similar thing on your own, I don't think there would be anything wrong in decompiling said mod.

1. Register event class. 2. @SubscribeEvent public void onRenderOvelay(RenderGameOverlayEvent.Post event) { if (event.type == ElementType.EXPERIENCE || event.type == ElementType.FOOD) { event.setCanceled(true); // You can use event like this to cancel rendering of food and exp } if (event.type == ElementType.HEALTH) { int w = event.resolution.getScaledWidth(); // the resolution I mentioned int h = event.resolution.getScaledHeight(); // You can draw whatever you want here. // big note regarding this part: If you ever change bound texture during rendering event you need to set it back to icons, otherwise you will mess up rest of UI. Similar rules apply to GL states (e.g alpha, colorization), etc. this.mc.getTextureManager().bindTexture(Gui.icons); // not needed, example per comment above. } }

Code please? TE, Block, renderer (if there is one).

For 1 and 2: Learn Forge events. @SubscribeEvent. 1. Since "This mod will not be installed server-side.", you probably want o catch client-received chat msgs: * Use ClientChatReceivedEvent 2. * Use RenderGameOverlayEvent. Notes: - Pick Pre or Post. (rather post) - Use event.type (choose one of phases, otherwise you will render many times). - event also ships scale param (which apparently not many know, so just saying). 3. Since mod is not on server, I assume you are asking about chat messages: Lookup GuiScreen#sendChatMessage(String). Or more directly: Minecraft#thePlayer#sendChatMessage(String). Additional notes: Since mod will be client-only, you can use: @Mod(clientSideOnly = true). Oh and this is 1.8+ ONLY (some of this doesn't exist earlier).

I am certain that you just forgot to clear() buttonList in GuiScreen. 1. You should NEVER add buttons from outside initGui() method. * GuiScreen#buttonList is clear()-ed internally: openGui -> constructor -> buttonList.clear() -> initGui() 2. If you are adding buttons during display you need to remove old ones or clear buttonList manually - again - you shouldn't do "new" every tick/frame.

If the field is marked by @SideOnly, it can only be referenced by @SideOnly method. You can have Class with both SERVER and CLIENT methods/fields, but they cannot cross reference each other. Then: If your method is SideOnly, it cannot be referenced by any other common method, thus - you always need to make all your calls by Proxy. Design choice: CommonClass { Map serverLogicalDraftable; // common map for server-logical registry register(IDraftable, World) { if (world.isRemote) proxy.registerClientDraftable(IDraftable) else serverLogicalDraftable.put(name, IDraftable); } } Proxy part: CommonProxy { registerClientDraftable(IDraftable) { // Do nothing } } ClientProxy { Map clientOnlyDraftables; registerClientDraftable(IDraftable) { clientOnlyDraftables.put(name, IDraftable); } } Then you can do similar with getters.

You need to assign TileEntity to your block. Look e.g BlockFurnace. Then, you need a TileEntity (don't forget to register it) which has inventory (depending on version, but you probably want to implement IInventory). Once that is done, you need Container (thing that represents slots in TileEntity) and GuiContainer (a display of Container for client). + You may need packets, but only if you will need dynamic updates of Block/TileEntity. There are many tuts on this + vanilla source.

Damn... your problem is simple: You don't know Java. You seem like don't even know objective coding... learn basics before modding. EntityPlayer#addChatMessage is good approach. Minecraft#thePlayer is client-only player (the one you control), you can't use it in common/server code. Only Proxy can call it (client only class). Saying that - you need common EntityPlayer instance. What I am saying - when do you want to print this message of yours? You can print it from event, from Item/Block methods, from anywhere actually.

MC#thePlayer is the client player which you control. This event is fired for server and client sides - for EVERY player in all server worlds AND for every player in MC#theWorld (client has only one world). Proper way to access player: event.player Additionally: This event has 2 phases (fired twice per tick) - use event.phase to pick ONE. Next: Learn @SideOnly: http://www.minecraftforge.net/forum/index.php/topic,22764.0.html Also: If you want to only ever use this to display stuff for MC#thePlayer - use ClientTickEvent registered from ClientProxy. That one is fired for client only and can safely use MC#thePlayer.

I am coding client mod which should only work (about 90% of it) only if server has proper mod. Please remind me - how do I check that? Would be awesome if I could have this boolean before EVERYTHING else (joining world (client), etc.)

!world.isRemote is used to check if you are on logical server side. The var in example is a pseudocode (world can be taken from e.g: entity.worldObj). EntityTracker is used to check which entities are being tracked by which player. Using it you can send update packets of entities to ONLY players that are tracking it. ExampleEntityPropertySync is a IMessage implementation responsible for sending "this" (a custom IExtendedEntityProperties implementation) to client via SimpleNetworkWrapper. Yes - ExampleEntityPropertySync IS NOT a IEEp instance, it's a packet. ExampleMod.channel.sendTo(new ExampleEntityPropertySync(this), (EntityPlayerMP)entityPlayer); ...will send mentioned above packet to given player. IEEP example: http://www.minecraftforum.net/forums/mapping-and-modding/mapping-and-modding-tutorials/1571567-1-7-2-1-6-4-eventhandler-and SimpleNetworkWrapper example: http://www.minecraftforum.net/forums/mapping-and-modding/mapping-and-modding-tutorials/2137055-1-7-2-customizing-packet-handling-with Short: (packeting) http://www.minecraftforge.net/forum/index.php/topic,20135.0.html BIG NOTE: As of 1.8.9 IEEP is DEPRECATED and then in 1.9 REMOVED from calls! You should really update to 1.8.x and use Capabilities. (we are on 1.9 alredy).

If I were you I'd read how proxies work. Usually people use Common and Client, where Common is also Server. Why? Because server usually doesn't need (can't have) spacial proxy since it also appears on client (server logic). You could have Server and Client proxy both extending Common. Just make sure you put right path to it in @SidedProxy and you don't reference ANY of @SideOnly methods/fields/classes that are on "other side" of the proxy. Readup on proxies and logical sides: http://www.minecraftforge.net/forum/index.php/topic,22764.0.html + Google.

In fact I just really needed 2h nap to refresh brain, it's always best to just read code, yet still - Thanks for help! Extra: I really like flexibility of this system. Only thing that I don't get is why would anyone want to actually use IStorage? I mean - saving and loading happens directly from e.g: capability#serializeNBT() which is part of ICapabilitySerializable - and that one can be easily reimplemented by user of some API. E.g: API gives you come interface for capability and you replace it (implement not-default class) with your own modification, but then - you can also edit its saving/loding processes (serializeNBT()), so why have IStorage? Is it just to give modders way to "only edit saving/loading" or is there some other goal here? Docs say "This allows for a central implementation of saving the data."

http://greyminecraftcoder.blogspot.com.au/2015/01/thread-safety-with-network-messages.html Problably your problem. If not - show WHOLE code (mainly packet).

Well, this code says nothing. Did you implement ITickable for your TileEntity?

Hey guys, While reading all those example codes: https://github.com/MinecraftForge/MinecraftForge/blob/1.9/src/test/java/net/minecraftforge/test/TestCapabilityMod.java https://github.com/MinecraftForge/MinecraftForge/blob/1.9/src/test/java/net/minecraftforge/test/NoBedSleepingTest.java And other sources (docs and google)... ... I can't help to wonder - What the hell am I supposed to do (with my particular implementation). Note: We are only talking about LivingEntities! With IEEP things were pretty straightforward: You bind data on Entity's Construction. It doesn't matter what kind of data it is, you can even bind 1000 different Objects (IEEPs) to different entities, and still keep them all with same registration name (e.g: "MyIEEP"). Well, my big-ass piece of code strongly depends on this fact. I am (was) treating all EntityLivingBase similar to player, with one fact - player had special extension on IEEP registered onto him. Structure: (I = interface obviously) IExtendedEntityProperties --->IExtendedBase (API mod) ------>ExtendedBase (abstract implementation of API) --------->ExtendedEntity (implementation of base) --------->ExtendedPlayer (implementation of base) Now, I was registering stuff like this: @SubscribeEvent public void onEntityConstructing(EntityConstructing event) { if (event.entity instanceof EntityPlayer) ExtendedPlayer.register((EntityPlayer) event.entity); else if (event.entity instanceof EntityLivingBase) ExtendedEntity.register((EntityLivingBase) event.entity); } Now, because of this I was able to use common abstract class (ExtendedBase) to reference either Player or other LivingEntities using: ExtendedBase.get(EntityLivingBase); This was very nice solution since in my mod, all livingEntities have on "profile" (stats), but players can have multiple (ExtendedBase returned singular for Entities and "current" for Player, but using ExtendedPlayer.get(EntityPlayer) you could also skim over "other" profiles (stats)). So now - how can one implement such system when Capabilities REQUIRE you to have default non-abstract implementation class. How can I register different Capability class for LivingEntity and Player, but keep them under same "title/name". Additional question: Can @CapabilityInject be placed anywhere in code? In most examples I see it in Mod's main class but e.g: docs say it can be anywhere?

This shit ain't basic and doing it with no modding (and/or Java) background will only bring you frustration. I doubt there is even a point in writing list of things that you are required to master before even beginning coding this. And yeah - master. You can't just open some Tutorial and copy paste stuff. This ain't that easy. 1. Armour: * Creating Mod's Base, Items, which also includes armour can be found on Google. Once you have that... 2. Opening Gui: * You will need either custom KeyBinding and @Subscribe to InputEvent.KeyInputEvent or just 2nd one and plain Keyboard-press check. * This is also covered (in parts) somewhere which can be found on Google - that includes Forge Events. 3. Actually opening Gui: * Logical thing to do - whenever your KeyBinding is pressed you check (on client) if you are wearing proper armour, then if yes - you open (Minecraft.getMinecraft().openGui(...)) Gui with your TextFields. You will need: * SomeGui extends GuiScreen + 3x GuiNumberField extends GuiTextField somewhere inside and GuiButton with "Ready!" * GuiNumberField will be GuiTextField extension that accepts only numbers. * After writing numbers and hitting "Ready!"... 4. Send packet to server: * Custom SipleNetworkWrapper implementation along with IMessage adn MessageHandler. http://www.minecraftforge.net/forum/index.php/topic,20135.0.html Long (example): http://www.minecraftforum.net/forums/mapping-and-modding/mapping-and-modding-tutorials/2137055-1-7-2-customizing-packet-handling-with 5. Now, on server side: * Check if received data (x,y,z) are "proper" and if movement is legal (you checked in player wears armour on client, but you have to make sure he actually does on server). Setup some "AI" algorithm that will move player to given coords. * The AI is actually worst part of it - It will be hard to write something that can analize where to go to get to some x/y/z. You will most certainly have to use partial pathing. Algorithms like that can be found on internet and in MC src. Note: You can also make movement from client side (something like bot).

Well. It worked for me in 1.8, 1.8.9 and now in 1.9. Best shot: Post whole src on Git. If not... you could call Skype (ernio333), since I've got some time (TeamViewer preferred).

Not an expert, but can't you just cancel it (event)? Modifying outcome is like the sole purpose of Events. Not in IDE so idk is Cancellable.

First of all - learn why you should use logical sides and run logical code on server, where it is supposed to be ran. Second - that is not really how you should do this. Check out vanilla's code for ray tracing blocks. I am unsude where exacly it is in 1.7.10. Why? We alredy have 1.9... cmon man! (update).

Well, there is vanilla EnumFacing which is used among everything in mc.

This will work. It is just that you are doing something else wrong. You are opening gui from Netty Thread (packet). What you need to do, and not only in this case, but in ALL your packets is to pass task to MC's thread. For Client: Minecraft.getMinecraft().addScheduledTask(new Runnable() ... For Server: player.getServerForPlayer().addScheduledTask(new Runnable() ...

Before writing anything, you should learn what it means to use Application Side (Dedic.jar or Client.jar) and logical side (client and server). Some events are for SP, some for MP and some for both. LivingHurtEvent can be fired on Server. Saying that - the event IS FIRED. It is just that your statement (if) stops it. Using minecraft.class in Common code will crash server side (Minecraft is client only class). Using #thePlayer in common code is retarded - #thePlayer is client player you are currently controlling. You need to check: event.entity

Wrap whole thing with if (!world.isRemote).

Way I see it - you would have to (in your Item's rightclick method and on server side: !world.isRemote) manually find all Entities, TileEntities (and maybe other stuff) and simply call update() on each of them. This might be a bit expensive, but that won't be a problem. Real problem might be in syncing and client-laggy display. If you'd force speedup on server, client's code (which is supposed to "replicate" server's acts) will stay in "normal" speed. Because of that you will get re-syncing laggy effect (everything will be qlitching a bit). Those are like... totally theoretical claims.