 |
MrCheviot
Novice
Joined: 02 Dec 2007
Posts: 42
|
 Posted: Sat Jan 12, 2008 5:44 am
[2.18] Recompile on variable type change
|
My mud uses color variables that, for better or worse, also use the @ like zScript. Thus, if "@Bword in blue @Rword in red" is sent to the mud, you'll see word in blue word in red.
In a script I created in ZMUD, I have variables that store these color codes, so that I can change the colors used in various public output functions:
| Code: |
#va textcol_pub "@B"
#func some_output {%concat(@textcol_pub,"some text")}
|
When converting to CMUD, I noticed that the @textcol_pub was being sub'd with @B, which itself has no value (there is no variable named "B"), so colors weren't working. I checked into it, and decided that the variable type for @textcol_pub needed to be a 'String (Literal)', not 'String (Expanded)' which was the value given on import. This solved the output issue, but raised another concern:
Changing the type the dropdown and then clicking Save did not recompile the variable. The compiled code output was the same before and after, so I had to go into each color variable, delete the letter (in this case B), and then retype it and save in order for the compiled code to be correct.
To test, create a new variable, set type to "string (expanded)", give it a value such as @B, save, check compiled code, change type, save, check compiled code - the same.
It's my opinion that choosing a new variable type and clicking Save should recompile (just seems intuitive) and should not require an edit to force a recompile. So is it just me, is this by design, or is there something I'm missing?
-Mrc |
|
|
|
|
Fang Xianfu
GURU
Joined: 26 Jan 2004
Posts: 5155
Location: United Kingdom
|
Posted: Sat Jan 12, 2008 7:56 am
|
Two things:
#var textcol_pub "@B"
creates a literal string, and that's right. You're looking for
#var textcol_pub {@B}
which creates an expanded string.
And also, check out the ANSI Colour tab in the preferences, which should hopefully solve this problem scriptlessly. |
|
|
|
|
MrCheviot
Novice
Joined: 02 Dec 2007
Posts: 42
|
Posted: Sat Jan 12, 2008 5:38 pm
|
Erp.. ah, in the example code it should've been {@B} as that's what was imported, but the literal is what I needed to get the %concat() to work properly.
I personally use color syntax, so while using %ansi(color) is an option for me, I've shared scripts with people in the past that did not like this option or have it configured, and I've just resigned myself to not using it in anything I may share (this is such a script). And for local color output I built a handy MXP color function lib, e.g. @dodgerblue(text).
At any rate, still curious about the type change -> recompile behavior...
-MrC |
|
|
|
|
charneus
Wizard
Joined: 19 Jun 2005
Posts: 1876
Location: California
|
Posted: Sat Jan 12, 2008 11:11 pm
|
I think what MrCheviot is getting to is this:
If you create a variable, such as #variable test {@R}, then realize it should have been a literal variable, so you go to Editor, find the variable, and change it to read String(literal) and click save, the variable is not recompiled. Meaning that it still won't work correctly. It's still showing
| Code: |
0000 VARREF @W <?> (class AardCharn) |
under the Compile script tab, when it should be showing:
So, in order to correct it, you have to edit the variable by deleting something, and retyping it, then clicking save. An extra step for something that should be done automatically, I think.
Charneus |
|
|
|
|
|
|
|
|
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
|
|
