Table custom option

[Causese]

Is your feature request related to a problem? Please describe.
There's currently no great way to create for example an allow / blocklist in custom options that just allows you to check for a specified spellId by using aura_env.config.tablename[spellId].

Describe the solution you'd like

Simple key value based table that extends with each entry or w/e

Describe alternatives you've considered

currently players create a string option and use code to put all entered spellIds in a table or create an option per spell.
its not that easy to make edits since most players dont remember what each spellId stands for.
that's what having a value would be useful for

aura_env.spellIDs = {}
for match in aura_env.config.spellID:gmatch("%d+") do aura_env.spellIDs[match] = true end

Additional context

i like what plater did as solution

@emptyrivers <3???

[emptyrivers]

hrm, i don't see the point? you can just put a couple lines of code in init to transform an array into the shape you want.

e.g. local blocked = {} for _, entry in ipairs(aura_env.config.blocklist) do blocked[entry.id] = true end would achieve your goal for this array (you can even write that into aura_env.config.spells if you want):

[emptyrivers]

It seems like the more relevant problem is this:

its not that easy to make edits since most players dont remember what each spellId stands for.

which could be solved in other ways

[mrbuds]

It's something i raised in an other ticket a while ago, with (bad?) idea to have an automated description field derived from a spellId field. Problem is that this solution would solve a specific problem but then you may want to do this with itemid? npcid? iconid? etc..

So what..

• add a custom coded read-only field which take info from other fields? + generic is good | - doesn't sound fun to implement, niche and require knowledge to use
• implement a list of premade id->description functions? + easy to use | - less generic but can be extended if needed | no idea about implementation

[emptyrivers]

well, a 'spell' type option has prior art in the trigger prototypes, so I would be ok with adding something like that in. items, too.

[emptyrivers]

like, an option that on the author side provided an item id (possibly a display name also? open to bikeshedding on that), but on the user side looked like this

would work IMO