V0idWa1k3r

Why are you using ByteBuf#getIntLE/writeIntLE? Why not writeInt/readInt? Why are you using ByteBuf#getX in the first place? You should be using ByteBuf#readX. The fact that this this.index = buf.getIntLE(this.index); even works is a miracle that only happens because index is 0 by default. FMLCommonHandler.instance().getWorldThread(ctx.netHandler) => ctx.getServerHandler().player.getServerWorld() Don't use FML internals when it's not necessary. I also have no idea what this MobileSuit ms = MSRegistry.getMobileSuitFromIndex(message.index); returns. I assume you've used the debugger and made sure this isn't the cause of your problem? mob.posX = message.pos.x+1.0; mob.posY = message.pos.y+1.0; mob.posZ = message.pos.z+1.0; => Entity#setLocationAndAngles. Or at the very least Entity#setPosition. How and where are you constructing/sending your packet? Are your fields set to the correct values? Also make sure that your packet is registered correctly. Step through your handle method in the debugger and see the values on the fields in your message. Something might be wrong there. Also make sure that the handle method is called in the first place. I don't even... What? What does your IDE have to do with this?

As I've said please stop using reflection here. It's not the use-case for reflection. Use a factory. Reflection wastes a lot of CPU cycles doing lookups for things. Modded minecraft is laggy as is, don't add more lag to it when you can avoid it. Packets are handled on a separate network thread. You must encapsulate whathever you are doing in a runnable and use IThreadListener#addScheduledTask. On the server your listener is the WorldServer instance. On the client it's Minecraft. Also don't blindly trust the client. Always assume that the client lies and perform additional checks in your handler. With your current code anyone could spam the server with artficial spawn packets and spawn thousands upon thousands of your entities whereever they want them to be. Also that is not the descriptor for IMessageHandler#onMessage. If you are calling this from your packet handler please post the whole code so it is easier to spot what's wrong.

This explanation doesn't even mean anything. How is it special? What does internally mean in this context? This is not within your API package so there is zero reason to use reflection. I've looked at your github and I still fail to see a reason to use reflection. If you want to create something dynamic that may or may not be overriden by something else use a factory, not reflection.

You can't spawn an entity on the client. You must do that on a server. Use packets to communicate the button press to a server. On a completely unrelated note: What on earth is this: Do you know how to instantinate things in java? Why are you using reflection? Also this is the worst way to handle exceptions. If something went wrong don't just print it and carry on. Minecraft crashes for a reason and so should you.

The event is client-side. You have access to the client's player. You have access to the player's open container. That has access to the slots.

This would be the preferred solution. a) Don't search it every tick but instead say every 10 ticks. b) Realise that the size of the vanilla player's inventory is only 44 slots and that will take virtually no time to iterate through and stop worrying. That said you might try to do something interesting with the MouseEvent. I wonder if Detecting the slot under the cursor Checking whether that slot can accept your item with your custom checks Cancelling the event if not will work. I suspect it will but I can't test it right now.

I guess it is possible by handling the PlayerContainerEvent.Open and then adding your custom slot to that container's slot list(Container#addSlotToContainer although you wouldn't be able to access that method directly since it is protected so you would need to either use reflection or replicate the functionality of that method). However all sorts of hell can and will break loose as soon as Container#transferStackInSlot is called. I couldn't even begin to imagine what would happen if the container attempted to handle the slot that it didn't know existed(read: wasn't programmed to handle). Probably the duping glitches would be the least of your worries. The containers are just not built to have slots added to them post-construction. Another alternative would be replacing the container with a different one alltogether... and creating a hard incompatibility with everything else that does the same. Having a separate Gui/Container pair is the most sane solution.

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.