Bukkit

@ImmortalOverlord

I already made a ticket concerning your question a few months back.

Getting the contents of a zombie to drop is handled by vanilla Minecraft, so you might have to specify "DEFAULT" in addition to whatever drops you have. Or make sure that the drops you specify don't override vanilla drop handling. Or something along those lines.

On the whole "inedible renamed food" issue, you might want to send a request to the developer of that plugin. Just seems like the easiest way out of your situation.

@ImmortalOverlord

I don't know actually.

Have you tried something like "BREAD~;<lore>" or "BREAD;<lore>"? Or perhaps you could do "BREAD~Bread;<lore>"?

Also, a plugin that prevents you from eating renamed food? Sounds like a badly designed plugin. Just because a food is renamed doesn't mean it should be inedible. o_O

@McPixel

Is what possible? What is "that" you're referring to? (What is your antecedent?)

Custom mob names are possible; just specify the name like so: "ZOMBIEName". Mobs that are added via mods are a different story. OtherDrops is only built against Bukkit, not MCPC+ or any other platform, so chances are, it won't have any support for mod-mobs.

Plugins built against Bukkit's enum can support mod-mobs in general, but they cannot support any specific type of mod-mob unless they're within Bukkit's enum too. (So, it would require some porting and such.) Unless MCPC+ somehow does this automatically for you, I'm not too sure.

@iGamingStudioX

That didn't really answer my question when I said "define special abilities". I asked, because I don't know what abilities MythicDrops adds. I did a quick glance through of the plugin, and being unfamiliar with it, I'll assume it just lets you apply potion effects. So in that scenario, yes, OtherDrops lets you do what MythicDrops does - apply potion effects to either attacker or victim.

For your integration ideas, I've mixed feelings about it. I honestly don't think it's needed/worth it, but it's up to @ZariusT to decide, not me. I would suggest making a ticket. It's a good thing to have, but I can think of a workaround to achieve your request which doesn't require the hassle of plugin-integration.

Whenever you level up some skill/class to some "number/type", have a plugin (the RPG plugin or another plugin) give the player a permission node you desire. Then, have OtherDrops act based on the assigned permission node. For example, if you level up woodcutting to 50, a plugin can give the permission node "otherdrops.custom.50wc", and you can specify something like this in OtherDrops:

    LOG@3:
    - permission: -50wc
      drop: DENY # can't chop down jungle logs without the permission node
    - permission: 50wc
      drop: LOG@3

Once you hit level 50 woodcutting, you get a permission node that lets you chop down jungle logs, essentially replicating the effect. Now, the only caveat is to make sure the same plugin that gives out permissions nodes takes them away if the player no longer meets the condition.

My concern with integration is that it would require extra work every update just to keep up with the other plugins updating, but I could be wrong.

@JaffaMiner

There's no such thing as an "OtherDrops block". Blocks are blocks, and OtherDrops just acts upon those blocks depending on your configuration.

Yes, there's a parameter for it, and I'm guessing it might involve "replacementblock:" and perhaps "delay:". But if you don't have that specified anywhere in your configuration, it's probably a bug. A bug I've never heard or seen before, so I have little reason to think it's a bug in this scenario.

@ImmortalOverlord

What do you mean by the custom drop name issue? For a bit of reference, here's this handy page.

@ImmortalOverlord

Ah, what an ingenious solution. :)

And on messaging the player, no idea. You're right in that it's not currently possible - I wouldn't bet on it being possible anytime in the future either, simply because it would be too infeasible to make possible. (The plugin would have to do quite a bit of tracking, somewhat like block-loggers do, which would cause it to consume a lot of CPU power.)

On second thought, however, maybe not so infeasible to add. I made a ticket that might be within the ballpark of your request. Although, I'm not going to expect it to be considered any time soon.

@ImmortalOverlord

My theory is that the server sees the zombie as dying for a reason not listed within your configuration (burning, explosion, etc.) - or that something in your configuration isn't being read.

Just for the heck of it, try making your list just include the following four items: "PROJECTILE_ARROW, ANY_EXPLOSION, DAMAGE_BLOCK_EXPLOSION, DAMAGE_ENTITY_EXPLOSION" and test to see if it works.

@iGamingStudioX

Define "special abilities". You can do basic stuff like potion effects and creating explosions. If you mean anything specific and/or intricate, like shooting fireballs at your whim, the answer might be "no" or "not possible yet".

What do you mean by integration with mcMMO and AncientRPG? Integrate how? Bear in mind, depending on if a plugin is version-dependent, adding hooks into "x" plugin could be an unnecessary hassle. It really depends on the circumstance though.

@ImmortalOverlord

Oh, whoops. Read the "STICKS" as a drop, didn't think of it as a message. :P

Have you tried specifying the tool as "ANY_DAMAGE" for the entry including the "sticks" drop? If that doesn't work (as in, the zombie doesn't trigger the stick-event on any dying circumstance) then this is probably a bug, either due to plugin conflicts (which I think is unlikely) or OtherDrops (which is probably more likely).

If using "ANY_DAMAGE" does fix the issue, then there's probably some strange configuration quirk going on.

On a side note, if you use "DAMAGE_BURN", there's probably no reason to include "FIRE", "FIRE_TICK", and "DAMAGE_FIRE" on the list. I'm also unsure as to whether the plugin can understand "FIRE" and "FIRE_TICK" as valid reasons for damage, but I think they could be aliases within OtherDrops, or valid names within Bukkit. I'd check the javadocs right now... but my laziness is inhibiting me.

@ImmortalOverlord

Perhaps the explosion itself is destroying the item? Beyond that, I'm not too sure.

Try increasing the offset, and decreasing the explosion size to 0. If the item still doesn't drop, there's either a configuration error, or a plugin bug. If the item does drop, it's probably the explosion itself destroying the item.

If that is indeed true, you'll have to delay the drop so that the item drops after the explosion has passed (so it won't be destroyed). See "delay: <ticks>" under parameters.

To my knowledge, I can't think of a way to make items explosion-proof due to vanilla limitations. I'm pretty sure that it would be possible to respawn an item destroyed by an explosion via a plugin... but that's too much unneeded work as opposed to delaying the drop.

@mal67

I'm not sure what could have caused it either, but I'm definitely sure it has to do with some sort of interaction with a block. Not very helpful though; ZariusT could respond with a better answer. The reason why I suspect it's some sort of block interaction is because "BlockIterator" is mentioned in the error.

Most OtherDrops-related errors are/should be pretty harmless - the worst that usually happens is that a piece of your configuration doesn't work, but not much else.

@ZariusT

Thanks! :)