Choonster

I suggest looking at the classes in the net.minecraft.client.audio package. You can probably use SoundHandler#getAccessor to get the SoundEventAccessor of a vanilla SoundEvent and use SoundEventAccessor#addSound to add a sound to it.

If you want to check if two IBlockStates are the same, just compare them with ==. Otherwise you can use BlockStateMatcher to compare two IBlockStates using a Predicate for zero or more properties.

The solution is to override the method in the class that already extends Item (i.e. Chestplate, Helmet, etc.), not to make your registration class extend Item.

LegacyJavaFixer is designed to allow 1.7.10 and earlier versions of Forge to run on Java 8, but you're using Forge for 1.11.2 on Java 7. This means that it won't work and isn't required, so remove it.

Applied Energistics requires Java 8, but you're only running Java 7.

Then you need to get the players from the World, as ctbe demonstrated. It's not directly related to your problem, but it should be noted that WorldTickEvent fires twice per tick per loaded dimension, so ticker will be incremented at least twice per tick with your current code. You need to check the event's Phase and the dimension being ticked to avoid this. You should avoid storing things related to game state in your event handler classes as these are shared between both logical sides (so you could potentially be accessing the fields from two threads at once) and aren't persisted in any way (so the data won't be saved when the client/server is stopped). Use data storage methods like World Saved Data or Capabilities to safely store per-dimension or per-map data that will be persisted with the save. You also need to consider which dimensions are affected by this "Solar Apocalypse", is it all dimensions or only the Overworld? Does each dimension have its own timer, or do they all use the same timer?

Your ModArmors class doesn't extend Item, so there's no onArmorTick method to override. You need to override it from the Item class used for your armour, not the class that registers the Items.

PlayerCloneEvent is fired when a copy of a player is created before they respawn. Use this to copy data from the old player to the new one.

onArmorTick is a method of Item, so you need to override it from a class that extends Item (or a subclass of it). It's only called on the Items that the player has equipped, so override it in your armour's Item class. It's not an event, I think Draco is confused.

It's still the same as it was. This page is the most up-to-date guide on setting up a ForgeGradle workspace and it explains what each step does in a bit more detail.

Draco isn't asking where you want to use the player, he's asking which player you're actually trying to use. If there are 20 players on a server, which one do you want to call the method for?

Minecraft only added the SoundEvent system in 1.9, it doesn't exist in 1.8.9. The SoundEvent class you're referencing is the base class for Forge's sound-related events. I don't remember exactly how the sound system worked in 1.8.9, but I'm pretty sure you just needed the sounds.json file; all the registration was handled automatically.

Yes, it wouldn't be caused by not having Forge installed. Post the FML log (logs/fml-client-latest.log in the game directory) using Gist/Pastebin if you want help with the crash. In future, you should post in the Support & Bug Reports section. This thread should be moved there once a moderator comes online.

FML and Forge come in the same JAR/installer. You have both installed.

Click the Files link at the top of the site or go to https://files.minecraftforge.net/.

The FML log can be found at logs/fml-client-latest.log in the game directory. Either copy it into your post here inside a spoiler (the eye icon) or upload it to Gist/Pastebin and link it here.

You're running Minecraft 1.11.2, but you have a whole lot of 1.7.10 mods installed. Mods (especially coremods) generally only work in the Minecraft version they were built for; very few (if any) 1.7.10 mods will work in 1.11.2. If you're using Mojang's Minecraft launcher, you can set a separate game directory for each profile; allowing each profile to have its own set of mods installed.

"It crashed" doesn't tell us anything. Post the FML log (logs/fml-client-latest.log in the game directory).

The Vanilla and Forge shaped and shapeless recipe classes ignore NBT on their ingredients. You'll need to create your own IRecipe implementation (probably extending an existing one) that checks NBT.

FluidRegistry.enableUniversalBucket must be called before preInit, like I said in my post. You also don't need to create or register your own bucket Item if you're using the Universal Bucket.

Enable the Universal Bucket by calling FluidRegistry.enableUniversalBucket before preInit (e.g. in a static initialiser of your @Mod class), then add your Fluid to the Universal Bucket by calling FluidRegistry.addBucketForFluid in preInit. There's no need to create your own bucket or handle any events, the Universal Bucket does it all for you. You can use UniversalBucket.getFilledBucket to get a Universal Bucket filled with a Fluid (ForgeModContainer#universalBucket stores Forge's UniversalBucket instance) or create an ItemStack of a fluid container, get its IFluidHandlerItem capability and fill it with IFluidHandler#fill. The FluidUtil class contains several methods for dealing with IFluidHandlers, including player interaction.

That class is completely unrelated to your situation. It handles remapping old Block/Item registry names to new ones when they change.

As Draco said, you need to use reflection to access the field. PlayerInteractionManager#durabilityRemainingOnBlock is a non-static field, so it needs to be accessed from an instance rather than the class. This is a basic Java concept. Each player's PlayerInteractionManager instance is stored in the EntityPlayerMP#interactionManager field. Every EntityPlayer on the logical server (when World#isRemote is false) is an instance of EntityPlayerMP.

If you look at the usages of World#sendBlockBreakProgress, you'll see that it's called from various places within PlayerInteractionManager; this is the server-side class that manages block interactions (e.g. breaking) for the player that the instance is attached to. When the player is in the process of breaking a block, PlayerInteractionManager#durabilityRemainingOnBlock stores the current break progress; this is passed to World#sendBlockBreakProgress whenever it changes.