I have been looking at it more and it seems like outside of interfacing with DF this could be handled entirely on the LUA side by defining a new state of locking (and associated flags), and a full screen overlay.
Here is what I was thinking:
M|C C W|M S A A H T S|
i|a r o|a t n n u r m|
n|r o o|s o i i n a a|
i|p s d|o n m m t p l|
n|e s C|n e a a i p l|
g|n s u|o D l l n i A|
|t s t|r e T C g n n|
|r M t|y t r a g i|
|y a t| a a r m|
Dorf1 0|0 0 0|* * * 0 0 0 0
Dorf2 *|* * 0|0 0 0 0 0 * *
Dorf3 0|* 0 *|* * 0 0 0 0 *
Dorf4 *|0 0 0|0 0 0 0 0 0 0
With actual shortening of the names, you could probably fit nearly 20 dwarves, how many disciplines would depend on how much room is left for dwarf names, assuming 13 that leaves enough room for 33 per page, which fits into 2 pages worth I think.
A selection icon similar to used in the game with a semifamilar paging method (either umhk or shift, or whatever) would make is usable in my opinion, and still significantly faster for a lot of the simple tasks than the in game UI.
Obviously the binary would need to provide the data and consume updates for this to work, but it is by no means impossible.
A Dwarf Therapist -like UI screen has been on my TODO-list but so far I haven't bothered with it yet. I've also been thinking of DFHack integration but because I reinvented the wheel and memory hacking part itself seems to work pretty reliably now, I probably won't bother with that yet.
Keep up the good work, although I will say a simple Dwarf Therapist style assignment mode would be the only thing it appears to lack, but of course that would require a GUI rewrite from what I can tell since no one makes text based GUIs anymore it seems .
Text is best. Graphics for losers! Boooo.
I'm thinking of making some bindings to DFHack if I'll expose some memory hacking functions to the lua script. But I haven't even checked if DFHack can handle multiple DF sessions at once, which is a must-have at the moment. I could always modify it though, if that's easily done.
Failing that, I can always do some more duplicate work...
I've been doing Windows compiling of the program on a Debian Linux with mingw32 installed. The building system is a card house and some libraries (modified SDL for some versions (there's the file that's been modified, but I'm going to phase out modified SDL for DLL injection), pdf manual (there's a tex file), some other DLL files) are not included in the git repository.
For the input problems I'm considering changing the way input is sent to DF. I have not been able to reproduce input problems. Currently it sends them to DF window with standard Windows messaging (PostMessage with some DLL injection to handle some key states) but now that I've seen some reports of input failures, I probably should change the method (perhaps with inline API hooking some functions from inside DF).
I've been collecting <a href="
http://genodeen.net/index.clua?df_stuff>here[/url] some stuff I want to implement. Things may proceed slowly because current dfterm code is a mess (I never expected it to grow beyond a simple one-day experiment) and because I'm lazy.
What format were the screen contents in for 40d?
For 40d and v0.31.03, dfterm uses a memory region, that has different buffers for each of attributes, symbol, red, green, blue, background red, background green, background blue, as 32-bit floating point values laid out by column, always at size 200x200.
There are several places for screen contents in many of the 40d16+ (dfterm started when 40d16 was out) series. The place dfterm uses has a format "S F B I", where each of the letter is one byte. S is symbol, F is foreground color, B is background color and I is intensity or boldness. So each tile in the screen is 4 bytes, or 32 bits. Symbol is a CP437 character code, F and B are DF colors (in range 0-9, if I recall correctly), I determines if foreground color is bright.
The tiles are laid out by column. In some earlier 40dXX series the buffer was always 256x256, in some version it changed to be the size of DF screen.
I think the code is available for the structures dfterm is reading from.