thomfre

In 75% of the cases, it's developers (or managers) embracing the benefits of online ads and tracking... There's a long way from utilizing online capabilities, to requiring being online... Partly offline is much better than no offline support at all. Imagine how hard geocaching would be if the app didn't support offline lists.

It's so much simpler than this to get the data! So I think the best way to deal with the cheaters, is to block them. And let us honest people play with better tools.

With the current implementation, there's absolutely nothing that require the app to be online, other than creating the illusion that it prevent people from cheating. All the data is transferred to the app, and the validation is already done in the app - which could be done offline - without affecting the features. This is why it's so easy to cheat now - why not use that to let people find them offline? Find other ways to detect cheaters, and simply block their access to the lab cache API. Problem solved.

The status page rarely ever show the actual status during failures like the one we're seeing now. Neongeo appears to be abandoned, and will stopp working on June 1st. It use the old API, which might be the explanation to why it works now.

API is working on and off. Very slow, and lots of errors. Just like it's been every day for the last two weeks...

I already explained why. I log my finds in chronological order, on my computer - not on my phone. I can have 10-1000 finds I have to log before I submit the Found it-log on the cache i just found first. The way I see it, if you want to rush out and FTF a cache, you read the logs first. Then you put it on watch list, and you'll get an email no matter what type of log someone write. FTF is not something the main site caters for (I wonder why?), so if a 3rd-party service provide some kind of indication specifically for FTF-hunters, that service should look at how large parts of the community handle this - and look at notes as well. People should generally start reading cache descriptions and logs again... And if you can't accept the way most people I've met handle the FTF game, that is really not my problem. Maybe you should look at the way you act yourself now. Edit: there's no requirement to log the find as soon as I've found a cache (or before, as some people do). I can log whenever I want. I only log the write note as a courtesy to other FTF hunters. I could have logged nothing, and waited until I got home. Would you prefer that instead? Edit2: From the help center:

I do write a found log. But I like to log my finds in chronological order, and I like to log using my computer. As a courtesy to others, I leave a note when I'm FTF. This way, I get to log the way I prefer, and people can see the note if they want to. This is how everyone's doing it here. If that's not good enough for you, that's really not my problem...

I'm not going to explain how they do it, but it's really easy, and it doesn't involve hacking the GS servers. I have reported the hole to Groundspeak.

Given this text on the profile, I'm going to say that the intention here is pretty obvious:

If we're looking at it that way, is there even a thing called FTF? There are no official rules. I can write FTF in all my logs if I want to. First to Find (this hour), Fifth to Find, Fourth to Find (today) etc.

Labrador_GC was not alone, lots of other fake logs. Why would people even want fake finds on their profiles?

The way I view it, this is clearly an issue with the app itself (since the app is now the only way to log lab caches). Lots of fake logs on new adventure labs, which should be handled by both fixing the app and banning the users that abuse the hole.

That is a problem with the 3rd party service then. There's so many services, and many of them work in different ways. I don't think we should expect everyone to follow requirements they don't even know exists. Writing FTF-notes have been common in Norway as long as I've been geocaching, and that's what we here consider courteous enough.

Yes, that was what I meant.

Last visited yesterday, so it could have been locked today, yes. But how could he/she find all the adventures in the world..?

How is it possible for this account to solve all new adventure labs? https://www.geocaching.com/p/default.aspx?u=labrador_gc Even with his/her account locked!?

Of course I agree! I always hoped my script was temporary, and I'm glad it turned out to be so. I use GSAK a lot myself (but I don't use drafts), so I welcome all improvements.

Believe it or not, it doesn't even make sense to do it in all apps... I believe in giving credit where credit is due, and it was geocaching.com that made this possible in the latest API. The feature request was: ...and that was done by Groundspeak. Sorry that I stepped on your toes, the macro is still awesome.

It is possible thanks to the new geocaching.com API All partner apps can implement this if they want to.

I don't mind I appreciate the 16k limit, but the per app limit is much more important. So if this change leads to the limit being 6k per app again, I'm perfectly fine with that!

Debugging would have been a lot more fun if logs looked like this

And since both date and timezone is known on the cache, it should be real easy to calculate the correct DST.

Leaking app? There is a lot of nice API apps out there, and they have been working perfectly fine until now. What most of you seem to forget is that people have gotten used to apps not affecting each other. I can't speak for the world, but it's common here in Norway to use the available quota to fetch caches in GSAK. People have done that for a long time, and how should they know that they have to stop now? If they don't, they can't use any other app. The issue isn't a single partner app (not sure where you get the data harvesting apps from, do they even exist anymore?) - it's users being used to doing something that will soon break their workflow. It doesn't matter to them that some random dude on the forum think they shouldn't need to download that many caches. And why should it? The increased limit is nice. But separate limits was a lot nicer.

All of that is true, but some apps will fetch data in the background, without the exact API call being initiated by the user (like indicated in the post I quoted). I went back and had a look, and I see plenty of evidence for the 6000 per app limit being intended. The new quota might be a huge increase for some, like the people using only one app. But for people using 3+ apps, it's not an increase at all.

I fully support that idea! But I don't think any API app use more than they have to (why should they?), the issue here is that you now have a shared pool where you used to have separate pools. This will affect users that use multiple API apps.