Saving the player's name to nbt will NOT automatically send that information to the client - you have to implement IEntityAdditionalSpawnData to piggyback on the spawn packet and write / read custom information that the client needs to know about if you want that data when it spawns.
However, this is not just a server->client issue. The code is run on BOTH sides, which is fine, so you will need to sync it as described above, but you also need to handle cases where the owner might in fact be null. That is super basic Java (and many other languages) - if you get a NullPointerException, then null-check. Simple as that.
If you think that the owner really should not be null, then you have to make sure you can consistently retrieve the owner. Look at EntityTameable / EntityWolf for an example of storing the owner in a way that automatically keeps it synced on the client (uses DataWatcher), as well as how to store and retrieve it.
And OP, for the love of coding, PLEASE rename your variables to something meaningful. No one wants to slog through a bunch of p_103509_a and func_1309826_c when they are trying to help someone. If you want people to help you, make it easy on them, will ya?
1
GuiServer overrides ContainerRepair#canInteractWith to always return false, so Minecraft closes the GUI during the next tick of the player.
You need to override it to do what the super method does: check if the block at the specified position is your anvil and that the player is within range of it.
BlockGoldenAnvil#onBlockActivated incorrectly passes the hitX/Y/Z arguments to EntityPlayer#openGUI, these represent the position on the block that the player clicked; not the position of the block in the world. The BlockPos argument is the block's position in the world.
1
You need to create an NBTTagList and add each position tag to it, before storing it in the NBTTagCompound.
When reading the data, iterate from 0 to NBTTagList#tagCount and use the appropriate getter method from NBTTagList to get each position tag and convert it back to a BlockPos before adding it to childNodeList.
I recommend using NBTUtil.getPosFromTag/NBTUtil.createPosTag to read the positions from and write them to NBT.
1
I was using "extend" in the general sense here, i.e. "add more stuff". I wasn't specifically talking about extending a class.
There's not much documentation on the JSON recipe system, so I'll briefly explain how to add custom recipe, ingredient and condition types.
To add a custom recipe type, first create a class that either extends an existing IRecipe implementation (e.g. ShapedRecipes) or implements IRecipe and extends IForgeRegistryEntry.Impl. You then create a class that implements IRecipeFactory and deserialises the custom recipe type from the provided JSON object.
To add a custom ingredient type, first create a class extends Ingredient or a subclass (skip this step if an existing Ingredient class provides the required functionality). You then create a class that implements IIngredientFactory and deserialises the custom ingredient type from the provided JSON object.
To add a custom condition type, create a class that implements IConditionFactory and deserialises the condition (a BooleanSupplier) from the provided JSON object. You can implement BooleanSupplier with a class (named or anonymous), lambda or method reference.
Create a file called _factories.json in assets/<modid>/recipes that specifies your IRecipeFactory, IIngredientFactory and IConditionFactory classes.
You can see some examples of custom recipe and ingredient implements here and some examples of the JSON files here.
1
You can probably achieve that with a custom ITemplateProcessor.
1
The registry system and registry events are documented here. Events in general are documented here.
The main change in 1.12 is that registry events are fired after preInit instead of before preInit.
You can see how I register my mod's Blocks and ItemBlocks here. You can see how I register my mod's models here.
2
Each JSON file can only contain a single recipe. You can have any number of recipes that produce the same item, they just need to have different names.
1
EntityThrowable#onImpact is called when the entity hits either a block or another entity. When it hits an entity, RayTraceResult#getBlockPos will return null.
EntityPotion#applySplash (called by EntityPotion#onImpact) uses the entity's bounding box as the basis for the effect area.
1
The ID/registry name is converted to a ResourceLocation, so the domain defaults to minecraft if not specified. If you don't specify a domain, ItemMonsterPlacer will automatically replace the specified registry name with the full registry name (including the domain) when it's first accessed.
It will work without specifying a domain, but it's best to be explicit.
1
Chicken is the old name for EntityChicken, the current registry name is minecraft:chicken.
See the wiki or the EntityList.init method for the registry names of vanilla entities.
Apart from that, your NBT structure (and the JSON representation of it) are correct.
2
Your method's parameters are in the wrong order, so it doesn't override ItemFood#onFoodEaten. Always annotate override methods with @Override so you get a compilation error if they don't actually override a super method.
I recommend using your IDE to auto-generate override methods with the correct signature and annotation. You should be able to start typing a method name in the main body of your class to bring up a list of methods you can override.
That said, you don't actually need to override ItemFood#onFoodEaten if you want the food to apply a single PotionEffect; just call ItemFood#setPotionEffect with the PotionEffect and probability.