Leaderboard

if the stack size is greater than one, split off the extra, shove them into the player's inventory, then open the gui.

The Minecraft class implements the IThreadListener interface, so you can use an instance of it as an IThreadListener.

You probably should implement it so that your model isn't rendered at a weird scale or rotation in GUIs, on entities, etc. If you're wrapping an existing model that implements IPerspectiveAwareModel, you can likely delegate to that.

Instead, you can "like" a post on the right of the replies.

The server's banned-players.json file is corrupt, either fix it or delete it.

Specifically from your mod(1)? Or a specific Item from your mod(2)? I would take the registry name and get the domain (modid) and compare it to my modid. Then yes that would be the best way to check.

You need a custom IRecipe implementation and add the recipe with GameRegistry.addRecipe(new IRecipeImp(...))

BlockPos#offset returns a new BlockPos offset in the direction of an EnumFacing by a specified amount (or 1). There is no method called BlockPos#getOffset. Use IBlockState#getValue to get the value of a property. Forge's documentation has an introduction to block states here.

TileEntity#getField can't return null. World#getTileEntity is returning null. This is why World#getTileEntity is annotated with @Nullable, you need to account for it returning null. Your IDE should warn you about calling a method on a @Nullable value without checking for null.

How about you check for null instead? Try...catch is actually pretty CPU intensive.

Import the forge src jar into your project java build path libraries.

EnumFacing#offset

So it works? Good. Yeah it is weird, huh.

Ok then downgrade upgrade because that exact version has problems with minecraft.

The Forge wrapper *is* a core mod. In fact, it is a general-purpose core mod that mods the core so you don't have to. Like other core mods, it is prone to conflicts with other mods that try to mangle the vanilla Java. Imagine coding a hook for an event only to have the vanilla class replaced by another mod that never calls your hook... Because it is general-purpose, it tends to conflict with anything and everything that tries to mod the core. Therefore, it does not guarantee interoperability with other core mods, and even warns that installing other core mods is probably a Bad Thing (i.e. leads to unpredictable results up to and including infinite loops that can eat all your memory and crash your OS with total loss of unsaved work). Clear?

Are you using an nvidia driver? If not this might help.

Client-Server architecture takes a few knocks to wrap one's head around, especially when Eclipse runs both on a single machine sharing a single JRE. For most classes and their constructors, it doesn't matter. If yours is coughing up a lung (and it's not an obvious rendering action crashing the server), then start wrapping your head... Look into the way that vanilla entities spawn. See how the dance is done so that the server makes decisions and the client follows its lead (an entity's image is on the client, but its soul is on the server). Usually, if your mod operates at the right level of abstraction, the client-server interaction (messages etc) are handled for you. If you happened to discover a class or method that looked useful but is down in the weeds, then you might accidentally be short-circuiting the process.

I feel like you probably understood what I told you, but what you said doesn't make a lot of sense. In your ClientConnectedToServerEvent handler, you need to call IThreadListener#addScheduledTask with an implementation of Runnable that actually performs the desired task. This can be a regular class, an anonymous class, a lambda or a method reference. Forge's documentation explains how to get the IThreadListener for each side here.