Bukkit

@My_Name_Was_Stolen

When you say the drops don't happen at all, do you mean the items dropping, or the event not being fired at all? For example, if you had something where a message and a drop fires when 'x' event occurs, does neither occur, or does the message occur but not the drop? If it it's the former, there might be a genuine issue with OtherDrops, or some event is being canceled before OtherDrops can intercept it (implying a plugin conflict). If it's the latter, there is also the chance of a genuine issue with OtherDrops, or a plugin conflict caused by a plugin blocking dropped items or something.

I'm not too sure why all, as opposed to one or two drops are not working. And just as a random tip, your spacing under "LEAVES@GENERIC" is off. Also, I did not know you could specify "GENERIC" as a data value, nor would I know why that's necessary to do, seeing as specifying "LEAVES" automatically implies all types of "LEAVES" blocks.

@JaffaMiner

Yes, it should be easily fixed, but by him, not me. A few things I would consider, is what kind of code RegenBlock uses (and if any of it relies on NMS code for some reason), if it's version dependent in any way, if its code has changed and OtherDrops needs to factor this change into its next build, etc.

@My_Name_Was_Stolen

New drops override vanilla ones if you have "loot_overrides_default" set to true within the "otherdrops-config.yml" file. If this is false, vanilla drops will occur in tandem with the drops you specify. If you want to set that option to false, but still override vanilla drops, you'll also have to specify "NOTHING" in addition to everything else as a drop to tell OtherDrops to cancel the original drops.

@dimasaurio

I'm not sure what your problem is, so I won't be able to help you effectively. Two things I do notice, though: there are two typos. It's "SUGAR_CANE" not "sugarcane", and it's "COAL" not "coal_inot". Coal ingots don't even exist in real life, as they are not a metal. The other thing I notice is that you have stone specified as an object multiple times; it would be better if you specified "STONE" as the object once, then put every entry under that object.

If you need me to clarify, ask, and I'll try to use simpler English.

@drewch123

I don't know how to code (yet); I'm just a documenter. ZariusT is the only developer for this plugin, so you should be asking him that question. Even then, the general response would be, "It'll be ready when it's ready." If you're dissatisfied with the lack of colour control in lores, and can't wait for the next update, submit a pull request or fork the project for your own needs.

@TheChiz

Please post your config snippets as "yaml code" so it's easier for me to read. Refer to "code" under this page.

Have you looked at how to specify drops on the parameters page? You can use brackets or curly braces to specify multiple drops, each with their own drop chances and drop amounts. There are also drop groups if you're interested in using that.

@drexel_levante

IRON_GOLEM@&1Modular Construct:

should be

IRON_GOLEM~&1Modular Construct:

As for the snowball issue, perhaps it's not so much as the feature is broken, but rather that the names you're using are deprecated (and hence why they don't work). I snooped around on the Bukkit javadocs and found that snowball entities are referred to as "SNOWBALL", not "SNOW_BALL", so you might want to try "PROJECTILE_SNOWBALL" instead of "PROJECTILE_SNOW_BALL". As for fishing hooks, you might want to try "PROJECTILE_FISHING_HOOK" instead of "PROJECTILE_FISHING_POLE". This one's a bit more intuitive, as it's not the fishing pole that's being thrown, just the hook.

@JaffaMiner

That might be a bug, considering how OtherDrops has support specifically for RegenBlock. ZariusT will have a better answer for you. My guess is that it has to do with OtherDrops tampering with the BlockBreakEvent and RegenBlock not recognising it, or something like that. Or maybe I'm just completely wrong about that aspect.

@MystTheReaper

It's already possible: just specify the tool needed with the enchantment. So for example:

    IRON_ORE:
    - tool: IRON_PICKAXE@!LOOT_BONUS_BLOCKS#1-3
      drop: IRON_INGOT/1-3

In this example, breaking iron ore with an iron pickaxe with the Looting enchantment of levels one through three will drop one to three iron ingots.

You can specify different enchant levels to drop different drops, but bear in mind, you have to specify every pickaxe you want the effect to happen on. (So for iron ore, that would include stone and diamond pickaxes.)

@McPixel

For your first request, no. Find another plugin for that, since that's a really specific, non-generalisable feature, so it really ought not to be implemented in this plugin.

As for your issue, I'm not sure; it looks fairly correct. Could you post a pastebin of your whole configuration? Also, I'm not sure if this has to do with anything, but you could try adding two spaces to both lines that come after "otherdrops:".

@drexel_levante

"PROJECTILE_SNOW_BALL" is not a trigger. It is an entity. Entities aren't triggers; that doesn't make sense, as they are merely agents that beget events. Events are triggers - and the trigger to use in this case is "HIT".

Also, if you have trouble with something, try posting the relevant snippet of your configuration so I can diagnose it better (if there is a problem).

Also, named bows work - I'm not sure what you're talking about because you haven't told me exactly what you want to accomplish with named bows. Named arrows are impossible to have, because an arrow is an entity, and does not retain any lorename-data from its item counterpart (all entities in general don't use/have name-based data; naming a mob is a different type of data entirely). Plugins that alter certain arrows add extra data onto certain arrows - not accomplishable by names alone.

@cyberpwn

OtherDrops is Bukkit/MC-version agnostic, although I believe version number might have something to do in this case. You see, I have the same exact problem as you - except without the error, and for some reason, it applies only to certain blocks in my config. For the whole "block drops item, block does not get destroyed" issue, you do not have to make a ticket because I already made one awhile back.

The reason I suspect the error itself is version-based is because I don't get it, and you do. I'm running 1.5.x, and you're running 1.7.x. I could be wrong though - the only way to find out is for you to test the same version of OtherDrops alone with the same configuration on a 1.5.x version of CraftBukkit. I should note, however, the error log is itself harmless. Error message or not, if there's a problem, the problem is the priority, not getting rid of the message.

And, that's some really thorough testing you did there. I appreciate that kind of effort - not many people are willing to do that before sending some type of bug report (whether as a comment or a ticket). And FYI, I never hang out on IRC (and never will), so commenting about any issues you have here can also be a viable way to get help. :)

@drexel_levante

Yes, your example should work fine - you can specify named mobs as the object (to distinguish it from generic mobs), and you can also specify named mobs within applicable parameters.

As for the "repair scroll" idea, no, it is not possible with OtherDrops. It's a good idea, but I think it would be a completely unnecessary feature to add to this plugin, because you would have to specify a list of every tool-like item for the repair scroll to look for, then somehow tell OtherDrops which tool-like item to repair. I don't really see the point in adding all this.

Two alternatives do exist though - both of which do not use OtherDrops. If, you have another plugin that offers a "/repair" command which repairs the tool in your hand (or a similar command), you can get a plugin like boosCooldowns to impose a fee on using that command - in your case, the fee would be the repair scroll.

The other, more awesome and less cumbersome solution is to use RecipeManager. Make sure you use the version of RecipeManager from @haveric's github fork (found in the comments) and not any of the official builds, because they're all out of date. Here, you can simply specify a recipe involving the repair scroll, and any tool-like item you want. Then, all you have to do, is specify a flag to repair the tool by whatever durability you want. (If you need help on how to do this, you can ask me here.)

@SuperiorCommander

NPCs are treated as players, so just specify the "PLAYER" entity, and its name - or in your case, the NPC name. So if you had an NPC named "Example Guard", just specify "PLAYER@Example Guard" as the object. And then specify the rest of the parameters (drops, etc.) as normal.

@dimasaurio

You have to be clearer in addressing what the problem is. I have no idea what your issue is, so I don't know what you need help in. So now, I'll have to infer it from reading your posted config. (Also, don't post your config as a picture; post it via PasteBin.)

You're using invalid item-names. For specifying item names, you have to use the names from Bukkit's material enum. Basically, when you specify names like "gold" or "sugarcane", and OtherDrops reads it, it won't have a clue what you're saying. To the plugin (and Bukkit), it's a bunch of gibberish, specifying names for items that don't even exist.

So for instance, instead of "gold" you have to specify "GOLD_INGOT". Even on the intuitive, human-reasoning level, specifying "gold" instead of something more specific does not make any sense, because you could be referring to "GOLD_NUGGET", "GOLD_ORE", "GOLD_BLOCK", or "GOLD_INGOT"; it's ambiguous.