jabelar

Yeah sometimes turning a problem around can be simpler. I think you kinda made my suggestion more complicated than it needed to be. I think it may not have worked because you confused the client and server side processing (usually if something works in single player and not in multiplayer it is a problem with side management). But looks like you made a real attempt and I know packets to sync client can be a pain.

I just asked about this and for 1.12.x, with the new registry events, the recommendation (as I suspected and confirmed by LexManos and discussion with Draco) is that you should now do ore dictionary registration in your item registry event handler after your item registration, as that fires before the recipe registry event.

I have a tutorial on blocks with containers including those with GUI and tile entity here: http://jabelarminecraft.blogspot.com/p/minecraft-modding-blocks-with-guis.html

Updating mod versions can be a bit of a pain, but is usually possible so long as you're a decent Java programmer. You need to be good at Java because you will have to hunt for equivalent functionality which sometimes has been significantly changed. Also sometimes little things like renaming methods happens which can be a pain to track down. I do give some general advice on updating mods, as well as some specific tips for updating some things in my tutorial here: http://jabelarminecraft.blogspot.com/p/minecraft-modding-updating-your-mod.html My tutorial only has specific tips up to 1.10 (still working on learning the 1.12 stuff myself) but those will still apply to you as steps along the way. Hope it helps.

Cool, thanks for the clarification Lex. Draco, yes I also expect it is somewhat tolerant since it registers string keys rather than actual instances so probably works in various orders.

Sure, but what type of GUI are you trying to create. You can read my tutorial to get ideas on the main approaches to common GUI types, but otherwise you should look at what is closest to what you want to do. It is true that when looking through the vanilla code sometimes the naming of things isn't perfect, but still a great way to get ideas. Overall a GUI can be pretty much anything. You could display animated graphics, make a mini-game, etc. But if you're doing something fairly standard, like a block that has a GUI with an inventory then there is a lot of examples out there.

Compasses just happen to be complicated due to returning an angle property so are good example of how powerful the property system is. But ItemElytra returns a boolean so maybe a simpler example. In both cases, the apply() method returns a value that is used as lookup in your master model JSON file. I have a bit more information about this all in my tutorial tip (look down the page a bit) here: http://jabelarminecraft.blogspot.com/p/minecraft-forge-172-quick-tips-gl11-and.html The property system is really simple. You simply apply an override getter that implements an apply() method that returns the possible values, then you create a JSON that maps those "overrides" to specific JSON models. It is very powerful as you can convert things like ItemStack NBT, but you can also process the world (i.e. like ItemCompass) or really look up anything (configurations, capabilities, etc.)

EDIT: Actually giving it more thought, I think it depends on whether you want to register ores against other mods or vice versa. If you want your stuff to act like another mod you'll probably want to ensure the other mod's items are already registered, so then the IRecipe registry event might be better.

Honestly, looking at the vanilla classes is the best way. You can see there are methods for adding buttons, taking action when the buttons are clicked, and so forth. Slots are a bit more complicated because they usually require a container and tile entity. I have tutorials on GUIs here: http://jabelarminecraft.blogspot.com/p/minecraft-forge-1721710-gui-and-input.html

This worked in 1.10 but expect it to still work in 1.12. You need to create and register a VillagerProfession using GameRegistry.register . You can then create one or more VillagerCareers for the VillagerProfession and use VillagerCareer#addTrade to add trades to each VillagerCareer.

I previously followed the advice in the forge documentation (https://mcforge.readthedocs.io/en/latest/utilities/oredictionary/) to register the ore dictionary entries "during the FMLPreInitializationEvent phase, after initializing the blocks and items that you will register". However, now the blocks and items have their own registry events and I believe (based on looking at my console output) that the PreInit is actually before these registry events. So I'm guessing that ore dictionary should be registered in the item registry event after the items? Or is there a dedicated ore registry event? On a related note, how can I tell which things have now have registry events? I tried to follow the code but most of it seems to give generics and I could only find where the block, item and recipe events were fired. But I think potions and biomes are also now using registry events? What is best way to see list of what has such events?

Wait, first you need to clarify what you're trying to do. Are you asking to allow players to create their own recipes, or do you mean you have two sets of recipes (easy mode and hard mode) that you want them to switch between? If you want them to be able to switchthen the simplest way is to look at the config during the recipe registration event and register the recipes according to the config. This would require restarting the game after each change of the config, but it would be safest way.

Look at the way compasses do it -- hint they define a "property" which can be used by the main model JSON to redirect to other JSON models.

When I run into these sort of things I often just simply set a "timer" that delays the action a tick or two. You can just create a boolean field called something like packetSent that defaults to false and is also set to false in the player joins world event and then in the player tick event you can check if it is false and if so (and on the server) you send the packet and set packetSent to true. If the player tick event is too soon as well, you can make the field a counter and set it to something like 2 and count down to delay the packet a couple ticks. If you're worried that two players might join in exactly the same tick you should use a map of booleans instead, but hopefully you get the idea.

I'm not certain but the combat tracker might be up to date on the client side. Each entity living base child class has a combat tracker that indicates what is attacking and what the damage source is. So you can call the getCombatTracker() on the player entity and then get further info such as the damage source and attacker. I guess you'd do it in the Player tick event. Also, if you can't figure out an easier way, you can have the server side send a custom packet to the client with the info you need.

I think the point of the optional "requirements" section of the advancement is to allow for OR operations. If you specify a bunch of item criteria without the requirements then it will be an AND. If you look at the information here: http://www.minecraftforum.net/forums/minecraft-discussion/redstone-discussion-and/commands-command-blocks-and/2809368-1-12-custom-advancements-aka-achievements#Requirements it specifically mentions that requirements are intended to allow boolean combinations of criteria. And an example earlier on that page shows where an advancement can be made if "either" (implying OR) criteria are met. The key to changing the AND to an OR seems toi be the placement of the brackets in the requirements.

Perfect, thanks for the detailed explanation.

You don't have to cancel all spawns. You can check for what is trying to spawn, what dimension you're in and return false if you don't want it to spawn. You should have full control of spawning through that event.

I think the only tricky thing is I'm not sure the exact timing and order of these various events -- you need to tag the entity with the Capability at the time of creation but before the join event if possible. If the join event happens before the capability is fully applied you might need to using a living update event instead. There is possibly an entirely different approach. There is a CheckSpawn event which is used whenever a natural spawn is being considered by the server. I don't believe check spawn is called when using a spawn egg. So you may not have to tag the entities at all, just intercept the check spawn event and return false for those you don't want to spawn in that dimension and spawn eggs should continue to work normally.

Yeah, ExampleMod isn't intended to be "removed" it is intended to be overwritten with your own code. Simply updating the mod info file and start editing the file with the @Mod annotation and you should be up and running.

Okay, but I just tested in my 1.12.1 and if I use all lower case for my lang file it does not translate and if I use old en_US.lang it does. So where would I specify different resource pack format if I wanted to use lower case?

In my 1.12.1 workspace, the referenced library with the Minecraft code only contains an english lang file (en_us.lang). Why doesn't it include the other languages? Also, in previous versions like 1.7.10 the Minecraft lang file was named en_US.lang but I noticed it is now en_us.lang. The capitalization has changed. However, in the forge assets it is still named en_US.lang and I tried both for my mod and it only works for en_US.lang. So why the inconsistency?

I have a tutorial on lang files here: http://jabelarminecraft.blogspot.com/p/minecraft-modding-localization.html

Yes, you could do something like that. Anything that somehow ties the use of the spawn egg to the creation of the entity. I suppose you could make use of the fact that entities have a field for the ticksExisted (or something like that) so when a spawn egg is finished being used you could check area for any of the same entity type that have only existed for a tick or less.

I can't really see an obvious way to tell how the entity was created. The spawn egg class (ItemMonsterPlacer) calls the code that creates the entity but doesn't seem to make any special call or post any particular event. I guess you could create a Capability for entities and replace the vanilla spawn eggs ((or maybe intercept the use of the spawn egg with an item use event) with your own version that not only creates the entity but also updates the Capability to indicate it was created by the spawn egg.