Ernio

So many issues, you didn't understand anything i told you. Start from begining, read my posts, You still have bad Tracking, bad usage of StartTracking, bad data-holding, bad instanceof (why check if player is EntityPlayer for example), a lot of small mistakes, damn, too much for me If you want to solve this FAST (as I don't have time on my hands - I have finals this and next week) call my Skype (ernio333), otherwise, READ everything from begining and debug from very basic level. Edit: And why am I so Skype-hyped - writing is waste of time, this is probably one of things (next to sleeping which is also waste of time) that I loathe the most.

RenderGameOverlayEvent allows you to cancel any vanilla-rendering, I don't know how about mods.

I don't have any experience in actually using 1.8 TE, but question: (everything I know is from 1.6.4 or reading from code straight): There is IUpdatePlayerListBox with update() Why is there no event (or is there?) in TE updating? In World class: Iterator iterator = this.tickableTileEntities.iterator(); while (iterator.hasNext()) { TileEntity tileentity = (TileEntity)iterator.next(); if (!tileentity.isInvalid() && tileentity.hasWorldObj()) { BlockPos blockpos = tileentity.getPos(); if (this.isBlockLoaded(blockpos) && this.worldBorder.contains(blockpos)) { try { ((IUpdatePlayerListBox)tileentity).update(); Yes, we can use WorldTickEvent and re-iterate list again, but isn't that pointless? Unless calling forge event would be less efficient than re-looping ofc. EDIT: To clarify - is there TileEntityUpdateEvent? ------------------ As to thread - above kinda answers what you should be looking at. World has tickableTileEntities, you can get chests from there and operate on their IInventories (using WorldTickEvent). EDIT 2: Welp, you are on 1.7.10 - namings might be different, but idea is still the same. EDIT 3: (dammit) When using TickEvents you have 2 phases, START and END - pick one, otherwise your code will run twice.

1. Make Github/Bitbucket 2. Upload code 3. Post link 4. 5. Profit! Seriously, this needs debugging (if you followed my instructions and everything else is working, the problem is in rendering).

This event is when player start to see other entity, which might be player. In that moment the "event.target" is the player (other) that showed up for you (your client). So what you need is to get data about the "target" and send this data to "player" (you). Above is case of dynamic update. Second case is when you change model and someone actually SEES you - they won't suddenly call StartTracking, because they are alredy tracking you (see you). In that moment, you will need to use the EntityTracker (to find WHO tracks you). Basically whe you change model, the server should get everyone who sees you and send packet that will update them about you. But if someone is NOT tracking you at current time, but will start soon, they will call StartTracking event - that is where you update data about tracked entity directly. Note that you also need to understand the fact - when two players start to track each other, they both call StartTracking, and both will get data about the other guy. That's it, if you don't understand, read everything again, if still not - AGAIN. There is literally everything you need, and why I am saying that - I am out for ~14hours (as told before), call me after if you want more help. And rly - there IS EVERYTHING what needs to be said on this topic.

Yes you shouldn't. Rendering events are called A LOT (FPS-dependent) and sending packet in FPS-time will make you send with ~60FPS about 25 times (depending on ping). Point is - the client will send packet per FPS until it gets response packet that will change value (and that might even take SECONDS with lags - so you would send more and more and moreeeeee...) As to secong "discovery" - no, you don't want to get Id's of OTHER player, but the id of player who changes model. There is player "YOU" and X number of OTHER players. YOU change model (click btn), packet goes to server, server changes server-side IEEP for YOU and sends packet to update their data about YOUR EntityPlayer's IEEP (not theirs, YOURS). Following that, when server sends packets to X OTHER players you need to pack entityId of player who needs to be updater (which is YOU, since you changed model). Then on OTHER's clients, they use Id (which refers to YOU) to update YOUR IEEP model data.

READ again. Still:

This is what you are doing: (joke alert) In short - you are not understanding the fact that one SERVER has many CLIENTS connected and one CLIENT has many PLAYERS (which are other Clients on same server). EDIT: Also what I've wrote before - Some client not always have other client's player constructed - ONLY when they see them (start tracking). If there are 2 Clients on Server, then there is: Server IEEP for ONE Server IEEp for two Client ONE IEEP for Client ONE (himself) Client ONE IEEP for Client TWO (and all other clients) Client TWO IEEP for Client TWO (himself) Client TWO IEEP for Client ONE (and all other clients) Client tells server to change server stuff, and server tells all clients to changes stuff about one specific client. You need to send entityId (player) inside packet that updates client stuff (from server to client) and use that entityId to change IEEP of specific player. If you need more explanations and few nice tricks - call my Skype: ernio333 (online in ~14 hours from now) Also: There is a BIG WALL between rendering and data-handling - don't EVER use rendering events (player rendering) to send packets or calculate stuff, you just use booleans in IEEP of given player that were previously set.

I am sorry, but where did you get "controlList" field? She's on 1.7.10, I am on 1.8, there is not such field as this. Also buttonList is not deprecated (in my Forge version, which might be quite old but STILL it's newer than any 1.7.10, so how can something be deprecated?) Welp, 1.7.10 still gets updates - which might be cause of my "outdateness" - what versions are you on guys?

Read my posts very carefully, you might have missed something. In your proveious post (one with #sendToPlayers) you can't cast Set of something to something. You need to use for each loop and send to all in Set. Tell me what works: (in this format: 1.1 ; 1.2 ; 1.3 ; 2.2; 2.3 ; etc) Situation 1: There is Server and 2 Clients, Client ONE and TWO are logged in and see themselves, Client ONE clicks button, changes model: - Server IEEP is updated - On Client ONE, the IEEP ONE is updated. - On CLient TWO, the IEEP ONE is updated. Situation 2: There is Server and 2 Clients, Client ONE and TWO are logged in and DON'T see themselves. Client ONE clicks button, changes model: - Server IEEP is updated - On Client ONE, the IEEP ONE is updated - When Client TWO starts seeing Client ONE, he gets update about his model Situation 3: There is Server and 2 Clients, Client ONE and TWO are logged in and DON'T see themselves. Client ONE AND TWO changes their models and suddenly "meet" (see themselves): - Both server IEEPs are updated - Client ONE has his model and Client TWO has his model (own entity) - Client ONE sees correct model of TWO, Client TWO sees correct model of ONE

BlockPos is wrapped x/y/z, if I am right (again - I never used that method) the "pos" param in method is the position you want to place the block in, so in probably 100% cases it will be air. You want to check (I think) what is under block, so you need to get Block in BlockPos below the one provided (pos).

Don't use @SideOnly(Side.CLIENT), google why and what it does. I never used method but I belive your return is not valid. You need to offset BlockPos by 1 down. EDIT Short explanation about SideOnly - method/field marked with it will be totally removed from classLoader (might be bad terminology) on provided side. CLIENT is the client.jar (not logical thread side) Using @SideOnly(Side.CLIENT) will make your method never work on dedicated.jar Using @SideOnly(Side.SERVER) will cause your method to only exist in dedicated.jar

Jabelar recently made tutorial on this, best thing is to write your own attack manager (tho I went othwer way and made own hook). http://jabelarminecraft.blogspot.com/p/minecraft-modding-extending-reach-of.html

@N247S - Learn to read, it can't have anything to do with packets (#noHate) Ms_Raven - tried to find something but really couldn't. Few tips for future tho: When you put @Override over method that is being overriden your IDE will correct you if you make mistake - ensures you won't write different method name or something. As to problem - is your constructor called? Maybe you have two classes with same name? Anything like that?

You could use onBlockPlacedBy and check if block under is your block. There might be cases when block is not placed by player (piston) - you can utilize onNeighborBlockChanged.

If you are refering to net.minecraft.util.Timer 1st of all - it's client only, and no - you DON'T use it. It's internal MC class. If you need something to run every sec you use ServerTickEvent.

Welp, this needs to be said. You are now (with your mod) entering area of what I would call "dynamic" data tracking. To make example: There is a SERVER and two CLIENTs. One client joins server and changes it's model, server updates IEEP value to some model. Now second player logs in - he doesn't know about other player's value. You need to tell him. Few facts: - Client only loads Entities that are in visible range (that is 60-256 blocks in "edge" cases). This means that if one player is further than some players visible range he doesn't have it's Entity constructed, thus you can't just send stuff. - Following previous fact - you need to updat value dynamically - when player starts tracking other player. To do that use: PlayerEvent.StartTracking This event is launched (server-side only) when one player "sees" some other entity, you can check if that entity is EntityPlayer and update it's values (send packet from server to client with update - your model for example). EDIT (important) Next thing with packeting is: EntityTracker When player click button to chenge value of his model (I am following what i wrote previously) packet from client is sent to server, server-side IEEP's model vallue is changed. Now, you need to send updates to all that need that value, to do that you will use: EntityTracker et = ((WorldServer) player.worldObj).getEntityTracker(); // player is the one that sent change to his model // now you will make that so all other players that are "tracking" player that changed his model will get update et.func_151248_b(player, YourPacketHandler.getInstance().getPacketFrom(new PacketWithModelupdate())); // Method above sends packet to player and all other players that require update. Private note: This above is tight shit, it's good to know it.

CustomIEEPClass cIEEP = CustomIEEPClass.get(this.mc.thePlayer); Never, ever, ever use one object to define behaviour of all (while you want each to have different obviously). By that I mean you are making all players use you own client-player. This is reason why your movement causes all player models to move with your movements (arms, legs, etc). use player-specific variable (from event). As to synchronizing - as said before, you need to tell other client to change value for your player. CLIENT -> clicks button -> button sends message to servr to change model of player -> server changes model value on server-sided IEEP -> server sends changes value to ALL (including clicking player) players that needs update (see player that sent button-click) -> packets are sent, clients are updated.

item instanceof ItemFood Best shot.

For my defence - this is pure vanilla code from 1.8, you think I wouldn't use for each? Just showing what might not be in 1.7.10.

But he's right. (I mean about what to do, not what he thinks of you, we shouldn't judge here, meh).

Might be, you could implement it on your own. public EntityPlayer getPlayerEntityByUUID(UUID uuid) { for (int i = 0; i < this.playerEntities.size(); ++i) { EntityPlayer entityplayer = (EntityPlayer)this.playerEntities.get(i); if (uuid.equals(entityplayer.getUniqueID())) { return entityplayer; } } return null; } playerEntities is public (in 1.8 ).

Above, and note: you can get player.getUUID() to save player to TileEntity's NBT (one UUID = one player). To retrieve: MinecraftServer#getEntityFromUuid(UUID uuid) // I think there is player-specific method, yet I don't remember Note: UUIDs are only working on server side. EDIT Yup, there is: World#getPlayerEntityByUUID(UUID uuid) - but it works per-world.

Could you please describe what exacly are you after? I pulled part of code from my handler, it works. @Override public Object getServerGuiElement(int id, EntityPlayer player, World world, int x, int y, int z) { switch (id) { case 0: return null; } return null; } @Override public Object getClientGuiElement(int id, EntityPlayer player, World world, int x, int y, int z) { switch (id) { case 0: return new GuiExample(player); } return null; } Where GuiExample extends GuiScreen. Opening is called from client thread (via packet): player.openGui(Main.instance, 0, //whatever params);

Bad, bad, bad I corrected him, because he used Item#onUpdate method with this.sprint, which obviously points out to field in Item.class which is NOT acceptable. Your idea is bad, jabelar. Holding value in MainMod.class is ridiculus since it'll be for client, both onUpdate() and damage-dealing runs on server. Yes, field is temporary and doesn't need saving, it still needs to be saved per-player, your would need either IExtendedItemProperties to get that working per-player (and like said before, no need to save it) or simplier way which I wrote in previous post - save temporary value in Item's NBT itself. Note: Simplier != Better, IEEP is always superior in stufff like that.