Zugg Software :: View topic

Wanderer Joined: 02 Dec 2001 Posts: 80 Location: Canada

Im having trouble with GSL emulations after 6.62, I posted this before, but it was 7.01 and Zugg said to switch to Browser_FE emulation. (available in 7.02) I even tried wizard emulation but the GSL code for time seems to be a bit off.

Zugg quote: "1) Simutronics changed the way zMUD is supported in v7.x. zMUD used to emulate the BROWSER_FE client (their Escape Java client). Now they are treating zMUD as the "Wizard" client. From what has been reported here in the forums, the Wizard client does not receive the same RoundTime GSL tags that the BROWSER_FE client does. In 7.02, you will be able to override this and select BROWSER_FE as the client emulation again to restore these triggers."

here is an example of how bad the codes are messing up: (a script that worked 100% in 6.62)

You reach out with your senses and see dimly flickering streams of Elemental energy coursing through the area.
You can sense that there is a bit more mana to the west.
Roundtime: 10 seconds
> climb stair

...wait 9 seconds.

Should I be askin this question here, or should I be asking simutronics? (who claims to be in partnership with zMUD...:"play.net and ZuggSoft have partnered together to make DragonRealms more accessible via the Zmud client. But that's not all! Many of the features currently available in the Wizard are now available in Zmud as well. Download a beta version of this client and see it for yourself!" (their website))

Any help would be appreciated.

script:
#TRIGGER "rtTrig" {Q} {#VAR roundTime {%gsl( Q)}} "" {gsl}
#COND {q} {
#VAR worldtime {%gsl( q)}
#IF (%eval( @roundtime-@worldtime)>0) {
#VAR rt {%eval( @roundtime-@worldtime)}
#VAR maxrt {@rt}
#T+ rtAlarm
#TS (@rt+1)
}
} {gsl}

#ALARM "rtAlarm" {-1} {
#ADD rt -1
#IF (@rt=0) {#SAY ROUND TIME COMPLETE} {}
#IF (@rt<1) {#T- rtAlarm}
} "" {disable}

Posted: Thu Mar 11, 2004 7:41 pm

Have you tried looking at the actual values of the %gsl(q) and %gsl(Q) variables? Compare them to the values captured in 6.62 to see what the differences are.

I have no knowledge of how GSL codes are used in Simutronics. All zMUD does is capture what is sent to it.

One thing I can think of is that when you refer to %gsl(Q) within the "Q" trigger itself, how do you know whether this variable is already set yet or not? This is not documented. In fact, you should probably be using the %1, %2, etc variables within a GSL trigger to capture the data sent by the MUD. The %1 variable should contain the exact data sent by the MUD unparsed by zMUD. Then %2..%n contain "parsed" versions where zMUD tries to break up the data sent by the MUD into different pieces. It's possible that the new version doesn't actually update the contents of %gsl(Q) until AFTER your trigger is done, but I'm not sure without looking at the code. But it's certainly not something you should depend upon.

Also, your trigger assumes that a GSL q will come right after a GSL Q code. None of these codes are documented by Simutronics. I know that the "GSL q" code is used for the timestamp and prompt since zMUD triggers on that internally to flag a MUD prompt for the mapper.

There have been a LOT of changed between 6.62 and 7.0x. You need to start splitting your script into pieces to determine where the change occured. For example, does your alarm still work properly by itself? Or is it really the GSL trigger not computing the correct value for it?

This is the place to keep asking. You won't get any help on the Simutronics site because nobody at Simutronics has a clue on how to write zMUD triggers or even what a GSL Trigger is in zMUD. The "partnership" has nothing to do with customer support. It's a marketing partnership that allows them to promote zMUD on their site and allows me to promote Simutronics on my site and allows zMUD access to the technical documentation on how to perform the custom login procedure for their games.

Wanderer Joined: 02 Dec 2001 Posts: 80 Location: Canada

Well I got some advice from someone else with same problem, so Ill post here what they told me... Make the q and Q triggers case sensitive, so far this has worked perfectly, but Ill try segmenting my script into small pieces anyway....

So for those of you having same problem... just make your GSL triggers case sensitive I guess

--my 2 (newbie) cents worth

Posted: Fri Mar 12, 2004 7:16 pm

Hmm, GSL Triggers were already supposed to be case sensitive. That sounds like a bug so I'll add it to the bug list for a future version. Thanks for reporting this!