coolAlias

So the same drop from a monster can be picked up by multiple players? Is there a limit to the number of players that can benefit from a single monster? What I would do is simply set the drop's stack size to an appropriate number, and then use a custom EntityItem so you can manage the pickup process. There, you check if your player has already accrued this item - if so, do nothing; if not, subtract 1 from the stack size and grant the player that material. If you are concerned about the item still rendering, you could try killing it on the client-side only for the player that picked it up. Might have some unintended consequences, but it could work. However, I think this system would work best if the dropped stack can be picked up only by one player at a time. You still need to override the pickup mechanics using a custom entity (or one of the Forge events), but then you don't need to worry about the rendering bit. If you want to allow more than one player to benefit, simply drop more of the item as separate EntityItem instances, each with a size of 1, and don't let them merge together. You could do a quick count of the number of players within a certain distance of the mob when it is killed and use that to decide how many to drop.

If you want to emulate rapid fire and/or shotguns, Ernio's suggestion of using particles is spot on. In order to manage the attacking aspect of it, rather than spawning an entity, you can ray trace each tick while the item is in use for the semi-autos and hit whatever that is (giving you ~1200 bpm, but realistically, a typical rifle magazine holds 30 before needing to swap out). Even if you get 'crazy', max magazine size is still 100 at best unless you have a feeder instead of a magazine. So sure, you can fire 30-100 shots at a rate of 1200 bmp, taking all of about 1.5 to 5 seconds before needing to reload, a process that likely takes 5-20 seconds or more depending on training, stress, etc. Just be sure to flag entities struck in this manner so that if they get shot again, you can stack the damage. Alternatively, just always allow firearms to cause damage, and forget about setting a flag. I'm sure you're aware, but doing so goes against a specific design choice of Minecraft to limit damage, and it could have serious playability consequences; of course, you'll have to try it to find out what those may be, and it could turn out to be awesome fun. For the shotgun, I'd recommend spawning a single entity per shot, and override the #onUpdate method so you can make a custom hit-detection algorithm. The projectiles ticksExisted field gives you the perfect input for calculating spread, and you'd simply damage every entity within the current spread. If you wanted to get fancy, you could estimate how many pellets you'd expect to hit that entity as a function of the current spread compared to the entity's height * width, and subtract that many pellets from the 'total'. Once the number of pellets is 0, the shotgun shell 'entity' is 'dead'.

You can make an entity travel quickly enough to be impractical to dodge. You can use a ray trace over a long distance, but keep in mind that the typical amount of loaded chunks is not going to be that far. 1 chunk = 16 blocks, and in most cases you will have 8-12 chunks loaded in any given direction, giving you 128 to 192 blocks worth of viable distance at most. Whether you choose an entity or a ray trace, entities can only be damaged once per 20 ticks or so; once damaged, any other attacks during that grace period do not inflict any damage unless the amount is greater than the previous damage amount. E.g. you get hit for 2 damage from a zombie and a few ticks later a creeper blows up next to you for 20 damage - even though you are immune to damage, you will still be hit for 20 damage because it is greater than 2. If you had been hit by a skeleton's arrow for 3 damage, however, the horde of zombies trying to attack you would be impotent until you once again become vulnerable to damage. Minecraft purposefully does not allow multiple attacks to stack damage, and I don't recommend trying to circumvent that. You may was well make one bullet kill rather than making damage stack.

Without code in front of me, an NPE during rendering suggests that you registered your item renderer BEFORE you instantiated your Item. Check RenderSnowball line 43 - if it has anything to do with an Item or ItemStack, then you just need to make sure to instantiate all of your Items and Blocks at the beginning of pre-init, and register your renderers at the end of pre-init (or during init, since you are still pre-1..

The title may be self-explanatory, but the problem certainly isn't without a crash report.

If your glowing items would normally be extending Item anyway, you can make one class e.g. ItemGlowing that the only thing it does is override #hasEffect to return true. Then any item you want to glow, you use that class. If you have multiple glowing items that would all be different classes, e.g. one that is an ItemTool, one an ItemFood, etc., then you either have to make separate classes for each of them (which you'd probably be doing anyway), or use an anonymous class. If you have some glowing items and some not using the same class, then you can use a final class field e.g. 'boolean glows' that is set via the constructor, and return that field from #hasEffect. That way, each item can specify whether or not it glows.

Except the OP's item probably isn't an ItemSimpleFoiled - you should only extend a class when your object is specifically related to that class. One wouldn't extend ItemSword to make a chair just because one wanted an attack damage attribute modifier. If ItemSimpleFoiled were a class that only dealt with the enchanted item glow and that was its sole purpose, and everyone understood that anything that glows should extend from that class, then I would agree with you.

As mentioned above, but you don't need to bother with ItemSimpleFoiled or anything else, just override #hasEffect in your Item class and return true. If you don't have a custom class, instantiate your Item using an anonymous class and override it from there.

One major problem with your code is you are using Minecraft.getMinecraft().thePlayer almost everywhere. That is the CLIENT player only, and you should NOT use it pretty much ever. Use the player you pass to your constructor, e.g.: public SkillPacket(EntityPlayer player, int[] s ) { // you pass 'player' here, use it! MarkData p = MarkData.get(player); // here, instead of Minecraft.getMinecraft().thePlayer p.XP = s; } However, the problem that you are experiencing is, still, that you do not understand the static keyword. Your IEEP#XP field CAN NOT be static lest you want every single player on the server to always have identical amounts of XP. And please, use some constants for your skill IDs (or wrap them in class instances) - how is anyone supposed to know what skill 15 is? Your code is going to be a nightmare to debug down the road, if it isn't already.

It's not BlockPos that makes it not work, it's the fact that Item cannot hold independent values. Say that two players both are holding an ItemStack containing your Item; player A right clicks, setting CustomItem fields appropriately. Well, now player B's item ALSO contains player A's position, because Item is a singleton as Ernio pointed out. If player B were to right click, player A's item values would also change. The only way you can store independent values for an Item is by using its container, i.e. ItemStack. That's why item damage is stored in the ItemStack and not the Item. Same with NBT. You can store the BlockPos in the ItemStack NBT, but not in the Item as a class field.

How are you accessing the magnet item's inventory while a GUI is already open? I don't see anything about the magnet inventory inside your GuiWirelessCraftingTerminal class.

You create a class that extends BehaviorDefaultDispenseItem OR implements IBehaviorDispenseItem, then you register it like so: BlockDispenser.dispenseBehaviorRegistry.putObject(item, new YourCustomDispenserBehavior());

Whenever you want to do something, take a moment to think if there is anything in Vanilla Minecraft that does something similar and then take a look at that. A) override #setDead in your entity class, check if it's tamed, and if so, do something like set its HP back to max and teleport it somewhere random. B) sitting: not too complicated - take a look at EntityWolf for the interaction and the wolf's Model / Render class for rendering stuff B) Chest GUI: quite a lot more complicated than either of the above - take a look at EntityHorse, plus the related Gui, Container, and IInventory (or whatever that has become if you are in 1.9) classes. If you are new to Java / modding, you might want to wait until you are more experienced to tackle this one. C) Override #attackEntityFrom in your entity class - the DamageSource#getEntity() method returns the entity that caused the damage, so you can check there if it is the owner and then return false rather than allowing any damage to occur.

Sounds like you are modifying position/velocity on the client side - don't do that. Non-player entities should have their velocity adjusted only on the server (and ALL entity types, players included, should only ever have their position adjusted server-side) - it will update all tracking players with the new motion automatically.

The fastest Minecraft can do anything is on a per-tick basis. Theoretically, someone might be able to right-click faster than once per tick and thus fire more bullets than any other method, but I haven't tested that. At worst, #onItemRightClick will be just as fast (or slow, depending on your perspective) as any of the tick methods. You can, however, simulate faster than once-per-tick by spawning multiple bullets per click/tick with their position offset so that bullet 1 starts further away than bullet 2, e.g. by 1/2 to several block distances between each bullet. You could also give them slightly different trajectories to emulate 'spray' or not-quite-perfect accuracy (take a look at EntitySkeleton's ranged attack for an example).

You should be declaring your Block properties as static - that's how every vanilla class does it, as well as every non-vanilla example that I have seen. Why it works that way, I couldn't tell you, but that's how it is so I wouldn't sweat it.

You need to override #onItemUse in your custom seed class; from there, you can do any type of checking you want and plant your crop on any type of block you want. As your code is now, your seed uses the same logic as its parent class, the vanilla ItemSeed, which makes all sorts of checks for plant type / sustainability and you don't want any of that. Here's an example of a seed that can be planted only on stone / rock-based blocks that are next to lava. As you can see, there is nothing that requires you to make the same checks as the vanilla seeds do.

Pre-1.9, you could also generally assume that the ItemStack returned from #getHeldItem is the one currently in use - it will always be the case for vanilla, and probably for about 99% of mods (even ones like BG2 that add dual-wielding because they purposefully coded it that way).

So the method #getConfigurationManager still exists, but its return type (class) doesn't? I have neither Eclipse nor a 1.9 workspace on this computer, but if the method exists, its return type must exist. You can use your IDE to search, open call and type hierarchies, or just ctrl-click your way through classes and methods until you get there, but you should be able to find it. The method in particular that I have used was called #transferPlayerToDimension

Np. Rookie mistakes (that every one of us has made) Btw, since Items are all instantiated as singletons, you can compare using identity '==' rather than the #equals method (which does check identity, but also potentially a lot of other stuff e.g. for complex objects that are separate instances but may still considered equal). // this is the typical way of comparing Items and Blocks (but NOT ItemStacks if you care about damage value and/or NBT data) if (cycledStack.getItem() == heldStack.getItem())

So what's the problem? Are you getting NullPointerException (i.e. because you don't check if cycledStack is null before calling a method with it)? Is your count not incrementing (i.e. because your condition is never true - ItemStack != Item)? Is the message not getting sent (I don't see any code to send a chat message...)?

Just FYI, almost all vanilla mobs use 3 as the update frequency and 80 as the tracking range - using the values of the most similar vanilla mob usually gives the best results. You can find all the values in the EntityTracker class (or maybe EntityList? I forget which one).

Shaped and shapeless recipes are added via the GameRegistry, and furnace recipes are added via the FurnaceRecipes class instance.

Damage is incremental, not decremental. When the item's damage value equals the max damage value, that is displayed as '0/max' and the item breaks, but really it is 'max/max'. An undamaged item is '0/max', but displays the opposite. Normally you use ItemStack#damageItem to damage an itemstack, not #setItemDamage.

Your block of code doesn't show how you determine what each of those variables' values are, so I can't say for sure, but if neither block changed, then chances are the coordinates are not what you think they are - possibly you just got them backwards, i.e. setting each block to itself.