Zugg Software :: View topic

Wanderer Joined: 24 May 2005 Posts: 71

I've got an alarm that fires every 30 seconds to collect xp info. It runs the following function:

Sorcerer Joined: 15 Apr 2011 Posts: 809

Try gagging it. BTW, you don't need all the %evals in your script, just putting parentheses around an expression is enough to evaluate it (in almost all cases), and it'll run much faster that way.

Wanderer Joined: 24 May 2005 Posts: 71

Gagging these blank lines (^$) doesn't work.

I wish there was some help document to explain the basic overview of zScript from a coder's perspective. Such as when things are evaluated, when they're not, and all the other basic properties of a coding / scripting language. I can write in several programming languages, but I've found so many inconsistencies in zScript that I've pretty much given up ever understanding when variables are expanded and when they're not, when expressions are evaluated and when they're not, etc.

I've decided the most sanity-saving approach is to force expansion everywhere when developing a new script, lest it fail because somewhere something was unexpectedly left unevaluated. Then the script can be pared down.

And "In almost all cases" are probably the four most dreaded words when coding. :P

Wizard Joined: 22 Mar 2007 Posts: 2320

There is nothing in the code you present that should be sending a CRLF to the screen. Are you certain it is coming from this code segment? Can you narrow down the specific line that is causing the CRLF? What commands do you think send a CRLF that shouldn't?

Wanderer Joined: 24 May 2005 Posts: 71

Hmm, maybe it's the alarm?

#ALARM "xpAlarm" *@period {@xpTick()} xpTracking

Sorcerer Joined: 15 Apr 2011 Posts: 809

The alarm itself firing shouldn't cause a crlf, but the xpTick function could...
EDIT: Oh wait, I guess that's the function in your original post, ignore me Embarassed

You could try putting #CALL in front of it though, in general you should never start a line with a function, you'll want to put a command like #CALL or #SHOW or #EXEC first.

Magician Joined: 23 Apr 2003 Posts: 358 Location: USA

Forgive my ignorance, but what is "%mud.xp"? I can't find it in the function reference... is it specific for your mud? That's the only line of code I can see that ~might~ cause a linefeed. You're not sending anything to the mud to get the xp sent back, right? If you are, try using #SENDRAW.

Sorcerer Joined: 15 Apr 2011 Posts: 809

%mud is a predefined variable that retrives mxp entities, comparable to %gmcp and %gsl.

Magician Joined: 23 Apr 2003 Posts: 358 Location: USA

I'm familiar with %gsl. Is it directly comparable, as in the MUD sends it whenever it updates and CMUD stores the value until it's needed (whether it is or not)? Or does the %mud function initiate communication, requesting the information and having the MUD send the requested information behind the scenes?

If the former, I'm flummoxed why there would be an extra CR, unless it's fixed using #CALL. If the latter, the LF is probably coming from the MUD with that info, and a #GAG may be in order to prevent the extra LF.

Wanderer Joined: 24 May 2005 Posts: 71

I changed the alarm definition to

#ALARM xpAlarm *@period {#CALL @xpTick()} xpTracking

removing the quotes around the name, and adding #CALL. No extra CR/LF now.

How each mud uses entities is up to the mud developers, so there is no way to be sure how any given mud updates, for example, %mud.xp. That said, my mud publishes entity updates (xp, hp, burden, etc) each time you send text to the mud, which is not necessarily when the entity values change - that is, value updates and value publication are asynchronous. I have no experience with other muds, but I imagine they use such entities similarly.

Magician Joined: 23 Apr 2003 Posts: 358 Location: USA

The important thing is that you have a solution now. =) Cheers!