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.

why don't you just load values from the config file. Assuming you have a "common" config file (present on both server and client), then the values can be loaded from the file. Just have the file contain (say item unlocalized names) and corresponding integer values for the burn time. Then get the item from the name (Item class has a static method, I believe it is for the unlocalized name) and then save the item and value to your map.

What even are you doing?!? Based solely on what you are doing, you should be doing something along the lines of: GameRegistry.registerFuelHandler(s -> { if(s.getItem() == Items.APPLE){ return 200; }else{ return 0; } }); /////////or///////////// IFuelHandler fuelHandler = s -> { if(s.getItem() == Items.ARROW){ return 100; } }; GameRegistry.registerFuelHandler(fuelHandler); ////////or as jeffryfisher suggested (you could also do a .contains if statement then get a value if true, but what have you)////// final Map<Item, Integer> fuelMap = new HashMap(); fuelMap.put(Items.APPLE, 200); GameRegistry.registerFuelHandler(s -> { final Integer i = fuelMap.get(s.getItem()); if(i != null){ return i; }else{ return 0; } }); Any of these ways should work. But, you seem to just be bull-crapping you way through this. Learn the language first, then try to solve the problem at hand.

You want to know what I did to find this answer, spend a minute looking at the minecraft source code, tends to have most of the answers... Just do something along the lines of : mc.getTextureManager().bindTexture(yourTexture); //This is a VERY standard way of getting the center of the screen, like you cant miss this, if you google it, it will be the first result, I'm sure; its common code. final int x = (width - x_length_of_texture_you_want_to_draw) / 2; final int y = (height - y_length_of_texture_you_want_to_draw) / 2; /* As a note, the width and height variables are provided via the gui which are the screens width and height (they respond to screen rescaling), you can also use xSize and ySize to get 176 and 166 (respectivly), those being the values for Minecraft's default gui sizes. Also, I make the ints x and y final, this isn't neccessary, just preference; stick to your own code style. */ drawTexturedModelRect(x, y, 0, 0, x_length_of_texture_you_want_to_draw, y_length_of_texture_you_want_to_draw); // this method is also provided via the Gui class, look at it, if you want to understand the parameters

you need to us mc.displayGuiScreen(yourGui) to display the GUI, because this method handles for null variables, aswell as handing the closing of previously opened gui. When you did the mc.thePlayer.openGui you did just that, open a GUI, on top of another GUI that wasn't closed. The displayGuiScreen method handles for that. Look at the class I said, and then at the method I said, if you want to know how.

Look at minecraft's GuiInGameMenu class. Your not handling your gui correctly.

could we see the ProjectPlasma.proxy.registerItemRenderer. Cause I don't see you calling any method along the lines (or event, if you want to go that route) on the client side... ModelLoader.setCustModelResourceLocation(Item.getItemFromBlock(yourBlockInstance), 0, new ModelResourceLocation(yourBlockInstance.getRegistryName().toString()));

Here's another idea that you could use, if this is that important to you: (1) you get a list of all of your items. This could be done via the Item.REGESTRY method I provided in my above example, or you just making your own static list, then having your items register themselves to said list upon initialization. (2) have an enum, with specific sorting types (see provided example). (3) Have your item classes return a specific (or a default) enum type. (4) upon the creative gui sorting through all of your stuff to display via the desplayAllRelevantItem method, you have your items to display sort based on the enum ordinal. Example below (my not be functional, but should give the general idea): //////////in your creative tab instance/////////// @Override public void displayAllRelevantItem(NonNullList<ItemStack> itemsToDisplay){ ModItemes.YOUR_ITEMS.stream().filter(yourPredicate()).forEach(i -> i.getSubItems(i, this, itemsToDisplay)); } private Predicate<Item> yourPredicate(){ return i -> i != null && i.getCreativeTab() == this; } /////////////Your Item Registry Location/////////// public class ModItems{ //NOTE:For this class, in your mods preinitialization stage, you should call the init() method public static final List<ItemBase> YOUR_ITEMS = new ArrayList(); /*Register your static final Items here. Since they are static, they to will have the ability to say use ModItems.YOUR_ITEMS.add(this) in their constructers in order to self initializes themselves to the list, order you state them desiding in what order*/ public static void init(){ YOUR_ITEMS.sort( (ItemBase i, ItemBase j) -> i.getSortOrder() - j.getSortOrder() ); } } /////////ItemBase class, is used as a starting point for all your items//////////// public abstract class ItemBase extends Item{ private final SortEnum SORT_ORDER;//have this initialized in a constructer ///....various code you would otherwise put here public int getSortOrder(){ return SORT_ORDER.ordinal; } } /////the enum public enum SortEnum{ APPLE,ORANGES,PLUMS;/*it doesn't matter what values these are, just the integer (ordinal) value they provide. Depending of if you have (itemOne - itemTwo) or (itemTwo - itemOne) will alter the order that these are sorted by. Beyond that, it will be the order of initialization, then should meta types come into play, they the getSubItems method will determine.*/ }

whipped this up on the fly, have no idea if this will work, and I don't like the way it works (the getting class part), but try it out anyways: //put this into your creativetab instance @Override public void displayAllRelevantItem(NonNullList<ItemStack> itemsToDisplay){ List<Item> l = StreamSupport.stream(Item.REGISTRY.spliterator(), false).filter(yourPredicate()) .collect(Collectors.<Item>toList()); l.sort( (Item i, Item j) -> i.getClass().getSuperclass().getName().compareTo(j.getClass().getSuperclass().getName() )); l.forEach( i -> i.getSubItems(i, this, itemsToDisplay)); } private Predicate<Item> yourPredicate(){ return i -> i != null && i.getCreativeTab() == this; } Even if this does work, I don't think I will cause of the .getClass.getSuperclass.getName() part, you still should try to avoid using it; the getting class name parts is usually a very bad idea. You could try making your own comparitor, and try to work something out from there. Not sure it this helps, but better than nothing, and hopefully it sparks your imagination towards a very creative means to an end. Good luck.

not sure about vanilla, but you could use .obj files, those are very easy to scale

You could manually just add the class to API, or you could have the SomeClass implement an interface, then change the argument to the interface and only add the said interface into the API; this being the more typical means that APIs are done. so like [old]: You would have to have to add the Apple class to the API, public void fall(Apple a){ a.fall(); a.update();//I don't know, just making code up } public class Apple{ //what ever code } but instead, you should do this [new]: public void fall(IApple a){ a.fall(); a.update(); } public interface IApple{ void fall(); void update(); } This way you only add the simple interface into the API package, and it is up to the user to use. I would like to mention though, that you could also use and abstract class instead of an interface, if you wish to provide some bulk of data ahead of time, and leave it up to the user to implement (extend really).