@Random, I took a short look at FcoisMarking and it definitly is possible but not very beautiful, neither in code nor for the user, as I didn't have that in mind when I wrote RbI. Same is partially true for a task "use item" as the actual functionality of "use" depends heavily on the item it is used on. Using a potion is an easy thing but a container needs to be looted too, with checks if space is available and such things. I know you linked code examples for this specific case, but I fear there is more to it than that and other item types as well.

While searching for a way to delay LLC and DLWC I did on the side implement a feature with which one does not anymore need to switch tabs at a crafting station and all tasks for the current station (refine, deconstruct, extract) can be executed immediately on interacting with the station. Thus said, when LLC or any other addon tries to craft or interact with the station there can be a race condition preventing either the other addon or RbI from succeeding, resulting in an output of success on RbI's side, maybe without it ever actually happening (and I don't even know what consequences for the other addon on failure).

Dolgubon (Author of LLC/DLWC) hinted me towards AutoReseach, an addon which delays LLC/DLWC execution till after it is finished, but I merely removes the event listeners of LLC/DLWC and calls their functions after it is finished manually. If I where to implement the same, I would need to check for AutoReasearch and remove it's event listeners to then call it, when RbI is done, or do the same as AutoResearch to LLC/DLWC, if AutoResearch is not around.
That's just too sketchy and who knows which other addons do the same which then would need a chain of these event listeners removals and oh gosh no. just no. ...
So, regarding LLC/DLWC, non of my attempts worked and as long as there is no feature introduced to LLC/ DLWC I would have to really fiddle, which at this point does not seem appropriate in my eyes.
If you have any idea, please let me know.

Regarding your guide, please share it with me/us when you're done, I would love to see an introduction to RbI written by a user.
Both the Wiki and RbI in general would probably profit highly from this

Hi Akopian, thanks for considering RbI. Until now I have had never heard of ItemTrig before and from what I just read and saw on it's page I might never had developed RbI, if I only knew it was there (EDIT: oh wait, it just wasn't around back then). That said, from the given overview it actually seems more complicated to me than RbI even with RbI not providing an interface helping you to design the rules. This might be due to me having written it and having studied computer science, so I am very familiar with the boolean rule structure RbI uses.

RbI has defined "Entry points" (ItemTrig term) for each "action" (ItemTrig term) which in RbI are called "Tasks". The "rule" (RbI term) you have to write is the "condition" (ItemTrig term).
I am confident that anything possible in ItemTrig, as long as a Tasks exists matching the "entry point" and "action" of ItemTrig, is possible with RbI too, maybe with even more granularity available.

Nothing is stated about multi-character setups other than that you can import a trigger from another character or the gallery, my understanding of this is of cause vague to say the least.

First thing RbI is capable of is a differentiation of characters inside a rule itself. With for example the integration of craftstore (another addon) RbI is capable of checking if the current character is the first in line of a given list of character names who needs to learn a recipe. So one rule can be used for all characters and will evaluate differently on each one!

Second, RbI always execute a Rule on an item, like ItemTrig would do too, to see if it fits, or not.
To make the process of writing easier rules can be combined to RuleSets containing rules in two buckets:
EVERY rule for the first bucket has to be true for the item to be considered,
and ANY of the rules of the second bucket needs to fit the item too.
This allows for easy reusing of rules and allows users to keeps the size of rules small.
Individual rules can be added to tasks (which automatically form an ruleset internally)
or a whole ruleset can be saved of this and later loaded.
Both each rule and each created (not intenal) ruleset are available to all characters.
Editing a rule or ruleset on one will change them for all.

Last, the RuleSets (both created and internal) assigned to all available tasks can be saved to a profile to easily "copy" them to a different character.
Editing a profile on one character changes it for all, so you never have to do the work twice.

Please see the wiki for more information on rules, rulesets, tasks, profiles and what terms/functions to use in your rules.
If you have any further questions or encounter difficulties, feel free to ask.


Yes, sorry this is a too hard solution for me to take.
But don't worry I am still trying to figure it out, only encountering some slight problems with LLC and DLWC interactions. I am trying to delay all RbI execution to AFTER these are done on any interface (station/bank). Or do you think it would be better to delay THEM? Both routes have pros and cons...

Please report if even with the update you encounter the problem again, maybe even go down with delay again to make it uhm easier to crash. Please also check if RbI in any case touches the items DLWC want's to move, that could lead to a slot beeing empty (because DWLC moved it) and RbI trying to move it too. Thanks!

I'll try to push an update this week, hopefully fixing the lua error you're getting, though a bit hard without knowing its origin...

No, this will always return true if ANY writquest is active, regardless of if DLWC want's to draw from bank or not. Thus it would delay/prevent bank interaction of RbI indefinitely if one does not turn in a writquest for whatever reasons and is therefor not a considerable solution for me.
For crafting though I think I have found a solution, delaying all processing of RbI for the time LLC is still working at given station.

@Random, is by chance this strange move from/to bank because of the quickslotted happening when the error occurs?

huh there you're saying something I wonder about. How did a locked item go past the safety rule O.o
Need to investigate this asap. thanks!
EDIT: never mind, junk is classified as a non-dangerous task, so safety does not apply here. I updated the wiki to better clarify this distinction. In short, safety is only in place for Sell, Destroy, Fence, Deconstruct and Extract as those changes can't be reverted.

Does your rule touch the things DLWC is moving? And of cause the fix for quickslotted() isn't there yet (testing in progress). This seems to be a problem tied to one of these, as it appears mainly, in my thinking, when RbI does think there would be an item in a slot when in fact it is not.
I use FCOIS to mark all writ items with a custom marker and those from RbI, this might have always prevent errors. Again, until I will update this (taking your code into account, thanks, I am also in contact with Dolgubon), please try to increase the delay before a tasks starts a little more.


Thank you both for your feedback, reports and patience!

@Talegas: I will look into the issue with the collection functions as soon as I can.
EDIT: Found it, you just can't junk ingame locked items, I did not know that and well, FCOIS locks are excluded in generally, so, as your rule does not explicitly say "not locked()" RbI thinks it needs to junk it, while it can't. I will see to exclude ingame locked items generally from junking, I guess. Same for Selling, Fencing, Laundering, Destroying, Refining and Deconstructing.

@Random:
1) I will look into the issue with quickslotted as soon as I can.
EDIT: Found the problem, it lies in the speed RbI has when processing items. As quickslotted() looks at the bag/slot instead of an itemLink to tell if the item is quickslotted it encounters a problem when it reaches the slot RbI just put things to, as the game not yet knows they have been put there and the slot is still empty, thus not quickslotted, the rule failes and RbI puts it back to the bank (because RbI knows it's there and by the time RbI processes the next batch it is).

2) There is an option to increase the delay before the interactions are called, try increasing it to not interfere with DLWC. I will look into a delayed call when DLWC was detected running. A LUA error I never encountered, though RbI was working simultaneously with DLWC, but my rules are not interfering with DLWC, so it might have to do with that. The only error I sometimes get is from Advanced Filters when DLWC opens and closes the bank.

3) I thought about a "use" task before, yes. Now that I know it is a feature someone wants I will try to find time and see to implement it. No promises though, let me first fix the above mentioned bugs and then let me see what I can do.

Thanks for sharing your use of RbI, hope it can be of help saving time in the end.
Spread the word to your guildies