Draco18s

No errors in the log, recipe not available in-game. gooblob.json, located at resources\assets\oreflowers\recipe: { "type": "minecraft:crafting_shaped", "pattern": [ "xx", "xx" ], "key": { "x": { "item": "oreflowers:oreflowers1", "data": 4 } }, "result": { "item": "oreflowers:sticky_goo", "data": 0 } } (I also tried resources\assets\oreflowers\recipes but another thread indicated that that was wrong). Also, I love how we went to enums for everything, only to then change to JSON files for recipes where raw metadata is used. new ItemStack(oreFlowersDesert1,1,EnumOreFlowerDesert1._4AVELOZ.getOrdinal() Was so good in 1.10 and 1.11.

FMLCommonHandler.instance().getMinecraftServerInstance().getWorld(dimension) Wasn't that hard for me to figure out, I knew that the method took a single integer named "dimension", returned a WorldServer object, and was named getXxxx(...)

IStateMapper is @SideOnly(Side.CLIENT)

The main class does nothing but pass the FML lifecycle events to the proxy. If the proxy is likewise useless, then you aren't registering your entity at all.

Well, your main class is useless, nothing of any worth is there (oh, you need it, it just doesn't help solve your problem what so ever because it forwards everything to the proxy classes which you didn't include). You have a registerGlobalEntityID() method in your entity class, which is both useless (it does nothing) and implies you're doing things Wrong. You should not be using global IDs. Third, /summon Entity303 isn't correct. This implies the default domain, minecraft, which your mod is not a part of. You would need /summon MODID:Entity303 using whatever your MODID actually is. Fourth, this is a forum, not a chat room. 37 minutes is hardly people ignoring your thread. Jesus, wait a bit.

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.