|
jennyA Novice
Joined: 13 Oct 2003 Posts: 31
|
Posted: Tue Oct 14, 2003 1:24 am
Object Oriented zMud Scripting |
Hi, I'm new to the world of zMud and had a few questions which I couldn't find the answers to in the FAQs, boards, and other resources I used. I'm used to taking an object oriented approach when developing applications. If wanted to break down different pieces of my application so they could become reuseable classes, how would I do that? Would the best approach be to create aliases for each function and use those? Still learning as I'm going here so this may be another stupid question, but is there a way to capture a return value from an alias (or something like it) without outputting it to the command window and capturing it with a trigger or another alias?
If there's a tutorial or post that I've missed that outlines this sort of stuff, definitely feel free to point me that way. Thanks for the help. |
|
|
|
Darker GURU
Joined: 24 Sep 2000 Posts: 1237 Location: USA
|
Posted: Tue Oct 14, 2003 1:56 am |
As far as OO concepts in zMUD script go, don't look too hard for them... They're simply not there. For the most part, zMUD Script is built on the idea of reacting step-wise to events in mud output caught by zMUD.
"Classes" in zMUD don't refer to encapsulated functionality. Instead, they're more like categories of settings that can be turned off and on.
To start achieving re-usable functionality, check out the help file for #Functions, and think in terms of aliases that modify variables (see #variable) that can be used by subsequently called aliases.
Hope this helps |
|
|
|
Vijilante SubAdmin
Joined: 18 Nov 2001 Posts: 5182
|
Posted: Tue Oct 14, 2003 2:03 am |
Last question first...best way to capture a return value is put it in a variable. All programming languages do it, but it is done behind the scenes. Here there is no cpu controlled stack that you can just push a return value onto.
Object oriented, closest thing is a class. Classes are more menat to group a number of settings together that are all used by each other; like putting the variables, triggers, and aliases in one place. There is no concept of scope. There is a vague level of inheritance, but it is better left ignored until you are proficient with zScript in general.
Even though I say there is no scope, the class character does allow you to create something resembling scope. I find simply keeping all settings names unique to be enough. |
|
|
|
StackAdder Wanderer
Joined: 30 Sep 2003 Posts: 77 Location: United Kingdom
|
Posted: Tue Oct 14, 2003 7:17 pm |
Or of course use jscript or vbscript instead of ZMud script for more OO based programming.
#function
The example in the help pages is, imho, wrong - in order to get the functionality the help page describes you need:
#FU fact {%eval(%if(%1<=1,1,%1*@fact(%eval(%1-1))))}
(or at least, that works, whether you need it or not is another matter)
then
#var fred @fact(5)
#show @fred
120 |
|
|
|
Oracle Apprentice
Joined: 29 May 2002 Posts: 121
|
Posted: Wed Oct 15, 2003 12:53 am |
I have found building your script based upon events (triggers) and then setting up your code into various aliases passing parameters back and forth by variables works great. I have taken this approach making my script to be quite efficient where I play.
I'm thoroughly pleased with Zmud and what abilities I have gotten it to do and will be a long time user for many years. |
|
|
|
jennyA Novice
Joined: 13 Oct 2003 Posts: 31
|
Posted: Thu Oct 23, 2003 8:39 pm |
Thanks for the feedback guys. Oracle, I'm actually working things out in the same manner. I've run into a few snags though. Let me see if I can explain and then maybe someone out there will have some feedback.
I've created an #ALERT trigger which runs every 5 minutes. When it fires it updates a database with certain information.
I've also got a patter matching trigger running. When the trigger matches a pattern I make several different calls to different aliases. The first is to a Global alias which sets up some parameters. Then based on different #IF statements I call several other aliases. At certain points in the aliases I create a trigger, send a command to the console (which hopefully gets the trigger to fire), and then disable the trigger. So...it becomes fairly complex.
Is this the easiest way to do things, meaning is using triggers and aliases like that the easiest way to set it up?
Edited to add - I too am VERY pleased with this product. It's one hundred times more powerful than any other interface that I've used. |
|
|
|
jennyA Novice
Joined: 13 Oct 2003 Posts: 31
|
Posted: Thu Oct 23, 2003 9:16 pm |
Another question...
In my example above I'm using triggers to call Aliases. Most of what I'm doing in those aliases is accessing a database via ADO. Would it be smarter to code the aliases which are doing the database calls/updates in VBScript and keep the other pieces in zScript? Wow, I love this client...so much flexibility. |
|
|
|
Vijilante SubAdmin
Joined: 18 Nov 2001 Posts: 5182
|
Posted: Fri Oct 24, 2003 10:56 am |
You might gain some speed by doing the DB work in VB, but the trade off is memory usage and accessibilty. The largest speed gain would be by building and 'loading' the VBscript in only one place, then simply calling into it. Read the help on #MSS, #SCRIPT, %mss, and #SS. You will see that some flush the script engine, and others add to it. The accessibilty issue is really a matter of variables, and what your doing with them. If your not using them in status bars, or button captions then it is not much of an issue.
|
|
|
|
|
|