Found Archived Adventures Not Accessible

[+Clan-Wallace]

When looking at the Adventure Labs View Finds web page, when you select the banner of an Archived (non-public) Adventure, it correctly takes you to the Adventure's description page, which also has the QR code so that you can scan with the AL App to open that Adventure for more details.

If you shared the link to the Archived Adventure with a user who has not found it, they do not get access to these details. I get that.

However, just lately, some of these Found Archived Adventures return Error 500 and are no longer accessible. In fact, we have a broken link, which will give any web master a very poor rating using the various web tools.

If I use the AL App and filter on Completed ALs, then try to view one of these Adventures, they do not appear in the App.

If I try to access the Adventure via the API using the Adventure Id, we get a 404 status code and obviously no returned data.

Can it be explained to me why I am no longer able to access, in any way, some of my Found Archived Adventure details?

While on the subject of Found Adventure Labs, with Caches, we can download the 'MyFinds' pocket query, which also includes all the Archived Found Caches.

Can the web page include an option to download our Adventure Finds in the same way so that we can combine all our finds together as waypoints in an app such as GSAK? This would allow us to correctly generate stats for our Geocaching activities. Such as in the attached image.

 

[+Max and 99]

2 minutes ago, Clan-Wallace said:

Can it be explained to me why I am no longer able to access, in any way, some of my Found Archived Adventure details?

I guess cuz it's archived. 

It's not meant to be seen anymore.

If there's a reason you need to see something from one of the locations maybe the AL owner can help?

None of the ones I have completed have been archived. 

[+Clan-Wallace]

Quote

14 hours ago, Max and 99 said:

I guess cuz it's archived. 

 

 

'Archived is not the same thing as 'Found Archived' (Or Found 'Private' or Found 'Off').

 

In your 'MyFinds' PQ, you get all your 'Found Archived' caches and if you follow the URL of that cache, you access the 'Found Archived' cache details.

• 'Found Archived' caches are part of your total finds.
• 'Found Archived' caches are part of your Geocaching history of where you have cached and part of your geocaching statistics.

Users would be very unhappy if GS removed 'Found Archived' caches from their MyFinds data and it would make no sense if they did.

 

When GS made Lab Stages into Geocaching finds, they became part of a users total finds, their history, their statistics and they expect, that when you follow a link on their Lab Finds web page, they can view or record data for their found Adventure.

 

Now this is true with the current Lab Finds web page, we can do all of these things, even for 'Hidden' Adventures.

 

But we are missing the point of this post.

 

Why do some 'Hidden' Found Adventures (I only have one out of my 10 hidden ones but I know others are also experiencing the same issue) suddenly have 'broken' links?

[+thebruce0]

3 hours ago, Clan-Wallace said:

When GS made Lab Stages into Geocaching finds, they became part of a users total finds, their history, their statistics and they expect, that when you follow a link on their Lab Finds web page, they can view or record data for their found Adventure.

 

This touches a bit on why Adventures are not the same as Geocache listings.  Earlier on there was the issue with people reusing adventures in other locations, remade, and messing up people's histories. Cache listings have a log that remains attached to the GC code. In theory people could rework the GC listing to something else, but that happens FAR less often than ALs being reworked to something complete different. ALs don't (at least on the surface) have distinct logs like cache finds do. AL find history comes off more like a lookup of an Adventure marked complete, to see all its details, where cache finds feel more like looking up your actual find log - though it still pulls all the data from the current cache listing it's connected to. Minor difference, but the implementation still feels different. Project-GC can now look up finds on cache listings as of the find date (eg, using the DT history checker), but ALs don't have that luxury.

 

AL finds are often out of timing with cache finds because AL completions are immediate whereas cache logs can be posted as drafts; so a day of caching may look like 20 AL stages followed by 20 finds, when in reality they were all intermingled.

 

So, when GS made Adventure locations part of the stats, in a way they reduced the implication of the 'cache find history' towards more just a generic record of finds/completions than a chronological history of caching activities. And because of the more 'live' lookup for AL data, and less of a sense of one-made-becomes-history that caches have, I find AL history to be less consistently reliable, despite being a part of our "geocaching" history.

 

The closest it could get I think is making AL completions distinct logs (like cache listings), and if an AL changes, it becomes disconnected from its prior completion logs. Then at least people can know that when they look at their AL completion history, if the AL is no longer what was originally completed, they won't see an Adventure marked found that they don't remember at all.  But that would be a significant overhaul of the logging process for ALs... 

 

It's that or disallowing Adventure edits after some arbitrary threshold of time or activity... =/

[+Clan-Wallace]

19 minutes ago, thebruce0 said:

AL finds are often out of timing with cache finds because AL completions are immediate whereas cache logs can be posted as drafts; so a day of caching may look like 20 AL stages followed by 20 finds, when in reality they were all intermingled.

Found Lab Stages do have a Log Id but they are out of sequence with Cache Ids. So you are correct in that displaying ALs and Caches together, we get all the Caches in one group and all the Lab Stages in another group, albeit, at least they are on the same day found.

Because Lab Stages do have a Log Id, you can display them in the order they were found within a specific day.
Take a look at some stats' my macro produces, For the AL Source to sea: The River Hamble, I deliberately found some on different days and a couple on the same day just for testing.

 

 

The different days are in order and if we focus on the same day I completed two labs, 2023-08-18, we can see that Lab 5, LBU6Xi05 (As stored in the GS database) was Find 4 ( Overall 552 ) for Adventure 95 and then I found another different AL Lab Stage (Overall lab find 553). Then I came back to the next Lab 3, LBU6Xi03 which was Find 5 ( Overall 554 ) for Adventure 95.

 

So it is possible to have a bit of history.
 

[+thebruce0]

Right, the timestamps of completions are recorded, it's just the mechanics of the AL vs the GC that means the typical user process will live-log an AL (though you can work around it by using the 'offline' method of flagging the location as visited and entering what you believe to be the correct code after you've posted any prior GC logs), and display activity out of [daily] chronological order. You could also just live-log GCs all the time, but that's a 'fix' to accommodate the default mechanic of the AL, since there's no 'draft' AL completion. So there are ways to minimize the difference between the mechanics, but the typical and expected process puts completions and log posts into two groupings. A minor annoyance, but another practical example of why ALs and GCs are not the same thing.  If you have to alter the expected ways of doing things or use 3rd party tools to see things the way you'd expect them to be seen...

 

The way I do things, I'm sure using the macro would put my activity back in true chronological order, since Drafts keep the timestamp of when you create them in the app (official and Cachly) so when they are composed (in app or via web) they keep their timestamp. BUT iirc, logs are displayed in cache histories by date first, then by those with timestamps (posted by API) first and then by log creation ID.  So in a profile activity history list, AL locations would still appear mixed with API-based GC logs, and out of order to non-API posted logs (but there's no way around that, and it applies to gc logs as well anyway).

 

Also although being different systems, we still have to rely on the timezone data being stored accurately (or equivalently) for both AL completions and GC logs; I'm not sure how consistent that is since we keep seeing international timezoning issues in various aspects of this GC hobby