Choonster

You should be able to check it in your implementation of IBakedModel#getQuads, that's what MultiLayerModel does. It will be null when the model isn't being rendered in the world (e.g. when it's rendered as an item).

PlayerList#getPlayers returns the players in every dimension, so your current code would damage players in any dimension if they happened to be close to the coordinates of the block.

Just report it with the "Report post" link, the moderators will delete the posts and probably ban the user when they come online. Unfortunately the spam seems to build up every day when there aren't any moderators online. Side note: The spam is in Korean, not Chinese.

Block#dropBlockAsItemWithChance is only called on the server. Block#removedByPlayer is called just before that on both the server and the client, but only the client of the player who broke the block. The clients of other nearby players don't know that a block was broken by a player, the server just tells them to play the breaking effects and set the block to air. Why do you need a numeric ID? Packets can send other data types, including strings. Every IForgeRegistryEntry implementation has a numeric ID, which you can access from the corresponding registry with RegistryNamespaced#getIDForObject. Vanilla implementations store their registry as a static field of the entry class, but mod implementations may not. If you only have the registry as an IForgeRegistry, you can't access the numeric IDs directly. There's nothing limiting SPacketSoundEffect to vanilla SoundEvents, it will work with any SoundEvent. Forge's documentation explains the various methods that play sound here. If you create a SoundType and set it as the Block's SoundType with Block#setSoundType, the SoundEvents will be automatically played at the appropriate times (including when the Block is broken). You can also override Block#addDestroyEffects to add any custom effects (and optionally disable the vanilla particles) when the Block is destroyed.

You should only include the item quads for the TRANSLUCENT render layer, this should ensure they're rendered with transparency enabled. You can get the current render layer using MinecraftForgeClient.getRenderLayer. The "flip-v" custom data property (in the blockstates file) is only used by ObjModel, it does nothing for any other type of model.

LivingExperienceDropEvent is fired when a living entity (e.g. a player) is about to drop XP on death, you can cancel it to prevent any XP from dropping.

They don't really do anything themselves, they're just vectors.that store 2 or more coordinates and provide methods for various vector operations (e.g. addition, subtraction, normalisation, dot and cross product). The number in the name is how many coordinates the vector stores (i.e. the number of dimensions). The letter after the number is the numerical data type used by the vector, e.g. i for int, d for double, f for float.

Create a class that extends TileEntity and implements net.minecraft.util.ITickable (not the ITickable in the client package). The implementation of the ITickable#update method will be called once per tick. You can store a counter in a field of the TileEntity and increment it each tick. When it reaches X (where X is some number you determine based on the proximity of nearby players), damage all nearby players and reset the counter. You could calculate X every time the TileEntity damages nearby players or every tick, depending on how accurate you want it to be. Register your TileEntity class with GameRegistry.registerTileEntity in preInit. Use your mod ID followed by a colon as a prefix for this name (e.g. "<yourmodid>:radiation_block"), since it will be converted to a ResourceLocation. Override Block#hasTileEntity(IBlockState) to return true and override Block#createTileEntity to create an return a new instance of your TileEntity class. An AABB (Axis Aligned Bounding Box) is just a box defined by two points in 3D space: the minimum x/y/z coordinates and the maximum x/y/z coordinates. World#getEntitiesWithinAABB simply returns a list of entities inside the AABB (i.e. entities whose own bounding boxes intersect the specified AABB).

It belongs in src/main/resources. It was only added to the MDK in Forge 1.11.2-13.20.0.2291 and you started with the MDK of Forge 1.11.2-13.20.0.2228 or earlier, so you won't have one unless you've created it. If you don't have one, download the latest MDK, copy it from there into your mod's workspace, edit the "description" property to say something like "<Your Mod> Resources" (this isn't actually displayed in-game for mod resource packs, but may be used by other mods or external tools) and delete the "_comment" property (this just explains the purpose of the file in the MDK).

@Mod.EventHandler is only for FML lifecycle events (that extend net.minecraftforge.fml.common.event.FMLEvent) and only works in your @Mod class. @SubscribeEvent is for regular events (that extend net.minecraftforge.fml.common.eventhandler.Event) and works in any class that's been registered to the appropriate event bus. Events are explained in more detail here. EntityPlayer#addStat does nothing when called on a client player, you need to call it on a server player (from the logical server). If you call the one-argument overload of EntityPlayer#addStat, it will call the two-argument overload with a second argument of 1 (like you're doing now). In your mod's pack.mcmeta file, is "pack_format" set to 3? If it is, Minecraft will only load resources with lowercase names, including lang files. Rename en_US.lang to en_us.lang. If it's set to 2 or not set at all (either because you don't have a pack.mcmeta file or because it doesn't contain a "pack" section), FML will use the LegacyV2Adapter IResourcePack wrapper for your mod's resources. This will still only load resources with lowercase names, except lang files. Lang files will only be loaded with the mixed case names used in earlier versions (e.g. en_US.lang).

You're accessing the players through the client World, which means two things: Your code will crash the dedicated server, where the Minecraft class doesn't exist. You're calling Entity#attackEntityFrom on instances of EntityPlayerSP or EntityOtherPlayerMP, both of which override it to do nothing but fire LivingAttackEvent and return false. You already have a World argument, use this instead of always using the client world. This way you'll fire LivingAttackEvent and damage players when it's called on the server and still fire LivingAttackEvent when it's called on the client. This is a general principle: Use the data you're provided (e.g. the World argument) instead of bypassing it and accessing it yourself (e.g. accessing the client World through Minecraft). Instead of iterating through World#playerEntities, I recommend calling World#getEntitiesWithinAABB with EntityPlayer.class as the first argument. This will return a list of all players within the bounds of the AABB. You can use the AxisAlignedBB(BlockPos) constructor to create an AABB with the BlockPos as the minimum bounds and the BlockPos + 1 as the maximum bounds (i.e. the 1x1x1 space occupied by the block) and then use AxisAlignedBB#expandXyz to expand it by the specified amount in all directions. No. Depending on how frequently you want it to tick, either schedule ticks with World#scheduleUpdate or give it a TileEntity that implements ITickable.

Please post logs in spoilers or on Gist/Pastebin. That doesn't appear to be the full FML log, it ends with a chat message and doesn't show the game stopping. There are a few errors in there, but none of them would crash the game. What's the actual issue you're encountering here?

Open a command prompt in the server's directory and run java -jar forge-<forgeVersion>-universal.jar. When you open the command prompt manually, it will stay open after the server process stops. If you don't know why it's crashing, post the FML log (logs/fml-client-latest.log) in a spoiler (the eye icon) or on Gist/Pastebin and link it here.

MessageTargetEntity is sending the client-side Repeater ItemStack to the server and MessageTargetEntityHandler is passing the copy of this it read from the byte buffer as an argument to ItemRepeater#attackEntity. This copy's IRepeaterData has its cooldown modified, but this cooldown is never used again and the object is garbage collected. The copy in the server-side player's inventory remains unmodified. Instead of sending an ItemStack in the packet, use the ItemStack already in the player's inventory. Another issue I encountered was this code in ItemRepeater#onUpdate: int coolDown = data.getCoolDown(); if(coolDown > 0) { System.out.println("COOL DOWN"); data.setCoolDown(coolDown--); } Because you're using the post-decrement operator, this calls IRepeaterData#setCoolDown with the existing value of the coolDown local variable (setting RepeaterData#coolDown to the same value it already had) and then decrements the coolDown local variable (which is never used again). If you use the pre-decrement operator instead, the cooldown will be decremented as intended. There's no reason to call Object#equals on an ItemStack, ItemStack doesn't override it so it's the same as using the == operator. If you want to compare two ItemStacks by value instead of reference, use the static equality methods in the ItemStack class. Object#finalize shouldn't be called explicitly, it should only be called by the JVM. MessageTargetEntityHandler calls it, even though it doesn't override it and as such will do absolutely nothing. MessageTargetEntityHandler calls ItemRepeater#attackEntity without actually checking if the targeted entity is in range of the player. A malicious client could currently send this packet to attack any entity in the same dimension as the player, regardless of the distance between them. The server should never trust the client. The way the Repeater sets itself as the active item while it's held is a bit hacky and doesn't take into account the off hand. I'd recommend removing this and sending the EnumHand holding the Repeater in MessageTargetEntityHandler instead of using EntityLivingBase#getActiveItemStack. I've fixed the first four issues and pushed the changes to a fork of your repository. You can view or merge the changes here.

In the second example, your variants have an object as their first value so the deserialiser doesn't treat them as fully-defined variants. To fix this, add a property before the "textures" property in each of the variants (a dummy value not used by format will work here). I explain this in more detail here. In future, please post logs in spoilers or on Gist/Pastebin.

The Chickens mod doesn't use the vanilla spawn egg system for its entities, since they're all subtypes of a single class. It has its own spawn egg item. You'll need to handle any mod that uses its own spawn eggs individually if you want your system to work with entities from those mods.

It should work for any mob with a spawn egg registered, regardless of which mod it's from. What makes you think it isn't working with other mods?

Please post code in a code block (the <> button in the editor) or on Gist/Pastebin with syntax highlighting. That's not the same NBT structure created by ItemMonsterPlacer.applyEntityIdToItemStack, it uses "EntityTag" rather than "AnimalTag". The target instanceof EntityMob condition is pointless, as it will always be false. When it's reached, target will always be an instance of EntityAnimal and can't be an instance of EntityMob.

It's not obvious which mod is causing this, so you'll need to remove mods until it no longer happens. Try starting with these:

In future, please create the Git repository in the root directory of your mod (where build.gradle is) and include the Gradle buildscript (build.gradle and gradle.properties), the Gradle wrapper (gradlew, gradlew.bat and the gradle directory), the source code and assets (the src directory) and your mod's license and readme files. See my TestMod3 for an example of the proper structure. I'll start debugging it soon.

Just running the game is enough, you shouldn't need to load a world or connect to a server.

Try running 1.11.2 vanilla first, that should allow 1.11.2 Forge to run.

I can't see any obvious issues with your code, could you create a Git repository for it (if you don't already have one) and link it here? I'll try debugging it myself.

What makes you think the cooldown isn't being set to 100? Are you looking at data from the client or from the server? Capabilities aren't automatically synced between the server and client, you need to sync them yourself. I explain how to sync item capabilities here.

Just have the server send a packet to the player's client in PlayerEvent.PlayerLoggedInEvent. There shouldn't be any need for a request packet here.