Choonster

I created an armour item that replaces your other armour when equipped and restores it when unequipped here. I created an armour item that deletes itself as soon as it's unequipped here. I use these two classes here and here to create an armour set that's automatically equipped when you equip the helmet.

Blocks should be created and registered before Items. Apart from that, I can't see any obvious problems. What makes you think something is wrong? I highly recommend migrating to registry events, they allow you to register things at the right time without worrying about when that is. This will also make it easier to update to 1.12+, where GameRegistry.register is private. I recommend against having a common proxy; proxies are for sided code, common code belongs in your @Mod class (or classes called from it). I recommend using an interface as the common parent of your proxy classes rather than a common proxy class.

Blocks are created and registered before Items, so you can't pass an Item to a Block constructor. When you create your Block instance, your Item fields haven't been initialised yet; so they still contain null.

Hard drive space is irrelevant, RAM is what you don't have enough of.

Anything spawned by WorldEntitySpawner#findChunksForSpawning. This includes any passive or hostile entities spawned in the chunks surrounding players, but not entities spawned in a newly-generated chunk.

Yes, the order is CheckSpawn, SpecialSpawn and then EntityJoinWorldEvent. If an entity with a mount or passengers is spawned, CheckSpawn/SpecialSpawn will only be fired for the main entity; but EntityJoinWorldEvent will be fired for every entity. SpecialSpawn is only fired by mob spawners when only the ID of the entity has been specified in the WeightedSpawnerEntity NBT. If the NBT tag has anything except the ID in it, SpecialSpawn won't be fired.

I don't know of any tutorials, but I will say that DimensionManager still exists.

The Vanilla and Forge registries are stored in the ForgeRegistries class. I think you mean @ObjectHolder.

This PR would have allowed you to control the movement speed while the item was in use, but the author hasn't responded for a while. If you were to update it, it may be merged for 1.12.1 and possibly 1.11.2.

LivingSpawnEvent is the parent of several events, don't subscribe to it directly unless you want to receive every child and you don't care which one is which (which usually isn't the case). LivingSpawnEvent.CheckSpawn is only fired for living entities that spawn passively (in WorldEntitySpawner) and for entities that spawn from mob spawners (in MobSpawnerBaseLogic). Setting the result to DENY will prevent the entity from spawning. LivingSpawnEvent.SpecialSpawn is fired just after LivingSpawnEvent.CheckSpawn in the same places. Cancelling it will prevent the entity from spawning. LivingSpawnEvent.AllowDespawn is fired when a living entity is about to despawn, setting the result to DENY will prevent the entity from despawning. EntityJoinWorldEvent is fired when any entity is about to be spawned (regardless of what kind of entity or where it's being spawned from). Cancelling it will prevent the entity from spawning. LivingSpawnEvent.CheckSpawn, LivingSpawnEvent.SpecialSpawn and EntityJoinWorldEvent can all be used to prevent entities from spawning, the difference is which entities the events are fired for and which additional effects will be prevented when you cancel/deny the event. If the entity is covered by the LivingSpawnEvent children, you should prevent the spawn as early as possible (i.e. with LivingSpawnEvent.CheckSpawn) to stop any additional effects related to the spawning from happening.

SoundHandler#onResourceManagerReload explicitly iterates through every copy of sounds.json for each domain (using IResourceManager#getAllResources), it doesn't just use first one it finds (using IResourceManager#getResource) like most other places in the code do. Looking at the code, it should only replace the sounds present in each sounds.json file (that opt-in to replace existing sounds); I'm not sure why the other sounds are being removed. Try setting a breakpoint in SoundHandler#onResourceManagerReload and stepping through the code.

IStorage#writeNBT is @Nullable, so it can return null. IStorage#readNBT can simply be a no-op. If your capability doesn't need to be serialised to NBT, don't implement INBTSerializable on the ICapabilityProvider you attach with AttachCapabilitiesEvent.

In the launcher, give the profile for each version a separate game directory.

Are there any errors in the log?

RegistryEvent.MissingMappings<T extends IForgeRegistryEntry<T>>, where T is the registry type you want to remap (e.g. Block, Item, Biome).

GUIs only exist on the client, but the server is in control of the game state. You need to send a custom packet to the server when the player clicks the button and make the changes to the player's held item in the packet's handler.

That's not the Minecraft game directory and those aren't the same file names mentioned in the log. This is where Forge is looking for mods: In future, you can follow these instructions when someone asks for a screenshot. This will be much easier to read than a photo of your monitor.

Minecraft has several randomised structures larger than a chunk, e.g. Strongholds, Nether Fortresses, Ocean Monuments, End Cities and Woodland Mansions. You can find the implementations in the net.minecraft.world.gen.structure package. The latter two use the Structure Block format rather than manually setting blocks in code.

Which mods weren't detected? Where did you download the mods from? Post a screenshot of your mods directory.

That is the FML log, but there's nothing about mod rejections in it. Was your connection to the server rejected in that session?

Post the FML log (logs/fml-client-latest.log in the game directory) using Gist or Pastebin.

It's still possible to register recipes from code, but they should be migrated to JSON where possible. If needed, you can create your own recipe, ingredient and condition factories to use from JSON. Now that recipes are managed by a registry, IRecipe implements IForgeRegistryEntry and instances can be registered in RegistryEvent.Register<IRecipe>.

A ticking TileEntity or a TileEntity with a TESR are probably your best options here.

Have you tried making an IIngredientFactory like I recommended? I just implemented one to do this here. I ended up using a custom Ingredient that never matches any ItemStack rather than using Ingredient.EMPTY; this is to prevent the Ingredient from matching an empty ItemStack when the conditions aren't met. I also added a recipe like your example that uses a compound ingredient consisting of an itemRubber ore ingredient and a conditional ingredient that matches Thermal Foundation's Rosin when Thermal Foundation is loaded.

This should have been fixed by this commit (Forge 1.12-14.21.1.2423). Make sure you're using the latest version of Forge.