coolAlias

If the mod is not installed server side, then I'm pretty sure you cannot get chat messages other than the ones you yourself send or receive. Also, I'm not sure if all chat messages are guaranteed to be routed through the server, either, for example any sent by mods directly on a client's machine, but I don't think you'd be interested in those anyway, right?

You can't make a mod until you have a solid understanding of Java. You already have your answer (see above quotes) - what more do you want? If you already know Java fairly well, then diesieben's answer is pretty much all you need; if you don't know Java, then as Choonster pointed out you need to learn it.

Minecraft.getMinecraft().gameSettings.keyBindJump.getIsKeyPressed(), or something like that.

super(null, par1ModelBase, parShadowSize); NEVER pass null in a constructor or method expecting a valid value. It never works out the way you expect... um, wait, what DID you expect? Of course it crashes. Please look at the examples in the posts I linked. Did you make an IRenderFactory? Why isn't that passing the RenderManager instance to your Render class constructor? Why doesn't your Render class constructor have a RenderManager parameter? You know, like: public RenderGenericLiving(RenderManager renderManager, ModelBase model, float shadowSize) { Btw, that's a 1.8 example - 1.8.9+ introduces generics, so your constructor call may be different, and certainly your class declaration needs to include the type specifier, e.g. extends RenderLiving<YourEntityClass>

You're not using the metadata at all right now: currentBlock.getDefaultState() That will only ever give you the default state, which isn't what you want. Assuming you have access to the metadata value of the block, you should use: currentBlock.getStateFromMeta(meta)

Then I'm afraid I can't personally give you an example, as I don't have access to a computer with an IDE / 1.8.9 source code. But, if you search for IRenderFactory, I'm sure you will be able to find something (such as this or this).

Well, the example would be different depending on which version of Minecraft you are using, so as I asked, which is it?

What version of Minecraft are you using? In 1.8, at least, you need an instance of RenderManager to pass to the super constructor. 1.8.9 this has all been changed so you would create a render factory to instantiate your render class, and you need an instance of that factory when registering your renderer.

Well, without registering a renderer, your entity won't render correctly. You need to register renderers via the ClientProxy, though - your CommonProxy#registerRenders method should do nothing at all.

You might be having issues because you created your own Boolean values for each of the directions, when those already exist as EnumFacing. Delete these lines: public static final PropertyBool NORTH = PropertyBool.create("north"); public static final PropertyBool EAST = PropertyBool.create("east"); public static final PropertyBool SOUTH = PropertyBool.create("south"); public static final PropertyBool UP = PropertyBool.create("up"); public static final PropertyBool WEST = PropertyBool.create("west"); And change any references to them to use EnumFacing.WHATEVER_DIRECTION instead.

EntityRegistry.registerModEntity is ALL you need as far as registering the entity itself; as of 1.8, you can even tack on 2 additional integer parameters for the spawn egg and have one made for you. Get rid of the global entity ID and everything related to it - just start at 0 and increment for your entity IDs, as they are unique to your mod. Where are you registering your entity renderer?

If the field is set once during entity creating, use IEntityAdditionalSpawnData to tack the initial value to the entity's spawn packet (which is sent to the cilent). If the field is going to change after the entity has spawned and needs to be kept in sync, use DataWatcher in your Entity class. Also, you should rename your variables to something meaningful instead of 'field_145791_d'.

You don't need a World object to generate/register baked models - that should be done through your ClientProxy during FML's pre-init phase after registering your items. And if for whatever reason you DO need the World object for your baked model (which you shouldn't), since you are doing this in your ClientProxy you can use Minecraft.getMinecraft().theWorld, BUT, I don't recommend that as it might very well be in an invalid state at that point (e.g. not existing yet). You can always access it from within your baked model class at the time of rendering.

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) {

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.