Ernio

Explanation: There is one instance of event handler class per game. All fields are shared between worlds and players. What you want/need: (guide) 1. Make sure you know good amount of java before starting (I am not taking about "I know what a for-loop is.") 2. To make it work on per-player basis you need to use IExtendedEntityProperties (IEEP). 3. After making your IEEP implementation, you need to assign it to player via EntityConstructing event. Note: IEEP is an object assigned to entity that can hold its own fields (e.g your counter). Note 2: MC has 2 logical sides: Server and client - every thread has its own enitity (meaning there are two EntityPlayers for each player). Same goes for EntityConstructing event - it will fire for both players and assign IEEP to each of them. That's why you need to synchronize those if you need client to also know what server knows. Tutorials: IEEP: http://www.minecraftforum.net/forums/mapping-and-modding/mapping-and-modding-tutorials/1571567-1-7-2-1-6-4-eventhandler-and Packets: http://www.minecraftforum.net/forums/mapping-and-modding/mapping-and-modding-tutorials/2137055-1-7-x-1-8-customizing-packet-handling-with http://www.minecraftforge.net/forum/index.php/topic,20135.0.html

1st of all - if you are dealing with players, you don't use LivingUpdateEvent (unless you need mid-tick). PlayerTickEvent FTW! Two ways: 1. Use PlayerTickEvent. * Pick tick phase (event.phase == Phase.START) * Do everything else like you did. // Note: This alredy cuts your tick-checks by about few thousand since you are only checking Players. 2. Use LivingHurtEvent * Check if event.source is type of DamageSource.outOfWorld which can only happen precisely when you fall out. * Cancel damage (event) and do everything else like you did. // Note: This cuts whole ticking part, yet LivingHurtEvent will check hurting of any EntityLivingBase. Numbers: Say you got 100 players and 2000 entities. In: 1. You do 2000 position checks per second. 2. I can't imagine having more than 2000 LivingHurtEvents fired per second, unless someone deals damage per tick. Verdict: "Premature optimization is the root of all evil!" Any of those if better than LivingUpdateEvent. Anyway - you obviously have NO idea how much MC does in one tick. Your code is NOTHING compared to rest. It doesn't matter how much code you'd execute in that event, this: player.posY < -60.0D ...alredy cuts out literally everything.

You make your implementation. And register it ofc. Something like this: http://mcforge.readthedocs.org/en/latest/blockstates/forgeBlockstates/ Idk if this si official docs. Only fancy thing is that you don't need that many variants, but shorter files. Depending on rendering operations, it can slow a LOT.

Error is most certainy in superclass GuiContainer#drawScreen. Where? I got nothing. Look there, some enable/disable stuff like RenderHelper.disableStandardItemLighting(); I have no clue what I am talking about, maybe it will point in right direction

Sometimes I wonder where do you get those ideas from. I mean - you find something challenging so you just sit there until you find a way to do it your way, or you just know even more than I thought. Anyway - that's some good shit. Useful AF, now I don't have to do "regen=vanilla(+1)+myStats(+x)" but directly "regen=myStats(+x)".

LivingHealEvent? Note: As far as I remember it is impossible to know how healing was applied. Only thing you can do is to deal damage whenever you know that entity might have been healed (mening: when food is above healing requirement).

IDs are not generated on startup, but per-world. Whenever new world is generated - (or there are missing entries) dictionary is being created in world's data. Dictionary binds names with newly generated IDs. In world1 245 can be Copper_Ore In world2 245 can be Tungsten_Rod

Minecraft cosists of 2 "code" sides and 4 "logical" sides (read: threads). 1. Looking as MC from logical side: There are 4 threads: Server Client Server-Netty Client-Netty 1.1. When running Client.jar: * SP: You have all 4 threads (4) (server is being ran in background) * MP: You only have client threads (2), server threads are ran by server you connected to (meaning you don't have any access to it, only communication are packets) Note that you also use packets when on SP - they are being sent "interanlly". 1.2. When running Dedicated.jar: * Dedicated server has always ONLY 2 threads - server ones. Clients connect to it and server threads operate on data (save/load) while clients only display them. 2. Looking at MC from source view: There is common code - used by both server and client threads, no matter if Client.jar or Dedicated.jar. There is code reserved for client and for server. Whenever you see/use: @SideOnly(Side.SERVER) @SideOnly(Side.CLIENT) It means that given class/method/filed is present ONLY when run on either Client.jar or Dedicated.jar. E.g: Minecraft.class is @SideOnly(Side.CLIENT), that means that class is NOT present (not loaded to VM) when you are running Dedicated.jar. That is why you use proxies when you need some client/server specific getters/setters. 3. What thread use what code? General rule is: Netty threads should NEVER access game threads: http://greyminecraftcoder.blogspot.com.au/2015/01/thread-safety-with-network-messages.html Now to actual question: Most of common code will be used by both threads (server/client). Whenever something gets calles you can perform "logical-check" with: world.isRemote true = this code is being ran by client thread false = this code is being ran by server Same code can and will often be used by both threads, that's why you can see those checks everywhere. Rule is: Manipulating data happens on server (!world.isRemote). 4. Synchronization: Let's talk about events - most of Forge ones are being called on both logical sides. Since you are here about IEEP interface: EntityConstructing event is called on both sides. Both client and server logical thread will assign new IEEP to given entity whenever it's being constructed. Since most calculations should/will happen on server, only server updates given entity's IEEP values. Client needs to be notified. That's where packets kick in. You send them, on client you handle them - generate new Runnable and put it into maing client thread. Example of working with IEEP sync: // in IEEP public void setExp(long exp, boolean notify) { if (exp < 0) exp = 0; this.exp = exp; if (notify) // notify will be true only on server side (it's my method). { Dispatcher.sendPacketTo(new PacketSendExp(this.player, this.getExp()), this.player); } } public class PacketSendExp implements IMessage { private int playerId; private long exp; public PacketSendExp() {} public PacketSendExp(EntityPlayer player, long exp) { this.playerId = player.getEntityId(); this.exp = exp; } @Override public void toBytes(ByteBuf buffer) { buffer.writeInt(this.playerId); buffer.writeLong(this.exp); } @Override public void fromBytes(ByteBuf buffer) { this.playerId = buffer.readInt(); this.exp = buffer.readLong(); } public static class HandlerExp extends AbstractClientMessageHandler<PacketSendExp> { @Override public void run(EntityPlayerSP player, PacketSendExp message) { Entity e = player.worldObj.getEntityByID(message.playerId); if (e instanceof EntityPlayer) { IEEP.get((EntityPlayer) e).setExp(message.exp, false); } } } } Above will update (by sending packet) owner of given IEEP whenever server changes exp value. Note to code above: I have quite background abstraction there. the run() method is actually wrapped Runnable. 5. Just call me: Skype: ernio333 If you want more useful info (really useful).

For arrows - because not only players can shoot arrows (skeletons?) and probably any other EntityLivingBase that you make shoot arrows with your mod. Why in survival? No idea, probably some hidden if statement.

Considering how much code alredy happens in every tick, I'd say that adding one boolean check per CanTrack won't suddenly cause massive performance issue. Hell, I'd even say that it's good that server would retry to add entity until you allow it to do so. Problem rather lies in fact that (not sure about it yet, still reading trackers) that before it would ask "should this guy track this entity", the server has to perform all those chunk-checks if it really should even begin asking. That's bigger performance hit than just a few mod-checks As long as event wouldn't be too widely used and only in special-mod cases, this might be a good idea (yet still: While I've seen mods that could utilize it, the hook itself is quite specific, so for most will be useless). Meh, anyway - I alredy used few other events to make client-sided player literally untouchable until confirmation so... gotta other things to code for now. Thanks guys If anyone sees potential in adding this to Forge, like said: for "special mods cases", give me feedback if I should dig into it.

It does save, you need packets to synch cows after they load (loading is server side). Also, I've cleaned up your code: public class EntityExtendedProperties implements IExtendedEntityProperties { protected EntityLivingBase theEntity; protected boolean isFrozen; public final static String IEEP_NAME = "AGKMEPEntity"; public EntityExtendedProperties(EntityLivingBase entity) { this.theEntity = entity; } public static void register(EntityLivingBase entity) { entity.registerExtendedProperties(IEEP_NAME, new EntityExtendedProperties(entity)); } public static EntityExtendedProperties get(EntityLivingBase entity) { return (EntityExtendedProperties) entity.getExtendedProperties(IEEP_NAME); } @Override public void saveNBTData(NBTTagCompound nbt) { NBTTagCompound data = new NBTTagCompound(); data.setBoolean("isFrozen", this.isFrozen()); nbt.setTag(IEEP_NAME, data); System.out.println(nbt); } @Override public void loadNBTData(NBTTagCompound nbt) { NBTTagCompound data = nbt.getCompoundTag(IEEP_NAME); this.isFrozen = data.getBoolean("isFrozen"); System.out.println(nbt); } @Override public void init(Entity entity, World world) {} public boolean isFrozen() { return this.isFrozen; } public void setFrozen(boolean state) { this.isFrozen = state; } } public class ForgeEvents { @SubscribeEvent public void onEntityConstructing(EntityConstructing event) { if (event.entity instanceof EntityLivingBase) { EntityExtendedProperties.register((EntityLivingBase) event.entity); } } @SubscribeEvent public void EntityInteractEvent(EntityInteractEvent event) { if (event.entityPlayer.getHeldItem() != null) { if (event.entityPlayer.getHeldItem().getItem() == Items.apple) { if (event.target instanceof EntityLivingBase) { EntityExtendedProperties.get((EntityLivingBase) event.target).setFrozen(true); } } } } } public class ForgeEventsClient { @SubscribeEvent public void RenderLivingEvent(RenderLivingEvent.Pre event) { if (EntityExtendedProperties.get(event.entity).isFrozen()) { GlStateManager.pushMatrix(); GL11.glColor3f(0.5f, 2.0f, 10.0f); GlStateManager.popMatrix(); } } } * Have 2 classes for Forge events - common and client. Same goes if you ever use FML events. * Don't register event class in its own constructor - it is not safe (bad practice to pass "this" from constructor). * Register ForgeEventsClient in ClientProxy, logically ForgeEvents go to CommonProxy. * Packets tutorials: Long: http://www.minecraftforum.net/forums/mapping-and-modding/mapping-and-modding-tutorials/2137055-1-7-2-customizing-packet-handling-with Cut and dried: http://www.minecraftforge.net/forum/index.php/topic,20135.0.html You will be sending packet from PlayerEvent.StartTracking - occuring whenever player loads some entity on client. Event fires ONLY on server and should handle sending packets to players.

This is the only and proper way to do this. There is nothing "less than a tick". Hits are calculated every tick onUpdate() by making little box around arrow and checking if the box touches some entity - if yes - checking if that entity can be hit and performing damage. You need to get height of arrow and compare it to entity's eye height. Obviosly you need to grab brackets like [eyeHeigh - 0.2, eyeHeight + 0.2].

Could you post new code of those classes?

Probably NPE. You can't get item before making sure itemStack is not null: if (this.itemStack[1] != null) { Item item = this.itemStack[1].getItem(); if(item == Items.redstone) { --this.itemStack[1].stackSize; if (this.itemStack[1].stackSize <= 0) this.itemStack[1] = null; this.power += 100; } } Note: this is the only error that can occure in code you've provided. If it's not it - it's elsewhere.

public class EntityExtendedProperties implements IExtendedEntityProperties { protected EntityLivingBase theEntity; protected boolean isFrozen; public final static String IEEP_NAME = "AGKMEPEntity"; public static EntityExtendedProperties get(EntityLivingBase entity) { return (EntityExtendedProperties) entity.getExtendedProperties(IEEP_NAME); } @Override public void saveNBTData(NBTTagCompound nbt) { NBTTagCompound data = new NBTTagCompound(); data.setBoolean("isFrozen", this.isFrozen()); nbt.setTag(IEEP_NAME, data); } @Override public void loadNBTData(NBTTagCompound nbt) { NBTTagCompound data = nbt.getCompoundTag(IEEP_NAME); this.isFrozen = data.getBoolean("isFrozen"); } @Override public void init(Entity entity, World world) { this.theEntity = (EntityLivingBase) entity; } public boolean isFrozen() { return this.isFrozen; } public void setFrozen(boolean state) { this.isFrozen = state; } } * Don't use colons, bro, jsut don't. * You don't need world field - its alredy inside entity. * Use EntityLivingBase, not EntityLiving. * That's how you use NBT. * Learn Java conventions (static = capitals)

Post your IEEP class and any other manipulating.

xjon.jum.init.UselessEntities#register(): Try setting updateFrequency for arrow to 3. Right now you have 5 which combined with this fact: xjon.jum.entity.projectile.EntityUselessArrow : 246 if (entity1.canBeCollidedWith() && (entity1 != this.shootingEntity || this.ticksInAir >= 5)) Might be causing problem. But I doubt this is real problem :C I mean, from logical side it shouldn't happen, but worth a shot. You can always extend to e.g: this.ticksInAir >= 10

That I know. And "invisible from code" I mean clients, server obviously has to know its shit I want one client to not know about other client aside from player list it receives (you know, Tab-player-list). More accurate definition to "invisible from code" is simply - client won't construct EntityPlayer when it should (and should = when you start tracking other player), but when I allow it to do so. Understanding of trackers is not as simple as it seems - mainly because it's still obfuscated as hell! I am currently looking for a place to insert custom CanTrack event (and PR it maybe), but damn - gotta make sure nothing can break. Just note: Removing entity from other's tracker will also cause server to not know who tracks whom - I know that. So unless there is a way to say "don't send update packet of this guy to this guy" I want to say "just don't track him" which will give same effect on client side, only server will know even less.

This probably goes to diesieben Is it safe to remove player from another player's tracker? And how? Expected results: When joining game 1st time you should get "uncloseable" GUI with "something". During that time I need player to be not targetable by mobs (there is even for that), immortal (also event). And invisible to other players from "code" side. So I was like: Let's remove this guy from that guy's tracker in PlayerEvent.StartTracking. Sadly - not possible (not cancelable). Is there a way (read: easy way, one I missed) to make other clients not know about certain player? P.S: What stops "us" from making PlayerEvent.StartTracking cancelable? (aside fact that it is called after adding entity to tracker) Eventually - make additional event (since StartTracking is called after all updates are made in EntityTrackerEntry#updatePlayerEntity()) before anything even happens - like PlayerEvent.CanTrack?

It's been a while since I did inventory containers, but note one thing: When assigning ID to slot you assign it per-inventory, not per-container. Meaning: If you have 2 inventories in 1 container, you can have slot with same ID in both inventories. You can't just copy code from vanilla: (I mean, it looks like copy-pasta mistake) net.minecraft.inventory.ContainerPlayer, line 41 this.addSlotToContainer(new Slot(playerInventory, playerInventory.getSizeInventory() - 1 - i, 8, 8 + i * 18) Your line: this.addSlotToContainer(new SlotArmourDefault(player, inventory, inventoryCustom.getSizeInventory() - 1 - i, 8, 8 + i * 18, i)); Seriously?! Anyway: SlotArmourDefault.class would be useful. If you don't get the point: You have 3 inventories there: *Your player *Vanilla player *Crafting In each of those slot ID go from 0 to their size. What you did is add slot to "Vanilla player" with slot id based on "Your player". Idk if it will fix problem, but that is one of them.

You are looking for net.minecraft.item.ItemSword - extend it, override #hitEntity and apply potion effect to target with entity#addPotionEffect. Don't forget to call super.hitEntity as it damages item when attacking.

You will need TileEntity to do that. There are plenty of tuts on net, use google. Come back if you have any questions (post code)

Remember that time when I politely pointed out that you need to learn Java, NOT on minecraft modding? Yeah, now I am urging you to do so. Anyway: 1. @Override is JUST an annotation - it doesn't mean anything outside your IDE. It just helps you make sure you are doing what you want to do (by checking if you are actually overriding something - read: have same method in superclass). 2. Rename your vars goddamit! This is some kind of elvish: p_70612_1_, p_70612_2_, p_110255_1_ !!! 3. I have no clue how or where you were trying to spawn fireball, but you've failed. Miserably! (lol) * Make sure you are on server thread (!world.isRemote) * Set entity-to-spaw positions. * Spawn entity. 4. As above (again faster dammit) - full code please.

And in my opinion sending such big files (considering .png can take MBs) via normal packet pipeline would be retarded, just saying. Open new thread and use standard java downloading. (What player skins do, or did when I last checked). Edit: I MIGHT be wrong about it (asked many times, none ever knew/answered). It just seems more reasonable to not overload main pipeline with huge data. Edit 2: Oh and also - while server->client packets are automatically split if they exceed packet size (sent partially and recreated on receiver), the other way around - they are NOT (last time I checked) - you would have to do it on your own with client->server.

1. Make sure you have enough Java knowledge before starting (writing just in case). If not - start with something else. 2. Look at Minecraft's and Forge's Model system - understand fact that models are "baked" once and reused. In 1.8 there is almost no direct interaction with GL. 3. Lookup Forge's ISmartItemModel. BakedQuad is an element of "baked" model. You can return any number of BakedQuads in #getGeneralQuads(). You can bake them on your own in runtime (requires good knowledge about vertexes) or get them from other models that you can bake on mc's startup. #handleItemState(ItemStack stack) allows you to, based on ItemStack, change your returned model. 4. Example: https://github.com/TheGreyGhost/MinecraftByExample/tree/master/src/main/java/minecraftbyexample/mbe15_item_smartitemmodel 5. Try it yourself, if you have enough skill - you should be able to do it from here. Post any questions.