Ernio

Before you even try to fix logic, you should fix design. Item is a SINGLETON - it cannot hold data (fields). Item - description of what you are holding. ItemStack - thing held. You need to save data into ItemStack's NBT (or @Capability for 1.8.9+).

Item#shouldCauseReequipAnimation

Google Forge Events. Use PlayerLoggedInEvent. Note: this event is fired only by server thread. More about sides: http://mcforge.readthedocs.io/en/latest/concepts/sides/

After months of seeing you here, I am quite surprised you don't remember stuff like this. 1. Your packets are not thread safe: http://greyminecraftcoder.blogspot.com.au/2015/01/thread-safety-with-network-messages.html 2. You are accessing wrong member fields in handler - this is precisely why most people separate IMessage from MessageHandler. * In #onMessage use message.field, not this.field. 3. Sending packet per tick shouldn't KILL the system, althrough - it shouldn't even be done. Do you even interpolate?! If you really need that much packets you can send updates per 5 or more ticks and then on client just interpolate values. Besides - why are you not using setPosAndUpdate method? (naming might be different). What the hell are you doing anyway? 4. Oh and btw. - your packets don't need dimension since client has only one of those (current) and also - I think you want velocity updates (tho with vanilla its kinda messed up to decode) - in which case you can simply send SPacketEntityVelocity (vanilla) or maybe some of SPacketEntity ones, as of now - idk really, but worth looking into. Server/client movements are more than just sending position updates - its about motion/velocity and interpolation.

Unless something THIS BIG was able to pass before my eyes (and whole google search engine) unnoticed - it doesn't exist. PC edition for MC is Java only. If you are referring to official clients that are written in C++, you are talking about extended Minecraft Pocket Edition for Windows 10 (and few other platforms). No - those are not even close to Java Minecraft which will stay (Java version) in development for at least quite many years if not even forever. If we were to expect C++ ports anytime soon - questions like these have been alredy asked and answers revolved around Forge being made for JAVA and if we were to get C++ version - it is possible that someone (even from forge contributors) might start working on it. As to hiring and all other stuff - highly unlikely. As to C++ capabilities - well, yeah, it would be possible but way I see it the modding would be totally different from current one (and much harder considering even Java is quite too hard for some here - I am refering to ppl that have no clue about coding and try to write a Mod. Said that - mastering C++ is waaaay harder).

About that - If I could gather some people to also work on it, I'd love to "rewrite" Java FX to Minecraft - at least some part of it. If you know FX you know what I am talking about - tree structure, Nodes, Properties, Listeners, Bindings, Events (top-down layered) and most importantly Layouts. If you think about it - project like that would most likely revolutionize everything that is GUI-based. End product could even end up in Forge itself. Sadly - one can't really handle all of it.

Check out: Rendering: * RenderGameOveralyEvent (Client Forge Events) * VertexBuffer / GL (Rendering) Logic: * LivingEvents, such as hurting and stuff (Common Forge Events) * IAttribute / AttributeModifier / AbstractAttributeMap (Vanilla attribute systems) * @Capability (http://mcforge.readthedocs.org/en/latest/datastorage/capabilities/) There is hella lot of stuff to know when dealing with stats and rpg stuff overall.

Well, this is purely Java question and Regex is something I didn't use in a long time, so wait for sm1 else to show up (you probably messed up matcher/pattern). Point of interest (this is totally random/unnecessary response):

Lookup CommandKill#execute Use: EntityPlayer#onKillCommand(); #setDead() is internal method for removing entities from world (as objects), you want to deal max damage (onKillCommand()). Don't forget to call this server (only).

Just look into vanilla resources?

Without thinking much - aren't projectiles supposed to receive velocity updates? "true" in projectile registration.

@Override public void onUpdate(ItemStack stack, World worldIn, Entity entityIn, int itemSlot, boolean isSelected) { NBTTagCompound nbt = stack.getTagCompound(); if (nbt == null) { nbt = new NBTTagCompound(); stack.setTagCompound(nbt); } int knowledge = nbt.getInteger("KL"); int knowP = nbt.getInteger("KLP"); // This is percent, use byte, unless you need to surpass 100. boolean isLearning = worldIn.rand.nextInt(51) + knowP >= 100; if (isLearning) { if (isSelected) { worldIn.spawnParticle(EnumParticleTypes.ENCHANTMENT_TABLE, entityIn.posX, entityIn.posY + 1, entityIn.posZ, 0.0, 0.0, 0.0, 1); nbt.setBoolean("S", false); } else { nbt.setBoolean("S", true); } nbt.setInteger("KL", knowledge + 1); } else { nbt.setInteger("KLP", knowP + worldIn.rand.nextInt(11)); // This will reach 100 very fast. } } Remove #onCreated. It's useless.

It's IExtendedEntityProperties. It does, but only globals and all-time. If one want to start from some point, it's kinda useless (well, you can use time-stamp-like "kill-stamps"). And yeah - you should update to 1.8.9+ (and use capabilities)

1. What is "FMLMessage-way" for you? You mean like you do it in code you gave (assign container to every gui, no matter what)? * Please post update source. 2. Packet delay is not really a drawback, it is just something that cannot be overcome. 3. Mentioned approach (my prev post) is the only viable way of doing it. Container should always go with GuiContainer and GuiScreen should always be client only.

IGuiHandler is designed to connect Container with its GuiContainer. If you don't need Container (and you need it only if you want to hold/display/interact with ItemStacks) you don't use it. In that case opening GuiScreen needs to be done from Client thread using: * player.openGui (which on client will directly call for client element) or * Minecraft#displayGuiScreen If whatever you do to open it (iteract with block/entity/whatever) is fired only on server, you need to send packet from server to client where it will call one of methods above.

Death != Kill Subscribing to events mean you listen to all such events. IN this case - you are listening to whenever EntityLivingBase dies (on client and on server). What you need to do is to make it player specific. 1. Implement http://mcforge.readthedocs.io/en/latest/datastorage/capabilities/ in order to store killings and progress in player (and his NBT). 2. In event - check event.source.getEntity() - if it exist and is player, get that player's capability and increment kill. 3. Obviously, if you want more than one kill tracker you have to hold some lists. 4. This all is harder than you seem to be thinking (seeing your code, you don't really know much about internals).

Some forge examples: https://github.com/MinecraftForge/MinecraftForge/tree/1.9/src/test/java/net/minecraftforge/test You want: NoBedSleepingTest.java and maybe TestCapabilityMod.java As to events - all over google. Get player that does something (in event), get his capability and edit it to your needs. Caps need to be saved to player's NBT - that is also included in links I gave. Oh and there is only sightest change between 1.8.9 and 1.9, so don't worry (one of them is event variable getters in 1.9+).

Use http://mcforge.readthedocs.io/en/latest/datastorage/capabilities/ to store progress/unlocks and forge Events to make changes. It is probably also possible to utilize vanilla's stats system, but that you would have to study on your own (lookup source).

I ment that this is the proper way (one of them as d7 suggested using potions) to perform tick operations on player. BUT It has flaw in design where you need to have player-specific counters. @SubscribeEvent public void onPlayerTick(PlayerTickEvent evt) { // if server // if phase int counter = player#capability#counter if (counter > 0 && counter % 20 == 0) { player.attackEntityFrom(DamageSource.drown, 2); } --player#cpability#counter; } Where this is pseudocode assuming you are holding integer counter in player's capability. Whenever capability counter is bigger than 0, decrement it from tick event. How to make such per-player data storage has been linked. And yeah - this is good advice:

Going through all classes: 1. public static CommonProxy proxy; Is not needed when mod is one-sided. 2. PlayerEvent.PlayerLoggedInEvent Is server ONLY and should NOT be used in client only mods. Doing so will result in: * Firing on SP (intergrated server/lan) * NOT firing on MP (dedicated server/lan) General rule is to write either common or sided mods/code - never do both (in different words: mods should be universal, for client mods - acting same on both SP and MP, unless ofc - there is some special design in play). 3. Now big question: * You say that prints (logs) are reached and they print expected name (I assume). * Then you say it doesn't work. Question is - HOW do you know it doesn't work? My guess it does and you are checking it by typing in chat - which, spoiler alert - will not work as you would want it to. When chat message is written in chat (client) and then sent - server receives it and converts it to "[playerWhoSentIt] + chatMessageReceived" which is then (in this format) sent to all other clients. Logically - if you change the name on CLIENT only, the server one stays intact resulting in "playerWhoSentIt" being non-changed server one. What you are doing there (event you do) only sets display name of client players, which gives you proper return when asking directly using that method. So for example - it will be correct when rendering name tag (should be). But anything that goes through server will most likely not. As to how to deal with chat messages - use chat events to replace string with your own - ClientChatReceivedEvent.

PlayerTickEvent is fired for each player on both sides, you need to: 1. Perform damaging on server - if (!event.player.worldObj.isRemote) 2. TickEvents have 2 phases - START and END - pick one (event.phase). 3. While code itself if not bad in mean of ticks/timing, it is bad regarding design. Held "tickCounter" will be shared between all players (on server side/thread), you can't do it this way. What you need to do is: * Use IEEP (1.8.9-) or @Capability (1.8.9+) to store counter per-player. * Use stored counter in event. * Capability CAN be server-only - unless you need other stuff, or need client to display counter, damaging happens server only, so counter can be too server sided. Links: http://mcforge.readthedocs.io/en/latest/datastorage/capabilities/ http://mcforge.readthedocs.io/en/latest/concepts/sides/

I don't think there is anything consistent/complete as of now. Your best shot is to study those sources: https://github.com/MinecraftForge/MinecraftForge/tree/master/src/main/java/net/minecraftforge/client Some of VertexBuffer and VertexFormat + some GL knowledge will be useful. Client Events and IModel, IBakedModel formats and loaders. On top of that .json loaders (they also allow e.g loading .obj models, basically again - custom model loaders). I highly recommend actually reading THIS forum. Skim through about 10 pages back and you will find some threads on that. I collect all links for threads of interest so maybe some would help: http://www.minecraftforge.net/forum/index.php/topic,37848.0.html http://www.minecraftforge.net/forum/index.php/topic,37784.0.html Even your thread: http://www.minecraftforge.net/forum/index.php/topic,39203.0.html http://www.minecraftforge.net/forum/index.php/topic,35961.0.html http://www.minecraftforge.net/forum/index.php/topic,36101.0.html http://www.minecraftforge.net/forum/index.php/topic,36639.0.html Just some of them + I have no clue what they contain, but you might be able to put something together or catch something interesting. P.S You didn't tell version, note that there has been few changes in 1.8.9->1.9.

While I don't have anything against timestamps - you also need to secure NBT timestamp for multi-dimensions. It is, if you use @Capability Said that - timestamp can often be better, but for short timers I prefere caps.

Make class, implements it and register. IRecipe allows returning result that can be altered by ingredients - so e.g you can check ingredient NBT or damage and transfer it over to result. Where is the problem?

Yup, that is fine - if you have direct reference that is. Registry name on the other hand can be used by other mods which don't. It is probably also used in internal stuff (but I am not the one to talk about this).