Bukkit

@Faldonboy

Didn't know that - added it to the parameter page. Thanks.

@Stormbow

There's a strange bug revolving around using Prism/CoreProtect and OtherDrops at the same time. I've never experienced it myself (although, I'm using outdated versions of both), but I've heard that it interferes with Vault or something.

If you don't encounter any noticeable bugs with it, I'd say it would be safe to ignore - but if you do encounter issues, you might want to try using the latest dev build of OtherDrops. If that doesn't help either, you'd be better off asking other people, as I wouldn't be very helpful at that point.

@McPixel

I believe this has been a longstanding "bug", in that ZariusT never got around to implementing "&" colour codes in lores. You'll, unfortunately, have to do without them for now. Or maybe I'm overlooking something here, but I'm pretty sure lores won't take colour codes.

On the other hand, try using the section symbol instead of the ampersand to see if that'll work better.

@CommodoreAlpha

What he's doing SHOULD work though, money was changed to a parameter awhile back but the normal way was kept so people weren't forced to change all of their configurations so this is probably a bug.

Pulled this from the change log:

Add: money action - replaces drop: money@percentpenalty/5 etc. Now money: 5, -5, 5%, -5% etc. Supports money.victim, money.steal, etc. (per other actions, money.world, money.server & money.radius all supported if you need them).

@gepardo43

See this page.

Money is not a parameter, it is an object which can be dropped, like so: "drop: MONEY/100".

Also, for the purposes of styling, don't list your drops like that. You should keep all your drops in a single set of brackets. While it decreases readability a bit, it also decreases ambiguity for when you have multiple entries under the same object.

@Stormbow

A dependency is an external plugin that is hooked into by another plugin. For example, OtherDrops hooks into Vault as a dependency.

Do you happen to have Vault and CoreProtect running on your server?

@iSleepzZz

Put only the relevant portion of your config in "code format". Don't put your entire message in code format. What you're looking for is "drop: DENY".

"NOTHING" means that the default drops are overridden and replaced with "AIR" (in other words, no items drop). "DENY" means that the event is canceled, and acts as if nothing has ever happened.

@malius91

By the way, about your "LEAF_DECAY" issue, it might also be due to the new leaf-block types (acacia and dark oak) added in 1.7.

Phew, it's been awhile since I was on here.

@JaffaMiner

I couldn't have a look-through on RegenBlock's source code (even though its license mandates that it's open source; although, I didn't check the .jar) so I'm not exactly sure what RegenBlock is doing when it intercepts BlockBreak and BlockPlace events. What I'm guessing, is that because OtherDrops had to specifically support that plugin, RegenBlock probably uses some special kind of listener that's not compatible with OtherDrops' interception and modification of block-related events.

In other words, if RegenBlock were to rely only on the BlockBreakEvent and the BlockPlaceEvent, it would be compatible with OtherDrops (like any other plugin), but it's not, so something else is going on. Either OtherDrops will have to reevaluate its RegenBlock support, RegenBlock has to change something (not sure what), or the incompatibility will remain in place. Keep in mind, these are all my conjectures, and also keep in mind I've no knowledge of coding.

Now, the problem with either route is that ZariusT seems a bit busy (last login is 20 days), and the developer of RegenBlock seems a bit dead. So you might want to look for an alternative, or find a developer to do the patching for you.

In the mean time, I believe there could be substitute plugins... have you tried looking at MineResetLite? If you use a bit of creativity, you can replicate the effects of RegenBlock, but only to an extent. (If you want to know some examples of how you can do so, feel free to comment here, or PM me.)

@malius91

Your error looks harmless, but I'm not sure why it would be happening. If you look at the error, you'll see that it's clearly tied to the "LEAF_DECAY" event (after all, according to you, it only happens when you specify that even, because all your other config-examples, which don't have that event, don't cause the error). A few other things to note though.

Don't use "GENERIC", use "0". It's just better that way. Don't use integers (AKA magic values) when you can use names, because magic values on item IDs are going to be deprecated soon. Don't use "action:", use "trigger:", as "action:" is a deprecated parameter (still works, although I wouldn't use it).

My guess is that the error stems from bad config (i.e. using deprecated parameters), or the fact that you're using version 1.7 of CraftBukkit which the latest build of OtherDrops isn't built against. Although, the latter is unlikely; it may actually be a bug in all OtherDrops versions, regardless of CB version. Do try playing around with your config to see what you get.

@My_Name_Was_Stolen

No problem, although if any issues arise for you in the future, I'll be glad to help. Just know in strange cases like this, I'm not always that helpful, but I'll still try.

@drexel_levante

Do you happen to be running Spigot, or any plugin that would happen to automatically stack together exp orbs and items?

If not, it could be vanilla Minecraft doing that, but I don't know about that either. Does the Ender Dragon drop multiple exp orbs when you don't specify anything within OtherDrops? If it does (meaning the drops are spread in vanilla), and if specifying the amount of exp the Ender Dragon drops via OtherDrops breaks the "dropspread:" factor (meaning OtherDrops "unspreads" the drops), I might think the parameter may be broken (in that it doesn't work, not that it breaks anything else).

I've never used the parameter myself, so I'm not really sure about that. You might want to consider doing something like this to see if it will work:

    ENDER_DRAGON:
    - tool: ALL
      dropspread: true # by the way, don't put it in all caps
      drop: [XP/100, XP/100, XP/100, etc.]

@ZeEye

I'd like to point out an important aspect of Faldonboy's statement:

Quote from Faldonboy:

You should never use multiple same-name entries in a single YML file.

If you want to specify the same object multiple times, don't do it in a single drops file. So seeing as you want to sort things by feature, and not by object, make multiple drops files for that, with each file being a distinct "feature" or "category". That should work, and if it doesn't, I would suspect that it's a bug, either on OtherDrops' side, or your side.

@gepardo43

You haven't even specified any object. Specify the object, like so:

    ZOMBIE:
    - drop: MONEY/100-600/40%
      region: NameOfWorldGuardRegion

In this example, your object is "ZOMBIE". The parameter is "drop". The "drop" parameter contains one item: "MONEY", with a quantity of "100-600" with a "40%" chance of occurring. This entry has one condition: a region, whose name is "NameOfWorldGuardRegion".

On an interesting side note, zombies neither "want" or "don't want" to drop cash. They're just a bunch of code slapped together that follow procedures. The moment zombies in Minecraft gain consciousness and a will is when a robot-zombie apocalypse will happen.

@ZeEye

Yes, that is rather normal.

You should never use multiple same-name entries in a single YML file. It can cause confusion and cause things to break easily.

@malius91

Or, instead of overcomplicating it, you could just do something like this:

    GRASS:
    - tool: DIAMOND_SPADE@!SILK_TOUCH
      drop: {DIRT/1/50%, GRASS/1/50%}

If "loot_overrides_default" is set to "false", you're going to also have to cancel the vanilla drop through the following example:

    GRASS:
    - tool: DIAMOND_SPADE@!SILK_TOUCH
      drop: NOTHING
      drop: {DIRT/1/50%, GRASS/1/50%}

Your examples has a few issues, mostly style-related. The first entry you have is completely unnecessary, because that's assumed (after all, that's a vanilla mechanic, so you're telling the server to do what it always has done).

The second entry is only necessary if "loot_overrides_default" is false - otherwise it doesn't need to be there, as it's the equivalent of telling the plugin to do nothing. You could combine this entry with the third one, however (as I did above).

Generally, you shouldn't use "chance:" to specify the chance of drops happening, and you shouldn't use magic values either, as those are going to be deprecated. Use Bukkit material names instead of magic values, and use the "itemName/amount/chance%" format instead of a single drop with a chance parameter. The chance parameter should generally be used for specifying the chance of an entire event, hence why it's specified outside of a drop. And if you don't have to, don't use brackets. Only use them when specifying multiple objects.

@JaffaMiner

I'm terribly sorry, but could you remind me as to what your problem was again? With all the influx of questions I've lost track of what your issue was. I hope I'll be able to throw out a hypothesis or some kind of conjecture as to the nature of your issue so that it'll be easier to understand and troubleshoot.

@foshizzle4nizzle

It's open source (look at the license; if you see something like GPLv3, there's a good chance it's open source). That means you can submit a pull request, or fork it as you please, but I'm assuming (not that you will) plagiarism still isn't allowed, else there wouldn't need to be a license to begin with. :P

Generally, if you use someone else's code for private use, as you're going to do, it's fine to do whatever you want. But the moment your work, which is a derivative of the original work, enters a public space (e.g. the internet) for others to access, you need to give credit back by referencing the original author(s).

If you need help with the code itself, I can't help you; only ZariusT can. I don't know how to code at all, although I hope one day to learn like you. :)

@tremby90

Use "&x", with 'x' being some "hexadecimal" value corresponding to one of the chat formatting codes. See here for the list of colour codes.

@tremby90

This plugin is a tool. It's up to you, and solely your responsibility how it gets used, what exploits it has and doesn't have, and any other consequences that stem from your configuration. If you're smart, you would find a creative way to fix any duping/exploitation issues created by your configuration + this plugin. If you need advice on good configurations, you can always ask me, but again, any problems that aren't bugs are solely your responsibility.

@McPixel

I'm not too familiar with horse spawning. First off, it's not "EntityHorse", it's "Horse". Correct me if I'm wrong though.

Second off, I think horses use NBT tags rather than damage values to determine certain attributes. Correct me if I'm wrong on this too. Seeing as OtherDrops doesn't currently support NBT tags on its own, you'll need to a third-party plugin to spawn in such horses. Either use a user-friendly spawning plugin like Essentials, or if you like to get dirty, find an NBT-editing plugin like PowerNBT, which literally let you do anything possible with NBT tags.

@My_Name_Was_Stolen

Have you tried experimenting with all kinds of drops? (e.g. not using just cobble, or the "drops:" parameter, but other things like "message:" and creepers) I'm sorry if I'm not very helpful at the moment, but I'm kind of bogged down on other stuff I have going on in my life.

I would agree that it's a very strange issue. Have you tried using different versions of OtherDrops? I would try the latest build on this (dev.bukkit) page, then the latest build from the Continuous Integration server. If neither work, I'm really out of ideas.

The issue is that only you have this problem - I'm not pointing fingers or saying it's your fault. What I'm saying, is that if it were a legitimate issue with OtherDrops itself, I'd be having many more complaints, each with the common idea of "Help, this isn't working!" But that's not the case, and so I suspect it might have something specifically to do with your situation. Random question, but do you happen to be using Spigot or some other CraftBukkit derivative?

@Ymerejliaf

A small problem with suggesting Essentials, as a way to spawn horses, is that if McPixel doesn't already have it, it would basically mean installing a heavyweight plugin for one small feature. If McPixel already has it, then that's great. Otherwise, I would recommend another plugin (and I can't think of any off the top of my head, although MyHorse comes to mind).

@McPixel

Making an item drop at a player's location, instead of where the event happened, seems pretty pointless. I also don't think it's currently possible, but again, I don't see the point of dropping an item at the player's location when you can just put it directly into their inventory. (You could make the argument that the item won't appear if their inventory is full, but I think that's a negligible case.)

You could, instead, just have OtherDrops run a command (provided by another plugin) to "/give <item>" to a player when the player triggers an event.