davidloew

i - iv is correct. that is how Wherigo is coded. As for the other notes, very good feedback. I'll make a note of this so that we can discuss here. Thanks. David.

We could do that, but, that particular call isn't supported in the compact framework (figures). The typical way, is to do it like the gps settings work. There is a config file (an xml file) that gets created if you change the settings. The folder for the cartridges could be the same thing, if you set it, it will get stored in the config file and read in when the app starts and when you do a reload carts on the main scree. The engine does not supply the cartridges, the player app does that (since it's operating system dependent). The engine draws clear lines between OS and Front-end. For example, the play sound is not implemented in the engine because to play a sound is OS dependent and the engine needs to stay OS agnostic (so it can be ported). So, pointing the cartridge file list to a storage card is very important as we move forward with many cartridges. As is supporting ascii characters above 127 for mult-languages. David.

There are other threads talking about this as well. Right now, the builder filters out ascii characters above 127. This has been logged into our bug system and we are looking at allowing these characters for messages/text and descriptions. I don't have a time frame yet for this. David.

My zone is 30 feet in size. I think I will definately increase the size and see if that makes a difference. Builder version is 2.0.4908 (3/7/08) and the player is 2.11 I believe. Khan 30 feet if very small. You need to increase the size so that your players can get into the zone. Sometimes, you'll notice that even the GPS can "wander" 30 feet. David.

It is. This mimics the colorado. I'll add this as a feature request, the ability to specify the cart folder David.

Hopefully a quick question. I have a PC running the Vista 32-bit version. Is this OS supported on the latest release? If not, are there plans to provide support? Thx! Since the builder requires .net 2.0. here is a link to the system requirements page. I would believe that it does, but I haven't tested it. .NET 2.0 System Requirements

Here's how it works with the distance, proximity and enter: Distance Range: This is the range that triggers the "When the player is within distance to a zone". So, if you create a zone with 1500 feet as the distance, the event will be triggered when you are within 1500 feet of the zone. Outside of that, there is no event you can track. In the emulator (message log tab), you will see a "NotInRange" value for this zone when you are outside of 1500 feet. If you create a zone with -1 in the distance value, the zone will always trigger a "When the player is within distance to a zone" no matter how far you are from the zone, but, until you get to the proximity distance. You will see "Zone:Distant" in the message log tab always. Proximity Range: This is more straight forward. It is the range at which the "When the player is within proximity" will trigger. Show Objects in this Zone When: If you can see the zone in the list, then you can see the objects within the zone based on this value. OnEnter means that you can only see the objects in this zone when you are in this zone ("here"). OnProximity means that you can see the objects in this zone when you are within the proximity range to a zone. Always means that the objects in the zone are always available in the you see list. Net result: You should always see zones in the location list. (I'll have to check the Colorado and check with Garmin on this issue on their devices). In the emulator and PPC player, it is coded the above way. David.

I will log this in our system so that we don't forget about this. Right now, we filter out characters above ascii 127. David.

THANK YOU for testing this. Whew! Setting up gps on devices can be a real pain. Actually, if you don'w have gps started and run the app, it should fail detection and ask you if you want to go to settings... David.

I just put a release of the Player up that, if the device detection fails, you can go to a settings screen and try the different comm ports/baud settings to try to find the gps. David.

I'm working on a fix for that. I'm bundling a few other things with it and will be doing a release of the builder and the player. David. I just put a release up for the player that will deal with the GetDeviceId() error and allow for manual settings if auto detect fails. David. Thank you, David. Any idea when the new player will be released?

It's not a huge job. Most of the core elements stay the same. The biggest pain is dealing with removing the touch screen elements. If you play a cartridge in the emulator, you'll see pretty much everything is touch screen, including custom commands for objects, back buttons etc. So, it's not trivial. Timeline? Not sure yet. By the way, I love the blackjack and I have two of them, so, I'm really looking into get Wherigo on it. David.

Animated Gifs are not supported. David

Try the bluetooth. My experience with the Tilt and the built in GPS is that it is pretty weak. You could also download some other gps software that shows the details of the signal (number of satellites and other detail info). David.

i'm running the program on my wm6 device...the att tilt. the program runs but it won't pick up the gps signal from the built in gps chip. so i'm stuck too Just to clarify. The Tilt runs Windows Mobile 6 with a touch screen, so it will run the player. The Blackjack is a Windows Mobile 5/6 smartphone and will not run the app until we port it to the Smartphone. David.

But, seriously, David, isn't there some other property we can check that tells the script a string representation of the player version or environment running the cartridge? Wouldn't the emulator application provide something specific to itself? I thought I remember seeing something to that effect in an early post, I couldn't find it. If that's the case, I feel that's what we have been looking for all along. Sorry, I didn't mean to stir the pot. I agree, we need a way to tell the engine about the environment that is running. That way, the engine can have a variable that can be used by cartridge authors to tell whether or not the player is running on a device or on a desktop. I'll put it in as a feature request. David.

Ok, ok... gotcha! Tomorrow I'll update my cart with the new check. Thanks for the note !!! Kazuma, geocaching-italia Just a note: the accuracy in the emulator right now is always 1 and the altitude is always 0. This may change in the future as we try to more accurately emulate real-world gps. David.

I'm working on a fix for that. I'm bundling a few other things with it and will be doing a release of the builder and the player. David.

I've just submitted a cartridge with that sort of protection in it. It allows you to "play" up to the end, before asking the final question. I'll be able to tell if I ever receive any complain about the game not working. Kazuma, geocaching-italia Not sure if Altitude is the most reliable way. In the emulator, the alititude is always 0. But, it is possible on the devices that altitude could always be zero (that would be bad and wouldn't say much for the device, but, I suppose it's possible). David.

parsing == narly

Thanks for your replies, Ranger Fox. I have one zone marked active and visible, and all others inactive and invisible. I set up a question to be answered on entering the active zone. I set up an input event on that question being answered and add if-then-else to see if the users input is correct (string variable matches). If there is a match, in that if-then-else script I set the current zone to be inactive and invisible and another zone to be active and visible. I only see the new zone when I exit the current zone. I see this behaviour on the simulator and on the real PDA. Regarding the second question, the effect seems to be random. Moving around slowly or quickly doesn't seem to affect whether or not I get the effect. Sometimes I don't see it at all, other times halfway through a walk through. I'm going to put a fix in the emulator that moves the player a little when an attribute changes. this will emulate the actual moving when outside. this should fix the emulator issues with things not updating until you move the icon around the map. For PPC, you have to move to make the position change. David

I can confirm this behavior as well. I had to make the zone large enough and even then, all save for one not reproducible time, I had to have it stay at zero for a few seconds, cross my fingers, and hope it registered. Being that my test cartridge was time-based (I made a Wherigo version of histryboy's "Countdown" cache), it was more than a little important this happen in a timely manner. Any way I can get the source code for this cartridge? I want to run it thru some debug scenarios. http://www.Wherigo.com/cartridge/details.a...7a-434fafb9780e Thanks, David.

This is a bug in the engine code that runs in both the emulator and the player. The engine either runs the script (and doesn't set the task attribute) or sets the task attribute not both. This has been logged and we are working on a fix for this. David.

That is exactly what my problem was. I didn't see the close button at the bottom of the Edit Online window because it was hidden behind the Windows task bar. Thank you very much for pointing this out. Builder team, this is a user interface issue that should be fixed. Noted and logged (to be fixed). Sorry for the problem. By the way, what is your screen resolution? David.

sorry, no this has not been fixed yet. it is something in the engine code and that takes a little more time to work on. I don't have a timeline yet. David.