Zugg Software :: View topic

Wanderer Joined: 17 Nov 2005 Posts: 65

I noticed the Zone Script tab and figured it's probably just for some scripting like scripting in an editor, but what I would like to see is allowance for triggers that's zone based. Is there a way of setting up triggers for only a specific zone?

Sincerely,

Dodgester

GURU Joined: 23 Dec 2000 Posts: 4834 Location: USA

That's exactly what the Zone Script tab is for. As long as your little blue dot is in that zone, all the zone triggers are active. Probably in a temporary class called _MapperZone in much the same way room scripts appear in the _MapperRoom class.

Wanderer Joined: 17 Nov 2005 Posts: 65

How I thought of the Room Scripts and Zone Scripts as scripts that's only executed just before entering into the room and zone respectively. However, if that's the case, then it's still like setting up triggers for when entering, but it doesn't do anything for when exiting the room or zone respectively. Therefore, from this stand point of view, it would be easy to enable zone stuff, but what about disabling zone stuff when leaving the zone?

Just like in Access, you have the following events that goings in the following sequence:

When an object is initially set to receive the focus on the form:

Enter Event is triggered, and the code in it is executed, if any (I use this quite often as part of my error checking process, though had to unbind all of my forms and control in order to revamp the error checking process within Access to get it more like how it's done in VB6)

If focus hasn't been shifted, then Object gets the focus, thus the GotFocus Event is triggered and if there is any code for that, then it's executed. This event is useful for setting up certain things once the object does have the focus.

Anytime there's a change that takes play on the object, the following evens takes place:

BeforeChange Event is triggered and executed for error checking purposes, if any code is in such event. This event is also part of the error checking process, but I don't really use this event so much due to the total revamp of the error checking process that I had to do.

If The Cancel property wasn't set to "True" in the BeforeChange Event code, then the Change Event is triggered and the code in it if any is executed. This event is used quite extensively within my error checking process though as it also controls the cursor stuff in certain situations.

If the Cancel property wasn't set to "True" in the BeforeChange Event code, then the AfterChange Event is triggered and the code in it if any is executed. This event is used for further setting up things similar to the GotFocus Event, but only while the contents within the control is being altered.

Once the object losses it's focus, the Exit Event is normally used for further error checking, but due to the fact this creates user friendliness issues, especially for mouse users, thus why I had to totally revamp the error checking process in Access, I only use this event for setting up certain things as part of the centralized error checking process, but nearly all objects gets the same set of codes for this event in particular.

The last event that is encountered is the LostFocus Event, which is also useful for certain other things. As I have found, certain properties on objects aren't updated until after the object has lost the focus, so this is the only event that one can use to do other manipulations that's dependent on such updated properties on the objects.

Anyhow, I realize zMUD isn't Access, but from what I see, while it has the entrance bit in it, it seems to be missing the exit part of it, unless I am just unclear about how it works within zMUD. If this is the case, then classes would be enabled when entering the zone, but then would not be disabled upon leaving the zone.

Sincerely,

Dodgester

SubAdmin Joined: 18 Nov 2001 Posts: 5182

If you have 2 zones and enter zone 2 from zone 1 then it is logical to understand you have exitted zone 1. If you have 17 zone and you enter zone 5 then it is logical to assume you have exitted one of the zones connected to zone 5. The zone scripts can include entire groups of settings and they are automatically on exitting the zone, but if you need to further do exit events then you will have to work from the entrance into the new zone and do your exit cleanup there.

Apprentice Joined: 11 Sep 2005 Posts: 124

Doesn't Zmud's Mapper do Sub-Areas (area's under other area)? How does this affect this problem?

GURU Joined: 23 Dec 2000 Posts: 4834 Location: USA

You can nest zones, yes, but programmatically they are all on the zone level. There's no SubZone level.

Wanderer Joined: 17 Nov 2005 Posts: 65

Sorry for the delay in response as I was out last weekend dealing with family stuff and of course, during the week except for summer time, my time is more or less fully booked.

I understand what you are saying, which in some ways, by using zone entrances, it may reduce the number of times you have to put in the same codes as compared to using room scripts, but it still could very easily be more than one time of the same set of codes to enter as there could be and often times are multiple zones linked to a single zone, especially those portal like moving mazes zones.

That's why I was asking about having such events type deal setup if possible so as the code only needs to be typed in one time rather than multiple times. Therefore, to be able to setup such scripts, I would also need to setup a global variable to say which zone I just came from, which then of course would need to be put into all zone scripts. If zones has something similar to the LostFocus Event of Access, then such a variable would not need to be setup and controlled from every single zone script.

Sincerely,

Dodgester

GURU Joined: 23 Dec 2000 Posts: 4834 Location: USA

That's why Zugg included 5 levels of mapper scripting:

Automapper (System|Automapper and System|AutomapperAll folders, comes standard in all non-child gaming window settings files). This is the "global" level of the mapper scripts, they are controlled solely based on what mode the mapper is currently in (ie, if in Off mode then these scripts are disabled, if in Follow mode only the Automapper folder is enabled, and if in Explore mode then both are enabled). Actual map in use is irrelevent (sort of.) If the mapper module is open, the status of these folders are unchanged until you switch modes (probably including the locked status as well).

Mapper (_Mapper and _MapperAll classes). These classes correspond to the mapper-level scripts that are specific to a given map. Also controlled based on what mode you are in, these are handy if you've broken up your really large map into manageable modules. These remain active as long as this particular map is loaded.

Zone (_Zone and _ZoneAll, or whatever actual names are used). Applies to each zone, but they don't handle exiting the zone.

Room (_MapperRoom and _MapperRoomAll). Room scripts that always activate upon entrance and existence in a room. Also do not handle exiting.

Walk. I don't recall if this is part of the Room stuff noted above, but I don't think it is. Useful for going through the room when it's not your destination (ie, searching out hidden exits).

Events would make the process easier to manage, but you can generally fake it fully already using plain aliases and the existing event aliases Zugg has for the mapper (albeit one of them is unusably buggy).

Posted: Sat Apr 01, 2006 8:05 pm

Another thing to keep in my mind is that Zugg is considering and event framework for CMUD to provide event based triggers. Depending on how that plays out.. it's not inconceivable to see mapper based events in CMUD Pro.