sTeamTraen

Is 13¾ years too long for a bump? Here are the latest numbers: https://docs.google.com/spreadsheets/d/1J_YQCWr29u8rTztVML9UYhXfux68xRGA/edit?usp=sharing&ouid=113582013589336579669&rtpof=true&sd=true (There have been other intervening updates to the table, but apparently I forgot to post them in this forum.)

OK, thanks to all for the clarification!

I created this cache, and recently adopted it out. The owner info (still) says "A cache by sTeamTraen", with a link to my profile. The name of the current owner (aksaY) isn't visible anywhere on the page (apart from the logs that they wrote after adopting it). It's true that there is a link next to "A cache by" saying "Message this owner", which opens Message Center with the current owner as the target of the message, but that is also a bit confusing. First, the words "this owner" imply that the link will message me (sTeamTraen), whereas in fact it will message the current owner. Second, it doesn't offer a quick way to see the name, profile, or e-mail link of the current owner. My suggestion would be to have "A cache by" contain a link to the current owner's profile. Maybe the original owner's name could be a plain text field somewhere, although in a previous version the CO could write a plain-text version of the ownership info, and one often saw something like "sTeamTraen (adopted by aksaY)" there; that seemed to work quite well. But I don't see any great need for the initial owner to be linked, especially since the original owner may no longer be part of the game (and some caches have been adopted multiple times).

See screenshot. What should be a URL is a local file reference, that will only work in the context of the server.

While out caching with the app the other day I noticed a typo in the name of a feature on the map. (If you want to see it, it's near the icon for GC790XR --- the caption says "Boomslang Canopy Trailil", so the last word should read "Trail".) So I made a note to go on to OpenStreetMap.org and fix this typo when I got home. But on that site, I can't find this caption at all. The path is listed as "Tree Canopy Walkway" (see here). Is there more than one OSM database? How can I go about making this tiny, tiny fix?

Normally when deleting a log, the page reloads with an "Are you sure?" message above the log for the user to confirm the deletion. On Microsoft Edge today, the page reloads but the "Are you sure?" message is not there, so I can't complete the delete. (Yes, I know I should be using Chrome or Firefox, but... reasons).

For various reasons I'm on a slump at the moment. To add to the sadness, this seems to have run into a bit of a bug in the statistics. Have a look at the attached image. My last find was on June 9, and I'm writing this on July 12. So the slump is from June 10 through July 12, which is 33 days if you include today (21 in June, 12 in July). So the "Longest slump" line appears to be correct. But the "Current slump" is wrong in two ways. First, the start date of the slump should be June 10 and not June 9. (OK, so maybe the word "since" means something different on that line.) Second, the length of the slump is *shorter* at 32 days, even though /a/ it's the same slump as the "Longest slump" (so it should have the same length), and /b/ if the calculation Is that it started a day *earlier* than the "longest slump", it should be one day *longer*. PS: I hope to find a few caches next week...

Sorry for the delay in replying - I've been travelling. Earwigo is working for me right now.

If you ask this in the Earwigo support Google group, it might have a solution. (It's about 8 years since I wrote this code and I don't remember what is and isn't possible, but the Earwigo power users will know!).

I just sent an adoption request to someone who taken over one of my TBs. I received this mail from the site: Now, I know that the procedures for adopting caches and trackables are very similar, and they probably use much of the same code. But perhaps the last sentence here shows that the difference between the mails in the two cases could be slightly more than replacing "cache" with "trackable". I don't even know how to maintain a trackable! ?

Ha! Modern app design confuses old man. (Surely it wouldn't hurt to make each mention of the user's name a link to their profile, though?)

It used to be (I think) that if I was in a MC dialogue with someone (on the web site) and I wanted to look at their profile, I could click on their name at the top of the conversation. Since the new release, I can't find any links that work for this. Am I missing something?

Or have the list filterable or sortable by status (available, disabled, archived) more generally.

They do, but I want to be able to scroll down the page while just focusing on the column with the wrench in it. Well, I'm not sure how much one can learn from the NA attribute. Perhaps people who archive their caches when they can't maintain them are placing better caches than those who archive them for other reasons (e.g., 90 days have passed, time to archive and churn the same container at the same location); this is basically an epidemiological question, and there are lots of counter-intuitive things that emerge in epidemiological studies, especially when survival (aka archiving here) is a factor. There are so many statistical tests I would love to run on the cache data! Anyway, my suggestion was just for one's personal owned caches, but maybe there is a lot of code shared with other displays.

When I look at the list of caches that I own (here), it would be nice to scroll down and use the presence of the red wrench icon to tell me which caches need maintenance. However, quite a few of those caches are archived. The fact that they need(ed) maintenance doesn't seem very relevant any more. If the wrenches were removed, it would be easier to see quickly which caches need maintenance.

There are two problems with the Netherlands Antilles: One is that that entity doesn't exist any more and so all the caches with that "country" should be edited to whichever Dutch-speaking area (I won't go into more political detail than that, it's complicated) they are in. The other is that in the specific case of the island of St. Martin all of the caches are listed under "St. Martin" with no distinction between the French and Dutch sides. The caches on this island are all reviewed by the Dutch reviewers. Hopefully GS will add this to the wishlist for the next international sorting-out.

When making Earwigo, after a lot of experimenting, I found a cross-platform Lua string that works: "\060BR\062\010" That translates to <BR> plus an ASCII line feed. However, the < and > have to be encoded as escaped decimal numbers to stop the compiler from eating them. In the Earwigo interactive builder you can just use a line break in a multi-line string box, or (I think; it's a long time since I checked) include "\n" in a single-line string box, and the code that generates the Lua file will handle this correctly.

Since the intention seems to be to refer to Mystery caches consistently as "Mystery" from now on, maybe it's worth noting places where "Unknown" still appears. To start the ball rolling: Automatically generated e-mails to the CO based on logs on Mystery caches that they own still use "Unknown" instead of "Mystery".

See below. For the Rhône-Alpes region, my PQs numbered 020, 002, and 003 were recently edited. The others have been unchanged for a few weeks. At some point since September, the code seems to have been changed to not send correct UTF-8 accented characters over the API.

I've hotfixed the builder to allow up to 5MB for media files. I hope this doesn't mean that image files will be exploding my database space...

A local cacher who is pretty reliable observer informs me that there are still problems with notifications. He describes it as "two days on, one day off", and says this has been happening for the past three weeks or so. I don't know if there have been any other reports of notification problems since the last major update.

What the title says: when you have 123 finds and then log "Attended", the app says "Well done, 123 finds". This incorrect count persists until the app next does syncs the profile from the server. No biggie, but one fewer bugs is always nice...

Wow. 5453K is about five minutes of audio, I think. Is someone meant to listen to that all the way through, in the field (with other random noises), and no media player controls to skip back 10 seconds if they don't hear something clearly?

Earwigo imposes a limit of 512K on a media file, simply because I didn't think anyone would need more than that. After all, a photo for a smartphone screen probably never exceeds 50K even as a BMP. Now that most people are playing Wherigos on a device that can actually play back proper sounds, I guess it makes sense to allow larger files for MP3s (back in the "Garmin days", sounds just meant beeps). I will fix the size limit when I get back from vacation, as I don't have all my tools with me here. But please remind me via the Earwigo Google Group support forum. (Indeed, for the future, please ask all Earwigo-related support questions in the Google Group support forum - I only found out about this thread from a Google alert!) How big is the biggest MP3 you are trying to use? I would imagine that a minute or so of sound ought to be enough for any given stage...

Awww, thanks! (I am the only "maker", but my team of translators and forum support people keep everything running smoothly!)