matejcik

psát česky se tu může, ale ostatním uživatelům fóra pak bude odpověď k ničemu ;e) takže ve zkratce: - OnClick prostě v garminu nefunguje a nebude fungovat - tlačítka ve zprávě fungují vždycky. ale to s tím nijak nesouvisí, protože: když dáš na věc OnClick, tak se místo defaultního zobrazení (image + description + tlačítka Commandů) ukáže tvoje zpráva, pokud to player podporuje na Garminu se ovšem defaultní zobrazení ukáže vždycky, takže do tvojí Message se nedostane vůbec musíš prostě nastavit Commandy do defaultního zobrazení, aby se to dalo použít i v garminu kdyžtak pošli PM ---- simple answer is: - you can NEVER use OnClick, because it doesn't work in Garmin. if you don't use OnClick, then when the player clicks on an item, they will see image, description of item, and list of commands if you use OnClick, then when the player clicks on item, you can show them a message or an input instead so if you use OnClick, then Garmin players will see description and list of commands (empty), but PPC and WhereYouGo players will see a message or an input. - you can use Message buttons always. they work fine in all players. but that doesn't matter, because if you use OnClick, you can't even get to the message to solve your problem, you have two choices: a) if there is only one way to complete a task: in the same place where you set the task to Complete, you can set the Command to enabled. if there are more ways to complete it: set task's OnSetComplete event script and enable the Command in that script. that way, whenever you have "task.Complete = true" anywhere, the OnSetComplete script will run and enable the command

you must not use "on click" events. instead, assign commands to the item, and then do things when the user picks the command

it's called WhereYouGo and you will find it in Market

do any of you know who made the app?

it works for me ... are you sure that you have all zones zonestage1 thru zonestage25 defined? also, from what you pasted, you are missing an "end" for the "function zonestage1:OnEnter". if "end" is missing, this function will end up eating all other functions and it won't compile

yes, that looks about right. except that you left "zoneTheLastOneEver" in the list, which probably doesn't exist in your cartridge ;e)

set zones' Distance Range to some bigger number distance range specifies how close to the zone you must be in order to see it if you want always visible, set distance range to -1

easy allzones = {zoneA, zoneB, zoneC, (.....), zoneTheLastOneEver} randomzone = allzones[math.random(#allzones)] then you can do whatever you like with "randomzone" or, if you stored the number somewhere, e.g. in variable i, use allzones to refer to that one

you have to set identifiers in zone properties, and then use those identifiers in your code.

well, this is the eternal Wherigo question: are Garmin devices really broken and don't work with zone shapes, or is it the people who play that are doing it wrong? i'm a strong advocate for the latter (and i have yet to be proven wrong), RangerFox carefully works with the assumption of the former. the proximity approach sidesteps the whole problem quite neatly, at the expense of certain level of control over the game experience basically it's like this: when you tell people to stop at zero, you're telling them the wrong thing to do. and if you want your cartridge to be foolproof, use RangerFox's proximity solution. these two advices are not in conflict.

i would change rules 4/5 to this: Remember that a zone is not a geocache and you don't need to "zero in" on it. In fact, if you stop right at the zero distance, you will end up on the zone border, not fully inside and not fully outside. Instead, walk freely. Just follow the general direction of the arrow and stop only when the device tells you that you are "here". Usually, zones are big enough that you don't have to worry about missing them.

yes, the domain has expired meanwhile. new links are: http://www.raketa2.cz/openwig/openwig-bbgps.zip for OTA: http://www.raketa2.cz/openwig/openwig-bbgps.jad http://www.raketa2.cz/openwig/openwig-bbgps.jar

hi, what you are doing sounds correct. just to make sure, here it is in more detail: 1. create variable 2. create "input" object, fill in question, link with variable 3. in some script, "get input" 4. in the input's "OnGetInput", display the message oregons never had problems with this. but maybe oregon is not running the "get input" script? are you using OnClick?

not entirely true - we do have a spec for the GWS format (although we didn't reverse-engineer it ourselves, we did the walled garden approach, same as with GWC), but it is impractical for us.we might, at some point in the future, auto-generate an "unlocker" GWS file, but it's not very high priority. if somebody does go talking to Groundspeak, i think that an "online unlock service" web API would be much more practical than supporting OWS.

if the extension really is GWS, then i guess that's a bug in WhereYouGo ... okay, not really a bug, more of a "confusing feature" menion, if you're reading, would you please reconsider this?

you want PocketPC. the functionality of all variants is the same, but PocketPC contain sounds, while Garmins don't i don't follow: you say that you can't upload gws (actually it's called ows, because it's different - see?), and that menion told you that it can't work this way, so you're asking again? okay, let me answer again: this can't be done. just to clarify, this is not your phone's issue. this is "system compatibility" issue between the open players (whereyougo/openwig) and the official players (garmins, PPC) well technically we could do it, but it goes like this: - GWS is Groundspeak's savegame format - OWS is openwig/whereyougo format - they are not compatible, because the players are different - Wherigo.com allows you to unlock by uploading GWS. not OWS, because, well, Groundspeak didn't create it and there are certainly issues that are more important than supporting it. - we could reverse-engineer GWS and create an "unlocker" GWS file for each completed cartridge (and this in fact has been done), but it doesn't seem necessary, because: - you can unlock without GWS, by using an "Unlock Code" that can be displayed on screen, and many cartridges already do this furthermore, this whole point is moot, because although you can unlock a cartridge on Wherigo.com, there is no way somebody else can check that you unlocked it. this may become important in the future, if/when Groundspeak extends the Wherigo.com site with this functionality. but i hope that when they do, they will also implement "online unlock" that will allow us to unlock the cartridge directly from the player, killing this problem once and for all

did you generate this code with a Builder? seems to be a builder bug. the code says: if zoneJersey.ZoneState == "Proximity" then and the correct code seems to be if zoneJersey.State == "Proximity" then as i said, this will not work in openwig and whereyougo, because it's not implemented yet, but i can add it rather easily. and it should work on Garmins and Emulator/PPC player just fine

well, do you have the Lua code for this statement? i think that it won't work in WhereYouGo/OpenWIG, because this functionality is not implemented (yet). but it should work in emulator

for this, multiple user profiles would be better. each with separate achievements, history etc. maybe log in with their Groundspeak account or something.definitely doable, though. TrackOnFly again? as long as it's your co-player, fine. messaging random players is harder than it looks, because all of those spam precautions, privacy protections, ignore lists etc.maybe go at it another way: make yourself "pulse" on the live map and ask others to send messages, should they be so inclined pretty simple ...... ho-hum ... this would be good for publicity. a Wherigo facebook app, perhaps? this would be a feature for the aforementioned server-based multiplayer

now let's see what i could possibly do by myself... i'd have to include something very close to a full-fledged HTML parser/renderer for this to work, and that is not something i'm too happy about. also, many supported phones have really low screen resolution.but reordering buttons, putting up multiple media, specifying order, background and foreground colors, all this should be doable without much hassle. also i've been thinking about extending the main four-option menu impractical on a cellphone, but very possible on Android - afaik, WhereYouGo already does this something like googlemap tags? again, impractical on a phone, possible on Android this just *might* work on Android, where applications can cooperate in interesting ways. but i can't imagine seeing this on PPC, at least not without a huge deal with Google.cellphones are out of the question, obviously probably relatively simple (although i don't see the point) this must be done on Groundspeak's side doable, the same way sounds work - if a cellphone supports the video format, it will play it there's this multiplayer API draft. heavier than that, it requires work on Groundspeak's end (that TrackOnFly thing? but unless that opens up, this would probably kill openwig ) needs work on Groundspeak's end. shouldn't be hard, though needs work on Groundspeak's end. also, achievements FTW ;e)

labrat: yes, the PPC version. it has the richest set of media, otherwise they're all the same eagsc: JAD is a signature file, JAR is the application itself. on some phones, you need the JAD to install, on others, JAR is sufficient. i am not sure about blackberries, so i'm including both

pocket pc and emulator software are basically the same, so yes, in PPC. (but maybe i'm wrong about this and you don't need the <br> in emulator/ppc) i was under the impression that the Wherigo.com service strips the <br>s for garmins - when testing on garmin, did you generate the gwc for the right target? again, i am not really sure that this really does happen - but i've seen cartridges that have <br>s in their texts, so it has to work somehow.

your syntax is wrong. ...and actually, i think that you have to use both <br> and "\n". this should work everywhere: MyText = "this is the first line<br>\nthis is the second" also note that you need backslash "\" not forward slash

at this point, all Wherigo players have a reliable save/restore feature - so yes, this approach is practical

see my reply in your other thread