How can I share my notes file from one world to all the others using include files? For example, I need to make it so that the notes are in a single file, and all the worlds read from it. Can that be extended to include triggers/timers/variables/etc?
Sharing notes between worlds using XML "include"
Posted by Poromenos on Wed 14 Aug 2002 04:45 PM — 5 posts, 21,758 views.
Yes, the intention is that this will work.
I am trying to do a small demo to show how, and am running into problems, either with remembering how it works, or maybe a bug in the code.
As soon as I work it out, I'll let you know. ;)
I am trying to do a small demo to show how, and am running into problems, either with remembering how it works, or maybe a bug in the code.
As soon as I work it out, I'll let you know. ;)
Seems to be a bug in the include code. Fixed in 3.26. The method, which should work in 3.26 is:
Make an include file like this:
Then in your main world file (using a text editor) add an "include" line, directly after the <muclient> line, like this:
You may need to put in the full path name if it doesn't find it. The idea here is that the include file will be processed first, and set up the notes for that world (and every world that uses it).
However you must only edit the notes by editing the include file in a text editor - as soon as you change it inside a particular world, MUSHclient will assume that that world is to have different notes, and will save them in the world file, thus overriding the included version.
Make an include file like this:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE muclient>
<muclient>
<world>
<notes>
<![CDATA[
My test notes
Line 2
Line 3
...
Line 99 ... and so on ...
]]>
</notes>
</world>
</muclient>
Then in your main world file (using a text editor) add an "include" line, directly after the <muclient> line, like this:
<muclient>
<include name = "notes_include_file.xml" />
You may need to put in the full path name if it doesn't find it. The idea here is that the include file will be processed first, and set up the notes for that world (and every world that uses it).
However you must only edit the notes by editing the include file in a text editor - as soon as you change it inside a particular world, MUSHclient will assume that that world is to have different notes, and will save them in the world file, thus overriding the included version.
Ahh, very nice... And I assume that this will also work with other parts of the world file, such as triggers/aliases/etc mixed up in one include file?
i.e. Can I have my notes, 3 triggers, 4 aliases and 2 variables in the include file? And also, where will the variable's value be stored, in the include file or in the world file?
i.e. Can I have my notes, 3 triggers, 4 aliases and 2 variables in the include file? And also, where will the variable's value be stored, in the include file or in the world file?
Yes, notes, triggers, aliases etc. can go in the include file.
Right now the code to manage clashes between the include file and the main file has not been written for colours, macros, keypad and printing sections.
The variables are stored where they are found, however if you change a variable (or anything) then MUSHclient assumes you are overriding the include file, and then saves it in the world file.
In other words, if a particular setting (eg. hyperlink_colour="blue") is in the include file, and you save the world file, then that setting is *not* written to the world file, unless the value has changed. So, for instance, if you changed hyperlink_colour to "green" then that is written to the world file as a "local override". Then if the include file was subsequently changed (eg. to "yellow") then any world files with the local change would not be affected, however ones that had previously used the included value will get the new value.
The idea here is that you can set up "standard" settings in the include file(s) but override them if you want in the main world file.
Right now the code to manage clashes between the include file and the main file has not been written for colours, macros, keypad and printing sections.
The variables are stored where they are found, however if you change a variable (or anything) then MUSHclient assumes you are overriding the include file, and then saves it in the world file.
In other words, if a particular setting (eg. hyperlink_colour="blue") is in the include file, and you save the world file, then that setting is *not* written to the world file, unless the value has changed. So, for instance, if you changed hyperlink_colour to "green" then that is written to the world file as a "local override". Then if the include file was subsequently changed (eg. to "yellow") then any world files with the local change would not be affected, however ones that had previously used the included value will get the new value.
The idea here is that you can set up "standard" settings in the include file(s) but override them if you want in the main world file.