Souvenirs don't get removed...

2.1k · September 23, 2013

In our area a local cacher apparently decided he wanted all the August souvenirs so he logged at least one find per day even though it required logging a few caches he did not actually find.

Two of us noticed this and checked cache logs at two groupings of caches. In five or six instances he did not sign logs and we believe he did not visit those caches. He did visit other caches in the groups but did so all on one day for each group and then logged the finds as one per day.

I emailed him to say that I did not see his signature in three caches and suggested that he might have done this in error and that he should delete those finds or go back and sign the logs. No response. The two of us then deleted the five or six without signatures a few weeks ago and we noticed that the souvenirs are still in place.

This is not a big deal in the great scheme of things but if folks find out they can post invalid finds to get the souvenirs and that deleting those finds later will not remove the souvenir we might get a new wave of "greetings" logs.

3.6k · September 23, 2013

I spend my time worrying about other things beside geocaching.

8.3k · September 23, 2013

I spend my time worrying about other things beside geocaching.

What? The owner of the cache drama thread does not worry about geocaching? Shocking.

But really Team Sagefox was pointing out a MAGOR bug in the souvenir software. Removing the find does not remove the souvenir. I also consider it a bug. It did occur to me that Groundspeak considers it a feature.

1.9k · September 23, 2013

There are so many ways that others cache that are different from the way we cache. It doesn't affect us and we don't really care. It's just a game.

September 23, 2013

I'm more bothered by the fact that caching Belgium or Venice doesn't get you any special souvenirs, but I completely agree that not removing souvenirs for deleted finds is a bug and not a feature that should be handled by Groundspeak.

9.2k · September 23, 2013

Or, at least 'Play Fair' in log the cache as found, get the souvenir, delete the log yourself...

It would save the CO's so much trouble and grief.

8.3k · September 23, 2013

Or, at least 'Play Fair' in log the cache as found, get the souvenir, delete the log yourself...

It would save the CO's so much trouble and grief.

What is even more interesting with this "feature" you don't even have to log a cache, just change the date on an existing log and then move it back to the original date. A souvenir will magically appear on your souvenir page.

September 24, 2013

I noticed several occasions when an out of town person logged that they'd attended an event in my area, only to delete that log later. The souvenir is still awarded.

September 24, 2013

But really Team Sagefox was pointing out a MAGOR bug in the souvenir software. Removing the find does not remove the souvenir. I also consider it a bug. It did occur to me that Groundspeak considers it a feature.

Sounds like some Medieval German warrior. Magor the Terrible!

Anyway, I do agree. This is a bug that should be fixed, although I am sure there are many higher priority's that TPTB have planned for us:blink:.

7.4k · September 24, 2013

The issue is that souvenirs are not tied to a single log in the database. When a log is posted, it's easy to check and see if it should award a souvenir and if the user already has that souvenir. It's not so straightforward when a log is deleted. To remove a souvenir in that situation, the system would need to check all of the remaining logs by that account to determine if any of them would warrant the souvenir. That would be a ton of expensive overhead.

What we would like to see in the future is the ability for people to manually remove souvenirs they don't want. That won't stop some from gaming the system, though.

10.1k · September 24, 2013

But really Team Sagefox was pointing out a MAGOR bug in the souvenir software. Removing the find does not remove the souvenir. I also consider it a bug. It did occur to me that Groundspeak considers it a feature.

Let's make better mistakes tomorrow? Seems to be a lack of consistency and follow through. Seems common here. If "A" then "B". If I mistakenly 'find' a cache in Hessen, I receive the souvenir, f I delete that mistaken 'find', the souvenir remains. That would require a program to determine if I still qualify for the Hessen souvenir. No. I do not. That would take planning, programming and consistency. There are many examples of inconsistency on this web site. Perhaps not "Let's make better mistakes tomorrow", but rather "Why bother following this thought through to make it consistent?" Lack of consistent thinking, and more programming from the development team? If I delete a find, there should be a program to determine if I still qualify for the souvenir. But the programming team does not seem to be able to program for consistency, only for new ideas. And, thus, we will see better mistakes tomorrow. No follow through for consistency.

21.9k · September 24, 2013

I'd venture a guess that you'd read a lot more informative explanations like Moun10Bike's post if there weren't so many contemptuous replies like Harry Dolphin's. I'll bookmark this for linking to when people complain that Groundspeak isn't as active in the forums as they should be.

8k · September 24, 2013

What we would like to see in the future is the ability for people to manually remove souvenirs they don't want. That won't stop some from gaming the system, though.

I was going to write that I don't consider that fact that people can game the system a bug. But it is certainly a bug that if someone makes a mistake and enters the wrong date on a log (easy to do), that they have no way to correct their souvenir record.

However, IMO, deleting souvenirs that you actually earned just because you find some souvies less worthy is just as much "gaming the system" as it is to claim souvies you're not really entitled to.

8.3k · September 24, 2013

The issue is that souvenirs are not tied to a single log in the database. When a log is posted, it's easy to check and see if it should award a souvenir and if the user already has that souvenir. It's not so straightforward when a log is deleted. To remove a souvenir in that situation, the system would need to check all of the remaining logs by that account to determine if any of them would warrant the souvenir. That would be a ton of expensive overhead.

What we would like to see in the future is the ability for people to manually remove souvenirs they don't want. That won't stop some from gaming the system, though.

I bet a lot of users would like to see that feature also.

2.1k · September 24, 2013

...Perhaps not "Let's make better mistakes tomorrow", but rather "Why bother following this thought through to make it consistent?" Lack of consistent thinking, and more programming from the development team?

...But the programming team does not seem to be able to program for consistency, only for new ideas. And, thus, we will see better mistakes tomorrow. No follow through for consistency.

This makes me sorry that I brought up the subject.

Groundspeak team, I'm in your corner. Keep up the good work.

5k · September 24, 2013

In our area a local cacher apparently decided he wanted all the August souvenirs so he logged at least one find per day even though it required logging a few caches he did not actually find.

Two of us noticed this and checked cache logs at two groupings of caches. In five or six instances he did not sign logs and we believe he did not visit those caches. He did visit other caches in the groups but did so all on one day for each group and then logged the finds as one per day.

I emailed him to say that I did not see his signature in three caches and suggested that he might have done this in error and that he should delete those finds or go back and sign the logs. No response. The two of us then deleted the five or six without signatures a few weeks ago and we noticed that the souvenirs are still in place.

This is not a big deal in the great scheme of things but if folks find out they can post invalid finds to get the souvenirs and that deleting those finds later will not remove the souvenir we might get a new wave of "greetings" logs.

If you don't want folks to find out, why did you post the info to a world wide forum? Seriously, the problem of sticky souvenirs has been talked about since they were created. Personally, I think that if someone wants to show everyone that they has the integrity of a worm by claiming phoney souvenirs, let them. It's kind of like logging your own cache.

2.1k · September 24, 2013

If you don't want folks to find out, why did you post the info to a world wide forum?

How many of the folks that might want a sticky souvenir, armchair virtual, or virtual TB discover do you think spend any time in the forums? What percentage of all geocachers read or are even aware of the forums?

September 24, 2013

But really Team Sagefox was pointing out a MAGOR bug in the souvenir software. Removing the find does not remove the souvenir. I also consider it a bug. It did occur to me that Groundspeak considers it a feature.

Let's make better mistakes tomorrow? Seems to be a lack of consistency and follow through. Seems common here. If "A" then "B". If I mistakenly 'find' a cache in Hessen, I receive the souvenir, f I delete that mistaken 'find', the souvenir remains. That would require a program to determine if I still qualify for the Hessen souvenir. No. I do not. That would take planning, programming and consistency. There are many examples of inconsistency on this web site. Perhaps not "Let's make better mistakes tomorrow", but rather "Why bother following this thought through to make it consistent?" Lack of consistent thinking, and more programming from the development team? If I delete a find, there should be a program to determine if I still qualify for the souvenir. But the programming team does not seem to be able to program for consistency, only for new ideas. And, thus, we will see better mistakes tomorrow. No follow through for consistency.

The point Moun10bike clearly made is that it's a whole lot more elaborate and time-consuming for the system to check.

When you log a cache, the system would need to check whether that cache qualifies for a souvenir. If you qualify, set that souvenir to true. It doesn't matter if the souvenir was already true, it doesn't have to check. It would have to look up against, say, 200+ sets of criteria for the same number of souvenirs (number guesstimated)

When you delete a log, the system has to perform the same check, then for each souvenir, interrogate every other found log you've ever logged (tens of thousands potentially) to see if any of them match the same criteria.

In summary, a couple of hundred steps potentially looped tens of thousands of times.

So yes it can be done, but If they did implement it, it would slow down the site generally, and then people would be complaining about that instead. I'm with GS on this one.

5k · September 24, 2013

If you don't want folks to find out, why did you post the info to a world wide forum?

How many of the folks that might want a sticky souvenir, armchair virtual, or virtual TB discover do you think spend any time in the forums? What percentage of all geocachers read or are even aware of the forums?

Well, first you have to define geocachers. I sometimes think that Groundspeak has a different definition than most of us. Does finding one cache with a friend make you a geocacher. I've played baseball but I wouldn't characterize myself as a baseball player. I sure that when you get the chaff out of the wheat, it's a tiny percentage.

But, it should have been obvious from the rest of my post that I was poking a bit of fun. I believe that the cachers that would exploit this have their own network where they pass around lists of solved puzzles, abandoned virtuals and geocoin tracking codes.

September 25, 2013

Lots of constructive conversation on a complicated topic, guys. That's what I like to see. It's always okay to ask questions, good to get the brains together, and think the tough things through. There's a lot of great collective knowledge between everybody who is active here. I think that there is so much value in working together on the same team to talk out some of the bigger issues within the game. Bringing understanding to the issues and having thoughtful, constructive conversations are what the forums are all about. Thanks for being a part of the bigger picture.

6k · September 26, 2013

There are lots of way to "game" the system as you said. It is very difficult to build a system that prevents people from getting something they don't deserve. For instance if I wanted the August souvenirs I could just go to one of my archived caches that isn't locked and log it every day. Not a problem. Get the souv and then delete the log. I'm not all that interested so I won't. Personally I don't care if someone "gets over" on the system. I do this for my enjoyment. Although I did get most.

Another example. Los Angeles school embarked on a plan this year to give every student an iPad for school work only and they had security setup to restrict it to that. One week after giving the first batch out the security was compromised by a student who spread the word and now they can access whatever they want.

Edited September 26, 2013 by Walts Hunting

August 16, 2014

If someone tells me they're a college graduate, I typically believe them without asking to see their diploma and a notarized copy of their college transcript.

If a drug-addicted ex-con tells me they graduated from Harvard, I might tend to disbelieve that.

Same thing goes with souvenirs. If you're the type that absolutely must at least touch the container when a group finds a cache, and wouldn't dare log a find without it, you're probably thought of as an upstanding person. I'd tend to believe that your souvenirs are legit. But if you're the type of cacher that lets other people solve the puzzles and waits in the car while somebody else jumps out to go climb the tree and sign the log, well... your collection of souvenirs probably won't impress me too much.

If you want to cheat, feel free, it doesn't effect me, you're only cheating yourself and making yourself less credible. Just don't brag about your latest souvenir, because I'll probably think you're full of crap.

Edited August 16, 2014 by GeekinTX

8.3k · August 16, 2014

The issue is that souvenirs are not tied to a single log in the database. When a log is posted, it's easy to check and see if it should award a souvenir and if the user already has that souvenir. It's not so straightforward when a log is deleted. To remove a souvenir in that situation, the system would need to check all of the remaining logs by that account to determine if any of them would warrant the souvenir. That would be a ton of expensive overhead.

What we would like to see in the future is the ability for people to manually remove souvenirs they don't want. That won't stop some from gaming the system, though.

Radnor gave us that ability on the Groundspeak profile pages. Thank you Radnor.

Now we need the API guys to check the column Radnor put in the database to suppress showing the souvenir on the Groundspeak profile pages so the API does not return the hidden souvenir. Then the souvenir will be gone from project-gc's profile page also.

3.3k · August 16, 2014

The issue is that souvenirs are not tied to a single log in the database. When a log is posted, it's easy to check and see if it should award a souvenir and if the user already has that souvenir. It's not so straightforward when a log is deleted. To remove a souvenir in that situation, the system would need to check all of the remaining logs by that account to determine if any of them would warrant the souvenir. That would be a ton of expensive overhead.

What we would like to see in the future is the ability for people to manually remove souvenirs they don't want. That won't stop some from gaming the system, though.

Is it really a ton of expensive overhead?

If you've got a souvenir based on some combination of location/cache type/find date the process should be simple. If a find log is deleted or changed the process runs:

1. Check to see what, if any, souvenirs the log would have earned

2. Scan remaining logs to see if any qualify for the souvenir

3. If (2) returns no results, delete the souvenir.

So if you've got a souvenir for finding a cache in Kansas and delete the log, all it has to do is find any other Find log (or equivalent - Attended/Took Photo) against any cache in Kansas. If you've got a souvenir for a multicache in August 2014 and change the Find to a Note it just looks for a multicache in August 2014. Instead of a process people think of as being slow that involves checking every single log, a single SELECT statement will do the trick.

Something like "select count(*) from logs, caches where logs.cacheid = caches.cacheid and logs.user='team tisri' and logs.logtype = 'Found' and caches.state = 'Kansas'" would do the trick. If the database supports an EXISTS statement it could be faster still, as the first matching hit would mean it wouldn't need to scan the rest of the tables.

Maybe put some kind of user counter in place so that if someone deletes or changes more than 10 logs in 24 hours it just tags them for revalidation at the end of the day just in case someone decides to try and jam up the system by endlessly logging and deleting logs, although I'd expect the time delays associated with the web interface to be more severe than the load on the server.

3.3k · August 16, 2014

I'd venture a guess that you'd read a lot more informative explanations like Moun10Bike's post if there weren't so many contemptuous replies like Harry Dolphin's. I'll bookmark this for linking to when people complain that Groundspeak isn't as active in the forums as they should be.

With respect Keystone, I think it's entirely reasonable to point out where the site appears inconsistent, where features appear to have been inadequately thought through and where the fanfare of things like the seemingly endless souvenirs then leads to something that is so easily cheated it's almost comical.

When we can't have virtual caches because there's no physical log to sign but we can have events, mega events and more recently giga events where there is no requirement to sign a log, where we can't have virtuals because they might lack the "wow" factor but can have endless soggy film pots behind posts, and where there is concern about cheating but then the souvenirs are awarded forever even when it's clear the qualifying log(s) were fabricated, what sort of feedback would you expect people to give?

But really Team Sagefox was pointing out a MAGOR bug in the souvenir software. Removing the find does not remove the souvenir. I also consider it a bug. It did occur to me that Groundspeak considers it a feature.

Let's make better mistakes tomorrow? Seems to be a lack of consistency and follow through. Seems common here. If "A" then "B". If I mistakenly 'find' a cache in Hessen, I receive the souvenir, f I delete that mistaken 'find', the souvenir remains. That would require a program to determine if I still qualify for the Hessen souvenir. No. I do not. That would take planning, programming and consistency. There are many examples of inconsistency on this web site. Perhaps not "Let's make better mistakes tomorrow", but rather "Why bother following this thought through to make it consistent?" Lack of consistent thinking, and more programming from the development team? If I delete a find, there should be a program to determine if I still qualify for the souvenir. But the programming team does not seem to be able to program for consistency, only for new ideas. And, thus, we will see better mistakes tomorrow. No follow through for consistency.

The point Moun10bike clearly made is that it's a whole lot more elaborate and time-consuming for the system to check.

When you log a cache, the system would need to check whether that cache qualifies for a souvenir. If you qualify, set that souvenir to true. It doesn't matter if the souvenir was already true, it doesn't have to check. It would have to look up against, say, 200+ sets of criteria for the same number of souvenirs (number guesstimated)

When you delete a log, the system has to perform the same check, then for each souvenir, interrogate every other found log you've ever logged (tens of thousands potentially) to see if any of them match the same criteria.

In summary, a couple of hundred steps potentially looped tens of thousands of times.

So yes it can be done, but If they did implement it, it would slow down the site generally, and then people would be complaining about that instead. I'm with GS on this one.

It doesn't need to revalidate every souvenir. If you delete a log the system only needs to revalidate the souvenir(s) that were awarded as a result of that log. So if I delete a Found log relating to a cache in Kansas all the system needs to determine is whether I still qualify for the Kansas souvenir. There's no need to check the other 49 states because the log I deleted makes no difference to those.

5.6k · August 17, 2014

@team_tisri

While you say "There's no need to check the other 49 states" .. well, it might as well do so since the only way to validate a single state is to review every one of your found logs since you began caching for a second match.

That said, how often does anyone delete a found log? One wouldn't think the overhead involved in this would be much at all due to the infrequency of the event itself.

3.3k · August 18, 2014

@team_tisri

While you say "There's no need to check the other 49 states" .. well, it might as well do so since the only way to validate a single state is to review every one of your found logs since you began caching for a second match.

There's no point validating all the other souvenirs because it's a waste of processor time.

If I delete a Find log against a cache in Kansas all the system has to do is check whether I have a single other Find against a cache in Kansas to see if I still qualify for the souvenir. So as soon as it finds a single qualifying cache it can stop looking because it knows I still qualify.

So rolling with this example (I'll switch from Kansas to Pennsylvania since I have found caches there), if I delete my last Find log in Pennsylvania what the system needs to know is "do I still have a find in Pennsylvania". So it starts with my first find and looks at them. After about 400 caches it will hit my first Find in Pennsylvania, at which point it can stop searching. It doesn't need to look at the remaining 1800-odd finds because it has already confirmed that the answer to the question is that I do still have at least one find in PA. There's no need to look any further because the answer to the question won't change. So in this example looking to revalidate every souvenir would take nearly six times as much processing just to look through the logs, when the only souvenir that is in question relates to the log that was deleted.

That said, how often does anyone delete a found log? One wouldn't think the overhead involved in this would be much at all due to the infrequency of the event itself.

I wouldn't have thought so but don't have the stats.

August 19, 2014

@team_tisri

While you say "There's no need to check the other 49 states" .. well, it might as well do so since the only way to validate a single state is to review every one of your found logs since you began caching for a second match.

There's no point validating all the other souvenirs because it's a waste of processor time.

If I delete a Find log against a cache in Kansas all the system has to do is check whether I have a single other Find against a cache in Kansas to see if I still qualify for the souvenir. So as soon as it finds a single qualifying cache it can stop looking because it knows I still qualify.

So rolling with this example (I'll switch from Kansas to Pennsylvania since I have found caches there), if I delete my last Find log in Pennsylvania what the system needs to know is "do I still have a find in Pennsylvania". So it starts with my first find and looks at them. After about 400 caches it will hit my first Find in Pennsylvania, at which point it can stop searching. It doesn't need to look at the remaining 1800-odd finds because it has already confirmed that the answer to the question is that I do still have at least one find in PA. There's no need to look any further because the answer to the question won't change. So in this example looking to revalidate every souvenir would take nearly six times as much processing just to look through the logs, when the only souvenir that is in question relates to the log that was deleted.

That said, how often does anyone delete a found log? One wouldn't think the overhead involved in this would be much at all due to the infrequency of the event itself.

I wouldn't have thought so but don't have the stats.

Delete or change a log from Found.

3.3k · August 19, 2014

@team_tisri

While you say "There's no need to check the other 49 states" .. well, it might as well do so since the only way to validate a single state is to review every one of your found logs since you began caching for a second match.

There's no point validating all the other souvenirs because it's a waste of processor time.

If I delete a Find log against a cache in Kansas all the system has to do is check whether I have a single other Find against a cache in Kansas to see if I still qualify for the souvenir. So as soon as it finds a single qualifying cache it can stop looking because it knows I still qualify.

So rolling with this example (I'll switch from Kansas to Pennsylvania since I have found caches there), if I delete my last Find log in Pennsylvania what the system needs to know is "do I still have a find in Pennsylvania". So it starts with my first find and looks at them. After about 400 caches it will hit my first Find in Pennsylvania, at which point it can stop searching. It doesn't need to look at the remaining 1800-odd finds because it has already confirmed that the answer to the question is that I do still have at least one find in PA. There's no need to look any further because the answer to the question won't change. So in this example looking to revalidate every souvenir would take nearly six times as much processing just to look through the logs, when the only souvenir that is in question relates to the log that was deleted.

That said, how often does anyone delete a found log? One wouldn't think the overhead involved in this would be much at all due to the infrequency of the event itself.

I wouldn't have thought so but don't have the stats.

Delete or change a log from Found.

huh?

9k · August 19, 2014

I think the issue is that yes, while a single select can (for most souvenirs, presumably) do a validation check, the structure of their backend database(s)/server(s) doesn't make it so cut and dry... Unless we can speak to one of the developers, we can offer suggestions (and I feel like I can guarantee they have already thought of most anything we suggest, especially if it's as easy as a simple select), but we can't know precisely why it may not be implemented. And jumping on the vitriolic bandwagon is not respectful or productive.

As implied, constructive discussion about possible solutions might produce something devs hadn't considered, and might eventually get implemented in whatever manner works for the system they've built (which we do not know first hand).

My thoughts on the process:

1) On Find deletion (or log type/date change), trigger the reverse souvenir check

2) Since Posting a log AS a find must scan available/active souvenirs for which are relevant, this function already exists for the reverse; do it again

3) Theoretically, a souvenir algorithm could be complex, or it could just be a matter of a simple property (find date, cache state, etc). For the latter, running a check on Find logs for each relevant souvenir is functionally simple.

eg.

A] Post a find in Illinois, execute souvenir algorithms (1) the Illinois algorithm will say that souvenir is relevant; (2) if not rewarded, reward; else do nothing.

B] Delete a find in Illinois, execute souvenir algorithms (1) the Illinois algorithm will say that souvenir is relevant, (3) scan Find log history for one qualifying log; if exists, do nothing, else remove the souvenir

It means that each souvenir would need an explicit 'reverse' function (3) in addition to the reward function (2), but the validation check (1) would be the same either way.

Additionally, if souvenirs are rewarded for a limited period of time, ONLY (2) could be disabled - but for perpetuity, (1) and (3) would need to remain active, and if there end up being hundreds or thousands of souvenirs over time, that would most certainly become a very significant burden on the system when someone deletes/changes a find log.

Also additionally, consider what properties of a 'find' are currently utilized in souvenirs: Date, State/Province/Country, Profile check for existing souvenirs (All 31 days? All 6 cache types?)... What if they create a souvenir for other cache properties? For collective achievements?

...that sort gets into another topic I'm worried about for souvenirs - how they've evolved from 'souvenirs' (implies location-themed collectibles) to 'achievements' (do certain tasks within a period of time, location may be irrelevant)... but nonetheless...

There are many factors involved with the reversal of achievement rewarding, as the system seems to work currently. So implementing a simple SELECT statement is most likely nowhere near as simple as we think it should be.

Edited August 19, 2014 by thebruce0

14k · August 19, 2014

There are many factors involved with the reversal of achievement rewarding, as the system seems to work currently. So implementing a simple SELECT statement is most likely nowhere near as simple as we think it should be.

And sometimes executing a SELECT query (which hits the database everytime) isn't the best way to handle something like this. Suppose upon login a simple select which creates a list that contains souvenir ids and a boolean value which indicates if one has qualified for the souvenir and stuffs it in memory (in ones user session). Now, everytime you post a found it/attended/photo taken or delete log, an additional hit on the database isn't needed unless there is a change in status. Unfortunately, that won't handle a case where a cache owner deletes your log. Adding complexity to a database query can produce a performance hit and sometimes grabbing more data that one might need with a single query then working in memory can speed things up.

14k · August 19, 2014

...that sort gets into another topic I'm worried about for souvenirs - how they've evolved from 'souvenirs' (implies location-themed collectibles) to 'achievements' (do certain tasks within a period of time, location may be irrelevant)... but nonetheless...

And what's annoying is despite the fact that users have specifically asked for more location-theme-collectable types of souvenirs they've discontinued them and, instead, continuing to give us achievement based souvenirs instead. Did anyone ask for a souvenir for finding a traditional cache any day of the month of August?

8.3k · August 19, 2014

...that sort gets into another topic I'm worried about for souvenirs - how they've evolved from 'souvenirs' (implies location-themed collectibles) to 'achievements' (do certain tasks within a period of time, location may be irrelevant)... but nonetheless...

And what's annoying is despite the fact that users have specifically asked for more location-theme-collectable types of souvenirs they've discontinued them and, instead, continuing to give us achievement based souvenirs instead. Did anyone ask for a souvenir for finding a traditional cache any day of the month of August?

Apparently so, but I don't recall that thread in the forums. Perhaps it was on farceface.

7.8k · August 19, 2014

Did anyone ask for a souvenir for finding a traditional cache any day of the month of August?

The requests must have come in via the mysterious feedback source where Groundspeak also learned that people wanted HTML emails.

13.7k · August 19, 2014

what's annoying is despite the fact that users have specifically asked for more location-theme-collectable types of souvenirs they've discontinued them and, instead, continuing to give us achievement based souvenirs instead. Did anyone ask for a souvenir for finding a traditional cache any day of the month of August?

Well, the hobby many of us started with has been pretty-much turned into a game (with many side games).

Maybe it used to be, but I don't believe the forum regulars are representative of the caching population.

Just found out last week that some are trying to fill a attribute grid (challenge I guess) and others are still discovering trackables like madmen.

- Who knows what that's about...

Games have points, points have goals, so achievement souvis kinda fit.

Maybe jholly's right, there does seem to be a lot of influence on faceplant.

'Scuse me while I wade into this tar pit...

3.3k · August 19, 2014

I think the issue is that yes, while a single select can (for most souvenirs, presumably) do a validation check, the structure of their backend database(s)/server(s) doesn't make it so cut and dry... Unless we can speak to one of the developers, we can offer suggestions (and I feel like I can guarantee they have already thought of most anything we suggest, especially if it's as easy as a simple select), but we can't know precisely why it may not be implemented. And jumping on the vitriolic bandwagon is not respectful or productive.

As implied, constructive discussion about possible solutions might produce something devs hadn't considered, and might eventually get implemented in whatever manner works for the system they've built (which we do not know first hand).

A vitriolic bandwagon may not be particularly productive but when faced with a wall of deafening silence from Groundspeak, as is so frequently the norm these days, it's easy to see why people start to get frustrated. Throw in the way things do seem to be rushed into implementation only to then be seen to be badly thought through - some would say "half assed" - and Groundspeak paint a picture of themselves as somewhat bumbling and inept, and unwilling to learn so they can make better mistakes tomorrow.

My thoughts on the process:
1) On Find deletion (or log type/date change), trigger the reverse souvenir check

2) Since Posting a log AS a find must scan available/active souvenirs for which are relevant, this function already exists for the reverse; do it again

3) Theoretically, a souvenir algorithm could be complex, or it could just be a matter of a simple property (find date, cache state, etc). For the latter, running a check on Find logs for each relevant souvenir is functionally simple.

eg.

A] Post a find in Illinois, execute souvenir algorithms (1) the Illinois algorithm will say that souvenir is relevant; (2) if not rewarded, reward; else do nothing.

B] Delete a find in Illinois, execute souvenir algorithms (1) the Illinois algorithm will say that souvenir is relevant, (3) scan Find log history for one qualifying log; if exists, do nothing, else remove the souvenir

It means that each souvenir would need an explicit 'reverse' function (3) in addition to the reward function (2), but the validation check (1) would be the same either way.

If a souvenir validation query were a generic "select cache.id from logs, caches where logs.cacheid = cache.cacheid and logs.username='team tisri' and logs.logtype = 'Find'" then the "reverse" function per souvenir could be little more than an addition to the existing WHERE clause, such as "cache.state = 'Kansas'" or "logs.date = '16 Aug 2014'".

Additionally, if souvenirs are rewarded for a limited period of time, ONLY (2) could be disabled - but for perpetuity, (1) and (3) would need to remain active, and if there end up being hundreds or thousands of souvenirs over time, that would most certainly become a very significant burden on the system when someone deletes/changes a find log.

It wouldn't need to be a huge burden when a log is deleted because even if there are millions of souvenirs any individual log will only ever qualify for a small number. If a person found the sixth August 2014 souvenir in a new state on Geocaching Day they might earn four souvenirs (the last August souvenir, the bonus souvenir, the state souvenir, and the Geocaching Day souvenir). So if they then deleted their log the system would have to revalidate their entitlement to four souvenirs. In this case the bonus souvenir would be the most complex, because it would need its own totally separate query to see whether the user had the other six souvenirs.

There are many factors involved with the reversal of achievement rewarding, as the system seems to work currently. So implementing a simple SELECT statement is most likely nowhere near as simple as we think it should be.

It's possible, but it's hard to see how a well designed database wouldn't support such a thing and the typical wall of silence from Groundspeak does little other than invite endless speculation.

8.3k · August 19, 2014

It's possible, but it's hard to see how a well designed database wouldn't support such a thing and the typical wall of silence from Groundspeak does little other than invite endless speculation.

and that might well be the crux of the problem. They did kill any sort of useful search function because the computers were getting overheated.

Edited August 19, 2014 by jholly

15.3k · August 20, 2014

It's possible, but it's hard to see how a well designed database wouldn't support such a thing and the typical wall of silence from Groundspeak does little other than invite endless speculation.
and that might well be the crux of the problem. They did kill any sort of useful search function because the computers were getting overheated.

I don't have any direct experience with the internals of Groundspeak's site, but to me, it looks like a hobby site that has grown well beyond its original concept, and is showing the strain. They've probably got a lot of legacy code that just isn't up to the tasks they'd like it to do, and replacing it with a new, well-deigned code (without disrupting the ongoing use of the site) won't be quick and it won't be easy.

1.1k · August 20, 2014

It's possible, but it's hard to see how a well designed database wouldn't support such a thing and the typical wall of silence from Groundspeak does little other than invite endless speculation.

I think you have answered yourself

3.3k · August 20, 2014

It's possible, but it's hard to see how a well designed database wouldn't support such a thing and the typical wall of silence from Groundspeak does little other than invite endless speculation.
and that might well be the crux of the problem. They did kill any sort of useful search function because the computers were getting overheated.
I don't have any direct experience with the internals of Groundspeak's site, but to me, it looks like a hobby site that has grown well beyond its original concept, and is showing the strain. They've probably got a lot of legacy code that just isn't up to the tasks they'd like it to do, and replacing it with a new, well-deigned code (without disrupting the ongoing use of the site) won't be quick and it won't be easy.

Maybe you're right, but if that's the case I'd have thought their time would be better spent on revising the code and planning a major update, than fiddling with email formats and colour schemes. It seems they've got the resources to endlessly tinker at the edges while useful functionality gets lost in the bottomless pit known as "the to do list".

If they were working on a major overhaul of the database to update it, it would be nice to hear something from them even if only as an explanation for why so many suggestions apparently get promoted to the "to do" list but then never seem to actually get done.

9k · August 20, 2014

A vitriolic bandwagon may not be particularly productive but when faced with a wall of deafening silence from Groundspeak, as is so frequently the norm these days, it's easy to see why people start to get frustrated.

Sure, we can analyze community responses to hell and back. Still not productive. It's quite obvious that forum-goers are quite often bothered by updates. I'm 100% convinced they are aware of that. Every. Single. Time.

Throw in the way things do seem to be rushed into implementation only to then be seen to be badly thought through - some would say "half assed"

One might think that, but one has no evidence of that. It's, as they say, heresay. Since we don't know the optimal way to implement something in their system, we can't say for certain if they didn't make an effort, if they don't have the skill, or they actually did the best they could do. So, throwing "half-assed" without evidence is simply insulting to them.

and Groundspeak paint a picture of themselves as somewhat bumbling and inept, and unwilling to learn so they can make better mistakes tomorrow.

Rather, they are humble and realize they have made mistakes in the past, and are making every effort to do better in the future, despite being dragged through the mud in the forums every time they make an update, whether or not it's a good one.

If a souvenir validation query were a generic...

I said many souvenirs are relatively generic. That wasn't the point being made. The point was that currently, a souvenir's impact on the database is only as long as it's active, on rewarding. Providing a reversal function means providing an additional perpetual function for deletion, the quantity of which increases proportionately to the number of souvenirs, active users, and activity of those users. Then there's the potential for complex souvenirs; moreso than the few current souvenirs-for-souvenirs.

It wouldn't need to be a huge burden when a log is deleted because even if there are millions of souvenirs any individual log will only ever qualify for a small number.

Nope. If there are millions of souvenirs, the algorithm needs to be run for every single souvenir first to determine which are applicable. This is already done once when creating a Find log. The execution is now duplicated for deletion or change of any Find log (at the moment, Date, and a couple of basic cache properties).

OH, and what if a property of a cache that was 'Found' changes, but that property was applicable to a souvenir at the time of a user logging their Find? If that cache property changes (with zero implicit trigger of the Find log update action itself - no find logs actually changed), then all users' souvenirs who found that cache will need to be rechecked as well. Sure, this process could be optimized to a degree, but it's still exponentially more complex.

And now that that particular point has come to mind, I'm absolutely certain that Groundspeak is 100% correct in their stance that implementing an auto-check for souvenir reversal is a functional nightmare.

Practically speaking, a souvenir can be awarded with a single execution of a validation algorithm for each souvenir when logging a find - this would check the log properties, and the related cache properties, then award a souvenir or not even if a more complex algorithm needs to be executed (such as analyzing the user's stats for that souvenir). A universal automated reversal ability would therefore necessitate the potential to scan any database value connected in any way to the Find log, even if not directly related to the action on the find log itself. A validation check would need to be run for souvenirs related to the cache listing, then check that against all past 'Found' users' profiles, then do any additional algorithmic check to determine if a souvenir should be added or removed.

This may not be the case now, but implementing auto-reversal checks means allowing for the ability to do MUCH MORE complicated tasks than a simple SELECT triggered on log deletion or log type change.

And then it still needs to run for perpetuity. For all users. For all user logs. For all caches. For all souvenirs.

It's possible, but it's hard to see how a well designed database wouldn't support such a thing and the typical wall of silence from Groundspeak does little other than invite endless speculation.

Before this comment, I would have agreed on the "well designed database" point. But thinking it through while composing this reply, I'm certain that even a well-designed database would be an absolute nightmare to equip with a well designed automated-removal souvenir system.

However, delayed or queued souvenir validation would certainly be possible. I don't see any reason why souvenir qualification checks would need to be run automatically for any potentially relevant property change. Queue it! Then for instance if you delete 100 logs before your souvenirs are re-checked, it only checks your (and all available) souvenirs against your find history (and relevant caches) once. Clean sweep. And if it's done on an independent server, then it can be done any time, and its power/speed can be upgraded independently, without affecting any other website functionality. And it can be running 24/7 across the entire database of users.

tl;dr:

* Automatic souvenir re-validation on deletion/editing of logs? Absolutely not, for reasons bolded above.

* Queued re-validation of users' profile souvenirs (across all available)? Absolutely.

Edited August 20, 2014 by thebruce0

3.3k · August 20, 2014

Sure, we can analyze community responses to hell and back. Still not productive. It's quite obvious that forum-goers are quite often bothered by updates. I'm 100% convinced they are aware of that. Every. Single. Time.

One might think that, but one has no evidence of that. It's, as they say, heresay. Since we don't know the optimal way to implement something in their system, we can't say for certain if they didn't make an effort, if they don't have the skill, or they actually did the best they could do. So, throwing "half-assed" without evidence is simply insulting to them.

Rather, they are humble and realize they have made mistakes in the past, and are making every effort to do better in the future, despite being dragged through the mud in the forums every time they make an update, whether or not it's a good one.

Sure, we can go back and forth endlessly on whether Groundspeak are doing a good job or not, although it's not really relevant to the discussion about souvenirs.

I said many souvenirs are relatively generic. That wasn't the point being made. The point was that currently, a souvenir's impact on the database is only as long as it's active, on rewarding. Providing a reversal function means providing an additional perpetual function for deletion, the quantity of which increases proportionately to the number of souvenirs, active users, and activity of those users. Then there's the potential for complex souvenirs; moreso than the few current souvenirs-for-souvenirs.

I'm not sure just what you're trying to say here. Certainly an automated deletion process requiring a reverse lookup function to find logs that qualify for it, would require that function to be defined. But since the function already needs to be defined so the system can award the souvenirs, all that would be required would be an additional definition of what logs would qualify for the souvenir to be awarded. Once that was defined any souvenir could be revalidated at any time.

The souvenirs-for-souvenirs adds a layer of complexity, but that just leads into questions about the purpose of souvenirs. If they are intended to mark finds in certain locations they make some sense. Personally I think things like the August series is silly - it would make more sense to encourage people to look for different cache types at any time rather than encouraging less-common cache types to be created just to qualify for souvenirs. Awarding souvenirs for earning combinations of souvenirs seems like pointless duplication to me.

It wouldn't need to be a huge burden when a log is deleted because even if there are millions of souvenirs any individual log will only ever qualify for a small number.

Nope. If there are millions of souvenirs, the algorithm needs to be run for every single souvenir first to determine which are applicable. This is already done once when creating a Find log. The execution is now duplicated for deletion or change of any Find log (at the moment, Date, and a couple of basic cache properties).

OH, and what if a property of a cache that was 'Found' changes, but that property was applicable to a souvenir at the time of a user logging their Find? If that cache property changes (with zero implicit trigger of the Find log update action itself - no find logs actually changed), then all users' souvenirs who found that cache will need to be rechecked as well. Sure, this process could be optimized to a degree, but it's still exponentially more complex.

What properties would have to change to create such a problem?

At present souvenirs are awarded based on some combination of location/type/found date. The found date would be covered by a log amendment so doesn't apply here. The type can't be changed - the process for that appears to be to archive the cache and relist. So that just leaves the location. If a cache were particularly close to a state line or an international boundary it's conceivable that moving it 100 feet might shift it from one state to another. If that happens the reverse lookup function can verify who is eligible for which souvenirs based on the transition. So if a cache gets updated coordinates that moves it from New Hampshire to Vermont, a process to revalidate New Hampshire and Vermont souvenirs can be queued.

Practically speaking, a souvenir can be awarded with a single execution of a validation algorithm for each souvenir when logging a find - this would check the log properties, and the related cache properties, then award a souvenir or not even if a more complex algorithm needs to be executed (such as analyzing the user's stats for that souvenir). A universal automated reversal ability would therefore necessitate the potential to scan any database value connected in any way to the Find log, even if not directly related to the action on the find log itself. A validation check would need to be run for souvenirs related to the cache listing, then check that against all past 'Found' users' profiles, then do any additional algorithmic check to determine if a souvenir should be added or removed.

Sure, the generic query would select the fields that might be used in validating a souvenir and then add a WHERE clause as required for each souvenir. If you take my previosu generic query and remove the "where log.user = 'team tisri'" then you've got a list of users who qualify for the souvenir.

If souvenirs get particularly twisted in their complexity it would become increasingly difficult to automatically remove them. But I'd say that raises a question of whether complex qualification was suited to souvenirs at all. It's one thing to get a souvenir for finding a geocache in Kansas, it's another thing entirely to have a souvenir that can only be earned by finding six caches in Kansas on each of six consecutive Thursdays, plus another three puzzle caches on three different Fridays in Vermont, plus either a multicache in France or an event cache in Greece.

This may not be the case now, but implementing auto-reversal checks means allowing for the ability to do MUCH MORE complicated tasks than a simple SELECT triggered on log deletion or log type change.

And then it still needs to run for perpetuity. For all users. For all user logs. For all caches. For all souvenirs.

It's possible, but it's hard to see how a well designed database wouldn't support such a thing and the typical wall of silence from Groundspeak does little other than invite endless speculation.

Before this comment, I would have agreed on the "well designed database" point. But thinking it through while composing this reply, I'm certain that even a well-designed database would be an absolute nightmare to equip with a well designed automated-removal souvenir system.

I still think the only problem is if souvenirs become sufficiently complex to be silly. Something as simple as "find a cache in France" works. Something more complex like "find a cache within 10 miles of the Eiffel Tower" might make for a pretty profile picture but seems less useful. But if they are planning such souvenirs, I'd agree that anything other than validation at the time of award would become a huge load.

However, delayed or queued souvenir validation would certainly be possible. I don't see any reason why souvenir qualification checks would need to be run automatically for any potentially relevant property change. Queue it! Then for instance if you delete 100 logs before your souvenirs are re-checked, it only checks your (and all available) souvenirs against your find history (and relevant caches) once. Clean sweep. And if it's done on an independent server, then it can be done any time, and its power/speed can be upgraded independently, without affecting any other website functionality. And it can be running 24/7 across the entire database of users.

It may be that anyone who had a Find log deleted or changed would be tagged for revalidation and queued. Likewise if a cache had its coordinates changed such that it moved into a different named area it would generate a queued process to validate the "before" and "after" location-based souvenirs.

That leads into another interesting question, namely whether a cache had its coordinates updated to reflect the cache being moved or to reflect the previous coordinates being wrong. If the cache was moved across a state line then arguably the cache I found in New Hampshire should give me the NH souvenir even if the cache is now in Vermont. If the cache was always in Vermont but listed with coordinates incorrectly showing it as being in NH then I should get the Vermont souvenir.

It surely can't surprise anyone that some users will cheat to gain souvenirs. So it's hard to conclude anything other than that either Groundspeak isn't bothered about the agitation their creations appear to cause, or they didn't think it through very well. It seems unfortunate that something that is apparently intended to be a bit of fun is regarded as a waste of processor time by some and generates disproportionate levels of angst among others who earned their souvenirs and dislike the fact that others cheated to gain the same virtual gold stars.

I guess ultimately the endless side games around geocaching are becoming the tail wagging the dog.

9k · August 20, 2014

The souvenirs-for-souvenirs adds a layer of complexity, but that just leads into questions about the purpose of souvenirs.

Yes. But that's another discussion. Which I pointed out above. And it's unlikely that Groundspeak will kill off any and all souvenirs that are more than absolutely basic log or cache properties.

My look at this is based on what we have now, what the purpose of this discussion is, and how to ensure it's not a dead end for the future based on what we know.

* souvenirs are not just based on log dates. they are also based on cache location, cache type (cache properties), and collections of souvenirs (a user profile property)

* under the higher classifications, auto-removal checks would need to be triggered when any of the above changes, presuming souvenirs might be created for any combination of the above (whether we like that concept or not). So, changes to Log properties, Cache properties, and User profile properties. -- not just a log edit/deletion.

> what if a property of a cache that was 'Found' changes, but that property was applicable to a souvenir at the time of a user logging their Find? If that cache property changes (with zero implicit trigger of the Find log update action itself - no find logs actually changed), then all users' souvenirs who found that cache will need to be rechecked as well. Sure, this process could be optimized to a degree, but it's still exponentially more complex.

What properties would have to change to create such a problem?

At present souvenirs are awarded based on some combination of location/type/found date.

Who knows? We're (well I'm) not looking at merely the currently existing souvenirs. I'm looking at the system they've been building for souvenirs, objectively. And that without programming specific souvenir instances, build the container to allow for what currently exists, and make it easier to work with in the future. So, log properties, cache properties, and user profile properties are all data triggers for the reversal function.

If a cache were particularly close to a state line or an international boundary it's conceivable that moving it 100 feet might shift it from one state to another. If that happens the reverse lookup function can verify who is eligible for which souvenirs based on the transition.

Yes. And this is triggered on the cache listing update, not a find log update. This therefore must apply across the board. You could add a minor update that triggers the souvenir check only if a state line is crossed - but that would be specific to explicit souvenirs, programmed as an exception. What about a potential location souvenir that perhaps within some distance of defined landmarks or coordinates (like your "find a cache within 10 miles of the Eiffel Tower")? Doesn't exist now, but it's another instance of a location change that could trigger a souvenir check. Regardless, in the instance that there's any souvenir relevant to a cache location (or any log/cache/user property change), its reverse check needs to be explicitly programmed in to cache listing updates and log edit updates, or even a chained event (such as a souvenir update for souvenir collections). This is not so with a queued validation process which isn't triggered explicitly and immediately by specific events. Algorithms would be simpler, especially to manage.

The purpose is the difference. Are we attempting to implement a solution that 1) reduces people gaming the system and 2) provides a consistent and immediately verifiable list of user souvenirs (that every time you view a user's awarded items you can be guaranteed they are accurate)? Or are we simply looking for (1) and a way to 2) make sure that a user's souvenir list will in due time be an accurate representation of items?

The former (immediate validation triggered by a relevant action) is FAR too complex to implement. The latter is much more feasible, and open to upgrade, improvement, expansion, etc.

Sure, the generic query would select the fields that might be used in validating a souvenir and then add a WHERE clause as required for each souvenir. If you take my previosu generic query and remove the "where log.user = 'team tisri'" then you've got a list of users who qualify for the souvenir.

Don't forget it's not just the same query as when rewarding. Indirect triggers have to occur as well. Plus you're presuming that the select query is a simple addition - which as said earlier isn't a guarantee because we don't know their backend setup.

If souvenirs get particularly twisted in their complexity it would become increasingly difficult to automatically remove them.

Exactly. And it doesn't get easier, because it has to remain for the indefinite future. As more and more are added to the system.

But I'd say that raises a question of whether complex qualification was suited to souvenirs at all.
...

I still think the only problem is if souvenirs become sufficiently complex to be silly.

Different discussion - one that certainly should exist, and I agree. Are they souvenirs or accomplishments? What are they trying to 'reward' by providing souvenirs? They keep using that word, but I don't think it means what they think it means .

if they are planning such souvenirs, I'd agree that anything other than validation at the time of award would become a huge load.

Ok, so we're on the same page then

That leads into another interesting question, namely whether a cache had its coordinates updated to reflect the cache being moved or to reflect the previous coordinates being wrong. If the cache was moved across a state line then arguably the cache I found in New Hampshire should give me the NH souvenir even if the cache is now in Vermont. If the cache was always in Vermont but listed with coordinates incorrectly showing it as being in NH then I should get the Vermont souvenir.

It also means checking anyone who has the VT souvenir and now shouldn't, or anyone who doesn't have the NH souvenir and now should.

And none of this was triggered by a log deletion or type change.

It surely can't surprise anyone that some users will cheat to gain souvenirs. So it's hard to conclude anything other than that either Groundspeak isn't bothered about the agitation their creations appear to cause, or they didn't think it through very well. It seems unfortunate that something that is apparently intended to be a bit of fun is regarded as a waste of processor time by some and generates disproportionate levels of angst among others who earned their souvenirs and dislike the fact that others cheated to gain the same virtual gold stars.

I guess ultimately the endless side games around geocaching are becoming the tail wagging the dog.

... see, to me that sentiment is irrelevant. I'm just a programmer, not a judge

Yes, cheaters will find a way to cheat.

---

If the goal here is to reduce gaming-the-system and increase reliability of the user souvenir list, then at this point I cannot blame Groundspeak for not implementing an immediate auto-reversal check for souvenirs on log deletion or type change, and firmly believe that, given their implied purpose for the souvenir system, a triggered and queued souvenir verification process per user is the only feasible course of action.

Again:

* Currently, only a validation check is run (in however many steps) for active souvenirs when a user positively creates a Find log.

* The immediate-check solution requires running a validation check on all souvenirs, triggered by any explicit action related to data used within that list of souvenirs, and also cascades (beyond a single user profile) if that's required for a souvenir.

* The queued-check proposes to extract the entire above process into a self-contained module (both software and hardware) that can run whenever there is 'free' time, can be improved and expanded, and accomplishes all of the above goal (except that there's no guarantee that an immediate view of a user's souvenirs will reflect a 100% accurate list, for time; but heck, why not even throw up a little icon saying the list is queued for re-verification)

Another idea to help optimize the queue process:

Consider even, if a souvenir has flags for classification as log, cache, or user data related, then

-- Edit a cache, and it triggers the flag for all its past finders' profiles to revalidate all cache-specific souvenirs (already rewarded or not; so this covers location, or any other property). If a user's already queued for that, they're not re-queued.

-- If a user posts/edits a find log, the flag is set for that user's log-specific souvenirs to be revalidated (as above), if not already set.

-- If during one of these algorithms, a souvenir is added or removed to a user's profile (for example), that user's profile-specific souvenirs are queued to be revalidated, if not already set

Example1) if the 6 August type souvenirs are set as cache-specific, and the 7th is set as profile-specific: in practice, each find log posted/edited for that user would trigger to check them against all log- and cache-specific souvenirs which includes those 6; then if one is awarded (or removed), the profile-specific souvenirs would be triggered to check which includes the 7th, so only rewarded if the user has all previous 6 souvenirs (or otherwise removed); rewarding the 7th would trigger another profile-specific souvenir check, but nothing more would change at that point, likely; an endless loop would only occur if the souvenirs' properties were saved incorrectly that way.

Example2) If a cache is moved, all existing finders' flag for cache-specific souvenirs would be queued for revalidation (this would effectively skip any souvenirs that are rewarded, for example, by the date of the find log - irrelevant to cache listing update - as are souvenirs for rewarding souvenirs).

Example3) If a user finds a cache on all 31 days of August, a meta-souvenir would eventually be rewarded after the profile-specific souvenirs for the user are checked. User sees they've got the souvenir, then changes the date of the log on the 31st to September when they actually found it. The change queues their log-specific souvenir validation. Day 31 is then removed - this triggers the profile-specific souvenir check, which eventually removes the meta-souvenir for completing August (which per ex1 re-triggers the profile-specific check, but would effectively change nothing then).

tl;dr:

sorry, I write and analyze as I think through things programmatically :laughing: . Lots of words, simple concept, significant development project.

8.3k · August 20, 2014

It's possible, but it's hard to see how a well designed database wouldn't support such a thing and the typical wall of silence from Groundspeak does little other than invite endless speculation.
and that might well be the crux of the problem. They did kill any sort of useful search function because the computers were getting overheated.
I don't have any direct experience with the internals of Groundspeak's site, but to me, it looks like a hobby site that has grown well beyond its original concept, and is showing the strain. They've probably got a lot of legacy code that just isn't up to the tasks they'd like it to do, and replacing it with a new, well-deigned code (without disrupting the ongoing use of the site) won't be quick and it won't be easy.

I would certainly agree with this statement.

1.3k · August 20, 2014

It's possible, but it's hard to see how a well designed database wouldn't support such a thing and the typical wall of silence from Groundspeak does little other than invite endless speculation.
and that might well be the crux of the problem. They did kill any sort of useful search function because the computers were getting overheated.
I don't have any direct experience with the internals of Groundspeak's site, but to me, it looks like a hobby site that has grown well beyond its original concept, and is showing the strain. They've probably got a lot of legacy code that just isn't up to the tasks they'd like it to do, and replacing it with a new, well-deigned code (without disrupting the ongoing use of the site) won't be quick and it won't be easy.

I would certainly agree with this statement.

Me too.

I believe Jeremy's quote very nicely encapsulates GS attitude toward the problem.

I believe his quote accurately conveyed the status of the requested improvement.

As has been said many times, there are lots of improvements that Groundspeak would LIKE to make, but programming resource constraints and urgent priorities like server overloads prevent all of these improvements from happening on a reasonable timeline.

In my personal opinion, "attitudes" like yours contribute to Groundspeak's reluctance to post timeframes or commitments for implementing specific suggestions. Instead, the improvements show up as unexpected surprises from time to time.

Suggesting that GS doesn't post timeframes or commitments because someone might show "attitude" seems like giving them an easy way out.

We know NOTHING, but perhaps as a moderator you are privy to more information regarding these alleged resource constraints and server overload priorities. If that is the case, you make it sound like they can't pull their programming finger from the dike or the whole IT infrastructure house of cards will come tumbling down.

I believe I've been here long enough to have a firm set of expectations regarding GS's (lack of)communications -- an "unexpected surprise" (is there any other kind?) would be to see a list of prioritized list of development tasks with expected delivery timeframes and challenges affecting their delivery.

3.3k · August 21, 2014

Yes. But that's another discussion. Which I pointed out above. And it's unlikely that Groundspeak will kill off any and all souvenirs that are more than absolutely basic log or cache properties.

It is relevant in that an unknown future complexity with its associated issues adds weight to the suggestion that Groundspeak really didn't think things through very well. It's one thing to hit an unexpected problem but another thing entirely to just start something, roll it out in stages and suddenly realise it's going to cause problems because you didn't design it right from the start.

My look at this is based on what we have now, what the purpose of this discussion is, and how to ensure it's not a dead end for the future based on what we know.
* souvenirs are not just based on log dates. they are also based on cache location, cache type (cache properties), and collections of souvenirs (a user profile property)

* under the higher classifications, auto-removal checks would need to be triggered when any of the above changes, presuming souvenirs might be created for any combination of the above (whether we like that concept or not). So, changes to Log properties, Cache properties, and User profile properties. -- not just a log edit/deletion.

I touched on this in my reply. It may be triggered by a user-related change (log deletion or log edit) or a cache related change. Then if the user profile changes there may be a cascading effect where deletion of one souvenir requires deletion of another souvenir (e.g. the current batch of six August souvenirs).

Who knows? We're (well I'm) not looking at merely the currently existing souvenirs. I'm looking at the system they've been building for souvenirs, objectively. And that without programming specific souvenir instances, build the container to allow for what currently exists, and make it easier to work with in the future. So, log properties, cache properties, and user profile properties are all data triggers for the reversal function.

We've covered how changing the log properties should be able to fire a trigger to revalidate caches.

Changing cache properties would only be relevant if the coordinates updated, so it should be possible to work something comparable. Because a much larger range of users might be affected it may be that this would trigger a queued batch process.

User profile changes should also be manageable via a trigger. If my collection of souvenirs changes, revalidate my other souvenirs.

Yes. And this is triggered on the cache listing update, not a find log update. This therefore must apply across the board. You could add a minor update that triggers the souvenir check only if a state line is crossed - but that would be specific to explicit souvenirs, programmed as an exception. What about a potential location souvenir that perhaps within some distance of defined landmarks or coordinates (like your "find a cache within 10 miles of the Eiffel Tower")? Doesn't exist now, but it's another instance of a location change that could trigger a souvenir check. Regardless, in the instance that there's any souvenir relevant to a cache location (or any log/cache/user property change), its reverse check needs to be explicitly programmed in to cache listing updates and log edit updates, or even a chained event (such as a souvenir update for souvenir collections). This is not so with a queued validation process which isn't triggered explicitly and immediately by specific events. Algorithms would be simpler, especially to manage.

I thought I'd covered that in my post but maybe I wasn't clear. I'd expect the algorithms to be the same whether the process ran immediately or in a batch, and either way you'd want the process to be as efficient as possible to avoid wasting processor time. If processes are identical then there's no reason why any trigger shouldn't run a quick check to see how many users are affected and then either run or queue the process based on the expected load. So if a cache with thousands of finders changed it might be queued but if a new cache with only two finders changed in the same way it might just run there and then.

The purpose is the difference. Are we attempting to implement a solution that 1) reduces people gaming the system and 2) provides a consistent and immediately verifiable list of user souvenirs (that every time you view a user's awarded items you can be guaranteed they are accurate)? Or are we simply looking for (1) and a way to 2) make sure that a user's souvenir list will in due time be an accurate representation of items?

Don't forget it's not just the same query as when rewarding. Indirect triggers have to occur as well. Plus you're presuming that the select query is a simple addition - which as said earlier isn't a guarantee because we don't know their backend setup.

Exactly. And it doesn't get easier, because it has to remain for the indefinite future. As more and more are added to the system.

I'd say it should be accurate within a short time, where "a short time" means as short as is practical.

We don't know their backend setup but we can draw some conclusions based on an assumption of at least some competence in designing it. If we can't assume even basic competence then Groundspeak has much bigger problems than people cheating to get souvenirs.

The number of souvenirs shouldn't make a vast difference, as long as they don't end up with endless levels of souvenirs for souvenirs. If a change (to a log or to a cache) is made the system can look to see whether a new user finding the cache as it was would earn a souvenir, then whether a new user finding the cache as it now is would earn a souvenir, and then validate the "before" and "after" souvenirs. So if a cache is moved such that it steps from Pennsylvania into Ohio the system merely revalidates the PA and OH souvenirs. There's no need to validate any others. When those two souvenirs are revalidated other triggers relating to user souvenir collections can mop up any related changes (e.g. a souvenir for finding caches in all three of PA/DE/NJ)

Different discussion - one that certainly should exist, and I agree. Are they souvenirs or accomplishments? What are they trying to 'reward' by providing souvenirs? They keep using that word, but I don't think it means what they think it means .

So once again a little feedback from Groundspeak might be useful.

Ok, so we're on the same page then

On that aspect, yes

It looks like souvenirs are lost somewhere between being a bit of fun to reward caching other than within a short distance of home, and an achievement-based measure. It may be that Groundspeak are trying to use souvenirs to demonstrate qualifications for the assorted grid-filling challenge caches, but if that's the case it seems the icons people seek would be lost among the fluff.

It also means checking anyone who has the VT souvenir and now shouldn't, or anyone who doesn't have the NH souvenir and now should.

And none of this was triggered by a log deletion or type change.

I wasn't thinking of what triggered the event - the question in this case is whether souvenirs should be updated at all. If the cache was in VT but was moved to a better hiding location then the people who found it before the move should retain the VT souvenir and not get the NH souvenir. If it was moved to reflect more accurate coordinates and was always in NH then earlier finders should have their VT souvenir replaced for an NH souvenir.

If the goal here is to reduce gaming-the-system and increase reliability of the user souvenir list, then at this point I cannot blame Groundspeak for not implementing an immediate auto-reversal check for souvenirs on log deletion or type change, and firmly believe that, given their implied purpose for the souvenir system, a triggered and queued souvenir verification process per user is the only feasible course of action.

If the goal is to reduce gaming it's a shame that there appears to be no system that removes caches that were not really earned at all.

Again:
* Currently, only a validation check is run (in however many steps) for active souvenirs when a user positively creates a Find log.

* The immediate-check solution requires running a validation check on all souvenirs, triggered by any explicit action related to data used within that list of souvenirs, and also cascades (beyond a single user profile) if that's required for a souvenir.

* The queued-check proposes to extract the entire above process into a self-contained module (both software and hardware) that can run whenever there is 'free' time, can be improved and expanded, and accomplishes all of the above goal (except that there's no guarantee that an immediate view of a user's souvenirs will reflect a 100% accurate list, for time; but heck, why not even throw up a little icon saying the list is queued for re-verification)

Your second point here is the one I disagree with. If a find log is changed or deleted the only souvenirs that need to be revalidated are those awarded by the original find log. If a cache is changed the only souvenirs that need to be revalidated are those based on the cache as it was and the cache as it is. Souvenirs for getting souvenirs can be revalidated by a trigger on the souvenirs table.

If Groundspeak plans to introduce more complex processes to award souvenirs (like "within 10 miles of the Eiffel Tower") it would probably save processing time if each cache had a list of souvenirs it would award when found. Then if the cache were moved that list could be recalculated based on its new location, and it would make revalidating souvenirs much less processor-intensive than having to check every single find for its distance from the Eiffel Tower.

That in turn would lead to a similar question to the issue of a cache moving across a border, and allow for souvenirs to be considered permanent even if something other than the user log changed. So in theory if you found a cache in Paris that was half a mile from the Eiffel Tower and subsequently the Eiffel Tower was moved to Nice, you'd keep the souvenir because at the time you found the cache it was within 10 miles of the Tower.

I don't have an issue with your queueing process, I think our disagreement is over how much of it could be done in realtime and how much would need to be queued.

It's interesting to read, I agree it's a simple concept, and don't think it's as significant as you do.

3.3k · August 21, 2014

(I had to bunch your comments together because the system really helpfully said "Too many quoted sections" without telling me how many I had and how many I was allowed. Now that would be an easy thing to fix...

20.7k · August 21, 2014

You guys are going around and around and around about something that doesn't much matter. If you get a souvi that you don't want, then you can get rid of it. Problem solved.

9k · August 21, 2014

(without going through and editing my whole comment again, I've added my latest idea for the queued revalidation process at the bottom; might not line up with details in my responses below)

Changing cache properties would only be relevant if the coordinates updated,

Not if there's a souvenir based on any other property. And rather than hard coding triggers for specific properties based on an ever-evolving list of souvenirs, queue the revalidation of all cache-data souvenirs for existing finders when a cache is edited.

I'd expect the algorithms to be the same whether the process ran immediately or in a batch, and either way you'd want the process to be as efficient as possible to avoid wasting processor time. If processes are identical then there's no reason why any trigger shouldn't run a quick check to see how many users are affected and then either run or queue the process based on the expected load. So if a cache with thousands of finders changed it might be queued but if a new cache with only two finders changed in the same way it might just run there and then.

Sure, prioritizing the queue could be a factor in the system. I wouldn't build in the 'run now' or 'queue for later' thing (imagine forum angst when someone sees that other users' souvenirs are updated before theirs so they're left waiting 'unfairly' =P) ok that's tongue-in-cheek. Anyway, point, prioritization of queued tasks is an independent function that can be implemented into the queuing system, rather than hard-coding two explicit options (run-now or add to queue).

The number of souvenirs shouldn't make a vast difference,

"shouldn't" doesn't cut it for me. We don't know what souvenirs could be added in the future, and we don't know how complex the system is to run checks on existing souvenirs, other than the awarding; we also don't know how high they prioritized server tasks and where they'd put general re-validation in that list. So, regardless of whether it 'should' make a difference, I'd rather be objective and accommodate for worst-case, or near-worst-case at least. That means, by their admission that such a system would be a burden, I'd take that into account. Exponential potential increase in server load based on souvenir count, user count, and global logging activities.

So if a cache is moved such that it steps from Pennsylvania into Ohio the system merely revalidates the PA and OH souvenirs. There's no need to validate any others.

No see that's hard-coding in algorithms into the system logic for specific souvenirs, and means it's no longer self-contained and easily maintained. You could take it a step higher and say if the Location property is changed, then run Location-specific souvenirs, but again it depends on the existence of location-specific souvenirs; and cache type specific souvenirs; and cache size specific souvenirs; etc. My suggestion is at the next to highest level - cache-data specific souvenirs. Not a full algorithmic check to see that every cache-data souvenir should be rewarded, but only create the list of souvenirs that should be checked (reducing say 100's to 10's). Just as the meta-souvenir (user-profile data souvenir) list would reduced 100's to (at the moment) <10's, plus exclude checking those souvenirs for cache-data specific souvenir checks. etc.

Classify souvenirs on a large-scale grouping factor with minimal processing, so that the more intensive processing (explicit validation of souvenirs) occurs on a much smaller scale. And avoid hard-coding souvenir-specific checks and algorithms into the website functions itself.

I see no need to build full validation triggers on specific cache property edits, find log creations, find log edits, profile updates, plus allowing for triggers on any other future souvenir 'ideas' data updates.

Queue users' souvenir validations based on souvenir relevancy to an action - cache update, log update, or profile update. Minimal alteration to the main web system, and addition of an independent optimized process to algorithmically check, as requested, souvenir lists.

It looks like souvenirs are lost somewhere between being a bit of fun to reward caching other than within a short distance of home, and an achievement-based measure. It may be that Groundspeak are trying to use souvenirs to demonstrate qualifications for the assorted grid-filling challenge caches, but if that's the case it seems the icons people seek would be lost among the fluff.

Seems they have a 'terminology' issue between the intro app and the paid app as well. But my theory is they're testing the flexibility of the souvenir system as a system to potentially replace/augment the Challenge Cache concept.

Imagine being able to create your own <strike>souvenirs</strike> badges for completing a challenge cache you've set up? A CO could validate a user's Found It log and reward the badge. Or, potentially, a system to auto-check user stats for a custom algorithm based on your challenge, and reward the badge. (just thinking of this I can already imagine huge issues, but I'm just thinking out loud =P).

Point, it feels like 'souvenirs' are becoming a badge system for achievements; moving towards potential rewards in the region of the Challenge Cache idea.

I wasn't thinking of what triggered the event - the question in this case is whether souvenirs should be updated at all. If the cache was in VT but was moved to a better hiding location then the people who found it before the move should retain the VT souvenir and not get the NH souvenir. If it was moved to reflect more accurate coordinates and was always in NH then earlier finders should have their VT souvenir replaced for an NH souvenir.

My idea somewhat addresses that.

If the souvenir is for finding a cache in VT, then it could be flagged log-specific but check cache data. On finding, the algorithm would reward it. If the cache were moved to a new state, the souvenir wouldn't be flagged for re-validation. If the user edited the log, it could be told not to revalidate since the data is not log-specific, only the trigger (even though the algorithm itself checks cache data).

If the souvenir is for find a cache in VT (minor distinction), then it could be flagged cache-specific. On finding, the algorithm would reward it. If the cache were moved to a new state, the souvenir would be flagged for re-validation.

> The immediate-check solution requires running a validation check on all souvenirs, triggered by any explicit action related to data used within that list of souvenirs, and also cascades (beyond a single user profile) if that's required for a souvenir.

...the one I disagree with....

I missed correcting that point - "a validation check on all souvenirs" should be changed to (based on other points I made in the comment) "all relevant souvenirs" (after the classification).

If Groundspeak plans to introduce more complex processes to award souvenirs (like "within 10 miles of the Eiffel Tower") it would probably save processing time if each cache had a list of souvenirs it would award when found. Then if the cache were moved that list could be recalculated based on its new location, and it would make revalidating souvenirs much less processor-intensive than having to check every single find for its distance from the Eiffel Tower.

That in turn would lead to a similar question to the issue of a cache moving across a border, and allow for souvenirs to be considered permanent even if something other than the user log changed. So in theory if you found a cache in Paris that was half a mile from the Eiffel Tower and subsequently the Eiffel Tower was moved to Nice, you'd keep the souvenir because at the time you found the cache it was within 10 miles of the Tower.

Indeed, that's a good optimization option - defer the relevant souvenir filter scan so that a cache edit (1) revalidates the set list of relevant cache-data specific souvenirs, then updates that list based on the new cache data. The only issue would be new souvenirs created since last save. In that case, either a) GS creation of a new cache-specific souvenir needs to check itself against the entire database of caches and add to relevant caches, or on editing a cache, after finishing (1) it also checks against new souvenirs that were created since the last list update.

ugh, on second thought that's getting more complicated too. Merely by the size of the cache database. Keeping a dynamic list of relevant souvenirs to check per cache isn't clean-cut, as it needs to be synchronized with the list of existing and relevant souvenirs.

I don't have an issue with your queueing process, I think our disagreement is over how much of it could be done in realtime and how much would need to be queued.

My only issue with real-time is that it requires hard-coding functions and triggers explicitly based on an ever-evolving list of souvenirs with no definable limit to qualifications. In an independent queued environment, it's self-contained and easily maintained; if there's a problem it can be disabled or removed with no loss. The only drawback is that it's not real-time

----

Thinking through again, with a few changes...

Souvenirs:

* Trigger options: log/cache/profile update (independent flags; all could be set)

* Persistent? (rewarded at the trigger, or based on current data?)

* Validation Algorithm (function, returns whether souvenir should be rewarded or not for a user)

Cache:

* On create/edit, trigger function: retrieve finder list, queue validation of users' triggered-by-cache-update souvenirs, if not already queued

Logging:

* On create/edit/delete, trigger function: queue validation of user's triggered-by-log-update and triggered-by-cache-update souvenirs, if not already queued

Profile:

* On any profile property update (not stats), trigger function: queue users' triggered-by-profile-update souvenirs, if not already queued

On execution from queue:

* Retrieve list of relevant souvenirs to revalidate (by supplied trigger - log/cache/profile update)

* Reduce to souvenirs that are Persistent, or not yet rewarded for the user (souvenirs both persistent and rewarded shouldn't be removed)

* Execute the validation algorithm for each souvenir (don't change the user's custom-set visibility flag if the souvenir is already rewarded)

* If any souvenir was rewarded or removed, queue the user's triggered-by-profile-update souvenirs

Optional:

* profile triggered souvenirs could be classified further to souvenir-triggered souvenirs, since that trigger would only occur after validating (and altering) a user's souvenir list.

Note:

* log-triggered souvenirs would be for souvenirs exclusively based on find log properties (eg Date). cache-triggered souvenirs would also need to be triggered with log post/edit/delete.

Example: Cache found in VT would be flagged as cache-specific, but triggers cache-souvenirs when Found by the user. If cache is moved to NH, cache-triggered souvenirs are queued for all current finders; if find log is edited to not found, cache-souvenirs are queued for that user.

Example: Cache found within 10km of Eiffel Tower flagged as cache-specific (by Location). Log posted as DNF mistakenly; edited to Found, cache-souvenir check is queued for that user. If moved beyond 10km, cache-triggered souvenir check is queued for all finders, unless marked as Persistent (once-off reward).

Example: Cache found 1.2km from Eiffel Tower flagged as cache-specific (by Location). User logs as found, cache-souvenirs triggered for check; but souvenir not rewarded (interestingly, this souvenir check does even occur in the current system for finds worldwide; but actions are filtered out likely first based on Country; that is, if I post a Find on a cache, the current real-time action checks all souvenirs to see if any are relevant; including this Eiffel Tower one, were it to exist). If cache moved within 1km of Eiffel Tower, cache-souvenir check is queued for all current finders.

* Remember: a check for a user based on a trigger is only queued once - multiple enqueue calls doesn't add stress to the system, or lengthen the time before souvenir validation. Calling a full cache-specific souvenir revalidation scan on a single cache edit isn't excessive - queuing the request actually trades the current real-time check for fewer souvenir algorithm calls.

Seriously, I'm kind of wanting to build this system now :grin:

9k · August 21, 2014

You guys are going around and around and around about something that doesn't much matter. If you get a souvi that you don't want, then you can get rid of it. Problem solved.

pssh... programmers don't care. It's a problem to solve. Even if it's never used, it's a thinking exercise, hones the logic centers of the brain ;D and it's fun!

Edited August 21, 2014 by thebruce0

Souvenirs don't get removed...

Recommended Posts

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment