Wegge

+1 My first choice would be for every log to be unique and detailed. Second choice would be hybrid logs, with a copy-paste overview of the trip and some content that is unique to that specific log. Third choice would be identical copy-paste logs describing the trip as a whole. And a distant fourth choice would be terse, nearly content-free logs like "TFTC" or "Found" or "DNF" or "". I would prefer TFTC over a copy-paste log. With the abbreviation, I at least can see that the logger is aware that the log is without information. The copy-paste log is something you'd have to read through, before finding out that it has null content. (Spoken as a CO)

According to Project GC, there are five other German caches with more logs. The top-ranking is GC13Y2Y Lego - einer ist zuviel with 11773 finds at the moment.

That depends on what issue you want to debug? I have a background in low-level systems, so I usually fall back on adding some Wherigo.Logmessage() calls in key positions, to log the state at that point. In the case of the player crashing, I've had succes with wrapping things in pcall: res, errmes = pcall (Wherigo.Showscreen(DETAILSCREEN, itemThisOrThat)) if not res then Wherigo.Logmessage(LOGDEBUG, "Error Showing ThisOrThat: " .. errmes) end Incidentially, by wrapping the ShowScreen() in a pcall, it's actually possible to show the detailscreen of an item in the Oregon player, without the GPS crashing. It appears that the player code is trying to call a boolean value as a function, which will generate a fatal runtime error without the pcall.

The problem is not only Garmin. The problem is that there is no specification for Wherigo, except reverse-engineering what come from the Groundspeak builder. It's using a pretty weak subset of what's actually possible in the Wherigo lua class (most of the Wherigo interpreter is written in lua[1]). The same hold true for the 3rd-party implementations, that also had to guess a specification. And that is where a large part of the perceived Garmin issues come from: Third-party builders, generating almost-compliant code, that the other players have adapted to. It's just not Wherigo. 1. Both the emulator and Garmin devices have a full lua implementation that include the reflective capabilities of the Lua debug library, so I hava a pretty good idea what's going on inside.

There are several problems with going the smartphone route. The main one being battery life. In many smartphones, GPS is a check-box capability, that isn't a core part of the product. Thus the hardware is minimal, leading to an extreme power drain, because of the heavy computational need. For instance, my phone will drain power completely in less than an hour, if the GPS is turned on at all time. On the other hand, I can have my handheld Oregon turned on for 16 hours on a set of rechargeable (and field-swappable) AA cells. So assuming that the umpteen smartphones on the market will all be usable, is not realistic. Second, a dedicated outdoor GPS receiver has much better ergonomics than a phone, coming from a market where thinner is better. Try walking a mile with a phone in one hand, and a Oregon or similar in the other hand, keeping an eye on the display at all (most) times. Now, which hand is the most sore? And finally, hardly any of the smartphones available are the least rugged. I also see this as a major drawback to smartphone as a viable WIG platform.

What about Garmin devices?

My Oregon 450 started behaving quite odd yesterday. Suddenly, the map view reports the present location as N0 00.000 E0 00.000, but only when the unit is moving. While stationary, the map resets to the proper place. Weirder still, the rest of the GPS knows perfectly well, where the unit is located, as for instance automobile routing still works (at least I get the beeps at the proper places). Displaying the satellite screen also shows a correct coordinate. I suspect that I have somehow hit the wrong place at the screen, sending the unit into an undocumented debug or demonstration mode. I've spent some time searching for a similar description, but my Google-fu is not strong tonight, so all I'm able to find are product reviews or people wanting to sell topographic maps So if anyone recognize this behaviour, and has a fix that does not involve a hard reset, I'd be happy to hear about it.

Python?

You are nearly wrong in all of the statements you make above. Lua was original developed for use in an application for the Brazilian oil company, Petrobras. The scripting language is very simple and easy to understand. And I have not seen any negative feelings from the Lua commynity against Wherigo. What is correct, is that Groundspeak have been very unhelpfuill in providing documentation for the platform, leading to a lot of badly implemented reverse-engineering apps, that each have their own quirks. Common to them all, is that they lack more than 50% of the functionality in the emulator, PPC player and the Garmin players.

How much processing is done inside your timers? Your problem could be that one timer doesn't finish, before it fires the next time. My suggestion would be to trigger the timers less often, and see if that makes the Oregon less crash-prone.

Seriously, why don't you use them? I'm sure that you have a better reason than, "they can't make me". I never said I didn't award them. Just that I haven't signed up to follow the whim of every other geocacher, that feel the need to proscribe how I should behave...

I don't remeber signing up to do abide alle of the peculiar ideas other geocachers have about this or that. So as long as GS doesn't force me to use the FP's (in which case, they would be given out at random), I cannot see why this is a relevant question.

The latest upgrade to Android 4.1 changes the way the SD card is visible to programs on the phone. So instead of looking in a folder on the SD card, the WhereYouGo app is now looking at an internal folder. You can still use the app, but you will have to move the cartridges to /mnt/sdcard/external_sd/WhereYouGo/ manually with a file manager app like ES File explorer or similar.

That is of course a possibility, but I wonder why the GS builder then bothers initializing the value to false. Also, I've tried to manually change it to true, and I've not seen anything behave differently.

Has anyone figured what the AllowSetPositionTo property of a zone means?

Signature items are still in use in Denmark. Or at least, has some followers. On the danish geocaching wiki, there is a gallery of some of the dansih geocachers' signature items: http://geowiki.wegge.dk/wiki/Signaturting

I have built a simple cartridge to test the possibilities. I have tried to run it in the WhereYouGo app for android, DesktopWIG and in the emulator. In all three cases, I could add more than 100 options, without any ill effects. I'd like to hear how the Garmins and iPhone app handles this.

If you build a clever little test cartridge that goes round a loop adding an extra choice each time until it crashes, and post it in the Earwigo group, then /a/ people with all the players will test it for you, and /b/ I will use the results to generate a warning in the Earwigo cartridge editor if the author gets close to the "minimum maximum" value. I will do that. And the // is only used as separators in the parts where translation is not possible, which are the cartridge name, cartridge description and the question asking for the language to use. As I see it, those three strings are inherently impossible to localize without compiling seperate cartridges.

You are excused, as I hid that question in the very last sentence of my post. However, after a bit of pondering, I looked at the way the Earwigo builder handles multiple languages. And there I found this hidden gem: WWB_localize_input = Wherigo.ZInput(cartPakkenTheParcel) WWB_localize_input.InputType = "MultipleChoice" WWB_localize_input.Choices = {"Dansk","English"} WWB_localize_input.Text = "Sprog // Language?" WWB_localize_input.WWB_cart = cartPakkenTheParcel function WWB_localize_input:OnGetInput (input) WWB_localize_input_handler(self, input) end And then the WWB_localize_input_handler is free to poke at the innards of the input object: function WWB_localize_input_handler (input_object, input_value) local i = 1 while (i) do local l = input_object.Choices[i] ... So I think I can achieve what I wanted to do by adding a table of Zones to my input object at definition time, and then picking the zone with the same index as the answer string for further processing, by using self.zoneTable. I've not yet tried it out, but with my present understanding of Lua, it should be possible to add. And while we are at the subject, what is the upper limit on the number of MS choices the various players are able to handle? And for that matter, show on a single screen?

Is it possible to get the selection from a MultipleChoice input as something else than a string? I'm trying to work around the limitations on the number of visible zones, by giving the player a Yellow-Pages item, where he/she can select the destination to go to. It works, but I end up with a lot of repetitions: zinputVisVejTil = Wherigo.ZInput(cartPakkenTheParcel) zinputVisVejTil.Id = "61b25265d6163eaa054ef91d00d49c1a" zinputVisVejTil.Name = "VisVejTil" zinputVisVejTil.InputType = "MultipleChoice" zinputVisVejTil.Choices = {"Supermarket","DIY store","Mason","Carpenter", ...) zinputVisVejTil.Visible = true And at handling function, I have to repeat this: function zitemVejviser:OnVisvejtil(input) if (input == "Supermarket") then zoneSupermarket.Active = true zoneSupermarket.Visible = true end if (input == "DIY store") then zoneDIY.Active = true zoneDIY.Visible = true end if (input == "Mason") then zoneMason.Active = true zoneMason.Visible = true end if (input == "Carpenter") then zoneCarpenter.Active = true zoneCarpenter.Visible = true end ... end While this works, it's error prone. So my question is: Is it possible to pack an object reference into the command? In my ideal world, it would be possible to specify a table for the input like this: zinputVisVejTil.Choices = {{Text = "Supermarket", Obj = zoneSupermarket}, {Text = "DIY store", Obj = zoneDIY}, {Text = "Mason", Obj = zoneMason}, {Text = "Carpenter", Obj = zoneCarpenter}, ... } With a construct like this, my coding could be a lot simpler. But so far, all of my efforts to find a way to do this have been in vain. Is it possible, or should I go and look for a way to create the commandlist at runtime instead, and make my own mapping table?

There is a picture of several different sizes and shapes on http://www.cacheopedia.com/wiki/Bison_tube

Early onset of DST trouble, perhaps?

I can print both Open Street map and MapQuest, using Google chrome (I use the CTRL-P shortcut). But I noticed that what is printed isn't exactly what's on screen. The print preview includes the part of the map that is obscured by the side panel. It also doesn't extend all the way, so depending on screen resolution and paper settings, I can get up to about three quarters of the displayed map to print.

What prevents non-PM's from logging a PM cache?

As a note on the cache page?