There are few caches that has attribute that is not defined in the array returned from PGC.GetAttributeList()
At least this cache https://coord.info/GC684 has attribute 16 (cactii nearby - what hell it was?).
My script crached for the users that founds this cache.
There are a couple of solutions:
after getting attribute list add to the array the missing attributes
wait until Magnus updates the getAttributeList
ignore any attribute that is not present in the array, something like
if attrlist[attr_index] then
ignore the attribute
A combination of notes to self, and presenting some facts...
The GCCOM API has a method to get all attributes. The attribute Cactus (id 16) exists according to the API.
There seems to be four geocaches in the world with this attribute.
GC684, GC19X08, GC1BHCR, GC1BXH4
Only the first isn't archived, the other three are. There is no working image at Geocaching.com either.
It doesn't seem like it's ever "unset".
Since we haven't seem this before, my guess is that something has changed at Geocaching.com. They probably never exposed that geocaches had that attribute before, but now it does.
It doesn't seem like the attribute should exist, so I do not want to add it into my database table of attributes that exists, and I don't want to add it into the API method to get all attributes available.
Since it's not affecting anything on the web, I prefer to not ignore the attribute when writing cache data to the database. Until it disturbs more, it can exist there.
What seems reasonable to me, is that I will do an AND on the attributes when fetching them from the database in the LUA callback. That way the LUA Sandbox will never see attribute 16 set.
$fields['attributes_set_1'] = 'c.attributes_set_1 & 9223372036854743039'; // Remove attribute 16 (Cactus)
I have made this patch and released to Live servers. I have not tested it. Do you mind doing that?
I made a test, now the cache GC684 returns attributes_set_1=0x8d204083, so the bit 16 is not set.
Are there other obsolete attributes? Please check it and filter it.
I think that the solution of filter the invalid attributes is valid. It has no sense to create new icon for attribute that is not visualized in listing and is set in only one active cache.
This one also has the cactii attrubute set but also has four blanks. The API returns dangerous animals (18) correctly, but also thorns (39), which is not set according to the website. Idk whether cactii is returned obviously, since you filter it. Any idea why (1) you didn't catch this one when searching for this attibute, (2) why thorns is returned but not displayed, and (3) what the blanks might be?