I was about to ask whether you are planning to make it 100% compatible with the existing client, and I gather not, from what you wrote recently. That’s fine too, I would do the same.
The plan is to keep it 99% compatible. Even if it means that I have to use wrappers to achieve some of it. I want it to be a drop-in upgrade and have existing scripts and plugins working as-is unless they're not written in Lua. So the only functionality/compatibility I am planning on breaking is WSH.
I have no idea on the current usage of non-Lua scripts (let me know if you do) but I imagine the userbase must have mostly turned to Lua after all these years.
Get rid of the Windows Scripting Host (WSH) and stick to Lua
Recompile without MFC
These two are top priority for the obvious reasons.
Modernise the dialogs (for example, a keybinding dialog to bind keys to actions), and allow them to resize in the modern manner to accommodate different screen sizes.
Also high on the list and Qt makes this and a lot more very easy. The tough part is completing the migration. :)
Get rid of stuff that would virtually be never used — Arrays spring to mind
I have never used this actually and I have not even looked up how it is implemented but like I said I want to retain compatibility on anything other that WSH.
Use STL instead of the MFC methods of walking lists (this will be a pain to get right). STL list walking is much simpler than MFC, because an iterator points to the current item in the list, whereas MFC advances the “pointer” to the next element in the process of giving you the current one.
I will be using QObjects and Qt container types wherever possible (because cross-platformness is guaranteed and implementations are optimized for each Qt supported platform) and the rest pure STL. MFC will eventually be striped entirely from the project.
Simplify exposed functions (at least partly). For example, there are multiple ways of finding the current world name WorldName and GetInfo
I could simplify a lot of this and use wrappers for retaining existing script functionality.
Improve the Help interface so that it works under modern operating systems. The help stuff is currently in a database, and there is currently a plugin that accesses that.
This was already high on my todo list. Help should be working without jumping through loops, heh.
Maybe make world files JSON rather than XML (obvious compatibility problems if you do that).
This I wouldn't do for two reasons. First is breaking compatibility, like you said, but my main issue is that JSON is not edit friendly for technically inept users.
Since we're not using a binary format, I'd rather retain the simplicity of XML, when a user who has no idea what any of that is, decides they need to edit their world file to fix/change something.
Simplify colour handling. I would just store 3-byte RGB colours for all style runs, not the mish-mash of methods currently used.
This is a great idea and just added to the todo list.
The Miniwindow stuff, like everything Lua related, will keep working. I make heavy use of that myself. I have written chat channel plugins for CthulhuMUD, deriving from those and extending them with things like toggleable "name mentioned" alerts, persistent scrollback buffer etc etc.
The plan is to extend functionality where possible or where it makes sense (eg make it possible to threadsafe offload scripts to worker threads) but existing scripts should keep working as-is.
In general, if you or Fiendish, or anyone else have any more ideas, or eg had specific things in mind, at some point, that would be cool but the current codebase makes it hard or tedious to implement, keep them coming my way :)