Zugg Software :: View topic

Newbie Joined: 27 Aug 2006 Posts: 4

I feel like slightly less of a n00b now, I have managed to get my map up and running, and have worked out how to set triggers to automatically move to a new waypoint on the map when I parse the command. I am now trying to auto set the recall point to the waypoint I have moved to, thus:

#TRIGGER {way 6} {#TE 1230 Southern Road} {#MENU Windows|AutoMapper} {#MENU Actions|Set Recall Location}

unfortunately this is not working. I can vaguely see why, as the second menu command is trying to be invoked inside the mapper, which it doesnt want to do. Anyone know a good workaround?

ps sorry to repost this, but I dont know whether my question has dropped off everyone's To Read list, as I just edited a post from yesterday. I would remove my old post, but that doesn't appear to be possible.

- Spigot

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

Actually, neither of the menu commands should be trying to get invoked. They are nowhere near the executed code section of the trigger syntax.

1)#TELEPORT is useless without the mapper open.

2)Only the second #MENU is needed (if the automapper isn't open, it's useless)

Newbie Joined: 27 Aug 2006 Posts: 4

Heh, thanks, i did say i felt like less of a noob, i am quite clearly still a total idiot, it was creating a class of #MENU with a subclass of something else, i quite obviously wanted the whole execution of the trigger to be in the first set of curly brackets:

#TRIGGER {way 6} {#TE 1230 Southern Road;#MENU Actions|Set Recall Location}

1) The #TE works fine.

2) I understand what you are saying about the mapper needing to be open, it is, but the #MENU function is still doing nothing.

3) Please explain as you would to an idiot, I have only been doing this two days, and am quite clearly not with it yet, I still don't even vaguely understand what a class is for, or why you would use one... but I'll get there in the end, I'm trying to use this task as a sort of general learning excercise, but am not having much luck, every time I go and read through the manual it is either too simplified to be useful, so way out of my league that my brain hurts, or just a long list with no examples... some human help would be greatly appreciated.

- Spigot

Novice Joined: 14 Aug 2006 Posts: 34 Location: Sweden

Classes are used to group things together for 3 different purposes (as I see it, there may be more)

1. resolving otherwise ambigous names
Consider a case where you want scripts to handle both autocasting spells to keep you buffed as well as to just keep casting spells to get better with them until you max out your skill. For both purposes you want a variable called "nextSpell". But, you also want to be able to run both scripts at the same time, so even if you're adepting shield, you still want the autocast script to recast fly if it runs out.
One option would be to rename the "nextSpell" variable to "nextAutoSpell" in one case and "nextAdeptSpell" in the other.

You could however also chuck all the of the autocast script into a class called "AutoCast" and the practice spell script into a class called "AdeptCast".
Now, the variables would be referred to as /AutoCast/nextSpell and /AdeptCast/nextSpell.

2. Keeping things from becoming one giant mess where you can no longer find what you're looking for.
Let's say you have 50 triggers, 50 aliases and 50 variables, all stored in the same place. It would get kind of hard to find a specific item in there.
If you instead partition everything into separate class as you see fit, you may end up with 10 classes holding only 5 each of aliases, variables and triggers.

3. Ease of enabling/disabling stuff.
Rclick a class, lclick enable which toggles the class on or off.
Use #t+ classname and #t- classname to turn an entire class on or off.