coolAlias

You can't use #onArmorTick for removing flight (because it is only called when the armor is worn), but you can use it for adding flight. There are lots of topics on this, especially over at Minecraft Forums. To sum up the common theme of all of them: 1. There isn't really a good way to not conflict with other mods, though there are some things you can try. Your best bet is to set the player's flying capability EVERY tick while your flight should be allowed; if every mod does this, then even when you set flying to false, the other mod should set it to true shortly thereafter (though it may still cause the player to fall out of the sky...). 2. The only reliable way to remove item-based flight is to check using the PlayerTickEvent, as this is called every tick no matter whether the player is holding or wearing the item(s) or not. So, you may as well use it to add flight, too.

How long is the string you are sending? You may have to split it up and send 2 packets after a certain length, but it takes a LOT of data to reach that point. Also, why are you encoding it to base 64? You can read and write directly: ByteBufUtils.writeUTF8String(buffer, this.message); this.message = ByteBufUtils.readUTF8String(buffer);

Unfortunately, there is no global meta flag that indicates that a crop has reached maturity, though the vast majority of crops will extend the vanilla BlockCrops class and thus tend to use meta 7 as the max growth stage. I don't have access to the code right now, but if you check the methods in BlockCrops and any interfaces it may implement (e.g. IPlantable or whatever), I seem to recall a method isFullyMature or some such, but it's been a long time so I could be totally wrong. Anyway, if there is such a method, you can check if a Block is an instanceof said class, then cast and call the method. boolean isMature = false; if (block instanceof IPlantable) { isMature = ((IPlantable)block).isFullyMature(world, x, y, z); } That would be more reliable than using metadata directly, but again, I don't have the code in front of me so I'm just making shit up.

It's pretty simple: player.motionY = 0.1F;

Well, 10 is a HUGE amount of upward velocity. To put it in context, a vanilla jump adds 0.15F, which is approximately one block height worth of upward momentum, so 10 should be about 66.67 blocks though I think it launches you even farther than that, iirc. Try player.motionY += 1.0F for less of a jump, but even that won't get you a levitation-like effect. If you want a slow-moving upward trek, you have to set (not add) the player's upward motion every tick to a small positive value such as 0.1F or less. You can do that either by setting a flag in your Item's enclosing ItemStack and using the Item's update tick method, or setting a flag on the player themselves and using the PlayerTickEvent.

If you know why you should extend a class, then you should know why you would get rid of 90% of that code and replace it with calls to super or not override the method at all. If the arrow is spawning on you, that is a problem with how you create and initialize the entity instance, either in your constructor(s) or in the code that spawns the entity.

What is your question? It's not clear from your post what exactly isn't working as intended. Also, as others have pointed out, you would benefit greatly from learning more about Java - in this casae specifically, I'd recommend learning about inheritance. Then you'll understand why it doesn't make any sense to 'extend EntityArrow' and the copy the entire contents of EntityArrow into your class.

VSWE did a tutorial series for 1.6.4 about interfaces, among others. Even though it is outdated, the concepts still hold true, and if you are struggling with understanding how something like a scrollbar works, I think you may find that series helpful. As for scroll bars, at its most basic it is simply storing the current x or y position of the scroll bar and rendering things on the background based on that. Think if you have a 1000 x 500 canvas, but can only show 200x100 at a time. Determining which part of your screen to render can be figured by calculating the scrollbar's position on a scale of 0 to 1. In this example, the scrollbar can be anywhere from pixel 0 up to "screen width or height minus scrollbar size in pixels" (for its top- or left-most position), so (current position / max position) is the current ratio which you then use to determine where to start rendering from. E.g. for a vertical scrollbar that is 10 pixels tall on our screen that is 100 pixels high, if it is currently at y position 45, then our ratio is (45 / 100-10) or 0.5F. Multiply that by our canvas sizes and you get 500 for the starting x position and 250 for the starting y position, so you will render from 500 to 700 on the x and 250 to 350 on the y. It may seem complicated at first, but it's really not. I highly recommend that tutorial series as it will introduce you to a lot of these concepts.

Items.stick? Items.apple? YourModItems.crystalKey? Whichever Item you are searching for. And be sure to put a 'break;' statement after you find it, since you don't need to keep looking.

Iterate through the player's inventory and, if you find the ItemStack containing said item, you can add NBT to it with the instance you have from your for loop. Pseudo-code with potentially dodgy syntax: for (ItemStack stack : player.inventory) { if (stack != null && stack.getItem() == itemYouWant) { // modify and/or set the stack's tag compound } }

Yes, but you have nowhere to do that, as there is nothing like IItemRenderer or similar. You're probably going to shoot me for this (I thought about doing so as I wrote it, so you're not alone), but you can cheat and do it inside of Item#getModel. It's on my list of things to 'fix' and do properly at some point, but with all the changes to rendering that happened within 1.8 and now 1.8.9, I was kind of waiting for a stable code base before I waste tons of my time learning it again (by that I mean in 1.8 there was an update that changed how rendering was done, specifically transformations, and negated hours of time I had spent getting my shields to render correctly... I still haven't fixed that, either). @OP Since you are already in 1.8.9, you should just spend the time to learn how to do it properly.

At least in 1.8, you can still tell Minecraft to render an ItemStack: for each ItemStack stored in your item { translate offset amount; Minecraft.getMinecraft().getRenderItem().renderItemModel(stack); } However, there is no guarantee that the items will be 2D - you could have some serious clipping issues with 3D models, and I don't know of any way to determine the 'width' of a model. As for ISmartItemModel, you just create a class that implements it and fill in the methods. Take a look at TheGreyGhost's MinecraftByExample code on Github and spend a couple hours playing around with it. You'll probably be able to figure it out. EDIT: Ninja'd by diesieben, and his explanation sounds like the more proper way to go about it.

Timing is as follows: int ticks = stack.getMaxItemUseDuration() - useRemaining; int iconIndex = (ticks > 17 ? 3 : ticks > 13 ? 2 : ticks > 0 ? 1 : 0); Where iconIndex is the integer variation of the model location to retrieve.

setupDecompWorkspace gives you the source, setupDevWorkspace doesn't. Yes, thank you. That's not what I said is it? THAT is what I was referring to. But... the guide does say dev... Or did you mean it the other way around, since hardly anyone would ever bother using the dev version? Or maybe they did change it?

The tutorial works in 1.8, too... hardly anything related to inventories changed, and there are plenty of notes explaining what you need to update. The capability system is like the IExtendedEntityProperties of Items - if you've got your own class, you're better off just coding it into that directly, but if you want your stuff to apply more generally (i.e. to all items or a group of items, such as tools), then that's where it shines. That's just the opinion I formed of it after glancing at it briefly, and I reserve the right to change my opinion at any time, especially after actually using it

I haven't updated any of my mods to 1.8.9 yet, so I can't give you the exact syntax for the IRenderFactory, but as long as you have a basic grasp of Java, it should be pretty straightforward, e.g.: public class MyFactory implements IRenderFactory { // whatever fields you need, e.g. Item to render public MyFactory(/* whatever args you need, e.g. Item item*/) { // initialize any class fields you made } // implement whatever methods it requires } // now when you register your renderers, it would be something like this: RenderingRegistry.registerEntityRenderingHandler(YourProjectileEntity.class, new MyFactory(MyModItems.projectileItem)); See? Not so hard. If that's too complicated, you can still use the deprecated registration method - just make sure to call it during the init phase rather than pre-init, whereas the new way is done during pre-init.

By 'static' do you mean non-moving? Why not make it a Block? If you need update ticks, add a TileEntity. If it's for trading, toss in an on-block right-clicked GUI + Container and you've got yourself a vending machine. As always, the more details you can give us about what you are trying to achieve, the better we can help you. ^^^ That is not very specific.

The obfuscated names simply mean no one has gotten around to submitting 'translations' for them to MCP yet, but it's pretty obvious what they are. You can get the RenderManager and RenderItem directly from the Minecraft class, whether you use the IRenderFactory or the deprecated version. // Old way: RenderManager manager = Minecraft.getMinecraft().getRenderManager(); RenderItem itemRender = Minecraft.getMinecraft().getRenderItem(); RenderingRegistry.registerEntityRenderingHandler(YourProjectileEntity.class, new RenderSnowball(manager, YourModItems.projectileItem, itemRender)); For the new way, you actually have to create a class that implements IRenderFactory and fill in whatever methods it has, then register your renderer passing a new instance of your factory instead of the Minecraft RenderManager and RenderItem.

Yes. Now you just need to do what Ernio suggested: read the vanilla code for examples. The furnace sends its burn progress to the GUI via the Container, so look at the furnace Container class, specifically the methods Ernio mentioned above.

There is nothing special about rendering a projectile entity vs. a regular entity - all entities are handled the same way: 1. Create your Entity class 2. Register your Entity class via the EntityRegistry 3. Register a Render class for your Entity (you can use vanilla Render classes or create your own) If your projectile has an Item associated with it (i.e. ammunition), then I suggest you start off by using the vanilla RenderSnowball class - don't even copy it, just use it directly until your projectile is rendering. This will help to ensure the rest of your code is correct before you start messing around with a Render class. Also, 1.8.9 introduces the IRenderFactory which is a factory method that allows you to register your Entity renderers during PreInit (it postpones the actual registration until later when the Minecraft render manager has actually been initialized). This is now the preferred method, though I'm not sure what was wrong with simply registering renderers during the init phase.

Are you sure you got the correct version? I haven't checked, but it might not even be compatible with 1.8.9 yet. You can still model in it using 1.8.0 - the models export as .java files just fine, which you can then use in your project just like the vanilla entity model classes.

Tabula is a mod, not a standalone piece of software - you run it from within Minecraft. There is a button on the main menu.

The 3rd parameter of #registerModEntity needs to be different for every entity - it is the entity's integer ID, and can start at 0 (which you did) and increment from there. You registered both your projectiles with the same ID of zero. Also, you should choose names that are unique - "Snowball" and "Egg" are already used by vanilla Minecraft (I think - if not, dangerously close). I suggest renaming them to "DangerousSnowball" and "DangerousEgg" or something prepending your modid. Finally, show the code where you spawn the entities into the world. It is possible you simply forgot to use the correct entity and are, in fact, spawning in snowballs

I just want to say damn, that is one waaaaaay over-engineered pig-spawning system you've got

Depending on how many textures / sub-blocks you have, you may need to make more block classes, but the general gist of it is #getIcon gives you both the FACE and the META, where the META would determine the sub-block, and the FACE which side of the block you need to get the texture for. You need to use both of these values to figure out ONE texture to return, e.g. the top texture of an oak log. This assumes, of course, that you have registered all of the textures; I'll use a double-array for the example. IIcon[][] icons; icons = new IIcon[num_sub_blocks]; for (i = 0; i < num_sub_blocks; ++i) { icons[i] = new IIcon[num_textures_per_block]; // e.g 1 for side, 1 for top, 1 for bottom = 3 textures per block for (j = 0; j < num_textures_per_block; ++j) { icons[i][j] = register texture for this sub-type and side combination } } #getIcon(int side, int meta) { int type = meta % num_sub_blocks; // determine which sub-block to use // if you had a texture for every side, you could return icons[type][side] // since side == 0 is the bottom side and side == 1 is the top side, // let's assume we registered 0 as the bottom, 1 as the top, and 2 as the side texture if (side < 2) { return icons[type][side]; // returns bottom or top texture of the specific sub-block } return icons[type][2]; // return side texture of the specific sub-block }