Description:
Advanced Bags + Eng Inventory + One Bag + Tons of Awesome - Lots of Suck = InvSort.
For a more full description, check out the link above. I don't want to maintain two full descriptions.
All bug reports go in the portal, or they don't get listened to. :)
Discussion:
The reason this isn't in released mods is because we're changing the name, and it's still alpha in my mind. As soon as I go beta, and change the name, I'll put it over in released mods. For now, I only want people who are willing to accept that this won't do exactly what you expect all the time to use it.
I have a lot of TODO's for it, like write up a "how to make new/awesomer categories," and fix a few bugs I already know about. I would very much like to know what kinds of features people would like to see. Use the portal on wowinterface. Don't post requests here. DOn't post requests if you haven't used it. :)
Fuck you, I'm tired and cranky and want to have my say (besids I'm probably repeating stuff you already know :P ) ... Beside I did look over your code, just didn't load up the mod.
Two things the mod NEEDS, if they are not already in...
First and formost, I'm sure you're quite aware that I wrote PeriodicTable with this (and a few other) addons in mind. There should be a nice, quick, simple way to add a PT set if PT is installed.
Second: Give the users a nice simple tooltip parsing interface for sets. Simple enough, the user defines a string (actually an LUA regex if they want) and anything that matches that string in it's tooltip is added to the set.
In the end there's really only a few set description means needed (though you've provided for any set that's definable in an lua function). Those would be:
Qualtiy (pulled from the API)
Empties (you already have)
Equipment types (again from the API)
PT sets (simple enough to add *grin*)
Tooltip parsing
I cannot think of any items that will not be sortable using one of these methods.
Also, be aware that PT provides some useful data that, in conjunction with the itemLevel data from GetItemInfo, can be used to sort the displayed items by quality. For example, all food and water items have a HP/MP recovered value if the item is consumable by the player (raw foods don't have values, they're available for pet-feeding mods really).
Anywho, PLEASE PLEASE PLEASE add PT support, it sholdn't bee too hard for you to do *grin* Do that and it's very VERY likly that I'll be abandoning EngInv very quickly, even for an alpha/beta mod.
Oh and someone else suggested Bank sort on WoWI, I wholeheartedly agree. My bank is such a mess nowadays! And from the LUA side it's no different, just the bank uses bags -1, 5-10 (or is it 11?) and the data is only accessable when the bank is open... unless you pull the info from KCI (which you should if it's installed!)
Two things the mod NEEDS, if they are not already in...
Yeah. "if they are not already in..." doesn't apply here. Sets aren't specific to the Inventory Sorter itself. It's like BossPanel Addons. BossPanel == InvSort. BossPanel_Experience == InvSort_PriodicTable
That way people can write their own categories that depend on other mods, like PeriodicTable,etc. I'll give you an example:
InvSort_RegularExpressions = AceAddon:new(...)
InvSort_RegularExpressions:Initialize()
InvSort:RegisterCategory({
name="Tooltip RegEx Scan",
description="Scans tooltips of items and includes them if the regular expression is found.",
usesnormalview=1,
iconpath="Interface\\Icons\\INV_Misc_QuestionMark",
contains = function(index)
tooltiptext = FunctionThatGetsTooltipText
return strfind(tooltiptext, self.get("regex"))>0
end,
})
end
That, right there, along with a command-prompt to self.set("regex"), is an additional addon you could release that provides a RegEx functionality for a group. Guess what? Same with Periodic Table. Same with Wardrobe. Same with KC_Items. Etc, etc. You can release any categories you want. Or you can write your own little personal ones.
The goal is for the basic package to include very basic, simple categories, then to let people introduce others. I plan to release the PeriodicTable one myself, as soon as the base system is stable, 'cause I'll be using that one. I won't use the Wardrobe one, but people requested it, so I'm hoping someone writes it. I will probably also release another one that adds AutoBar functionality...
I cannot think of any items that will not be sortable using one of these methods.
I can think of tons, and just because they are sortable doesn't mean that's how a user wants to sort them. I very actively sort blue and green equipment into multiple sets, I like to sort my alchemy stuff into: buyable parts, herbs, potions i make and don't use, potions i make and use, and mana/health pots. There's five categories you didn't list. :)
Also, be aware that PT provides some useful data that, in conjunction with the itemLevel data from GetItemInfo, can be used to sort the displayed items by quality. For example, all food and water items have a HP/MP recovered value if the item is consumable by the player (raw foods don't have values, they're available for pet-feeding mods really).
Yeah, I know. And if you'd like to write the PT categories, feel free. :) I'll write them to the best of my ability, using everything I can see in PT. In fact, I even plan to send you PMs when I'm writing them to make sure I get the most out of PT.
Anywho, PLEASE PLEASE PLEASE add PT support, it sholdn't bee too hard for you to do *grin* Do that and it's very VERY likly that I'll be abandoning EngInv very quickly, even for an alpha/beta mod.
Yeah. Honestly, as soon as I'm comfortable using IS instead of another bag (which starting today, I think is fairly likely), I'll be writing at least a basic PT set.
Oh and someone else suggested Bank sort on WoWI, I wholeheartedly agree. My bank is such a mess nowadays! And from the LUA side it's no different, just the bank uses bags -1, 5-10 (or is it 11?) and the data is only accessable when the bank is open... unless you pull the info from KCI (which you should if it's installed!)
I plan to add bank support as soon as I can. I may rip out the AceInventory support, 'cause I actually think it doesn't help as much as was originally intended, and it makes some things more confusing. Either way, the only things stopping bank support right now is AceInventory. And I'll be adding it soon. Now the question is:
PT, or bank support? which is more important?
I'll probably add bank support before making my own PT categories, since bank support is a basic fundamental need, and PT categories are just good ideas. :)
Heh, I think you're misunderstanding how PT was designed, for one. PT support should be added to the base mod really. The user should not have to dabble in the LUA, and an big slock of lua stuff should not be neede for each PT set. Frankly, those blocks of code are larger that the PT sets themselves are. The user should be able to do something like "/is addptset food" and bam! they've got a new set. Making sets definable seperate from the main addon is a nice idea, but frankly I see those more as modules (I.E. part of the main addn that the user can remove if they want). Seperating them out makes no sense to me, and it kinda fels like you're trying to offload the category defining on someone else... but I already put a lot of work into making the sets in PT as useful to anyone as I could, and damn easy to access (there's only two API methods you'll ever need to use).
I can think of tons, and just because they are sortable doesn't mean that's how a user wants to sort them. I very actively sort blue and green equipment into multiple sets, I like to sort my alchemy stuff into: buyable parts, herbs, potions i make and don't use, potions i make and use, and mana/health pots. There's five categories you didn't list. Smile
Blue/green, I said item quality did I not?
"that I use" sounds like a user-defined set, which you seem to already have
buyable parts - PT
mana-health pots - PT
potions I make - PT's tradeskill module
:P
BTW I'm sure you already know, don't take any of this the wrong way. It's all construtive criticism. I desperatly want to drop EngInv, but I'm gonna have my say in the mod that replaces it. I've already written PT for sets, and there's also my AceTooltip for the tooltip parsing if you want. In the end the only reasn I've not put this bugger together myself is the simple foct that I hate XML. Maybe that'll change in 1.10 *grin*
::ducks in and tries to avoid the firefight here::
I haven't looked at PT much since xelepart took over the main coding for InvSort. But if I understood what i've read it do handle a bunch of the sorting type stuff we'd want to do. But suppose I want a group for my FR gear? Or a group for my engineering trinkets? All green+ items that aren't soulbound? Are those trivial to implement in PT?
(that was one lousy atempt to avoid the firefight, bringing up the heated topic right away)
Anywho... a handful of comments/bug reports:
* Empty slots is showing 32, I've sold some stuff, picked up some stuff from AH, and now I have 30 empty slots. The text in the empty slot never updated.
* Ammo slot: I'm a rogue, I have my crossbow equipped and I carry one stack of arrows. The ammo loads the right icon, but it doesn't count any ammo. (I show 0 in the icon, and I mouse over and it says "Ammo (empty)"
* What happened to the mouse over a group and it shows you the contents? Or was that only in my latest local copy... Anywho, I wanted the groups to have the functionality similar to my XRayVision mod, where you can see what's in the group without actually opening it.
Well Ramble, I'm not saying that PT will do EVERYTHING needed in an inv sort mod, just a big chunk of currently missing stuff. I do believe the mod already has user-defined categories, which is what you're asking for when you want "my FR gear" and such. As I pointed out, there a few core things that are needed...
User-defined classes, add items one-at-a-time.
Tooltip classes, match all items that say "Bind on Equip" for instance
PT's classes, covers stuff like consumables, reagents, tradeskill ingreds. tokens (ZG/AQ) and a lot of other things
Tradeskill data, also can be gotten from PT
Equipment types, quest items, item quality - some of the only useful sorting info available from GetItemInfo
Empty slots, ammo and soul pouch slots - kindof a combination of API and PT here, PT has itemID's for the ammo/soul bags. Emties can be decerned using the API
I'm not trying to sound like a jerk or anything, but I really don't like the plugin idea. I can wholeheartedly see each of the grouping option as a module within the main program, but totally seperate addons does not make sense to me. The code needed to create a set is too much, and it sorta forces the user into learning lua. The other thing that bothers me is the ability he added to use a list of itemID's. That's really all that PT does is maintain lists of ID's, I put a lot of work into making it use the minimal memory it can at all times.
*shrug* I dunno I'm just seeing lots of things being implemented that I put into PT specifically to make this mod easy, and they're not getting used. When I wrote PT I had three mods in mind specifically... Sorted AIOI, Autobar and PetFeeding. I'm well aware there are many other uses for PT, but my focus was to provide a simple mechanism for classifying and sorting items by worth.
And if not, do you think it'd be possible to mod InvSort to look like this? I've been thinking about making a list-type bag mod for a long while now, but itfeels like such a huge beast to tackle. But maybe if I could use InvSort (or maybe some other mod?) as a foundation, it'd make my life a helluva lot easier.
Okay, after writing a 30 page essay on a variety of subjects, such as:
* I understand PT just fine, and I fully plan to make everything you want PT to provide easy to do.
* You obviously don't understand my design of IS.
* User's don't write lua, modders do. Users download mods. Once you or I writes the PT portion of IS, nobody else has to write any lua.
* I hate the list I provided as well, but I didn't want to change Ramble's original rules, and he had them. :P ::points the blame away:: -- I think I'll remove those any way.
I decided you may be right. The actual bulk required to integrate PT as an optional dependancy is minimal.
But I'd just like to point out that "lots of things being implemented that you put into PT specifically to make this mod easy" -- nothing is being implemented that you put into PT. Simple, very basic categories are included right now for testing purposes. I would actually expect almost everyone who wants this mod to use PT as well, and use the PT categories module.
Quote from "stylpe" »
Speaking of bag mods, are there any that present the bags in a list? I mean, like:
Check out Posessions here. -- it doesn't sort by category, it sorts alphabetically. But I bet you could do a few changes here and there and incorporate PT into that, and it'd rock.
I'm going to start a new post here for design discussion.
Okay, here's a few points that need to be addressed:
One thing I *REALLY* don't want is a big clunky UI to set up new categories. I hate that about ABF. The reason I originally designed it as modular is because there's no good way to make up "new rules" unless you're really interested in getting your hands dirty. The average end-user wants to log in, pick some bag types they care about, force certain items/exceptions by moving items into and out of bags, and that's it. Normal people don't want to go "okay, I want a bag that includes blue or rarer items, and a bag that includes green armor and weapons, and a bag that includes all my alchemy supplies, except health and mana pots, and a bag..." -- they want someone else to come up with good bag ideas, then to see a mod described as "this mod gives you options for trade skill bags" and to download that if they care about them.
Learning how to properly use a huge clunky complex rules system for bags is nearly as bad as learning lua, and half the people who would learn the complex rules probably already know lua. and most people are going for similar bag concepts (ex: PT bags). That's why I decided that a simple "is the item in bag b, slot s in you rule?" function definition was the best way to do it. It's simple lua to understand, doesn't require much extra work, etc.
In coding the system, I realized there's some extra information:
Is this a rule that summarizes information (empty slots, auto-bar-like functionality, etc), or is this a rule that shows you a bag? Both work the same way, one rule could provide both options, etc. So you need a way to say which type of rule a new rule is. Summary, Normal, or Both.
If it's normal, it needs an icon for the icon bar and the frame. So you need a way to specify the icon path. And I don't want to do what ABF did, and provide 600 icons, so if you want a custom icon, you'd have to include that is an addon anyway.
If it's a summary view, it needs an icon to indicate which summary it is when it's empty (if it has items in it, it uses the first item's icon so you know what you'd use if you clicked on it.) So you need to include a way to set the summary view icon.
You need a way to describe what's in the bag. Some people might just was "/is addptrule food" but someone else might want "/is addptrule food and water" and someone else might want "/is addrule potions and not (mana potions or healing potions)" ... and now you're talking a complex logic parser, or a complex gui, to provide the PT grouping systems someone might want. Or you need an "/is alterrule rulename add/remove :type:"
So you want to provide all the options you expect people to want to use either as defaults on, or with a single "/is toggle foodandwater" and "/is toggle buffpotions". This is another reason I did it the way I did -- let someone who has the time and desire to come up with good ideas come up with them, make them powerful, and provide a simple access method for end users.
Furthermore, you also need to know how the user wants something sorted. Alphabetically, by level, by set, by type, by heal value, by rarity, in the order you found it, etc, etc...
So, we need:
a rule type.
a way to identify up to two icons.
a complex definition system for what is contained in a rule.
a sorting system.
How do you think we should approach this? I don't want complex series of /commands like Visor, I don't want a complex bloated UI like ABF... Perhaps something like EngInventory? Here, let me discuss:
"/is newsummary Rulename Iconpath" (or newnormal, or newboth, with two iconpaths)
makes a new empty rule that uses the summary view. (or normal, or both, obviously)
Now, you have the normal UI. If you RIGHT-click the icon or the summary button, you get a context-sensative menu that lists all the concepts the system knows about.
For instance:
Level 1:
NormalInfo ->
PT Info ->
TooltipInfo ->
Level 2:
Pt Info->
Healing Potions
Mana Potions
other categories... etc...
etc...
Now you can use that to check and uncheck the various concepts to make a rule. Everything that is checked is OR'd together:
Healing Potions OR Mana Potions etc...
Followed by an AND NOT (...) for anything that you put an X next to. ...?
That still seems kinda complex, but relatively straightforward. Still, making new rules requires the end user to know what the icon path they want is...
So, what's the proper way to do this? I mean, I could write exactly the default rules that *I* want, and just let people set up exceptions however they want, but the goal is to allow a powerful extensible system that lets everyone sort things the way THEY want.
Which brings me back to not integrating PT in the first place. Just because *YOU* want PT doesn't mean everyone else will. And the PT rules will be just as easy to write and provide with the current system as they would if I integrated them.
So now I'm wavering again. :)
So, instead of telling me about how you think modules don't make sense, and how end uses shouldn't write Lua code, and how you designed something to make my life easier, even though end users don't write code, modules make perfect sense and are used in all the most popular mods, and I'd still be using everything you designed just as much whether or not it's in a module... why should PT be part of this? How do I solve the problem of a complex interface that can be made a hundred times less complex by limiting the people who actually use it to Lua modders, and providing a very simple striaghtforward end product for most users?
"Here are the rules we made. You can add exceptions to them." And let people who have the time and effort and know-how and desire add new rules they can pick from. I honestly don't see any good argument for why it should be any other way. :) So, propose one, make it clear and make sense.
So, instead of telling me about how you think modules don't make sense, and how end uses shouldn't write Lua code, and how you designed something to make my life easier, even though end users don't write code, modules make perfect sense and are used in all the most popular mods, and I'd still be using everything you designed just as much whether or not it's in a module... why should PT be part of this? How do I solve the problem of a complex interface that can be made a hundred times less complex by limiting the people who actually use it to Lua modders, and providing a very simple striaghtforward end product for most users?
Well 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)...
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'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?
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 ^^
Well, the reason Plugins are attractive is because they are more accessable to the end user. It is easier to install a whole other plugin addon than have to add files to an existing addon and modify toc files. And it's easier on the developers. As a developer of InvSort I wouldn't want to be responsible for changes to.. say Wardrobe .. that affect the way I sort things.
And just so you know, I'm toying with making PT sets right now with out rule structure. I'll come back with some codein a few.
Yea Ramble, plugins make sense, just not for the base mod. The main installation should be one mod, many modules, does everything you *should* need. Plugins would only enhance it.
I mean, the plugin structure in place is nice, I'll fully support it, I just think thatthe stuff xele is including with his download should just be modules. Performance impact is miniamal for a plugin/module here (which is NOT the case with Titan/Bosspanel addons) so I see no reason why they shouldn't just be modules in the core addon. The user can always choose to delete the lua files for a module if they want and it'd be fine, but the base sets shouldn't be seperate addons in my crappy opinion :P
Hey xele, I was thinking about it at lunch/dinner... if the icon for a set isn't defined you should use an icon for an item in the set, or if it can't find one just use that big red ? icon of Blizzy's. Then we have the option of a static or dynamic icon.
OK I agree with that tekkub. The stuff included with InvSort (default categories) can be included as a module inside InvSort that can de deleted out. And it can be defined in such a way that it'll look exactly like it would if it were an external plugin.
So I got PT groups working, but I need to talk to xele about it before showing off any code cause I had to change how the contains function works (well, I didn't have to but i defined my PT Categoies with anonymous tables and contains needed to be aware of that).
About Icons: that sounds like a great way to handle it. II'd probably have to be the first item in the set just for consistancys sake.
About rules being complicated: they range from simple to complicated. For PT, all it is is a call to ItemInSet. For some of the rules I came up with, perhaps it's a bit more clunky, but obviously it doesn't have to be. There are definately bugs that need to be hammered out before we start bitching too much about the content of rules.
Well 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?
I mean, the plugin structure in place is nice, I'll fully support it, I just think thatthe stuff xele is including with his download should just be modules. Performance impact is miniamal for a plugin/module here (which is NOT the case with Titan/Bosspanel addons) so I see no reason why they shouldn't just be modules in the core addon. The user can always choose to delete the lua files for a module if they want and it'd be fine, but the base sets shouldn't be seperate addons in my crappy opinion :P
If you conduct repeatable tests that show that there's a performance enhancement for having it as a single addon, I'll do it. All the tests I conducted, which are most of the ones I'm aware of, show that it's number of files, not number of addons, that has the highest effect on load speed and memory usage. And I'm sorry you have a crappy opinion. :P heheh
Hey xele, I was thinking about it at lunch/dinner... if the icon for a set isn't defined you should use an icon for an item in the set, or if it can't find one just use that big red ? icon of Blizzy's. Then we have the option of a static or dynamic icon.
+ Ramble's response
I kinda disagree with this. You don't want the little icon on the iconbar that's supposed to immediately scream to the user "THIS IS FULL OF POTIONS" to be dynamically changing on them every time they run out of mana potions or pick up a new Absolutely Terrible Health Potion. You want it static from the moment they start.
As for the "second" icon -- the summary button icon, for when the summary is empty? Sure, that could default to the "empty" slot icon, but it'll be confusing if you have "empty" summary with 30 empty slots, then "empty" ammo with 16 empty slots, both at the same time, visually no different. That's why the "empty ammo" has a separate icon.
I really think that someone, somewhere, needs to pick a consistent good icon for every rule. And if we're not actively defining every rule for the user (they make categories then and/or/not rules together, ala an Eng-like system), then the user needs a good way to pick icons. And as we all know, that leads to ugly, ugly, ugly interfaces.
Perhaps all new categories start with the ? icon, then you can right-click the ? icon and get a "set icon as..." option, which then lists the items in the rule? So you can set it in-game whenever you want? Same with Summary Buttons?
It looks like I'm gonna have a lot of context menus to write with the Eng-like rule builder and the icon selector... guess I'll have to go learn how THAT stupid XML works now... ::sigh:: Ramble, drop out of college and write this mod for me. please. :)
You're welcome! I know neither does the sorting that you wanted, but I'm actually interested in what you come up with. If you get PT/InvSort style sorting with a vertical "<miniicon> - name" tree-like inventory systtem, I might stop using InvSort. :P
You're welcome! I know neither does the sorting that you wanted, but I'm actually interested in what you come up with. If you get PT/InvSort style sorting with a vertical "<miniicon> - name" tree-like inventory systtem, I might stop using InvSort. :P
That's pretty much exactly what I had in mind :D
But right now I'm in the middle of a C++ project, so I won't be starting on this for a while =/
You're welcome! I know neither does the sorting that you wanted, but I'm actually interested in what you come up with. If you get PT/InvSort style sorting with a vertical "<miniicon> - name" tree-like inventory systtem, I might stop using InvSort. :P
That's pretty much exactly what I had in mind :D
But right now I'm in the middle of a C++ project, so I won't be starting on this for a while =/
AH well, that's too bad. :) Cheers to you when you do, thouhg.
Back on subject -
Ramble and I discussed, and I think we're going to fully integrate PT. As in, no module required. If PT is installed, it will use it. No default categories, PT is the source for them. So you win, tekkub. :) Me out. Fixing this stuff up.
-x
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
Name: InvSort (until further notice) alpha/beta.
Description:
Advanced Bags + Eng Inventory + One Bag + Tons of Awesome - Lots of Suck = InvSort.
For a more full description, check out the link above. I don't want to maintain two full descriptions.
All bug reports go in the portal, or they don't get listened to. :)
Discussion:
The reason this isn't in released mods is because we're changing the name, and it's still alpha in my mind. As soon as I go beta, and change the name, I'll put it over in released mods. For now, I only want people who are willing to accept that this won't do exactly what you expect all the time to use it.
I have a lot of TODO's for it, like write up a "how to make new/awesomer categories," and fix a few bugs I already know about. I would very much like to know what kinds of features people would like to see. Use the portal on wowinterface. Don't post requests here. DOn't post requests if you haven't used it. :)
Hope you all love it. I know I do.
-x
Fuck you, I'm tired and cranky and want to have my say (besids I'm probably repeating stuff you already know :P ) ... Beside I did look over your code, just didn't load up the mod.
Two things the mod NEEDS, if they are not already in...
First and formost, I'm sure you're quite aware that I wrote PeriodicTable with this (and a few other) addons in mind. There should be a nice, quick, simple way to add a PT set if PT is installed.
Second: Give the users a nice simple tooltip parsing interface for sets. Simple enough, the user defines a string (actually an LUA regex if they want) and anything that matches that string in it's tooltip is added to the set.
In the end there's really only a few set description means needed (though you've provided for any set that's definable in an lua function). Those would be:
Qualtiy (pulled from the API)
Empties (you already have)
Equipment types (again from the API)
PT sets (simple enough to add *grin*)
Tooltip parsing
I cannot think of any items that will not be sortable using one of these methods.
Also, be aware that PT provides some useful data that, in conjunction with the itemLevel data from GetItemInfo, can be used to sort the displayed items by quality. For example, all food and water items have a HP/MP recovered value if the item is consumable by the player (raw foods don't have values, they're available for pet-feeding mods really).
Anywho, PLEASE PLEASE PLEASE add PT support, it sholdn't bee too hard for you to do *grin* Do that and it's very VERY likly that I'll be abandoning EngInv very quickly, even for an alpha/beta mod.
Oh and someone else suggested Bank sort on WoWI, I wholeheartedly agree. My bank is such a mess nowadays! And from the LUA side it's no different, just the bank uses bags -1, 5-10 (or is it 11?) and the data is only accessable when the bank is open... unless you pull the info from KCI (which you should if it's installed!)
Okey enough ranty, more sleepy.
Yeah. "if they are not already in..." doesn't apply here. Sets aren't specific to the Inventory Sorter itself. It's like BossPanel Addons. BossPanel == InvSort. BossPanel_Experience == InvSort_PriodicTable
That way people can write their own categories that depend on other mods, like PeriodicTable,etc. I'll give you an example:
InvSort_RegularExpressions = AceAddon:new(...) InvSort_RegularExpressions:Initialize() InvSort:RegisterCategory({ name="Tooltip RegEx Scan", description="Scans tooltips of items and includes them if the regular expression is found.", usesnormalview=1, iconpath="Interface\\Icons\\INV_Misc_QuestionMark", contains = function(index) tooltiptext = FunctionThatGetsTooltipText return strfind(tooltiptext, self.get("regex"))>0 end, }) endThat, right there, along with a command-prompt to self.set("regex"), is an additional addon you could release that provides a RegEx functionality for a group. Guess what? Same with Periodic Table. Same with Wardrobe. Same with KC_Items. Etc, etc. You can release any categories you want. Or you can write your own little personal ones.
The goal is for the basic package to include very basic, simple categories, then to let people introduce others. I plan to release the PeriodicTable one myself, as soon as the base system is stable, 'cause I'll be using that one. I won't use the Wardrobe one, but people requested it, so I'm hoping someone writes it. I will probably also release another one that adds AutoBar functionality...
I can think of tons, and just because they are sortable doesn't mean that's how a user wants to sort them. I very actively sort blue and green equipment into multiple sets, I like to sort my alchemy stuff into: buyable parts, herbs, potions i make and don't use, potions i make and use, and mana/health pots. There's five categories you didn't list. :)
Yeah, I know. And if you'd like to write the PT categories, feel free. :) I'll write them to the best of my ability, using everything I can see in PT. In fact, I even plan to send you PMs when I'm writing them to make sure I get the most out of PT.
Yeah. Honestly, as soon as I'm comfortable using IS instead of another bag (which starting today, I think is fairly likely), I'll be writing at least a basic PT set.
I plan to add bank support as soon as I can. I may rip out the AceInventory support, 'cause I actually think it doesn't help as much as was originally intended, and it makes some things more confusing. Either way, the only things stopping bank support right now is AceInventory. And I'll be adding it soon. Now the question is:
PT, or bank support? which is more important?
I'll probably add bank support before making my own PT categories, since bank support is a basic fundamental need, and PT categories are just good ideas. :)
Hope sleep's going well.
Blue/green, I said item quality did I not?
"that I use" sounds like a user-defined set, which you seem to already have
buyable parts - PT
mana-health pots - PT
potions I make - PT's tradeskill module
:P
BTW I'm sure you already know, don't take any of this the wrong way. It's all construtive criticism. I desperatly want to drop EngInv, but I'm gonna have my say in the mod that replaces it. I've already written PT for sets, and there's also my AceTooltip for the tooltip parsing if you want. In the end the only reasn I've not put this bugger together myself is the simple foct that I hate XML. Maybe that'll change in 1.10 *grin*
I haven't looked at PT much since xelepart took over the main coding for InvSort. But if I understood what i've read it do handle a bunch of the sorting type stuff we'd want to do. But suppose I want a group for my FR gear? Or a group for my engineering trinkets? All green+ items that aren't soulbound? Are those trivial to implement in PT?
(that was one lousy atempt to avoid the firefight, bringing up the heated topic right away)
Anywho... a handful of comments/bug reports:
* Empty slots is showing 32, I've sold some stuff, picked up some stuff from AH, and now I have 30 empty slots. The text in the empty slot never updated.
* Ammo slot: I'm a rogue, I have my crossbow equipped and I carry one stack of arrows. The ammo loads the right icon, but it doesn't count any ammo. (I show 0 in the icon, and I mouse over and it says "Ammo (empty)"
* What happened to the mouse over a group and it shows you the contents? Or was that only in my latest local copy... Anywho, I wanted the groups to have the functionality similar to my XRayVision mod, where you can see what's in the group without actually opening it.
User-defined classes, add items one-at-a-time.
Tooltip classes, match all items that say "Bind on Equip" for instance
PT's classes, covers stuff like consumables, reagents, tradeskill ingreds. tokens (ZG/AQ) and a lot of other things
Tradeskill data, also can be gotten from PT
Equipment types, quest items, item quality - some of the only useful sorting info available from GetItemInfo
Empty slots, ammo and soul pouch slots - kindof a combination of API and PT here, PT has itemID's for the ammo/soul bags. Emties can be decerned using the API
I'm not trying to sound like a jerk or anything, but I really don't like the plugin idea. I can wholeheartedly see each of the grouping option as a module within the main program, but totally seperate addons does not make sense to me. The code needed to create a set is too much, and it sorta forces the user into learning lua. The other thing that bothers me is the ability he added to use a list of itemID's. That's really all that PT does is maintain lists of ID's, I put a lot of work into making it use the minimal memory it can at all times.
*shrug* I dunno I'm just seeing lots of things being implemented that I put into PT specifically to make this mod easy, and they're not getting used. When I wrote PT I had three mods in mind specifically... Sorted AIOI, Autobar and PetFeeding. I'm well aware there are many other uses for PT, but my focus was to provide a simple mechanism for classifying and sorting items by worth.
Speaking of bag mods, are there any that present the bags in a list? I mean, like:
And if not, do you think it'd be possible to mod InvSort to look like this? I've been thinking about making a list-type bag mod for a long while now, but itfeels like such a huge beast to tackle. But maybe if I could use InvSort (or maybe some other mod?) as a foundation, it'd make my life a helluva lot easier.
* I understand PT just fine, and I fully plan to make everything you want PT to provide easy to do.
* You obviously don't understand my design of IS.
* User's don't write lua, modders do. Users download mods. Once you or I writes the PT portion of IS, nobody else has to write any lua.
* I hate the list I provided as well, but I didn't want to change Ramble's original rules, and he had them. :P ::points the blame away:: -- I think I'll remove those any way.
I decided you may be right. The actual bulk required to integrate PT as an optional dependancy is minimal.
But I'd just like to point out that "lots of things being implemented that you put into PT specifically to make this mod easy" -- nothing is being implemented that you put into PT. Simple, very basic categories are included right now for testing purposes. I would actually expect almost everyone who wants this mod to use PT as well, and use the PT categories module.
Check out Posessions here. -- it doesn't sort by category, it sorts alphabetically. But I bet you could do a few changes here and there and incorporate PT into that, and it'd rock.
I'm going to start a new post here for design discussion.
One thing I *REALLY* don't want is a big clunky UI to set up new categories. I hate that about ABF. The reason I originally designed it as modular is because there's no good way to make up "new rules" unless you're really interested in getting your hands dirty. The average end-user wants to log in, pick some bag types they care about, force certain items/exceptions by moving items into and out of bags, and that's it. Normal people don't want to go "okay, I want a bag that includes blue or rarer items, and a bag that includes green armor and weapons, and a bag that includes all my alchemy supplies, except health and mana pots, and a bag..." -- they want someone else to come up with good bag ideas, then to see a mod described as "this mod gives you options for trade skill bags" and to download that if they care about them.
Learning how to properly use a huge clunky complex rules system for bags is nearly as bad as learning lua, and half the people who would learn the complex rules probably already know lua. and most people are going for similar bag concepts (ex: PT bags). That's why I decided that a simple "is the item in bag b, slot s in you rule?" function definition was the best way to do it. It's simple lua to understand, doesn't require much extra work, etc.
In coding the system, I realized there's some extra information:
Is this a rule that summarizes information (empty slots, auto-bar-like functionality, etc), or is this a rule that shows you a bag? Both work the same way, one rule could provide both options, etc. So you need a way to say which type of rule a new rule is. Summary, Normal, or Both.
If it's normal, it needs an icon for the icon bar and the frame. So you need a way to specify the icon path. And I don't want to do what ABF did, and provide 600 icons, so if you want a custom icon, you'd have to include that is an addon anyway.
If it's a summary view, it needs an icon to indicate which summary it is when it's empty (if it has items in it, it uses the first item's icon so you know what you'd use if you clicked on it.) So you need to include a way to set the summary view icon.
You need a way to describe what's in the bag. Some people might just was "/is addptrule food" but someone else might want "/is addptrule food and water" and someone else might want "/is addrule potions and not (mana potions or healing potions)" ... and now you're talking a complex logic parser, or a complex gui, to provide the PT grouping systems someone might want. Or you need an "/is alterrule rulename add/remove :type:"
So you want to provide all the options you expect people to want to use either as defaults on, or with a single "/is toggle foodandwater" and "/is toggle buffpotions". This is another reason I did it the way I did -- let someone who has the time and desire to come up with good ideas come up with them, make them powerful, and provide a simple access method for end users.
Furthermore, you also need to know how the user wants something sorted. Alphabetically, by level, by set, by type, by heal value, by rarity, in the order you found it, etc, etc...
So, we need:
a rule type.
a way to identify up to two icons.
a complex definition system for what is contained in a rule.
a sorting system.
How do you think we should approach this? I don't want complex series of /commands like Visor, I don't want a complex bloated UI like ABF... Perhaps something like EngInventory? Here, let me discuss:
"/is newsummary Rulename Iconpath" (or newnormal, or newboth, with two iconpaths)
makes a new empty rule that uses the summary view. (or normal, or both, obviously)
Now, you have the normal UI. If you RIGHT-click the icon or the summary button, you get a context-sensative menu that lists all the concepts the system knows about.
For instance:
Level 1:
NormalInfo ->
PT Info ->
TooltipInfo ->
Level 2:
Pt Info->
Healing Potions
Mana Potions
other categories... etc...
etc...
Now you can use that to check and uncheck the various concepts to make a rule. Everything that is checked is OR'd together:
Healing Potions OR Mana Potions etc...
Followed by an AND NOT (...) for anything that you put an X next to. ...?
That still seems kinda complex, but relatively straightforward. Still, making new rules requires the end user to know what the icon path they want is...
So, what's the proper way to do this? I mean, I could write exactly the default rules that *I* want, and just let people set up exceptions however they want, but the goal is to allow a powerful extensible system that lets everyone sort things the way THEY want.
Which brings me back to not integrating PT in the first place. Just because *YOU* want PT doesn't mean everyone else will. And the PT rules will be just as easy to write and provide with the current system as they would if I integrated them.
So now I'm wavering again. :)
So, instead of telling me about how you think modules don't make sense, and how end uses shouldn't write Lua code, and how you designed something to make my life easier, even though end users don't write code, modules make perfect sense and are used in all the most popular mods, and I'd still be using everything you designed just as much whether or not it's in a module... why should PT be part of this? How do I solve the problem of a complex interface that can be made a hundred times less complex by limiting the people who actually use it to Lua modders, and providing a very simple striaghtforward end product for most users?
"Here are the rules we made. You can add exceptions to them." And let people who have the time and effort and know-how and desire add new rules they can pick from. I honestly don't see any good argument for why it should be any other way. :) So, propose one, make it clear and make sense.
-x
http://www.curse-gaming.com/mod.php?addid=2345
That's the one I was thinking of, not Possessions.
-x
Well 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)...
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'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?
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 ^^
And just so you know, I'm toying with making PT sets right now with out rule structure. I'll come back with some codein a few.
I mean, the plugin structure in place is nice, I'll fully support it, I just think thatthe stuff xele is including with his download should just be modules. Performance impact is miniamal for a plugin/module here (which is NOT the case with Titan/Bosspanel addons) so I see no reason why they shouldn't just be modules in the core addon. The user can always choose to delete the lua files for a module if they want and it'd be fine, but the base sets shouldn't be seperate addons in my crappy opinion :P
Hey xele, I was thinking about it at lunch/dinner... if the icon for a set isn't defined you should use an icon for an item in the set, or if it can't find one just use that big red ? icon of Blizzy's. Then we have the option of a static or dynamic icon.
So I got PT groups working, but I need to talk to xele about it before showing off any code cause I had to change how the contains function works (well, I didn't have to but i defined my PT Categoies with anonymous tables and contains needed to be aware of that).
About Icons: that sounds like a great way to handle it. II'd probably have to be the first item in the set just for consistancys sake.
About rules being complicated: they range from simple to complicated. For PT, all it is is a call to ItemInSet. For some of the rules I came up with, perhaps it's a bit more clunky, but obviously it doesn't have to be. There are definately bugs that need to be hammered out before we start bitching too much about the content of rules.
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.
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...
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?
-x
If you conduct repeatable tests that show that there's a performance enhancement for having it as a single addon, I'll do it. All the tests I conducted, which are most of the ones I'm aware of, show that it's number of files, not number of addons, that has the highest effect on load speed and memory usage. And I'm sorry you have a crappy opinion. :P heheh
I kinda disagree with this. You don't want the little icon on the iconbar that's supposed to immediately scream to the user "THIS IS FULL OF POTIONS" to be dynamically changing on them every time they run out of mana potions or pick up a new Absolutely Terrible Health Potion. You want it static from the moment they start.
As for the "second" icon -- the summary button icon, for when the summary is empty? Sure, that could default to the "empty" slot icon, but it'll be confusing if you have "empty" summary with 30 empty slots, then "empty" ammo with 16 empty slots, both at the same time, visually no different. That's why the "empty ammo" has a separate icon.
I really think that someone, somewhere, needs to pick a consistent good icon for every rule. And if we're not actively defining every rule for the user (they make categories then and/or/not rules together, ala an Eng-like system), then the user needs a good way to pick icons. And as we all know, that leads to ugly, ugly, ugly interfaces.
Perhaps all new categories start with the ? icon, then you can right-click the ? icon and get a "set icon as..." option, which then lists the items in the rule? So you can set it in-game whenever you want? Same with Summary Buttons?
It looks like I'm gonna have a lot of context menus to write with the Eng-like rule builder and the icon selector... guess I'll have to go learn how THAT stupid XML works now... ::sigh:: Ramble, drop out of college and write this mod for me. please. :)
-x
You're welcome! I know neither does the sorting that you wanted, but I'm actually interested in what you come up with. If you get PT/InvSort style sorting with a vertical "<miniicon> - name" tree-like inventory systtem, I might stop using InvSort. :P
-x
That's pretty much exactly what I had in mind :D
But right now I'm in the middle of a C++ project, so I won't be starting on this for a while =/
AH well, that's too bad. :) Cheers to you when you do, thouhg.
Back on subject -
Ramble and I discussed, and I think we're going to fully integrate PT. As in, no module required. If PT is installed, it will use it. No default categories, PT is the source for them. So you win, tekkub. :) Me out. Fixing this stuff up.
-x