#(apemademid) `ListTag.find_tag`, `ListTag.find_last_tag`

91 messages · Page 1 of 1 (latest)

royal galleon
#
example_data:
  type: data
  entries:
    - type: foo
      value: 1
    - type: bar
      value: 2
    - type: baz
      value: 3
    - type: baz
      value: 4
    - type: foo
      value: 5
    - type: foo
      value: 6
    - type: bar
      value: 7

<script[example_data].data_key[entries].find_tag[ <[FIND_VALUE].get[type].equals[baz]> ].get[value]> -> 3

<script[example_data].data_key[entries].find_last_tag[ <[FIND_VALUE].get[type].equals[foo]> ].get[value]> -> 6

loud plinthBOT
#

(apemademid) ListTag.find_tag, ListTag.find_last_tag

loud plinthBOT
#

Hi I'm AutoThreadBot! Don't mind me, I'll just be adding the helper team to this thread so they can see it. A human will get to you soon.

buoyant sealBOT
#
Changed to Feature

Thread is now a Feature thread. This indicates a request for a new feature to the plugin, that both (A) does not already exist and (B) reasonably can be added. If you are unsure whether this applies, use </helpthread:1028674284870180883> to change back to a normal help thread.

olive spruce
#

Does this even work

desert kettle
#

its a feature request, but uh

royal galleon
#

Feature request ye

desert kettle
#

i see what you meant, but i think you meant like, similar to listtag.filter[tag].first kind of thing

royal galleon
royal galleon
#

it's too hard filtering the whole list to get a single entry

#

(mentally hard)

desert kettle
#

it takes a lot of processing when you have a big list of maps

royal galleon
#

i mean i'm currently making a proc for that

desert kettle
#

but idk how this would work in denizen

olive spruce
#

What does <script[example_data].data_key[entries]> return

royal galleon
#

just assumed it's not too fancy or undeground of a feature not to make it a tag

olive spruce
#

did you try that ingame

royal galleon
#

invalid syntax

#

it can't be done as a script key directly, but common generated data

desert kettle
#

<script[example_data].data_key[entries]> would return li@ map@[type=foo;value=1] etc

royal galleon
#

that's how the data is actually generated

desert kettle
#

wait

royal galleon
desert kettle
#

wtf are you doing there kekw_dog

olive spruce
desert kettle
#

err

royal galleon
#

put that example to display the kind of data format i'm referencing in my very specific case
can work with any list otherwise

olive spruce
#

Ye I know.

royal galleon
#

For now i'll just use a proc but it'd be useful

#

Also for consistency it might as well return the index of the matching entry, as does ListTag.find

#

Tho in that case I'd consider the actual entry more useful

olive spruce
#

!t list.find_all_matches

onyx wagonBOT
olive spruce
#

wouldn't that help you

royal galleon
#

no i'm dealing with a map

olive spruce
#

You are dealing with a list, that returns maps.

desert kettle
royal galleon
#

the only tag-based workaround currently is Behr's suggestion

#

listtag.filter.first

desert kettle
#

li@type<&ampco> foo| ew lol

royal galleon
#

i get this with the mock script

olive spruce
#

Yeah the parser does not support that

desert kettle
#

maybe because its a data script container, with a real script attached

royal galleon
#

also in case you ever need to put lists of maps in your item scripts, unrelated gift for ya

# Converts a map to a list, using the keys ordered alphabetically to determine the order of map values.
map_to_list:
  type: procedure
  debug: false
  definitions: MAP
  script:
    - determine <[MAP].keys.alphabetical.parse_tag[<[MAP.<[PARSE_VALUE]>]>]>
desert kettle
#

isnt that an existing tag

olive spruce
#

<[MAP.<[PARSE_VALUE]>]> tf

royal galleon
#

used as

example_data:
  type: data
  entries:
    0:
      type: foo
      value: 1
    1:
      type: bar
      value: 2
    2:
      type: baz
      value: 3
    3:
      type: baz
      value: 4
    4:
      type: foo
      value: 5
    5: 
      type: foo
      value: 6
    6:
      type: bar
      value: 7

<script[example_data].data_key[entries].proc[map_to_list]>

royal galleon
desert kettle
#

!t maptag.to_list

olive spruce
onyx wagonBOT
# desert kettle !t maptag.to_list

Returns a list of all key/value pairs in this map, separated by the specified separator symbol. If none is given, uses the slash '/' symbol.
Note that there is no escaping of the separator, so maps that have the separator in their keys will not be possible to convert back to a map.
Inverted by !tag ListTag.to_map

Returns

ListTag

Examples
# Narrates "a/1", then "b/2", then "c/3"
- foreach <map[a=1;b=2;c=3].to_list> as:slashed:
    - narrate "<[slashed]>"
olive spruce
#

no not that

#

!t map.get_subset

onyx wagonBOT
royal galleon
#

no, to_list will make <list[a:b|c:d].to_list[:]> turn into [a=b;c=d]

olive spruce
#

maptag.get_subset[<maptag.keys.alphabetical>]

royal galleon
#

pretty smart

#

off topic tho, back to find_tag and find_last_tag

#

actually no

royal galleon
#

it returns a copy of the original map with a new order

#

need an additional values

#

if there's such tag

#

!t maptag.values

onyx wagonBOT
royal galleon
#

ye there is

olive spruce
#

Do you want to sort by value or by key

desert kettle
#

i believe the map based on tags

#

eg highest / equals something

#

key or value

royal galleon
royal galleon
olive spruce
#

I'm slightly confused what this does

desert kettle
#

with this:

  entries:
    - type: foo
      value: 1
    - type: bar
      value: 2

he wants to return the second map without parsing over the list at all without filtering it first

#

it can be a heavy tag with the filter

royal galleon
olive spruce
#

AH, and you want to return the VALUE

#

Okay got it now.

royal galleon
#

it's really just a quick helper i setup to be able to include lists of maps in my scripts

#

---------------------------

end of parenthesis on maps

back to the find_tag thing, i actually can't even make a proc out of it

#

a proc of this type is based on an input tag with definition, and i can't do like <[list].proc[find_tag].context[<[FILTER_VALUE].some[condition]>]> because then <[FILTER_VALUE].some[condition]> is parsed before being passed to the proc, and errors

#

so for now it's indeed limited to filter_tag.first