Current Zone

[+cache_in_pocket]

Is there a way to reference the 'current zone'? For instance, the player has an item to drop. Is there a simple way of dropping it in the current zone rather than having to if then else through all the zones in order to hit the zone the player is currently in. This would be outside of builder...I'm pretty sure builder can't do it.

 

Then the next question, how do you check that the player is in 'any zone'?

 

Thanks.

[+trenkle]

cache_in_pocket,

 

The problem with "current zone" is that it the concept doesn't exist. While it is easy to imagine a world where you are either in any one of a group of zones (or none at all), imagine a map with overlapping zones.

 

Consider a Zoo being one zone that has smaller zones for each exhibit within the zoo. In such a case, if you are at the lion exhibit, you are probably "within" both the Zoo zone AND the Lion zone. Which would be the current zone?

 

Though I've never tried it, I think your best bet would be to write a user sub-routine that checks the current location to see if it is within the bounds of a pre-defined group of zones. This should be fairly easy to do, and the function could return the "current zone" or nil otherwise.

[+cache_in_pocket]

cache_in_pocket,

 

The problem with "current zone" is that it the concept doesn't exist. While it is easy to imagine a world where you are either in any one of a group of zones (or none at all), imagine a map with overlapping zones.

 

Consider a Zoo being one zone that has smaller zones for each exhibit within the zoo. In such a case, if you are at the lion exhibit, you are probably "within" both the Zoo zone AND the Lion zone. Which would be the current zone?

 

Though I've never tried it, I think your best bet would be to write a user sub-routine that checks the current location to see if it is within the bounds of a pre-defined group of zones. This should be fairly easy to do, and the function could return the "current zone" or nil otherwise.

 

I see what you mean. And I think I can see a way to do it....just not as easy as I hoped I could make it.

 

However, on a somewhat related topic, is there a list somewhere of Wherigo variables that we can exploit? I've read about player name and altitude, and some other undocumented variables.

 

Thanks.

[+bamageek]

Are you guys saying that Wherigo supports embedded zones, ie I can be in two zones at once? How does the "You See" work? Does it show a combination of each zone?

 

If thats the case, would it be possible to have a Current Zone array, for example, "CurrentZone[0]" would be the innermost (or the last zone you enter), CurrenZone[1] the next, etc?

 

For example, if you're in the zoo zone, and you go to the lion zone and you drop a steak in CurrenZone[0], it would put it on the lion zone. Likewise, if you drop a steak in CurrentZone[1], it would put it in the zoo zone.

[Ranger Fox]

is there a list somewhere of Wherigo variables that we can exploit?

Not yet. They're working on the documentation. For now, we know whatever is leaked out.

 

If thats the case, would it be possible to have a Current Zone array, for example, "CurrentZone[0]" would be the innermost (or the last zone you enter), CurrenZone[1] the next, etc?

That's what I'd do. I'd have an attribute that would return an array, e.g. Player.CurrentZonePosition[]. Calculating the innermost zone might be difficult to do, so perhaps the first version of the code would just give you all zones the player currently occupies.

[+bamageek]

That's what I'd do. I'd have an attribute that would return an array, e.g. Player.CurrentZonePosition[]. Calculating the innermost zone might be difficult to do, so perhaps the first version of the code would just give you all zones the player currently occupies.

 

I wonder if there's an iterator or a while loop of some sort in the Wherigo scripting language? If there is it would be pretty easy to iterate through the CurrentZone instances. Or, if the array type has some sort of size attribute you could use that to get the last entry.

 

I'm looking foward to seeing the documentation. I'm betting there's a lot of functionality in there already that we don't know about.

[Ranger Fox]

If any programming language is worth its salt (or, if I wanted to be punny, I'd say "code"), it had better have the standard logic (control) structures: if, for, while, etc.

 

Lua should have a "for" loop, so you'd be able to iterate through through the array.

 

For more information, see:

http://www.lua.org/pil/4.3.html

 

And for the numeric for loop, see:

http://www.lua.org/pil/4.3.4.html

[+bamageek]

Lua should have a "for" loop, so you'd be able to iterate through through the array.

 

For more information, see:

http://www.lua.org/pil/4.3.html

 

And for the numeric for loop, see:

http://www.lua.org/pil/4.3.4.html

 

Thanks for the links. I didn't realize they were using lua. This should help tremendously. Now if I could just figure out how to get them to use Java...

 

Dave

[Ranger Fox]

I believe they're using lua because other companies have had success in using lua as a scripting language to be interpreted and run by their code. For instance, do a search for "World of Warcraft" and lua and you'll see many links. I don't play the game myself, so I can't how players can create a lua script for the game.

[+twolpert]

As others have pointed out, there is no clear concept of "current zone." Even the discussion of "nested" zones does not really cover the waterfront. For example, it's possible to have two zones A and B which are defined in such a way that the player might be in neither, in both, just in A or just in B...

 

Nonetheless, there are probably circumstances in which you might want to know what zones the player is in at the moment. It is not necessary to do anything complicated to check this. Each zone has a State property which is a string. This property takes on the values NotInRange, Distant, Proximity, Inside as the player moves toward and into the zone. It takes on those values in reverse order as the player moves out of and away from the zone. Note that the meaning of the NotInRange, Distant and Proximity values depends on the distance and proximity settings for the individual zone. I am not entirely certain how NotInRange and Distant interoperate when the distance setting for the zone is -1.

 

Note that this information probably does not get updated for inactive zones. However, I would expect it to be updated more or less immediately when you activate the zone. Pure speculation, however.

 

I have tested this behavior in the emulator. I have not tried it in the field, nor have I experimented with it for inactive zones. As always, beware of incompatibilities between the PPC and the Colorado with regard to the distance setting and visibility.

 

Lua does possess iterators. In particular, it is easy to iterate over tables, which in Lua combine the concepts of arrays, collections, and key/value dictionaries. Went back to reverse engineering to see if there's a good answer to the question. Indeed there is!

 

Player.InsideOfZones is a table-valued property which apparently contains a collection of the zones in which the player currently exists. You can easily iterate over the contents of the table using a for statement in Lua. To see how this works, open any cartridge in the emulator. Move the player into a zone. (To make it interesting, you might want to use a cartridge with overlapping zones. Don't have any like that, so my example was not as interesting as it might be.) Now, switch to the Lua Debug tab and type (or copy/paste) the following into the command box:

 

print(Player.InsideOfZones)

for k,v in pairs(Player.InsideOfZones) do print(k,v,v.Name) end;

 

Click Execute Lua Command... Something like the following will appear in the result box (where my zone is named Fred). Remember that printed output appears in the result box with the most recent output at the top.

 

1 a Zone instance Fred

table: 03602F48

 

Of course, all of this is undocumented, unsupported and may well stop working with the next release... You too can play with reverse engineering.

 

Tom

Edited March 19, 2008 by twolpert

[Ranger Fox]

As a result, the only way I know of to make use of the zonexxxx.State property is test each zone individually.

Yeah. And that's the part we don't like.

 

I wonder if we could define a variable that will hold a reference to the current zone? In each zone's enter event, the zone could put a reference to itself in the variable, so long as it's a reference and not cloning the object. On the exit event, the zone could set this reference variable equal to nothing.

 

Hmm... When I get some time, I might want to try it out.

[+twolpert]

As a result, the only way I know of to make use of the zonexxxx.State property is test each zone individually.

Yeah. And that's the part we don't like.

 

I wonder if we could define a variable that will hold a reference to the current zone? In each zone's enter event, the zone could put a reference to itself in the variable, so long as it's a reference and not cloning the object. On the exit event, the zone could set this reference variable equal to nothing.

 

Hmm... When I get some time, I might want to try it out.

 

You snuck in while I was revising the prior post. See the revised copy for something a little more clever.

 

Tom

[+twolpert]

One other piece of interesting reverse engineering. The cartidge object has a property AllZObjects. This is a list containing all the (non-variable) zobjects -- zones, media, characters, items, tasks, inputs, and the cartridge itself.

 

All zobjects are tables in Lua terms (type(zwhatever) always returns "table"). The best way I have found to tell one from the other is to use the tostring() function. Each zobject returns a string which describes the type of zobject. For example, tostring(zcharacterWhatever) returns "a ZCharacter instance".

 

To see how you can use this, open any cartridge in the emulator, start it, switch to the Lua Debug tab, and type (or copy/paste) the following into the statements box:

 

for k,v in pairs(cartYourCartridgeName.AllZObjects) do

print(k,v);

if (tostring(v) == "a Zone instance") then print("it's zone "..v.Name) else print ("it's not a zone") end;

end;

 

Be sure to replace YourCartridgeName with the name of your cartridge. If you're not sure, open the Lua for your cartridge and look for "Wherigo.ZCartridge()" (without the quotes). The name to the left of the equals sign is what you need to plug in for "cartYourCartridgeName".

 

You will see something like the following in the result box:

 

it's not a zone

0 a ZCartridge instance

it's not a zone

15 a ZInput instance

it's not a zone

14 a ZInput instance

it's not a zone

13 a ZInput instance

it's not a zone

12 a ZTask instance

it's not a zone

11 a ZTask instance

it's not a zone

10 a ZTask instance

it's not a zone

9 a ZItem instance

it's not a zone

8 a ZItem instance

it's not a zone

7 a ZCharacter instance

it's zone Herman

6 a Zone instance

it's zone Marvin

5 a Zone instance

it's zone Harvey

4 a Zone instance

it's not a zone

3 a ZMedia instance

it's not a zone

2 a ZMedia instance

it's not a zone

1 a ZMedia instance

 

Remember that the printed output appears in reverse order, so the result of the "if" test appears just above the key/value pair to which it applies. The sample output also illustrates the string values of tostring() for most of the zobject types.

 

There is also an interesting function, Player:GetActiveVisibleZones(), which returns a list of zones. However, it appears that the function name is somewhat misleading. At least with no arguments, it returns an incomplete list of active, visible zones. It appears that inclusion in the result list somehow depends on the player's proximity to the zone. Without more information on the implementation, this function is not likely to be useful. Hence the fallback to the cartxxxx.AllZObjects collection.

 

As always, use at your own risk since it's undocumented and unsupported.

 

Tom