Labcaches

I will release two updates to the Sandbox API in a few minutes.

Both implementations are 100% untested. Feel free to test them, if they don't work, please inform me here.
None of them are documented yet. I will generate a new Doxygen documentation when I know that they work.


New method PGC.GetLabCacheFinds(profileId)
Doxygen basis

	/// @brief Returns an associative array with the labcache finds from given profileId.
	///
	/// Returned fields: guid, name, date_found
	/// @param[in] int $profileId An integer with the users profile id.

New in-parameter to PGC.GetFinds()

	/// - includeLabCaches (bool): If set to true, will include labcache finds. Note that most fields returned will be null.

If used, the data with Geocache finds will be merged with Labcache finds. It's a hack though. All fields except those mentioned here will be set to NULL. The LUA script must be able to handle that.

• cache_id - Will be set to crc32 of a GUID string.
• gccode - Will be set to the GUID of the Labcache. Example: 0008be86-1cf0-49b3-8b21-a9aa17bac1a2
• cache_name - The name of the labcache.
• visitdate - Date logged.

The implementation first fetches all geocache finds as before. When that process is done it fetches the labcache finds and append those.

After that it sorts the data again. We do not have data to sort labcaches and geocaches within the same day correctly. Geocaches will still be sorted correctly, but all the Labcache finds will be at the end of that day.

If a limit has been provided, we will slice the data array down to the limit again.



Edited 1 time(s). Last edit at 01/15/2020 11:13AM by magma1447. (view changes)

I assume it's not deployed yet?

Caught exception: attempt to call field 'GetLabCacheFinds' (a nil value)

pieterix Wrote:
-------------------------------------------------------
> I assume it's not deployed yet?
>
> Caught exception: attempt to call field
> 'GetLabCacheFinds' (a nil value)

It is, but I forgot to add the method into the Sandbox, I just wrote the code... I should have tested it myself. I will attack it tomorrow, and at least test that it gives decent data.

It's fixed now, and I made a new release.

I have tested method GetLabCacheFinds(). It seems to return relevant data.

I tested GetFinds() so that it actually runs. I did not verify that I got the data I expected. So if you do not find any labcaches here, it probably doesn't work.

Regarding GetFinds() I added these two comments:
* The field cache_id is NOT guaranteed to be unique between geocaches and labcaches.
* Filters are ignored, even for dates.

If parameter includeLabCaches = true is set, it will return ALL LabCaches finds for that user, regardless of filters. Also note that the script can not rely on the cache_id being unique. The GC-code will be however, since it's either a GC-Code or a long GUID. As the data is today, there are 34 collisions between cache_id (int) and crc32(labcache-guid).

GetLabCacheFinds() works for me now.

I'm having trouble with GetFinds. Doing

local finds = PGC.GetFinds(profileId, { includeLabCaches = true, fields = {'gccode', 'cache_name', 'visitdate','type', 'country'}, order = 'OLDESTFIRST', filter = filter })

seems to set finds to true, instead of a table for some reason. I thought the fields/filters might mess it up somehow, and indeed with

local finds = PGC.GetFinds(profileId, { includeLabCaches = true })

the result is a table at least, however it still does not include Labs.



Edited 1 time(s). Last edit at 03/03/2020 12:22PM by PattuX. (view changes)

I will look into this. Maybe it doesn't work as it should. If you haven't heard anything on Monday, please remind me. Right now I am trying to not lose focus on the 360-tool for the The All Around Cacher. Got so many notes about it here that I want to implement most of it.

Found a sloppy error. After adding the Labcaches I need to re-sort the data. The code did a $data = uasort(...); But PHP's uasort() doesn't return the result, the parameter for the data is a reference, so it's sorted in-place. $data was set to TRUE because the sort was successful. I of course know that uasort() doesn't return the result, so it was surprising to find the error.

I will make a new release with the fix in a few minutes. I still haven't tested the code. If it still doesn't work, could you provide me with a link to a fairly simple LUA script which shows the issue?

https://project-gc.com/Challenges//46972

local finds = PGC.GetFinds(profileId, { includeLabCaches = true })

works correctly.

PGC.GetFinds(profileId, { includeLabCaches = true, fields = {'gccode', 'cache_name', 'visitdate','type', 'country'}, order = 'OLDESTFIRST', filter = filter })

however results in some backend error (see checker). Specifically, the order parameter. Without it, it works fine.



Edited 1 time(s). Last edit at 03/04/2020 09:33PM by PattuX. (view changes)

Hi Pattux, it looks interesting:)-D, but I could not get it working yet. Would you make a calender matrix checker for lab caches? It should look like this one https://project-gc.com/Challenges/GC7GQTV/31113

Such a challenge would surely not be published, see rule 10 of the guidelines.

Quote

Not allowed: Trackable, Benchmarking, Waymarking logs, or specifying Lab Cache finds.

I find "specifying" a bit vague, but I think it's fine to allow Lab Caches to count towards a challenge (i.e. as one type in "Find 100 caches for each of 7 types", or one date in "find a cache on each calendar date") but not to make them mandatory.

Also please use the Checker requests forum for checker requests.

I was just curious wether it is really possible with your script or not. Would be fun to see, since U was not able to get your https://project-gc.com/Challenges//46972 working yet

Just from a technical side it would be no problem, even now. PGC.GetLabCacheFinds(profileId) works correctly and contains log dates, so you could just modify some existing calendar checker to call that insead of PGC.GetFinds().

PattuX Wrote:
-------------------------------------------------------
> https://project-gc.com/Challenges//46972
>
>

> local finds = PGC.GetFinds(profileId, {
> includeLabCaches = true })
>

> works correctly.
>
>

> PGC.GetFinds(profileId, { includeLabCaches = true,
> fields = {'gccode', 'cache_name',
> 'visitdate','type', 'country'}, order =
> 'OLDESTFIRST', filter = filter })
>

> however results in some backend error (see
> e checker). Specifically, the order parameter.
> Without it, it works fine.

Thank you for the script, most helpful.

I have found three issues, and corrected them in the development environment. I am aiming for a new release before 3 pm CET today. Could also be within an hour. Just have some other things to cleanup first.

Issue 1) When specifying fields, some fields are always added even though you don't request them. Those are fields used by the code. The log_id is required for the re-sort after adding Labcaches, but it was missing in the list of always-add-fields. Therefore you got the errors you got.
Issue 2) Type wasn't set to anything. It will from now on be set to *Labcache* (no stars).
Issue 3) Fields that doesn't exist for labcaches, should be filled with NULL. The callback has a mapping between field names and database column names, with table prefixes. Instead of setting for example log_id to NULL, I was setting l.log_id to NULL. I was using the value in the table instead of the key.

Conclusion: I need to trust myself less when changing the LUA callbacks. Seems like I more often get it wrong than right. At least I did say it was untested this time. :)

Typical example of a row from a labcache when fiels isn't specified:

    'gccode' => 'e71611de-13a8-42c3-8b66-879021f7bae4',
    'cache_id' => 1157519609,
    'cache_name' => 'Adventure 10 - Find the image',
    'type' => 'Labcache',
    'difficulty' => NULL,
    'terrain' => NULL,
    'size' => NULL,
    'owner_id' => NULL,
    'placed_by' => NULL,
    'latitude' => NULL,
    'longitude' => NULL,
    'elevation' => NULL,
    'hidden' => NULL,
    'last_publish_date' => NULL,
    'country' => NULL,
    'region' => NULL,
    'county' => NULL,
    'archived' => NULL,
    'disabled' => NULL,
    'premium' => NULL,
    'last_find_date' => NULL,
    'last_archive_date' => NULL,
    'num_finds' => NULL,
    'latest_logs' => NULL,
    'favorite_points' => NULL,
    'favorite_points_pct' => NULL,
    'favorite_points_wilson' => NULL,
    'last_cache_harvest' => NULL,
    'last_log_harvest' => NULL,
    'log_id' => NULL,
    'visitdate' => '2020-01-27',
    'length' => NULL,
    'words' => NULL,
    'attributes_set_1' => NULL,
    'attributes_set_2' => NULL,
    'attributes_unset_1' => NULL,
    'attributes_unset_2' => NULL,

I hope it works better for you now. I couldn't see anything else that's weird.

Thanks, I'll have a look later when it's live.

> Issue 2) Type wasn't set to anything. It will from now on be set to *Labcache* (no stars).

On gc.com it's 'Lab Cache' btw. I guess it doesn't break anything but consistency is always nice.

PattuX Wrote:
-------------------------------------------------------
> On gc.com it's 'Lab Cache' btw. I guess it doesn't
> break anything but consistency is always nice.

I'll update to 'Lab Cache' before the release. If I forget, please remind me.

I had used the name 'Lab Cache' in Profile stats as well. I have changed the LUA callback to that now, and am preparing a release. Expect it to be live in ~5 minutes.

Seems to be working :)

I also tried filters any everything seems fine so far. I'll let you know should I find some error.

Ok, thank you for your effort Pattux and Magma1447, I could use your challenge checker now too, however I am still having problems with this issue:

This multi cache calender checker https://project-gc.com/Challenges/GC7GQTV/31113 uses this source: Generic calendar checker, by pinkunicorn

It displays every calendar day with a multi cache find in a nice looking table.

The decision, that multi caches are to be checked is made not by the source but with the tag config. I was able to change it from multi cache calender checker to traditional cache calender checker by changing the word multi cache into traditional cache in the tag config. However, changing it into Lab Cache does not show any finds, even though I definitely have found la caches on several days. In the source of Generic calendar checker there are lab caches mentioned with all the other caches, there is a lab cache icon with all the other icons, so I can not find the mistake.

That script doesn't support Lab Caches, like most aren't. It just happens to have a copy/paste-block with the name and an icon. It's not fetching Lab caches from the API for example.

There probably aren't many active scripts handling Lab caches, probably even fewer that hasn't been created this year, if any.

I guess it is not possible to change the script so it supports it?

It seems to be possible and I'm planning to do that (it's my script).

I don't think this thread is the right place for that discussions. But since it's possible to write such script, it's possible to change the script into handling it.

I can't answer for how hard it is since I don't know the script. It can possibly have unintended side-effects on other features in the script. It could very well be smarter to create a new script, that does what you want, therefore requesting a check could be more wise. I am personally for many small script that fills few purposes rather than gigantic unreadable scripts that does everything.

Ok, I will simply request one. ;-)

I've just updated the Multiple Test Checker (enhanced) script to allow includeLabCaches parameter for the functions which make sense to allow it (calendar, date, number, streak and in_a_year). Default is off, so that it doesn't change existing checkers.

Given HQ's apparent drive to add more Adventure Lab caches, are there any changes in the pipeline on the information that Project-GC receives from HQ regarding them? I seem to recall (and I can't find the thread where this was mentioned) that PGC receives almost no information on them, eg. no owner, coordinates, etc.

I can't find that post either, even though I actually saw it this morning. I know I posted the DB schema definitions of the tables.

There currently are no changes. I hope to be able to get the owner of them in the future, and maybe even coordinates. I don't know if they have coordinates for all or just some. Also, I don't know how relevant the coordinates actually are.

Also, is there actually any of this information that would be relevant for challenges? I doubt it, at least with current guidelines. You are not even allowed to create a challenge that requires you to log a lab cache.

Well, coordinates could give you country/region/county data, so they could be included in those type of challenges, in the same way that they may count for calendar finds, even though you may not explicitly request them. My above question was more aimed at for-my-info than a real request for challenges.

As for the information about who is the owner of lab caches, I can note that the lab cache app doesn't seem to know that itself: it shows my own adventure as just any unlogged adventure.

Yes, I've noticed that too. Which means I could potentially log my own one. Silly.

If I recall correctly - Their documentation even says that you could/should log your own. Even sillier.

magma1447 Wrote:
-------------------------------------------------------
> If I recall correctly - Their documentation even
> says that you could/should log your own. Even
> sillier.

I can't find anything about that in their regular help pages, at least.

I have spent some time trying to track down where I read it. I can't find it.

I did however get a confirm from a Geocacher that had asked HQ, who said it was ok.

Coordinates doesn't automatically get you the country, that's fairly complex and I am not sure that's a good route to walk either. However, it's likely that Project-GC will try to handle that at some point. But as long as they don't have a country field in HQs DB I don't think it's a good idea to use it. Mostly because it's not HQs intent.

Yes, they may be included when calculating calendars - and Project-GC already has support for that.

Remark on the calendars
The time stamp on logs for Lab caches is Seatle, so on calendars for instead in Australia the day found is a lot of difference

Just a note on that - the API seems to provide the correct date, Geocaching.com seems (or at least seemed the last time I checked) to reassign the lab cache finds to the Seattle date at the time. PGC is reporting my lab cache finds on the correct dates (or at least is reporting the leap day finds on the correct date).

Hope this is the right place to ask,
since lab caches icons are now displayed in the geocaching app, are there any attemps to include Lab finds into those 360° Challenges like this one?

https://project-gc.com/Challenges/GC58QY2

Team On Wrote:
-------------------------------------------------------
> Hope this is the right place to ask,
> since lab caches icons are now displayed in the
> geocaching app, are there any attemps to include
> Lab finds into those 360° Challenges like this
> one?
>
> https://project-gc.com/Challenges/GC58QY2

The 360-challenges are considered grandfathered and it's not likely there will be any code changes at all. Not the least since no new such challenges are allowed to be published.

Labcaches still aren't geocaches technically and Project-GC does not have the information needed to make the change you request. In fact, the data you need aren't shown on the maps either. The icon you see is some location chosen by the ALC owner, it's not the coordinates for each step, which should be the ones considered being "geocaches".