Bukkit

@ZeEye

For your first part, I don't know if it's currently possible to do so - if not, it would be a great idea to make a ticket for.

I don't know if it's possible to specify a drop-group as a drop, but if it is, it would be possible to achieve this idea. You would need to test if this is true, though. Consider this:

    ZOMBIE:
    - dropgroup: exampledropgroup
      chance: 0%
      drops:
          - command: /etc arguments
    - drop: {exampledropgroup/1/20%, item/1-3/10%}

Here, a drop group is being treated as an item, hence treating a list like curly braces around a list of items. I don't know if this works, though. If it doesn't please make a ticket with a request for the feature in such a way that dropgroups can be treated as drops themselves. If it somehow does work, though, then great, that's your solution. :)

As for potion effects applying to a radius around the victim rather than the attacker, I don't think it's currently implemented. Again, make a ticket for that. I do believe the "potioneffects:" parameter currently supports applying a radius, but only around the attacker (or do-er) rather than the victim (or receiver). If you're curious on how to apply a radius to the attacker, just specify the ".radius" extension, and add an extra "@<integer>" onto the arguments, and it should work out.

@KnifePlay

Here is a very helpful page outlining most, if not all the parameters currently available in OtherDrops. The "world:" parameter should be able to help you out there.

@iPerki

That's not intended behaviour, because your configuration looks fine. Could you set your "verbose" level to "extreme" and pastebin your log to me? Perhaps that'll help me get to the bottom of this. Also, remember to space your lines correctly. Your "ANY_CREATURE" line has no spaces, and your other lines have eight, for some reason.

Also, your config has a lot of redundancies which should be eliminated. I've taken the liberty of "cleaning it up":

    ANY_CREATURE:
      - tool: DIAMOND_SWORD@!LOOT_BONUS_MOBS#1
        drop: MONEY/5-10
        message: "got $%q"
      - tool: DIAMOND_SWORD@!LOOT_BONUS_MOBS#2
        drop: MONEY/10-15
        message: "got $%q"
      - tool: DIAMOND_SWORD@!LOOT_BONUS_MOBS#3
        drop: MONEY/150-200
        message: "got $%q"

@Alsiokowsky

This page could be helpful. The general format is this: "Object~Name", where the object can be a block, item, or mob.

@Mal2ksc

I can't find them myself (not in the changelog; I've yet to sift through the code), but you could try experimenting what the slots are. Try "body" or "chest" or "top" for the top armour, "legs" or something like that for the bottom armour, and "feet" for the boots. If those don't work, I don't know what will, but Faldonboy/ZariusT will probably know.

On a side note, if you find out (or if someone answers), I'll be sure to document it right away and link you to it for future reference.

@ZeEye

The "lorename" parameter was never intended as a condition for objects, only tools; you have to use "ITEM~Name" to specify that a certain object must have "x" name for "y" effect to occur.

The way OtherDrops reads your config is something like this: It sees the block "CHEST", but there's no name required for it, so the effects you specified apply to all chests. It then sees the "lorename:" parameter, but there's no "tool:" specified, so you're basically requiring that the nonexistent tool should be named whatever name you set it to in order for whatever effect you have specified to happen.

Now, what you want to do to "fix" your config is something like this. Take all the "lorename: <name>" lines, and move them to their respective "CHEST~Name:" entries. It should work after that.

As for outcomes and chances, see Drop Groups; it lets you have what is essentially "drops within drops". It's actually a pretty powerful concepts. Alternatively, you can use the "flag: UNIQUE" parameter to specify that the events of each entry are disjoint.

@deleted_11934140

If this were a problem, we would be getting a ton of complaints. My guess? A plugin conflict. Some other plugin is interfering with damage/death events being fired, and OtherDrops is caught in the crossfire.

Quote from Breymja:

The damage only gets registered once.

According to your log, twice:

[OtherDrops:2.8b.582] OnEntityDamage (victim: CraftPig)
[OtherDrops:2.8b.582] Damager: CraftArrow
[OtherDrops:2.8b.582] PerformDrop (HIT, CREATURE_PIG@!UNSADDLED!ADULT!!!!ItemStack{AIR x 1}%10.0%!!ItemStack{AIR x 1}%10.0%!!ItemStack{AIR x 1}%10.0%!!ItemStack{AIR x 1}%10.0%!!ItemStack{AIR x 1}%10.0%%10.0h w/ PROJECTILE_ARROW@PLAYER) no potential drops found
[OtherDrops:2.8b.582] OnEntityDamage (victim: CraftPig)
[OtherDrops:2.8b.582] Damager: CraftArrow
[OtherDrops:2.8b.582] PerformDrop (HIT, CREATURE_PIG@!UNSADDLED!ADULT!!!!ItemStack{AIR x 1}%10.0%!!ItemStack{AIR x 1}%10.0%!!ItemStack{AIR x 1}%10.0%!!ItemStack{AIR x 1}%10.0%!!ItemStack{AIR x 1}%10.0%%10.0h w/ PROJECTILE_ARROW@PLAYER) no potential drops found

Also, the plugin shouldn't need to support Towny specifically as it should naturally be compatible with all plugins that come with region protection. Else, people would be asking for WG support, Residence support, etc., but we haven't gotten any requests like that recently. Towny is probably doing something weird in how it protects regions compared to other protection plugins, but I don't really know. A better question you could have asked would have been, "Could you support protection plugins?" or "Why doesn't OtherDrops adhere to protection plugins canceling the BlockBreakEvent?" rather than "Could you support 'x' plugin (as opposed to any other plugin)?" When it comes to support for any number of plugins that do similar things, I would like OtherDrops to remain agnostic on that fact.

@BMWBrandon

Don't feel stupid. That's why we're here. :) (Also, I'm never on IRC, and never will be.)

Could you pastebin your otherdrops-config and all relevant drops files so I can look through them? If, for some reason, you cannot disclose it here in the comments, feel free to shoot me a PM, or even email me.

Judging from your description, that is definitely not intended behaviour, but I can't really make a diagnosis for your issue because I don't have much to go off of. Have you tried setting the zombies/zombie-pigmen to drop only "AIR" or "DIRT" with the override-loot option set to true?

@hagiel120

I don't quite understand. What's "that thing"?

If you want a drop to occur as a result of having a certain exp level, that's not currently possible, but I believe I've already made a ticket about it.

@ZariusT

I saw an API include extra events for the changing of "day" to "night" and so forth. Don't remember the name of the plugin, but the developer's name was "coldandtired" or something. Perhaps you could just have something similar, where OtherDrops sees passing the "nth" tick of the day as passing from one phase to another, like dusk to dawn.

@ecksfiftyone

I sadly turned down someone else who had a very similar idea a few comments ago (while saying it was infeasible to add, but I now take that back). Then ZariusT did bring up a potential idea that he would implement in the future that might make such an "event" possible. Basically, the idea is to have the ability to turn on and off certain drops files for whatever duration under whatever conditions, so that should technically make events and thus your idea possible. In the future.

As of now, no, not possible.

As for the reaper, you'll have to give it some sort of data that OtherDrops can read as a condition in order for it to distinguish between just that special mob, and all skeletons. What do I mean by "readable data"? In this case, you'll either have to change the Reaper's health, name, or both, then make a separate OtherDrops entry just for that special skeleton, based on the health/name you changed it to.

An example, depicting what you wanted, might look like this:

    SKELETON:
    - trigger: MOBSPAWN
      spawnedby: NATURAL
      drop: [NOTHING, SKELETON@eq:head:PUMPKIN!!eq:hands:GOLD_HOE@25h~Reaper]
      chance: 5%
    SKELETON@25h~Reaper:
    - trigger: MOBSPAWN
      potioneffects: INVISIBILITY@999999@1

It might work, but I'm not experienced with how to put equipment on mobs via OtherDrops. The format is very messy for that.

To pick out a quote from the changelog, which I ought to document soon, here's the "explanation":

Quote from Changelog:

Skeleton: test version of equipment config (allows for setting all armour slots and holding, any item including datavalues and enchantments) - format is SKELETON@eq:<slot>:<material>@<data>\!<enchantment>#<ench level><<dropchance>!!<next slot....>. Yes, there is a "<" character before the dropchance and you do need "!!" rather than "!" as the main separator and "\!" as the separator before any enchantments - couldn't process the config properly any easier way. Here's an example:

@alanthya

Work how? If you want to specify an NPC as an object, just do "PLAYER@<NPCname>". The reason you can do this is because NPCs are treated as players. Just watch out not to have an NPC named after a real player that plays on your server, else something funny could happen to the real player.