Quote fromWell first and foremost, I think modules (extentions of the mod, all part of the same mod, the mod functions fine if they're not there but they are there by default) makes perfect sense. This is how most of my mods have become. In PT the tradeskills and each "superset" of sets is it's own module. You didn't go the module route though, you went the plugin route (seperate addons entirely). I completely disagree with that choice because I feel the whole needed option can be coverd in a half dozen modules (Pt, tooltip, user-defined... blah blah blah)...
I know I sound like an ass, okey I know I am an ass... it's just we've waited for a long time (I started PT after the last version of this mod was posted up for trying out)... maybe I expected more to have happened in that time? On the surface this still looks like the same mod. I guess I'm just being whiney cause I expected PT to get slipped in there already is all.
Oh and for the record, I do like the idea of definitions being seperate from the core code, I just think you need to make them all modules of the same program. Drop the plugin design route and aim for a modularized single addon. Heck, I might even stop being a whiney bitch and write a few modules for you (PT and tooltip). I mean, PT support is so trivial... well that's the whole reason I think modules make more sense than plugins! The basic modules I pointed out are all rather small, it just doesn't warrent being o seperate plugin. Plugins would still be possible, but make your mod should only be one mod ^^
If you want to take over InvSort, feel free. But I *HATE* mods that come with multiple sub directories that you can delete if you don't want sub-parts. That was one of the reasons I decided not to use KC_Items. I absolutely detest it. If you have 5 different concepts, give me 5 mods, let me pick what I want at the getgo. Don't make me re-download the whole fucking thing every time you update one sub module.
There is absolutely no way I'll work on a mod that's modularized the way you want, and it's just a semantic difference. Offering 5 downloads for 5 mods that work well together instead of offering 1 with 5 sub directories that you can delete doesn't change how anything inside is implemented. So if it really bugs you that much, just take InvSort, and rock it. It's designed to be both AutoBar and a sorted inventory, and I bet it can even handle that other ammo thing you wanted, but i don't know what that is... ;) So it's everything PT was designed to help.
As for "PT being slipped in there" -- honestly, I don't know why you expected PT to be an integrated part of it just because you made it. As you've said a hundred times -- the PT/IS connection is remarkably simple. I'm writing IS, not PT, and connecting them is very easy. So I'm working on getting IS capability working. You know. That XML crap you hate? I hate it too. Maintaining stupid lists, displaying items right, giving the end-user the power to move things around and have detached and attached groups, and display the right numbers, and not get lost off the side of the screen when you resize, and bank support, and not be too memory inefficient... Gee. I'm sorry I didn't spend the time connecting PT to the mod as well. Next time, I'll do that before I even have it displaying items, to make sure you don't feel like your work is going unappreciated. Sorry if I sound bitter, but it's really quite obnoxious how you've been telling me to use your idea of how a mod design should be instead of my own and how I haven't fully incorporated your work before I even get mine to a basic stable release. Seriously. If you want to write this mod, go ahead. I'm ONLY doing it because Ramble's in school and I absolutely hate every alternative. I don't want to write this. I don't want to maintain it. I want to go play WoW with it. And when I do? I'll be using the PT rules. So I'm either going to write a single mod with a PT requirement, or I'll write a very basic mod with plugins. I'm not writing a modular system with subdirectories. I'm not even willing to USE those on principle, so I'm not going to write one. Stop asking.
Now how is PT helpful to this? Well using those things you defined....
So, we need:
a rule type. -- The PT set
a way to identify up to two icons. -- Uhm, why not just use an icon from the set automaticaly? save it if you need, pull one out of GetItemInfo, whatever
a complex definition system for what is contained in a rule. -- no need for complexity, PT tells you a simple yes/no if it's in the set
a sorting system. -- Provided automatically with the values from PT, if applicable
You didn't really read what I wrote, did you. :P
a way to identify icons - "just use an icon from the set" ? Because the end user might not want his enchanting set icon to look like a dream dust? What if he doesn't have any items from the set, and doesn't use KC_Items? He can't get the icon? So it's just blank until he gets one? Then I have to store the icon it uses? Or does it go blank again if its empty? And change as they change items? Or are icons stored in PT? (That would go against your "Efficiency" thing though right? :))
a complex definition system for what is contained - PT tells you yes or no for a single category concept. I understand that you love PT and think it's the end-all be-all of all categorization concepts, but I'm not sure I agree. Maybe I'm wrong. Maybe PT is every category everyone on the planet would ever want, with just a few items falling in the wrong places for a few people. Who knows. But PT doesn't provide grouping of categories, or "things in one category and not in another," etc. so there's still a complex combination of rules. EngInventory has one of the better solutions I can think of to this problem, and I'm not sure the entirely modular idea I am currently working on does, you're right. But Pt isn't a solution to the problem either, there's still the same problem that InvSort has to deal with.
a sorting system - again with the thinking PT is the end-all be-all. Some people would like their mana potions from weakest to strongest, some from strongest to weakest. Some people like potions alphabetical. Some people don't like it when their bags sort. Sure, that's just 4 options I could give every bag. Some people like equipment sorted by item slot then level, some people like it sorted by level, some alphabetically, some by rarity... You don't want PT to provide every possible sorting option, and I don't want to try to guess how everyone would sort, nor do I want to make the interface overly complex with sorting options everywhere for everything. If I just said "level" as a sorting option for everything, how would it sort recipes, which are all level 1? So that doesn't make sense. How a given set of items is sorted should generally depend on the set.
Or, I can do what Eng and ABF and everyone else did and say "f. that sh*t" and just sort alphabetically or by PT...
You've got to remember not to get too complex here, as you said AdvBag's config was scary. EngInv's honestly isn't, it's the code behind it I didn't like. I look at my EngInv config and every set definition comes down to a single rule. If users want a really complex class it really seems that a user-defined, add items one-at-a-time set is what they need. The power of your design is that items will fall into many categories, so why make filters overly complex?
That's a good point. I think basic "or" and "not" functionality (slightly more advanced than Eng's) with Pt might make for a sweet system. So now you've got me wavering again. PT required, otherwise it's just OneBag, inefficiently done vs. my current design. And to be honest, maintaining my current design is probably more work than just making it PT required. So, next free time I have, I'll take a look at PT and see if I can come up with a different design idea that I like that incorporates PT better. Deal?