Resolving Conflicts Between Rules and Categories [Question]

[boddoleblitzer]

So I've got a lot of both default and custom categories setup for my inventory and generally it does a good job of managing all my items. However, items inevitably show up that don't fit default categories or I just haven't accounted for them. So I'm trying to end up with 2 general 'boxes' of otherwise unsorted items - 'bound' and 'unbound' (and I've already got the default 'bound' category which manages to miss lot of items).

So I made a rule that is just "bound(3)", which does seem to grab all the other bound items not caught by the default categories. The problem is that (I guess) because rules supersede categories, it also grabs all the other bound items that have already been sorted into boxes and just makes things worse than they were before.

So, is there a way to accomplish what I'm trying to do with this add-on as it currently is (that doesn't rely on configuring every single item that won't use default categories)?

[arkayenro]

default category > rules > assigned category (custom or system)

the system>bound category is a failsafe, it will only pick up item that cannot be assigned to any other category and are soubound. its not meant to pick up every soubound item, theres too many that belong in other categories.

your rule is too broad, youre pulling in all soulbound items regardless of type. you need to limit it further, specially to just what you want collected.

what soubound items are not getting categorised the way you want? is their default category wrong, or it just happens to be a soulbound item in that category?

typically you do create custom categories and manually assign each item to those. its typically a one off thing as new items turn up, and assigning a category is pretty simple now that drag and drop works in edit mode

[boddoleblitzer]

Took another look in my inventory, thought about it a bit-

So what I'm seeing are generally issues caused by items that I don't want to create boxes for, and items that fall into 'odd categories - I'll elaborate. So I often end up with lots of 'trade goods' and 'skill' items that get bound to me, but I don't see it as a good solution to need to make a box with a rule that includes strings of every trade good & skill category that also have the bound attribute - same goes for adding in all the more obscure item categories like 'item enhancement' (just one I happened to notice).

It would seem to me that the much more 'to the point' solution is to try more/less what I did, make a rule to grab bound items that are not already sorted into another box. Or for this add-on specifically, make an item 'aware' of if it has been sorted into a box or not (and if not, go to the 'system-bound' box if it exists). Or perhaps an addition to the hierarchy - 'new thing' > default category > rules > assigned category.

Just some thoughts.

[arkayenro]

sb( ) and type( 7 ) will collect all soulbound tradegoods sb( ) and pt("Tradeskill.Tool") will collect any soulbound tradeskill tools

caused by items that I don't want to create boxes for

what are some examples of these items? its possible their default isnt correct (that i can fix but its also what hard assignments are for). if theyre a one off then youll need a custom category, or hard assign it to a system category. if its a whole bunch of similar items then you create a rule for them.

Or perhaps an addition to the hierarchy - 'new thing' >

there isnt a "new thing". every item has a default category, worse case they fall into one of the generics (soulbound, tradeskill, misc, default), but they all have one - where you assign those categories has no bearing on what default category they are assigned. any category you dont assign to bar will go to the bar the default category is assigned to

[boddoleblitzer]

Took some more time to think about this- (and thank you for humoring my questions, and just for the record I think this is -by far- the best item management add-on)

-I'm sure there is a reason you didn't set things up this way, but to me I think Rules would be nice if they had more 'priority control', such that you could change the priority to be something like [rule x] > default category > [rule y] > assigned category (custom or system) > [rule z], and just let the user decide how they want to structure things. So in my case I could use the very general 'bound(3)' or whatever, and let that apply unless a box with a higher priority category/rule/assignment exists.

[these relate to your last reply] Also, for me things get very confusing around crafting/trade/reagent items (among other things) in general. Mote of Harmony and Windwool Cloth are two such items I've got in my inventory right now - They both say "crafting reagent" on the tooltip, but Motes are 'Trade Goods>Elemental' and Windwool is Skill>Tailoring. So it gets confusing on how to write rules / make boxes for all these types of items.

So you gave me the "sb( ) and type( 7 )" example and just to try something out I did just 'type(7)' to see what would happen. It pulled the Mote (ok, expected that), but it also pulled Windwool (which surprised me) because Windwool is listed as reagent, defined as a 'skill'. After looking at the debug menu I noticed the tradeskill attribute, but that's 3 'attributes' just for one item, add in all the other items that may need sorting and things get really confusing.

"caused by items that I don't want to create boxes for" "what are some examples of these items?" -Something like "Rook's Lucky Fishin' Line" (increases fishing skill) (Consumable>Item Enhancement), items that are relatively obscure. As it is now (I think) to get what I want I'd need to make a rule that grabs every single attribute type that I don't want to make box for + sb(whatever), and then erase attributes if it turns out later if I do make box for them. Not to mention trying to do that will inevitably 'steal' other items from more appropriate boxes. Basically I just don't think what I'm trying to do is possible currently.

-Just another thought, maybe on the function help pages like https://github.com/arkayenro/arkinventory/wiki/RuleFunction_ItemType, list all the possible types/values so that users can be more proactive in setting up their rules rather than having to wait for individual items to show up with a certain type/value then re-write to account for them.

Thank you again for your time.

[arkayenro]

They both say "crafting reagent" on the tooltip, but Motes are 'Trade Goods>Elemental' and Windwool is Skill>Tailoring.

if its doing that then you have tailoring and its trying to be helpful. if you dont care to have crafting reagents that are for one of your skills assigned to its skill category then you can change that in the config. depending on which version you have its either under config > general > professions options, or config > profiles > controls > professions. set the priority to ignore.

Something like "Rook's Lucky Fishin' Line" (increases fishing skill) (Consumable>Item Enhancement), items that are relatively obscure.

those (the lures are the same) i can fix via the internal periodictable, ie this would default to skill > fishing instead, but these sorts of items are going to come up, and its why you have the ability to reassign them

list all the possible types/values

some do, but then blizzard change them, so its easier to have people look up the current values from the in game item debug menu when they are writing their rule instead of complaining that the wiki page is out of date (i hardly ever update them as they dont change much from my side)

I think Rules would be nice if they had more 'priority control', such that you could change the priority to be something like [rule x] > default category > [rule y] > assigned category (custom or system) > [rule z], and just let the user decide how they want to structure things.

you cant write a rule that picks up entire classifications and then want a specific category to have "priority" and not be in the rule, change the rule so it only picks up the items you want, or if its just a few items you want excluded then hard assign a category to them.

the code is a sequential check; is it hard assigned?, is it a rule (checked in priority order)?, no, then use the default (which was calculated way before this).

the default is the fallback when everything else fails so im not sure how im supposed to code it so that the default can ever "win" - its why i created custom categories, and hard assignments, that was the only way to let a category override a rule

if a rule can override a hard assignment then why assign a category to it in the first place, the rules going to pick it up anyway?

i can sort of see where youre coming from but i think it might end up causing a lot more confusion than what i have now. theoretically i could code it so that the "rule" list ends up with hard assigned categories, and custom categories, as well as rules all in there but im pretty sure people are going to just ignore it for being too complex. plus the default is always going to be the default, it never going to override anything

[arkayenro]

actually there is one way to have a default "win" and thats by allowing the categorisation code to exit at that point.

the default categories would be set to continue checking but have an option to exit if matched resulting in the default category "winning" the assignment and all rules, system and custom categories, are ignored for it

the list could get get pretty big and ugly though, youd have default categories, repeated for hard assignments, custom categories, and rules, all in one really big list - even if you had no rules or custom categories it would still be fairly long

im presuming youd want all the categories listed individually and not as a single entry that covered all of them?

[boddoleblitzer]

"if its doing that then you have tailoring and its trying to be helpful. if you dont care to have crafting reagents that are for one of your skills assigned to its skill category then you can change that in the config" -good to know.

"those (the lures are the same) i can fix via the internal periodictable, ie this would default to skill > fishing instead, but these sorts of items are going to come up, and its why you have the ability to reassign them" -right, I'm not complaining about how its classified - just wishing I had a more general way to control it (these types of items) that didn't require manual intervention.

"some do, but then blizzard change them" -ahhh, totally understand.

"i can sort of see where youre coming from but i think it might end up causing a lot more confusion than what i have now." -I can see that, the ability to confuse people because they have 'too much' control - more on this below.

==== "you cant write a rule that picks up entire classifications"

"the code is a sequential check; is it hard assigned?, is it a rule (checked in priority order)?, no, then use the default (which was calculated way before this)."

"im presuming youd want all the categories listed individually and not as a single entry that covered all of them?"

-Its tough trying to explain/understand all of this just in text, but I'll try to layout how I could see this working - of course how much re-working on your side this could cause I have no idea.

I sort of see the system as being more/less as it is now, just instead of completely separated tiers, everything can be assigned a priority value.

EX: 'Priority values' range from 0-9999 (like rules currently do? or whatever range makes sense).

So range 0-1999 could be empty, 2000-2999 could be where the 'defaults' are, 3k-3999 empty, 4k-4.999 being where the rules are, 5k-5999 blank, 6k-7999 being where hard assignments / custom categories are, 8-9999 being being blank (something like that).

In this way, the program behaves the same general way by default, "the code is a sequential check; is it hard assigned?, is it a rule (checked in priority order)?, no, then use the default (which was calculated way before this)." So theoretically an already existing user's setup would evaluate the same as before the change.

The difference being that -if desired-, the user could change the evaluation order to whatever they want. And the key point being that the system would know the difference between an item simply having a default category versus that category actually existing in the user's setup (ie. if an item's default is 'fishing item', it should be smart enough to check if any user boxes actually contain that category, and continue to search if it isn't found).

So going waaay back to my old example, lets say I've got a bound 'fishing item'. The system starts at 9999, searches down until it finds the default category, realizes I'm not actually using it with any boxes, then finds the 'bound(3)' rule which is somewhere from 0-1999 and realizes that I do have a box that uses the rule, and sorts it accordingly.

As a fail safe, an item with no matches could be dumped into 'box 0' or make a 'anything' category at priority 0 (since I'm not sure on how everything gets handled).

====

Hopefully that sort of explains how I'm thinking of it...

[arkayenro]

basically you want the ability to rearrange the system and custom categories within the rules, one big list of entries that you get to decide what order they are processed in, and in the case of the defaults, if they exit at that point instead of going on to look for a custom category or rule. which makes sense, and is probably viable.

checking if youve assigned the category to a bar already is possible but probably not a viable method to check if youre actually interested in that category. eg i use the same profile/blueprint across all my alts and have categories for all the skills assigned to bars. i dont care about the skills i dont have but it lays out properly for the toons that have them.

i have most of the categories laid out even if theres practically nothing in a lot of them. i do it that way because when an item does turn up for that category it will be where i want it and not clumped up in the default bar

also, the code will have no clue as to what a rule does. from a code perspective its a function that takes an item and returns true or false. if true i assign that rule id to the item, if false i keep processing rules. theres no real way to know for sure what it relates to.

[boddoleblitzer]

"checking if youve assigned the category to a bar already is possible but probably not a viable method to check if youre actually interested in that category. eg i use..." -Right, I mean I don't expect the program to magically know what I want after all. I was just making the point that the system would need to be able to determine if it should continue looking past 'default categories'.

"also, the code will have no clue as to what a rule does" -I'm not seeing what problem that would cause. Ultimately if the item is not assigned any ID, no sorting occurs in the rule context / and if it is, then it will get sorted at the appropriate time? So in this theoretical system nothing is different other than it could be evaluated for sorting much later on than it is now, but everything else is the same.

--