Print

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

[Adeon]

This is Dfterm3, a remote Dwarf Fortress playing software for multiple users through a web interface.

GitHub page.

Downloads
Dfterm3 is composed of two pieces: A dfterm3 plugin for dfhack and a dfterm3 server program. Install the dfterm3 plugin for dfhack and run the server while DF is running.
 
Windows binaries:
Download Dfterm3 0.3.1 installer.
Download Dfterm3 plugin (DFHack 0.34.11-r3).
Download Dfterm3 plugin (DFHack 0.34.11-r4).
Download Dfterm3 plugin (DFHack 0.34.11-r5).

Linux binaries:
(no Dfterm3 server binaries)
Download Dfterm3 plugin (Dfhack 0.34.11-r3).
Download Dfterm3 plugin (Dfhack 0.34.11-r4).

Linux version does not work well. Make sure to check current issues for the linux version. In particular, PRINT_MODE:TEXT does not work and there are some serious issues with CPU usage.

Old versions:
Download Dfterm3 0.3 installer.
Download Dfterm3 0.2 zip file.
Download Dfhack with the Dfterm3 plugin. (you need this instead of the vanilla Dfhack)

Installation and usage instructions

Run the installer and then launch Dfterm3.

Install the Dfterm3 plugin to a Dwarf Fortress installation you want to expose to Dfterm3.

Now, start the Dwarf Fortress and in the Dfhack console, enter the following command:

Code: [Select]

start-dfterm3

If Dfterm3 is running, it will take at most 20 seconds for it to connect to the Dfhack. You will see connection has happened if you follow the messages in either Dfhack console or Dfterm3 console.

Once connection has been established, go to the administrator panel: http://127.0.0.1:8081/

The Dwarf Fortress that is running should appear below "Unregistered Dwarf Fortress games". From here, you can write a name for the game (that name will be shown to players) and click "Register". After the game has been registered, it can be seen and played from the playing interface: http://127.0.0.1:8080/

You can give out the playing interface URL to other people so they can connect to your Dfterm3 server. For this, you need to replace the address 127.0.0.1 part with your own IP address or host name. Before a player can play or chat, they need to enter a nickname to the login box.

Ports to open (port forwarding)

If you are behind a firewall or a NAT, you might want to know which ports to open. The ports are:

• 8000 The Websocket port.
• 8080 HTTP server that serves the playing interface.

You don't need to forward port 8081 because the administrator panel is not served outside localhost anyway. You can change the ports to use by giving command line options. (try dfterm3.exe --help). There are some instructions at http://portforward.com/ for specific routers should you require help.

Source code repositories

Dfterm3: https://github.com/Noeda/dfterm3.git

Bug and issue reporting
Report bugs, feature requests and other issues at the GitHub issue tracker: https://github.com/Noeda/dfterm3/issues. Alternatively, you can post here; however, it is easy to forget to fix something if the bug report is not somewhere easily trackable.

Changelog
From v0.3 to v0.3.1:

• Windows platform: fixed installer not installing some web interface files.
• Fixed a potential crash bug in Unicode string handling.
• UI changes.

From v0.2 to v0.3:

• Windows platform: there is no administrator password by default and you are never asked for one.
• Windows platform: There is now an installer.
• Windows platform: Dfterm3 has an icon.
• The plugin should not lose connection quite so easily anymore.
• You can see a list of players currently watching a game, as well as when they join and leave a game.
• When playing, you need to give your nickname right away (as opposed to giving it only if you want to play or chat).
• It is now possible to manually add Dwarf Fortresses to Dfterm3 in administrator panel.
• Minor cosmetic and informative changes in various parts of the web user interface.

From v0.1 to v0.2:

• User interface improvements in various places.
• WebSocket port is no longer hardcoded to 8000 in the client interface.
• Implicit parameters to dfterm3 can be turned off with --no-default-ports parameter.

Fixed issues:

• Not all keys work properly.
• The Linux version does not work properly. It compiles but launching Dwarf Fortresses does not work.
• Dfterm3 uses more CPU than it needs to.

Relation to Dfterm2

This is a completely new codebase and shares no code with Dfterm2. Dfterm2 only had a telnet interface; Dfterm3 only has a web interface. It is possible write a telnet interface to Dfterm3 and I might do so if there is demand for such feature. Dfterm3 also uses Dfhack exclusively to obtain the screen data from Dwarf Fortress; Dfterm2 had its own mechanism that did not involve Dfhack.

[Meph]

This sounds very interesting and I'd like to include it in my mod-pack, if it is possible to play mods with this of course. The greater number of players might help find and squash some bugs as well.

[Adeon]

This sounds very interesting and I'd like to include it in my mod-pack, if it is possible to play mods with this of course. The greater number of players might help find and squash some bugs as well.

Dfterm3 is licensed under a very permissive ISC license. This means you can do almost anything with it without asking for permission, including changing its name and charging money for it if that is your cup of tea.

Tilesets are not supported and Dfterm3 requires Dfhack to be present in Dwarf Fortress but otherwise, as far as I can tell, there should be no conflicts with mods. Dfterm3 will only see what is in the Dwarf Fortress screen so mods that have external user interfaces don't show up in Dfterm3. At the moment you have to use my version of Dfhack; however, I have asked my changes to be put in the official Dfhack repository, along with the Dfterm3 plugin.

I'd greatly appreciate feedback. Feedback lets me know what doesn't work and on what aspects I should focus on. If you put this in a modpack and that brings up players to toy around, I would be grateful.

[Putnam]

This sounds very interesting and I'd like to include it in my mod-pack, if it is possible to play mods with this of course. The greater number of players might help find and squash some bugs as well.

Masterwork's usage of the localization patch... should only cause problems with DFTerm2, actually. Nevermind.

(This is a PTW)

[Jaso11111]

I appear to be unable to set the administrator password. When i do the command it just gives me New Password: and i cant type anything.   

[Putnam]

I appear to be unable to set the administrator password. When i do the command it just gives me New Password: and i cant type anything.

I know on some terminals passwords don't appear to be typed but they are.

[Adeon]

I appear to be unable to set the administrator password. When i do the command it just gives me New Password: and i cant type anything.

Ah, I think I should have mentioned this on the post. This is one of those password prompts that don't display the ****** characters. This is how every UNIX password prompt that I know of works but understandably that scheme is not familiar with Windows users and just leaves them confused.

In other words, you can type the password; it merely looks like you are not typing anything. If you leave the password prompt empty, it will ask you if you want to disable administrator panel.

[Vabalokis]

Maxthon failed to load any ui
Safari didnt connect
Tor,Comodo Ice Dragon (both based on safari) and Comodo Dragon (based on chrome) gave me this :

Spoiler (click to show/hide)

after that , i gave up

[Adeon]

Maxthon failed to load any ui
Safari didnt connect
Tor,Comodo Ice Dragon (both based on safari) and Comodo Dragon (based on chrome) gave me this :

Spoiler (click to show/hide)

after that , i gave up

The web interface uses Websockets, which are a relatively new technology. My understanding is that it is only very recently they became enabled by default in the most popular browsers. The fact that the interface doesn't work well in several browsers is something I expected.

However, if it can get past the connecting phase (like it seems to have happened in that screenshot), the display bugs should be fixable. I suspect, judging from the last screenshot, that the problem may not be in the web interface. I will investigate once I can get to it.

So far, I have tested this on Chrome, Firefox and Opera and in all of them it works out of box.

[Vabalokis]

Tried it on opera , still the same as in my last screen but noticeably less lag and game itself is kinda playable up to the point when you need actual words to know what is going on

Spoiler (click to show/hide)

edit : just after posting this i realized how retarded i really am... i was trying to do all this with true type on and graphic tileset... after reverting to vanilla everything worked like a charm ...

[Jaso11111]

Hot damn! You did you magnifisent bastard! Me and a friend play together for a bit, he choped down some trees wile i dug out some rooms!
Sure it was lagy, a bitch to setup and the playing window in the broswer was way to big but those all things that can be fixed!
You have my outmost suport for this project (even if its not much ).

[Vabalokis]

Hot damn! You did you magnifisent bastard! Me and a friend play together for a bit, he choped down some trees wile i dug out some rooms!
Sure it was lagy, a bitch to setup and the playing window in the broswer was way to big but those all things that can be fixed!
You have my outmost suport for this project (even if its not much ).

Resize the game size and it will resize itself on browser too

[lethosor]

For better browser compatibility, this socket library looks like it would work (although there are probably other good libraries out there as well). I'd be willing to help rewrite parts of the web interface, if you need help with that

[DVNO]

nice.

There are some tile alignment issues, though. (PIC)

Gives a crazy lsd vibe. Don't know if bug or feature ....

[Adeon]

For better browser compatibility, this socket library looks like it would work (although there are probably other good libraries out there as well). I'd be willing to help rewrite parts of the web interface, if you need help with that

I would be very grateful if someone who actually knows how to make beautiful and functional web interfaces would help. I have barely have experience in user interface design. The web interface is in under web-interface/ directory in the source tree to play around. It should be possible to refine it without having to compile anything in Dfterm3. The administrator panel however, does not actually use the files under web-interface/ except for CSS files.

There is no documentation on the current Dfterm3<->Web protocol but I'll describe how it currently works here:

The connection is a Websocket connection using the Hybi10 draft specification. I think the Websocket specification has now has an RFC but the Haskell library I use for Websockets does not support that yet.

From Dfterm3 to the browser, every message is a binary message. The first byte specifies what the message is about:

• 1 - Screen data. I won't go into details how the screen data is encoded, it can be read from the source code.
• 2 - JSON message. The rest of the packet is UTF-8 encoded JSON that, on the top-level, is an array. The first element in the array is a string that describes what the message is about and that to expect in the rest of the array:
  
  • "who_is_playing" - The second element of the array is the name of the player who last gave input to the Dwarf Fortress game we are watching right now.
  • "chat" - The second element of the array is the name of the player who is talking and the third is the contents of the chat message.
  • "game_list" - The second element of the array is another array where each element is an array of two elements, the first one is the name of a game and the second is an index that the client can use to refer to a game when it talks back to Dfterm3.
• 3 - Login failed (the rest of the packet is empty)
• 4 - Login succeeded

From the browser to Dfterm3, all messages are text messages. The first character determines what the message is about:

• "\x01" - Choose a game to watch. The rest of the message is Unicode-encoded index that was received from the "game_list" message as described above. Note that it may take up to 20 seconds before the server responds and there is no separate "game watching succeeded" message, you'll just start getting screen data.
• "\x02" - Stop watching a game and receive a new list of games.
  
• "\x03" - Send a chat message. The rest of the message is the contents of the message. The server will ignore this message if the user has not logged in.
• "\x04" - Log in. The rest of the message is the name you want to login with. The server will truncate this to 20 Unicode code points. Wait for acknowledgement (see above) before assuming logging succeeded.
• "\x05" - Send key input. The message after the first character is a JSON-encoded object with following keys and values:
  
  • "which": This is a virtual key code value. The name comes from the field in the keyboard event object it is taken from.
  • "code_point": Unicode code point this key corresponds to. It can be 0 if the key has no such representation.
  • "shift": Boolean, true if shift was pressed down when this key was pressed.
  • "alt": Boolean, same as shift but for alt key.
  • "ctrl": Boolean, for control key.

If that's not all of the messages used in the protocol, it is most of it. As you can see, it is a mixture of JSON and custom formats. I think it might be better to encode most of the things in JSON, with the possible exception of screen data that is sent very frequently and the messages can be quite large. Changing the protocol is quite easy. I didn't quite spend time trying to design it properly as I felt there were more important things to develop at hand.

I took the trouble to document this protocol in the vain hope that someone appears with an alternative or modified interface that is better than what I currently have there.