Bukkit

@Kofeyy

Concerning aliases, a good situation to use them (instead of long-hand) is in cases where it is both time-saving and self-documenting. In other words, giving an intuitive "name" to a group of "things" that are all related. If not all items in the group of "things" are related (i.e. they are not all tools, but are a bunch of different parameters), it is not good practice.

For example, assigning a whole blob of parameters to environNoDrop is not a good idea (unless you have excellent memory) because you have no idea how each parameter will factor in when you apply the alias to whatever object. Calling a whole bunch of "death-reasons" (AKA tools) "EnvironmentallyCaused" is a good idea, because it's immediately clear what EnvironmentallyCaused is referring to, and thus immediately clear what effects it will have.

@sakura_blades

Sorry about the delay on documentation, but I'll begin working on it tomorrow.

Naming/putting data values on entities should work similarly to items. Here's an example that should work:

    ZOMBIE:
      - trigger: MOB_SPAWN
        drop: [NOTHING, ZOMBIE@5h~ExampleName]
    ZOMBIE@5h~ExampleName:
      - drop: [NOTHING, DIRT] # to make sure that this zombie is the same one as above

Here, the zombie should spawn with the name, "ExampleName", and should have 5 points of health. (Making it easier to kill, which makes it easier to test.)

How to equip mobs can be found at the bottom of this page. If you've any more questions, feel free to ask.

@Kofeyy

Oh shoot, forgot to reply to this sooner!

So, aliases can be a good, convenient thing, and aliases can be self-documenting, but the reason I don't use aliases (yes, I do everything the long way) is because I need to see exactly what everything is doing. Your issue was actually very difficult for me to decipher because you used aliases. (That doesn't mean you should stop using them, but you should take more caution around them.)

Here is the issue I think you are having. "Custom-health skeletons" have the alias, "environnodrop" attached to them. If you look at what this alias consists in, you'll see that it involves only mobs spawned by "SPAWNER". Now, according to your config, where do these "custom-health skeletons" come from? From OtherDrops, because you're intercepting spawner-mobspawn events. Therefore, if you what environNoDrop to work on these custom-spawned mobs (and not spawner-spawned mobs), you'll have to add in the spawnreason, "CUSTOM" in addition to "SPAWNER".

@ShadowKillerx

Do you know what the plugin does? :)

But yes, you can:

    STONE:
      - drop: NOTHING # removes all drops from breaking STONE blocks

@NanoEdit

You might want to use this: <<code yaml>><</code>> to display whatever configurations you may have. Anyway, here's a quote from the page on how to configure drops (yes, I know the documentation is currently obscure, sorry about that):

Quote:

An Important Note: If you want to specify colour coding within lore, there is a current bug where ampersands (&) are not read. You must use the section symbol (§) in place of the ampersand, AND you must use UTF-8 encoding, NOT ANSI encoding (which is usually the default).

I've noticed a few tidbits from the changelog (while at a boring convention) that haven't been documented yet. And I do realise I should've moved a lot of stuff to the wiki a long time ago. I'll begin working on documentation beginning of next week, then because I have to fly elsewhere later in the week, I'll probably "finish" my work by mid-July.

Small, undocumented facts from the changelog, include, but are limited to (I'm commenting it here, because I'm lazy and want to keep a list here):

• Multiple option placeholders (eg. "+<36> <mace|sword|dagger> of <lightning|fire>" -> +4 mace of fire). I'm not sure how the numbers work; how does <36> translate into 4? But probably a great feature for RPG servers using lore-based effects.
• Fix: allow entitydamage events to work for damage other than by entity (eg. environmental damage). What does this mean? Is there some condition-parameter I've yet to see?
• Fix: allow simple data to range without "RANGE" ala CROPS@0-6. So, does this imply there is a parameter called "range:"?
• Short-form drops & money, eg. ZOMBIE: [egg] (for drops) or SKELETON: 3-7 (for money).
• Add: support for "ZOMBIE" meaning any zombie with no customname, and "ZOMBIE*" meaning a zombie with any customname (except blank).
• "explosion@player" specifies the explosion to be generated at the player's position. Awesome, now I can finally be a terrorist!
• Add: sound action now supports range for volume and pitch & {sound1, sound2, etc} format. Only basic { } support with equal chance of any value being selected example: "sound: {anvilbreak/0.81p/0.9v, catmeow}" So basically, choosing from multiple sounds and having ranges for volume/pitch.
• particleeffects: effect@speed@count
• "adjacent" condition-parameter; not yet functional, but worth a mention so we don't forget to document it later on.
• Skull@%v drops the victim's head.
• "enderman@carry" and "enderman@nocarry"
• Could be important to mention, but what does "Fix: drop: DENY now correctly removes player inventory" mean? Don't drop the victim's inventory when you kill them? Erase their inventory when you kill them?
• It might be worthy to mention that you can specify colours on leather armour, and that hex-colour-numbers will be implemented in the future.
• Even though enchanted books are enchanted in the same way as weapons, it might also be worthy to mention that you can specify enchantments on them in the exact same way. Maybe this is too obvious.
• Written book support - /odd writtenbook@author=me:title=Snail:page=Once there was a:page=snail.
• Support creatures riding creatures (passenger^ride) - eg. cow^bat = cow riding a bat. Supports entities, eg. entity_boat^bat
• Ocelot "baby" status and make config easier/more resilient (can be OCELOT@RED!TAME!BABY or @WILD!BLACK, etc). Config is OCELOT@<type>!<wild or tame>!<baby - optional> order of type/wild/baby doesn't matter. On an irrelevant note, villagers in 1.8 will have "professions within professions".
• For the clueless, a nice little warning not to have recursive drops.
• The entity list could be updated and ported to the wiki, but that comes last.
• The name of entities that are objects, like paintings, item-frames, boats, and all the different kinds of minecarts. Couldn't find it in the docs, or my 30 seconds of searching wasn't enough.

Just FYI, if something has actually already been documented, then just ignore the point, but I'm not asking these questions to myself. ;) (Pokes @Faldonboy & @ZariusT)

@cilioo

What do you mean by a "natural spawner"? Natural spawn reasons? And when you say "spawn at day", I assume you mean "spawn with at higher light levels".

There's no clean way to do it with OtherDrops alone, because OtherDrops consists mostly of intercepting other actions and events. If a mob doesn't spawn in daylight, it passes no event (because it's a vanilla mechanic, so it didn't need to pass anything to begin with). It doesn't "spawn then despawn" or anything like that, so OtherDrops really has very little to work with, in this aspect.

When it comes to mobs, the most OtherDrops can do is replace a mob-spawning event with whatever you specify, but no such events are passed for the spawning of hostile mobs during daytime (besides in already dark places like caves). You could intercept mobs that spawn during daytime, but in dark caves, and offset their spawn so that they spawn elsewhere, but this can be very unpredictable (and is anything but a satisfactory solution).

@Argagaes

    ZOMBIE@20h:
        - dropgroup: zombies
          trigger: MOBSPAWN
          spawnedby: -CUSTOM
          flag: UNIQUE
          drops: 
              - drop: ZOMBIE@eq:head:pumpkin~insertnamehere
                flag: UNIQUE
                chance: 0.05

@CommodoreAlpha

The name ALWAYS goes last(or should, there might be a few instances where it wouldn't)

@Argagaes

Yep, you're right. Like I said, giving out suggestions at 3am in the morning, I'm bound to make mistakes. ;)

5/10000 = .0005 = .05%

The problem I'm having is that I know how to give mobs equips, and I know how to give mobs names, but I don't know how to do both. For instance, giving a zombie a pumpkin hat alone would (or should) look like this:

ZOMBIE@eq:head:PUMPKIN

And giving a zombie a name would look like this:

ZOMBIE~InsertNameHere

But I'm not quite familiar with how to put the two together (as in, what order they come in), which is why I'm not being very helpful right now. At this point, I may have to redirect you to @Faldonboy, if he knows how to do this. On a side note, if you or him figure out a way to do that, I'll make sure to update the documentation with the correct information.

@Argagaes

Oh, silly me! I forgot a really important line: "trigger: MOB_SPAWN" You should add that to whatever configuration you have. Also, instead of "DENY" you should have "NOTHING". Giving suggestions at 3am in the morning, I'm bound to make mistakes. ;)

The error was probably because somewhere in there, my format was invalid. Try using "ZOMBIE@eq:head:PUMPKIN!InsertNameHere" instead. If that doesn't work, I'm out of ideas, and you'll have to play around with it yourself. If you get something that works, feel free to comment back so I can improve the documentation.

@Q2Lummox

The problem seems to be quite simple. You have "ZOMBIE 1-2". That space won't parse correctly of course (there's absolutely no reason why OtherDrops should interpret that space correctly). Try "ZOMBIE/1-2" instead.

On another note, the spacing of your example is incorrect. They should be in multiples of four, not what you currently have:

ZOMBIE: # 0 spaces
   - Action: MOBSPAWN # 3+2 spaces
     drop: ZOMBIE 1-2 # 5 spaces
     time: DAY # 5 spaces

@Kofeyy

Your suggestions, while helpful and interesting, could be nuanced a bit more. ;)

For example, the issue with using block placement and block breaking is that, well, if I never do those things to begin with, I can walk around the day, zombie-free. Using a radius, however, is a good idea. Also, there are plugins out there which disable burning-in-daylight on zombies, but whether he wants another plugin is up to him. It would be slightly strange if all daylight zombies were helmet zombies, and all night zombies were normal zombies.

This is an example that might suit him (taking your helmet idea into account; also with appropriate spacing):

    ZOMBIE:
      - trigger: MOB_SPAWN # action: is the deprecated alias
        time: DAY
        drop: [NOTHING, ZOMBIE@eq:head:LEATHER_HELMET/1-2] # cancel original zombie and drop 1-2 hat-zombies
        loc-randomise: 16/0/16 # spawn a chunk's distance away, no y-alteration

The problem here is that zombies could probably spawn within solid objects. I've never tested that parameter before (loc-randomise) so I wouldn't know. But it does work better than the original example.

If one wanted all the spawned zombies to actually do something (that is, spawn near the player) to give the feeling of a higher difficulty, here's an alternative one could use:

    ANY_BLOCK: # Should be whatever block you can think of; using every block not recommended
      - trigger: PLAYER_MOVE # Warning, not to be overused
        time: DAY
        drop: ZOMBIE@eq:head:LEATHER_HELMET/1/.5% # every 200 steps = 1 zombie
        loc-offset: 0/2/0 # Zombies will spawn within the ground because that's where the event occurred; tp them 2 blocks up to prevent conflicts
        loc-randomise: 16/0/16 # The trigger will have occurred at the player's feet-location, so this essentially acts as the radius within which they can spawn

This way, if you walk during the day, you'll be sure to encounter a zombie - and rarely a zombie who spawns right in front of you! Great if you're evil and you're running a hardcore server.

Also, when you tag a mob with a nametag, it also edits the mob's NBT data and sets the "despawnable" parameter to false. OtherDrops cannot edit such NBT tags, you'll have to look for another plugin to do that.