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.
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.
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.
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:
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. ;)
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. :)
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?
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.
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..
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.
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.
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.
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. :)
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.
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.
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.
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.