Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Adeon]

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:

Code: [Select]

        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.

[Guvante]

Sorry I have the bad habit of using GUI for anything, including command line interfaces ><.

May eventually poke around your code some more, will just have to figure out how to compile it first .

In either case a very cool tool.

[DrJonez]

Using putty, and I can connect and SEE the game, but I can't actually control anything. I hit control-A, my name turns red, but none of my keyboard input is recognized. I've read the manual, not sure what else I can try

Ran through the tutorial linked earlier in the thread, and all of my putty settings seem correct. Running on Windows 7 if that matters.

Help! I wanna make this happen so I can play DF from work!

[Guvante]

Using putty, and I can connect and SEE the game, but I can't actually control anything. I hit control-A, my name turns red, but none of my keyboard input is recognized. I've read the manual, not sure what else I can try

Ran through the tutorial linked earlier in the thread, and all of my putty settings seem correct. Running on Windows 7 if that matters.

Help! I wanna make this happen so I can play DF from work!

Here is the workaround I used, it requires starting DF from the machine but not too bad.

• Start DFTerm
• PuTTY into it
• After authenticating type /launchdf
• Change to the game window, and load your game
• Once the game is loaded you can hit Ctrl+A on the PuTTY window

It seems that the bug is averted by not gaining control until the game is fully running (aka not any title screen), you could leave the game paused, and you can even disconnect without causing any problems. Should work as a temporary solution until a fix is found.

[MooCow13]

Right now, you use PuTTY as your client, but wouldn't it be a good idea to make your own client that would be optimized to run DF, or at least one that would properly display the symbols and has access to all the DF keyboard commands.

Also an interesting idea... if you set up the server to be able remember the menus and XYZ position of the screen and the cursor, you could set it up so multiple people can play the same fortress at the same time. all of them looking and working on different things. You would just need the server to connect people on alternating frames switching every frame from one persons state to the next and only sending the client what he would see on his specific frames. The host would just see a bunch of cycling shit all over the screen, but the clients would only see what they were working on. I guess you would need to work something out for pausing the game, but it would be an interesting experiment.

[Adeon]

Right now, you use PuTTY as your client, but wouldn't it be a good idea to make your own client that would be optimized to run DF, or at least one that would properly display the symbols and has access to all the DF keyboard commands.

Also an interesting idea... if you set up the server to be able remember the menus and XYZ position of the screen and the cursor, you could set it up so multiple people can play the same fortress at the same time. all of them looking and working on different things. You would just need the server to connect people on alternating frames switching every frame from one persons state to the next and only sending the client what he would see on his specific frames. The host would just see a bunch of cycling shit all over the screen, but the clients would only see what they were working on. I guess you would need to work something out for pausing the game, but it would be an interesting experiment.

One of the main points in dfterm is that it works with any terminal client. Therefore, there will be no specialized client programs. At least not by me. Browser DF (if I ever get that ready) may extend that to browsers.

Your multiplayer idea has also already been discussed elsewhere. I concluded that it'll be too much of a hassle to get anything practical working, so it's not worth the effort.

[Silencer]

Right now, you use PuTTY as your client, but wouldn't it be a good idea to make your own client that would be optimized to run DF, or at least one that would properly display the symbols and has access to all the DF keyboard commands.

Also an interesting idea... if you set up the server to be able remember the menus and XYZ position of the screen and the cursor, you could set it up so multiple people can play the same fortress at the same time. all of them looking and working on different things. You would just need the server to connect people on alternating frames switching every frame from one persons state to the next and only sending the client what he would see on his specific frames. The host would just see a bunch of cycling shit all over the screen, but the clients would only see what they were working on. I guess you would need to work something out for pausing the game, but it would be an interesting experiment.

One of the main points in dfterm is that it works with any terminal client. Therefore, there will be no specialized client programs. At least not by me. Browser DF (if I ever get that ready) may extend that to browsers.

Your multiplayer idea has also already been discussed elsewhere. I concluded that it'll be too much of a hassle to get anything practical working, so it's not worth the effort.

I think this is a pretty cool thing you've got here, connected to the test server just fine, and managed to start up my own (and get it working!) on Win7 x64. In light of these "multiplayer" suggestions, I think it'd be interesting if multiple people could work in one world at the same time, in seperate forts. I know that this isn't probably the right place to toss it out, but I think it'd be an interesting idea in future versions of DF.

D:

[Beeff]

dfterm is awesome, Adeon.  I use it to play df on my macbook.  It took a bit of fiddling with the fonts, but it looks nearly perfect now.

The only 2 bugs being a pain in the ass are the shift+ keys not registering and the way you have to manually launch the game.  But these can be worked around.

Thanks for this!

[Rhenaya]

my colors in putty are off, it only recognizes red everything else is dark or light gray black&white df anyone? :x

EDIT: problem solved, dfterm doesnt like modified colors in the init file :x

[Lap]

It'd be nice to have a list of active games listed on the forums or something. Even better would be if you could have an option for the host to check that would automatically advertise their broadcast on some central server. Then we could load up that server and browse through all the different worlds.

It might also be worth trying to make this a sticky in the succession games subforum.

[DeMasked]

TIP: if all you're looking for is a way to remotely play Dorf Fort, VNC is perfect. However, this is an impressive project.

[Lap]

How's the speed and responsiveness of VNC compared to TeamViewer, if you've ever used that.

[Beeff]

VNC or remote desktop caused either df or the connection to slow down way too much.  So far dfterm has given me the best responsiveness.

[Calhoun]

dfterm also has the obvious benefit of allowing someone on the remote machine to keep doing things, and allowing multiple players. It also uses far less bandwidth.

[flowsnake]

I'm using the linux version, and dfterm never attaches to an already-running dwarfort process.