matejcik

basically, "no they don't". problem is, geocachers as Wherigo's largest audience are so used to zeroing in on things that they get confused with zone navigation. the arrow points towards the closest coordinate of the zone's border, the geocacher walks toward this zero and then she stops there, standing right on the zone's edge and dropping in and out. (now if you have solid evidence that the problem is something else, i would LOVE to see it - in the form of, let's say, two different GWL logs from the same cartridge, where the entry and exit points are at the same physical coordinate. but despite asking repeatedly, nobody was able to provide this, and i have much evidence that i'm in fact right with this) there are two ways around this - one is using proximity (this is also an answer to your other thread), other is hiding the zone and making them walk towards a) a physical object or an in-game object placed in the middle of a zone. if you set up a proximity range (let's make it 20m in your case, with 1m wide zone) and use OnProximity instead of OnEnter, the problem is sidestepped - our geocacher happily walks into the proximity range when hunting the zero, and because the events fire right away, she never actually needs to reach the zone shape. in this case, you can use OnDistant event instead of OnExit, like this: 1. set up a variable "zoneentered" or something. set its value to 0 2. in your OnProximity script, set "zoneentered" to 1 3. in OnDistance, check whether "zoneentered" is 1, and if it is, do whatever you wanted to do in the OnExit handler. then, reset "zoneentered" back to 0 if you say "walk towards that tree over there", they stop relying on the arrow and walk towards the middle of your zone without problems. similarly, if you say "walk towards this tree in You See list", they use the tree's arrow for navigation, and that points to a specific coordinates well inside the zone shape hope this helps

if you are trying to set up zones of about 20m, just set up a 20m zone, nothing complicated about that. you don't actually need proximity unless you have a specific "proximity distance" action in mind, so 1m proximity doesn't make much sense

OnEnter works on garmins just fine. so does OnExit. the "onenter does not work" is a myth.

maybe you can use a TCP redirector instead of different JVMs? First, download the software called GPSPort. Run it, select your COM port and pick a TCP port number. Keep it running and start OpenWIG. Go to Options, select "TCP socket" as GPS type, then click "Choose..." below the GPS box, and enter the TCP port number from GPSPort. Finally, click Save. Afterwards, from the main menu go to "GPS" and click "Connect". Confirm any permission requests and soon you should see your GPS data.

JBed is good - but you might need a newer version or you might read the "GPS workarounds" part

hi, you are doing it wrong. (don't worry, many people do ) i have written a guide to run openwig on WM phones: http://code.google.com/p/openwig/wiki/WindowsMobile

1. you can create "played" log without actually unlocking the cartridge. the website doesn't check this, nor can you see which cartridges you unlocked, nor can the cartridge author see who unlocked his cartridge. yes, this is pretty dumb if you insist on unlocking... 2. you should have received the completion code when playing the cartridge. if you didn't, the author of the cartridge probably didn't implement this feature - ask him to do so if you did receive the completion code but didn't write it down, chances are you can find it listed in the GWL file 3. finally, as a last resort, you could open the GWC file in notepad and look for the completion code - it's a string of 15 uppercase letters or numbers this is one of Wherigo's open secrets yes, this is pretty stupid too, but the fact is that there aren't many better ways to implement this without the possibility of cheating anyway

Lua does, it's just Wherigo.com services that struggle with it...

well some of us are solo dancers ;e)

except that in this case that person is a really lousy dancer and a sloppy kisser and you'd be better of if somebody else took you to the dance in the first place ;e))

you have to enable the other player first. i didn't think about disconnecting later, that could certainly be added if it seemed necessary it's much harder to do proximity detection with wi-fi, bluetooth is designed for it.if we're considering internet, the protocol would probably have to be somewhat different. sure, this is no problem. this protocol works only with new events that will not be started on garmin, so the new code will not run and everything will stay as before.of course, if you need more players to complete one cartridge, it will be impossible on garmin. but the cartridge will work.

well, somewhat bigger scale, probably yes. longer range, probably not. but blah blah, bluetooth it is for now, at least for this experiment ;e) what i'd like to know, do you see anything in particular that is missing from the draft? some functionality that is important but i overlooked it?

i found that too... apparently, i need to sign my code with RIM's keys which are $20 apiece. that is very affordable (considering that regular J2ME signing keys are $500 per year), so i might just buy them. on the other hand, i have no idea about how to set up the signing environment for blackberry etc etc ... i'm doing all my development for J2ME phones, the fact that the app works on blackberries is a lucky coincidence ;e) so, i'm not going to do anything about it for now, except for removing the killer error (you will not be able to use the internal GPS, but you will be able to run openwig with a bluetooth dongle, for example) and when i have enough time on my hands, i'll try to look into it if, on the other hand, you knew a person who does some blackberry development, ask them for help, they might fix this much quicker than i ever could ;e)

and, does your BB come from Verizon, by any chance?

weellllllll, now this is interesting. "GPS not allowed." say, when you set the Internal GPS for the first time, did you have to confirm some permissions? maybe the confirmation dialog cannot show because there is nothing visible on screen at that time...?

yeah, well, the million dollar question is: what error was it this time?

sure, sure .e) that was the first thing i came up with. for some usecases yes, it even has its advantages - you have to be physically close to the other player, so if he's a cheater, you can punch him in the nose more easily ;e)for others, not so much - e.g. if there was only one item of a kind in the cartridge, there is no good way to check which player picked it up first, unless they are travelling together but the big advantage of BT is that it is simple to implement, does not require any kind of server and works in areas without cell/wifi coverage 5. one more thing the remote players should probably be shown in "You see" list. it should be possible to use them as regular Character objects - i.e. assign description, media, commands. there should probably be a library function that would "copy" a selected character object's properties onto the RemotePlayer instance - so that if the other player chose to be a girl, you could display his character as a girl etc.

A rough draft of what i came up with recently. I have an implementation in mind, but i can't promise any kind of timeline. This would, of course, only work in OpenWIG, and only on devices with functioning Bluetooth support (so many WinMobile smartphones are out), and of course limited by the number of simultaneous BT connections the device can handle (remember that in many cases the GPS will eat one) so without further ado: The Multi-Player API. 1. mode of operation When enabled, your device would periodically scan its surroundings for other devices like it. If it found one, it would establish a connection, exchange greetings, showed some confirmation dialogs to users and then create link objects in Lua. Lua code could then pass and receive messages, in the form of method calls: each new player would represent a new source of events and a new object to manipulate. The object would allow you to query the other player's nickname, GUID of their cartridge (two cartridges could be made to cooperate with each other - much like Pokémon Gold/Silver) and connection status (in range/out of range) 2. the API core of the api is a new object class: openwig.RemotePlayer it has the following properties: Name - the nickname of geocacher who downloaded the cartridge CartridgeID - the GUID of the cartridge CartridgeName - the regular name of the cartridge CartridgeVersion - the end of the world as we know it InRange - true/false property indicating whether the connection to this player still exists and one method: Send(nameOfMessage, parameter) - nameOfMessage must be a simple alphanumeric string, this will be the name of event on the other side - parameter can be a string, number, true/false, boolean, Lua table or nil. this might possibly include object references (passed only as IDs - basically indexes into AllZObjects table), but i am still not sure about how good idea this is. returns True if the message was successfully sent, or False if sending failed (probably the other side disconnected or went out of range) if you try to send a message while the other player is out of range, you get False. it is your responsibility to make sure that the message is re-sent later. getting True does not mean that the remote side processed the message or that it even supports it. ZCartridge object gets two new events: OnPlayerInRange(openwig.RemotePlayer), OnPlayerOutOfRange(openwig.RemotePlayer) Player object gets new events, each for every supported message. same as with Commands: OnWeirdMessage(openwig.RemotePlayer, parameter) is called when a remote player represented by the RemotePlayer variable sends a message named "WeirdMessage" 3. possible usage a simple game of cards: one player deals, others receive. the dealer sends "Deal" messages with "cardname" as parameter - this unit makes sure that every player has different cards individual players can then send "Play" messages with "cardname" as parameter back to the dealer, and dealer resends "CardPlayed" with {"playername","cardname"} to every other player two-cartridge cooperation: each player has a different version of cartridge. each must pick up an item that the other requires to complete. then they meet in a designated zone and swap completion messages 4. comments, questions?

no, but you can do something equally good: - create a big zone (at least 50m diameter) around the cache - create an item called "Cache", place it into this zone, and move it to specific coordinates of the cache. then when the players arrives at the cache zone, they will see a "Cache" in "You see", and the "Cache" will have an arrow pointing to the specific point. but of course! create a Countdown timer. on Timer Tick, show the message. on Exit of the zone, start the timer

ah, but that's not what i meant. perhaps i phrased it wrong, the "thinking in terms of code" is part of it. the problem is not "what role does the other player take". that is easy enough. the problem is that you have two players with two instances of the same code supposedly interacting within that code. the second player is not just another object, she's a few levels above that. for one, you cannot track other player's activities, you have to rely on what they send to you. you can only, say, pass some messages, that would map to lua calls.... waitaminute...... now i'm very, VERY tempted to try and implement this as a new API in OpenWIG 1. search bluetooth devices 2. link 3. introduce 4. synchronize 5. pass messages 6. ??? 7. PROFIT!

ah, well. try this (OTA): http://raketa.140.cz/openwig/openwig-bb2.jad http://raketa.140.cz/openwig/openwig-bb2.jar it might crash again, but hopefully with a different error

this sounds neat in theory, but it would be extremely difficult for cartridge makers. how would you code interaction of two players, for example? just think about it - not necessarily in terms of code, but in terms of "what does it even mean, having another player in my cartridge?"

BlackBerry folk, please try this build: http://raketa.140.cz/openwig/openwig-bbgps.zip for OTA: http://raketa.140.cz/openwig/openwig-bbgps.jad http://raketa.140.cz/openwig/openwig-bbgps.jar the gps problems should (theoretically) be gone

BlackBerry folk, please try this build: http://raketa.140.cz/openwig/openwig-bbgps.zip for OTA: http://raketa.140.cz/openwig/openwig-bbgps.jad http://raketa.140.cz/openwig/openwig-bbgps.jar the gps problems should (theoretically) be gone

BlackBerry folks! please test this: http://raketa.140.cz/openwig/openwig-bbgps.zip for OTA: http://raketa.140.cz/openwig/openwig-bbgps.jad http://raketa.140.cz/openwig/openwig-bbgps.jar the GPS problems should, in theory, be gone also, Adrenalynn, i discovered the cause of your missing dialog problem. i'll try to squeeze the solution into the next version