Draco18s

While this may be true, you're still fetching the name from Mojang's server when you don't need to: the player is right there, their name is already cached, just query the cache as D7 has indicated. No need to request from the auth server, no need for a child thread, no need for a callback. EntityPlayer::getGameProfile().getName() Boop, done.

The capitalization changed in 1.11 when Mojang moved to an all-lower-case format for ALL resource files. I am not sure how the vanilla language files are handled, but mod language files can still be loaded with the resource pack format of 2 (current format is 3). As for only the English lang file being available in dev: I'm sure there's a reason, I just don't know what it is.

UUID is the way to go. Never* use a reference to an entity other than by UUID. *There are exceptions, but they're rare

I didn't have a good way of mapping multiple chunks to one ticket.

Ok, so, 1, World implements IBlockAccess, you can check and cast. Or 2, IBlockAcess#getTileEntity().getWorld()

1) One time only: find the field (expensive) 2) One time only: store it in a publicly accessible location (cheap) 2) One time only: set the field accessible (expensive) 3) Every tick: set the value (cheap)

Use Reflection instead. It's a lot easier.

You can't do this. The server is in control. You need to tell the server what you want to do, the server verifies it and sets the itemstack data, and that will sync to the clients. Remember: The client always lies.

Yes, anything that can only be handled by the physical client must go in the Client Proxy. This includes model registration.

http://mcforge.readthedocs.io/en/latest/concepts/registries/#registering-things

This is wrong. If you're using the ModelMesher you're doing it wrong. ModelLoader.setCustomModelResourceLocation() in preInit or the ModelRegistryEvent (and client side) only.

My code uses a separate ticket for each chunk. I am not 100% sure at this point that that is required, but I know that my code can take advantage of that. This code is in my main class because the code is not sided. Both the client and server need to know about the chunks being loaded. I use a list (actually a HashMap) because I need to keep track of all of the tickets and I need to know if the ticket for a given chunk is active or not (if it's active, increment the number of active "references" to that ticket).

When looking at the folder with File Explorer (not in your IDE) is the path src/main/resources/assets/extendedemeralds/models/item or is it src/main/resources/assets.extendedemeralds.models.item?

I hate this: https://github.com/44tim44/Capability_Battery/blob/master/src/main/java/com/bte/mod/proxy/CommonProxy.java#L19 There is no reason to pass the FML lifecycle events to the proxy classes. The only thing you do in those events can be handled by the main mod file just fine. E.g. here's my common proxy: https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/ores/CommonProxy.java Look at how deliciously empty it is. There's exactly 1 external method call. Could it be in the main class? Sure, but with an existing method (needed by client proxy) it made sense to have it there. In your client proxy you do fuckall with most of those methods.

Jar files are zip files. The zip format enforces case sensitivity in its file format specification.

This may help you: https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/industry/ExpandedIndustryBase.java#L180-L204

Loading* You mean loading.

Oh good. You're asking us how to bypass a mechanic you wrote and provided dick all in code for us to even have a clue.

Which bit? All lower case? No, you should still do that. Uploading the project to github? No, you should still do that.

Yes, but you can do other things as well. You just need to figure out how to map the states.

if (this.villagerObj.getDistanceSqToEntity(this.animal) > 2.25D) //Crashes here No, it's crashing trying to calculate the distance. Inside this function. There's only one object here that could be null: this.animal Do a search of your file for "animal =" and tell me what you find and if you still have a problem.

No I can't. I have to assume the opposite, because if I assume that your superclass does something, then I can assume your code works perfectly.

Because we can totally tell what your superclass does.

https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/farming/entities/TileEntityTanner.java#L174-L189

Packets.