Jump to content

markens

Members
  • Posts

    28
  • Joined

  • Last visited

  • Days Won

    7

Everything posted by markens

  1. My browsers actively prevent connecting to the site when this happens, with no way to override. It's a security error. I'll note more detail next time it happens.
  2. Hi Nic, It seems that access to the forum is increasingly interrupted with "unable to securely connect" errors lately. This generally indicates a server certificate error of some sort. It lasts a day or two, then all is okay again for a while. When it happens, I see it in different browsers. Any idea what's up?
  3. Open the App Store. Then, in order: tap the profile icon in upper right corner; tap "purchased" near the top; tap "My Purchases"; type "cachly" in the Search box and tap Search button. There should be an entry for cachly with a cloud download icon. Tap that and you should be in business.
  4. With regard to the PQ issue: could it be that the PQ rework project underway at groundspeak has affected this functionality? They seem to have broken a number of PQ features. See this thread: https://forums.geocaching.com/GC/index.php?/topic/382502-release-notes-website-pocket-query-api-october-18-2022/
  5. I like and use the cachly feature which lets me set the status of individual adventure lab stages to FOUND, which then shows those stages with a smiley on the map. This works great on labs imported via GPX. But I have not found a way to do this on lab stages loaded in the live view via API, which are then added to offline list(s). For those loaded via API, the current abilities are good (see stage info, navigate to the stage, and load the stage in the Adventure Lab app). It would be very useful to add a fourth option to set the stage to FOUND in cachly. Thanks! BTW, I love the ability to search an area for all ad lab stages in that area. This is so incredibly useful, and a feature sorely missing in the geocaching HQ apps. Well done, Nic.
  6. I'll have an opportunity Thursday, and will try to capture a video.
  7. I've noticed this as well, very bizarre behavior. No idea how to replicate it since it happens when re-opening the app after being on the move. I'll try to notice whether it matters if cachly is running in foreground or not, and more specific details about when this behavior occurs.
  8. Wouldn't it be straightforward to apply such a filter locally after the results are returned by the API (which would give the user the same effect)?
  9. I had the same issue. Just updated to cachly 6.1 which indeed fixed the problem. Thanks!
  10. I second this request! This is my work flow as well, and I routinely empty a list manually before importing gpx from gsak. The requested function will be very useful.
  11. I thought I tried this via the offline list ... button, and it only removed highlights from those caches currently in the list. Does this really remove highlights in other lists as well? Seems it should just be the current list. But the other option you mention (More tab) appears to be what I'm looking for, removing highlights across all devices and lists. It currently shows 643 highlights for me, which is exactly what I want to clear! I will try this when I'm done with current set of active highlights. A bit of background: I import caches into offline lists from gsak. I liberally use the gsak "user flag" method for setting highlight upon importing into cachly. And I often empty an offline list before importing more caches into it, leaving behind the highlight attribute. When I load a new set of caches (with different user flag/highlight combinations), the previous highlight attributes reappear on caches I don't want highlighted anymore. Being able to do a global clear of highlights solves my immediate issue. But a slight modification of the import process into cachly would make this much easier. My suggestion: When importing a gpx file into an offline list, first check to see if the gsak user flag is set for *any* cache in the set. If so, then that implies that the lack of a user flag is also important. Therefore, set highlight for caches with the user flag set, and *remove* highlight from caches with the user flag not set. (If the user flag is not set for any cache in the gpx file, then simply ignore stored highlight attribute as now happens.) To me, this is expected behavior when using the gsak user flag in this manner. If you don't want to make this default behavior, perhaps it could be made an option along with recognizing the user flag in the first place. Thanks!
  12. Questions about behavior of highlight attribute for caches in offline database. From what I see, the highlight attribute persists in the database even after the cache has been deleted from all offline lists. And so that same attribute is applied when an affected cache is seen again in an online search, or added to an offline list. While not expected, this behavior is useful much of the time. If a highlight needs to be adjusted or removed, it can be done as usual when a cache reappears on a list. But it would be useful to be able to remove the highlight attribute from all caches in the offline database, to prevent them reappearing again on new searches. Is it possible to do this? Other than deleting the app and reinstalling? Thanks.
  13. Also rebooted my phone with no change in behavior.
  14. Updated to 5.1.2(3) and tried several more tests: (1) Added a 7th pending log and exported as .txt -- same result (all seven logs show "(null)" as the log text. (2) Selected "Send Log Now" for the added entry, and sent it to gc. It was posted correctly (with the intended log text). (3) Deleted all pending logs (4) Wrote and saved a new log entry. Exported via .txt with same "(null)" log text as before. Submitted to gc using "Submit All Logs" button; it was posted correctly. So definitely an issue with exporting via .txt, at least in my instance. I've used this extensively as part of my normal work flow with no problem until now. Thanks.
  15. Yes, they all have log text in the "Message" field when I look at them in the Pending Logs section.
  16. The "message" field is missing in exported logs. Version 5.1.1(1) on ios 12.2. I have six pending logs, each with a log message saved. When exporting for use in GSAK I use the "Export .txt File" menu option under Pending Logs. This used to work fine! In 5.1.1, the message field is written as "(null)" instead of the saved log message. I usually export to Dropbox, but I also tried sending via email with the same result. Here's the .txt file written via either method: GC87EKZ,2019-05-23T17:50Z,Found it,"(null)" GC887J1,2019-05-23T18:06Z,Found it,"(null)" GC87ZQ0,2019-05-23T18:19Z,Found it,"(null)" GC87F3J,2019-05-23T18:30Z,Found it,"(null)" GC80R08,2019-05-23T18:44Z,Found it,"(null)" GC87ZYR,2019-05-23T19:35Z,Found it,"(null)"
  17. GPX file sent as requested. Thanks.
  18. Ah, this all makes sense. I only walked away 50' or so with the watch. Thanks for the info.
  19. I did a cache today that has several auxiliary waypoints with significant (and useful) note/comments. See https://coord.info/GC82PKY I knew the comments existed, but could not find them in cachly no matter what I tried. Investigation just now at home shows several things: - I imported the caches into cachly via a gpx file generated by gsak. The relevant notes are included in the gpx file in <cmt> tags within the <wpt> tags within the <gpx> scope. - The "Waypoints" list for the cache in cachly at this point just has name and coordinates (image 1 below) whichis what I saw in the field - Refreshing cache via GC Live API causes notes to show up in the waypoints list okay (image 2 below) Is gsak using incorrect xml tag for this (even though it is in the gpx scope)? Or is this a bug in cachly? I don't usually refresh caches loaded from gsak unless there is a specific need. I can provide the gpx for this one cache, but don't know how to include it in the post! Thanks.
  20. Quick followup regarding using compass: I tried using both cachly compass screen and native ios compass app today while out on the trail. Definitely worked better for me today than in the past. Issue of using it in the car remains, so having an option for GPS course following will still be useful. I tried tracking to the cache via cachly app on my watch as well. How does it determine where to point? Turning around had no effect. Neither did starting to walk away from the cache (it still pointed "up" on the watch cachly compass screen). Thanks.
  21. I have not used the ios compass app other than checking it at home, so good idea to compare it to Cachly. I'll give it a try tomorrow when I'm out and about. The compass app allows setting a target heading, so it will be interesting to observe how stable it is. I'll post what I find. The fact that GPS "course" reading only reacts to device motion is exactly what is good about it! Compass mode has its use but so does this mode. I agree it should be off by default. Thanks for considering it!
  22. Thanks for the clarification about follow mode. I'm currently using an iPhone SE, but have had similar issues with previous devices. The most pronounced problems are indeed in the car, and so the metal would be a factor. But I also have issues with it out on the trail with no metal around at all. "Calibrating" the compass has no useful effect for me. This all adds up to a good use case for the feature I am asking for: provide an option to use device motion to determine North when navigating on the compass page. I find it much more stable and accurate overall. Is this possible? I have been using my trusty Garmin handheld but would love to use Cachly more often to navigate since I already have it open to the cache info. Thanks!
  23. Bumping this topic. I am loving new 5.0 functionality, especially premium maps. But navigation using the compass page continues to be frustrating to me, for reasons discussed in this thread. In general, I have never had a satisfactory experience navigating with a GPS compass pointer in traditional compass mode because it never seems to point accurately despite calibration attempts. I much prefer the mode where the device's motion (changing coordinates) determines which way is considered N (as is used on many standalone GPS units), and find it a much more accurate method of navigating to a target which is more than a hundred feet away or so. Is this the "follow" mode you're discussing in the previous post? I do see the three follow modes while navigating on the map page. But nothing on the compass page. If this functionality already exists, I would love to know how to use it. Otherwise, please consider this a strong request for enhancement. Thanks!
×
×
  • Create New...