|
nostra Wanderer
Joined: 23 May 2001 Posts: 68 Location: Sweden
|
Posted: Mon May 26, 2003 11:45 pm
Print record variable in straight column to WIN |
Howdy,
I have made up a "dynamic" record variable that contains following:
KEY, NAME
Playername, Location
For example:
Diablo, Town
Darkstar, Rune
Zim, Keep
Yourban, Town
The "challenge": I want to "print" this list to a seperate zmud window (using the zmud command #win winname).
I want the record-list to be printed in straight columns and sorted after the KEY value (playername).
I've only found #SHOW @record_variable_name, but that doesn't help much as it produce this kind of list:
Diablo|Town|Darkstar|Rune|Zim|Keep|Yourban|Town
Indeed, after some more reading I also found #SHOWDB but I didn't manage to get it to print the values to a seperate window (using the #window {winname} {#showdb @variable_list}.
If above (printing straight columns) is not possible to achieve from a record-list I guess I have to turn to a proper database (which means going back to the drawing board for me ;)
Any input as always much appreciated! |
|
|
|
MattLofton GURU
Joined: 23 Dec 2000 Posts: 4834 Location: USA
|
Posted: Tue May 27, 2003 3:25 am |
look into the %format() function
li'l shmoe of Dragon's Gate MUD |
|
|
|
LightBulb MASTER
Joined: 28 Nov 2000 Posts: 4817 Location: USA
|
Posted: Tue May 27, 2003 5:28 am |
#WINDOW is used to display text in another window. It won't cause the child window to execute commands or evaluate functions. That's done by sending the commands with the focus character, :.
You should also note that variables, like other settings, belong to the window they're created in. They can't be easily referenced from other windows.
LightBulb
Advanced Member |
|
|
|
Kjata GURU
Joined: 10 Oct 2000 Posts: 4379 Location: USA
|
Posted: Tue May 27, 2003 12:25 pm |
As for sorting, there is no function or command to sort a record variable, but there is one for stringlists. By tricking zMUD into thinking that the record variable is a list, we can then sort it:
#VAR record_variable_name %replace(%sort(%replace(@record_variable_name, %char(29), "|")), "|", %char(29))
Kjata |
|
|
|
nostra Wanderer
Joined: 23 May 2001 Posts: 68 Location: Sweden
|
Posted: Fri Jun 06, 2003 2:05 pm |
Hey Katja,
It's working like a charm! However, if you have the time I would like to know the brief logic behind the statement (e.g., where in the string does it say that 'the first column' is sorted)...
Any comments appreciated! |
|
|
|
Kjata GURU
Joined: 10 Oct 2000 Posts: 4379 Location: USA
|
Posted: Fri Jun 06, 2003 5:53 pm |
Sure, no problem. First we take a look at the structure of a record variable. A record variable stores a group of key-value pairs in a single variable. Each key-value pair is separated from the next one by using the ASCII character 29. Next, each key is separated from it's corresponding value by using ASCII character 30.
Now, let's analyze the statement. Starting with the innermost %replace, it replaces all instances of ASCII character 29 with a |. This in effect converts the record variable into a stringlist where each item in the list is a key-value pair. The result of this is then sent to the %sort function. This function will sort the items in the stringlist in alphabetical order. Since each key-value pair starts with the key, the %sort in effect rearranges the stringlist so each key-value pair is in order according to the key (all alphabetical characters come after ASCII character 30, so the separator between keys and values presents no problem). Finally, after the list is sorted, the outermost %replace replaces each | back to ASCII character 29 converting it once more into a record variable.
Kjata |
|
|
|
nostra Wanderer
Joined: 23 May 2001 Posts: 68 Location: Sweden
|
Posted: Fri Jun 06, 2003 6:07 pm |
I'm getting the hang of Zmud scripting but at the same time I realize that despite the progress there is still so much more to discover.
Eventhough I'm a believe in "learning by doing" I think that a zmud manual for the novice with complete scripting examples would be a great learning aid. Mainly because for the zmud user with a limited programming experience probably finds zmud has a very high entry barrier when it comes to more advanced scriptbuilding.
Also, a manual would probably reduce some of the repetitive forum issues because it's easier to reference issues back to a manual and at the same time include new topics.
Zmud has been around long enough, I think it's time to write an extensive "zmud programming for dummies".
Yet, I'm amazed how supportive this forum and probably because of that there really hasn't been any call for a manual, hehe.
Kindly,
Mikael |
|
|
|
MattLofton GURU
Joined: 23 Dec 2000 Posts: 4834 Location: USA
|
Posted: Fri Jun 06, 2003 10:02 pm |
We have a manual, though I personally think it's a tad too big. We even have supplements to the manual that cover specific topics like COM.
li'l shmoe of Dragon's Gate MUD |
|
|
|
Vijilante SubAdmin
Joined: 18 Nov 2001 Posts: 5182
|
Posted: Sat Jun 07, 2003 12:45 am |
I recently revised the help and added many examples, including some more advanced larger scripts. The main barrier to making the help completely comprehensive is finding a way to present information while leaving it findable.
In general the Reference section of the help provides concise examples of usage, and highly detailed information about arguments for the command/function. The Settings, Advanced Topics, and Getting Started sections tend to have larger examples with more explanation of what is occurring and why. When Zugg wrote those sections he designed them to function as a manual and build the appropiate knowledge to use the Reference section. My revisions of those sections attempted to enhance that, but I guess it wasn't enough.
In terms of writing a totally seperate manual, I just don't think it is possible. After years of using and working with zMud, my effort to revise and update the help was continually met with me thinking, "I never knew about that syntax for command XYZ." All to often that was from an example for function abc. To create an actual zScript for dummies manual would require making examples that are extremely generic. Looking through any resonable number of posts in this forum and you will find either a Guru or an expert saying. "we need specific information to help you," quite often. That requirement alone makes it nearly a fool's errand. |
|
|
|
|
|