Download
(109 Kb)
Download
Updated: 10/22/23 04:35 PM
Pictures
File Info
Compatibility:
Endless Archive (9.2.5)
base-game patch (9.1.5)
Necrom (9.0.0)
Scribes of Fate (8.3.5)
Firesong (8.2.5)
Lost Depths (8.1.5)
High Isle (8.0.0)
Updated:10/22/23 04:35 PM
Created:09/11/18 09:42 AM
Monthly downloads:198
Total downloads:26,618
Favorites:55
MD5:
Rulebased Inventory  Popular! (More than 5000 hits)
Version: 2.31
by: TaxTalis, demawi, otac0n

Automated item distribution/action management (Bag, Bank, Junk, Use, Deconstruct, Sell, Fence, Launder, Destroy, Notify, CraftBag, FcoisMarking), where YOU rule! (this means: YOU have to define the rules yourself) (>>Wiki<<)

What does it do?
After installing it, it does nothing. It’s simple as that.
You have to define rules for different tasks which then are executed automatically. Please see the Wiki for further documentation (after that you can ask your questions here in the comment section or at RbI-ESO Discord)

Automated Tasks are:
  • Bank-related (task starts when opening the Bank UI)
    • BagToBank moves items from Backpack to Bank (also with Homebank-Support)
    • BankToBag moves items from Bank to Backpack (also with Homebank-Support)
  • Itemupdate-related (checks the specific item, when it comes in changes its status, like 'junk'-flag)
    • Junk marks items as 'junk' (there also exists a consistency mode option for UnJunk)
    • Destroy destroys defined items
    • Use uses items (like type('fish'), type('container') or type('recipe'))
    • Notifiy notifies the user, when a defined item is looted
    • CraftToBag moves items from CraftBag to Backpack (also triggers after eso automatic to craft bag transfer)
    • FCOISMark marks items with FCO Item Saver markings (there also exists a consistency mode option for FCSOISUnmark)
  • Vendor-related (task starts when opening the Store or Fence UI)
    • Sell sells items
    • Fence fences items
    • Launder launders items
    • Buy buys items
  • CraftingStation-related (task starts when opening the crafting station UI or the respective tab)
    • Deconstruct deconstructs items
    • Extract extracts items
    • Refine refines items

Other automation gimmicks:
  • Auto open bank/shop/assistant
  • Auto close bank/shop/craft (at station and or assistant) after RbI work done
  • Auto despawn assistant

Needed libraries
Recommended libraries
Supported optional addons and libraries
  • FCOIS (check and set item-markers)
  • CraftStore (adds functions to check what your others characters need to learn or already learned)
  • LibPrice (adds given price informations)
  • AutoCategory (check the autoCategory-names)
  • LibSets (check types of the set)
  • WritWorthy (adds costpervoucher-function)
  • LibTextFilter (support for LibTextFilter's extensive syntax in addition for 'freetext'-parameters)
  • AlphaGear (adds alphagear-functions)
  • Dolgubons Lazy Writ Crafter (compatibility with working queue and station closing)

Special mentions/thx to the following addons for some functions:
Special Key Features
  • take actions on specific amounts of an item, not only on a whole stack (e.g. keep only 100 lockpicks in inventory)
  • check if your current character is the first one of a defined list in need of an item for research or a recipe to learn (so you can "hand down" a recipe if your main crafter doesn't need it to your secondary and further) (CraftStore needed)
  • save profiles and load them on multiple characters
  • a notification will include pricing (provided by LibPrice if installed), count of vouchers for masterwrits and the count you have in backpack, bank and craftbag
  • ...

YOU ARE USING THIS ADDON AT YOUR OWN RISK!
I will not be hold responsible for any damage or inconvenience this addon might cause for any reason.
This said, I have tested this addon on my main account for quite some time and try to do everything I can to make your experience with this addon as good and as safe as possible.
I admit, this is not an addon for everyone. There is no interface defining the rules for you by clicking buttons, you have to insert them by text. (See the mentioned Wiki for this.
A wrongly defined (but valid) rule may cause severe damage when fencing, destroying or deconstructing as the items will never return after such an action was taken.


Features and fixes in development (or at least considered)
  • ... see Wiki-Roadmap for further information. Currently it's a lot but we're always interested in your ideas.

Cumulative change log for version 2.31
  • added: AwesomeGuildStore integration. Recommended to use a rule reference, like `rule('Recipes for Main')`
  • re-fixed: text filter for `tag` function (sorry!)

Cumulative change log for version 2.30.2
  • references to the removed function IsInTutorialZone have themselves been removed.

Cumulative change log for version 2.30.1
  • bug fix for tag()

Cumulative change log for version 2.30.0
  • added characterLevel(), characterLevelMin(...), and characterLevelMax(...) functions.
  • added hasQuest() function, using quest name. ('Glitter and Gleam', etc.)
  • added characterName() function (similar to isCharacter(), but supports e.g. creator(characterName()))
  • added 'my_house' to ZoneTypes.

Cumulative change log for version 2.29.13
  • prevent unconstrained purchase by the Buy task.

Cumulative change log for version 2.29.12
  • removed references to FISHING_MANAGER for compatibility with upcoming releases
  • fixed: buy interaction now updates cache to prevent duplicate purchases

Cumulative change log for version 2.29.11
  • added buy interaction along with supporting functions: buyItemPrice, buyStackPrice
  • updated functions to support buy interaction: countStack, countStackMax
  • fixed: round displayed currencies to match guild store

Cumulative change log for version 2.29.10
  • fixed: countBag-function returned nil instead of 0 for items not present in bag

Cumulative change log for version 2.29.9
  • fixed: notify-task without LibPrice installed made problems

Cumulative change log for version 2.29.8
  • fixed: WritWorthy addon can return a nil matList, so canCraftMasterwrit had problems with some witches-recipes/writs

Cumulative change log for version 2.29.7
  • fixed: the new LibPrice dependency within the "price" function broke the safety function (thx@Sensei27)

Cumulative change log for version 2.29.4/2.29.5/2.29.6
  • fixed: under some circumstances zo_strformat(SI_UNIT_NAME, charName) does not uppercase the first character so for the mutichar-api we're now using zo_strformat("<<C:1>>", charName) (thx@punkfairie)
  • fixed: reconstructionCost wrongly returned a boolean for non reconstructable items, now it will return RbI.NaN (thx@Thiana)

Cumulative change log for version 2.29.3
  • added all currencies to loot informations
  • fixed targetBank with named chests

Cumulative change log for version 2.29.2
  • Fixed quest-cache error for masterwrit-handling, which occurs when LibCraftText isn't installed
  • Added default-argument for price-function. When there is no price. price will return NaN, while price(value()) will return the npcVendor price.
  • countBank can now also be used for homebanks
  • ItemInspector-Fix for inspecting an itemLink (there was a problem with autoCategory throwing a nil-error)

Cumulative change log for version 2.29.1
  • Fixed intern caching problem for bank2bag,deconstruction,sell tasks

Cumulative change log for version 2.29.0
  • Lightweight currency-transfer settings
  • Fixed craftingExtractBonus-function for enchanting (thx@altlavista)
  • New task/functionality for homebanks. This comes with 2 options
    • Target Mode: within BankToBag/BagToBank you can specify the target bank via targetBank-functionality
    • Task Mode: for every homebank (1-10) will be added a new task-pair HomebankXToBag/BagToHomebankX
  • New functions:
    • needForWrit() returns whether the item is needed for a crafting writ. This also includes masterwrits. (Addon-Dependency: LibCraftText)
    • needForWritCount() returns how much of the item is needed for a crafting writ. This also includes masterwrits. (Addon-Dependency: LibCraftText)
    • mountLevel(mountSkill) returns the current mount training level for stamina, capacity and speed
    • mountLevelMin(mountSkill, charNames) returns the minimum of the specified mount training level over all given chars
    • mountLevelMax(mountSkill, charNames) returns the minimum of the specified mount training level over all given chars
    • needMountLevel(mountSkill, charNames) returns if an of the given characters has not maxed the given mount training level
    • needMountLevelInOrder(mountSkill, charNames) returns true for the first character who hasn't maxed the given mount training level yet
    • task(taskName) if someone wants to unify some tasks in one rule
    • tradeableTemporarily() aka. tradeableTemp() returns true whether the item is temporarily tradeable
    • tradeableTemporarilyWithGroupMember() aka. tradeableGroup() returns true whether the item is temporarily tradeable with a member of the current group.

Cumulative change log for version 2.28.1
  • Fixed Quickslotted

Cumulative change log for version 2.28.0
  • Fixed autocategory function with casesensitivy=on
  • removed "OnQuest" as option for AutoOpenStore, as return-quest-dialog-options are indistinguishable from normal chatter for e.g. undaunted pledges
  • New functions:
    • zoneType(zoneTypeNames) returns true whether we're in a given zoneType (like "pve", "pvp", "dungeon"...)
    • groupSize() returns the current size of the group
    • groupRole(groupRoleNames) returns true whether we're in a given groupRole

Cumulative change log for version 2.27.2/2.27.3
  • fix for ItemInspector when CraftStore isn't installed

Cumulative change log for version 2.27.1
  • Fixed auto-close for controllerUI

Cumulative change log for version 2.27.0
  • Constant UI: As like rules now also constants can be defined. In rules they can be used via the new constant(constantName)-function. (This can be used e.g. to specify a specific character order.)
  • craftingType characteristic is now also determined for masterwrits
  • fixed function "craftingRank"s first argument: before it took an integer value, now it's corrected to crafttypeName
  • New functions:
    • All functions can now have an itemLink as first argument. When the first argument is identified as itemLink, it will be cut off and will be set as ctx.item.link (while ctx.item.bag and ctx.item.slot will be set to nil) for this function-call.
    • constant(constanName): use a predefined constant
    • needForDailyWrit(): returns true whether the item is needed for a crafting quest
    • needForDailyWritCount(): returns how much of the item is needed to fullfill a crafting quest. You could use: "needForWrit() and countBackpack('<', needForWritCount())" in Bank2Bag which ensures that you're pulling not more materials for writs than you need
    • inArmory(): return whether the item is part of an armory build
    • armorybuild(buildNames): return whether the item is part of one of the given buildNames
    • getRefined() which will return an itemLink, which can be used as parameter for other functions
    • reconstructionCost() will return the transmutation crystal costs for a reconstruction of the item
    • alphaGearBuild(buildNames) checks if the item is in the given alpha-gear-build referenced by build-name
    • alphaGearBuildNumber(buildIndex) checks if the item is in the given alpha-gear-build reference by index
  • New timesaver settings:
    • Auto open bank/shop/assistant with different options. Additionally with defining a prevent key.
    • Auto close bank/shop/craft with different options after RbI has finished. Additionally with defining a prevent key.
    • Auto despawn assistant: also despawn assistant after auto close.
  • Plugin system for other multi-character knowledge provider beside CraftStore.
  • RuleInspector now differs between Syntax and Unknown-term errors.
  • checked new version 8.0 "HighIsle" compability.

Cumulative change log for version 2.26.0/2.26.1
  • Fixed an error which occured with DLWC and/or long TaskDelay setting

Cumulative change log for version 2.26.0/2.26.1
  • Optimized loot-handling after container-use
  • Now all bags emitting an OnItemUpdate after specific status changes (also like FCOISMark or junk operations). Enhanced the performance for OnItemUpate.
  • Settings-Menu sightly changed in the task-section.
  • Compability with DolgobonLazyWritCrafter: waiting for DLWC to finish. RbI runs only when DLWC doesn't closes the station. So immediate DLWC and immediate RbI should be compatible now.
  • Auto-Data-Import for functions type and stype. Some keys have slightly changed.
    • type: armor_booster -> booster_armor
    • stype: removed "s_"-prefixes
    • stype: s_eventcontainer -> container_event
  • functions added:
    • needCraftingLevelInOrder: if the character you're logged in is the first one who has a craftingLevel (depending on the item) < 50 it will return true
    • craftingRankCount, which will counts how many characters have the same rank as the required rank for the item. With that we can determine if a ressource is need for daily quests or not. The first argument can be optional the craftingRank otherwise the requiredCraftingRank of the item will be used.
    • collectible: returns true when the item is a collectible item (like a set-item or a stylepage)
    • collected: returns true when an isCollectible already unlocked
    • tradeable: returns true when the item isn't bound in any way

Cumulative change log for version 2.25.0
  • Support for the new deconstruction assistant (thx @AndASM for code and testing)

Cumulative change log for version 2.24.9
  • Settings-Menu: Changed layout and added checkbox, when anyone don't want to use/see "ruleset"-template functionality.
  • Problem with FCOIS 2.2.5 fixed (thx @AndASM for a quickfix)
  • Refactoring: Eso event listening only after complete addon initialization.
  • Changed OnItemUpdate-task order. It's now FCOISMark, Junk, Use, Destroy. So Junk now can react on FCOISMarks.

Cumulative change log for version 2.24.8
  • under some circumstances (like using a container with a treasure map, while having the same treasure map already in the inventory) the UseTask took a long time (~80sec for the 5 retries) till it reports the failure, that the item can not be used. This should be registered much faster now (~5-6sec for the 5 retries).

Cumulative change log for version 2.24.7
  • for (custom-user) functions: enriched the ctx-object with ctx.task = {} and ctx.item = {bag = bag,slot = slot,link = itemLink} which will be completely reset accordingly to their lifecycle.

Cumulative change log for version 2.24.6
  • fixed filter comparison functionality for integer based functions like setId, id, instanceid..

Cumulative change log for version 2.24.5
  • fixed RbI.ConsistencyCheck at the beginning, when also FCOItemSaver is used (thx @AndyDrew for the hint)
  • removed itemLink from Iteminspector, istead the name will be shown

Cumulative change log for version 2.24.4
  • fixed incorrect profile initialization (which could occur under some circumstances)
  • fixed itemdata for the tag-function => cut of encoded language specific pronouns like "^f"

Cumulative change log for version 2.24.2+2.24.3
  • fixing colorized message output

Cumulative change log for version 2.24.1
  • fixed canCraftMasterwrit when no knowledge is needed. Added holidaywrit for stype function.

Cumulative change log for version 2.24.0
  • Selectable chat message color
  • Add task-option for Junk/FCOISMark tasks to also run their counterpart/reverse tasks (when checking an item, on manually task run/test and initial item-check) So we have two task types:
    • one-way marking: like Junk is/was initially designed. Additional manually markings won't be reverted.
    • two-way marking: implicit UnJunk/UnMark tasks will also be executed. Manually markings will be reverted.
  • rule-content limitation to 2000, because eso will not save greater content.

Cumulative change log for version 2.23.3
  • ItemInspector: corrected output for fcoisMarker
  • Fixed: after using and looting a container some consumables weren't checked for further tasks

Cumulative change log for version 2.23.2
  • When there are no rules specified, also the opposite task (UnJunk or FCOISUnmark) should not be called. Accidentally this was the case for new items and the item startup-check.

Cumulative change log for version 2.23.1
  • FCOISMark-tasks now using the constant icon name, so instead of fcoisMarker(1) we're using fcoismarker('lock') now. Just run a test with a wrong marker name and the RuleInspector will show you all static ids and language dependent names.
  • added scrollable for task-selection

Cumulative change log for version 2.23.0
  • added function cancraftmasterwrit, which determines if the current character has everything (knowledge and materials) for a masterwrit (needs addon WritWorthy)
  • support for anonym custom user functions...
    • added function call which will execute a lua-function and returns the return value of the function, like: call(function() d(ctx.itemLink) return false end) or call(function() return IsItemJunk(ctx.bag, ctx.slot) end)
    • populated the global to the ruleExecutionEnvironment. So global functions like IsItemJunk can be used.
    • populated a table-variable 'ctx' to the ruleExecutionEnvironment. So ctx.itemLink, ctx.bag, ctx.slot, ctx.station, ctx.taskName can be used.
    • added setting for activating case-sensitivity for rules. So we can reach all global-functions (and use variables like ctx.itemLink). Normally rules will be lowercased before execution. (After activating it, you have to use the lowercase or the official camel-case function names.)
    • refactored and generalized the multi-character functions (needTraitInOrder, needTrait, needLearnInOrder, needLearn, craftingLevelMin, craftingLevelMax, craftingRankMin, craftingRankMax). The refactoring will also reducing the introducing effort for other multi-character knowledge provider like CraftStore.
  • added task FCOISMark tasks, which automatically sets Fcois-Marker
  • functions id, instanceId, craftingrankRequired, glyphMinLevel and glyphMinCP can now used with arguments and works with arguments as a filter-function. So we can simplify something like id() == 2 or id() == 3 to id(2, 3)
  • added id print out for ItemInspector
  • change function fcoisMarker, when it's used without any argument it will not throw an error anymore. Instead it checks, whether if any marker exists. Additional now it also takes icon-ids (1-45) as argument, like fcoismarker(13) for the first dynamic icon-marker. Strings and iconIds can also be mixed.
  • optional item check after login (can be activated via settings), which checks the following tasks for the backpack: Junk (+Unjunk), Use, Destroy, FCOISMark (+Unmark). So it's the same as you would hit "Run" button for all of these tasks.
  • added "not companion()" as precondition for junk-task

Cumulative change log for version 2.22.4
  • deconstruction task: fixed test-run preview

Cumulative change log for version 2.22.3
  • fixed destroy task execution, when there are no junk or use-task rules defined

Cumulative change log for version 2.22.2
  • added loot-information, for use-task when the item is a container.

Cumulative change log for version 2.22.1
  • fixed: under certain conditions the use-action-output did not trigger

Cumulative change log for version 2.22.0
  • added 'use' task (will be released as 'beta')
    • currently I have tested following itemtypes: fish, container, currency_container, recipe, motif (are there more interesting use-types?)
    • usages will be delayed, when interacting elsewhere (like opened bank/mail/store, swimming, combat, looting)
    • fish-usage also will be delayed when running, because it needs an animation, that won't be executed when running
    • support for automated looting containers, with respecting transmutation crystal limit
  • new function 'usable()', which is used as precondition for the new 'use' task
  • added ItemInspector context menu for itemLinks (like chatLinks, guildtradinghouses, lootwindows, mailattachments)
  • added missing static key (SPECIALIZED_)ITEMTYPE_CONTAINER_CURRENCY for type and sType

Cumulative change log for version 2.21.0
  • added language independent shortnames for function trait. So trait-names like 'training', 'aggressive' can be used regardless of the language and regardless of whether it is armor, weapon or jewelry. Like trait('aggressive') or trait('training')
  • fixed data structure for data-types, especially language dependent for data-type 'trait'. Problem: Different traits (like armor_aggressive, jewelry_aggressive) that are mapping on the same key-name (like aggressive) currently will be overwritten
  • test method dumpWhen(<boolean>, ...) now returns the first argument instead of generally 'false'. For the generally 'false' return value it now gives dumpWhenF(<boolean>, ...)
  • ignoring 'do not translate' in given eso-translations. So they can not be found in dataTypes (like equipType) anymore.

Cumulative change log for version 2.20.0
  • optimized clipboard with title/footer and colorized content, which decides between language dependency and independency.
  • ItemInspector: grouped item charasteristics for gear and crafting-stuff.
  • ItemInspector: added function-listing at the end, which non-parameter functions will return true for an item
  • setId now also works as a filter so setId(1,2,3) will return true/false and setId() without argument will return the setId of the item as it was before.
  • on the other hand the following previous filter functions now return their value when using it without parameters: name(), setName(), creator()
  • workaround for a eso-bug at enchanting station, where a creation crafting-sound wants to be played, on extraction.

Cumulative change log for version 2.19.1
  • fixed ischaracter-function

Cumulative change log for version 2.19.0
  • fixed crowngems-soulgemtype for non-english-clients (they were processed as empty)
  • added filterType-function, which can itself have mutliple values for an item (like "armor" and "companion"), if only one argument matches one of the rule inputs the function will return true
  • added simplification function companion() for "filterType('companion')"
  • added companion trait types (aggressive...)

Cumulative change log for version 2.18.2
  • Fixed ItemInspector throwing error when not having CraftStore installed

Cumulative change log for version 2.18.1
  • Fixes the character-name validation
  • craftType(...) is not a simplifaction of "gearCraftingType(...) or recipeCraftingType(...)" anymore. It now works on craftingTypeGet()-function, which also delivers craftingType for raw jewelrytraits.

Cumulative change log for version 2.18.0
  • When running a rule test, the items from the craftbag also will be included now
  • changed gear() from "not equipType('none')" to "not equipType('none', 'poison', 'costume')"
  • added craftingTypeGet-Retrieval for "material_raw_jewelrytrait", because GetItemLinkCraftingSkillType returns 0 for them. Traits can not be assigned to craftingType in general, like armor-traits or weapon-traits.
  • New functions...
    • craftingTypeGet():string, Determines the craftingType of an item. Is used internally as default for the following crafting-functions.
    • craftingExtractBonus():int[0-3], which looks at the crafting skillline regarding extract/deconstruct skill
    • craftingRank():int[0-10], returns the rank of the craftingType
    • craftingRankMin(List<Charnames>):int[0-10], returns the minimum craftingRank over all given characters.
    • craftingRankMax(List<Charnames>):int[0-10], returns the maximum craftingRank over all given characters.
    • craftingRankRequired():int, which determines the required crafting rank for a material item
    • cSkillSpent(championStarName):int, returns the skill points spent on this star
    • cSkill(championStarName):int, return, if it is a slotable star it returns the skill points spent on this star, otherwise 0. So it returns only really used skill points.
    • cSkillSlotted(championStarName):bool, returns, whether the skill is currently slotted
    • cSkillSlotable(championStarName):bool, returns, whether the skill is 'TypeSlotable' and has enough points.
    • cSkillTypeSlotable(championStarName):bool, returns, whether the skill can be slotted in general
  • added more data for the ItemInspector including 'setId' and 'setName'
  • Hint: The refinement task with a rule with "cSkillSlotted('meticulousdisassembly') and craftingExtractBonus() == 3" ensures that you refine only with the best possible results. It works also with deconstruction/extraction, but of course for this tasks we have to define what gear/glyph should be deconstructed/extracted in the first place.

Cumulative change log for version 2.17.0
  • Optimized error handling and better feedback to the user due to Stacktracing!! for the rule/function environment (inclusive the list of used arguments), with hints what is wrong and which should be used instead. Just write and test a wrong rule stype("bla") or stttttype() or completely emtpy rule to see it :) Works also with new "rule"-function (see below) (btw.: Max-Stacktrace size is currently set to 30)
  • New functions...
    • gearCraftingType(<craftingTypes>). Select gear for a given crafting-type. (like gearCraftingType("woodworking"))
    • recipeCraftingType(<craftingTypes>). Select recipes for a given crafting-type. (like recipeCraftingType("blacksmithing"))
    • craftingType(<craftingTypes>), simplification function for "gearCraftingType(...) or recipeCraftingType(...)"
    • craftingLevel(optionalCraftingType):int[0-50] same as skilllinelevel (which is now marked as deprecated), but allow to leave out the argument. The "craftingType" (gear and recipes) will be automatically determined from the item.
    • craftinglevelmin(<charNames>):int[0-50], craftinglevelmax(charNames):int[0-50]. Returns the "craftinglevel" over all given characters (Requires CraftStore addon)
    • simplification function gear() for not equipType("none")
    • simplification function fragment() for sType("key_fragment", "recipe_fragment", "runebox_fragment", "collectible_fragment", "upgrade_fragment")
    • simplificationfunction glyph() for type("glyph_armor", "glyph_jewelry", "glyph_weapon")
    • rule("ruleName"):bool (an allias for rule is "_", so _("myRule") is also fine), which will call the given rule.
  • Test functions... (functions for testing purposes)
    • dump(output-expression) and dumpWhen(boolean-expression, output-expression), like dump(craftingType()) or dumpWhen(not craftingType("none"), craftinglevel()). When testing the rule, the outputs will written for each testing item.
    • ensure("rule-expression") like ensure("gear()"). Will throw an error when wrong items reach the ensurance function.
  • Renaming for rules. This will rename the rule itself and update the references in characters/profiles and rulesets. But it can not update the names when the rule is used from another rule via rule("myRule1")-function.

Cumulative change log for version 2.16.1
  • fixed an issue when laundering craftbag materials while having active esoplus

Cumulative change log for version 2.16.0
  • Trigger
    • Junk/Destroy-tasks are also triggered when an item state change (not only for new items). So now "junked()" can be used in a destroy rule and we can react on manually-junked items by the user.
    • CraftToBag-task now also triggers after the game had run his auto-transfer-to-craftbag-routine.
  • Character-related and CraftStore rules
    • Motif/style support for needlearn(...) and needlearninorder(...) including stylepages, -chapters, and -books
    • Introduced a inner-variable "defaultchars", which is automatically filled with all your characternames. So we can use 'needlearn(defaultchars)' (same for needlearninorder, needtraitinorder, needtrait) [The feature for self defining this variable is in the pipe.]
    • When using needlearninorder and needtraitinorder without an argument, the 'defaultchars'-list will be used (The default for needlearn and needtrait remains with the current logged in character).
    • A hint will be given, when using '...inorder'-functions with only one charname argument. Performance-wise it would be better to use the function without 'inorder'.
    • Character names will now ensure that all character data are correctly written and also available in craftstore. If you're getting an missingCraftStoreCharacter error, you have to relog into the specified character.
  • Item inspection via context menu
    • Fixed the output and inner-variable for style() combined with monstersets. Now it's really "undaunted".
    • Now all valid values will be shown (the fixed key-values and also the language dependent ones, which were introduced with version 2.15.1)
    • Errors now will be printed to clipboard
  • Clipboard-UI
    • Item inspector now prints the output to this separate "clipboard"-window (where you can scroll and strg+c).
    • Errors are also will be printed into this clipboard. Additionally argument-errors will also print all valid arguments.
  • Updated some tooltips in general settings (p.e. "Safety Rule" tooltip now shows directly the inner safety rule and to which tasks it will be applied)
  • Checked Blackwood API compatibility

Cumulative change log for version 2.15.3
  • fixed taskStartOutput setting not being used, thanks Friday_The13_rus!

Cumulative change log for version 2.15.2
  • fixed FCOIS issue when ControllerUI is enabled but FCOIS (which wouldn't work) isn't active or even installed

Cumulative change log for version 2.15.1
  • updated for Flames of Ambition API
  • added checking for ControllerUI which would make FCOIS functions unsound
  • new general setting: immediate execution at crafting stations. you now don't have to click on the deconstruction or refinement tab to start the task! just enable in menu
  • added function reconstructed() for getting items which where crafted via transmutation
  • added functions esoplus() and ischaracter() implemented by MegwynW
  • function inputs are now gathered from within the game where possible. Thus it is in your clients language and for now I won't provide a list of those. Please use the context menu to get the correct inputs. The previous data is left as legacy data and your rules will work normally. But new e.g. styles like "welkynar" (yes long time no update to the data) and sTypes like "toy" are added now, but exactly these will be in your clients language!

Cumulative change log for version 2.10.3
  • corrected unforeseen consequences of quickslotted function as the value needed to be stored in item lookup to be save to interleave tasks
  • excluded ingame-locked items from junking as it isn't possible anyway
  • excluded non-sellable items from selling

Cumulative change log for version 2.10.0
  • added function quickslotted (brilliant idea (and even implementation) by Random!)

Cumulative change log for version 2.9.2
  • for materials level function now returns highest craftable gear level
  • for materials cp function now returns highest craftable gear champion point level
  • for raw materials level and cp functions will refer to the materials refined form
  • added cp and level to context menu output

Cumulative change log for version 2.8.0
  • updated for Markarth API
  • added function freeSlots
  • added function setCollection
  • added function setItemCollected

Cumulative change log for version 2.7.0
Cumulative change log for version 2.6.0
  • needTrait and needLearn functions now support "no input" to check current character only

Cumulative change log for version 2.5.0
  • updated for Stonethorn API
  • added FCOIS marker to context menu output
  • corrected return of "locked"-function now correctly taking FCOIS "lock" into account

Cumulative change log for version 2.4.0
  • updated for Greymore API
  • updated usage of LibCustomMenu (thanks Baertram!)
  • fixed renamed function of LibSets
  • added function skillLineLevel
  • corrected typo in input data (corwnitem -> crownitem, corwnrepair -> crownrepair)
  • fixed file encoding in manifest
  • fixed error in FCOIS dependency

Cumulative change log for version 2.3.0
  • countbackpack/bank/craftbag will now return count when no input is given
  • replaced PreHookHandler with new SetHandler function (thanks sirinsidiator!)

Cumulative change log for version 2.2.1
  • fixed error on opening housebank

Cumulative change log for version 2.2.0
  • added function motifKnown
  • corrected testing of rule now also including items in subscriberbank

Cumulative change log for version 2.1.0
  • added Task CraftToBag which is executed on Bank visit and fetches items from craftbag to backpack
  • added simplification-functions "material" etc. (Wiki: Functions without input)
  • item-functions "name", "setName" and "creator" now support LibTextFilter (optional)
  • added context menu button in inventory to print most of the item's data for reference (requires LibCustomMenu) (optional)
  • fixed erroneous item-functions


Cumulative change log for version 2.0.0
  • Rules and Settings will be lost when updating to 2.0.0
  • Backup settings for reference by copying SavedVariables/RulebasedInventory.lua.
  • Be willing to rewrite your rules and recreate your profiles...
  • OR DO NOT UPDATE TO 2.0.0!
  • Complete rewrite
  • new rule syntax (sorry, for the now mandatory rewrite of rules)
  • added task for refinement
  • deconstruction now uses the game's multi-deconstruct feature
  • introduced RuleSets (two-leveled set of rules)
  • tasks can now have a RuleSet instead of a Rule (so, multiple rules per task instead of one!)
  • added support for LibSets and LibPrice
  • huge performance improvements (at least for me, tested on i7-7700k, GTX1080ti, 16gb DDR4)


Cumulative change log for version 1.6.2
  • Update 2.0.0 is right around the corner
  • Rules and Settings will be lost when updating to 2.0.0
  • Backup settings for reference by copying SavedVariables/RulebasedInventory.lua.
  • Be willing to rewrite your rules and recreate your profiles...
  • OR DO NOT UPDATE TO 2.0.0!


Cumulative change log for version 1.6.1
  • removed libstub (thank's Beartram!)

Cumulative change log for version 1.6.0
  • removed rulestring-colorization for output as it didn't work correctly anyway and furthermore could cause a game crash

Cumulative change log for version 1.5.2
  • Updated for API 100028
  • Source is now available at https://gitlab.com/taxtalis/rulebased-inventory, wiki there might be used in the future

Cumulative change log for version 1.5.1
  • Fixed an error with writworthy integration when ttc was not found

Cumulative change log for version 1.5.0
  • Updated for API 100027
  • renamed 'schematic' (derived from constant's name SPECIALIZED_ITEMTYPE_RECIPE_ENCHANTING_SCHEMATIC_FURNISHING) to 'praxis' (ingame name)
  • added writworthy integration with wwMatCost and wwMatCostPerVoucher (thx to ziggr)
  • added functions itemsetname and itemsetnamematch to filter for setnames

Cumulative change log for version 1.4.2
  • fixed usage of AutoCategory function

Cumulative change log for version 1.4.1
  • added general option for a message when starting a task
  • added support for AutoCategory
  • added function: autocategory("category1",...)
  • fixed multiple bugs which occurred on a full bag
  • fixed test of deconstruct
  • fixed test of notification not using an unsaved rule
  • fixed an issue where in bagCache the count of an item would not be updated

Cumulative change log for version 1.2.2
  • added filters for events to not listen to unnecessary ones
  • rewrite of action- and event-queue
  • rewrite of action execution
  • rewrite of bagCache and generation of actions from task
  • rewrites for integration of LibAsync to reduce runtime per frame for less lag
  • API bump for Murkmire

Cumulative change log for version 0.10.1
  • dropped library because of instability: LibLoadedAddons
  • functions fcoismarker and fcoismarkermatch now support the custom names for fcois markers
  • safe rule switch for deconstruct now has the tooltip it deserves
  • events (junk/notification/destroy) now only are accepted when items were added to the bag to reduce lag
  • fixed notification to try to notify about already again empty slots (like loot containers directly extracted by other addons)
  • optimized events (junk/notification/destroy) to only create a cache of the whole bag if necessary to further reduce lag

Cumulative change log for version 0.8.0
  • tasks are only executed if a rule was defined
  • output now shows intricate and ornate symbols
  • added itemdata: fcoisismarked (replaces fcoislocked)
  • added itemdata: fcoismarker
  • added function: fcoismarker
  • added function: fcoismarkermatch

Cumulative change log for version 0.6.1
  • fixed variables leaking into global namespace (thanks Votan!)
  • added German translation
  • added itemdata: tags
  • added function: itemtag
  • added function: itemtagmatch
  • added itemdata: reagenttraits
  • added function: reagenttrait
  • added function: reagenttraitmatch
  • minimum delay and timeout lowered

-Version 0.4.2 was initial release-
Archived Files (84)
File Name
Version
Size
Uploader
Date
2.30.2
105kB
otac0n
08/24/23 01:04 PM
2.30.1
105kB
otac0n
06/19/23 05:03 PM
2.30.0
105kB
otac0n
06/18/23 09:04 PM
2.29.13
110kB
otac0n
05/07/23 09:49 AM
2.29.12
110kB
otac0n
05/02/23 08:45 PM
2.29.11
104kB
otac0n
03/19/23 05:26 PM
2.29.10
102kB
TaxTalis
02/05/23 07:07 AM
2.29.9
103kB
demawi
11/06/22 10:23 AM
2.29.8
102kB
demawi
11/02/22 04:15 PM
2.29.7
102kB
demawi
08/29/22 06:13 PM
2.29.6
102kB
demawi
07/19/22 01:40 PM
2.29.5
102kB
demawi
07/17/22 05:10 AM
2.29.4
102kB
demawi
07/16/22 04:34 AM
2.29.3
102kB
demawi
07/14/22 05:11 AM
2.29.2
102kB
demawi
07/07/22 04:22 AM
2.29.1
102kB
demawi
07/01/22 04:30 PM
2.29.0
103kB
demawi
06/23/22 02:29 PM
2.28.1
96kB
demawi
06/06/22 01:11 PM
2.28.0
96kB
demawi
05/22/22 09:44 AM
2.27.3
92kB
demawi
05/16/22 02:31 AM
2.27.2
92kB
demawi
05/15/22 01:37 PM
2.27.1
92kB
demawi
05/11/22 02:14 PM
2.27.0
92kB
demawi
05/10/22 02:16 PM
2.26.2
76kB
TaxTalis
04/24/22 02:06 PM
2.26.1
75kB
demawi
04/23/22 11:55 AM
2.26.0
75kB
demawi
04/23/22 11:20 AM
2.25.0
71kB
demawi
04/10/22 11:51 AM
2.24.9
71kB
demawi
04/06/22 02:50 PM
2.24.8
70kB
demawi
02/02/22 11:07 AM
2.24.7
70kB
demawi
01/26/22 07:21 PM
2.24.6
70kB
demawi
01/19/22 03:20 PM
2.24.5
70kB
demawi
12/04/21 05:47 AM
2.24.4
70kB
demawi
09/06/21 05:43 AM
2.24.3
70kB
demawi
08/12/21 02:49 AM
2.24.2
70kB
demawi
08/10/21 10:36 AM
2.24.1
70kB
demawi
07/31/21 09:04 AM
2.24.0
70kB
demawi
07/30/21 04:02 PM
2.23.3
69kB
demawi
07/17/21 08:23 AM
2.23.2
69kB
demawi
07/15/21 05:07 PM
2.23.1
69kB
demawi
07/15/21 04:45 PM
2.23.0
69kB
demawi
07/15/21 07:38 AM
2.22.4
65kB
demawi
07/01/21 10:46 AM
2.22.3
65kB
demawi
06/28/21 04:29 AM
2.22.2
65kB
demawi
06/26/21 12:33 PM
2.22.1
65kB
demawi
06/26/21 09:06 AM
2.22.0
65kB
demawi
06/24/21 04:01 AM
2.21.0
62kB
demawi
06/09/21 12:27 PM
2.20.0
61kB
demawi
06/07/21 10:11 AM
2.19.1
59kB
demawi
06/02/21 01:33 PM
2.18.2
58kB
demawi
05/30/21 07:31 AM
2.18.1
58kB
demawi
05/28/21 08:40 AM
2.18.0
58kB
demawi
05/28/21 03:08 AM
2.17.0
54kB
demawi
05/22/21 06:46 AM
2.16.1
46kB
demawi
05/14/21 03:00 PM
2.16.0
46kB
demawi
05/13/21 09:25 AM
2.15.3
42kB
demawi
02/23/21 01:36 AM
2.15.2
42kB
TaxTalis
02/22/21 09:42 AM
2.15.1
42kB
TaxTalis
02/21/21 03:30 PM
2.10.3
39kB
TaxTalis
11/25/20 11:12 AM
2.10.0
38kB
TaxTalis
11/18/20 04:18 PM
2.9.2
38kB
TaxTalis
11/15/20 06:25 AM
2.8.0
38kB
TaxTalis
11/08/20 07:46 AM
2.7.0
38kB
TaxTalis
10/11/20 11:54 AM
2.6.0
38kB
TaxTalis
09/09/20 06:01 AM
2.5.0
38kB
TaxTalis
08/11/20 10:59 AM
2.4.0
38kB
TaxTalis
05/25/20 02:34 AM
2.3.0
37kB
TaxTalis
02/26/20 12:20 PM
2.2.1
37kB
TaxTalis
01/07/20 01:05 PM
2.2.0
37kB
TaxTalis
12/30/19 02:22 AM
2.1.0
37kB
TaxTalis
12/25/19 12:17 PM
2.0.0
35kB
TaxTalis
12/18/19 05:03 AM
1.6.2
920kB
TaxTalis
11/27/19 01:48 PM
1.6.1
920kB
TaxTalis
09/06/19 08:47 AM
1.6.0
920kB
TaxTalis
08/31/19 04:02 PM
1.5.2
922kB
TaxTalis
08/14/19 09:25 AM
1.5.1
920kB
TaxTalis
05/25/19 02:57 AM
1.5.0
920kB
TaxTalis
05/24/19 10:07 AM
1.4.2
914kB
TaxTalis
10/27/18 09:00 AM
1.4.1
914kB
TaxTalis
10/26/18 02:36 PM
1.2.2
911kB
TaxTalis
10/12/18 01:27 PM
0.10.1
910kB
TaxTalis
09/26/18 12:27 PM
0.8.0
911kB
TaxTalis
09/16/18 01:58 PM
0.6.1
909kB
TaxTalis
09/15/18 07:08 AM
0.4.2
903kB
TaxTalis
09/11/18 10:06 AM


Post A Reply Comment Options
Unread 12/19/20, 09:13 AM  
Random

Forum posts: 0
File comments: 46
Uploads: 0
There doesn't seem to be a good way to filter by type for the festival toys like the Disposable Juggling Knives. The Item Data gives Type: Trophy sType: 111
Report comment to moderator  
Reply With Quote
Unread 12/19/20, 03:35 AM  
TaxTalis
AddOn Author - Click to view AddOns

Forum posts: 0
File comments: 190
Uploads: 2
@Friday_The13_rus, I just realized you said you were not on an English client.
The levels for material are pulled from the item description's string (I couldn't find any other method rather then hard coding it, which I might need to do), so, sorry, it is just working on the English descriptions for now.
Report comment to moderator  
Reply With Quote
Unread 12/14/20, 12:05 AM  
TaxTalis
AddOn Author - Click to view AddOns

Forum posts: 0
File comments: 190
Uploads: 2
Originally Posted by Friday_The13_rus
Thanks for the great addon! I keep using it and like it more and more!

Found two small bugs:
1) Setting "Task start message" does not hide start message in chat
2) Function "Level" does not work correctly for jewelry craft materials (I did not test other). I use Russian game language.
I have rule
Code:
material_jewelry() and level() >= 26
I expect that material Copper Ounce (level 26-50) and all CP materials match this rule, but only CP materials matched.
Noted. I'll look into that. Thank you for using RbI!
Report comment to moderator  
Reply With Quote
Unread 12/13/20, 04:52 AM  
Friday_The13_rus

Forum posts: 5
File comments: 73
Uploads: 0
Thanks for the great addon! I keep using it and like it more and more!

Found two small bugs:
1) Setting "Task start message" does not hide start message in chat
2) Function "Level" does not work correctly for jewelry craft materials (I did not test other). I use Russian game language.
I have rule
Code:
material_jewelry() and level() >= 26
I expect that material Copper Ounce (level 26-50) and all CP materials match this rule, but only CP materials matched.
Last edited by Friday_The13_rus : 12/13/20 at 05:02 AM.
Report comment to moderator  
Reply With Quote
Unread 12/07/20, 03:47 PM  
TaxTalis
AddOn Author - Click to view AddOns

Forum posts: 0
File comments: 190
Uploads: 2
@Talegas, good to hear that! Thank you for reporting a success

@Random, no, sadly CraftStore does not provide this function (yet). I requested this twice, two and one year ago, but it was never a priority to begin with. Nothing I can do here, as I won't fetch data from someone else's addon without a standardized function written by its author.
Last edited by TaxTalis : 12/07/20 at 03:47 PM.
Report comment to moderator  
Reply With Quote
Unread 12/07/20, 03:07 PM  
Random

Forum posts: 0
File comments: 46
Uploads: 0
Is there no motif equivalent for needlearninorder?
Report comment to moderator  
Reply With Quote
Unread 12/03/20, 06:34 PM  
Talegas

Forum posts: 0
File comments: 16
Uploads: 0
Thanks for fixing the annoying chat notification!



Just wanted to thank you for it. I am now swapping gear and no annoying messages about my previous items going to the junk (yet not going there).

cheers!
Report comment to moderator  
Reply With Quote
Unread 11/29/20, 03:21 PM  
TaxTalis
AddOn Author - Click to view AddOns

Forum posts: 0
File comments: 190
Uploads: 2
That destroy rule is a topic for RbI 3.x then I'm afraid
But I have at least some ideas now.

No, I am sorry, but there is no way for you to manually override the size of the field.
You could copy and paste back and forth from an external editor though, as an intermediate solution.
I'll try to get it working or think of an alternative. Stay put!
Report comment to moderator  
Reply With Quote
Unread 11/29/20, 12:54 PM  
Random

Forum posts: 0
File comments: 46
Uploads: 0
Originally Posted by TaxTalis
For destroy, I don't know what more logic do you want or need? If you enable the run button for destroy and hit it when in need of bagspace you could do stuff like "when under X slots destroy all stolen items with a value less than 10", "when under Y slots destroy all stolen items with a value less than 40" ...
Is there even more to it?
Uhm yes.
I'd want something like the following psuedocode:
Code:
while count(stolen treasure) > remainingDailyFenceLimit():
  find least valuable treasure:
    if quality < superior
      destroy it
    else
      chat message saying we're full up
      exit function
I'd do something similar for laundering raw materials and unknown/valuable recipes/motifs.


Originally Posted by TaxTalis
The UI issue you encounter has somewhat to do with LibAddonMenu.
The code should, and as you noticed, normally does extend the window to fit the lines of the rule,
but in some instances, and I haven't yet figured out when or why, it breaks and stops doing that.
Ugh. Okay, well, try to find something, please. It's fairly annoying. Is there at least to get an option where I can manually drag it to make it larger?
Report comment to moderator  
Reply With Quote
Unread 11/29/20, 10:55 AM  
TaxTalis
AddOn Author - Click to view AddOns

Forum posts: 0
File comments: 190
Uploads: 2
FCOIS markers are labeled internally, the tasks would refer to this, not the given name, and even the task could change name according to the markers name, that's not the problem

Your selling setup looks right, I'll try to look into that. Don't want RbI to sell more than it should...

Well yea, there is the function "skillLineLevel" which for now only maps to crafting skill lines, so the alt would know it is training and needed to deconstruct, simply by adding a rule with skilllinelevel(...) < 50 to the first set of rules where an item "needs to fit all".

For destroy, I don't know what more logic do you want or need? If you enable the run button for destroy and hit it when in need of bagspace you could do stuff like "when under X slots destroy all stolen items with a value less than 10", "when under Y slots destroy all stolen items with a value less than 40" ...
Is there even more to it?

The UI issue you encounter has somewhat to do with LibAddonMenu.
The code should, and as you noticed, normally does extend the window to fit the lines of the rule,
but in some instances, and I haven't yet figured out when or why, it breaks and stops doing that.
Last edited by TaxTalis : 11/29/20 at 10:56 AM.
Report comment to moderator  
Reply With Quote
Unread 11/29/20, 10:32 AM  
Random

Forum posts: 0
File comments: 46
Uploads: 0
Originally Posted by TaxTalis
I use AutoResearch but RbI handles the "researchable items", for this reason they have to be quite specific and I don't use random loot to research but crafted lvl 1 gear, so I can check specifically for it and also if I already know the trait and if I already have on in my backpack. that way my bank gets free after bulk crafting research grear and my alts pull just one of those items per trait when they need it and store them "locally".
Sounds like you might be a fan of Leos's Trainer, which I've played with some, but not a lot. But it will make the L1 items for you. :-)
In the end, I think you're right, and RBI would only tangentially be involved in any auto-research process.



Originally Posted by TaxTalis
Without having looked at it, because RbI does not use items at the moment, the only thing Unboxer (when only unboxing things) should "overlap" with RbI is the items it unboxes will be checked by RbI for Notify, Delete and Junk, so there should not be an issue... unless maybe there are boxes in boxes... never had issue though with DLWC unboxing boxes in boxes though.
Yep, and I'm keeping it, at least until I find something better.

Originally Posted by TaxTalis
regarding FCOIS: I fiddled with setting the markName from a function in a rule and think it would work. Then there would be a task "FOCISMARK", but then the user would need to put the "mark" somewhere in the rule by calling a function for the task knowing what to do in its action. And if you put multiple marks in one rule (possible, by the way) you could even put them like so that one rule could mark everything differently as the order of evaluation should be from inner to outer, left to right (would need to read this up in LUA Documentation, thus if you do "false and FCOISMARK("LOCK")" "LOCK" will never be seen by RbI. then you could do "(X and FCOISMARK("X")) OR (Y and FCOISMARK("Y")" with an per item evaluation which marker(s) is/are set! If you mess it up though and FCOISMARK is either never or always visible, you could have a very hard time. And this could pose a problem potentially even to users which otherwise do fine with RbI.
The other idea I had was the following: One Task per Mark. Booosch 40 new Tasks and I need to make the task dropdown scrollable and it looks ugly as hell would work though, and no marker-function with extended boolean knowledge necessary.
Yea, I wouldn't advise the Task per Mark path, since then you have to deal with the eventuality of people renaming some of the marks, and then you have to figure out what to do with the old tasks.... and it would look like a royal mess for a limited set of use cases.
Having the function within seems like it could work.

Originally Posted by TaxTalis
What RbI oversold stuff?! No way :O I sure hope it was an error in the rule and not a bug in RbI :/
Quickslotted you would use only to determine if you want them put to bank, or withdrawn right?
I haven't quite understand what happend there.
I think I had it set up like:
Code:
BankToBag: CountBackpack("<", 100)  and name("Essence of Stamina")
BagToBank: name("Essence of Stamina")
Sell: CountBackpack(">",  countStackMax() + 100 - CountBank())
countstackMax is 100 for these. I had 100 in bag, 146 in bank. Talked to merchant, and it sold 100, not 46. Went to bank, withdrew 100 (ok), then talked to merchant, and it sold all 100 again. At which point I just dismantled the selling rule, and went back to only selling junk.

Originally Posted by TaxTalis
What starting tasks on button push? And I thought I would be running in the right direction making it all automatic noted that one down, seems a valid point. And this would be optional of cause, so all set up to ones liking. the function would at this point be a general "what level does this skill have"-function. so you're rule would get a little bigger but it keeps my side hopefully simpler and the function more flexible.
Yea. One of the cases I also have is when I'm training an alt up on blacksmithing, I want that alt to do a bunch of decon work, sacrificing the extra profit of having the main crafter do the decon, (but getting the profit back long term with better daily writ rewards). Writing all the logic for "oh this alt is training, so they decon before main crafter, but once they hit 50, stop" is possible, with the right functions, but a lot of bother. If I just say "decon with a keypress", then I get the control I want, with minimal hassle. Once they are all trained, I can go back to full auto, at which point a filter for the passive would be nice.


Originally Posted by TaxTalis
As I said, if you have a big block of rules for a task which you tend to use in multiple of your profiles which you also tend to edit/improve/correct, you should take a look at saving this as a ruleSet. If you have set this ruleset on multiple profiles, wherever you change it and save it to the same name it will be replaced in all profiles using it. Same like rules, as you mentioned, being changed everywhere when edited.
Hmm, so I could have my "main profile" instead be a ruleset, and then have several profiles based off that ruleset, only with each profile storing a few additional task->rule mappings? Hmm. Okay. I'd have to play with that. That's not at all clear from the wiki.


Originally Posted by TaxTalis
For the "destroy on overload", well technically could run a destroy-task when your bag reached a certain threshold... but this is a dangerous thing. that's why even the "run" button for destroy is not active in menu. I could enable it, and if you'd want to take the risk you can do for yourself. then if you know "bag is full but I am not done yet rummaging around in other peoples belongings" you could hit it and be... good to go, if everything plays nicely. When or if I implement keybinds that could surely be keybinded too.
Yea, I think that to get what I really want here, I'd have to write my own addon. I think the logic I'm looking for would get beyond what RBI would ever be capable of without a complete re-write. So I'll see if I care enough about it to go that far. :-)

=====

One thing that has really been bugging me of late is a UI issue. When I enter a new rule, the textbox for editing the rule will grow in size (number of visible lines). Some of my rules get a bit lengthy, like 8-9 lines. When I then go back to edit the rule, I get a three line window, which makes it really hard to read and edit. I don't know the ESO LUA UI options enough, but can we get a resizeable text box here, or at least have it open with more lines for large text blocks?
Report comment to moderator  
Reply With Quote
Unread 11/29/20, 02:44 AM  
TaxTalis
AddOn Author - Click to view AddOns

Forum posts: 0
File comments: 190
Uploads: 2
I use AutoResearch but RbI handles the "researchable items", for this reason they have to be quite specific and I don't use random loot to research but crafted lvl 1 gear, so I can check specifically for it and also if I already know the trait and if I already have on in my backpack. that way my bank gets free after bulk crafting research grear and my alts pull just one of those items per trait when they need it and store them "locally".

Without having looked at it, because RbI does not use items at the moment, the only thing Unboxer (when only unboxing things) should "overlap" with RbI is the items it unboxes will be checked by RbI for Notify, Delete and Junk, so there should not be an issue... unless maybe there are boxes in boxes... never had issue though with DLWC unboxing boxes in boxes though.

regarding FCOIS: I fiddled with setting the markName from a function in a rule and think it would work. Then there would be a task "FOCISMARK", but then the user would need to put the "mark" somewhere in the rule by calling a function for the task knowing what to do in its action. And if you put multiple marks in one rule (possible, by the way) you could even put them like so that one rule could mark everything differently as the order of evaluation should be from inner to outer, left to right (would need to read this up in LUA Documentation, thus if you do "false and FCOISMARK("LOCK")" "LOCK" will never be seen by RbI. then you could do "(X and FCOISMARK("X")) OR (Y and FCOISMARK("Y")" with an per item evaluation which marker(s) is/are set! If you mess it up though and FCOISMARK is either never or always visible, you could have a very hard time. And this could pose a problem potentially even to users which otherwise do fine with RbI.
The other idea I had was the following: One Task per Mark. Booosch 40 new Tasks and I need to make the task dropdown scrollable and it looks ugly as hell would work though, and no marker-function with extended boolean knowledge necessary.

What RbI oversold stuff?! No way :O I sure hope it was an error in the rule and not a bug in RbI :/
Quickslotted you would use only to determine if you want them put to bank, or withdrawn right?
I haven't quite understand what happend there.

What starting tasks on button push? And I thought I would be running in the right direction making it all automatic noted that one down, seems a valid point. And this would be optional of cause, so all set up to ones liking. the function would at this point be a general "what level does this skill have"-function. so you're rule would get a little bigger but it keeps my side hopefully simpler and the function more flexible.

As I said, if you have a big block of rules for a task which you tend to use in multiple of your profiles which you also tend to edit/improve/correct, you should take a look at saving this as a ruleSet. If you have set this ruleset on multiple profiles, wherever you change it and save it to the same name it will be replaced in all profiles using it. Same like rules, as you mentioned, being changed everywhere when edited.

For the "destroy on overload", well technically could run a destroy-task when your bag reached a certain threshold... but this is a dangerous thing. that's why even the "run" button for destroy is not active in menu. I could enable it, and if you'd want to take the risk you can do for yourself. then if you know "bag is full but I am not done yet rummaging around in other peoples belongings" you could hit it and be... good to go, if everything plays nicely. When or if I implement keybinds that could surely be keybinded too.
Last edited by TaxTalis : 11/29/20 at 02:49 AM.
Report comment to moderator  
Reply With Quote
Unread 11/29/20, 01:35 AM  
Random

Forum posts: 0
File comments: 46
Uploads: 0
Originally Posted by TaxTalis
That is a lot of stuff, @Random
A man can dream....

And yea, I figured several of these ideas were long shots, just letting you know some of the things I think of, that I'd use if the opportunity arose.

I've used Research Assistant before, when I was working on nine traiting my main crafter. It works amazingly well, as long as you focus on one character at a time. I've since mostly decided I'm not that invested in researching on my alts, so likely won't pursue this much more.

For the container part of "using", I just found the addon Unboxer, which seems to work quite well at having me not think about boxes of things anymore.

I just have reservations of having too many addons operating in a similar space, since they can interfere with each other, and get really nasty to debug. Hence mentioning them here, to see if I could further integrate things.

Originally Posted by TaxTalis
I see the use case of fcois marking, thanks for your example. Sadly as I said currently
there seems no elegant way of implementing this.
Yea, I've thought about it some more within the confines of your model. Selecting the items and having a task would be really easy... right up to the point where you say which mark to apply, especially since there are dynamic markers as well. The "best" idea I've had is completely inelegant, and pure cheese, which would be to read something from the name of the rule to get the mark. So you could have a rule like "Mark Covetous Treasure [Covetous]" which then sees the "[MarkName]", telling you what mark to apply. I warned you it was pure cheese.

Originally Posted by TaxTalis
If you want to keep only a stack soulgems in bank and you know you will put your backpacks soulgems to the bank next so you know how many soulgems would be transferred. 25 soulgems should remain in backpack on BankToBag, there you surely use
Code:
countBackpack("<", 25)
and also deposit all to the bank on BagToBank, as the rules are exclusive. Now, lets do a little math in our rule, which is a bit clumsy to be honest, and I have not tested this very code but you should get the point (the code is only calculation of selling amount, not for selecting the item, also we are using countStackMax() to be item-unrelated, so this should work for every item):
Code:
CountBackpack(">",  countStackMax() + 25 - CountBank())
This will give you the following: It will sell all of this item as long as your backpack holds more items than the total amount you want to keep in both backpack and bank combined (a full stack "countStackMax()" and the 25 of your backpack) reduced by the amount you already have in your bank. Bank: 150, Bag: 100 -> 200 + 25 - 150 = 75, so all items above 75 will be sold, which is 25, as you have 100 in bag.
I played with this some, and kinda got it working, but it was pretty clunky in practice, and was starting to be a solution more painful than the problem, so I stopped caring. I ran into issues with getting the amount to sell be correct (it would at times oversell), and then realized that the rules would get really complicated with some of the potions... like the Essense of Stamina, which my Argonian Tank drinks like breathing air, but nobody else touches.... point being this is a place where I use Quickslotted... which greatly complicates the selling rule when a character only sometimes wants it in inventory. I'll just continue periodically manually selling the overflow stacks in the bank.

Originally Posted by TaxTalis
Checking for the "deconstruction enhancement" passives should be a simple function again, returning a simple number, I will think about it.
Cool. For reference, it's multiple skills, once per line. Metal Extraction, Unraveling, Runestone Extractions, Jewelry Extraction, Wood Extraction. Each of these have three levels. A helper function of "for this station's skill line" would be handy, of course.
I could also see the Refine/Extract/Deconstruct tasks being triggered by a bound key instead of automatic, just so there's more control over it firing.



Originally Posted by TaxTalis
If most of the rules stay the same, how about not editing the profile but the RuleSets then?
Otherwise, sorry, no, this sounds like a hell of work and new UI elements and everything. I am glad the profiles work as they do and between different profiles there should be no additional work needed when changing Rules or Rulesets both profiles use. I hope there is a way you can avoid the extra work you seem to have.
I use a ruleSet for Junking, Selling and then some Rules for StockItems I want to keep on every character on all of my profiles for example. So if I change them on one (correcting a bug or just adding things to the mix), it is changed for all.
I really haven't tried using the stored rulesets yet, because I didn't see a big win of using them over loading one profile, making some changes to mapping, and then saving it as a profile with a different name. Unless there's something I'm missing here.

I know that when I update a Rule, it updates across all profiles and characters who use it.
As things settle in, it shouldn't be too bad.

I'm still debating how best to handle my "destroy cheap stolen stuff when over capacity" issue though. That's an actual problem, as I'll head out and steal all of Wayrest at times, and that can be a lot of loot. I'm unaware of any addons that come close to managing this part of things.


In the end, thanks for all the work. RBI is already solving >90% of my loot management problems, which is way more than I had before.
Report comment to moderator  
Reply With Quote
Unread 11/28/20, 05:20 PM  
TaxTalis
AddOn Author - Click to view AddOns

Forum posts: 0
File comments: 190
Uploads: 2
That is a lot of stuff, @Random

Yes, I know you would like a "using" task, I'll maybe take a look at this in the future, maybe starting at specific item types for which one could extend the initial rule which selected the item by if and under what circumstances the item should be used, so that the action can be tailored for the item type.

Researching would kind-of be possible with RbI but not very good. The problem here lies in RbI's rule-system which is inventory-slot-based. RbI just loops over ever item in the bags and checks the task's rules. If it fits, the action is taken otherwise not. Now having to go over items in a specific order or having rules themselves look through the pile of items is a functionality currently not provided by RbI's core and could have immense implications for performance. Please use addons like AutoResearch for this, which are specially designed for this task.

I see the use case of fcois marking, thanks for your example. Sadly as I said currently there seems no elegant way of implementing this.

If you want to keep only a stack soulgems in bank and you know you will put your backpacks soulgems to the bank next so you know how many soulgems would be transferred. 25 soulgems should remain in backpack on BankToBag, there you surely use
Code:
countBackpack("<", 25)
and also deposit all to the bank on BagToBank, as the rules are exclusive. Now, lets do a little math in our rule, which is a bit clumsy to be honest, and I have not tested this very code but you should get the point (the code is only calculation of selling amount, not for selecting the item, also we are using countStackMax() to be item-unrelated, so this should work for every item):
Code:
CountBackpack(">",  countStackMax() + 25 - CountBank())
This will give you the following: It will sell all of this item as long as your backpack holds more items than the total amount you want to keep in both backpack and bank combined (a full stack "countStackMax()" and the 25 of your backpack) reduced by the amount you already have in your bank. Bank: 150, Bag: 100 -> 200 + 25 - 150 = 75, so all items above 75 will be sold, which is 25, as you have 100 in bag.

As stated with the researching, the prioritizing of certain items is not possible with RbI as a rule would need to know more than it can read from the currently tested item.
Therefor it cannot and maybe will never provide a function to "prefer" an item over the other. No prioritizing of crown items over their non-crown counterparts I am afraid.

Sadly this also prevents from fencing more valuable... uhm this one might say "found" items first.

The gear durability however could work, this should be a static function only which checks gearslots, doesn't need to search for items in the normal bags and does result in a simple number. I will think about it. Applying a repairkit however stands on a different card, as you know my struggle with the "using" of items.

Checking for the "deconstruction enhancement" passives should be a simple function again, returning a simple number, I will think about it.

If most of the rules stay the same, how about not editing the profile but the RuleSets then?
Otherwise, sorry, no, this sounds like a hell of work and new UI elements and everything. I am glad the profiles work as they do and between different profiles there should be no additional work needed when changing Rules or Rulesets both profiles use. I hope there is a way you can avoid the extra work you seem to have.
I use a ruleSet for Junking, Selling and then some Rules for StockItems I want to keep on every character on all of my profiles for example. So if I change them on one (correcting a bug or just adding things to the mix), it is changed for all.
Last edited by TaxTalis : 11/28/20 at 05:26 PM.
Report comment to moderator  
Reply With Quote
Unread 11/28/20, 01:58 PM  
Random

Forum posts: 0
File comments: 46
Uploads: 0
Originally Posted by TaxTalis
@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.
At the moment, I'm in a pretty good spot on much of the things. With the LUA error gone, and the withdraw/store cycle resolved, most of my previous tasks have been adapted. For many of the remaining interactions with DLWC, I have an FCOIS marker "WritWork" which gets applied, and I have integrated into rules to limit the insanity.

The remaining bits are "nice to haves", but here's a list, so you can think about ways to handle the scenarios:

The auto-reading of recipes and motifs, as mentioned before.
The auto-looting of containers upon receipt, as mentioned before.
The auto-researching of traits, with rules about order of traits to learn, and who needs what (from Craftstore)
[though, since I have my main crafter 9-traited, this is less of a topic]

In Thieve's Guild, there's the Covetous Countess quest, which is a great way to speed level your Thieve's reputation... once you get a starter stockpile of appropriately typed treasure. In the past, I've made use of a task which I could toggle on, and when out looting the planet, (my main character is a complete kleptomaniac), treasures which could be used for that would get a FCOIS marker for the purpose, and be excluded from being fenced, instead getting laundered, etc. But I only do this one in a while, and fence/sell all of it the rest of the time. Having them marked in inventory also added a nice visual indicator of how I was doing.

I have some "commodity" items, where I want to keep a certain number of in character inventory, and then and stockpile in the bank. This currently works fine, with the CountBackpack functionality. However, what I'd like to add is another layer of logic, which is that if the bank has a full stack of the item, then overflow should be sold at a merchant. So let's talk Soul Gems. I want to keep 25 in inventory, and 200 in the bank. If my current character has 100, and there are 150 in the bank, and I then open a merchant, I'd like it to sell 25 of them. (keep 25 in inventory, and have 50 go to the bank, sell the remaining). I haven't figured out how to do that three way math yet.

Related to the above, I'd like to lump crown soul gems in with filled soul gems, and say things like "give my 25 total in inventory, but prefer crown ones when available". Thus, if I had 25 filled gems in bag, and 10 crown ones in bank, then rbi should put 10 filled gems into the bank, and take the 10 crown ones out.

When I'm out thieving, I reallocate to my possession treasures of various qualities, white/green/blue. As any good thief knows, there a daily fence limit, and so if you have lots of reallocated possessions, you can't fence all of them (this saddens Khajiit). Thus, one wants to sell the expensive stuff first. I have a rule auto-fence any blue or better treasure. However, there limits on inventory, and how many whites I can hold in the meantime. How might I make a rule where I auto destroy white treasure, but only if the sum of `Stolen() and Quality("normal", "fine", "superior", "epic") and type("treasure")` would put me over the remaining daily fence cap? Note that this might include such oddities as looting a blue treasure, thus triggering a white treasure getting destroyed.

I typically use Grand Repair Kits, with a different addon which repairs what I'm wearing whenever it gets under 5% (tunable) durability, on exiting combat. This is fine, and RBI now keeps my characters stocked with Repair Kits, without my thinking. However, I also have a small pile of Crown Repair Kits which I leave in my bank account, gathering dust. I'd love to have a threshold of average gear durability, and if when I hit the bank I'm below that level, I withdraw a crown kit and apply it.

Currently, I have a separate profile for my main crafter, since she has the advanced passives to get more out of refining and deconstructing, so I steer all of that work to her. If, instead, I had a function to check for the presence of such passives, I could collapse those profiles.

Alternatively, I'm noticing that I have a "base set" of rules that I use all the time, and form my main profile, but then have have some auxiliary profiles (like the crafter above, but also one for when I'm running surveys, to pull them out of bank, instead of stuff them in) which are just adding a couple extra rule/task mappings over that base profile. However, when I edit the base profile, it seems I have to go edit all the others. Would it be possible to mark a profile as "additive" or "on top of" a different profile? That would remove the need to have the crafter levels in previous idea.

Originally Posted by TaxTalis
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
It likely won't help you as you'd like, since I'm mostly just telling people to add a certain set of rules and task mappings. Many of them are not CS backgrounds, and thus wouldn't figure it out.
Last edited by Random : 11/28/20 at 01:59 PM.
Report comment to moderator  
Reply With Quote
Post A Reply



Category Jump: