coolAlias

On the server side, use World#playSoundEffect(x, y, z, ...) - the server will broadcast the sound to all nearby clients (i.e. players). If you want to play the sound for ALL players, regardless of where they are, then yes, you'll want to iterate through the list of players and play the sound for them, but on the client (unless you want a cacophony of sound when players are near each other).

Looks to me like line 17 is: ItemStack stack = player.getCurrentArmor(1); Only thing that could be null there is 'player', possibly because the tick event might fire before the client player has fully constructed? Try adding a null check for the player.

Do you not have a custom frame? If not, then you can subscribe to PlayerInteractEvent and check for RIGHT_CLICK_BLOCK + obsidian, then do the same thing I mentioned above.

If you have your own custom portal block, just override #onBlockActivated and check if the player is using the item to light the portal and the portal frame is correct, then activate your portal.

Last I checked it was 2.9, but you should be able to find out by looking at your project's referenced libraries.

You need to use #getKeyIsPressed, not #isPressed (at least in 1.8 it was that way). Also, TickEvents have both a Start and an End phase and you only want to choose one of them: // example shortcut to only handle the start phase (in pseudo-code) if (event.phase == end) { return; } rest of code;

Pretty sure EntityRegistry#registerModEntity still requires an instance of your mod, even in 1.8.9: int entity_id = 0; int tracking_range = 80; // used by most mobs and animals; most projectiles use 64 int update_frequency = 3; // used by most mobs and animals; most projectiles use 10, except arrows EntityRegistry.registerModEntity(YourEntity.class, "registry_name", entity_id++, YourMod.instance, tracking_range, update_frequency, true, egg_color_1, egg_color_2); Take a look at the vanilla EntityList class for the tracking range and update frequencies used for vanilla entities - that will help you decide what to use for each of your particular entities.

Your message is being sent to the server, so you need to register it with Side.SERVER, not Side.CLIENT. You put the movement code (and also the stack-damaging code) in the message handler's onMessage method, but I suggest you also keep your code that updates the client-side player motion - it will make the controls more responsive feeling.

Is there any sort of logic to how you choose inputs and outputs, or you just want every single registered item to be craftable in groups of 9 to make... what? Anyway, just iterate through the registered items and add recipes, e.g.: for (Item item : registered items) { GameRegistry.addRecipe(output, 'xxx','xxx','xxx', 'x', item); }

It's still perfectly doable - subscribe to PlayerTickEvent and do something like the following: public static final AttributeModifier SPEED_BONUS = new AttributeModifier(args); if (player is wearing your boots && player.isSprinting()) { player.getEntityAttribute(SharedMonsterAttributes.movementSpeed).applyModifier(SPEED_BONUS); } else { player.getEntityAttribute(SharedMonsterAttributes.movementSpeed).removeModifier(SPEED_BONUS); } You might want to throw in a check first to see if the modifier is already applied, or save a boolean flag like #isSprinting does so you don't add/remove it constantly.

Oh, so they aren't actual bees? As in they aren't Entities flying around in the world that can sting you and be killed? If that's the case, then what you want is a custom particle that you can spawn around your block via #randomDisplayTick or something like that.

Making the bees fly sporadically is NOT the same as animating. Take a look at EntityBat's navigation code - that will give you a good start at getting your bees to move in the way you want. As far as actual animation is concerned, I would recommend starting out by looking at the various types of code vanilla Minecraft uses to animate entities. That will give you a good starting point for basic animations such as walking, flapping of wings, etc. If your animation needs to be tied to a specific action, such as an attack, then take a look at the Iron Golem Entity and Model classes for one way to send information to the client.

Does your naming scheme apply across different Items? If not, it doesn't make any sense to separate the logic into its own class - that'd be like making a separate class for your #addInformation or #getColor methods

You don't need to load NBT yourself, no, and for creating a specific Item, you do just that: // make a new NBT tag compound with all the stuff you need in it NBTTagCompound tag = new NBTTagCompound(); tag.setWhateverYouNeed(...); // then add it to the drop/loot/whatever ItemStack stack = new ItemStack(yourItem); stack.setTagCompound(tag); You can do that for crafting recipes or anything you want, really. If the ItemStack already exists, you'll have to be a little more careful e.g. check for existing NBT tags first.

You do realize this is a forum where people voluntarily help at their leisure and not an instant help line, right? If you don't want the player to spawn in the ground, move them out of it, e.g. while (in ground) posY++.

Neither your IMessageHandler attempt (which doesn't even implement that interface... -.-) nor your IMessage class are properly done. As for your crash, you didn't register any messages. Will you please just follow a network tutorial from start to finish? @Draco Why does everyone think/say that? If done well, there won't be any chance at all of mixing anything up. See for example here, a message for which looks like this. As you can see, the IMessageHandler is completely generalized and reused for every message, allowing the IMessage to be totally self-contained. Makes for way nicer code, imo.

That will crash your game - the main class also runs on the server, and Minecraft + Render classes are all CLIENT-side only. You need to put that code in your ClientProxy and call proxy.preInit(), proxy.init(), etc. from your main class. Also, 1.8.9 introduced the IRenderFactory so that you can register renderers during pre-init (why that's important, I still don't know, but it is the way forward now). Here is an example which you could have found by reading the links I posted earlier.

You won't be sending a vanilla packet, so you'll need to setup your own SimpleNetworkWrapper instance and create both an IMessage and an IMessageHandler for each specific type of action / data you want to send. Keep in mind that a 'packet' is simply bits of data that is sent from one side to the other, allowing the different sides (client and server) to communicate with each other. Sometimes, a single bit is enough data, other times you need to send lots. In your case, you could get by with a packet that doesn't send any data at all other than the packet ID (which is written and read automatically), e.g. PacketToggleJumpKey, whenever it is received server.jumpKeyState = !server.jumpKeyState, but you'd probably want to send the actual state (true or false).

The best way is to use AttributeModifiers, not modifying the player walk speed. Item#getItemAttributeModifiers can return a multimap containing any number of attribute modifiers that will be applied automatically when the item is equipped or held, and then removed when the opposite is true. If you don't want the modifier to apply when the item is held, you have to do a lot of extra work: set up IExtendedEntityProperties to store the last equipped item in the boots armor slot and check each tick via PlayerTick whether the item has changed. Each time it changes, remove all modifiers for the previous item and apply any for the new item, if any, then store the new item.

Caused by: java.lang.NoClassDefFoundError: net/minecraft/client/Minecraft at com.koopamillion.Main.ServerProxy.keyBindJump(ServerProxy.java:36) ~[serverProxy.class:?] Same error as before, basically: don't use Minecraft class on the server! Your ServerProxy CANNOT access client-side only classes. If you want to handle things on the server, you need to send a packet when the key is pressed and do whatever you need to do while handling that packet.

It's okay, but it could be written better by following Java naming conventions (e.g. camelCase variable names). Also, the last boolean parameter of #onUpdate is a flag telling you whether the item is held or not, so you could use that, and the slot index is given to you as well: @Override public void onUpdate(ItemStack stack, World world, Entity entity, int slot, boolean isHeld) It's amazing how much having properly named variables helps understand the code. @Override public void onUpdate(ItemStack stack, World world, Entity entity, int slot, boolean isHeld) { if (isHeld && entity instanceof EntityPlayer && stack.getItemDamage() >= 255) { ((EntityPlayer) entity).inventory.setInventorySlotContents(slot, new ItemStack(yourItemHere)); } }

Keyboard is CLIENT side only; #addInformation is also CLIENT side only, so it works. Almost all of the other Item methods, however, are called on both client AND server, and when they are processing on the server side, the Keyboard does not exist and thus your error. You cannot use client-side classes and methods on the server. Send packets and don't use direct keyboard values, especially not as magic numbers (which key is 54, for example? Do you know without looking?) - registering KeyBindings for your custom keys also allows users to remap them to their own liking or even use something like a gamepad.

For your jetpack, you could make a method in your Proxy classes to check if the jump key is pressed, returning false from your CommonProxy and Minecraft.getMinecraft().keyBindJump.getIsKeyPressed() in your ClientProxy; then in your jetpack code, check if (MyMod.proxy.isJumpKeyPressed()) instead of what you have now. Note that it will still be client-side only, which is fine for messing around with the player's motion but not for damaging the itemstack nor for changing the player's inventory. Really what you should be doing is sending a packet from the client to the server when the jump key is pressed and released, storing its current state on the server for each player, and calculating most of your stuff on the server. Can't spawn particles from there, though

Just a tip in case you don't know: StatCollector#translateToLocalFormatted allows you to use most if not all of the same formatting arguments that String#format can use, so you can have complicated translations that are not hard-coded. E.g. If you have something like the following: return StatCollector.translateToLocalFormatted( "item.element.display_name", // translation key that will handle word order StatCollector.translateToLocal(this.getUnlocalizedName()), // first word, pre-translated StatCollector.translateToLocal(element.getUnlocalizedName()) // second word, pre-translated ); Without changing the above code, your language file can now support different word orders: // English: Item of Element item.element.display_name=%1$s of %2$s // Some language with different word order: Element blah Item item.element.display_name=%2$s blah %1$s It's not perfect as in some languages the word 'Item' or 'Element' might require a different form depending on the rest of the sentence context, but it's pretty flexible and works most of the time. Also note that you should never do any translating on the server, as it has no idea what language the client has selected. I fell for that some time ago when sending various chat messages from the server (the solution there was to send ChatComponentTranslation objects).

Last I checked there wasn't any generic left click method in the Item class, but you can subscribe to the ClientTickEvent and check if the GameSettings#keyBindAttack was pressed and your item is held, then call a method. Note that this is all CLIENT side, so if you want to do anything real, you'll need to send a packet to the server and do it there. PlayerInteractEvent may also work, but I don't recall whether there is a LEFT_CLICK_AIR; if there is, you probably still need to send a packet, as I doubt it is called server side. If you plan on having more than one item with this type of interaction, I'd make an interface for it such as ILeftClick with a method #onLeftClick, then you can have one check for that type of Item rather than a bunch of if/else if statements for all the different item types you want to handle.