It would be very convenient to be able to set groups of items (e.g. armour, food) to have a global limit and perhaps have configurable groups as well

I used your file as a starter and modified it for bukkit's Material list which I am using. I tested it briefly, but more testing would be great.

Check here for the latest test version which includes this: https://github.com/haveric/StackableItems/tree/master/versions/test

My server is using it now, though I haven't done any extensive tests. However, I did notice something; is the plugin responsible for the chat messages you get when you click something in your inventory?

I might have left that in one of the test versions, what does the version say when you use /stackableitems? The latest one (0.7.5t6) does not have any messages.

well I retrieved the jar and group file from the link that you gave, and it says v0.7.5.t5, so I'll update it. Also, I posted that comment like 8 hours after I downloaded it, and it seems you updated between those times. oops.

That's partially why I'm doing these test versions to better catch my mistakes before pushing out an update. There are quite a few changes though, and I'd like to get a few more in before I make it official as well as do some extensive testing.

Let me know if you find anything that is not working properly or anything you'd like to see added. This feature seems quite useful and I had wanted to do something similar to what Stackable did before, but I never liked the way it was limited there.

I also want to note that I do not run a production server, so any feedback on how well it works, performance, or anything else is greatly appreciated.

While it would be less file i/o, I'm not sure how I'd do that as they are all optional files. If you have any suggestions, I'd love to hear them.

I could do some of those things, but I wouldn't be able to start until tomorrow at the earliest. there seems to be a way to get all groups that are in the permissions but not all players. I would like to avoid iterating over all the .yml files in the directory but it seems it must be done.

There was a bit of delay between before the email got to me. That was kind of a continuation of the post before.

The list of groups just gives a list of files to look in, and a way to distinguish a playerfile from a groupfile. The ones that are found could be placed in a map<lowercasename,max> and then they could be looked up at runtime. The reload would just be re-filling those maps.

wrong button....

I haven't been able to do much testing, but that's mostly because I haven't been able to figure out how to work this plugin (also: laziness). There weren't any examples in that I could find, so i looked at your code to see how the files were accessed, and I came across line 157 in Config.java and it seems that the code looks for an int mapped from a group name. However, it is looking in the group file, and here the group names are mapped to a list of items. Did you mean for it too look in a different file? I didn't want to fork it because it us such a small change and I don't know how you would like to do it.

The group.yml can be any permissionGroup.yml so that you can override the defaultItems.yml for a given group using permissions. You can also use player.yml to override it for a specific player.

Example cases would be if I am in permission group "admin" and I am player "haveric", I could use admin.yml to affect all people in the admin group and haveric.yml to only affect me.

It checks for them in this order:
player.yml
group.yml
defaultItems.yml

If a player.yml does not exist, it will check group.yml and so forth.

Hopefully that helps, let me know if it's still confusing.

Well that's embarrassing. It seems that I did not notice that group is a string variable and not a string literal! That clears things up.

:$

From an efficiency point of view, it might be worth it to load and cache the group and player configurations. Also, the way it is now, as soon as a file is saved, the changes take effect on the server.

The permission groups wouldn't be a problem then. Perhaps I could load in the player file after a player first joins. That would probably be the easiest way to handle it, and that way when a player leaves, the data can be removed.

Of course this would mean that people have to leave in order for changes to take effect, which is not ideal.

Edit: A reload could probably check for all current players and load those files. That might work.

I rewrote the code that handles item loading and it now stores them in the plugin until a reload is called. The player files will be loaded/unloaded as people come and go. Will try to get a jar up tonight after making sure everything is working again.

Sounds like a great way to do that, thanks. Also, let me know if there are any other things from Stackable that I have overlooked as this is meant to be a replacement. Or any ideas, concerns, bugs, etc about it, feel free to let me know.

Thanks again,
Haveric

Cool.
I started to work on a grouped Item file. If you want it I'll post a link.

here:

• http://dl.dropbox.com/u/45951203/grouped%20items.yml

I do remember Stackable having groups for armor and food which I can add. I'm not quite sure what you mean by configurable groups though. Are you saying that it would just be a file with say all of the food in it that could be added to/removed from for the lists?

Yeah, that's where I got the idea, having used Stackable before. I was just thinking that there would be support for a file itemGroups.yml (or something) written in the style

group1_name:

• item1
• item2

group2_name:

• item3
• item4

(or something as effective) that could be used to define groups that could referenced in defaultItems.yml. Then you (haverik) could use that file (with the food, armour, etc. in it by default) to implement the groups that people probably want.

Thanks, that will help a lot. I'm going to see if I can come up with a dynamic way of declaring these groups, allowing people to create their own groups like you have here.