Zugg Software :: View topic

Wizard Joined: 26 Mar 2008 Posts: 1547

What is an expanded string used for? I'm pretty sure I understand what a literal string is, since the label "literal" is not only appropriate but clear. However, expanded can mean many things and I'm not entirely certain when I would want to use an expanded variable over a literal one.

Posted: Fri Nov 07, 2008 3:15 pm

An expanded string is surrounded by {} rather than "" (many commands make them optional, though), and variables and functions in it are expanded. For example, the argument of #say {Value is: @something} is an expanded string.

Wizard Joined: 26 Mar 2008 Posts: 1547

So it would be sent to the MUD parsed, as opposed to literally?

Edit: Also, bonus question if someone has an answer. If a trigger creates a variable because the session doesn't have it, should I keep that or should I make sure the session has the variable first?

Posted: Fri Nov 07, 2008 3:39 pm

Yes, and err... what do you mean by "the session has the variable"? If a variable doesn't exist and is given a value by a trigger or alias, it'll be created in the window where the trigger fired or the alias was typed. If that's incorrect, then yes, you'll need to remedy it, but if it doesn't matter then it's safe to leave it. Basically, if it works after the trigger's created the variable, you don't need to fix it.

Wizard Joined: 26 Mar 2008 Posts: 1547

Well, I have a lot of triggers in the DSL packets, and they tend to create variables in the main session package, which is wonderful. I tend to move them to the appropriate folder as I get the time, but I wanted to make sure this was something that was there for a reason, as opposed to something that was never deemed important enough to fix and thus unstable and unreliable.

Posted: Fri Nov 07, 2008 3:44 pm

I edited the post above after I made it, I'd confused triggers with some other types of settings.

And no, there shouldn't be anything intrinsically wrong with it, except that the variable might not be able to be seen by some things you want it to be seen by - for example, a variable that's created by a trigger in a global module will be created in a window, and thus won't be visible outside that window's package. But like I say, if it's not broke, don't fix it.

Wizard Joined: 26 Mar 2008 Posts: 1547

It's actually desirable that it creates it in that window package, since that's what separates my characters, they are all different sessions with different windows. The DSL package is the only universal one, and it only contains universal variables. Thank you for informing me.