Bukkit

@mrretrus

For IDs, you can either use the name or the number. All parameters take whatever value is considered valid, and because the number and the name are just two different names for the same value, they're both equally valid. Or should be equally valid. If one doesn't work, try the other; if both don't work, then that's another problem entirely.

@mrretrus

I'm actually not sure. One of my mods adds a couple of potion effects, but when I use the native Minecraft command to give myself a potion effect with the correct ID number, it fails to recognise the ID number. This suggests there's a problem with the server-platform in that Bukkit isn't registering everything Forge imports.

OtherDrops probably does support the use of ID numbers - names from the enum, I'm not quite as sure. If you're able to use IDs for items but not for things like mobs, biomes, enchants, etc., it would suggest that the problem lies somewhere within Cauldron.

@To everyone who uses a Cauldron server and would like to know what the heck modded stuffed are named (including but not limited to items, potion effects, enchantments, biomes, mobs, etc.)

This is quite a strange suggestion, but trust me on this. There is a plugin called RecipeManager. Now you might be wondering, "but I thought you were guiding us on how find documentation for our mods, we don't want a recipe-changing plugin!"

Well, it is a recipe-changing plugin, but it also has the ability to list all this stuff for you! Download RecipeManager, run it on your server with all the mods installed on it. Go to your RecipeManager folder (in your plugins folder), and open up a file called "name index.html". You will find pretty much all the names there. However, I'd like to warn that this plugin documents numerical IDs according to your server.

Now, if you use the technical name of anything in any other plugin, and that other plugin doesn't recognise it, it's because that other plugin only specifically supports vanilla and does not read the enum.

@mrretrus

Numerical IDs will be deprecated in the future, although I'm sure you already know that. The problem is that to my knowledge with other things like items, numerical IDs are handled dynamically, so you might just want to figure out what the biome enum is.

@delsolsi213

Yes, it's possible, but I'm rusty. Try testing this to see if it works; if not, you can play with it to see if you can get something to work.

  ANYBLOCK:
    - drop: [STONE_AXE@!DAMAGE_ALL#4!FIRE_ASPECT#2~&9Test Axe;§eThis is line one;§eAnd this is the second line/1/80%]
      world: WorldNameHere

This should translate into an 80% chance of any block within "WorldNameHere" dropping a stone axe with Sharpness IV and Fire Aspect II. The stone axe's name will be "Test Axe" with the &9 colour code, whereas the first lore line will be "This is line one" in yellow followed by another lore line with "And this is the second line" in yellow.

I set the chance high so you'll have an easy time confirming if it works or not. Remember to change the worldname too. Last but not least, an important note from the "Drops" page:

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).

@delsolsi213

Short answer: no.

A chest is a tile entity. A tile entity can be thought of as a block that contains specific data, such as what kinds of items are inside, what text it has, etc. OtherDrops does not support tile entity data (as you can tell, it would be rather complicated to do so).

I do know that plugins which do as you describe exist, but I don't remember their names or if they even work now.

@Graitt

Now, now, adding mods to the mix of plugins can be a tricky business. Don't get all hung up in it, you'll figure it out in time.

"Names with dots" - pardon me, but when I said "technical name", I should've been more specific. I guess the most concise definition of "technical name" is the mob's ID, much like "minecraft:air" is the ID for an air block. The "names with dots" you're referring to is not the technical name, it's a "class" specified within the code to represent/define that mob.

(Side note: I don't know any programming, so my vocabulary may be erroneous.)

"ARMADILLO" would seemingly be the correct name to specify. Why it doesn't work, I can't tell at first glance. Do you happen to be using Cauldron? You could also get support there if need be. (Erroneous vocabulary inbound) What's supposed to happen is that each mod imports its enum - or list of "things" like items and mobs which contain their IDs - into Bukkit's enum, and OtherDrops just reads from this new enum. Seeing as OD is saying "unknown material", it's not recognising the name at all. Either it's still the wrong name (perhaps Cauldron prefixes the mod's technical name onto each mob's technical name) or the enum isn't getting imported at all.

Try "PROJECTZULU_ARMADILLO" to see if that works. It's essentially the mod's name prefixed onto the entity's name (don't forget the underscore).

@Graitt

Look for the technical name of the mod mobs in the mod's source code. OtherDrops does not (and does not have the ability to) handle the names of mobs in any way - the reason why it's so flexible is because it just refers to the enum (list of mobs, items, etc) and that's it.

Enderdragons are a tricky thing and I haven't messed with them myself yet. I've heard that when they die, they don't technically pass a conventional death event, so you may be better off asking someone more knowledgeable (if they're even around) or looking at how another plugin changes enderdragon drops.

The "delay:" parameter essentially means that the "event" or "drop" won't occur until "x" ticks after the event itself has occurred. The chunk should be loaded, else nothing would happen (I don't think it's even possible to pass any event in an unloaded chunk).

Drops occur, by default, where the mob has died, or more generally where the event has occurred. But you can always add in an offset parameter to change the position of the drop relative to where the event occurred. If you do decide to use the offset parameter at any point, be aware that it could cause something to occur inside of a block or within a wall.