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 ➜ General ➜ Size of your world files?

Size of your world files?

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


Pages: 1 2  

Posted by Nick Gammon   Australia  (23,133 posts)  Bio   Forum Administrator
Date Tue 07 May 2002 03:11 AM (UTC)
Message
I am in the process of converting MUSHclient to read/write XML for its world files. This will have a heap of advantages, not the least of which will be:


  • Backwards compatibility - old world files will work with new versions
  • Forwards compatibility - new world files will be able to be read by older versions
  • Easier to add new options to MUSHclient, without worrying about making existing world files unreadable
  • Viewable in a text editor, or web browser
  • You could forward snippets of world files (eg. a trigger) by email or by the forum much more easily


The question I want to ask is - what is the maximum world file size you are likely to need? To find this out, look in the directory where your world files are, and (in the Explorer) click on View -> Details. Then click on the Size column heading to sort the world files into size order, and then note the size of the largest one.

Please post your response here, and don't bother if someone has already posted a file larger than yours.

I'll start the ball rolling by stating that my largest world file is 9 K bytes.

However if you have hundreds of triggers and aliases, as I gather some of you have, then yours will probably be larger.

I am trying to establish a reasonable upper limit for the world file size, so that MUSHclient would refuse to open (say) a 10 Mb world file.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

Posted by Magnum   Canada  (580 posts)  Bio
Date Reply #1 on Tue 07 May 2002 05:21 AM (UTC)
Message
.MCL file size: 38KB.

Triggers: 178
Aliases: 256
Timers: 2 to 6
MushClient Variables: Approx. 130

Well established character, new triggers/aliases are added very rarely now, although the potential lies to add over 100 new aliases, since each spell/skill requires me to write an alias, and I have not explored all the guilds in this world.

I can't imagine anyone required a file over 1MB in size, under the current implementation.

Get my plugins here: http://www.magnumsworld.com/muds/

Constantly proving I don't know what I am doing...
Magnum.
Top

Posted by Shadowfyr   USA  (1,790 posts)  Bio
Date Reply #2 on Tue 07 May 2002 09:10 PM (UTC)
Message
Hmm... Taking a look at mine I am using only a 16k file. Also a mess of triggers and stuff though.

One thing Magnum is overlooking though is that XML is text based while the current MCL files are somewhat binary in nature. So while now a trigger might me say hex 10, followed by the match strings, etc. and maybe a byte containing flags, the XML version has to spell all those out.

In magnum's case that would be say 1780 extra bytes in the file, just to add <trigger> or whatever you use to all 178 triggers he uses. So... multiply his by say 50 just to be on the safe side and you get a 1.9MB file. And 50 times may be conservative, since you need markers for:

triggers> name=, match=, color to change/match, flags, send, label, script

Alias> name=, match=, flags, send, label, script

All the world settings, etc.

All of them 'have' to be user readable for there to be any point to using XML. I don't know how big the file would actually need to be, but it will definitely not be under 1M if the user has anything close to as many aliases and triggers as us heavy hitters use.
Top

Posted by Nick Gammon   Australia  (23,133 posts)  Bio   Forum Administrator
Date Reply #3 on Wed 08 May 2002 02:56 AM (UTC)
Message
Yes, I understand that, but wanted to have a baseline idea of what sort of size I am looking at.

Probably what would be helpful is to get a count of triggers, aliases, variables, timers. Each one is likely to have a fixed overhead, as you pointed out, plus the variable content.

If you run this little script, and post the results, that will tell me ...


world.note "Count of variables = " & world.getinfo (218)
world.note "Count of triggers = " & world.getinfo (219)
world.note "Count of timers = " & world.getinfo (220)
world.note "Count of aliases = " & world.getinfo (221)


It might also help if you two, and anyone else with a large world file, emails me a copy of a representative sample. You can de-identify it by removing character names, world names, IP addresses, passwords etc.

Then I can run that through the XML generator, and then re-parse it in XML, to find:


  • If it works; and
  • How much larger the file gets

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

Posted by Shadowfyr   USA  (1,790 posts)  Bio
Date Reply #4 on Wed 08 May 2002 06:05 PM (UTC)
Message
Ok. As usual I was more responding to Magnum's minor misinterpretation of the situation. ;) lol I any case the following is the info specific to my use:

Count of variables = 8
Count of triggers = 91
Count of timers = 2
Count of aliases = 90

Most of the triggers are color adjusters and if the mud let me change more things to taste probably wouldn't be used as much. Though 16 colors no matter how you look at it is a pain to work with. ;)

This is not necessarilly representative of what I 'might' do in the future a better limit would be to find out at what point the client starts to get badly slowed down and set the limit below that. Any limit you set assumes that no circumstance will ever arise that 'breaks' that standard. I can in the worst case consider maybe having 2-3 times as many triggers and aliases as well as maybe half that in timmers. Variables since they slow the client in great numbers would probably not rise much higher than I already use, but then again, now that direct setting of variables is possible in triggers, I may use a few more in some cases for convenience, but not any significant number.

I assume you are testing the create/load xml with the assumption that all aliases, timers and triggers call scripts, as well as all other possible options? Otherwise it still wouldn't be very accurate.

On a side note... I kind of wish scripting languages supported the same object persistance as COM. (or even DOS BASIC with respect to variables) lol But then opening a file and dumping all globals into the file at world disconnect or at intervals is not a lot different than what COM does and generally as prone to failing if a crash happens. But at least with COM and BASIC you can/could save the state and thus all variables in one hit. Sigh... Oh, well nothing you or anyone else can really do about it save writing a sub to do it the hard way. Which I think Magnum already did with some stuff he has. ;)
Top

Posted by Nick Gammon   Australia  (23,133 posts)  Bio   Forum Administrator
Date Reply #5 on Wed 08 May 2002 09:21 PM (UTC)

Amended on Fri 10 May 2002 06:50 AM (UTC) by Nick Gammon

Message
Quote:

I assume you are testing the create/load xml with the assumption that all aliases, timers and triggers call scripts, as well as all other possible options? Otherwise it still wouldn't be very accurate


Yes, I'll try to catch all cases, but you know how tricky that can be sometimes. :)

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

Posted by Dave   Australia  (93 posts)  Bio
Date Reply #6 on Fri 10 May 2002 01:20 AM (UTC)
Message
Instead of refusing to open a 10MB world file, why not, by default, have a msgbox that asks "mud.mcl is 11.2MB big. Are you SURE you wish to open it?", and an option to turn this warning off?
Top

Posted by Nick Gammon   Australia  (23,133 posts)  Bio   Forum Administrator
Date Reply #7 on Fri 10 May 2002 03:29 AM (UTC)
Message
Yes, I suppose so.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

Posted by Nick Gammon   Australia  (23,133 posts)  Bio   Forum Administrator
Date Reply #8 on Fri 10 May 2002 05:43 AM (UTC)
Message
Quote:

In magnum's case that would be say 1780 extra bytes in the file, just to add <trigger> or whatever you use to all 178 triggers he uses. So... multiply his by say 50 just to be on the safe side and you get a 1.9MB file. And 50 times may be conservative, since you need markers for:
triggers> name=, match=, color to change/match, flags, send, label, script
Alias> name=, match=, flags, send, label, script
All the world settings, etc.
All of them 'have' to be user readable for there to be any point to using XML. I don't know how big the file would actually need to be, but it will definitely not be under 1M if the user has anything close to as many aliases and triggers as us heavy hitters use.


Strangely enough, my testing doesn't totally bear that out.

Taking Magnum's file, which he kindly supplied me, that has 178 triggers, 256 aliases, 2 timers, and 117 variables, the file size has gone up from:

38 Kb (original format) to
89 Kb (XML format)

This is just over double, and a long way off reaching 1 Mb.

As for 10 Mb, that would be pushing it. :)

I think the reason is partly that the new format, whilst wordier in some respects, actually saves space in others. For example, I am not saving options that are zero or empty strings, thus taking zero space which in the old format would have taken at least a byte or four.

The message seems to be that the new format will not be unduly bloated, which is nice.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

Posted by Dave   Australia  (93 posts)  Bio
Date Reply #9 on Sat 11 May 2002 04:03 AM (UTC)
Message
XML for configuration files seems a nice addition, for the reasons stated in this thread, regardless of the size expense.. but also so people can write scripts/programs/whatever to parse the XML file to their own end. This was.. inpractical in the older version MCL files.

Also, I'd hope sufficient documentation regarding the new file format would be supplied ;)

One thing that comes to mind though, is updating of the MCL XML file. If I opened it in a text editor and edited it while it was open in MUSHclient, would MUSHclient auto-update the changes? This would be nice, if so..
Top

Posted by Nick Gammon   Australia  (23,133 posts)  Bio   Forum Administrator
Date Reply #10 on Sun 12 May 2002 01:29 AM (UTC)
Message
Quote:

Variables since they slow the client in great numbers
would probably not rise much higher than I already use, but then again, now that direct setting of variables is possible in triggers, I may use a few more in some cases for convenience, but not any significant number.


I was a bit alarmed by this statement. Variables are designed to be fast, as they are implemented with a hash-table lookup. A bit of testing on my old 266 Mhz Pentium reveals the following figures:

Get a variable (world.getvariable) - 1760 per second
Set a variable (world.setvariable) - 310 per second

A bit of tweaking of the hash table size (in the next version) gives these new figures:

Get a variable (world.getvariable) - 2300 per second
Set a variable (world.setvariable) - 520 per second

Probably some of this is the overhead of a COM call, rather than the time taken to look up the variable.

Seems to me, that unless you have thousands of variables, and that a particular script accesses them all, you should have reasonable performance with MUSHclient variables.

For instance, a script that merely gets one variable will be slowed down only 1/2300 of a second.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

Posted by Shadowfyr   USA  (1,790 posts)  Bio
Date Reply #11 on Sun 12 May 2002 05:54 PM (UTC)
Message
Hmm. Well Magnum noted the variable slow down, I haven't a clue how many he uses, but I think he also has a much slower machine too. If I remember right I thought he said a 150mhz system. It may simply be one of those cases where the slower the system the more obviously noticable it is, or even some odd quirk in the way he is actually using them.
Top

Posted by Vaejor   (120 posts)  Bio
Date Reply #12 on Sun 12 May 2002 06:06 PM (UTC)
Message
Just my primary playing location:

Count of variables = 106
Count of triggers = 71
Count of timers = 0
Count of aliases = 38

Size of .MCL file: 19,238 bytes
Top

Posted by Magnum   Canada  (580 posts)  Bio
Date Reply #13 on Mon 13 May 2002 03:38 AM (UTC)
Message
Shadowfyr,

That main thing that would slow down my client, is my "spellqueue". It's something that happened more often back when I had first programmed it:

Events in the game would trigger a mass of spells\skills be added to the queue in quick succession. For example, if casting was stuck "on" and I didn't notice, the spell queue might build up to 25 spells rather quickly, each spell using at least 5 mushclient variables... So in a very short time, I'd have 125 extra variables. The client slowed down so badly, it literally took about 5 minutes before it processed my "csq" alias, which erases the entire queue (and deletes the variables).

Since then, I have refined my triggers and script to handle "casting" better... so now, I very rarely have more than 5 spells\skills in the queue, except for rare occasions where I stack up "conceal item" 20 times to conceal 20 vials of poison, or someting like that. :)

I'm on a P166, by the way. Runs better that the P700 or something I was using elsewhere today. It's suprising how fast your computer can run when you keep it trim, tidy and in order. :)

It's possible I may refine my spell queue script further some day, and convert all the mushclient variables to regular variables, since it isn't really necessary to remember spells across multiple sessions...

My EQ script uses a fair amount of variables too, and those are a MUST for keeping across multiple sessions... but lately, performance seems fine, so I am not too worried.

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,133 posts)  Bio   Forum Administrator
Date Reply #14 on Wed 15 May 2002 03:31 AM (UTC)
Message
Based on my earlier figures, it shouldn't take 5 minutes to delete 125 variables, even on a slightly slower machine.

If you can supply a snippet that actually takes ages to do something simple like that, I'll try to work out what is wrong.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
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.


64,686 views.

This is page 1, subject is 2 pages long: 1 2  [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.