Bukkit

@Testercraft

No; whereas "lorename:" is a parameter, "loreline:" is not.

Short answer is, there are no parameters for lores; they're specified as "metadata", and should only be specified as metadata. (There is no point in making a parameter to specify lore.)

Just use the first example you gave. It's far more compact and concise (and thus easier to read) than the second hypothetical example, anyhow.

@Smac3223

Looking at your "otherdrops-drops.yml", you haven't spaced your lines correctly. Each "object" should begin with four spaces (NOT a tab), and each entry under an object should begin with six spaces, a hyphen, and another space. Why, you might ask?

Well, look at the line where you specified "IRON_GOLEM", then look above it until you see a line saying "otherdrops:". Because you put all your "objects" in the same "column" as "otherdrops:", the plugin doesn't read the information as falling under "otherdrops:" so it skips all the information you specify. Hence why your configuration isn't working in the slightest bit. If you space correctly, your configuration-drops will fall under "otherdrops:" and it will thus be read by the plugin. Follow the example within the .yml file EXACTLY, but without the "#" symbol if you need guidance.

Since you're only using OtherDrops to disable a few drops, you should set "loot_overrides_default" to "false", and use the original configuration I suggested, where you use "NOTHING" instead of "AIR".

@Testercraft

Sorry - I didn't quite understand what you asked. Could you clarify?

If you want to know how to insert lores into an item, take a look at this page. For now, that is all I can offer.

@Smac3223

Hmm, your configuration looks correct, so I can't tell what could be going wrong. Maybe the "NOTHING" variable doesn't work? It should, but I've actually never used it myself. If that's the case, you could try setting the "loot_overrides_default" option to "true" within the "otherdrops-config.yml" file to see if that will work. If changing the option doesn't work, try replacing every instance of "NOTHING" with "AIR".

Or maybe I'm looking too hard, and the issue lies not within your configuration, but in how your configuration is placed, if that made any sense. You may have misplaced the .yml file in question, or you may have left out an essential line at the beginning of the .yml file. You can send me your configuration files via pastebin if you want me to analyse further, but drops should either be specified within "otherdrops-drops.yml" or within any named ".yml" file under the folder "includes". All the aforementioned folders and files are located in OtherDrops' plugin folder.

@Testercraft

Yeah, I think using [] within {} is the problem. Because that might've just confused OtherDrops when it read your configuration. Try removing it to see if it works. Thanks for pointing that out by the way, I wouldn't have noticed it! :)

If it still doesn't work, I'll try to investigate your issue IF I have the time. But that's a pretty big "IF".

@Smac3223

You're making two entries instead of one per section. Read this page for what an "entry" is. From the plugin's perspective, you're specifying triggers and effects separately, so the plugin isn't attributing them together as is intended. Making sure you do this should solve your issue, although with the results you described, I'm quite surprised you got that even with a nonworking config.

You might also want to space your entries better... I don't know if that will fix anything, but you should put at least two spaces in front of each "object", then space the rest under each object accordingly. (Follow the example within the config you posted.)

Also, you should either use the <<code yaml>>textgoeshere<</code>> format, or pastebin to submit your configuration. Sending a .jpg works, but can prove to be inconvenient. And one more thing - extremely irrelevant - but you shouldn't explicitly ask for help at the end of a request because we can infer it's a request for help. While it doesn't bug me much (but I pay too much close attention to details), other people might have a problem with it. Especially with the way you've spelled it as "Halp" instead of "Help". Fixing a typo (which you probably did on purpose) really goes a long way in making an impression. ;)

@Smac3223

Yes, check out the Tools page. Here's an example you can use:

    CHICKEN:
    - tool: DAMAGE_BURN
      drop: NOTHING

If you kill a chicken by any sort of heat-related damage like fire, firetick, or lava, it will drop nothing. Otherwise, everything will drop normally. Now, if you have the "override loot" option set to true (it's defaulted to "false"), then you'll also have to specify the following to make sure that the chicken will drop normal drops on any other cause of death.

    CHICKEN:
    - tool: [ANY_DAMAGE, -DAMAGE_BURN]
      drop: DEFAULT

Hope that was helpful enough.

@Testercraft

You're using "@" but you need to use "@!" for names.

@Chester2000

It's half possible... You can make all zombies that spawn at night with all the attributes you just listed, but it would happen every night. An "event" isn't possible - you'd have to find another plugin for that. The reason is because OtherDrops does actions based on triggers/scripts and conditions - an event would be more like the plugin taking the preemptive to change outcomes/effects based on a certain timer. In other words, events require the plugin to respond on its own, whereas OtherDrops only responds to triggers. So having the ability to add events would be quite out of the scope of this plugin.

If you just want all zombies to spawn every night with more hp, stronger hits, and a chance to drop more zombies, you could do something along these lines:

    ZOMBIE:
    - time: NIGHT
      trigger: MOBSPAWN
      drop: [NOTHING, ZOMBIE@40h] # cancels original zombie, spawns a double-health one
    ZOMBIE@40h:
    - time: NIGHT
      drop: ZOMBIE@40h
      chance: 50 # 50% chance slaying a 40hp zombie at night spawns another 40hp zombie
    - time: NIGHT # all 40hp zombies that spawn at night should receive the potion effect
      trigger: MOBSPAWN
      potioneffects.victim: INCREASE_DAMAGE@1@99999 # level 1 strength for 99999 seconds

If potioneffects.victim doesn't work, try potioneffects.attacker. If you only want some zombies to spawn with the attributes, just add "chance: <integer>". Also keep in mind, there's a "SPAWNEDBY: <reason>" parameter too if you want to use that.

@Chester2000

Please use the <<code yaml>>inserttexthere<</code>> format, because it really hurts my eyes when I have to parse through jumbled configurations like that.

Now, you mention "It's there possible to do something like that?" What is "that" you are referring to? Pronouns need antecedents, and you haven't provided any, so I have no idea what you're talking about. I would try to decipher what you're trying to say to try my best to help you... but this is the most ambiguous message I've ever seen, so I can't do anything to help you. I can't even infer what you want. :|

Now, looking at your configuration. You have block "19" specified there. That's a sponge, not a daylight sensor. Next, you have "chance: 100" which is completely redundant; I'm not sure why that's there. And, you have "drops: ZOMBIE". It's "drop:" not "drops:" - read the documentation here as it's pretty darn helpful. ;) So, to summarise your first entry, every time a sponge block gets powered up, there's a 100% chance that a message will be sent to the server, and that a zombie will be spawned at the location of the block. Doesn't make a lot of sense, but hey, it's your judgment not mine.

For the second part, if you use any tool to break a sponge, there's a 30% chance that exactly ONE zombie will drop at its location. What's weird is that you specified "quantity: 1" which is already implied... so it's pointless. It's as if you suspected the plugin would drop some random integer-amount between negative infinity and infinity, so you wanted it to only drop one. :P

@arturek1666

Use the command parameter, or go find another plugin for that. There's no good reason that OtherDrops should innately offer support for that feature. (Or there is a good point, but I've yet to be persuaded.) To me, there is no difference between picking up items, and items going straight to the inventory. They both achieve the same effect, although forcing items to the inventory is far more problematic in many ways.