Draco18s

You would need a custom IStateMapper. For example, I needed something like this, so I used two blockstate files and used the mapper to decide which one to load. https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/flowers/states/StateMapperFlowers.java

Actually.... You want [inside the current chunk] + (8,8) Due to the way Minecraft generates chunks, you want to always offset by 8 blocks in the positive X and positive Z directions. The next chunk in that direction are guaranteed to already exist.

You can't. At some point, somewhere, you have to specify what you want dropped.

http://mcforge.readthedocs.io/en/latest/networking/simpleimpl/

The tripwire probably has a non-default IStateMapper. For example, this block: https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/flowers/block/BlockOreFlower1.java#L114 Has 3 properties. But you'll notice that one of them is distinctly missing from my blockstate file: https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/resources/assets/oreflowers/blockstates/oreflowers1.json That's because this class handles it: https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/flowers/states/StateMapperFlowers.java In my case, the property splits across two blockstate files, but other options are available as well (such as outright ignoring it). You'll have to dig around for the one Vanilla uses for the tripwire. You then call ModelLoader.setCustomStateMapper(block, mapper); to register it.

You can't. You would need to use an event handler and check which block the entity is standing on.

veganism:hemp_tripwire#attached=false,disarmed=true,east=false,north=true,powered=false,south=false,west=true for blockstate "veganism:hemp_tripwire[attached=false,disarmed=true,east=false,north=true,powered=false,south=false,west=true]" net.minecraftforge.client.model.ModelLoaderRegistry$LoaderException: Exception loading model veganism:hemp_tripwire#attached=false,disarmed=true,east=false,north=true,powered=false,south=false,west=true with loader VariantLoader.INSTANCE, skipping Your block has a "disarmed" property but your blockstate file lacks it. Also, you might be interested in using the Forge Blockstate format http://mcforge.readthedocs.io/en/latest/blockstates/forgeBlockstates/ Which doesn't require you to fully specify every possible combination of states. For example I have a block with three properties: https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/resources/assets/harderfarming/blockstates/tanner.json#L17 The facing indicates the rotation, the other two properties specify a submodel (although they could specify anything other than rotation). Forge then automatically combines these.

That will spawn it exactly on top of the player. Probably not what you want, but yes.

There's a few other things to do, as well, such as setting the entity's position. But largely, yes. Take a look around the vanilla code for some other examples of that function in use (right-click -> references -> find in workspace)

World.spawnEntity(...)

In the code that modifies that integer (I mean...you wrote it...)...check to see if that integer is greater than the desired number and if so, give the player the advancement (check vanilla code for how to award advancements).

I doubt the veracity of this statement. You can prove me wrong by posting your code.

I love how your screenshot is completely useless (the fuck does "he turned face" (this isn't even a sentence!) and this cropped screen shot have to do with each other?). Fuck if I can tell what's wrong with your code snippet based on that screenshot.

It looks like it's been through a hash algorithm because Mojang obfuscates the source code. All field names, class names, and method names get replaced with single-letter abbreviations, then two-letter, then three-letter, and so on until there aren't any more to replace. As for complex...well yeah, it has to be. Minecraft as a game is complex and incredibly flexible.

I thought I said that... Oh, I did.

Ok, so. 1) It looks like you are storing the entity's name in a class field. You can't do this, Items are singletons. 2) You need to check whether or not you've already stored an entity or not, and if you have, do something different 3) Figure out how to spawn cows, then work out how to genericize it.

How does EventPriority.HIGHEST solve the client-vs-server issue? I'll give you one hint: It does fuck all about it.

Read the javadoc

They're longs. Do subtraction.

If it's all AI, no, you don't need to do anything for the client. As for the capability, use GetCapability(...) on the entity in question.

Local variables.

That's what the ObjectHolder annotation is for!

Uh. You're not using them correctly. http://mcforge.readthedocs.io/en/latest/concepts/registries/#injecting-registry-values-into-fields public static final Block diamond_block = null; // public static final is required. // Type Block means that the Block registry will be queried. // diamond_block is the field name, and as the field is not annotated it is taken to be the resource path. // As there is no explicit domain, "minecraft" is inherited from the class. // Object to be injected: "minecraft:diamond_block" from the Block registry. Notice how the field is null. Notice how the field is of type Block. Notice how the field name equals the registry name.

The...world...? All entities have a reference to it.