coolAlias

That's a pretty cool effect! Very stereotypical, but that's why it's awesome.

That's the wrong way to do it. First of all, that looks like you used a static class member - no no no no. NO. Please Google 'Java static class member' and read about what it means. You need to pass the slot index value you already have in your IGuiHandler to your Container's constructor when you instantiate it. Do you know what that means in terms of code? It means this: return new ContainerCelestialKeypouch(player, player.inventory, new InventoryKeyPouch(stack), x); Then in your Container class: private final slotIndex; public ContainerCelestialKeypouch(EntityPlayer player, IInventory inv, InventoryKeyPouch itemInv, int slotIndex) { this.slotIndex = slotIndex; // rest of constructor code }

Yep, that's the right place to look, and yes, you could pass in 'x' to your Container constructor so it knows which slot to lock down.

Then I would store that information as additional data attached to those players, i.e. each player stores information about the Item(s) they can create. Use IExtendedEntityProperties (pre 1.8.9) or the Capabilities system (1.8.9+). Or is the registry global for all players? In any case, world start up isn't the place I would choose to do this - unless you really need access to the World object for some reason (e.g. time of day), I would do it during the FML init or postInit phase, after all my items were registered.

Only other issue that sticks out is you didn't choose between the 2 different transferStackInSlot options - you can't use both. In other words, use ONLY ONE of those two if statements, keeping the 'else if' after whichever one you choose.

What do you mean? You've already sent the packet, that's why you are in the message handler code. And it looks like you got my advice backwards somehow... I wasn't recommending you remove the check on the Item contained in the ItemStack, but removing the unuseful check if i is equal to the currentItem. I mean, if i == currentItem, you're still sending 'i' because they are equal, right? So that's a pointless check that makes your code more complicated looking than it should: @Override public IMessage handleServerMessage(EntityPlayer player, OpenGuiPacketAlt message, MessageContext ctx) { for (int i = 0; i < player.inventory.getSizeInventory(); i++) { ItemStack stack = player.inventory.getStackInSlot(i); if (stack != null && stack.getItem() == YourMod.backpackItem) { player.openGui(MainRegistry.modInstance, message.id, player.worldObj, i, 0, 0); break; } } return null; }

That could very well have something to do with it, yeah

And where will this Item be located? Are you giving it to the player when they join? Use PlayerLoggedInEvent. Are you placing it in a chest somewhere? Use the ChestGenHooks or loot tables or whatever that has become to add it to random loot or use one of the world gen events to place it yourself. Or are you doing something else entirely? I don't see what the problem is that you're trying to solve.

Checking if the world is remote (which would mean it's the CLIENT world, btw), is not really a goal, it is a means to something else. So, what exactly are you trying to do? If you want to add data to the world, use WorldSavedData. If you want to add structures or something like that, look into IWorldGenerator (if that's still a thing) or the various generation events such as PopulateChunkEvent.Post.

He gave you pseudo-code, not copy/paste ready code. By 'onTick' he meant that you should create an event handler for ClientTickEvent, which is the one I was trying to tell you about earlier but I was thinking it was tied to the PlayerEvents, which it's not (sucks not having an IDE handy...). So: @SubscribeEvent public void onTick(ClientTickEvent event) { // rest of code here }

Personally, I would prefer to compare the event key to keys[bACKPACK_KEY].keyCode rather than your keyValues array - that is only for the default key binding value i.e. before the player has a chance to change it in their settings. Basically, once the game starts, you have no idea what the actual key value of the keybinding will be, so you need to use the KeyBinding instance you created. Anyway, the problem would seem to be in your packet, since when you open your GUI without sending a packet it works fine, and as long as your packet is actually being sent and your network code is all correct, that is the only place left that could be broken. Do the System.outs in your packet's #handleServerMessage method ever print to the console? It looks like it should print out 36 messages, since you never break out of your for loop. Might want to do that, as I doubt you want to open the GUI 36 times.

Are you sure your flight is not getting disabled? Try also setting player.capabalitites.isFlying to false - that will drop you out of the sky if you are currently flying. Also, KeyInputEvent fires for every key that is pressed OR released; Keyboard#getEventKey() will give you the key code of the key that triggered the event, and Keyboard#getEventKeyState() will tell you if the key was pressed (true) or released (false). So: if (!Keyboard#getEventKeyState()) { return; // don't care about key being released (you might, but it seems like you won't need to) } if (Keyboard#getEventKey() == ExtendedCrafting.keybinding.getKeyCode()) { // your key binding was pressed In this case, you're probably better off using one of the player tick events to check, rather than KeyInputEvent, and you probably want to send a packet to the server and let it decide if the player can fly or not. If you do go with a tick event, you generally want to use #getKeyIsPressed() (or #isKeyDown(), whatever it's called now), not #isPressed(). Java tip: boolean values do not need an ' == true' or ' == false' comparison, as they are already either only true or false: if (onToggle && !notToggled) { // is the same as but syntactically better than: if (onToggle == true && notToggled == false) {

Yeah, that could work so long as you validate everything server side, otherwise any old hacker could send that packet from their client to spawn in a doppelganger of themselves. Note that you can't store the ResourceLocation server side, only the String (at least I'm pretty sure it's an @SideOnly(Side.CLIENT) class, but no IDE right now). When you handle the additional spawn data packet on the client, however, you can create the ResourceLocation from the String no problem.

Since it only occurs when you use a key press and not when using onItemRightClick, you can rule out your GUI and Container classes as the culprit. Show your key handler code - are you by chance opening the gui from there before or after sending the packet? Are you sending your packet? Speaking of your packet... your if statements are really weird, specifically '... && i != player.inventory.currentItem)' and then the next one that checks the opposite. First of all, why even check that? Does it matter if it is the held item or not? Just send the slot index to your IGuiHandler and it won't care in the slightest if it's the currentItem slot or not. Second, and irrelevant (for your specific case) after you follow the above advice, but the way your if statements are written, you are checking 2 if statements every iteration through the loop. That is poor coding style. You generally want to do as few operations as possible, so always ask yourself "which is more likely?" Is 'i' more likely to be equal to currentItem, or not? Check the most likely condition first, and use an 'else if' for the following conditions: if (i != currentItem) { // this will happen 35 out of 36 times, and always if the item is not in the hot bar } else if (i == currentItem) { // will only happen if the item is in the hotbar and i < 9 } Furthermore, those 2 conditions are exact opposites, so you don't need 'else if', just 'else'. Long story short, you need to take some time to go over Java basics so you can write better code. I recommend Oracle's tutorials - if you follow all of them diligently, you will have increased your Java skills 10 to 100-fold.

Your previous code was this: ItemStack stack = player.inventory.getStackInSlot(x); if (stack != null) { return element with new inventory(stack) } Well, all you know is that the stack is not null - what if it's a stack of chicken meat? Or dirt? It could be anything, but your inventory constructor is expecting a specific class of Items, specifically YourBackpackItem, and if it gets anything else, you are probably going to crash.

Don't have access to the code right now, but you may want to take a look at the other methods in the BlockLadder class, specifically the two #onEntityCollidedWithBlock methods. I believe that is where motionY is added the climbing entity, but if not, then you can use your IDE's search function to find the locations of BlockLadder and Blocks.ladder (or whatever it is called) in the code and inspect those to find out how ladders function.

Do you have any mods installed, and are you using any modded blocks in your structure? The trouble with modded blocks is that they do not have set IDs - the integer IDs can and will be different between different worlds, so they are no longer a valid storage format without some sort of converter (e.g. a file storing the map of block IDs to block registry names used to create the structure).

Yep, all you need to send is the ResourceLocation string, which you then send to the client side version of your entity / renderer (client side being all tracking players' instances of your entity / entity renderer) so they can fetch the correct image. You'll also want to store the ResourceLocation string in your Entity and make sure to save it to NBT when the world saves so you can still have it when the player is no longer around, unless that's not how your entity is supposed to work.

No, but since you're passing '0', chances are you are getting a non-null but incorrect ItemStack in that slot in your IGuiHandler, so you either need to pass player.inventory.currentItem OR actually do a real check in your IGuiHandler (which would be safer anyway) - note that you can and should do both. // in IGuiHandler ItemStack stack = player.inventory.getStackInSlot(x); if (stack != null && stack.getItem() instanceof YourBackPackItem) { // okay to return GUI or Container element } else { // do nothing - invalid item }

It happens when a non-player causes blocks to drop, such as water flowing over crops or a creeper exploding (maybe the creeper counts as a harvester? it's been months since I've looked at the code).

Show your Item code.

The typical way to go about it is to check if the player can see the sky or not. The problem with that is how do you differentiate being under a tree or in a house vs. in a cave? So you have to decide how would you even define a 'cave'? Should it be mostly stone blocks? What about dirt? Sandstone? Mineshafts? Once you decide that, you can get fancier and check surrounding blocks, but that will slow your algorithm down exponentially with the search radius. To make it faster, you could only check the first non-air block above the player and see if it's in your whitelist of acceptable 'cave' blocks, but then you still get false positives if a player makes a house of stone, for example. Anyway, there isn't any surefire way that I know of to say with 100% certainty a player is in a cave, so you have to figure out what is an acceptable level of error for your purposes.

The shift-click ghost issue is one I have noticed occurs when you limit the stack size of your inventory slot to 1 - is this perhaps the case with your inventory? If so, the issue isn't your code, it's Mojang's, but you can fix it by overriding #mergeItemStack in your Container class and using the code found in that link. That implementation I wrote myself almost 2 years ago now, but I've seen others do it slightly differently since then that you may want to look at also, or if you want a challenge you can avoid looking at my or anyone else's code and see if you can't figure out what's wrong with Mojang's implementation on your own

If you read the docs for HarvestDropsEvent, you'll see that it specifically states that 'event.harvester' can be NULL, so you need to check for that.

Within a given loot table, there is not any way of which I am aware to affect what is chosen - thus the use of different loot tables when fishing. It might be possible, however, to change the weights of the items in the table before selecting an item, but unless you made a copy of the table to do so (possibly slow) or make sure to change it back (possibly affects other loot using the same table or even potentially risks ConcurrentModificationException), then it's probably not advisable.