matejcik

i have none! (or maybe you're wrong and it does work in OnStart after all ;e) )

well, technically yes, you could call compiling first pass and execution second pass. but that's not relevant here, because functions are first-class values.the following code function cartSomething:OnStart() (something) end compiles to "set item 'OnStart' of table 'cartSomething' to value 'compiled function chunk 0xdeadbeef'", so you don't know which function will end up as OnStart before you actually "run" its definition.

that is actually impossible ;e) first you have to call ZCartridge, then you define OnStart. at the point where ZCartridge is called, OnStart doesn't exist. (and it wouldn't help the case anyway - either you do have the position before loading and running the bytecode, or you don't)

geos715, hi again :e) i didn't know that you didn't realize that you can run openwig on android. so here goes: you actually can ;e) you need to use netmite android converter to convert the .jar file to .apk, but then it works.

that's all nice and fun (and obvious to me ;e) ), but now i no longer understand why the code in OnStart won't work in the same way the code in author functions does. before, i thought that when OnStart runs, the GPS position is not yet known to the Wherigo engine. That makes sense - the engine must actively populate the Player object with the coordinates, so maybe it runs OnStart first and populates the position afterwards. but i think that OnStart runs -after- the author scripts, because if it did run before it, that could seriously mess things up. so why do author scripts see the position and OnStart doesn't?

the pencil example is a good way to solve this. another way to do it is to have a "notebook" object in the inventory, and that would have a command to change each variable, which would trigger the corresponding input dialog. or place a character in the zone and make the player "tell" the character the solution - which the player can do many times over if they decide to change their answer. mostly depends on your theme.

the item itself will be visible. the command to drop it will be hidden. or maybe it's "disabled", i'm not sure what language is the Builder using (somebody with windows please fill in the details ;e) ) you will do something like this: when cartridge is started: - set the command "Drop" of item "Ring" to Disabled when "Take" is selected: - move item "Ring" to Player - set the command "Take" of item "Ring" to Disabled when player enters zone "YourTargetZone": - set the command "Drop" of item "Ring" to Enabled when "Drop" is selected: - move item "Ring" to zone "YourTargetZone" - set the command "Drop" of item "Ring" to Disabled (optionally, set the Take command to enabled again.

yes, this should do the trick. thanks.

great. that is the desired behavior. RangerFox, would you be so kind and update my original post with the new code?

right, that makes sense. and the original code didn't. how i came up with it, i'll never know... try to replace rundialog function with this: function rundialog () local ds = dialogStrings dialogStrings = {} local cb = {} cb = function(thing) if thing ~= nil then local item = table.remove(ds,1) if item ~= nil then if item.Callback == nil then item.Callback = cb end originalFns.MessageBox(item) end end end cb(1) end i didn't test it, but unless i did a syntax error, it should fix your issue. if it does, please report back and i'll try to convince RangerFox to edit my original post ;e)

which line is number 934 in your cartridge?

also, it's a bad idea to use onClick. it doesn't work on garmin players

create a command "Drop" on the item. keep it hidden. when you enter the zone where you want to drop, set it to visible. then you can write the code into that command. if you want to explain some of the steps in more detail, just ask :e)

ah. check the location's distance range. it won't show up in list of locations until you get closer than the set distance range. you can set it to -1, then it will always appear

this is happening on some particular device, or in the emulator as well? does the task hiding work for that zone? (i.e. is the event handler really executed?)

i can do it; and if i can, in all likelihood somebody else can too. you would need to decompile the cartridge to do it, or convince the emulator that the cartridge is locally published (i think the latter can be done too, but i'm not sure which way is less difficult) so that it would show even hidden zones whatever you include in the cartridge can be read. status of it doesn't matter. only way to work around this is not to include something. for instance, include an "encrypted" version of the data (zone points) and use some local information to "decrypt". create a zone that is offset by a specific vector from its desired location. then, ask a player to input something like a serial number of a lamp post on the starting coordinates. use that number to calculate the vector and move the zone to where it belongs.

see this: http://forums.Groundspeak.com/GC/index.php?showtopic=198305 (why didn't you google it, anyway? it's, like, the first result)

okay, for the benefit of others (and for somebody to argue with me, possibly), i'll copy my latest reply to you here. Yes, 10m across is too small. Due to how GPS works, even when you're standing in the dead center of a 10m zone, there is still something like 50% chance that it will report your position as outside. And that's with a very good signal. (plus, as i wrote before, it seems to me that when you specify the zone size in builder, it uses that size as a diagonal of the box, so 10m zone isn't even 10m across) Think of it this way: if you're standing at specific real coordinates, your reported GPS position can be anywhere within a circle with a 10m radius (!) around that position. If the spot has good signal strength, then the offset of reported against real position on that location will be roughly the same every time (provided that you use the same GPSr and the weather is good). But it can still be pretty much any point in the circle. You need zones that are at least 20m across, so that you have 99% probability of hitting when you stand in the middle (because then your circle is completely "boxed" within the zone). Of course, bigger is better. If you need to navigate to a specific point, like a geocache, your best chance is setting an item on that spot and then telling players to go find it. For zones, you usually don't need this kind of precision, so you can easily do away with 30m or bigger "places". If you want to say things like "now you're standing in front of a house", you can say that from 30m away without problem.

no, that's not it. but you have to set some checkbox in cartridge properties, something along the lines of "enable logging"

you should have file "test.gwl" in the same directory as the cartridge. also, please send me both the test.gwl and test.gwc (unless it contains some secrets. of course )

thanks for the info. yes, by "recently downloaded" i mean during the last week, and it doesn't seem to depend on cartridge, but it does seem to depend on the user. I might have isolated the problem, though: For me, the "15-digit" unlock codes always seem to have 16 characters. (example is the BMW tour in moscow, which gave me an unlock code GE3TAOBVGQYTSNZQ) When i try to unlock with this code, it fails. But when i deleted the last Q, the 15-character unlock code (GE3TAOBVGQYTSNZ) was accepted. (emulator reads 16 characters too, so this is not openwig-specific) i sent a message to the other users to confirm this

i have three people from geocaching.cz confirming it (and two other saying that they don't have problems), and when i tried, i couldn't unlock a randomly selected cartridge either. i can get usernames if that helps. i guess you can try and see for yourself?

okay, this should be interesting. please turn on logging in your cartridge, and if you do experience the OnEnter problem, send me the logs from both devices. in case the problem exist, i would love to see the logs for it. otherwise, good luck with your cartridges :e)

It's like this: There is a commonly held belief (myth) that the described problem with garmin players exists. But ever since I came to the scene year and a half ago, nobody was able to actually show me the problem. And seeing that nobody from my country ever experienced it, i firmly believe that the OnEnter problem, if there ever was such thing, doesn't exist in latest Garmin firmware. also, there are no issues with OnEnters or OnProximities on PPC devices. if you choose to use them, it will work. also, the OnEnter problem is a matter of player app, not of builder. so it's the same for earwigo and offical builder.

it seems that the new unlock codes generated in recently downloaded cartridges aren't recognized by Wherigo.com. which is a problem for openWIG players, because they can't unlock using gws files. anybody knows a workaround or solution for this?