Bukkit

@Faldonboy

By the way, you've been with ZariusT far longer than I have. Would you by any chance happen to know about his "whereabouts"? I do have his email, but I think resorting to that would basically be me adopting the "update now plz!?" attitude, and at this rate, I consider myself bordering on that.

If necessary, I may even consider making a list (which I will post later if I make it) of 1.7+ features that won't work (or can't be recognised) with the current latest build of OtherDrops.

@CommodoreAlpha

Ya, most spells have a target-self or beneficial option. And for the spells that don't you can have OtherDrops force them to cast from console and target your opponent or an x,y,z location.

@Faldonboy

So it's possible to have a player target himself with his own spell, even if it was an offensive spell? That's a really interesting feature...

@ZeEye

The only possibility that comes to mind at the moment, is to get a developer to fork the project. ZariusT hasn't been on in awhile, so I don't know what's happening with him.

@CommodoreAlpha

@Zarkiel7

Mobs casting spells is possible using OtherDrops because MagicSpells can force a player to cast a spell via console, so you could create spells that target the caster and have OtherDrops force you to cast them on damage events to make it appear that the mob was casting it. It would be far easier to get a plugin like MythicMobs or create this system inside of MagicSpells itself though.

@Zarkiel7

Does MagicSpells allow mobs to cast spells on its own? Do spells need a target? If so, how is the target acquired? Via command? Entity within crosshairs? Are there any restrictions to spell-casting? (What conditions to casting spells are there?)

I've only heard of MagicSpells, but I can only guess that it won't be possible to do so, because of all the possible caveats I inquired about within the above paragraph.

If MagicSpells allow mobs to cast spells on its own - that is, if spells don't need to be executed from a player - then keep reading. If spells require a player, mobs won't be able to cast spells because... well, how are you going to have a 'player' that will impersonate the mob and who will this 'player' be? The solution to this would be far more complicated than its worth.

If spells don't need to be executed from a player, you'll next need to consider if a target is required. If a target is not required for the spell in question (I know there's multiple types of spells with varying conditions), then mobs should be able to cast that specific spell. If a target is required, keep reading.

If a target is required, you'll need to consider if MagicSpells gets the target via the crosshairs (where the player looks) or via command (specifying a playername in the command). If it's via crosshairs, the mob casting the spell would be impossible with just MagicSpells and OtherDrops, because mobs don't have crosshairs. If it's via command, you'll just need to specify the playername, via a variable.

On second thought, giving mobs abilities from MagicSpells via OtherDrops might be a tad bit complicated/impossible. Maybe it's best to find a third-party plugin to do what you want. :D

@SentinelCraft

I don't know myself, as ZariusT hasn't been in awhile even though he said he would push out an update... eventually. I don't have any method of contacting him (I do have his email, but I feel as if emailing him as a "reminder" to work on OtherDrops would be inappropriate).

OtherDrops will always work on future Minecraft versions, unless something fundamental about Minecraft's code changes - I wouldn't see why you would have to drop OtherDrops entirely due to that. You could, perhaps, supplement OtherDrops with more plugins, but given its power, I don't see a need to drop it due to it being "outdated".

@Testercraft

No need to apologise about language difficulties because you're the one trying - I'm sure I would sound pretty crappy myself if I tried to write in your language. ;)

So, what you have to take into account is that you have two entries in there. The first entry basically reads like this:

First Entry:

"When you break 'CROPS' with 'GOLD_HOE' (the correct name is 'GOLD_HOE' not 'GOLDEN_HOE'), you will drop 'x' drop and the crops will be replaced by '59@1'."

Second Entry:

"Any item with the name, '&fGladius Hoe' is required for this drop to occur. When this drop occurs, drop 'x' will drop, with a 25% chance."

Do you see the problem with keeping the "tool:" and "lorename:" condition within two separate entries? You need to combine the conditions into one entry if you want the plugin to recognise that only "Gold hoes with the name, 'Gladius Hoe'" will work.

I hope that was helpful, but if you have further questions, or you want me to clarify what I said, feel free to ask.

@Zarkiel7

This example should work:

    ZOMBIE@21h:
    - drop: DIRT

Here, all zombies that have a max hp of "21 points" will drop dirt. All other zombies will drop whatever you specify and/or whatever the default is. Don't forget to specify that the "special mob" should be able to spawn to begin with.

I don't quite remember how to specify names on mobs... I really should have documented that when it came up in the comments quite awhile ago. I believe the format for naming mobs is something like "ZOMBIE@Example Name", but I could be wrong.

@ZeEye

Ah, thank you very much. About colour coding, your (and Faldonboy's) contribution has actually been incredibly helpful, as it "solves" a problem many others have had. I say "solves" because it's a good workaround, but the bug still exists in that the colour code should be accepted regardless of text formatting. But that doesn't matter; excellent job. :D

Concerning "DAMAGE_WATER" not working, it might be because it's a bug or because it's not completely coded. For now, though, you'll just have to live without the parameter. I know of an unsavoury workaround for this... but it's unsavoury for a reason. You can use the WaterProof plugin to make it so that crop blocks are invincible to water (the plugin requires NBTLib, however). The problem, however, is that crops can be used as an ultra-effective barrier to water. If you don't mind the caveat of two additional plugins and waterproof crops, then this is one workaround I can suggest.

Changing the drop of farmland won't do anything about the crops, because OtherDrops would then focus only on the "farmland block". The "farmland block" is just a block, and has nothing to do with "CROPS" - which could be counterintuitive, but that's how the basic block mechanics of Minecraft works.

So, with all the issues revolving around "CROPS", I would say (from the top of my head; keep in mind I don't know code) that it's not possible to modify OtherDrops' code so that it can read for these events and cancel them properly. Which brings me to my next point...

On my sidenote, I do understand finding that "balance" can be painstakingly difficult. My apologies if I made the process sound too simple, or if I berated you in any way. For now, I can only recommend solutions/workarounds involving other plugins; the issues here cannot be resolved with OtherDrops alone.

If you are trying to limit the yield of wheat-crops so that people will find it harder to make bread, you can use RecipeManager to change the recipe of bread to something more costly. You need to use the unofficial build posted within the comments by @haveric. The general idea is that if you cannot change the output, make everything requiring the output more expensive; this is an indirect way of devaluing the output, which in this case, is wheat.

@Zarkiel7

Currently, you can't do that. There needs to be some distinguishing factor about "custom mobs" that you create so that OtherDrops can pick up on them. An easy way to do that would be to give the mob a different amount of hp, a unique name, or both, then edit their drops based off of those factors (making sure to include "NONE" as a drop, or turning on "loot_overrides_default").

Giving "custom mobs" specific groups sounds like a good idea to make distinguishing between mobs easier (and to also distinguish and keep track of which mobs "belong" to OtherDrops), but ZariusT hasn't been on in awhile, so it's unlikely the idea will be implemented any time soon.

Do make a ticket about it though. Better to have it on a "to-do" list than to have it get washed away in a sea of comments.

@asacavanagh

Technically, [DEFAULT, DIRT] should work just as well as - and if not "better" than - listing them as separate drops. Do you by any chance have "loot_overrides_default" set to true?

Also, I believe the skin database will be based on UUIDs in the near future (because player-names are changeable, and are thus not representative of accounts). That being said, Mojang will probably have a UUID for all their MHF skins. Where you will find that, I don't know. A good place to start searching would be the Minecraft Wiki.

@Varijon

A player is a player - there's no such thing as "fake" players and "real" players (concerning the concept of accounts; in-game fake players are a different story).

@DivinityCraft

Specify the drop as "NONE", then specify whatever drops you want. "NONE" is a variable that will just cancel vanilla drops.

@tremby90

Firstly, I would tell you to rethink your server's design. Before you go about making anything on your server a certain way - for example, being able to get multiple "ore" blocks from the same ore - you need to think of all the possible exploits that will come about.

Yes, OtherDrops can fix most item-related "exploits" whether they come from other plugins or from itself (depending on what you specified in the config), but the idea is that there shouldn't need to be anything to fix to begin with, UNLESS the problem is intentional (and if it's intentional, you should also have a solution already).

To answer your question more directly, use data values on blocks (i.e. GOLD_ORE@1) so you can distinguish between "natural" blocks and "dropped" blocks.

@The3ShotGod

I don't use aliases myself, but I believe there's an alias.yml file somewhere you can edit. Just edit the names there. "OAK_LEAVES" is basically "LEAVES@1" and the tall grass you're thinking of is "LONG_GRASS@1". "GRASS" refers to the block itself, because that's its name.

@Anyone else

If I missed anyone's comment, or a question anyone may have posted, and they still need help, please post it as a comment again.