coolAlias

That's my point: you SHOULD change things from the tutorial, because the tutorial is there to TEACH you about a subject, not provide you with a copy/paste solution. I'm going to rewrite my tutorials so the code doesn't even compile, just to avoid situations like this.

I just told you: "return (5 seconds * 20 ticks / second) = 100 ticks for the max use duration" In the Item class, there is a method called getMaxItemUseDuration(ItemStack) - override it and return the value you want.

Entity#getEntityData() returns the entity's custom NBT tag data; if the modder is being nice, he/she either used this custom tag or IExtendedEntityProperties. Otherwise, I think your only recourse would be to write the entity to an NBTTagCompound, then get the info from that. Using the getEntityData() tag, which is the most likely scenario: int type = entity.getEntityData().getInteger("Subspecies");

In onItemRightClick, set the item in use and have your Item return (5 seconds * 20 ticks / second) = 100 ticks for the max use duration; then, override onItemUseFinish, which is called after the item has been used for the entire max item use duration, and set the block then. Since onItemUseFinish doesn't give you block coordinates, you can either store the coordinates clicked as NBT or use the player's current look vector to determine where the block should be placed. Which one you choose depends on your intended design.

What do you mean by "all Blocks", the instance of the Block class, or every single block in the world? What are you trying to accomplish by storing this information?

See the whole history and you'll understand... I've tried explaining. And the tutorial IEEP identifier IS horrible for a reason - it EXPLICITLY tells you to come up with a more unique name: /** Note that a single entity can have multiple extended properties, so each property should have a unique name. Try to come up with something more unique than the tutorial example. */ public final static String EXT_PROP_NAME = "ExtendedPlayer"; Why bother to use a tutorial if you aren't going to READ it?

There is no way for you to know what other mods might be adding flying, but if you and they both code correctly, you should be okay. What I mean is, each mod should be applying player.capabilities.allowFlying=true every tick that it is allowed, and only turning it off ONCE, so if another mod still has a situation that allows flying, you turn it off, but they immediately turn it back on. It gets trickier with setting isFlying to false, because if you do that right away, even if the other mod allows flying again, the player will still fall out of the sky, so you should set isFlying to false on the NEXT tick IF the player is still not allowed to fly. Potions: Yes, apply them on the server. As a general rule, apply EVERYTHING on the server.

You need to call super.onUpdate() in your entity's onUpdate method.

Do you know how to use events? You need to put @SubscribeEvent annotation above your method and then register the containing class to the appropriate event bus - in this case, TickEvents are fired on the FML bus: FMLCommonHandler.instance().bus().register(new ClassContainingYourEvent()); Also, you check if the player has the same item twice. hasItem = checkInventory. if (checkInventory again, even though I just checked it...) You may want to consider using more curly braces to make your logic clearer as well. if (condition) do something // vs. if (condition) { do something } The second is much less prone to mistakes, especially as nesting gets deeper.

That's because the Item#onUpdate (and any other such methods, e.g. onArmorTick) are only called while the item is in your inventory. To change something when it is NOT there, you have to be able to check from somewhere else, such as the PlayerTickEvent.

Are you spawning the arrow on the server only? If you spawn it on the client, too, weird graphical glitches like you describe can happen. If you don't register your entity, then the server will not send a spawn packet to the client - that's why your entity was invisible when you tried that earlier. In sum: 1. Spawn ONLY on SERVER 2. Register using ONLY EntityRegistry#registerModEntity 3. Make sure you are using correct tracking update frequency value 4. Double-check your entity code to make sure you are not doing anything weird in there

That question doesn't make any sense... Have you used proxies before in modding? You should Google it. Anyway, it's probably not necessary for your situation - often, you can just place the 'world.isRemote' as the first condition in your if statement before any client-side classes are accessed, and that will be enough to prevent the server from crashing. There are situations where that is not sufficient, however, but in your case, I bet it will be.

The problem is you are registering your entity with the incorrect tracking values. I don't know why, but I see it ALL the time that people want to use '1' for the update frequency, and that's just plain wrong. Look at the EntityTracker class to find the entity most closely resembling yours, e.g. an arrow, and see what values vanilla uses for tracking - then use those same values for yours. Arrows use '64, 20, true' for the last 3 parameters. Also, don't use global entity IDs. One, there is no point in using them for things like arrows, and two, they are for vanilla only. You should only use EntityRegistry#registerModEntity. Just that, nothing else.

What doesn't work? We can't help you if we can't see your code. Also, if you are just going to ignore every single property in your blockstate definition, why have them at all? Can you not just remove all of the properties from the block? If you do need the states for something but want it to have one single model for every possible state, you can easily do that by returning a single ModelResourceLocation from your mapper: new StateMapperBase() { @Override protected ModelResourceLocation getModelResourceLocation(IBlockState state) { return yourModelResourceLocationHere; } };

You'll want to make sure you are on the client BEFORE checking any Mouse or Keyboard states, and it would be even better if you checked that state through your proxy. As your code is now, it will crash a server.

Bumping after 40 minutes? Seriously? Anyway, of course it is not swapping server side - you are using Minecraft.getMinecraft().thePlayer, which is CLIENT side only. Use an EntityPlayer from a parameter somewhere, probably in a packet since you are trying to swap with a button press - input interactions are also CLIENT side only.

Easy if you are on the client side: if (Minecraft.getMinecraft().currentScreen != null) But you shouldn't use that in an Item method - use MouseEvent to handle left clicking. There is also EntityPlayer#openContainer, but I haven't found that to be as reliable as it seems to only account for Container-based GUIs (which the inventory is, so you may be fine).

If they don't need the powered property, then remove that property from your door. If your door needs to have that property but you do not want it listed in the JSON file, then register a custom state mapper that doesn't use it, e.g.: ModelLoader.setCustomStateMapper( yourBlock, (new StateMap.Builder()).addPropertiesToIgnore(POWERED).build() );

This is not true. You cannot specify the tick rate for random ticks. The tickRate method does nothing. Are you sure? When I tested it out before, it definitely seemed to affect how often the updateTick method was called, but that was way back in 1.6.4, of which my memory is a bit foggy, so... Hm, yeah it seems tickRate isn't really used anywhere other than (in 1. for trip wire hooks which use it when scheduling a block update, and in Forge's BlockFluidFinite class. In 1.7.10, it's only used for stairs, and not really even there because it just returns a different block's tick rate. Really makes one wonder sometimes, doesn't it? It's probably legacy code that Mojang just hasn't gotten around to removing (I hope).

Thanks diesieben and Lex, that's what I thought, but I wasn't sure if there was something I was missing.

It can be every tick, but normally it's not called at all unless you specifically schedule an update tick (which you could do every single tick). For blocks that are set to tick randomly, it is called somewhat regularly based on the tick rate you return from tickRate(World).

Yes, I know that, which is why I'm limiting the event to only handle one element type. My question is whether there is any reason to choose one element type over another. Rendering in creative vs. survival would be such a reason, if it were true (it's true that the experience bar itself does not render in creative, but the event still fires for that element type so custom GUI elements can still render just fine).

You just need to check the chunk bounds while generating, or even just check if the chunk for each given position is loaded, but that's a lot more checks than simply restricting your bounds. Given a set of block coordinates x/y/z, the chunk coordinates are (x >> 4) and (z >> 4), which is equivalent to (x / 16) and (z / 16). That will give you the (0, 0) of your current chunk, but you want block coordinates so multiply it by 16 again to get those. // example int x = 64; int z = 72; int cx = (x >> 4); // gives you 4 int cz = (z >> 4); // also gives you 4 cx = (cx << 4); // gives you 64 cz = (cz << 4); // also gives you 64 // (64, 64) is your zero position for the block coordinates (64, 72) // This iterates over every x position in the chunk: for (int i = cx; i < cx + 16; ++i) { // put z position, etc. } Or, once you've found the zero position, you can also set the max (zero + 16), and the make sure every block position you set is within those bounds.

I'm in the process of consolidating my various Gui Overlays to all be called from the same event handler, rather than each being registered as their own independent event handler, and it got me curious: - Is there any reason to choose one ElementType over another when rendering an overlay? - Is there any reason NOT to use the same ElementType for all Gui Overlays? They render just fine regardless of which I use. What I'm doing is this: @SubscribeEvent public void onRenderExperienceBar(RenderGameOverlayEvent.Post event) { if (event.type != RenderGameOverlayEvent.ElementType.EXPERIENCE) { return; // chose a random element type to use for all overlays } // My event handler class has a List of IGuiOverlays to render for (IGuiOverlay overlay : overlays) { if (overlay.shouldRender(event.type)) { overlay.renderOverlay(event.resolution); } } } As you can see from IGuiOverlay#shouldRender, I originally looped over all gui overlays for every single element type and let them decide whether they should render or not, but that seemed inefficient, so I ended up with an EnumMap<ElementType, List<IGuiOverlay>> to reduce how many times my code was lopping, and that seemed like overkill. Thus the above questions. Cheers, coolAlias

event.state is an IBlockState instance, which you are comparing to a Block instance, so of course it is always false. You need to use event.state.getBlock() to compare.