Register to post in forums, or Log in to your existing account
 

Play RetroMUD
Post new topic  Reply to topic     Home » Forums » zMUD General Discussion
jennyA
Novice


Joined: 13 Oct 2003
Posts: 31

PostPosted: 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.
Reply with quote
Darker
GURU


Joined: 24 Sep 2000
Posts: 1237
Location: USA

PostPosted: 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
Reply with quote
Vijilante
SubAdmin


Joined: 18 Nov 2001
Posts: 5182

PostPosted: 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.
Reply with quote
StackAdder
Wanderer


Joined: 30 Sep 2003
Posts: 77
Location: United Kingdom

PostPosted: 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
Reply with quote
Oracle
Apprentice


Joined: 29 May 2002
Posts: 121

PostPosted: 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.
Reply with quote
jennyA
Novice


Joined: 13 Oct 2003
Posts: 31

PostPosted: 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.
Reply with quote
jennyA
Novice


Joined: 13 Oct 2003
Posts: 31

PostPosted: 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.
Reply with quote
Vijilante
SubAdmin


Joined: 18 Nov 2001
Posts: 5182

PostPosted: 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.
Reply with quote
Display posts from previous:   
Post new topic   Reply to topic     Home » Forums » zMUD General Discussion All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

© 2009 Zugg Software. Hosted by Wolfpaw.net