Choonster

This is an intended feature, not a bug.

This issue has been reported here.

You need to handle any references to client-only classes through your proxy, with methods that return the client player, the client world, etc. In your client proxy, implement these to return the appropriate values. In your server proxy, implement these to throw an exception (because they should never be called on the logical or physical server).

Have you registered all of your messages with unique IDs? This can happen when two messages are registered with the same ID and FML uses the wrong message handler on the receiving side.

Forge's documentation has an introduction to block states here.

If you look for usages of the method, you'll see that PotionUtils.addPotionTooltip uses I18n.translateToLocal to localise it for potion tooltips.

This exception is caused by a client-to-server message (which Forge limits to a single CPacketCustomPayload, i.e. 32,767 bytes), not a server-to-client message.(which Forge splits into a a maximum of 255 SPacketCustomPayloads, i.e. 267,366,480 bytes). Do you need to send all of that data to the server at once? Can you send individual parts that have changed, possibly through the Container? You shouldn't be storing mutable game data in a field of your @Mod class (Caterpillar#mainContainers), since it's shared between logical sides in single player. You should be using World Capabilities or World Saved Data (if storing the data directly in the TileEntity isn't an option). Iterating through a server's World's to find a block at a specific position is very unreliable, what happens when two dimensions have a drill at the same position?

You don't need the old player's thirst data after you've copied it to the new player in PlayeEvent.Clone, just use the new player's thirst data when sending the packet.

You shouldn't be catching IndexOutOfBoundsException, it should be allowed to propagate up to FML's exception handling and/or crash the game. It's only thrown when you've done something wrong that should be fixed. Is the IMessageHandler scheduling a task on the main thread to perform its action? Is it being called at all?

You're trying to send data to the server from the server, which makes no sense.

Use the Simple Network Implementation to send data between the client and server.

That code reaches across logical sides by accessing the server through the Minecraft class, which is client-only. It will also crash the dedicated server. Since FakePlayer extends EntityPlayerMP and requires a WorldServer, it should only be used from the logical server.

I'd suggest having a method on your TileEntity called something like insertHeldItem that takes an EntityPlayer and an EnumHand and attempts to insert the player's held item into the TileEntity's inventory. Use IItemHandler#insertItem to insert into a specific slot or ItemHandlerHelper.insertItemStacked to try and insert into the first slot possible, filling up existing stacks first. These both return the remaining ItemStack that couldn't be inserted (null in 1.10.2 or ItemStack.EMPTY in 1.11.2 if the full stack was accepted), so use EntityLivingBase#setHeldItem to replace the player's held item with this.

Line 429 of RenderItem is the following: if (stack.getItem().showDurabilityBar(stack)) The only value that can be null on that line is the return of ItemStack#getItem, which means an ItemStack with a null Item is being rendered. The method is being called from GuiContainerCreative#drawTab, which draws the tab's icon ItemStack into the GUI. This means that the ItemStack with the null Item is the one you're returning from CreativeTabs#getIconItemStack. Creative tabs need to be initialised before items, so you can't pass an Item to a CreativeTabs constructor. Instead, override CreativeTabs#getTabIconItem or CreativeTabs#getIconItemStack (there's no need to override both) to get the Item from the the field it's being stored in (e.g. in your ModItems class).

Your file probably wasn't encoded in or compiled as UTF-8.

Call TextFormatting#toString to get the formatting code of a TextFormatting value. If you're registering your event handler with EventBus#register, do it from the client proxy (or a client-only class called from it). If your mod is marked as client-only, you can reference client-only classes from anywhere and don't really need a proxy. If you're registering your event handler with the @Mod.EventBusSubscriber annotation, pass Side.CLIENT to it as an argument so it's only registered on the physical client. EntityJoinWorldEvent is fired when an entity is added the world. It should work in any event. Side note: Everything from the start of the quote in your second bullet point to the end of your post is formatted with a white background and black text, which looks quite ugly in the dark theme. I suggest you remove formatting when copying and pasting text into posts (or use Ctrl-Shift-V to paste without formatting).

That should work, but I'd recommend using TextFormatting instead of hardcoding the formatting code in the prefix string. I'd also recommend only setting the prefix when you create the team. Make sure you only add entities to the scoreboard on the client side (register the event handler from your client proxy or pass Side.CLIENT to @Mod.EventBusSubscriber [so it only runs on the physical client] and check that World#isRemote is true [so it only runs on the logical client]). What are you trying to do?

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).