Bukkit

@asacavanagh

Since other skulls don't actually exist you would have to find a player that has the same skin as the mob you want and use his name.

Other plugins such as Craftbook have their own built in skull drops for every mob and you can change the drop chance too. That might be easier then trying to have OtherDrops handle it.

@ZeEye

@CommodoreAlpha

Section symbol and ampersands both work but they each only work in certain file encoding. Try changing it from 1252(ANSI) to UTF-8 and see if it works. (I use 1252 and use ampersands personally).

So the crops thing is an interesting problem, it's not really a bug its just how MC and Bukkit handle things. I'm not sure if this will fix it(And your players might find it annoying if it does work) but you can try making it so that crops only drop things when broken with a specific tool(like a hoe, might as well give it a real use). Failing that, try making the block the crops are planted on not drop anything. I believe the block is called "FARMLAND" but double check that with the /od id command.

@deleted_8741347

Instead of using messages, have you tried using drops to test it? If the outcome for drops remains the same - that both drops occur regardless of the type of zombie - then there's probably something wrong.

But if both messages occur, but only the correct drop occurs, there might be another factor at play. I can only conjecture so much as to the nature of these types of issues, so it would help if you could reply back to this comment.

Have you tried using negations? For instance, instead of "spawnedby: SPAWNER", you could try "spawnedby: [SPAWNER, -NATURAL]".

@ZeEye

I'm glad you told me that the section symbol doesn't work - now I can probably add a warning in the documentation not to use it in place of ampersands. I would say colour codes in lores should work, but for some reason they aren't, and so I would normally think it's a bug. I do believe @Faldonboy, at some point, said that they worked for him, but my memory isn't that great these days. You could try asking him about this.

As for the second issue, it's because there's more than one way to remove a block. Breaking a block with your hands invokes the "BlockBreakEvent". OtherDrops reads for the "BlockBreakEvent" and modifies the drops based off of this. I'm assuming explosions pass the same, or a similar event that OtherDrops also reads for. It's somewhere in the javadocs on Bukkit, but I'm too lazy to look right now.

When a water flows "into" a block (or more accurate, displaces affected blocks with itself), that invokes the "BlockFromToEvent". The natural default on conditional parameters is that drops will only occur via "tool: BREAK" - that is, blocks destroyed via "BlockBreakEvent". You also need to specify blocks damaged by water, which would be "tool: DAMAGE_WATER".

As for breaking farmland blocks under wheat crops to get the vanilla drops, I don't know the name of this particular event, or if it's an event at all (that's passed through Bukkit). The thing is, when a "CROPS" block "breaks" after removing the soil underneath, it's not actually breaking - thus, it's not a "BlockBreakEvent". What happens is that breaking the farmland block updates the state of all blocks adjacent to it. Because vanilla Minecraft (in this case, your server) realises the "CROPS" block is actually "unsupported", it updates the block to become "AIR" (to destroy itself) and drop whatever items that vanilla mechanics mandate.

On a side note, if your server's integrity is pivotal on a few select features/mechanics, you might want to rethink how you're approaching the entirety of your server's design. I've had some rather unsavoury moments concerning problems like these myself. Instead of relying on one feature to make farming a difficult process, you could try a bundle of methods packed together. In short, there's always more than one way to solve a problem.

@CommodoreAlpha

I'm not sure that I've ever tried to use ranged data values, however I get that warning with a lot of other things, it's usually harmless and whatever is giving the warning is still working the way it's supposed to so I'd double check it to make sure it really isn't working.

It should only be "@" using "/" had some kind of problem before in yaml configurations.

@Faldonboy

Does using ranged data values on items work for you? For some reason, I get an "error" in my console whenever I try to specify something like "COCOA@0-3", saying that it's illegal data. I'm pretty sure it's correct though, as it's consistent with the documentation. Perhaps I'm just doing something wrong or using something deprecated.

Also, should specifying something like: "event: EXPLOSION/2/NOBREAK" work? For me, it doesn't work, but when I use "@" instead of "/" it works. I'm asking, because I'm wondering if I should label the use of "/" within such parameters as deprecated and non-functional.

@ghr4

You have to specify the item's data-value. For example, "WOOL@1" would be orange wool. "WOOL" would be all types of wool. "WOOL@2" would be yet another colour of wool. To specify data-values on an item, just add "@<integer>" after the item's material name.

I'm not sure if using names instead of numbers work, but it wouldn't hurt to try - for example, "STAINED_CLAY@PINK" or "STAINED_CLAY@ORANGE".

@PratamaJr

Telling me it doesn't work, then offering sparse information won't allow me to help you. So I can only tell you to figure it out on your own 'till you offer me more information.

@ZeEye

"Is it possible to distinguish between sunlight and normal light?" Short answer is no, because there's no such thing as sunlight. That's not a game mechanic to my knowledge.

When something is under direct sunlight, that's just a "concurrent condition", where two conditions are met:

1. There are no opaque blocks between the reference block and the maximum y-level.
2. The reference block is indeed receiving light (or has a light level that is above 0). Although I don't know if this is an actual condition. (Glass doesn't reduce light levels by the way; if something is truly transparent - or non-opaque - they don't reduce light that passes through.)

For your colour-coding issue, try using section symbols instead of ampersands to see if that'll work. I believe colour-coding should work in item-lore, but for some reason, many people complain it doesn't, and none have reported back to tell me if using section symbols instead works (it should).

@highfaller

Use damage values. That's how I prevent all possible instances of "break-and-place" dupes on my server. (It's also how, unlike other plugins, I can use the looting enchantment to drop multiple ores without worrying about duplication.)

You might also want to consider using Item Renamer (requires ProtocolLib) to be able to distinguish between the same items with different damage values better, which can be handy.

Here's an example of what I'm talking about:

    DIAMOND_BLOCK@0:
    - drop: DIAMOND_BLOCK@1/4
    DIAMOND_BLOCK@1:
    - drop: THIS

If that doesn't work, make sure that the drop is occurring correctly; as in, "DIAMOND_BLOCK@1" drops, and not just plain "DIAMOND_BLOCK@0". If only "DIAMOND_BLOCK@0" drops no matter what you try, it may be a vanilla mechanic restriction.

Anyhow, if you have any questions, feel free to ask. :)

@Faldonboy

Thanks for correcting me. ;)