Bukkit

@Faldonboy

Oh, OOHHH. That makes WAY more sense. Thought he was talking about something else. I remember suggesting something similar for MobManager, but it got shot down because it would require NMS code (as you've said, not implemented in the Bukkit API yet) and would thus break on every update.

I would like to see this too, as would many others, but you're right that it's not currently feasible. I did a check on leaky, and didn't find anything recent on implementing attributes, so it'll probably be awhile before it does get implemented.

@Testercraft

If you didn't read the above portion of my comment, attribute-support won't be possible for awhile because it would cause OtherDrops to break on each Minecraft update; OtherDrops' flexibility would then be lost.

@CommodoreAlpha

He's suggesting that OtherDrops needs support for attributes which iirc bukkit still hasn't made an API for so it's currently not feasible to do. Attribute support would be WONDERFUL but its low on bukkits to do list unless they did it when I wasn't looking.

@PazaCraft

Something's wrong either OtherDrops (more likely) or your server, because the Bukkit material enum refers to block "22" as "LAPIS_BLOCK". Ergo, "LAPIS_BLOCK" should give you a Lapis Lazuli Block, not Lapis Lazuli Ore (which frankly makes no sense).

You shouldn't be using Magic Values (AKA data values) either, because they're going to be depreciated really soon. In my opinion, you should not have to resort to workarounds unless really needed - if there's a problem, and something is not working as expected, you should fix the issue, not find an alternate solution.

Have you checked to see that OtherDrops isn't reading "LAPIS_BLOCK" as an alias of "LAPIS_ORE"? It's most likely this that's causing the issue, or you've a strange issue on your hands.

@Testercraft

The tickets section should be found here; you can see it by looking at the tabs on the top of the plugin page. I already filed a ticket for you and also nuanced your suggestion to better fit the idea of flexibility.

I'm also unsure as to what you mean, when you say "But need attributes".

@SentinelCraft

I don't think it's currently possible, because I believe lightning just strikes a coordinate point rather than striking an object. So you can't use the logic, where if a block gets hit by lightning, it will turn into something else - because the lightning is striking the block's position, not the block itself.

But, I do think Zarius can implement it; it's a nice idea, and you should make a ticket about it. I believe it can be implemented by adding a "LIGHTNING_HIT" trigger-parameter. In this parameter, Zarius could just make it so that he gets the position of the lightning strike, and looks for the block below the position where the lightning struck. (I think lightning strikes the top of a block rather than the block itself, but I could be wrong.)

@PazaCraft

"LAPIS_BLOCK"

@yloplopy

I'm unsure as to whether or not you can specify enchantments in conjunction with "group-type" aliases. It may be, that on your second "tool" line, the plugin is reading "ANY_PICKAXE@!SILK_TOUCH" as just "ANY_PICKAXE".

Also, silk touch not working on your server with stone is most definitely an issue on your side. You should not use another plugin to "fix" it, unless it's an "outstanding" vanilla bug that has been experienced by many (AKA reproducible bug). What you need to do to fix your problem, is to troubleshoot its "cause" and figure out why it might be happening. If a plugin is at fault, contact the developer of that plugin, because pickaxes enchanted with silk touch should most definitely work on every server - and when they don't, it's probably because of plugin interference.

Do a "binary" search on a test server to look for the offending plugin. A binary search is basically where you remove half the plugins, and check to see if the bug is still there. If it's still there, the offending plugin is in the half you didn't remove. Rinse and repeat.

@tarossk

The problem with fluid blocks is that, while you may technically be "targeting" the fluid block itself, you cannot "interact" with the fluid block - only with solid blocks. (If there are no solid blocks within interaction range, then you technically interact with an AIR or fluid block.)

Now, there are two issues that come to mind about how to implement this feature. The first is that interacting with fluid blocks themselves is a tricky business, given how vanilla Minecraft works. The second, is that you would need to specify whether a player interaction should occur at the targeted block, or at the targeted block barring all fluid/air blocks.

@Testercraft

Just FYI, it's "fixtool" not "repairtool"... I think. I can't see how adding a parameter like "player.equip" would remedy the issue properly. Unless you meant that "repairtool" should have extra data applied to it, like "repairtool.head", "repairtool.body", etc. Either way, you should make a ticket about it.

Right now, it's not possible to make repairtool repair equipped armour, because repairtool can only repair the "thing" that did the action - in other words, the item you used to trigger the event. Again, if you'd like to see this possible, make a ticket about it to help out Zarius. ;)

@Faldonboy

That doesn't make a lot of sense when it's written that way. :|

I'll revise it for clarity.

@CommodoreAlpha

"PLAYER" block means that PLAYER is the target.

    PLAYER:
        - trigger: FISH_CAUGHT
          message: "You caught a fish!"