[Home] [Downloads] [Search] [Help/forum]

Gammon Software Solutions forum

See www.mushclient.com/spam for dealing with forum spam. Please read the MUSHclient FAQ!

[Folder]  Entire forum
-> [Folder]  MUSHclient
. -> [Folder]  General
. . -> [Subject]  Size of your world files?
Home  |  Users  |  Search  |  FAQ
Username:
Register forum user name
Password:
Forgotten password?
(New message)
Subject: Size of your world files?
Name:
Your forum user name.
Register forum user name
Password:
Your forum password.
Forgotten password?
Message:
Message to be posted (in English, please).
Forum codes:
Check this if your message uses 'forum codes' or templates (auto-detected for new posts).
Forum codes Templates

Save this message ...

Subject review (reverse sequence)

Pages: 1 2  

Posted by Nick Gammon   Australia  (18,772 posts)  [Biography] bio   Forum Administrator
Date Fri 19 Jul 2002 08:06 AM (UTC)  [ quote  ]
Message
I have waited quite a while for bugs in 3.23 to be reported, and there are indeed very few.

Therefore I will correct the main (albeit fairly minor) problems, and release 3.24 next week.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Exodus   (12 posts)  [Biography] bio
Date Fri 19 Jul 2002 02:44 AM (UTC)  [ quote  ]
Message
Hi there,

May I know when is 3.23 being released? According to the message, it was supposed to be released in june. Or maybe i can't find the page to download it from. http://www.gammon.com.au/files/mushclient/ doesn't have it.

Well, the main reason i'm asking is because my world file is too big for the present 3.22 to load at one shot, and its quite troublesome to keep loading the different bits everytime i use the client.

Thanks
[Go to top] top
Posted by Nick Gammon   Australia  (18,772 posts)  [Biography] bio   Forum Administrator
Date Tue 04 Jun 2002 01:39 AM (UTC)  [ quote  ]
Message
Here's another approach that should work. :)


  1. Identify a large chunk of the world file (using a text editor), eg. all the variables (between <variables> ... </variables>).

  2. Copy them to a separate file (eg. myvariables.xml).

  3. Delete them from the original file.

  4. Repeat if necessary (eg. with triggers) to get the original file size below 102400 bytes.

  5. Open the trimmed world.

  6. Go to File menu -> Import and import the variables.

  7. Ditto for triggers if required, etc.



What this will do is let you open the file "in pieces", so you will have everything back. Hopefully only one extra piece will be needed.

Then when version 3.23 comes out just go back to the original world file.

Again, back up that world file before you do anything.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Nick Gammon   Australia  (18,772 posts)  [Biography] bio   Forum Administrator
Date Tue 04 Jun 2002 01:18 AM (UTC)  [ quote  ]

Amended on Tue 04 Jun 2002 01:19 AM (UTC) by Nick Gammon

Message
Sorry about that. I will increase the limit to 1,000 Kb (1 Mb). That will be in version 3.23 which will be released this week.

Meanwhile, if you are desperate, edit the file with a text editor and (after making a backup) delete the parts that are taking up a lot of room (eg. the variables). That will let you use it for a few days, and then when the new version is released, go back to the backup, and get all the variables etc. back.

You can delete whole chunks, eg. between:


<triggers> ... </triggers>
<aliases> ... </aliases>
<timers> ... </timers>
<variables> ... </variables>


The critical part, that has the connecting info, is between:


<world> ... </world>

However, backup before you start, or you may be worse off, if you corrupt the file so it can never be opened.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Robin Lionheart   (14 posts)  [Biography] bio
Date Tue 04 Jun 2002 12:02 AM (UTC)  [ quote  ]
Message
Well, my largest .MCL file, after I opened and resaved it in MUSHclient 3.22, was 146287 bytes.

I cannot open it in MUSHclient any longer, it says "too large - maximum permitted is 102400 bytes (problem parsing XML)". Wish I had backed up the old format .MCL.
[Go to top] top
Posted by Nick Gammon   Australia  (18,772 posts)  [Biography] bio   Forum Administrator
Date Fri 17 May 2002 10:18 PM (UTC)  [ quote  ]
Message
Quote:

I think it still holds true that processing Mushclient variables is slightly slower than processing regular script variables


This wouldn't surprise me too much. To use a MUSHclient variable the scripting language has to make a COM call (ie. jumps from the script engine to MUSHclient). This will inevitably have *some* overhead.

However, as I said, you shouldn't have to worry about using a few hundred MUSHclient variables.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Magnum   Canada  (580 posts)  [Biography] bio
Date Fri 17 May 2002 05:20 PM (UTC)  [ quote  ]
Message
In truth, this may may have only happened once, where I had to wait a long time for Mushclient to process anything.

I believe I had made an error in programming triggers, etc, and was adding a new skill to the spell queue every time my health bar was displayed in combat.

I'll blame myself for the error, due to the complexity of my script/triggers. I don't think it's something that the average user would encounter.

Actually, I think I experienced the slowdown more often back around that time, but either something I programmed, or something Nick added in more recent versions seems to have corrected the problem.

For example, I had added an "incombat" variable, and triggers that set the variable accordingly. Other triggers now check that flag before automatically adding a skill/spell to the queue.

Once again, I will probably refine the script some more to eliminate the use of Mushclient variables. I've had this script running for some time now, and have NEVER required the skills/spells be remembered across multiple sessions.

Although my slowdown(s) may have been exaggerated for some reason, I think it still holds true that processing Mushclient variables is slightly slower than processing regular script variables... Thus, it seems wise to avoid using Mushclient variables unless the value needs to be saved across multiple sessions. When I started my spellqueue project, I didn't think the performance would be significant, but in retrospect, that was a poor decision. Faster is always better. :)

Actually, I may leave things as they are for a while, until I can get a feel for this new XML format... then I'll consider trying to convert the project to a plugin that anyone can use. :)
Get my plugins here: http://www.magnumsworld.com/muds/

Constantly proving I don't know what I am doing...
Magnum.
[Go to top] top
Posted by Nick Gammon   Australia  (18,772 posts)  [Biography] bio   Forum Administrator
Date Wed 15 May 2002 03:31 AM (UTC)  [ quote  ]
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
[Go to top] top
Posted by Magnum   Canada  (580 posts)  [Biography] bio
Date Mon 13 May 2002 03:38 AM (UTC)  [ quote  ]
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.
[Go to top] top
Posted by Vaejor   (120 posts)  [Biography] bio
Date Sun 12 May 2002 06:06 PM (UTC)  [ quote  ]
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
[Go to top] top
Posted by Shadowfyr   USA  (1,774 posts)  [Biography] bio
Date Sun 12 May 2002 05:54 PM (UTC)  [ quote  ]
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.
main {
__if (Schrodinger_Cat is Alive or version >= "XP"){
____if version = "Vista" then Performance /= Number_of_Cores;
____call Functional_Code();}
__else
____call Crash_Windows();}
[Go to top] top
Posted by Nick Gammon   Australia  (18,772 posts)  [Biography] bio   Forum Administrator
Date Sun 12 May 2002 01:29 AM (UTC)  [ quote  ]
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
[Go to top] top
Posted by Dave   Australia  (93 posts)  [Biography] bio
Date Sat 11 May 2002 04:03 AM (UTC)  [ quote  ]
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..
[Go to top] top
Posted by Nick Gammon   Australia  (18,772 posts)  [Biography] bio   Forum Administrator
Date Fri 10 May 2002 05:43 AM (UTC)  [ quote  ]
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
[Go to top] top
Posted by Nick Gammon   Australia  (18,772 posts)  [Biography] bio   Forum Administrator
Date Fri 10 May 2002 03:29 AM (UTC)  [ quote  ]
Message
Yes, I suppose so.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] 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.

6,774 views.

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

[Reply to this subject]  Reply to this subject   [New subject]  Start a new subject   [Refresh] Refresh page

Go to topic:           Search the forum

[Go to top] top

[Home]

Written by Nick Gammon - 5K

Comments to: Gammon Software support
[RH click to get RSS URL] Forum RSS feed ( http://www.gammon.com.au/rss/forum.xml )

[Best viewed with any browser - 2K]    [Internet Contents Rating Association (ICRA) - 2K]    [Web site powered by FutureQuest.Net]