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
geniusclown
Magician


Joined: 23 Apr 2003
Posts: 358
Location: USA

PostPosted: Thu May 15, 2003 3:32 pm   

DragonRealms: %gsl(w)
 
One of the neat features of Simu's eScape (their HTML based client) is that it has a time/weather window. I found that the %GSL(w) code contains the information that runs that window, but it also provides a lot of other information, so if I watch it in the GSL Emulation dialogue in Preferences, the codes flash too briefly for me to write down or anything. I tried setting up a trigger that would record them, so I could begin to make a log of what codes are for what, but every attempt has failed. Any suggestions?

On that same note, the same GSL code says when to make certain fonts monospaced I use Comic Sans, which is not, and when I check experience or look at tables in in-game catalogs or whatever, the lack of monospace makes them difficult to read. I've tried setting up a trigger to respond to that code (%gsl(w)="00008output class=mono/") to change the font to "monosys" using an MXP code, but zMUD doesn't register the gsl code until after the block of text has already been sent - when I set it as "#SHOW Test" instead of changing the font, the block of text appears, and the word "Test" appears after it. I even tried setting the MXP with #PRIORITY, but that also failed.

More info: I've tried the Triggers as Types Pattern and GSL. For the Value, I first set a variable as the code {pos=%gsl(w)}, then test the variable, rather than the code directly. Tests showed that it would not respond to testing the code directly, but responds too late (as described above) when testing the variable.

I will be happy to provide any other information that I've left out.

Running zMUD 6.62 under Win2k, SP3 on a 450Mhz PII with 128Mb Ram
Reply with quote
Anabasis
Wanderer


Joined: 26 Jan 2001
Posts: 74

PostPosted: Thu May 15, 2003 9:56 pm   
 
quote:
but zMUD doesn't register the gsl code until after the block of text has already been sent


Actually, Simu is sending two different mono codes on either end of the monospace blocks. A log of it looks something like this...



GSw00008[output class="mono"/]

Showing only skills with field experience.
To see all your skills, type EXP ALL

Time Development Points: 11 Favors: 10 Deaths: 2
Overall state of mind: clear
EXP HELP for more information
GSw00008[output class=""/]


Angle brackets replaced with square brackets for viewing purposes.

I noticed the weather codes as well, but I haven't played with them at all yet. I had planned to ferret them out sooner or later by running eScape and Zmud side by side, log everything, and sort through the data.

Ana
Reply with quote
geniusclown
Magician


Joined: 23 Apr 2003
Posts: 358
Location: USA

PostPosted: Thu May 15, 2003 10:15 pm   
 
Yes, that's exactly what the server sends, so that the client, such as the Wizard or eScape, will know exactly what block should be monospaced. But, zMUD won't register the code saying to start the monospace until after the block is finished.

Here's what I have: #TRIGGER {pos=%gsl( w);#IF {@pos="00008output class=mono/"} {#pri {#show TEST}}}

Here's what I get:
quote:
> exp

Circle: 8
Showing only skills with field experience.
To see all your skills, type EXP ALL
(skills listing)
Time Development Points: 5 Favors: 5 Deaths: 0
Overall state of mind: clear
TEST
>

So, if I set it to change the font when it receives the gsl code, it will change the font after the text block is received, doing utterly no good.
Reply with quote
Anabasis
Wanderer


Joined: 26 Jan 2001
Posts: 74

PostPosted: Fri May 16, 2003 2:59 pm   
 
Ah, I see what you're saying now.

I can't get your trigger to work at all, but when I wrote my own, I did encounter your problem. I couldn't get it to trigger off of GSw00008[output class="mono"/], which does flash by pretty quick but Zmud is definitely getting it. My trigger was...

#TRIGGER {w} {#IF (%gsl( w) = "00008[output class="mono"/]") {#pri {#show TEST}}} "" {gsl}


It's strange. I don't know why my trigger didn't fire anymore than yours didn't. It's not showing any syntax errors, and that is the exact value fed into the gsl variable.

Angle brackets again replaced by square brackets for display purposes.

Ana
Reply with quote
geniusclown
Magician


Joined: 23 Apr 2003
Posts: 358
Location: USA

PostPosted: Fri May 16, 2003 9:09 pm   
 
Be sure to use ~'s before the " and brackets.
Reply with quote
geniusclown
Magician


Joined: 23 Apr 2003
Posts: 358
Location: USA

PostPosted: Fri May 16, 2003 9:25 pm   
 
Be sure to use ~'s before the " and brackets.
Reply with quote
kilthan
Wanderer


Joined: 21 Jan 2003
Posts: 76

PostPosted: Fri May 16, 2003 9:37 pm   
 
The issue isn't getting the trigger to fire on the right pattern, it's why #COMMANDS will not be processed before the experience information is sent to your screen. If you just send something like "jdlks", it will come before it.
Reply with quote
geniusclown
Magician


Joined: 23 Apr 2003
Posts: 358
Location: USA

PostPosted: Fri May 16, 2003 9:54 pm   
 
I see what you mean. I didn't think to check for non-#COMMAND responses. I find it particularly odd that it won't even execute a #PRIORITY command... unless I completely misunderstand the point of having it. Anyone else have any thoughts on this?
Reply with quote
Vijilante
SubAdmin


Joined: 18 Nov 2001
Posts: 5182

PostPosted: Sat May 17, 2003 12:50 am   
 
#PRIORITY is not meant for this usage. While it should have no adverse effect, it also should not do anything in this form.

Normal zMud processing allows that a script is paused when a looping command is encountered. Script thus paused are resumed once all other triggers have a chance to fire for the same packet. The #PRI command overrides this pausing, forcing the loop to be processed immediately.

Anyhow, I can't see any problems with the script. All I can suggest is eliminate the #PRI as it shouldn't do anything.
Reply with quote
Shon
Newbie


Joined: 22 Jun 2003
Posts: 1
Location: USA

PostPosted: Sun Jun 22, 2003 7:04 am   
 
I figured out how to get it to respond to the monospace tags!

What I did was I created a trigger that would match any line using ^(%*)$ as the pattern, and disabled it by default. What the trigger does is substitute the line with one enclosed by MXP tags which change the font like this: #SUB "~<font Monotype.com 1>%1~</font>" I found that zMUD doesn't seem to like the font command spanning multiple lines anyway (always screws it up on the last line and crashes sometimes) so this works out better anyway...

Then I created a GSL Trigger on w, with this code:

Weather = %gsl( w)
#IF {@Weather = "00008output class=mono/"} {#T+ MonoSpace}
#IF {@Weather = "00008output class=/"} {#T- MonoSpace}

I don't know why it required the creation of a variable, I tried everything to get it to match from the $gsl(w) command directly with no success... maybe someone can improve on it...

But anyway, as you can see, it simply enables and disables the MonoSpace trigger... and this does not wait to happen until after the text is all received like other commands so the full monospace element is displayed IN monospace just as it should be. <G>

This is fun, I'm getting to like zMUD ^_^

--Shon
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