Bukkit

@TheKitsch

It's not a waste of my time to at least look at all this. I did not meant to imply such either. In fact, I consider a public discussion of such concerns and interests valuable for all who might come here seeking similar.

I personally would question the reliability of a plugin that caused me to be kicked upon its usage, desired outcome or not. It underlines the instability and guesswork of coding directly against undocumented/unsupported implementations (CraftBukkit, Minecraft, etc.) It's a simple side effect that has a workaround (simply rejoin) but again it just makes me so nervous about how much else could be going wrong and I may not find out about it all until it's too late.

The complexity comes from how to do it properly. Many plugin authors will take shortcuts that I simply won't impose on the server owners that use my plugins. They are too unreliable. I rely on the Bukkit team to support the Bukkit API and we all can win that way. Of course, the caveat there is when you want to do some really custom mods... sometimes you just gotta take the risk, I get that.

I wish you the best of luck in finding what you need.

@TheKitsch

Oh, there are ways to support custom NBT data if you do it yourself, yes. But that increases complexity and support effort significantly. On top of that, you run the risk of assuming too much and backing your users into a corner or worse (breaking things).

Basically it is possible to code against CraftBukkit/Minecraft directly. But like I said, I won't commit to that with this plugin. There is just too much to manage for such needs and it typically creates more problems than it resolves.

I really like the simplicity and supportability of the Bukkit API. It allows for rapid development and long term stability. I simply won't commit to custom NBT data support if Bukkit doesn't support it natively. I know that may limit the complete usefulness of this plugin, but it's all I can guarantee right now in my free time (which has even been really sparse lately itself.)

Oh yeah, just checked out PowerNBT. That guy is doing some nasty reflection voodoo: https://github.com/DPOH-VAR/PowerNBT/blob/9e351418a1046b24fb16fe6594d07fcbd8ec1006/src/main/java/me/dpohvar/powernbt/utils/ReflectionUtils.java

See he is dynamically looking at Java code at runtime and assuming a lot... what their names are, how they work, etc. If Mojang changes how those functions work one day and he doesn't have proper checks in place to prevent problems, your server could suddenly start to delete/alter/destroy your custom NBT data. And in fact, look at the problems it creates with plugins like mine which support the Bukkit API exclusively. PowerNBT leads server owners to believe that custom data is just fine and there is no problem with it, when in fact it is simply not supported.

Now this all said, I believe Mojang has been encouraging a lot more custom NBT type of solutions... but like I said I'm not sure Bukkit's official stance on all that just yet or how it will play out. We are sort of at a crossroads in time where a decision will need to eventually be made on how to properly handle that data. But until then, I can't do it myself, it's just too much effort and danger.

@TheKitsch

I'm a bit out of touch with Bukkit at the moment by a few months or so, but this plugin only uses native Bukkit functionality to serialize NBT data. I'm assuming Bukkit still is not supporting custom NBT data in some fashion.

I'll try and find time over the coming weeks to see what is going on exactly.

@TheKitsch

I'm excited to hear this plugin works well for you and your server.

The copy and move commands were really last minute adds that I decided to put in when I started thinking about the various manipulations admins might want. Primarily useful for things like where an admin can use other game mechanics to administratively create an item (anvil, enchantment table, etc) then want another player to have the item immediately and not have to go through a delivery interface. Although I agree they don't flow exactly with the other commands/usage of this plugin. Ideally I'll find some more time to make all these commands have a more unified experience which lets you choose to put it in a player's direct inventory immediately if there is space, then rollover to a delivery inventory as appropriate. Then if you use /copy or /move and there is no space, it'll rollover to delivery also. I guess they are only partially implemented placeholders for an idea at this point.

No ongoing resources are used by this plugin other than the file space to store the delivery inventory information for each player. The only time this plugin will use resources is when a player opens their delivery inventory, it'll read their delivery file and load up a temporary inventory chest instance for them to manipulate as appropriate. But all of that is practically equivalent to any player opening a regular chest in game. So basically, no.

@dawm

Yes /ekit would totally work also.

I also forgot bukkit.yml aliases do not support periods in them. :(

You could maybe do something like:

aliases:
  kit: ekit
  delivery-kit: inventory:kit
  delivery-kit-define: inventory:define
  delivery-kit-delete: inventory:delete

Or whatever you want appropriately. But yes, the point is to find aliases you want to use as you prefer.

@dawm

It turns out Essentials does some non-standard things with commands... For some reason they force another plugin's command alias to override their plugin's primary command name. So you'll need to use your bukkit.yml alias (kit) to point to the Essentials alias (ekit) to ensure it works as you want. Based on what you said, I'd guess you'd want this in your bukkit.yml file:

aliases:
  kit: ekit
  delivery.kit: inventory:kit
  delivery.kit.define: inventory:define
  delivery.kit.delete: inventory:delete

That will give you your /kit command calling Essentials and /delivery.kit, /delivery.kit.define and /delivery.kit.delete calling Inventory appropriately.

@dawm

You should be able to control the commands using the aliases feature in the bukkit.yml file.

I haven't flushed out this plugin's documentation yet, but you can find the originally registered command names in the source: https://github.com/EdGruberman/Inventory/blob/master/resources/plugin.yml

So, you could force the kit alias to point to your preferred plugin's command, then alias the inventory:kit command to delivery.kit or whatever you want for intuitive interaction as you see fit:

aliases:
  kit: otherkitcommand
  delivery.kit: inventory:kit

If you tell me the other plugin I can try and research the exact syntax for you. I'm curious myself to ensure this works as I expect it to.

Also, I'll eventually be adding a feature to this plugin to allow for adding kits directly to a player's current inventory (and with automatic overflow control if it's full/they are offline/etc also for that matter...) So maybe one day you can consolidate your plugin usage and avoid having to deal with conflicting commands altogether.

@craftik7

Who says it might not eventually? :)

@tjjerome

Yes. That's exactly why I created this plugin for myself in the first place.

@Zulgol

I'm surprised 1.4.7 doesn't still work. Although I don't test against it directly, there is code in the plugin's latest version that should let it work with such.

What specific error are you getting? Do you have any log files?

In fact I just tested myself with 1.4.7 and it works. So something is up with your setup. I'm not very familiar with FTB setups and how they work though. Perhaps there is some other conflict?