These changes are great, especially the redrawing of the vtmap and #map list to variable changes. Thanks for the updates!

Looks like there may be a possible defect with some of the changes regarding room symbol handling. In some of my maps I have set the room's symbols as such- Room symbol: <029>D<099>

When the mapper renders it (at least in the vtmap mode, I didn't confirm others), the spacing of the map gets out of whack because the brackets are no longer rendered ie it should be: [D] and instead becomes just D. The map renderer doesn't compensate for the brackets not being present and/or the zero width color characters? This is new since moving from the previous beta build (from ~sometime this summer) to this version, the previous version rendered this situation correctly.

Regarding the square brackets "[ ]" from what I remember from recent stuff in the map drawing code for the ASCIIGRAPHICS mode those were only used if NO symbol was set or they were put around a symbol with only one character... You can, of course, put those back into a symbol manually for that map mode though that won't help if you use the SYMBOLGRAPHICS (I think) and switch to using the single character symbol map mode as an alternative.

Personally I have a situation where I've really hacked over the map drawing code so that I can use a Unicode Font that I've modified with custom glyphs for drawing rooms and exits, I also created a few custom glyphs for room symbols. I also want to share some of the maps I make (using #map map in HTML mode) so I needed to have a set of glyphs to use that were publicly available. I found it was feasible to store both room symbols in elements stored in the roomdata field and to load the appropriate one into the roomsymbol field as required - it takes a few seconds to loop through all the rooms to swap the symbols over so this can be a way to cope with wanting something other than the first character of the symbol field in ASCIIGRPAHICS mode to be used when NOT in that mode...

I can confirm all previously reported issues fixed with this build. Another weird issue popped up now, but I'm not sure that I'm able to reproduce it 100% of the time. After a few minutes of the terminal window being open (and during that time period the action for my hpbar firing repeatedly) it just magically stopped complaining and worked correctly. Ran tt fresh again a few minutes later and it started complaining again.

I have a hpbar set up that uses an #action to capture the lines of text, process them, and create a reformatted replacement hpbar. I then have a #prompt to match the same line as the #action (yes, I realize this is redundant) and place the reformatted hpbar string into the bottom screen split. Since sometimes it results in text too wide for the terminal size, I created a utility function to automatically cut the size of the string down to the terminal width, and also escape some characters so that tt wouldn't complain when it echoed them.

What I'm seeing now is the prompt reporting the string is too wide, although I know it's not.

I'm not sure why it's reporting the length to be almost double what it displays as on the screen- doing a normal #echo of the var has no problems. Other than this minor issue, everything else so far looks good.