Updates
I changed the name of the repository from "NannyMud" to "TinMan". I have rewriten the core modules of the framework so that they are mud agnostic so others can use it on any mud of their choice (and so I can use it to play on multiple muds without maintaining multiple versions of the code).

I have also started separating all the configuration from the modules so that all configuration is done in the "conf" directory. Using the framework should require no mucking with the modules or framework itself.

1. Rewrote module manager module to be more flexible. Modules can now exist in nested subdirectories in the module directory.
2. Rewrote the session manager class to read all configuration from separate files.
3. Rewrote the session manager class to work with any mud.

Updates:Funny: About a month ago, I decided I was going to start playing muds again. I downloaded TinTin, started relearning the syntax using some newly acquired programming skills. Over a month later, I haven't played at all and have probably invested 200+ hours in building a TinTin framework. I cannot wait to start playing. lol.

1. I had started attempting to build the framework to be mud-agnostic and cross-platform compatible. This started quickly becoming prohibitively time consuming, so I stopped. The framework will only run correctly on linux (and perhaps OSX). It's only designed to work with NannyMUD.

2. I had struggled with naming conventions and scope issues. I settled on a convention where each module stores its variables in a list specific to that module and functions and aliases store their variables in a list named after the function or alias. This does make the code undesirably verbose, but it has helped me avoid lots of problems as the size of the framework has increased. At the end of each alias or function I am able to clean up the temporary data by using #unvar on the one list, rather than every variable used in the module. At the moment, functions store the return variable in their list, so I am not cleaning up their data. However I intend to rework this so that return variables are not stored in the list and are instead stored in the default return variable, that way I can clean up their data. I will have to review my code to make sure that return data is immediately utilized before another function call to ensure that return values are not overwritten by subsequent function calls.

3. I had struggled with my module implementation and how to deal with persistent data. I experimented with implementing a module for managing persistent data (like LokiChaos has with his materiamagica framework), however for now I settled on an more simple solution where modules are not automatically loaded as a class and instead are read. This way I can define persistent data at the top of the file before opening the class, then when reloading the module the persistent data will remain. This system has much room for improvement, but it works acceptably for now.

4. My module manager and session manager modules are now "completed" and working. The session manager configuration has been moved to a completely separate file so if anyone else chooses to use this framework, they can add their own configuration without having to modify the core/sessions module.

5. I have added a bash launch script that accepts arguments. The framework can be started in the default mode, or in tmux mode (./tinnm -t). If started in tmux mode tt++ is bound to a single tmux session and loads a framework specific tmux.conf file which provides the appropriate configuration. When starting, the framework checks to see if it is running in a tmux session, if it is it loads the optional UI module, which adds features for managing tintin "windows" (tmux panes). When closing, the framework checks to see if we are running in tmux UI mode - if we are then it closes all the tmux panes in the framework's tmux session.

6. The tmux UI module is not quite finished, but is getting close. This module provides aliases for managing tintin "windows" (tmux panes). It maintains stateful information about the windows - the name, the pane index, the command running in it, the parent "window" (the pane it was split from), and the dimensions. This module provides commands for creating, killing, resizing, and updating windows. When creating a new window all "window" dimensions are updated.

7. I have started a status module which harvest data about each session and synchronizes this data in all the sessions. At the moment data like: hp, max hp, missing hp, sp, max sp, missing sp, toxicity, health saturation, and map location are collected. My intent with this is that future modules (such as autohealing) can move a second character to the first when their health is low, and automatically heal them.

8. I have started working on a mapping module. So far it just wraps the basic features, but it is "UI" aware and will "turn on" the map in a tmux pane or in a split, depending on the mode in which the framework is running. I've seen lots of threads about adding advanced features - and this is what I plan to move on to next. Features like: like scraping room names, descriptions, searching roomdata, automatically detecting map locations, detecting when the map location is out of sync with the actual location, etc.

9. I've added lots of libraries. Libraries are not managed by the module manager, but are loaded into corresponding classes.
There are libraries that provide colour definitions and colour-related utilities, standardization of status messages, log management, time-related utilities, and the ability to reload the framework from within tintin.

In the spirit of sharing, I've published it all (and will continue to do so) - hopefully someone else may find this useful, even if they don't play on the same mud. I've attempted to make the modules as non-mud specific as possible.
I'm also idling in #tintin on freenode IRC - it would be awesome if others joined so we had a place to talk and share about tintin in real time.

3. I had struggled with my module implementation and how to deal with persistent data. I experimented with implementing a module for managing persistent data (like LokiChaos has with his materiamagica framework), however for now I settled on an more simple solution where modules are not automatically loaded as a class and instead are read. This way I can define persistent data at the top of the file before opening the class, then when reloading the module the persistent data will remain. This system has much room for improvement, but it works acceptably for now.

I'm glad it (and the SQLite) code was helpful. One note, my method of persistent values is not simply to survive a rmmod/insmod, but leaving tt++ entirely. It is intended to allow a module to store data though client restarts or at the very least the end of a tintin session. However, your method is ideal for allowing a module to keep data though unload/reloading a module.