V0idWa1k3r

Have a capability that contains an ItemStackHandler handling the contents of your custom slot Have a Gui/Container pair open on a press of a button/keybinding/however you want it to be In the Container of that pair access your capability and create a SlotItemHandler that references your ItemStackHandler. That's pretty much it. See baubles for an example of custom slots.

By the time the AttachCapabilitiesEvent is fired the player's inventory has not yet constructed(as didn't many other things like the UUID, game profile and many others). You must construct your slot later. Anyway, why are you constructing a Slot in your capability? Slots are constructed in the Containers, not in the capability.

I mean you could read minecraft's EULA. It doesn't really specify what counts as "containing enough code" and stuff but it is pretty clear. I would say "don't be a jerk". Don't redistribute straight up sources of the game or source code that is masked as a mod. As long as you are not trying to redistribute mojang's intellectual property you are clear. Redistributing similar code to the code that you've locally decompiled is fine. I am no expert in this though, I can only judge from what I've seen so far. And so far this is the idea that I have. Mojang still owns the right to take down your mod if they find it illegal but in most cases they do not even with mods that massively copy the decompiled code.

This is minecraft modding, You are using the methods provided by mojang(kinda). Sometimes there is only one way to do something. So what, if MC does it in the same way can you not use it anymore? Does your code have to be completely different from that of the base game? Well, both yes and no. You can't just blatanly copy the game's code and call it good. But at the same time it's okay to use a similar code that does the same thing. Even better yet - what if you need to replicate the behaviour of the base game? And you need an accurate replica, not just something close to that. In those cases you have to replicate the source code too, there really isn't a way around that(well you could write your own code but it will end up looking similar if not exactly the same in most cases). So is this legal or not? I would say it is fine as long as you are not "replicating" all of the game in that manner effectively redistributing the game's sources. the ItemBow#findAmmo method belongs to the second case. It is not the only way to do this but it is a decent way.

Are you redistributing minecraft source code? If not then you are clear. That said you shouldn't be blindly copying vanilla just because it works. Actually go through the process of understanding what is that this code does and how it could be improved. Because usually it can. A lot of modmakers blindly copy mojang's code without considering that it does a lot of things that are inefficient, outdated or even deprecated in some cases.

You need to check the value in your gui(hint: on the client) hence my suggestion of using the debugger. It's a powerful tool. Learn how to use it. Apart from redundant code I do not see anything wrong with this update method and your output confirms that it is counting in a range of [0-24]. Check the values in your gui, something is wrong there.

The game simply creates a NonNullList<ItemStack>, then calls this method for each item in the registry with that list as the second parameter and current creative tab as the first. Anything that ended up in the list is displayed in the creative tab. See GuiContainerCreative if you want to study this process in greater detail. This also answers your question of how to use this method. Just override it and you will be good to go.

If it crashes then you must provide a crashreport. Simply saying "it crashes" is not helpful. However you might be mistaking the debugger suspending the main thread for crashing. I don't know which is true since you have not described anything nor provided a crash report.

It's a void method. It doesn't return anything. The list you can add ItemStacks to is passed to you as the second argument, the first one being the creative tab that invoked the method in the first place. I think you misunderstand what subtypes are. A subtype for an ItemStack is any itemstack that has the same Item but differs in something else like NBT or metadata(hence the name, it's a sub type of the Item). You do not need to "define them in class code" whatever that even means. Just populate the list passed to you as an argyment with whatever items you want added to the creative tab. For example here is me populating the creative tab with 16 versions of my items, each having a different color stored in it's capability.

https://www.jetbrains.com/help/idea/debugging-code.html

This is impossible. You have to handle the cases where there isn't an NBTTagCompound attached to the item at all. The best way is to stop using NBT alltogether and use capabilities since a capability will always be attached to an ItemStack regardless of how the stack was created. Use Item#getSubItems, create a new ItemStack, assign the NBT needed to it and add it to the list.

An alternative way to render a second "durability bar" is to handle the GuiScreenEvent.DrawScreenEvent, iterate all slots in the GUI, take the item in that slot and render the durability bar manually like I do here. Be aware that there are z-level issues with this approach since you are either drawing before the item was drown and the item will be overlayed over your durability bar or after everything else was drawn and as such you will be drawing over the tooltip.

This check is useless. Any number * 0 = 0. Use the debugger. This number gets really big. Find out why.

Depends on what behaviour do you need. If you only need the energy to be visible in the GUI use the vanilla container listener system: Have a local field storing the last energy value in the container. In Container#detectAndSendChanges compare the local value to the actual energy value. If they differ send the actual value to all listeners using IContainerListener#sendWindowProperty. You can use the second argument to differentiate between different data you need to send to the clients. In Container#updateProgressBar(client-side only!) you will get the data alongside with the ID you've assigned to it. Compare the IDs and if it maches set the tile's energy to data you got. Send the initial data values to new listeners in Container#addListener using the same IContainerListener#sendWindowProperty This method ensures that every player who has the container opened will see the correct values. You can see an example of me using this to sync the energy in my container here. However if you need more than that(for example your rendering depends on the amount of energy you have) the container isn't the best solution since it will only work while the player has the container opened. In this case you will have to use packets.

Define How do you know it's not there? Did you place a breakpoint in your update method and made sure you are on the server side? Or if you are on the client are you sure you are properly syncing the energy to the client?

This is pretty much the only option. Monster eggs exist as one single item with various NBT data that determines the mob spawned. As such it has one creative tab - the misc tab. As it is a singleton you can't change the creative tab of a specific monster egg without changing the creative tab of them all. A hacky partial workaround is to override CreativeTabs#displayAllRelevantItems in your CreativeTab and manually add the spawn eggs you need to the tab items list. However this will require you to manually construct the correct NBT data of the egg and it won't remove the eggs from the misc creative tab.

As long as you expose the energy capability in your tile the pipes/conduits will be able to push FE into your tile by themsemves and you won't need to manually drain anything. It is not always possible - some mods might not even have their wires have a TileEntity/expose the energy capability but instead treat pipes/conduits as valid "paths" for the energy produced by generators to traverse(aka a simple pathing algorythm). This way a pipe/conduit is but a connector that doesn't have any properties on it's own and it's the power providers that do all the work. As an example here is my TileEntity that has an internal energy storage and can use that energy for specific operations. Note that the only thing it does is expose the energy capability. It doesn't drain any ajacent energy storages or anything. And as far as I am aware it works perfectly fine with TE and EIO and many other mods. TL;DR: You don't need to drain from pipes/conduits as they tend to eject energy by themselves as long as you expose the FE capability. It might be the case that the energy bank returns false at IEnergyStorage#canExtract if it is not configured to push to that side.

Well every block has one. The queston is - did you set it up correctly as in did you pass your properties to the container created in your overridden Block#createBlockState. Your blockstate file says that your block has a facing variant with 4 possible values. Is the same true for your BlockStateContainer? As I've said it will be at your %mdkDir%/run/logs/debug.log. I can only randomly guess in the dark at the error you've posted which may even not be the correct error without the full log. I need to see the full error message, not just one of the two model loaders erroring.

I would need a full debug log to tell more(sometimes one model loader will just report a generic error and the other one will actually tell something usefull) but this says that the game is looking for a normal(generic, no properties) variant. Is your BlockStateCotainer setup correctly?

Blockstates can't have parents. That aside this is not a blockstate file. It is a model file. Blockstates have a completely different format. Read the docs. %mdkDir%/run/logs/debug.log(this may be different if you are using eclipse though so you might have to search for it yourself)

Show your blockstates file(and a full debug.log). You could also read the official docs that explain how to make blockstate <-> model pair for your blocks/items...

This can and will return null if a block at a given position doesn't have a tile entity. So You can't just do that a few lines later without checking for null first.

Your TileEntity never returns an IItemHandler in it's getCapability method, although it claims to have one in it's hasCapability method. That causes the slot to initialize with a null capability and crash as a result.

You are most likely messing up some GL state. For example... ... This is not how GL scaling works. Scaling by 1,1,1 is doing nothing. Think of it as currentScale * passedVector. If you scale by 1 then you are doing currentScale * 1 which is currentScale. In order to scale back use 1 / scaleUsed, in your case this would be 1 / 4 = 0.25. The rendering layer doesn't matter. It is all done in one method, but the background is rendered first. Experiment with enable/disable lighting and OpenGlHelper.setLightmapTextureCoords Experiment with depthtest(GlStateManager.enable/disableDepth). I can't remember of the top of my head whether MC uses depth testing for rendering items or not.

RenderHelper.disableStandardItemLighting(); RenderHelper.enableGUIStandardItemLighting(); .... Your rendering code .... RenderHelper.enableStandardItemLighting();