spazierenmitziel

Did you find any solution? I have the same issue on a native Win 11 Laptop since a several weeks...

And this gave me headaches as well... The simple but less accurate solution would be to chenge the log-date of the "normal" caches (not lab caches) you found before the lab to the day before, log the lab and the subsequent caches. This solution mixes up log dates (and this is why I don't do it) and it does not work if you find more than one lab on a day. Today I found a solution which fixes the order for gsak + FindStatGen3 - and this is what I need . So I hope it might be helpful to others as well. Unfortunately, it is a bit cumbersome so I would do this only if the milestones are relevant: Install the Macro "CreateLog" from the gsak macro index (https://gsak.net/board/index.php?showtopic=6527&st=0&#entry246496) (just for the first time) You will need a sqlite database editor. I'm using the sqlite manager that even comes with gsak Log your "normal" caches so that they have a "found" log in your gsak database. Create a dummy log entry for your labs by selecting the lab cache and running the CreateLog Macro. Unfortunately, FindStatGen does not use the time you entered to sort the logs but the LogId. The macro creates a dummy ID which is still out of order. Now we could think of an enhanced macro which creates the best fitting ID automatically based on the time stamp, but I proceeded manually: Start the sqlite manager and open your "Founds" database. You will need to locate the database on your computer. On mine, it is on C:\users\[myusername]\AppData\roaming\gsak\data\FoundAndLost\sqlite.db3 (FoundAndLost is my database name) Check the caches you found on this day using the following SQL statement (adjust the date!): SELECT * FROM Logs WHERE lDate = "2022-11-29" You should now get a list showing all your found logs including their IDs. Sort the list based on the lLogId column by clickin on its header. You should now see your lab-caches with IDs starting with 9000... and the other ones starting with higher numbers. Now identify between which caches the lab shall be placed. Then choose a new ID which is between the IDs of the respective caches. In my example, I now want the lab with ID 900000001 to be placed between the cache with ID 1139501716 and the one with ID 1139501782. I was lazy and chose 1139501780 as the new ID for the lab. Now you update the database with the new ID: UPDATE Logs SET lLogId = 1139501780 WHERE lLogId = 900000001; Of course you have to adapt the numbers according to your situation. Check the result by running the SQL statement from step 6 again. Repeat step 7 & 8 for all LAB caches for that day. Close the sqlite manager (otherwise gsak will not be able to open the database) Run FindStatGen3 in gsak and check your milestones!

Based on the attribute search we can add: 16: "Cacti nearby", #retired, text taken from gpx file of https://www.geocaching.com/geocache/GC684 and there are a few new ones which could be added: 69: "Bonus cache", 70: "Power trail", 71: "Challenge Cache", 72: "Geocaching.com solution checker", Nr. 68 seems to be missing, too - the attribute search did not give any results. Just in case anyone wants to write some code using attributes, this one could save you some editing: attributes = {1: "Dogs", 2: "Access or parking fee", 3: "Climbing gear", 4: "Boat", 5: "Scuba gear", 6: "Recommended for kids", 7: "Takes less than an hour", 8: "Scenic view", 9: "Significant hike", 10: "Difficult climbing", 11: "May require wading", 12: "May require swimming", 13: "Available at all times", 14: "Recommended at night", 15: "Available during winter", 16: "Cacti nearby", #retired, https://www.geocaching.com/geocache/GC684 17: "Poison plants", 18: "Dangerous Animals", 19: "Ticks", 20: "Abandoned mines", 21: "Cliff / falling rocks", 22: "Hunting", 23: "Dangerous area", 24: "Wheelchair accessible", 25: "Parking available", 26: "Public transportation", 27: "Drinking water nearby", 28: "Public restrooms nearby", 29: "Telephone nearby", 30: "Picnic tables nearby", 31: "Camping available", 32: "Bicycles", 33: "Motorcycles", 34: "Quads", 35: "Off-road vehicles", 36: "Snowmobiles", 37: "Horses", 38: "Campfires", 39: "Thorns", 40: "Stealth required", 41: "Stroller accessible", 42: "Needs maintenance", 43: "Watch for livestock", 44: "Flashlight required", 46: "Truck Driver/RV", 47: "Field Puzzle", 48: "UV Light Required", 49: "Snowshoes", 50: "Cross Country Skis", 51: "Special Tool Required", 52: "Night Cache", 53: "Park and Grab", 54: "Abandoned Structure", 55: "Short hike (less than 1km)", 56: "Medium hike (1km-10km)", 57: "Long Hike (+10km)", 58: "Fuel Nearby", 59: "Food Nearby", 60: "Wireless Beacon", 61: "Partnership cache", 62: "Seasonal Access", 63: "Tourist Friendly", 64: "Tree Climbing", 65: "Front Yard (Private Residence)", 66: "Teamwork Required", 67: "GeoTour", 69: "Bonus cache", 70: "Power trail", 71: "Challenge Cache", 72: "Geocaching.com solution checker", }

Well, I'd like to advocate against counting every lab wayoint as "Found", too. Either the game is integrated in the Geocaching ecosystem or not. If it is not integrated, I do not care about the number of points given for ALC stages, distance, speed or whatever will appear in the future - it would be the ALC-world which is consistent in itself. But if ALCs are conidered beeing part of the geocaching ecosystem, the ruels for counting should be the same. A "Cache" is a collection of tasks (often just one task) which needs to be performed to log it as "found" (e.g. solve a puzzle + find the box in the case of a mystery, just "find the box" for a traditional or "visit several stages" in case ol WiGs, multis, etc.). An ALC is such a collection as well. There is no substantial difference. Threfore, an is closest to a multi-stage-mystery with automatic answer checking. And this woul result in one (1) found log. I appreciate that the ALC app marks completed answers as completed, this is a nice feature I would like to have sometimes for multi caches as well, but those should not count as founds. I really do not care if someone makes more finds-per-day than I do, but I like consistent behaviour of systems. And there are several challenges around for which the counting of ALCs can make a real difference! Those are often broken by the current behaviour.

Hi all, when I was visiting Chiapas, I figured that there are nearly no Geocaches around. therefore I placed one at the Cascada El Aguacero at N 16° 45.510 W 093° 31.650. Now the problem is that the reviewers will not publish it without a local cacher helping in the maintenance of the cache if necessary. Is anyone of you willing to jump in and claim that he/she would be willing to perform maintenance if need be? I hope to be in the area every two years, but I can not guarantee for that. Any help is greatly appreciated. Oliver / Spazierenmitziel (Germany)

Hi Community, what would you think about having the attributes stated in the GPX-file? I'm using GSAK a lot and I'd love it if it could show me e.g. caches which are not available at night. This feature request does not come out of the blue: On Easter I've been standing in front of four closed gates and that could have been avoided if GSAK would have had a chance to tell me about it... What do you think about it? Cheers Oliver

Hi all, I found lots of threads regarding language issues in the forum but found no appropriate solution yet. To summarize, there are two sorts of problems: 1) having geocaching.com in "your" language 2) having the cache descriptions in a language you'll understand. Issue 1) is already being addressed by Groundspeak (thanks for that!) but issue 2) seems to be unresolved. I don't think that bablefish or anything else is a solution since many descriptions include some word play which is not translated correctly. I'd rather suggest adding an additional attribute indicating the languages in which the cache descriptions are given. It's the owners responsibility to modify the text and attributes accordingly. The advantage of this method (in contrast to having multiple texts for different languages) is that it's technical realization should be easy. The disadvantage is that descriptions have to be doubled (or tripled, or...) for each language. Greetings from Germany Oliver

I would appreciate a (default "on") filter "Hide unavailable Caches" for google maps, pocket queries, ...

s*-word, f*-word... That should be explained somewhere! I thought it's just a different (and more convenient) media!

Hi all, I just got my Pre-Loaded microSD-Card with CityNav N. America NT. It works fine on the device but I'd like to use the maps in my Mapsource Software as well. Is there any way to have mapsource recognizing the maps? Thanks