matejcik

ho-hum.... we would need a cartridge that would really exercise the Wherigo player. lots of different zones (three or four active at the same time), lots of items (at most four in a zone) moving around between zones and inventory, long dialogs, maybe even some kind of high-processing computational loop somewhere plus of course timers. this way there is a good chance that the cart would crash the problematic units. but on the other hand there is a good chance that it would crash the other units as well. maybe there are only "more stable" and "less stable" oregons... i'll think about it, but i don't have a particularly good idea at the moment

the active/inactive thing works well with zones, but i am not so sure about characters but i have a feeling that you're overcomplicating the whole thing. you said that you want to set the character to visible when player first appears in the zone, but you don't want it to be visible later. so that means that you are setting it visible in OnEnter? why not just make the character visible by default, then do nothing in OnEnter, and finally set it invisible somewhere else (kill the character) and be done with it? alternately, instead of setting invisible, you can move the character to nowhere (i am not sure how to do this in urwigo, but i guess there is an option to set "nowhere" or "nothing" or "nil" as a target of move) then you don't need to care about whether the character is visible

ah, well. i am not aware of any urwigo bug related to this - but maybe there is one. if it is a text question, then what i wrote will not work. do this: 1. turn off source encryption/masking/whatever the option is called in english urwigo you need to be able to export readable source 2. generate a gwz file from urwigo 3. rename it to .zip, open it and extract the .lua source file in the source file, find "function zinputYourInputName:OnGetInput" and paste code of that function here. then we can look at it and find out what caused the problem

welllll....... so you get an input, then you suddenly decide that you don't want to answer it and press Exit instead? first of all, don't do that :e) when somebody asks you for input, you should answer it. many cartridges will simply ask you right again if you decide to exit; some others are badly designed and when you do this, you cannot continue, because the author didn't anticipate it. to answer your question: this is a Builder bug. you can fix this in code, or you can use Earwigo/URWIGO which don't have this bug. it happens when you have numeric input and don't give an answer. the problem is that the input handling code tries to convert your input to number, and because you didn't answer (so the answer text is empty), the conversion crashes. the code for this goes like this: yourinputvariable = tonumber(input) if yourinputvariable ~= nil then (... do something ...) the first line crashes. to fix it, change it to this: if input ~= nil then yourinputvariable = tonumber(input) but note that when you change this manually, you can no longer open the cartridge in Builder

as RangerFox said; i have lots of anecdotal evidence that Wherigo player on Oregon varies from unit to unit. some Oregons are pretty fine (except for oregon-specific bugs), others crash for no good reasons at all i will have a look at the cartridges by Fried Okra. but what i'd love to see - somebody with a "buggy" Oregon try and play one of those cartridges. then we would see whether the problems can be solved in cartridge, or if it's the device's fault

yes, it seems broken for everyone. ...shall i start coding openwherigo.com? ;e)

this is interesting. so you have a cartridge that plays fine on an oregon, and is elaborate and you have a different cartridge that breaks? can you send links to such cartridges?

restart is simple enough - just set all the properties to their initial values. then you can force save

what do you mean by "lack of public outcry?" the dozens of threads related to this are not outcry enough for you? ;e)

that means that your Java machine is not capable of accessing files. you'll have to find a different one (check for JSR-75 in list of features)

actually, you don't need that at all instead of showing the item like this (which is a bad idea anyway, as it might crash an Oregon), make it part of the dialogue. for the first screen, set a media object same as the item's, and put "You got new item: (name of the item)" as a text. or if you insist on showing the description, copy it into the dialogue. then create the rest of the dialogue as usual.

i vaguely remember someone mentioning somewhere that this device is windows CE 5.0 in 5.0, there is a limit of 32MB per process. it is quite likely that Wherigo Player can't fit into this

the "one language" is Lua. and it's always Lua. i'm actually not sure what you mean now.

my instructions earlier were incorrect. you need to run it like this:runMidlet.exe -classpathext "OpenWIG.jar" "OpenWIG.jad" gui.Midlet (it's the "gui.Midlet" part that is important) i don't have the slightest idea what this is supposed to mean in general, yes. if you have a specific problem, please report a bug and provide all details (e.g. the error message and where it appears)

because Wherigo isn't making money, that's why Groundspeak has limited resources and putting most of them into Geocaching-related stuff, because GC is the cash cow (and i reckon it needs a great deal of attention) plus, Wherigo is the kind of project where the effort is too big and the return is too small, at least at this point

hmm, that's not all. you would need to do a few more steps for each item: - make the "take" command disabled by default - enable it in the small zone's OnEnter - and disable it again in OnExit ...the end result is this: each item has its own zone, which is invisible the zone is activated when you enter the big zone. at this point, items become visible, because the small zones "broadcast" them to a certain distance so you can see the item, but can't pick it up, because the "take" command is missing when you come close enough, you enter the small zone and item's "take" is activated. you can pick up the item and move out still, there's a bunch of loose ends. if you're not a programmer, i suggest you try to come up with something less complicated than this.

if you really set it up so that players would have to get 5ft to the item to pick it up, they would kill you five feet is a very very small distance. much smaller than even the best GPSr's precision can get you. nobody could ever get close enough to the item to pick it up, so playing your cartridge would be an exercise in frustration. bear in mind that when you're geocaching, you don't need to see zero on the display to pick up the cache. in Wherigo, you would actually need to get to the precise coordinates, which is impossible most of the time. if you want to get players closer to the items, make the zones smaller - but again, not too small. 15 metres wide (cca 50 feet) is the recommended minimum - smaller than that and even Colorado will throw you out of the zone on occasion with that in mind, here's what you can do: - let's take one "main zone", which is the one that should contain three items - for each item, create a 50ft wide zone. set it to invisible and inactive and place it around the item's supposed location - this zone should display items "on proximity" (there is a drop-down for that). make sure that "distance range" for this zone is -1 and "proximity range" is at least as big as the main zone (which is 150ft, you said?) - place each item in its corresponding zone, instead of the main zone. set the proper coordinates. - create an OnEnter script for the main zone. in it, set each of the small zones active - similarly, in OnExit for the main zone, set the small zones inactive (if you already have OnEnter or OnExit, add the activation/deactivation to it) - repeat for each of the big zones hope this helps

"create from map" does not work. for USA, it stopped working a year ago, for other parts of the world it never worked in the first place. also, there are at least eleventy recent threads about this the only good solution is to stop using Groundspeak builder and use one of the alternatives - earwigo or urwigo. both have very good map editing capabilities

so, did you look into Commands? those are like little buttons on items or characters. they don't work on tasks, and that's what is confusing to most people. task are designed to be non-interactive - a checklist for stuff the player should do to in order to advance. place a character "wise man" or "guardian" into the zone, say "i won't let you pass until you answer my question" in its description, and place a command called "answer the question" on this character. then you get a new event - "when Answer the question happens", where you can call the input. or if your cartridge is simply a series of questions (which, at least in my opinion, is not at all better than direct-walk), just create item called Question in the zone and add a command "answer" on it.

there are no "input forms on tasks" at all. how about you create an input form and initiate it from, i don't know, SOMEWHERE ELSE than OnClick? Commands on items, Timer events, Zone enter/exit/proximity events and OnStart events are good starting places

yes, it comes pre-installed with Windows, MacOS X and most linuxes. in windows, most people know it as "notepad" on a more serious note, very good workflow is to use Earwigo (especially suited for this mode of operation) to define a list of media, zone, character, item and task objects, then download the resulting lua file and type in all scripts by hand. then you can use either Builder, urwigo or Wherigo.com compilation service to build the cartridge

that cannot work, for a number of reasons one, you cannot use file i/o on oregon two, LuaExpat is a binary extension which you'd have to install on the oregon somehow three, you are still limited by Wherigo's interface. you can safely stuff accented characters in various encodings into a cartridge as it is, but you can't display them, because the interface won't let you. ...which, on the one hand, is rather weird - after all, oregons must have some kind of native encoding, which, when fed in binary to the display, should show the accents properly. you might want to toy with that

5.1, bytecode is 32bit little-endian why do you ask?

attach file is somewhere around here, but it only works for zips. anyway, here's what went down: 1. the first time around, when you scanned the outcropping, a message appeared: "You have discovered a cute but unidentifiable creature. (...)" Did you see this message? Did you click "Ok" to continue? 2. the second time, when this message appeared and you clicked "Ok", another message appeared: "New Task: 'Scan' Alien with Transponder to name it" after this, the alien was moved into the inventory. the first time, for some reason, the callback was never initiated. this happens to be the same problem that we saw on Android. i'll look into it in more detail, perhaps there is some kind of race condition that is killing the callbacks ... blah blah. i now have a pretty good idea of where the problem is lurking. but you have to tell me: did you see and click through the dialog i mentioned?

well, the developer originally said that he didn't want to put it up on the Market. perhaps he was testing something and then pulled the app