Bukkit

@DoubleZ

I don't believe your first idea (mobs killed by bow with flame enchant drop something different) is possible. Here's why:

1. Your first example states that mobs should drop "x" if killed by a bow with the flame enchantment. Think about that quite literally. You're saying that mobs will drop something different if literally killed by the bow. Not an arrow, a bow. You specified a bow, therefore you'll get a bow. That's why mobs drop the custom drop when you swing at them.
2. Arrow entities cannot be enchanted. Entities (besides item drop entities) cannot be enchanted. From the plugin's perspective - and given the fact entities cannot be enchanted - "PROJECTILE_ARROW@!ARROW_FIRE" makes absolutely no sense.

In order for it to be possible, you might have to make a suggestion to Zarius (via a ticket) to support a bit of extra data for entities - in this case, entities on fire. In other words, I don't currently believe there is a way to specify in OtherDrops whether an entity is on fire or not, but if you could get Zarius to implement that, then you could specify "PROJECTILE_ARROW" on fire, along with the custom drop, to successfully implement the idea you want.

Now, as for your fishing rod example, I'm not sure what you're trying to do here. If you want the most specific, accurate help possible, you're going to have to specify what you're going for there. I'm going to assume you wanted to make a fishing rod that would slightly damage and poison enemies if they were hit by the "fishing hook".

First off, I'm not sure if the "trigger: HIT" parameter works as you'd might expect. I believe as of right now, "HIT" is just an alias of "LEFT_CLICK" - hence why your example may not work. But I may be wrong, and if I am, that's good.

I'm not sure why you have a "lorename" specified. Well, I do have an idea of why you would do that, but remember, I'm reading it like the plugin would: quite literally. I don't believe certain entities - including this one - can have a "name" or "lore". Again, distinguishing between fishing hooks based on the names of the fishing rods they came from might require extra functionality to be implemented (meaning another suggestion ticket). In short, the parameter doesn't make sense to have it there.

I'm not sure why you get the errors, but I do have a few ideas. The first message might suggest that OtherDrops doesn't recognise the "PROJECTILE_FISHING_ROD" entity, which could be a bug, but I really don't know. The second suggests that you used an invalid tool for "ANY_CREATURE"; again, I'm not sure - but I believe the two messages are related. Because OtherDrops doesn't recognise the entity, the entity doesn't "exist", and is thus an invalid tool (you can't use things that don't exist).

@semirotta

Before you make dubious claims in response to someone's question, read up on the documentation, for this case, here and here. I know you weren't acting in bad faith, but misinformation is something you always want to try to avoid. Always.

There is such a thing as "PROJECTILE_FISHING_ROD", otherwise he wouldn't have used it. And again, the plugin being quite a literal reader, "FISHING_ROD" wouldn't work, because (I would assume) he's looking for the "fishing hook" to deal the effects, not the item itself. The plugin would read "FISHING_ROD" as the actual item itself; that left clicking an entity would inflict poison on it.

Also, he didn't use "ANY_CREATURE" as a tool, so I'm not quite sure why you said "ANY_CREATURE is not a tool for block". In fact, the error states "Unrecognized tool for block ANY_CREATURE" which implies ANY_CREATURE is being referred to as a "block", not a tool.

@TheMcPlayer1997

You can try this:

    HORSE:
    - tool: [SADDLE, -SADDLE@!~Horse Saddle]
      trigger: RIGHT_CLICK
      drop: DENY

This basically means "Unless you right click ANY horse with a saddle named 'Horse Saddle', your action will be canceled." And do note that's most likely case sensitive. Using "drop: DENY" is pretty counterintuitive - there are no drops, I know, but "denying a drop" also means to cancel any event, so using that to cancel saddling a horse should work. If it doesn't, you would probably need to ticket Zarius for that.

I'm not sure if the example will work for a variety of reasons, however. One is that I don't remember if the Bukkit name for the horse entity is "HORSE". Another is that I don't know if you can make "tool negations" based upon lore alone. If you can't, tell me and I'll suggest another workaround I know of, though it's more intricate and requires other plugins.

@NemesisMate

Most likely, yes, you can. For the animal you want, specify the "drop" - be it an item, an entity or both - and specify "spawnedby: BREEDING". That should work pretty well.

@TheMcPlayer1997

This plugin is about drops, not crafting. You might want to look at this plugin though.

@Tony556

I don't know if this includes OtherDrops too, but most plugins seem to be unable to drop/give blocks - that don't normally support metadata - with metadata. In other words, most plugins can drop something like "LOG:2" just fine, but they won't be able to drop "STONE:1" because stone is both:

1. A block-type item.
2. Doesn't normally support metadata. Usually if those two conditions are met, most plugins (and vanilla's "/give" command) tend to fail at giving block-items with metadata.

On a side note, for some reason, if you used "replacementblock" however, OtherDrops will successfully replace the block with what is configured, regardless of the "restrictions" mentioned earlier. Which is strange indeed.

However, I do not suspect your issue to be a bug unless you can prove it to be a bug. You can prove that it's a bug by using a test server and running OtherDrops alone, and seeing if this lack of metadata applies only to a specific case, like "104" dropping with no metadata, or to all block-type items that don't normally support metadata. If it applies to specific cases only, that would be quite weird, and it would probably be a bug - making it ticket-worthy. But if it applies to all the cases that I've expected, then it's not a bug.

Long story short, if...

    GOLD_ORE:
    - drop: {104@1,104@2,104@3}
      chance: 1%

...won't work for you, I don't know what will. You'd have to come up with a creative workaround, or this simply isn't possible.

@Shraven420

I forgot to say this, but you should try testing the configuration on a testing server running only OtherDrops and the appropriate CraftBukkit build. If blazes still don't work as intended, it's probably an issue with OtherDrops that you should report (in the form of a ticket). If blazes start dropping as specified in the config, then it might be due to a plugin conflict.