Wherigo Builders’ Forum

[CodeJunkieParticipant]

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.

[Team Black-CatParticipant]

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.

Hmmm… In Wausau it might have to be another canoe cache. 😈

[gotta runParticipant]

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

[CodeJunkieParticipant]

@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.

[CodeJunkieParticipant]

@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.

[CodeJunkieParticipant]

@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.

[gotta runParticipant]

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

On the Left Side of the Road...

[CodeJunkieParticipant]

@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.

[gotta runParticipant]

It worked this time. 😕

On the Left Side of the Road...

[sandlandersParticipant]

@cheezehead wrote:

YUP!! I understand EVERYTHING you guys just said…… 😯 😯 😯 😯 😕 😕 😕 🙄 🙄 😉 ❓ ❓

Ditto for this page, too.

[Author]

Posts