Choonster

If you use the Scoreboard from the client World and enable glowing for the entity from EntityJoinWorldEvent, it will work without issue in single player and multiplayer. You should generally treat single player and multiplayer identically. Usually if something works in single player but not multiplayer, you've tried to reach across logical sides. Note that any changes to the team or its membership on the server side will overwrite the changes you've made on the client side.

Don't implement IItemColor on your Item, it's a client-only interface and as such will crash the dedicated server if you reference it in common code. You need to create a completely separate implementation of it (e.g. with an anonymous class or lambda). You can't store the SingularityType in a field of your Item class unless you create and register an instance of the class for each SingularityType. You need to use the ItemStack's metadata value to get the SingularityType. You should store the colours as part of the SingularityType enum rather than using a giant switch statement to determine the colour.

As I said in your other thread, that method can add any entity to a team, not just players (despite the name). You shouldn't create a ScorePlayerTeam or a Scoreboard yourself. Use World#getScoreboard to get a World's Scoreboard and Scoreboard#createTeam to create a ScorePlayerTeam.

What exactly do you mean by a texture overlay? To colour an item model dynamically, register an IItemColor for the Item by calling ItemColors#registerItemColorHandler on Minecraft#getItemColors in init on the client side. The tint index passed to IItemColor#getColorFromItemstack tells you which part of the model is being rendered. For regular models, the tint index is manually specified for each face in the model. For models that extend builtin/generated, the tint index for each layerN texture is N.

You don't need MCPBot or SRG names for either of these. Use ScorePlayerTeam#setPrefix to set the team's prefix. The first TextFormatting code in the prefix string will be used as the glow colour of entities on the team.

Use Scoreboard#addPlayerToTeam to add an entity (not just a player) to a team. Pass the entity's UUID string (Entity#getCachedUniqueIdString) as the player argument. If the team doesn't exist, you'll need to create it (Scoreboard#createTeam) before adding any entities to it.

What do you actually need to do? Why do you require SRG names? MCPBot is documented here.

It's an interface with a single method, implement it to return Collections#emptyMap. There's no need for a tutorial or example. Register it by calling ModelLoader#setCustomStateMapper on the client side in ModelRegistryEvent (if you're registering your Blocks/Items in RegistryEvent.Register) or preInit (if you're registering them in preInit).

You can fix this by registering an IStateMapper that returns an empty Map. I'm not too sure about this.

The crash looks like this issue, which was fixed in Forge 1.11.2-13.20.0.2235. Update to the latest of version of Forge and it will either crash with a clearer message or not crash at all. However the root cause of the issue is the fact that your Block is being rendered as the missing model. The FML log will have an error in it stating exactly why this is, but I suspect it's because your Block has two properties that aren't accounted for in the blockstates file. To fix this, either register an IStateMapper for your Block to ignore those properties (recommended) or include them in your blockstates file (not recommended).

Entity#getEntityBoundingBox is the method you want, not Entity#getBoundingBox.

Override Block#getComparatorInputOverride to return the comparator output level stored in your TileEntity. When this level changes, call TileEntity#markDirty to notify Minecraft that the TileEntity's data has changed (so the chunk containing it won't be skipped when saving the world) and update the output level of adjacent comparators. The client shouldn't be involved in this, it will simply return 0 (the default value of an int) from Block#getComparatorInputOverride if the TileEntity's output level isn't synced (which is fine, since the server's level will be the one used by the comparator).

You cannot use Thread.sleep, that will pause the client or server thread completely and stop the game from running for the duration of the sleep. If you want to delay an action by a certain amount of time, you need to schedule a block update or count ticks in a ticking TileEntity or tick event handler. Why is the client telling the server to run a command? The server should be in charge of the game state (e.g. running commands) and send any data necessary for display purposes to the appropriate clients. The client doesn't need to know the comparator output level, it can simply return 0 while the server returns the actual value. You can't store mutable data in fields of your Block class, it's a singleton shared between all occurrences of the block. Mutable data must be stored in the block state or TileEntity.

World#spawnParticle(EnumParticleTypes, double, double, double, double, double, double, int...) does nothing on the server, it only spawns particles when called on the client. You need to use one of the spawnParticle overloads from WorldServer instead.

You can't delay the return statement, but you can just send the response packet from the SimpleNetworkWrapper as you would a regular packet.

That's correct. When you have a method that does if (some_boolean_expression) return true; else return false;, you can simplify it to return some_boolean_expression;.

You need to render the quads for all EnumFacings (and null), not just null.

Don't return false when the Block changes, otherwise your Block's TileEntity will remain after the IBlockState at its position was replaced with another.

By default, mod TileEntities are replaced any time the block state changes. To change this, override TileEntity#shouldRefresh to return true when the Blocks of the old and the new IBlockStates are different.

I meant EntityCamera, yes. It's actually the EntityHanging#facingDirection field that's null rather than EntityHanging#hangingPosition as I initially suspected; this is because the EntityCamera(World, BlockPos, EnumFacing) constructor doesn't call EntityHanging#updateFacingWithBoundingBox.

You called EntityHanging#onValidSurface without setting EntityHanging#hangingPosition to a non-null value. which probably means that you're calling the EntityHanging(World) constructor instead of the EntityHanging(World, BlockPos) constructor. If this isn't the case, post the ModSecurityCamera class.

You do need your own implementation of IRecipe, though it can extend an existing implementation like ShapedOreRecipe. You need to implement IRecipe#getRemainingItems to return a list containing the container item (ForgeHooks.getContainerItem) for every slot except the shears. For the shears, copy the stack and then damage the copy with ItemStack#attemptDamageItem. If the shears were broken (ItemStack#attemptDamageItem returned true), call ForgeEventFactory.onPlayerDestroyItem with the player returned by ForgeHooks.getCraftingPlayer as the first argument to fire PlayerDestroyItemEvent and then use ItemStack.EMPTY (null in 1.10.2) as the remaining item for the slot. If the shears weren't broken, use the damaged stack as the remaining item for the slot.

Did you try using the debugger?

I recommend handling it in an override of Item#itemInteractionForEntity, which is called when a player right clicks your item on an entity.

No, LootEntryTable takes the ResourceLocation of a LootTable and loads it from the LootTableManager when loot is generated from the containing LootTable. I use LootEntryTable to add one LootTable to another here.