V0idWa1k3r

No it isn't. FoodStats#setFoodSaturationLevel is though. So in order to modify saturation you indeed need reflection. Or I guess you could write the food stats to the NBT, modify the foodSaturationLevel tag and then read the stats from the modified NBT.

If your code has any reference to that method that is invoked from common code you will crash the server. The client will not observe the model changing as soon as another player comes into range with your current implementation.

Which player? There can be a lot of players on the server... And you have to account for that if your mod isn't client only. You can get the list of all players with World#playerEntities.

EntityPlayerMP is the EntityPlayer of the logical server. EntityPlayer is a base class for players that other classes representing the player derive from. No player would actually be an instance of EntityPlayer. EntityPlayerSP is the player of the client for example.

Depends. Players move on the client and just send the server their new position. Entirely server sided. How would a server even handle mouse clicks if it may not even have a mouse? This is entirely client-side. In general everything rendering or input related is client side only, and pretty much everything else is either common or server sided. Note that when I say server sided I mean the logical server, not the physical server. Every time you need to do something think about it. Could a dedicated server perform it? It has no controlling player, no mouse input, no keyboard input and may not even have any display at all. If it can't - then the thing you are trying to do is client based. Otherwise the server is likely the entity that needs to do it. In general the client doesn't do much at all anyway, it mostly displays stuff. Most logic runs on the server and if you have any custom logic you should run it on a server aswell. Define "not specifying the side".

1.7.10 is no longer supported on this forum. Update to a modern version of minecraft to receive support.

I am not too familiar with gradle myself but I managed to find this answer on stackoverflow.

Why not compare container objects themselves? private static GuiContainer lastInventory; ... @SubscribeEvent public static void handler(TickEvent.ClientTickEvent event) { GuiScreen current = Minecraft.getMinecraft().currentScreen; if (current != lastInventory) { // Opened GUI changed. } ... lastInventory = current instanceof GuiContainer ? (GuiContainer)current : null; }

Are you sure? Because this Is the player's inventory GUI, and player's only.

This is a common event, meaning it is fired for both the client and the server. You are using client-only classes so you must only subscribe your event handler to the bus on the client. Just wait untill there is at least one item in the inventory. They all get synced at once so as long as there is at least one item there are others there too. Your current code only checks the inventory once on the first tick as it is opened which is probably too early. Also Slot#getSlotTexture returns an ItemStack that is used as the background image for the slot, hence the name. You need Slot#getStack. Also I think that the player's inventory is always known to the client so you can just get whatever is in it in the GuiOpenEvent.

Don't use the runClient/runServer gradle task. Edit your launch configurations. The ones under the "application" tab.

Show what you have done and define "does not work". Obviously don't post your password though, replace it with something(*)

GuiOpenEvent(client) PlayerContainerEvent.Open(server). Although if the inventory in question isn't synced to the client at all times you need to handle one of the TickEvents(depends on the side you want to perform the actions) and check the current opened container. If it changes start scanning for changes in it's contents(switch a boolean to true or something and if it is true scan the inventory). Once it isn't empty anymore the items have been synced and you can do whatever it is you needed to do.

Is something wrong with the existing option of the Twitch Launcher? It allows you to do exactly what you've told but not requiring to start the game beforehand.

EventHandler is for FML lifecycle events, not forge events. I suggest you to read the official docs on the events.

Click on the run configuration in the top right of the screen, select "Edit Configurations", Select your client/server configurations and put your arguments in the Program Arguments line. yes.

I am pretty sure you can fake mouse input with java's Robot. From my tests it indeed triggers the MouseInputEvent.

Yes, the only class that ever calls Block#randomTick and by default implementation Block#updateTick is WorldServer which is a server-side representation of the world. Thus the only side Block#updateTick is called on is the server(by default, excluding other mods potentially doing other stuff).

You need to specify your login and password in launch arguments. The argument keys are "username" and "password"

Your IMessage implementation must have a parameterless constructor. Also this forum has a spoiler tag. Use it.

Unfortunately not really. You can use BlockRendererDispatcher#renderBlock, but it is only good for rendering a couple of blocks at a time and it doesn't account for blocks being connected to eachother(so it would render all faces regardless, won't do connected textures, etc.) and it isn't good for performance. If you want to render a structure of some kind you would need to use a "Fake World". Basically you would create a fake World object, put your blocks into places with their TEs and then render that world as if it was a normal world. I've never worked with that though, so I only know about the general concept.

I think you have to call KeyBinding.resetKeyBindingArrayAndHash after you've changed your key code in your keybinding to recalculate the cached keyCode <-> keybinding map.

You might be calling the second method on the server and so nothing happens. The first implementation ensures that the particles are spawned on the client. However it is also the case that you might be reaching across logical sides there. Basically I think that whenever you are calling these methods the actions actually happen on a server, not on the client. However because you are running the physical client and not the server the proxy being injected is the client proxy. And in that proxy you are explicitly using the client world for spawning your particles. This way the particles work since you are spawning them through a client world and you see them because it is the physical client but what is actually happening is you are reaching for the client from a server thread - and that is called reaching across logical sides and must never be done. And the reason the second method isn't called on the client is likely because some kind of condition isn't satisfied on the client but is satisfied on the server. For example vanilla uses data parameters to sync the fuse timer of the TNT to the client so it is always aware of the fuse and is able to do client-related stuff according to it, like the flashing animation. You need to satisfy that condition on the client by using a DataParameter or packets, as I've told you twice already.

First of all this is not how you setup a repository to your minecraft mod. Your root repository directory must be your root workspace folder, the folder with the gradle batch files and such. Don't. ITileEntityProvider is legacy code. Just override Block#createTileEntity and Block#hasTileEntity. BlockBase is an antipattern. You do not need it. You do not need to set the state in Block#onBlockAdded. Just return the state you want in Block#getStateForPlacement. You do not need your TileEntity manipulations in your setState method. Just override TileEntity#shouldRefresh and return false if it is simply a change of a property. There is no need to override Block#getItemDropped, Block#getItem and Block#getRenderType in your case since you just default to a base implementation. Your Burning property isn't saved nor loaded into/from metadata. No. No no no no. Never implement IInventory ever. Use capabilities. There is no need to copy the TileEntityFurnace.getItemBurnTime method. It is static. Just call it. This is not the first time I am seeing all these issues. Are you using a tutorial of some kind? If you are could you link it so I could go complain to the author that it is a horrible one? As for the issue you've posted: Your block's material is ROCK. Blocks with this material(and a couple of other ones) will not drop anything unless broken with a propper tool. Either change the material or override Block#canHarvestBlock.