TheHarvesters

Regarding that last bit magpet:do you have 20 zones active at the same time...? That would kill the unit for sure. I tend to have around 3 maybe 4 active zones at any time. 5 is an absolute maximum (at the moment at least). I think you can go up to about 8 or even 10 safely, but 20 would definitely be too much work for the unit. Paul.

Good post, magpet. I look forward to reading some responses from the 'officials'. I too own a Nuvi 550 and Oregon 300. I'm developing my first Wherigo cartridge at the moment I have tested using the Nuvi, and have already decided I will not attempt to make this work. The interface looks good, but the cartridge is unplayable simply because it is far far too slow. The Oregon is fast, but I have found it will crash unless you are very 'clean' with the build of the cartridge. I've kept my active zones low, and manage the screen displays very carefully. I wonder if here is any way you could prevent your cartridge from crashing on the Oregon by any kind of clean up? I don't mean to criticise your cartridge build by saying that, but from all that I have experienced and read on this topic it is very easy to make it so that things will go wrong in this way - so far, I have found ways to work around it on the Oregon.

Okay, I have now thankfully solved this... In my RandomDieRoll function I now have BOTH the following lines math.randomseed( os.time() ) DieRoll=math.random(6) previously I was just setting the seed for randomisation once in the author script - it seems this is less effective on the Oregon than in the PC emulator, just giving me a skew to the upper numbers. By resetting the seed each time the virtual die is rolled I get a good variation. Woo hoo! one step closer to finishing this thing... oh, and ... Hi Bernie! 8)

I'm using the earwigo developer, but in effect that is what I'm doing. Someone advised me that the software doesn't keep a cascade of the screens. There is only one 'slot' so-to-speak. So, if you display the main_screen this way then the prior message screen is gone. That seems to be enough to stop the unit getting 'confused' when another message is displayed. Hope it works for you too. ;o)

For completeness: I have resolved this by showing the main screen after each event instead of the message boxes. It's fairly crude, and not quite as informative for the player as I;d like, but it seems robust enough. P.S. Bernie... I know you're out there! 8p

...still can't get this work satisfactorily on my Oregon. I have the following in the Author script section: require "math" math.randomseed( os.time() ) math.random(); math.random(); math.random() -- note these extra random calls are supposed to 'clear' the not-so-very-random first few calls that happen. and a function called randomroll with the following lua script: dieroll=mat.random(6) On the emulator this works just fine, giving me (seemingly) very realistic random 'rolls' between 1 and 6. However when tested 'in the field' I just get 5, 6, 5, 6... etc. Can someone explain/help please? many thanks, Paul.

I did exactly the same thing Monique when I started my cartridge. I made every zone (15 of them) active, but not visible. Just do it the other way around and make them active/inactive as the player passes through and you wont have a problem. Paul.

Does anyone know of a way to have the unit shut down a message box (which is awaiting a button press) on a zone enter event, or timer tick event? e.g. effectily passing the message a default button press instead of one from the player? I think that would solve my problem. It seems to me its in the layering of message boxes requiring a button press response. Ideas anyone?

As per the description, but here is some detail: I have a cartridge in development where a timer is set to run away from a monster (sooo original!), but also that in the path you run down a set of four zones which trigger arrow events as they are entered. When the arrow event occurs two things happen: 1) a message is displayed instructing the player to either "jump" or "duck" (e.g. zone 1 and 2 are 'jump', zone 3 is 'duck'), with those two options as buttons. 2) another timer is set so they have to respond correctly within just 2 seconds. If either the player is too slow or presses the wrong button they get an ouch message, and the lose some points in the game. However, I am getting lock up on my device (it *IS* an oregon!), and this seems to be because a message (ouch!) is being displayed when a message ('press jump!') is already awaiting an answer. Am I right in my diagnosis? and can someone suggest a way around this please? many thanks in advance for any help you can give me on this one. Paul.

Please tell us about the faults in the group. If they're not fundamental to the philosophy of the thing, I'm always open to improvements. Well, actually... at the moment I think it's mostly me who is fault. But what I really meant to say is that it is being continually developed. Any things you wish it would do that it doesn't already will be considered and 'prioritised' it seems for inclusion in a future release. Of course the wishes have to be within reason...

If you encounter problems (or repetitive strain injury) with the Groundspeak builder, feel free to send me a mail via my profile if you want to give Earwigo a try. For completeness of this thread I should just point out that I've been using Earwigo for the past 3 days and am impressed with its intuitveness when compared to the standard builder. It's not without fault, but clearly the better of the two imo. Add to that a terrific support from Nick and others via a seperate google group. I'd encourage any of you serious about this to check it out. Of course I'll be frequently using this forum also. I just wish Groundspeak would update something. Even some ambiguous, "well be looking into that later in 2010", would suffice for now. Has that sort of statement been forthcoming?

thanks Steamtraen, that *is* very good. Apart from getting the in-app solution working for outside of the US I can't imagine anything much better!

Thankyou both. frustrating, but at least I can stop trying to fix it now. I was creating my points as you suggested, so that's all good, but doesn;t give me that flexibility that the map affords. never mind. I'm currently re-imagining one of my multi-caches as a Wherigo - not sure I'll publish it as such, but it's helping drive through the understanding - I promise you I will be back with more questions! I'm sure they'll be equally straightforward for you to answer though.

Topic title says it all really. When I try to use the create zone from map option I just get a page of signals smiling at me and a message telling me the themes 'are not available'. I can't recall the precise message, but it is a theme issue and I am away from my building machine right now. I have tried with each of the three themes, and get the same message each time. Is there anyone who could help me with this, as it would certainly make the building easier. I am UK based - could that be part of the problem? FYI, when I emulate - the map appears fine.

thanks for the comments. Getting back more specifically to the OP topic, is it the case that in a high saturation area such as... Hampshire! Wherigo is the way forward. It is one of the reasons I've been looking into it. The techie options appeal to me too, so the challenge as you put it, coupled with the greater placement opportunities will probably mean that my idea is completed as a Wherigo cache, i.e. rather than Wherigo only. It does look like fun (I shall lookinto the Spiderman one nearest my home), and will encourage others at our local meet to take a look of course. I'll be sure to post back here too, in case any of you want to make the trip.

I've been working on a cache adventure for a little while now, and think it is much better suited to a Wherigo than a multi/puzzle cache type (a lot of boxes!) However, am I likely to get more than 5 vistors if I set a Wherigo? like a previous poster said - there is a lot of effort required for this.