Forum Replies Created
-
AuthorPosts
-
I would not disable a cache for a particular season of weather. By doing so you’re essentially taking on greater responsibility for the safety of the cacher–now it’s ok to hunt, now it’s not ok to hunt. Seems to be a much greater chance of someone claiming “well you said it was ok now” if something goes wrong.
On the Left Side of the Road...@Lostby7 wrote:
Ouch does my back hurt. I’m not sure if that is snow out there or lead. It took me almost three times as long to dig my way out….and practically everyone at work has called in so far…oh and the lot is NOT plowed. Oh joy how I love winter…..
No problems on my 14-step commute to my home office. 😛
On the Left Side of the Road...It worked this time. 😕
On the Left Side of the Road...@CodeJunkie wrote:
I took a few minutes to look at the file format and it appears to be standard text. Manual edits should work fine. I was concerned there may be some kind of checksum or other “tracker” in the file to ensure it’s integrity, but I’m not seeing anything.
I’m not sure if this works to edit outside the builder. I think the builder may be including some additional data/variables when it compiles the .lua file into a playable cartridge. This would also seem to be indicated by the warning line “don’t edit anything beyond here because it will be overwritten by the builder.”
Specifically, I have a line in this cartridge that reads:
function zoneParkPavillion:OnProximity()
There is no variable there, nor is one shown (20 feet) elsewhere in the code. So where does the value come from in the final cartridge?Anyway, I tried to change the function:
function zoneParkPavillion:OnEnter()
tofunction zoneParkPavillion:OnProximity()
but that didn’t work, at least when I opened it in the builder. Now it simply treats the command as if it’s not there. So it looks like I’ll have to manually rebuild all my “onenter” comands to be “onproximity” commands in the builder, in order to help improve the playability of the game. (Again, this gets back to the bug that it doesn’t matter how big you make the actual zone itself; you have to reach the EXACT coordinates to fire the task if you use an onenter command.)
On the Left Side of the Road...What’s the possibility of using notepad to make basic changes to the lua file and bypass the builder?
I have a whole set of scripts that I’d like to change from an “on enter zone” to “on proximity zone” and I don’t want to rebuild them in the builder. But neither do I want to bodge things up by tinkering with the code.
On the Left Side of the Road...Yeeee Haaaaaaaaaaaaaaaaaa!
On the Left Side of the Road...@AstroD-Team wrote:
It would be neat to get something together to show off some historic areas of Green Bay though.
I can only code so fast….
On the Left Side of the Road...@-cheeto- wrote:
sounds fun in a dorky kind of way just like geocaching.
What do you mean? You wander around staring at a little screen, press buttons pretending to interact with invisible people, pretending to pick up nonexistent items, and completing imaginary tasks. Then you go sign a slip of paper in a piece of Tupperware in a bush somewhere. Nothing dorky about it. Now please excuse me because I have a comic book convention to get to before the Star Trek marathon starts.
On the Left Side of the Road...8) x 400!
On the Left Side of the Road...@Team Deejay wrote:
When they received a collective yawn from these folks (again, due to the lack of hardware options), I think they have moved on to other projects (such as the Iphone app).
Yes, when you mentioned that apparently the player will NOT be part of the next generation of Garmins, that is not good news for these.
I could see Wherigo caches going the way of Project APE caches.
Which is too bad because they are now finally starting to be developed!
On the Left Side of the Road...@Team Black-Cat wrote:
There seems to be only a few caviats to pay attention to when building for the Garmins. For one, it seems that you have to make your trigger “zone” big enough or the player treats it like a point.
This is a problem that required a workaround. I originally created all the zones based on a center point with a reasonably wide radius–say, 30 feet–and set tasks to fire “on enter” into the zone. However, the on enter task only fires when the exact coordinates of the center point were reached, regardless of how big I made the zone.
Therefore, you have to use a “When player is in proximity to zone” command, rather than “When a player enters zone” command, and set the proximity to the radius you want. Then it works fine–but it’s not intutitive.
Also, the OnClick event is not handled at all.
Yes, I learned this one the hard way. 😡 Something else that works in the emulator and not in the real world. Thanks to Lionsfan for the workaround on this one.
On the Left Side of the Road...@Lostby7 wrote:
I gave up trying on my third attempt at creation…they all worked but none of them the way I wanted them to work. They sure are fun to play though. I just wish the method of creation wasn’t so complex.
It makes you appreciate how complex the human intellect is when you try to program some of these tasks, which are actually quite rudimentary as far as gaming programs go. The program only does exactly what you tell it to do, not what you want it to do!
The builder program could be a bit more intuitive for the non-technical, however. I think its interface really inhibits its usage.
On the Left Side of the Road...Key learnings:
Having developed 2 cartridges thus far, I’ve learned a few important things.
-The learning curve for the builder is steep, at least for someone with no programming experience. 😯
-Success in the builder/emulator is no guarantee things are going to work in the field. 😡
-The design software is beta (alpha?) and is buggy. Building certain tasks, particularly “take,” require workarounds. 😕
-Wherigo players, at least on the Garmin Oregon, lock up. For no apparent reason. A LOT. 👿
-Unless you build it the right way, it is possible for someone to play a Wherigo cartridge at their desk using the emulator–i.e., without being on site. 🙁 If a true “field solve” is imprortant to you, you have to build one or more tests or locks into your cartridge (too detailed to explain here).
On the Left Side of the Road...There will (or at least should) be another Wherigo in Green Bay by end of week–a walking tour of riverfront artwork. The emulator likes it as does the Oregon, and I have a guinea pig testing it on a pocket PC, so stay tuned…….. 😀
On the Left Side of the Road...I think that attribute is a red herring on that one.
On the Left Side of the Road... -
AuthorPosts
