draganz

OOO, I see, typo on my part, sorry, don't do player.displayGui, do player.openGui, still do the check of !world.isRemote, though. Just make sure your guihandler has been registered via the common (both server and client). Sorry about that, slight typo.

Why don't you just do if(!world.isRemote){ playerIn.displayGui(new YourGui); } that will also work if you move your registration of the guiHandler to your common registration. You will have access to all server variable as well, no need for packets. The best answer is usually the simplest, don't make more out of this than it is.

As far as the RenderGameOverlayEvent event goes, one can find out how it is called by either opening the call heiriarchy, or by going to GuiInGameForge (net.minecraftforge.client.GuiIngameForge) class. There you will find that the event is used to render, you guessed it, the in game gui. The subclasses of RenderGameOverlayEvent are just as they sound, should your method be called before all of the rendering, or after. If not specified (you have RenderGameOverlayEvent as your parameter, rather than, for say, RenderGameOverlayEvent.Post) then it will be called during each of the rendering processes. This may be easier if you look for yourself by using the call hierarchy feature, and/or if I explain the next thing, the ElementType. The ElementType is basically the rendering type. For instance, when the player health bar is being rendered, the GuiIngameForge is called for the ElementType of HEALTH; this is then posted (forge terminology); this is when any registered methods (such as yours) might get called. However, keep in mind, that if you don't specify an element type via a boolean (i.e. if(event.getType() == ElementType.HEALTH)), then your event will be rendered for each and every time a forge event is "posted," which is unnecessary and bad. So, this can be avoided by either you using RenderGameOverlayEvent.pre (which is called once, before any of the other renderings are used) RenderGameOverlayEvent.post (which is called once, after all other renderings are done), or by having an if-statement say when to render (if(event.getType() == ElementType.HEALTH). As far as ElementType.ALL goes, however, I believe it is only used during the pre and post events. So, looking at what I posted earlier, the if-statement checking if the ElementType was ElementType.ALL, might not be necessary, as the RenderGameOverlayEvent.post inherently has the ElementType set to ALL. Thus, that if-statement where you check the ElementType, seems to only be necessary if you are using RenderGameOverlayEvent in its "raw" form, rather the pre, post, or whatever subevents. Final note, about the profiler; I believe that is used for if something should break, say for rendering, then if your profile hasn't closed (profiler.endSection()), then the issue might be from your rendering process, thus is able to print a log statement saying how your specified profile was still open, when the crashed occurred. This is more of a debug thing, that way if anyone (or yourself) is using your mod and a crash occurred, it is a lot easier to see what might have been the cause; particularly if the cause happened while your mod was rendering, but might have been cause because of someone else's mod doing shenanigans. Just a log/debug thing, its nice thing, that as minecraft itself does it, so ya.

Since you mentioned Botania, I had a look, and from what I have seen, all you need to do is something along the lines of: As a side note though (and I could be wrong here, but what-ever), I don't believe raw TESRs create any signifiant "lag" on the system, it being more along the lines of the TileEntity updating, so as long as you do your code right, and remember the distinction between server and client, then you should be okay with TESRs (though, of course, you CAN make it very laggy, but it isn't inherently so). Finally, in the retrofitted code I provided, it used RenderGameOverlayEvent.Post, you might o use what you initially suggested, the RenderGameOverlayEvent; depends on what end result you want, in a when/where it is drawn on the screen, per render pass.

[queue the sarcastic voice] O yes, I know just what you are thinking, how couldn't I? You give no information, and expect and answer, we need more info. Some common issues: does you mod show up in the dev environment? have you made sure your gradle build script is correct? do all ids match up (this more in regards toward the gradle script)?

Place the block, if the block does have an associated tile entity, then use the world to get the tile entity, then use a setter method in the tile entity to set the value. So get rid of the create and setTileEntity calls you have, just get the tile entity from the world and set the specific value; this can be done all in one call (no intermediate reference objects).

This is a duplicate post recent post that is still valid (and at the time I was reading this post, was 3 threads down) [cough cough, try looking for your answer before posting, cough cough]. Look at Draco18s's post

Mmm, mind you I have never done any redstone before, but from ten minutes of looking at Minecraft code, you just (and others please correct me if I am wrong) need to create a propertyEnum, set all of the property states and meta, have canProvidePower set to return true, then (look at how Minecraft discriminates between what "strong" and "weak" is, I choose weak, cause that might be more of what you want, if you want to have behavior like a comparator, set you getStrongPower to your weak power) have getWeakPower return an int value (between and inclusive between 0 and 15) based on the property state. For you case, specifically, you should probably also want to override onNeighborChanged so to detect when power is being provided. Beyond that, everything is self-explanatory, just look at how Minecraft does it, tends to be the best way.

you need to return ItemStack.EMPTY rather than null. Parameterizing a null still gives a null variable, and looking at the ForgeHooks class (and the Shaped Recipe class, but this is more irrelevant), the passed in ItemStack from the getContainerItem method calls !stack.isEmpty(), which if the passed in stack is null, can't be done.

One thing, is that you are registering your event twice, remove the deprecated FMLCommonHandler bus register

Interesting grammar choice, but scroll through the gui folder in the Minecraft source code, all the GUIs are there, just take in to consideration of how they might be named, then look into their functionality (I find the buttons the most helpful) and decide if that truly is the GUI you are looking for. If I have this correct, the GuiOverlayDebug and GuiIngameMenu are the specific classes you are looking for.

1.8.9 is no longer supported, and help shall not be given on this forum.

There's... a lot wrong with this. (1) the constructor for isBlockLoaded requires a BlockPos, not a Block; (2) Are you using Minecraft's Block class, cause I don't thing there has ever been a constructer that defines the usage of three double's in it; so ya, of course it is undefined. (3) Even if Block did have that constructor (it doesn't) and onBlockLoaded had those parameters (it doesn't), then it still would not work, cause you are declaring a new instance of a block; that block will never be equal to any other block instance; that is why you only define an instance once. Gist of this, read the parameters of the method you are trying to use; not hard. But, in the case that you for some reason decided to past all of that toward this thread for the simple mistake of a typo of Block instead of BlockPos; then just use getPos(), it will work, and is already predefined by the tile entity.

Then use a boolean

The source file is the source file. That means that one could use it to see what your code means; ever used a .jar decompiler, things are obfuscated. The first file (not labeled) is used as the .jar you are looking for, the other is the source file, for if you have (this is an example) a library you want others to be able to reasonably use.