matejcik

that's good news. another question is whether the .urwigo is included in a compiled GWC, which would be bad. can you check that? (hint: open gwc in a text editor and look for a blob of xml tags)

Groundspeak account = GC account = forums account = Wherigo account simply go and log in with your GC credentials

correct. (the other way should be possible - i am not sure, but i think that you can import Builder-generated .lua in Urwigo) i wonder if we could pack the .urwigo file into the gwz. somebody care to try? that would be a nice feature

the lua file is good-working, you're just using it wrong. note three things: 1. Lua is program code, not a save format. Groundspeak Builder writes Lua code in a very specific way so that it can read it later. But that is not the "only proper way" to write Lua - Urwigo uses extended functions and doesn't keep Builder's way. (After all, sometimes even Builder breaks its own way of writing.) Nevertheless, the Lua file can be compiled by Wherigo.com just fine. It is a proper Lua file, just "not good enough" for Builder. 2. Because of that, URWIGO uses its own *save format* called .urwigo. If you save your cartridge as .urwigo, you can open it in URWIGO later without problems. 3. Because URWIGO allows you to do more than Builder, you cannot export cartridges from URWIGO back to Builder, because Builder wouldn't understand them anyway. the moral of the story is: if you don't need to change the .lua file, do not touch it. And if you don't need the GS Builder, don't touch it either

as specified where?

from where i'm standing, it is so unstable because Garmin decided that the project is not interesting and stopped putting any resources at all into it. coincidentally, very similar thing happened at Groundspeak (although admittedly, they do put -some- resources into it, just not quite enough to do any significant good) so my guess is that Wherigo on dedicated GPSr is a no-go until and unless it gains some traction by other means please note that the opinions expressed are purely mine and do not represent official stances of either Garmin or Groundspeak ;e)

i'd guess it goes like this: if target==PPC and we have a resource ending in _ppc.*, use that else if target==garmin and we have a resource ending in _garmin.*, use that else use first resource or maybe: if target==PPC: if we have a resource ending in _ppc.*, use that else if we have a resource not ending in _garmin.*, use that else use first else if target==garmin: (same thing)

yes, that's the point

exactly

no, i'm afraid you think wrong. can you give an example in pseudo-code? something like: something like this? if that is what you are trying to do, you don't have to write this in author script. you only copy-paste my author script into your cartridge, and then you create this code in the builder normally

not really - you can select one media per screen. but you can put both images as resources for the same media. If you do this, then the compiler will automatically pick whichever image is appropriate for the target device. the "looks better" depends on what kind of image you have and what kind of compression settings are on the jpeg. but yes, some people are using png's and they work fine

i am pretty sure that the Lua runtime in Oregons is exactly the same one as the Lua runtime on Colorado, PPC and Emulator (compiled for a different architecture, of course) now how the Oregon Wherigo app actually manipulates the runtime, that's a different issue altogether. and perhaps the Oregon UI is multi-threaded and Lua runtime is used in an unsafe way (which would, by the way, be a very nice explanation of the ShowScreen bug)

okay. first of all: do you really need to write this in an Author Script?

see what i said in my other comment

also, the way you are calling it, it will not work. you need to do it this way: Wherigo.Dialog{ {Text="Erste message"}, {Text = "Zweite message"} } Wherigo.MessageBox{Text="Letzte message"} or if you just need simple things like this one, do not write the code in AuthorScript and just use Builder's "message box" and "series of messages" commands.

you have to use the "Wherigo" prefix: function zitemThing:OnHelpMe() Wherigo.Dialog("Erste Dialogmessage", "Zweite Dialogmessage") Wherigo.MessageBox("Und hier die letzte Message") end This is how Builder generates the code. Or you can add these two lines to your author script: Dialog = Wherigo.Dialog MessageBox = Wherigo.MessageBox then your code will work unchanged

that's precisely what they said

okay, i take it back, this is not Wherigo.com's fault. Wherigo.com sends the proper header ("Content-disposition: attachment; filename=something.gwc") and mobile browsers happily ignore it and save as download.aspx that's why i let openwig display all files, not just gwc ;e)

this is because Wherigo download pages suck (as do most other Wherigo webpages ) but the truth is that the file extension does not matter in this case. if you download it straight to phone, you can use a file manager to change the extension from .aspx to .gwc and it will play all right

something interesting cropped up in the Earwigo group: let's measure the capacity of Oregon's text buffer.set up a timer that will show a messagebox with longer and longer text every second. initial length and increment will be configured via inputs. the number will be shown at start of text. let it run and see what number comes up last, before the unit crashes. see if the number is always the same, or whether it varies

hi, the thing is, tasks are designed to not do anything. this is what confuses people the most. tasks are supposed to be a list of stuff for the player to do. for example: - visit the king (done) - talk to the king's cook (done) - get a tasty bread (failed) - find the magical lake (done) - pick up the magical ring (pending) - give the ring to the king (pending) so no, there are no instances where "tasks make most sense". tasks are a list of stuff. and in this sense, they work in Garmin players perfectly. when you want your player to do something, you need to prepare something that is "doable" - which is a zone that can be entered, item that can be picked up, character you can talk to etc. then you can, if you want, write up a task that says "hey you player, now your job is to walk to that and that zone, where you meet a character, so just click on his Talk command" the problem with Garmins is that they do not support OnClick events (and i say good for them ), which is the only way to bring some kind of interactivity into a task. there is a thing you -can- do on Garmins and PPC players alike, and that is setting "when a task is completed" event. this works like this: you can set some task to complete from many places. say, you have a task called "get some bread" - you can accomplish it by walking into a shop, stealing from a character or finding some bread just lying around somewhere. in each of the instances, you set code to "set task ztaskGetsomebread to Complete" and in "when a task is completed", you can for example fire up a messagebox saying "good job, now you stuffed your face" hope this helps

best oregon-specific crasher is ShowScreen other than MAINMENU. (so for example showing list of zones or details for a specific item) if used often enough, it is almost guaranteed to cause a crash.

it is still the same. geocaching tracks only caches. no cache -> no point.

as a matter of fact, yes, PDK would help quite a bit. it would mean that you can use readily available Lua for C, so the harder part is already done. (disclaimer: even though it is possible now, i will not be the one to write the player. but i'm willing to provide assistance to whoever decides to do it)

and why exactly would you want to import lua files? it is impossible to make a general importer for just any kind of Lua files. in Groundspeak Builder, Lua is the primary save format, and it has a very specific syntax in order to work. (so specific, in fact, that sometimes the Builder will save the file and can't read it back) in Earwigo and URWIGO, Lua import is only for compatibility with Builder, and the importers only eat Lua files in Builder's format. so if you extract a Lua file made in URWIGO, you will never be able to import it anywhere, because it uses a different syntax, which is not designed for importing. instead, URWIGO has its own save format, .urwigo, which you can use to save and load cartridges