Choonster

Forge will load advancements from your mod's assets/<modid>/advancements directory. I don't think there's any way to remove vanilla advancements without messing around with the internals of AdvancementManager.

The name of a SoundEvent isn't the name of the sound file(s) it plays, you need to get the file the same way that the sound system does. First use SoundHandler#getAccessor to get the SoundEventAccessor for the SoundEvent's name (SoundEvent#getSoundName). This is a wrapper around zero or more ISoundEventAccessor objects, each of which could be either another SoundEventAccessor (a sound event) or a Sound (a sound file). Then use SoundEventAccessor#cloneEntry to select a random Sound from the event's list of sound files and Sound#getSoundAsOggLocation to get the path to the sound file (a ResourceLocation). One you have the path, use IResourceManager#getResource to get the IResource and IResource#getInputStream to get the InputStream. If the record has more than one possible file, this will select one at random. To get every possible file, you'd need to access SoundEventAccessor#accessorList via reflection.

It was replaced by RegistryEvent.MissingMappings<T extends IForgeRegistryEntry<T>> in the 1.12 registry overhaul. T is the registry type you want to handle the missing mappings for.

Looking at the methods where C08PacketPlayerBlockPlacement was used (PlayerControllerMP#onPlayerRightClick and PlayerControllerMP#sendUseItem), it's been replaced by CPacketPlayerTryUseItemOnBlock (sent by PlayerControllerMP#processRightClickBlock when the player right clicks a block) and CPacketPlayerTryUseItem (sent by PlayerControllerMP#processRightClick when the player right clicks air). What are you actually trying to do?

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.