Learning Mapper Database getting too big

I'm having trouble with the learning mapper causing bloat, plugin failing to load, and subsequently crashing the plugin and deleting the entire database. The MUD I'm playing on (AwakeMUD) is rather large, admittedly, and room descriptions can be very descriptive, leading to 2k+ rooms added to the database.

Is there some method I can use to avert this crash, and subsequent loss of the map? I've been combing the forums for weeks and not found a solution.

You shouldn't lose everything. At the very least I would suggest making a backup of the mapper data (the state file) which you will find in the plugins "state" directory.

Its name will have "99c74b2685e425d3b6ed6a7d" in it.

For example, under Wine, the directory is:



My state file is:



Yours will have a different hex number at the start, which is the unique ID of your world file.

If you copy this somewhere else then you have saved the "good" file from your last run. Of course, don't copy it if the file seems corrupted. Preferably make a script to copy each time under a different name with the date/time as part of the name. Then you can always revert back to a good copy of it.

If things go wrong, put the copy back under its original name.

For a longer term solution I'll look at storing the mapper database as an SQLite3 database rather than into a plugin state file. That should be much more robust. However that may take a few days to write and debug, so as a temporary solution I would be making backups.

Side note: The state file maximum size limit isn't very large (looks like 5mb? https://github.com/nickgammon/mushclient/blob/6b79a6d88ea811f797b143623e839eed07fa9802/xml/xmlparse.h#L8). I had to switch from storing intermediate data in the state file to storing it in a separate file for one of my plugins because people were experiencing crashes during reload of my chat capture plugin when they had a large amount of text captured. https://github.com/fiendish/aardwolfclientpackage/commit/e2d79fcb3d064904619d86781a2b664b5d069044

Maybe we should make it larger as an interim solution?

We could. What's a good size though in 2022? 100? 200?

Ok, I increased it in https://github.com/nickgammon/mushclient/pull/75
But it seems so wasteful. The plugin should probably just be updated to write to plain files instead of the state file.

Anyway, Faedara, as an interim stopgap solution until Nick updates how the plugin saves its data, this MUSHclient executable should work around the issue at the expense of a bit more RAM used: https://github.com/nickgammon/mushclient/releases/download/latest_commit/MUSHclient.exe

Just replace your current exe with it.

Wow, ya'll are an incredible team. I was expecting something along the lines of, "You forgot to update how much allocation is applied by this setting", not "I updated the client within a day to solve your problem, and we're rewriting the plugin to prevent similar future problems."

Absolutely astounding~ <3 Thank you.

Fiendish's change is to allow slightly more than 20 times as much when reading an XML file. 100 MB to be precise.

I want to do it with a minimal amount of extra work changing the plugin (because I am lazy). Perhaps serializing the plugin data (to a disk file) rather than putting it into a state file would be the simplest solution.

I don't think it is particularly wasteful. That line that you changed is just a sanity check to not load too large files. The memory isn't actually allocated until the file is read in.

And if it is serialized a different way it will still take the same amount of memory. Unless it is rewritten to use the SQL database, which would be quite a lot of work.