[Prepopulating an input field with a "default" value]

In my Build your Own GPSr cartridge it is onerous to enter an entire coordinate string, especially in the Colorado.

 

Is there a way to pre-populate the input fields with a "default value" (e.g. the player's current location)?

 

The Colorado does this for you when you are marking a waypoint outside of a Wherigo

 

This would also be useful if the user makes a mistake that you find when parsing and checking any kind of input but just needs to change one or two characters, say. It would be nice under such circumstances to prepopulate the input field with the previous erroneous entry for them to edit

[Zones and Characters]

Just because the player can see the character doesn't mean that every action for that character has to be turned on. In the OnClick event for the character you could measure the distance from the player and turn on (enable) the Talk action if he is close enough or turn it off (disable) if he is too far away.

 

Another approach would be to have the Talk always available but test the distance when the Player tries to talk and if they are too far away give a message like "Fred is too far away to hear you right now - please move closer to him"

 

You could also experiment with making mini zones within the big zone and putting the characters in the mini zones instead.

[Function Call]

Shouldn't it be:

 

GetAllOfType('zItem')

 

rather than

 

GetAllOfType('ZItem')

 

?

[Formatting minutes part of waypoint]

You can make the code slightly shorter...

 

Thanks so much - this will be much nicer

[Formatting minutes part of waypoint]

I am not that familiar with the format strings used by the string.format function - I have currently created a rather unsatisfactory (yet working) bit of code to format the minutes part of a coordinate in the way we are used to - i.e. 00.000 (rounded to 3 decimal places with leading and trailing zeroes included)

 

Here is the code that formats the entire latitude portion as currently implemented:

 

local l = math.abs(lat)
local deg = math.floor(l)
local min = 60*(l - deg) 
local minint = math.floor(min)
local mindec = min-minint+ 0.0005
if lat < 0 then
cout = "S "
else
cout = "N "
end
cout = cout .. string.format("%2i",deg) .. [[ ]] .. string.format("%.2d",minint) .. [[.]] .. string.format("%.3i", mindec*1000)

 

I would be grateful for any suggestions for improvement as this seems rather inelegant

 

Thanks

[Build your own GPSr]

Have you ever wanted to include instructions in your cartridge to navigate to a particular set of coordinates?

 

Have people complained that they need to save the cartridge, use their GPSr to get there, and then restart the game again?

 

I have experienced this situation in play using the Colorado - either I had to save the game and later restart it, worrying that I might miss something along the way, or use a separate GPSr to navigate to a waypoint.

 

Well, I have developed a mechanism to provide the player with much of the functionality of a GPSr from right within the cartridge itself.

 

Version 0.1 of "Build your own GPS" is available for field or emulator testing at http://www.Wherigo.com/cartridge/details.a...6d-b16f48b79597

 

In this cartridge the player is given an item (a GPS !!) with which they can ask where they are, mark waypoints (i.e., where they are), create waypoints (elsewhere), navigate to waypoints, and delete unwanted waypoints. A waypoint is implemented as a very small zone that is active and visible everywhere and so appears in the "Locations" list immediately on creation or on selecting it from the "Go To" list. To conserve processor power only one such waypoint can be active and visible at any one time.

 

Please try to break it, find areas I could improve, provide other suggestions etc.

 

When I am comfortable with it I do plan to release the source code as I think it provides a useful feature for everyone and demonstrates some useful techniques.

 

I do plan to add waypoint projection and dealing with poor/no GPS reception - I anticipate a number of updates and will advise here when/if they occur

 

Thanks for your interest

[Dealing with zone boundary issues]

I would say that just programming the coordinates to change rather than creating extra larger pseudo zones would be better just in the sense that there is less burden put on the processor calculating zones which aren't actually being used.

Yes - it is certainly a more elegant programming approach although I am not certain there would be any significant overhead other than a tiny bit of memory consumption as long as the zone is never made active or visible.

 

Attached is an example of doing this. In order to get the emulator to display the effects of this approach I found it was necessary to make the zone invisible then immediately visible again as part of the OnEntry and OnExit events. This would not, of course, be necessary or desirable in a published cartridge but is a useful technique to demonstrate the behaviour.

 

Zone_Expansion___refactored.zip

[Dealing with zone boundary issues]

As I get a bit more experience with both designing and playing these cartridges I have noticed a number of problem situations that all seem to come back to having a player prematurely leaving a zone accidentally.

 

Some of these issues are:

• Items or characters disappearing
  
• Messages getting overwritten
  
• Cartridge crashes
  

I believe that many of these issues can be explained by the phenomenon of people prematurely leaving a zone. This is, of course exacerbated when the zone is small and there is flaky GPS reception - so you could "leave" the zone even without moving. You could continually leave and re-enter - and I believe that is what was happening to me today causing the cartridge I was playing to crash. (In this case, on entry I was presented with an input request that I could not cancel, and I wandered around over quite an area looking for the data to enter - I'm sure I left and re-entered a number of times). This kind of behaviour will cause OnExit and OnEntry events to fire and if they do so repeatedly all kinds of problems could arise including stack overflow, resulting in a crash (which is what I think happened to me today).

 

I had thought at first that having larger zones might fix this so in my first published cartridge I made all the zones pretty large. but I failed to account for the human nature that causes people to stop moving immediately they enter the zone, rather than moving to the middle of it (in retrospect this is obvious - they have no idea where the middle is or how big the zone is!!). I had a player lose some useful (but not vital fortunately) information because he stopped right on the boundary of a large zone. He then wondered why he couldn't see the characters that should have been (and were according to his log file) in the zone.

 

Having pondered all these situations I have come up with what I think might be a rather simple solution. It can't be completely done in the Builder, a very small amount of lua code editing is required.

 

I would appreciate people's input on its efficacy.

 

In the attached game which you can open in the builder and run in the emulator, I have created a target zone (active and visible) and, surounding it, a larger zone (inactive and invisible). On entering the target zone I simply change its boundaries to those of the larger zone, thereby giving the player much more freedom to move around and the GPS much more freedom to wander a bit without firing the OnExit event. When the player does eventually leave the (now expanded) zone, its OnExit event shrinks its boundaries back to the original size.

 

(For the programming purists, the larger zone is not actually needed, I could just have coded the coordinates by hand, but it was easier to use the builder to create it and it also makes for a better display when you run it in the emulator. I would probably refactor any code I ended up actually using in a published cartridge)

 

When you play this in the emulator you will see that the display of the zones does not change to reflect the changed boundaries but that seems to be a feature (bug?) of the emulator itself since the other behaviour (e.g. the "Item" being visible") does conform to what I would expect.

 

Try playing this moving the character in and out of the inner and the outer zones and see what you think.

 

This seems a very simple approach and I would be interested in comments.

 

I plan to test this out live with the Colorado tomorrow and if it is effective I will incorporate it into my published cache.

 

Zone_Expansion.zip

[Function Call]

... some items may not have a command named 'Drop' ...

 

I think that is where your problem lies. You probably need to figure out how to enumerate just those that do have this command.

[Releasing our old cartridges!]

 

You mean downloading the source file, right? Unfortunately, MoBot source code cannot be edited and saved in the builder. This is why you cannot download the source file.

 

Not the builder - the website.

 

The download page says

 

Not Allowed

 

You do not have access to this download.

 

I was able to get all the others ok but I am confused. You said you were releasing the source for this in your OP and there is a link on the website to download it but then you said

 

This is why you cannot download the source file.

 

Seeing the source outside the builder would be helpful too

[Releasing our old cartridges!]

This is much appreciated and very useful to help cartridge builders.

 

For some reasone the Mobot one said that I did not have access to download it, but all the others worked OK

[Process for here and geocaching.com]

Sure, the cartridge will be available before the cache, but let that be a reward for the few cachers in your area who check the new cartridge page every night.

 

If you want you could require the player to enter a code into the cartridge before it will start up. That code could be available only on the published cache's page. It would probably be polite to warn people on the Wherigo page's listing that this is the case so they don't rush out, turn on the cartridge, and find they are stuck.

[Colorado : ok with compiled version for test, but crash with published version]

We'll take a look at this!

 

Thanks J2B2 - if they are not cached in the bowels of the Wherigo website and if it would help I will happily send you the source code from the problem versions off line.

 

There is clearly a difference in the behaviour of the online complier and that embodied in the builder - given that I had been running this repeatedy in the version compiled locally with no problems and never dreamed that the online version would produce different results.

[Colorado : ok with compiled version for test, but crash with published version]

I have just encountered exactly the same symptoms with my new cache http://www.Wherigo.com/cartridge/details.a...34-a20e859b220b

 

This is exceedingly frustrating - works fine on the CO compiled locally, but compiled on the site or uploaded from the builder it crashes the CO on hitting "Play".

 

With a hint from Tequila I managed to fix the issue. It seems the CO didn't like the long introductory message that was displayed on hitting "Play". I therefore split that up into a series of shorter Dialogs and it seems to proceed fine now.

 

I wish TPTB would at least respond that they have noted this issue and intend to fix it

[Function Call]

OnItemPickUp()

 

function OnItemPickup()

 

Spot the difference (hint: check character case)

[Degrees symbol handled inconsistently]

Thanks for investigating, RF.

 

Pending any definitive solution from TPTB I think I shall just omit the character altogether since its virtual presence would be obvious to the reader - but it is a shame given the particular subject matter of the application

[CHARACTER : Make globally visible..?]

wondering what's the best way to make a character globally visible? like a tour guide that you can always turn to when you need help etc..

 

I wonder if you could make a very large active but invisible zone that covers a lot more than the playing area and put the character there. Not sure how the "zone within a zone" situation would be handled though. (Side comment - I did notice in field testing the other day that, where I accidentally had 2 zones that overlapped, the CO happily said "here" for both of them at the same time)

 

Also I wonder what the performance implications would be.

[What size and format are the icons supposed to be?]

I think it automatically resizes.

 

It doesn't seem to resize in the emulator except for the cartridge icon. Maybe it does on actual PPCs. Since it is not needed in the CO I haven't bothered to add any icons.

 

I wish TPTB would answer some of these questions that should be simple to answer instead of leaving us all, including poor old RF, to guess.

[Demo mode detection]

I just experimented with running my Wherigo that is under development in Garmin Demo mode on the CO and found that the OnEnter event for the first zone didn't fire when it zeroed out. It works fine in real (WAAS) mode.

 

Is this actually an effective trap (i.e. without resorting to this invisible zone technique) or is there something wrong with my setup?

 

Thanks for any input

[Function Call]

You can either move your calling function into the authors area as suggested in another repsonse or, if you don't want to do that, you can try creating a dummy variable ("dummy" say) and inserting the code

dummy = function()

into your builder managed function. The function will get executed and you never need to use the value of "dummy"

 

This has worked for me so far.

 

It seems that the builder assumes that functions are intended to return values rather than simply have sideeffects, thereby proving that "assume" is making an "a**" out of "u" and "me"

 

(oh isn't that bizarre - this forum replacess the two "s"s in removespaces("a s s") with stars - aren't we just so PC. I wonder what it does with "arse" - apparently nothing - good job we are not discussing zoological topics about quadripeds )

[Degrees symbol handled inconsistently]

Trying to get the degrees symbol ( ° ) to be part of a text string I find that it either displays correctly in the Colorado or in the Emulator but not both. Sometimes it displays as a square box, sometimes it is preceded by an upper case A with an accent on it, sometimes it actually displays correctly. I haven't figured out what are the deciding factors but I suspect it is some kind of endian problem or depends on whether it happens to lie on an even or odd byte or something. Given that this entire application relates to the use of data that is built around information using this symbol one would have thought that this particular symbol would have been properly handled. I have searched the archives and the minimal documentation available but can find no reference to how to properly display this symbol. Any ideas?

[Emulator check]

Sorry to be bearer of bad news, but the check for desktop is VERY easy to get around.

 

Indeed - all you have to do is to go into the .gwc file with a hex editor and change the first occurrence of the string "DeskTop" to something else. To frustrate this hack you probably need to i) choose random names for your string variables so it is hard to find the bit of code where this check is made, and ii) obfuscate (by hashing or whatever) the test string. Even that will probably not prevent the determined hacker, but then if they get more fun out of the hacking than they do out of actually doing what is intended with the cartridge that is up to them I suppose.

[Timer event]

It gets annoying when you have to zero out on small zones. As I said, I'll have to look into this again.

 

It certainly does, so thanks for checking. I am designing my game with large zones for exactly this reason. The only reason for very small zones that I can think of is in order to find a physical cache - but the way around that is to have a character provide you with exact coordinates when you enter the zone, answer a question, or something. Of course, to frustrate hackers you need to obfuscate that bit of text but that is pretty easy.

[Colorado : ok with compiled version for test, but crash with published version]

... Someone will probably respond during the work week, then. ...

 

Since this comment was posted about six work weeks ago and a response has not yet been forthcoming, one is inevitably left pondering the question "which particular work week did you have in mind?"

[Timer event]

...you currently have to zero out for Garmin Players to recognize you entered the zone. With OnProximity, you don't have that problem.

 

Are you sure about that? I have been running some field tests with the CO, changing the size of zones and observing the resultant behaviour. While the distance counter displayed on the CO seems to have to "zero out" as you suggest, I have also observed that the distance that you need to get to drop to zero appears to be calculated from your actual location to the nearest zone boundary (as you might expect) and not to the centre of the zone. IOW, if I enlarge the zone it seems to be much easier to get the OnEnter event to fire. An adjunct topic to this discussion is whether the behaviour of the attribute "Show Objects in this Zone" (when "On Enter" or "On Proximity" is selected) is governed by the same mechanism as the firing of the OnXXXXX event. Do you have any insights?