Register forum user name Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.

Due to spam on this forum, all posts now need moderator approval.

 Entire forum ➜ MUSHclient ➜ Suggestions ➜ Global Defaults, Logging (and XML format)
Global Defaults, Logging (and XML format)

It is now over 60 days since the last post. This thread is closed.     Refresh page

Pages: 1 2  3  4  

Posted by Magnum   Canada  (580 posts)  Bio
Date Tue 21 May 2002 05:40 AM (UTC)

Amended on Wed 24 Sep 2003 02:25 AM (UTC) by Nick Gammon

Message
Heh. Out of curiousity, I tried playing with an .MCC file, to what could be accomplished. First, I resaved my default colours to get a newer file coded in XML. Next, I loaded my most popular World XML file, and copied some "settings" to the colour file.

Part of the reason I did this, is because most of the settings I tried to copy are also "colour" related. (Colour of commands echoed to the output window, etc...).

I found that the extra information in the file was ignored. I assume because the code that loads the colour file only looks for certain tags, and ignores all others. Here is my modified file (which DOES NOT WORK):

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE muclient>
<!-- Saved on Tuesday, May 21, 2002, 12:34 AM -->
<!-- MuClient version 3.22 -->
<!-- Written by Nick Gammon -->
<!-- Home Page: http://www.muclient.com/ -->
<muclient>

<!-- colours -->

<colours
muclient_version="3.22"
world_file_version="15"
date_saved="2002-05-21 00:34:06"
>

<ansi>

<normal>
<colour seq="1" rgb="gainsboro" />
<colour seq="2" rgb="maroon" />
<colour seq="3" rgb="darkgreen" />
<colour seq="4" rgb="#8A8A00" />
<colour seq="5" rgb="navy" />
<colour seq="6" rgb="purple" />
<colour seq="7" rgb="royalblue" />
<colour seq="8" rgb="#3C3C3C" />

</normal>

<bold>
<colour seq="1" rgb="white" />
<colour seq="2" rgb="red" />
<colour seq="3" rgb="forestgreen" />
<colour seq="4" rgb="#C1C100" />
<colour seq="5" rgb="blue" />
<colour seq="6" rgb="darkviolet" />
<colour seq="7" rgb="cornflowerblue" />
<colour seq="8" rgb="black" />

</bold>

</ansi>

<custom>
<colour seq="1" name="Custom1" text="#FF8080" back="gainsboro" />
<colour seq="2" name="Custom2" text="darkgoldenrod" back="gainsboro" />
<colour seq="3" name="Custom3" text="#515151" back="gainsboro" />
<colour seq="4" name="Custom4" text="#80FFFF" back="gainsboro" />
<colour seq="5" name="Custom5" text="#0080FF" back="gainsboro" />
<colour seq="6" name="Custom6" text="#FF80C0" back="gainsboro" />
<colour seq="7" name="Custom7" text="red" back="gainsboro" />
<colour seq="8" name="Custom8" text="#0080C0" back="gainsboro" />
<colour seq="9" name="Custom9" text="magenta" back="gainsboro" />
<colour seq="10" name="Custom10" text="#804040" back="gainsboro" />
<colour seq="11" name="Custom11" text="#FF8040" back="gainsboro" />
<colour seq="12" name="Custom12" text="teal" back="gainsboro" />
<colour seq="13" name="Custom13" text="#004080" back="gainsboro" />
<colour seq="14" name="Custom14" text="#FF0080" back="gainsboro" />
<colour seq="15" name="Custom15" text="green" back="gainsboro" />
<colour seq="16" name="Custom16" text="blue" back="gainsboro" />

</custom>
</colours>

<world
muclient_version="3.22"
world_file_version="15"
date_saved="2002-05-20 20:04:29"

input_font_name="FixedSys"
log_line_postamble_input="&lt;/font&gt;"
log_line_preamble_input="%H:%M&gt; &lt;font color=#FF8040&gt;"
log_line_preamble_notes="%H:%M&gt; "
log_line_preamble_output="%H:%M&gt; "
output_font_name="FixedSys"
display_my_input="y"
echo_colour="11"
echo_hyperlink_in_output_window="y"
history_lines="1000"
hyperlink_adds_to_command_history="y"
hyperlink_colour="#0080FF"
indent_paras="y"
input_background_colour="darkgray"
input_font_height="9"
input_font_weight="400"
input_text_colour="black"
log_html="y"
log_input="y"
log_in_colour="y"
log_notes="y"
log_output="y"
max_output_lines="5000"
mud_can_change_link_colour="y"
note_text_colour="#040000"
output_font_height="9"
output_font_weight="400"
show_underline="y"
underline_hyperlinks="y"
unpause_on_send="y"
use_default_input_font="y"
use_default_output_font="y"
wrap_column="125"
write_world_name_to_log="y"
> <!-- end of general world attributes -->

</world>

</muclient>

(I left off forum codes to prevent conflicts).
Get my plugins here: http://www.magnumsworld.com/muds/

Constantly proving I don't know what I am doing...
Magnum.
Top
Posted by Magnum   Canada  (580 posts)  Bio
Date Reply #1 on Tue 21 May 2002 05:40 AM (UTC)
Message
[continued]

Since the above did not work, what I would like to see eventually is a seperate box on "Global Preferences | Defaults" that allows for the loading of default World settings.

Also, there are several options that I feel are colour related, and should be 'moved' to the colour section, particularly those above that have anything to do with colours and fonts.

The logline pre-amble and post-amble (above), plus file pre-amble and post-amble (not shown) can be a real pain to modify in every new world, and I would LOVE to be able to define them in a default file that loads for each world. The biggest problem is that I would like to be able to insert a tag in such code that would replace, for example %WorldName with the name of this particular world (Already stored in the "name" option - not shown), and the %PlayerName (already stored in "player" option - not shown). This should be fairly easy to accomplish by adding %worldname and %playername to the list of variables that are already available (such as %H and %M)

Another handy variable here would be %WorldsDir, which would be the "Default World Directory" from the "Global Preferences | Worlds" window.

Something else I have noticed, is that Custom Colours can not be modified in a world that loaded the Default Colours. I find this somewhat interesting. I would have expected that the colours COULD be modified, but would be stored in the World file. The Default Colours file would be loaded each time the world is initialized, but then any values in the World file would over-ride the default settings. This kind of behaviour would be a MUST for the other default files (I would expect). I haven't tried the other defaults out, so I can't comment on that.

Anyway, I'll wrap this up now. It seems like the new XML files are relatively stable, so hopefully adding these new features would not be too much of a bother, during this "upgrade" session. :)
Get my plugins here: http://www.magnumsworld.com/muds/

Constantly proving I don't know what I am doing...
Magnum.
Top
Posted by Magnum   Canada  (580 posts)  Bio
Date Reply #2 on Tue 21 May 2002 06:04 AM (UTC)
Message
Speaking of the logfile, I've noticed that text sent to the log file is sent as black text. I don't know why it chooses that colour.

I was about to suggest a function to WriteColourLog, but I also noticed that there is no line pre- and post-amble for lines sent.

The only reason I use World.WriteLog is to log World.Send commands:

Sub LogSend (SendString)
	World.Send SendString
	World.WriteLog SendString
End Sub


The better solution would be to automatically log anything sent to the mud using World.Send, as if it had been sent from the command line. (I.E: Use the "Commands" pre- and post-amble).
Get my plugins here: http://www.magnumsworld.com/muds/

Constantly proving I don't know what I am doing...
Magnum.
Top
Posted by Magnum   Canada  (580 posts)  Bio
Date Reply #3 on Tue 21 May 2002 06:19 AM (UTC)
Message
Argh, one more thing about logging:
I've noticed my log starts with the following:

Ages of Despair - Tuesday, May 21, 2002, 12:03 AM -------------------------------------------------

I would prefer if the line of dashes appeared on the second line, underneath the world name - date.

Oh, and I assume that text I mentioned was in black because I don't set a font colour in the file preamble header, and black is the default...?
Get my plugins here: http://www.magnumsworld.com/muds/

Constantly proving I don't know what I am doing...
Magnum.
Top
Posted by Magnum   Canada  (580 posts)  Bio
Date Reply #4 on Tue 21 May 2002 07:08 AM (UTC)

Amended on Tue 21 May 2002 07:18 AM (UTC) by Magnum

Message
LOL, Yet another subtle suggestion:

%z and %Z do the same thing.

I propose one of them be altered to display the time zone offset (and code, if possible), for example:

Times (on the left) are %z.
Times (on the left) are Eastern Daylight Time.

Times (on the left) are %Z.
Times (on the left) are EDT.

Times (on the left) are %z (%Z).
Times (on the left) are Eastern Daylight Time (EDT).

Times (on the left) are %#z.
Times (on the left) are GMT -04:00.

Times (on the left) are %Z (%#z).
Times (on the left) are EDT (GMT -04:00).
Get my plugins here: http://www.magnumsworld.com/muds/

Constantly proving I don't know what I am doing...
Magnum.
Top
Posted by Nick Gammon   Australia  (23,173 posts)  Bio   Forum Administrator
Date Reply #5 on Tue 21 May 2002 08:40 AM (UTC)
Message
Quote:

Part of the reason I did this, is because most of the settings I tried to copy are also "colour" related. (Colour of commands echoed to the output window, etc...).

I found that the extra information in the file was ignored. I assume because the code that loads the colour file only looks for certain tags, and ignores all others. Here is my modified file (which DOES NOT WORK):


Correct, when loading colours it sets an internal mask so that only colour sections are processed, however one work-around right now is to use File -> Import, which gives you control over what is imported, and the default is everything.

What your posts touch on here is what I have been working on over the last couple of days, and that is file inclusion. In my current (development) version, this works right now:


<muclient>
<include name="mystandardsettings.xml" />
<world
  blah blah
 >
</muclient>


What is more, include files can include other files, so you can nest them. I think this will address most of your concerns about having to have "default" behaviour in each world, simply put it all in an include file.

However the problem that I am wrestling with, and will look at again tomorrow, is collisions. Let us say, for instance, you had a file like this:


  • Include "A" - "A" sets note text colour to "red"
  • Include "B" - "B" sets note text colour to "blue"
  • <world note_text_colour="green" >


Which colour should prevail? This is not like collisions of trigger names, colours like that don't have names, plus you can't not have one. There has to be a colour, even if it is the default.

Say you have an option, like this:


<include name="a" overwrite="y" />

The intention here is that by having "overwrite" set the include file would overwrite (override might be a better word) the main world settings. But what if you used the option twice, like this?


<include name="a" overwrite="y" />
<include name="b overwrite="y" />

And both "a" and "b" change the colour?

If you can make some sensible suggestions for working around this, they would be appreciated.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Magnum   Canada  (580 posts)  Bio
Date Reply #6 on Tue 21 May 2002 07:53 PM (UTC)
Message
This is where my "virtual machines" theory comes into play.

Each "include" directive (I.E: Each XML File) runs in it's own "vitual mudclient machine". I posted much about this in the first XML thread.

Much of what can be configured could run in it's own virtual machine. For example:

Aliases
Triggers
Timers
Scripts
Some "formatting" (Like Note colour).
etc...

There are, of course, some things that should only be set in the "core" machine. For example:

Output screen formatting
Command box formatting
Logging
Connection info
Scrollback buffer
etc...

This may require a significant overhaul to the settings file:

Seperate CORE World settings to it's own XML file, and GUI interface.
Allow for loading "Default" core settings via interface (like you do now for colours, triggers, etc).

Provide a seperate interface for interacting with settings that can run in multiple "virtual machines". (Namely: Aliases, Triggers, Timers, Scripting).

In this second interface, the user would indicate WHICH "machine" (XML file) they are interacting with.

On world initialization, you would:

Load Default Colour file
Load Default Alias file
Load Default Trigger file
Load Default Timer file
Load Default Preferences file

Load World File. Override any Defaults if World File has "colliding" values. This is the "CORE" machine.

Load "Include" files. Ignore "CORE" settings (settings which should only be declared once, as above). Each "Include" file runs in a virtual machine, so collisions are NOT relevant.

The HUGE advantage to this method is that it supports "plugins" in a very versatile way. That is, each machine could run it's own script file, and they could even be programmed in different languages!

You would process mud output first through the CORE machine, then through the INCLUDE machines (probably in the order they were loaded). Each INCLUDE would have a turn at processing input and output to act on triggers/aliases, etc...

Critical CORE settings are only loaded in 2 places, the "Defaults" file, and the core "World" file. Collisions are handled by over-riding the Defaults file (which is natural, of course).
Get my plugins here: http://www.magnumsworld.com/muds/

Constantly proving I don't know what I am doing...
Magnum.
Top
Posted by Nick Gammon   Australia  (23,173 posts)  Bio   Forum Administrator
Date Reply #7 on Tue 21 May 2002 09:48 PM (UTC)
Message
Quote:

Something else I have noticed, is that Custom Colours can not be modified in a world that loaded the Default Colours. I find this somewhat interesting. I would have expected that the colours COULD be modified, but would be stored in the World file.


This was done before the include stuff. At the time, the defaults basically overwrote the world ones, so modifying them would have been pointless.

This takes us back to collisions, which colour has preference?
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Nick Gammon   Australia  (23,173 posts)  Bio   Forum Administrator
Date Reply #8 on Tue 21 May 2002 09:49 PM (UTC)

Amended on Tue 21 May 2002 10:05 PM (UTC) by Nick Gammon

Message
Quote:

Speaking of the logfile, I've noticed that text sent to the log file is sent as black text. I don't know why it chooses that colour.

Not sure what you mean by that. Do you mean, from a script? - and, you mean HTML/Colour logging? If so, it should log in the current text colour on the screen. That is supposed to be how it works.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Nick Gammon   Australia  (23,173 posts)  Bio   Forum Administrator
Date Reply #9 on Tue 21 May 2002 10:00 PM (UTC)

Amended on Tue 21 May 2002 10:03 PM (UTC) by Nick Gammon

Message
Quote:

I was about to suggest a function to WriteColourLog, but I also noticed that there is no line pre- and post-amble for lines sent.

The only reason I use World.WriteLog is to log World.Send commands:


You can now get at the line pre and postamble with world.GetAlphaOption. Just modify your routine to use those. Plus, you could pull in the command colour while you were at it. eg. something like this:


Sub LogSend_HTML (SendString)
 World.Send SendString

 World.WriteLog world.getalphaoption ("log_line_preamble_input")

 World.WriteLog "<font color='" & _
            World.RGBcolourtoname _
            (World.GetOption ("input_text_colour")) & _            
            "'>"

 World.WriteLog FixupHTML (SendString)

 World.WriteLog "</font>"

 World.WriteLog world.getalphaoption ("log_line_postamble_input")
 
End Sub
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Nick Gammon   Australia  (23,173 posts)  Bio   Forum Administrator
Date Reply #10 on Tue 21 May 2002 10:22 PM (UTC)
Message
Quote:

Argh, one more thing about logging:
I've noticed my log starts with the following:


Ages of Despair - Tuesday, May 21, 2002, 12:03 AM -------------------------------------------------


I would prefer if the line of dashes appeared on the second line, underneath the world name - date.



Hmmm - that bug has been there for a while. I gather you are logging in HTML? I forgot to convert the world name to HTML, and put a <BR> before the hyphens, in HTML mode. If you edit the log file, you will see there is a newline before the hyphens, but that doesn't cause a newline in HTML.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Magnum   Canada  (580 posts)  Bio
Date Reply #11 on Tue 21 May 2002 10:43 PM (UTC)
Message
WriteLog doesn't capture from the screen, so there is no colour set for it. You nailed it in your second post though...
Quote:

This was done before the include stuff. At the time, the defaults basically overwrote the world ones, so modifying them would have been pointless.

This takes us back to collisions, which colour has preference?

Under my proposal, the Output screen, and the Command box would use the "Core" machine's colours. The colours would not have to be a "Core" only setting though. A virtual machine could also have it's colour settings, and utilize them as well.

For example, a "virtual machine" could inherit the "core" machine's colours, but modify, for example, number 16, then use that colour for "World.Note" functions. If this seems to confusing, or you just see too many conflicts/collisions with this setting, you could mark it as "core" only, so that only the "core machine" would accept this setting. (It would be ignored in "Include" files/machines).

Under this latter scenario, there are two places to grab colour settings: The Default file, and the World file. Load the Default file first, then over-ride any colour settings if they are also set in the world file. Ignore colour settings in any other place.

Even nested "include" files would still run in their own "virtual mushclient machine", so you COULD load the colour settings just once more per VM, over-riding the [inherited] core machine's colours. The colours in the virtual machine's settings would only have effect in a few places though, like the "Trigger - Change colour" option, or World.Note, etc... Once again, main output and command box couldn't be effected through an "include" virtual machine, those would be set by the "core" machine.

Basically, any setting that can not tolerate collisions, you mark as "core only". They can only be set in two places: The Default file, and the Core file. The Core over-rides collisions from the Default. (You ignore that setting in any other XML file).

All other settings (and there should be plenty), can run in the "core" machine AND/OR "virtual machines".

Should I explain furthur using examples?
Get my plugins here: http://www.magnumsworld.com/muds/

Constantly proving I don't know what I am doing...
Magnum.
Top
Posted by Nick Gammon   Australia  (23,173 posts)  Bio   Forum Administrator
Date Reply #12 on Wed 22 May 2002 12:17 AM (UTC)
Message
Quote:

The biggest problem is that I would like to be able to insert a tag in such code that would replace, for example %WorldName with the name of this particular world (Already stored in the "name" option - not shown), and the %PlayerName (already stored in "player" option - not shown). This should be fairly easy to accomplish by adding %worldname and %playername to the list of variables that are already available (such as %H and %M)

Another handy variable here would be %WorldsDir, which would be the "Default World Directory" from the "Global Preferences | Worlds" window.



I have added the following:


Added extra options to the formatting strings for log file preamble, postamble, line preamble etc. These are:

  %N - name of current world
  %P - player name
  %F - default world directory
  %L - default log file directory
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Shadowfyr   USA  (1,792 posts)  Bio
Date Reply #13 on Wed 22 May 2002 12:44 AM (UTC)
Message
Hmm.. Magnum's idea for color collisions is a good idea with respect to the main and world files, though this virtual machine stuff is confusing in as much as I am not entirely sure what he means. My suggestion would be this.. Make the defaults load, override them with the specific world files, but require that any changes to colors not in an actually script be added/changed 'only' by direct importation (which can warn of such changes, show a sample and ask if they really want the change), otherwise included color definitions would be simply ignored. Any other method bring up to many conflicts and if any future version that allows direct setting of a color within triggers is implimented this will become mostly irrelavent, since most 'standard' ansi color sets are left as is and only the custom set is usually modified, a feature needed for backward compatibility, but which won't be critical for triggers using a full color definition.
Top
Posted by Shadowfyr   USA  (1,792 posts)  Bio
Date Reply #14 on Wed 22 May 2002 01:21 AM (UTC)
Message
One thing... If you do end up with a default file, then load a world file over it. It would be nice if there was also a few additional options:

DefaultNoteColorRGB for one example.

While you can set the note color any way you want in a script it is inconvenient having to look up the original in the world file in order to find the correct thing to set it back. Being able to change a setting and then later reset it to the default would be useful. Of course in this case the default would likely be whatever the world file defined as the 'normal' color and not the actual actual default (unless the world file lacks a raplacement for it). ;)
Top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

126,039 views.

This is page 1, subject is 4 pages long: 1 2  3  4  [Next page]

It is now over 60 days since the last post. This thread is closed.     Refresh page

Go to topic:           Search the forum

[Go to top] top

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

Home