davidloew

Thanks for repro'ing this, I'll add it to the next release (a fix that is). David.

thanks, andy, I'll check the cab file settings. david Andy, I fixed the cab file so now the install is correct. Nothing else changes, just copy the cab to your device, uninstall and reinstall. It just had extra files to that folder you noticed, this has been fixed. David.

thanks, andy, I'll check the cab file settings. david

Yeah, that's why I used the interval. With that, I could display the remaining time to the user. FYI: Timers contain a Remaining field that you can access in your Lua code. For example: ztimerTestTimer.Remaining will return the number of seconds left on the timer. This will work nicely for a countdown timer. David.

I'll have a look at that and get a fix posted shortly. Thanks. ** UPDATE: this is now fixed in the latest install ** David.

Am I correct to assume that this resolves the issues on this thread and that the Colorado player doesn't need to be changed? GO$Rs Sorry, this got buried. That is correct, the behaviour on the Colorado is correct and the PPC now reflects that as well. David.

That's weird about the install, could be something to do with the xda. Try installing and take all of the defaults. There is nothing in the cab file that installs outside the core program files folder. I use a utility on the mio to set the Static Navigation Off. Its MMSirf from www.memory-map.com. Here's a link to a forum entry about it. Use at your own risk though: Sirf Forum Mention David

Sorry to keep coming back to you on this, but you recall I said I had reinstalled into main memory because of the duplicated Player.exe when I installed into card storage. Well, I've just noticed that it still has 2 copies of Player.exe, now both in main memory. One is in the WherigoPlayer directory and the other in the Groundspeak/Wherigo/Player directory. I'm going to try running with it set to 57600 to see if it makes any difference to the red/green bars. I thought it would only work at 4800 but it seems to connect up whatever speed I have in the config file. However, it is throwing it down here tonight so it will have to wait a while Rgds, Andy Hi Andy, it sounds like you have left over installs in various folders. I checked the cab file install and even if you specifiy the storage card, it doesn't put files there. Sometimes if you remove an install it doesn't always remove all of the files. I would uninstall everything you have (via the remove files) and then clean up all folders and then reinstall via the cab file. I don't think the 57600 will work. You could try 9600 but, I don't think this is causing the lost fix. Is this a sirf chip? If so, you can check the static navigation settings. Make sure you have that off. David.

That was my post about re-typing a numerical variable after setting it to a value; however, that is not the case here; although it is probably related to the same Builder bug. The problem you are having is that Builder is converting your variable's reference to a string. I just ran a quick test of my theory. When comparing variables that are strings, Builder will do this if your input variable is InputAnswer and the variable you want to compare is CorrectAnswer: if Wherigo.NoCaseEquals(InputAnswer,"CorrectAnswer") then If you take the quotes off, it will work when you compile it outside of builder. Otherwise, the condition is only true if the player enters "CorrectAnswer", the name of the variable. The following also works... if InputAnswer == CorrectAnswer then but I think the NoCaseEquals function does some thing else like removing the 'case' sense of the strings...i.e. uppercase and lower case so that you don't have to worry about the 'case' of the player input. WARNING WHEN LOADING these modes into Builder and then saving...(I just ttried loading things back into builder and this is what I get) if you change "if Wherigo.NoCaseEquals(InputAnswer,"CorrectAnswer") then" to "if Wherigo.NoCaseEquals(InputAnswer,CorrectAnswer) then" builder will remove the whole if statement...royally screwing up your lua file. It removes the 'if' line and the associated 'end', but leaves the 'else' If you convert it to if InputAnswer == CorrectAnswer then, builder will covert it back to if Wherigo.NoCaseEquals(InputAnswer,"CorrectAnswer") then So the best thing to do is make your changes AFTER you are all done and ready to publish. While testing, just input the "name" of the variable to get it to work for the time being. I too have just experienced the same problem. ie "if Wherigo.NoCaseEquals(InputAnswer,CorrectAnswer) then" builder will remove the whole if statement...royally screwing up your lua file. It removes the 'if' line and the associated 'end', but leaves the 'else' Oh what fun. Just confirmed that by entering variable name the If statement condition evalkuates to true. That will have to do for now. Many Thanks cache_in_pocket I'm looking into this one. I'll have a fix in our upcoming batch of updates. Thanks for looking into this. David

Hi Andy, I'm glad things are going better. As for the flashing red and green sat bars, it sounds like it's getting intermittent connections on that device via our Gps library (dll) that we use. If the gps library reports that the fix is lost, then the sat bars will go to red. This could be because the library isn't running too well on the Orbit. I'll check the company that created the library. I do agree that the 200mhz is probably the lowest of the low-ends for a .net app to run on. David.

When the Wherigo Player starts up for the first time, it will try to auto detect the gps port. This, on some devices, either never detects or simply locks up. In the latest version of the player, there is code to override this behaviour and make the system use a certain communications port. Here are the instructions: Check to see if you have a wigconfig.config file in you device's \Program Files\Groundspeak\Wherigo\Player folder. If you do, you can copy it to your desktop and change the settings there. In the file, there is a line called AutoDetectGps. It probably has a value of "True". Change that to "False". Then you'll see "BaudRate" and "CommPort" values. Here is what the whole file looks like: <configuration> <appSettings> <add key="AutoDetectGps" value="False" /> <add key="BaudRate" value="9600" /> <add key="CommPort" value="COM4:" /> <add key="CartDirectory" value="My Documents\Groundspeak\Wherigo\Cartridges" /> </appSettings> </configuration> This will cause the player to not to try to auto detect and to try to use the com port instead. To repeat, the file on your device is/should be: \Program Files\Groundspeak\Wherigo\Player\wigconfig.config If you don't have this file on your device, you can create it exactly as above with your settings and then copy it to your device to the folder mentioned above. Make sure you have the latest player program installed.

Thanks for writing this up. I'll look into it and get a fix put in for the next release. David.

Many thanks David, that's done the trick. Andy, Sorry for the problems. I'm glad that helped. About the install, we use .Cab files for installs. There's a bug with cab files in that they don't (as you know) install anywhere but the default folder as specified in the cab file. You can however, move the installation from the default folder (\Program Files\Groundspeak\Wherigo\Player) to the storage card. Also, I'm working on a change to allow pointing the Cartridges folder to anywhere. This way, you can run the application and point to the cartridges all on the storage card. Remember, though, that the shortcut on the Start menu will still point to the main memory. I'll check into the phantom storage card executable. The tutorial doesn't look at hdop, it looks at accuracy feet. This is fed to our "engine" behind the scenes from the gps. The accuracy is evaluated as > 0 and less than 150 feet. The accuracy is fed to the engine based on the HDOP Estimated Error Feet. We've found that this is generally a good value to use. I will look into it though since I've heard a few people mention this problem in the tutorial. Thanks for experimenting with your gps connection. I do the same in terms of using bluetooth or the built in gps so the settings come in handy. David.

Hi Andy, Check to see if you have a wigconfig.config file in you device's \Program Files\Groundspeak\Wherigo\Player folder. If you do, you can copy it to your desktop and change the settings there. In the file, there is a line called AutoDetectGps. It probably has a value of "True". Change that to "False". Then you'll see "BaudRate" and "CommPort" values. Here is what the whole file looks like: <configuration> <appSettings> <add key="AutoDetectGps" value="False" /> <add key="BaudRate" value="9600" /> <add key="CommPort" value="COM4:" /> <add key="CartDirectory" value="My Documents\Groundspeak\Wherigo\Cartridges" /> </appSettings> </configuration> This will cause the player to not to try to auto detect and to try to use the com port instead. To repeat, the file on your device is/should be: \Program Files\Groundspeak\Wherigo\Player\wigconfig.config If you don't have this file on your device, you can create it exactly as above with your settings and then copy it to your device. Make sure you have the latest player program installed. David.

the player interface is written specifically for a 240x320 device (namely a pocket pc, read "hardcoded!"). I will be working on a more robust interface that will do a better job of dynamically drawing the screen. Some other big things to do first though. It is on the list. David.

Hello, Thanks for the information, I did find a bug with parsing variable names that contain underscores. For now, as a workaround, please remove the underscrores in the variable name. Go into the Lua Script and rename the variable. This will work until I post a fix to the parsing. Thanks, David

Just a reminder. The Builder always writes out lua files in US settings (that means that the dates and coordinates and numbers are in the us format). The builder program will interpret these values properly, though for the regional settings of your computer. This means that eventhough you have a lua file that has a coordinate like 47.61743, it will show in the builder for your regional settings like 47,61743, or whatever settings you have. David.

I would like to see the lua file myself to see where the builder failed parsing. We've been fixing parsing errors recently so make sure you have the latest builder installed. David

can you tell me exactly what's in the if statement (variable name and string value)? We have had problems with variable naming and parsing, but, I think this has been cleared up with the latest builder. Also, make sure you have the latest builder installed. David.

This sounds like a firewall problem. Are you doing this from work? The HTTP error, especially if it's consistent is being caused by something in your connection to the internet. It's possible your firewall has some settings that are preventing our browser from executing within the builder application. David.

In regards to (i); this (according to documentation) is NOT the way Wherigo is coded. It is instead the way the PPC is behaving. According to the glossary a zone will only be displayed in 'Locations' if the visible property is set to "Visible" AND the player is within "Distance" to the zone (see above post with glossary definition). The Colorado does this as documented, but the PPC is acting as stated in (i). That's the whole issue with this thread. The PPC is showing a zone in Locations regardless of "Distance", while the Colorado is relying on BOTH settings to determine when to show a zone in Locations. True, I'm going to follow up with Garmin to verify how they've coded dealing with how to show zones. David.

I've logged the Total distance around as a bug. It should be in the distance units specified in the zone. David.

WM6 did have some problems with gps. The registry entries are different than WM5 and this messed up our Gps software. The latest player application versions work fine on WM6. David.

You should be able to access it via Player.Name. So, in a message you could do something like [[Hello, ]] .. Player.Name David.

We do have a bug in the player involving the not found cartridges. The next release will fix this. The workaround for right now is to go into the cartridges directory and rename the cartridge that is not being found. This will cause it to be found. David.