XML world file format

Posted by Magnum on Wed 08 May 2002 07:18 AM — 16 posts, 63,466 views.

Magnum Canada Wed 08 May 2002 07:18 AM #0

In the back of my head, I've been wondering if I should sort my files even further than I currently do:

I keep a different subdirectory for each world, all stored under a central mushclient directory, which in turn is stored in my personal directory where all user files go.

E:\User\Magnum\MUSH Client\Worlds\Ages of Despair\

I'm wondering if I should create yet another series of subdirectories to append to that path, each one for a different character on that world. I currently only use one character per world, so it's not a rush decision...

I would want to share the script, and almost everything in the world file between characters (except login name & password, of course), but I would want logs to go in the proper subdir, as well as some other files created by my scripts. Variables should also be custom to the character... Oh, timers too.

It's too bad you don't have "World files" and "Character files" as two different entities... the Character file creating unique info, but inheriting settings from the World file... This would be ideal for people who use multiple characters at the same time.

...I suppose it would also require a major overhaul to the scripting language support too though, since you would have to distinguish between Character objects, as well, or instead of World objects.

Like I said, I don't have need for this yet... I guess the workaround is to clone the world file for each character, but as aliases/triggers are added, they must manually be copied to each character's world file.

Nick Gammon Australia Forum Administrator Wed 08 May 2002 07:49 AM #1

You raise an interesting and highly relevant point, as it turns out. :)

I am in the process of designing the XML interface for world files, and this would be a good point to consider this whole cloning issue.

Without going into the exact syntax of the new world files, maybe something like this would be very useful ...



<triggers>
  <trigger name="myname" regularexpression="1"
     match="^(.*) attacks you" enabled="1">
      <send> kick %1 </send>
   </trigger>

<!-- now get some default triggers which I always use -->

<include name="c:\mushclient\mytriggers.mct" />

<!--  and some experimental ones -->

<include name="c:\mushclient\othertriggers.mct" />

</triggers>

You see the idea would be to let you mix standard triggers with ones specific to the world. The general idea could be extended to all aspects (aliases, timers, macros, etc.)

Magnum Canada Wed 08 May 2002 06:50 PM #2

If I get the gist of that correctly, then it would be fantastic, as I could create "plugin" scripts with "plugin" triggers, aliases, timers, etc.

I wouldn't have to go through the tedious process of writing many "World.AddTrigger" lines, and asking the user to run an install. The script would be shorter without all of that.

Also, I could keep all autowalk aliases in a seperate file. Those are usually deemed classified by mud operators, as giving them away is a form of illegal info sharing. (Easier to keep secure in a seperate file - or give away!).

A few things would be handy to go with this:

The ability to grab the user name from the login settings:
- within a script file
- on the log setup page

If it's already possible, I don't know how.


Sub SomethingorOther
  If World.UserName = "Magnum" Then World.Note "say The king is here."
End Sub

In the log setup screen. As well as being able to use all those date functions/variables, it would be great to be able to have a %Username one.


E:\User\Magnum\MUSH Client\Worlds\Merentha\%Username\Merentha Log (%Username) %Y-%m-%d %a.html

I think these knew ideas open up a plethora of possibilites. Exciting!

Nick Gammon Australia Forum Administrator Wed 08 May 2002 09:26 PM #3

Yes, I think it allows much more flexibility. Maybe even something like this:



<copy "myfile" replacing "--username--" with "Magnum">

That could be handy!

Also, maybe it would be nice to imbed scripts into the world file. Could be fiddly to implement, but something like this ...


<trigger match="blah" label="mytrigger" script="onblah">
 <send>emote sighs</send>
 <script>
   sub onblah (a, b, c)
     world.note "script called"
   end sub
 </script>
</trigger>

The only way I can see this working (from the scripting point of view) is for all script snippets to be concatenated internally into one big script, and then that passed to the script routine.

One obvious drawback would be that the line numbers reported in error messages would be wrong, because they would represent the line number in the concatenated script file, not the snippet.

Nick Gammon Australia Forum Administrator Wed 08 May 2002 10:21 PM #4

Quote:

The ability to grab the user name from the login settings:
- within a script file

You can do that now with:



world.getinfo (3)

Shadowfyr USA Thu 09 May 2002 12:09 AM #5

>Also, maybe it would be nice to imbed scripts into the world file. Could be fiddly to implement...

Definitely. But line numbers will not correctly match in some cases anyway. Adding REM or ' to put in notes results in the script engine 'skipping' those lines and misreporting the error location. This is a symptom of the fact that most scripting languages assume that you are using them in a browser where you can only have essentially one 'sub' in any real sense. Some other languages had similar IDE glitches when first implimented. As long as the script where concatinated at the 'end' of the file and you made it necessary to start them with an _ there is unlikely to be a major problem. Now why _? Because they are external to the main script and thus 'could' cause confusion or even name collisions. A similar arguement has been made recently with POVRay, where including a file with some needed script code could accidentally cause a collision between user defined data and an unused part of the included script (very likely in some cases). It is generally a good idea to prevent these kinds of accidents from the beginning, rather than hope that it never comes up. ;)

Otherwise it is a good idea and one could even add a script to the world file in that way that would, on loading the world, read a series of filenames from a 'plugin' directory, load each of the scripts it found 'and' execute their install scripts (creating all the needed triggers, etc.). The suggested convention being: Scriptname_inst(), where Scriptname is the same as the file being loaded. The only better way to do this is to have some way to override existing installer(s) and use the one from the file that was just loaded, but the scripting engines don't support that.

Kalahn United Kingdom Thu 09 May 2002 06:59 PM #6

Just wondering if:


<triggers>
  <trigger name="myname" regularexpression="1"
     match="^(.*) attacks you" enabled="1">
      <send> kick %1 </send>
   </trigger>
</triggers>

<!-- now get some default triggers which I always use -->
<include name="c:\mushclient\mytriggers.mct" />

<!--  and some experimental ones -->
<include name="c:\mushclient\othertriggers.mct" />

Makes more sense than:


<triggers>
  <trigger name="myname" regularexpression="1"
     match="^(.*) attacks you" enabled="1">
      <send> kick %1 </send>
   </trigger>

   <!-- now get some default triggers which I always use -->
   <include name="c:\mushclient\mytriggers.mct" />

   <!--  and some experimental ones -->
   <include name="c:\mushclient\othertriggers.mct" />
</triggers>

From the point of view, that an include file might contain more than just triggers. Then again, if <include ...> is supported anywhere in the world file than this would automatically be supported.

I also assume the format will allow multiple sections of the same name.

How will it handle included info which changes info defined within the world file itself? Or even two files included one after the other with the same trigger but a different action. Do you want to implement it with some concept of scope?

You have in the world file itself, then included files, then client wide settings stored in the client xml settings file, then settings stored in the registry. I am in favour of removing the need to store info in the registry because it allows Mushclient to run on a single floppy at universities etc.

- Kal

Shadowfyr USA Thu 09 May 2002 09:16 PM #7

>How will it handle included info which changes info defined
>within the world file itself? Or even two files included one
>after the other with the same trigger but a different
>action. Do you want to implement it with some concept of
>scope?

I imagine this would be rather hard, but maybe not impossible. A method that does like windows does with the DOS file names when they are the same and appends ~1, ~2, etc. to the name would probably avoid this, but it may be useful to also allow the option of 'overriding' an existing trigger, but that would mean the need to identify it with some other method besides just the name since there would be no way to tell which is which. It also presents a minor problem with aliases, but simply warning that the name had to be changed would probably be good enough.

You are however incorrect in assuming that the mct file needs to be someplace else. It would be helpful perhaps to be able to include definitions from another world file (or something similar that could export 'only' triggers, aliases and other such things into a single source instead of seperate files for inclusion, but without the other settings). However, mct files are specifically (M)ush(C)lient (T)riggers. ;)

>You have in the world file itself, then included files,
>then client wide settings stored in the client xml
>settings file, then settings stored in the registry. I am
>in favour of removing the need to store info in the
>registry because it allows Mushclient to run on a single
>floppy at universities etc.

Yes settings stored in the system registry annoy me too, mostly because it means things can get mangled and stop working. I don't know what if anything MUSHClient uses that actually 'needs' the registry, but there may be nothing at all since it does not force a reboot under 98 when installed. Unfortunately since MUSHClient is not likely to ever impliment its own plugin methods you will still be stuck with using the system registry, if only to create temporary keys for a COM objects people creates to use with it. But for its own settings the registry is a 'very' bad place to put them. Just wish the other devolopers didn't use the bloody thing for storing settings either. It is a bit like storing the companies research documents next to the bin for papers to be sent to the incinerator. lol

Nick Gammon Australia Forum Administrator Thu 09 May 2002 09:30 PM #8

I am inclined to agree with you Kalahn. I have been thinking about this at some length while I do my preliminary implementation of XML.

I think the logical place is really at the global scope, as you suggested, rather than salted away further down the tree. Then a single include file could include triggers, aliases, variables etc. needed to implement a particular function.

I would expect that an include file would be an entire, well-formed XML document in its own right, possibly excluding some sections, however you could exclude sections anyway (eg. if you had no triggers).

The real issue is what to do with collisions, I can't see how scope would totally help. For instance, if two include files both set a value for the variable "monster" which one would prevail? The first? The last?

I am inclined to say "the last", since that is simpler to implement. Ditto with triggers etc. with identical labels, however maybe it would be better to go with the first and do a warning (I suppose you could have the warning whichever one prevailed, anyway).

I suppose there could be other solutions, like namespaces for variables, but that is moving away from simply working out how to do an XML file format.

The other issue with collisions is, whether you want the first or last of something to prevail, which order do include files get processed? Here are some possibilities:

Scan for include files first and do them before anything else
When an include directive is found, stop what you are doing and process it "in situ"
Process include files after the main file.

Each method would alter the way collisions would be handled.

Another possibility would be user choice, like this:



<include name="myfile" collision="keep"/>

<include name="myfile" collision="discard"/>

I am planning to have something like the following as the general XML format. Does anyone have any objections or comments? ...

My explanations are in italics.



<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE world>
<world

 <!-- General, once-off settings --> 

  <general
   world_name="Ages of Despair"
   auto_say_string="say "
   enable_scripts="1"
   enable_speed_walk="1"
   player_name="Gandalf"
   server_ip_address="agesofdespair.org"
   > <!-- end of general attributes -->

 <!-- Multi-line, once-off settings --> 
 <!-- Note, HTML in log file "escaped" --> 

   <log_file_postamble>
Ages of Despair [%Y-%b-%d %a]
&lt;/pre&gt;
&lt;/font&gt;
&lt;/body&gt;
&lt;/html&gt;
   </log_file_postamble>

   <notes>
Watch out for Kalahn!
   </notes>

  </general>  <!-- end of general section -->

 <!-- Triggers section - multiple triggers --> 

<!-- triggers -->
<triggers>

  <trigger
   regexp="1"
   sequence="100"
   match="^You are hungry$"
  >
   <send>
eat food
   </send>
  </trigger>

  <trigger
   enabled="1"
   regexp="1"
   sequence="100"
   match="Kalahn"
   name="Loglabel"
   script="LogIt"
  >
  </trigger>

</triggers>

 <!-- Aliases section - multiple aliases --> 

<!-- aliases -->
<aliases>
  <alias
   match="aha"
   enabled="1"
   speed_walk="1"
   ignore_case="1"
  >

   <send>
(brief/brief) 3n 7e 4n e 3n w (brief/brief) (enter/out) 
   </send>

  </alias>

</aliases>

 <!-- And so on, for variables, timers etc. --> 

</world>

One more question - does anyone have any preference for the order in which attributes are written? (eg. trigger name, match string, enabled flag etc.). Here are some possibilities ...

Alphabetic order (so "enabled" comes before "match")
Importance (subjective), however you might have the match string before the regexp flag.
Grouped by type (eg. strings, numbers, flags)

This wouldn't affect the parsing, just maybe make the generated file easier to read if you want to edit it.

Nick Gammon Australia Forum Administrator Thu 09 May 2002 09:51 PM #9

Quote:

Yes settings stored in the system registry annoy me too, mostly because it means things can get mangled and stop working. I don't know what if anything MUSHClient uses that actually 'needs' the registry, but there may be nothing at all since it does not force a reboot under 98 when installed.

I agree with both of you about the registry. I only really used that because I didn't want to muck with the world file format earlier on.

I will migrate most, if not all, settings from the registry to the world file, and, perhaps, a "global settings" file, also in XML.

Magnum Canada Fri 10 May 2002 08:47 PM #10

I don't know XML programming, so it's a little tough to comment on some of the advanced techniques you are talking about.

I've looked at the XML conversion of my file that Nick mailed me, and for the most part, it appears easy to read, and I hope it won't be too difficult to learn once I try interacting with it directly.

...In the meantime, I was wondering about the client interface. You mention using "include" directives in the code, but what I think I would like to see is the ability to declare include files via the setup interface. The other thing you have not mentioned, is multiple script files.

Now, here is something I would like to do:

Write a script file "plugin" for use at a particular mud, or type of mud. Include the triggers, aliases, timers, variables for use at that mud.

Under this XML implementation, I would expect to share 2 files to accomplish this task:

Script Project.XML
Script Project.VBS

Optimally, for the user to include my plugin, they would go to a screen in their setup/preferences, and (perhaps):

Click: Add Plugin
Enter directory for XML file.

That's it! Done. The novice user would not need to dictate what script file(s) to use, or where they are stored... The XML file should be able to handle that. They would not need to run an "/install" (at least not to install the triggers/aliases). They would not need to edit their main script file to modify (the current workaround) code to "include" the script "plugin".

Here are some things I think Nick would have to consider in programming the interface:

Collisions (as mentioned already).
Multiple script files.
Script file routine names colliding.
Script file global (not mushclient) variables colliding.
Variable scripting languages, among multiple script "plugins".
Trigger/Alias/Timer/Variable interface editing. Which XML file are they editing via interface? Indeed, ANY setup options, which XML file are they editing?

Now... In the context of Microsoft Windows, you get multiple programs running "at the same time", each as thier own "virtual machine". Of course, they aren't really multitasking, they just take turns using the processor very quickly.

In the context of Mushclient, I think a similar approach might be useful. A sort of "virtual XML machines", all sharing the output/input windows, and client interface (kind of like Windows does). The priority would likely be a bottom-up approach:

XML plugin A
XML plugin B
XML Character file
XML World file

Any output from the mud would be processed by the last XML file, then the next up, then the next up, etc... Any text from the command line would be processed in the same manner.

Since each XML file would run in a "virtual machine", collisions would not be as significant. You could have the same mushclient variable in BOTH plugin A and B. You could have an alias "scripthelp" in BOTH plugin A and B. In this example, first plugin B would process the alias (and do whatever), then plugin A would ALSO process the alias (and do whatever). Of course, trigger collisions would be handled the same way.

One XML file could use VBS scripting, a different XML file might call a pearlscript.

The only collisions left to handle would be certain settings that really shouldn't be duplicated, like connection info, number of lines to keep in scrollback buffer, etc...

To edit any other settings via an interface, the user would have to dictate which XML file they would like to edit first.

All this came off the top of my head, hope it makes sense.
:)

Kalahn United Kingdom Fri 10 May 2002 09:47 PM #11

Regarding the preference for order in an XML file... I would take the approach required/always used fields before optional fields. Obviously parsing can read them in for any order.

- Kal

Magnum Canada Fri 10 May 2002 09:59 PM #12

An interesting complication occured to me, regarding my proposal above.

What happens if the user has two worlds open, and is using the same "plugin" within both worlds? This brings up a new aspect of "collisions".

It would probably be best to to run multiple "machines" in this regard to (to keep variables seperate), but even so, when the user goes to "save" the file, one "copy" will overwrite the other!

I'm probably getting pretty far ahead of myself speculating down this road...

I can already see workarounds to this, it would just require some careful scripting by the programmer... like including the worldname as a prefix to variable names. (Though this could make the file pretty large). Another solution would be to allow for cross-programming values to another XML file, so that, for example, a plugin could access variables in a "character" file.

All of this sounds pretty complex, and I imagine it would require a major overhaul of the client program. It may be worth it though, given the programming power and ease of use (for non-programmers) of this model.

Nick Gammon Australia Forum Administrator Fri 10 May 2002 11:02 PM #13

Quote:

Regarding the preference for order in an XML file... I would take the approach required/always used fields before optional fields. Obviously parsing can read them in for any order.

OK. In the general world configuration there are about 2 required fields (ip address, port) and the rest are optional (ie. can be zero, or take defaults).

What order would you have the remaining 127 fields?

Nick Gammon Australia Forum Administrator Sat 11 May 2002 02:16 AM #14

My current plan is to release a new version of MUSHclient soon, that supports XML loading/saving but nothing else new.

That way we can test the XML part, without being confused about any other new features.

Then, with the more powerful file format at our disposal, can look at adding new features. eg.

triggers that let you colour with RGB colours (ie. any colour) rather than the 16 custom ones
scripts attached to triggers/aliases etc.
include files
mapping any keystroke to any action
scripts directly on numeric keypad actions
... lots of other things :)

Nick Gammon Australia Forum Administrator Thu 16 May 2002 07:19 AM #15

I have now released version 3.21 which writes out XML world files (and reads them back in, of course).

So far, "include" files are not supported, principally because this would have needed GUI changes as well (eg. a list of include files), and I wanted to make this version basically the same as the previous one, but with XML saving/loading.

Have a play with that and see what you think - the world files are roughly double in size, and the loading speed is pretty acceptable. :)