[CodeJunkie]

@cheezehead wrote:

Atlas Snowshoes @ Cabelas
Mine were around $200 with out the poles and bag. GET POLES!!

Just ordered these. I’ve been looking at these for a few days and finally made the plunge. I bought the combo (after debating about poles) which includes a carry bag and poles. With the $20 off coupon from their website and the current sale the whole package with shipping only ran me about $165.

As an avid outdoorsmen I’m hoping to also use these for hunting, getting in to cut wood, and CACHING (of course). I’ll post a followup after getting them and giving them a whirl. Of course this means I’m going to have to hope for more “craphas.”

[CodeJunkie]

@-cheeto- wrote:

Meep meep

Wasn’t this phrase coined by the Road Runner? I loved that cartoon (almost as much as this craphas).

Or was that “Beep Beep” or maybe even “Mheep Mheep” In any event why does the english language have to be so confusing. So much so that I think one of the great puzzlers has built a few puzzles in the land of Sellzup based on these confusions (i.e. Hooked on Phonics series).

[CodeJunkie]

For a whole bunch of different versions of this, do a “Google” search using the following words:
gps distance calculator

[CodeJunkie]

I believe the following website can clear up a number of Wisconsin pronounciation issues.
http://www.misspronouncer.com/
And if you watch the scenic slideshow on the homepage you’ll even see a few pictures of “craphas” including this one.

[CodeJunkie]

A little different twist, but still winter related. I did my first cache in the snow today and here are some things I learned along the way (and posted in the log). No they didn’t all happen, but some did (and I’m not telling which ones).

1) Always wear your gloves (i.e. snow is cold when it’s 5 degrees outside).
2) If you’re not wearing gloves (see #1) then make sure you don’t touch anything that’s metal (i.e. moist skin freezes instantly to the metal in this weather)
3) Caching in the snow is a little like caching in the dark (i.e. you don’t always see the hole, stick, etc. that’s going to get you)
4) Hang on to the cache (i.e. dropping the container into a foot of snow can make for an interesting day)

[CodeJunkie]

@Team Black-Cat wrote:

A=(Point1Latitude * Pi /180)

B=(Point1Longitude * Pi /180)

C=(Point2Latitude * Pi /180)

D=(Point2Latitude * Pi /180)

I assume you meant Point2Longitude for D.

[CodeJunkie]

Awesome – Congratulations.

[CodeJunkie]

@gotta run wrote:

@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()
to

function 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.)

I just tried this in a simple example and it seemed to work OK.

[CodeJunkie]

@CodeJunkie wrote:

@gotta run wrote:

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.

Not sure. Try making a copy of the LUA file (i.e. xyz_new.lua or xyz_2.lua) and then edit it manually. You could then open this one up in the builder to see what happens and your original would still be untouched.

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.

[CodeJunkie]

@Team Black-Cat wrote:

I did some serious playing around with the builder today and actually created a working cart with a few interactive characters and objects.
It’s hard to get used to scripts being synchronous. You can’t, for instince, ask for user input and use the result from that input in the same event because the script doesn’t wait for the input before continuing.
I’ve got an idea for a storyline. If it looks like something that anyone else might enjoy, I’ll create a WhereIgo cache somewhere in Wausau.

Another classic programming paradigm called “state management”. I haven’t played enough yet, but it looks like “state management” could be achieved by using variables to keep track of the state. The first example that comes to mind is using a hammer to pound a nail and it needing 3 or 4 hits to complete the task.

[CodeJunkie]

@gotta run wrote:

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.

Not sure. Try making a copy of the LUA file (i.e. xyz_new.lua or xyz_2.lua) and then edit it manually. You could then open this one up in the builder to see what happens and your original would still be untouched.

[CodeJunkie]

Just “played” with a sample from Gotta Run. Working with a real file made this a lot easier than trying to muddle through on my own.

Here’s my take as a programmer:
1) Classic object oriented architecture. Objects have properties and events that act on them.
2) The designer is very rudamentary and isn’t exactly user friendly or intuitive.
3) Simple things like double clicking in the designer don’t work like I would have expected.
4) The logic constructs are different than standard programming languages I’ve worked in.
5) Visible / Active are very normal programming constructs. I’ll have to give some more thought to how they fit within this framework though. Generally these are used in combination to make textboxes work.
Active / Visible – User can see and enter data
Inactive / Visible – User can see but not change data
Active / Invisible – Hidden field which isn’t normally used
Inactive / Invisble – Hidden field used for calculations / data storage you don’t want the user to see.
5) This is just another programming language and once a person learns the quirks it would be pretty easy to program.

Although most of my points were on the negative, I think this is a very viable programming platform. I think with a few tweaks to the designer this could be much more user friendly.

I think the key here is the same as any programming project I’ve worked on. You need to “storyboard” the project first. This includes being very specific about what can / should / should not happen. If this is well done, then the rest is just building it which just becomes working within the constraints of the development tool.

[CodeJunkie]

@gotta run wrote:

The program only does exactly what you tell it to do, not what you want it to do!

As does any programming language. As a “code junkie” this frustrates the heck out of me, because I can only blame myself when the programs I write don’t work the way they’re intended to.

@gotta run wrote:

The builder program could be a bit more intuitive for the non-technical, however. I think its interface really inhibits its usage.

My thoughts exactly (and coming from a programmers perspective) when I started playing with this a few days ago. I’m guessing once you get a handle on it, it won’t be so bad. The learning curve just seems pretty steep for something so simple. Maybe a good Whereigo 101, 102, 103, 201, 202, … is in order (if I can figure this out).

[CodeJunkie]

@Lostby7 wrote:

@gotta run wrote:

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…….. 😀

Very cool. 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.

This is right up my alley as a programmer, but I don’t have the right hardware to play them. I have a couple of emails out to get samples so I can play with real world scenarios. I think it would be fun to be a resource for these. At first blush, these are very basic “event driven” programs (in the simplest sense) and nowhere near as complex as what I do on a daily basis.

[CodeJunkie]

Technology threw us a curve ball but as Jim says – We got ‘er done.

[Author]

Posts