Print

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

[Solra Bizna]

I've had something like this for a long time. (Since some time before 2010, actually.) I used it regularly to "play" Dwarf Fortress on a 300MHz machine over the Internet and over laggy wireless. Now I've turned its guts into a general-purpose protocol, and released client and server code as open source... so I spent yesterday and today updating the Dwarf Fortress side of the equation, and finally released it in a form others can use.

Behold dfstream. It's a shim that sits between SDL and Dwarf Fortress, turning it into a TTTP server. In terms of utility, it's similar to dfterm (which I found out about for the first time today), but instead of using telnet it uses TTTP. TTTP clients can use any font Dwarf Fortress can, and have comparable display performance. It's not (and never will be) compatible with graphical tilesets or with TTF fonts, because of the nature of the TTTP protocol. (This version of the server also only runs on Linux, and *maybe* OSX. Definitely not Windows. Windows TTTP clients are totally fine, though, and someone who doesn't hate Windows programming the way I do is free to make a Windows version of the server.)

Because of the way it works, it's automatically compatible with new versions of Dwarf Fortress, and also with DFHack. (In fact, it might even be compatible with other DF-like games that can use 2D SDL for display.) I used the same prototype version of this shim for dozens of versions of Dwarf Fortress from 0.31.02 all the way up to 0.42.05, and---luckily, even when I switched to playing with DFHack---never once had to make a compatibility change. As far as Dwarf Fortress is concerned, it's displaying a totally normal window with a strange-looking font.

Install 32-bit PTH and GMP development libraries, do "git submodule update", and "make"... that should be all it takes to build. Directions for setting up, running, and connecting to the server are on the page I linked above.

Sorry about the messy state of the code. Some code from the original prototype-of-the-prototype is still in there, dating back to 2009, and in an attempt to avoid stepping on libstdc++'s toes I wrote it all in restricted GNU C99...

[funkydwarf]

BOOM! What the hell... This community never ceases to surprise. I was searching for a good way to do this for a while, finally give up and use a Google drive to sync multiple locations, and this hits from nowhere. I mean you been working on this for years? In seclusion like a strange mood dwarf?  Or did I miss this posted elsewhere long ago? Holy cow, nice work. Thank you for this. I will check it out. Thanks again!!

[Diamond]

Well, that come out of nowhere. A pleasant surprise, maybe I can try running a persistent multi-user fortress again.

who doesn't hate Windows programming the way I do

Why the hate, though?
I would really like to run this, but I don't feel like installing linux just for that. Also, I've heard rumors on stability of linux DF version compared to windows one.

And what is TTTP exactly? Never heard of it, couldn't find anything as well.

[Orange Wizard]

Oh, this is very cool.

It should probably go in the Utilities subforum though; there should be a Move button at the bottom of this thread.

[funkydwarf]

The stability of the Linux version was specifically for one of the other dead remote programs. There is a memory leak or something.

[Sizik]

And what is TTTP exactly? Never heard of it, couldn't find anything as well.

Looks like it's a protocol created by the OP: https://github.com/SolraBizna/libtttp

[Solra Bizna]

I mean you been working on this for years? In seclusion like a strange mood dwarf?  Or did I miss this posted elsewhere long ago?

Other than a cryptic mention in a bug report, I don't think I've ever publicly talked about this before.

who doesn't hate Windows programming the way I do

Why the hate, though?

Honestly, at this point at least 50% of it is just that "it's not UNIX"; I've been a UNIX programmer basically forever. The rest is issues with tools (You have not signed the agreement, Visual Studio will now self-destruct), with the silly ways DLLs work (don't get me started), with weird kludges layered on inconsistent behaviors layered on ancient bugs... and I'm especially annoyed that Microsoft deliberately removed UTF-8 as an API character set, forcing the use of UTF-16 if you don't want to subtly break in "international" situations. Sigh...

I would really like to run this, but I don't feel like installing linux just for that.

For years, my workstation has been booting into Windows, with its Linux partition relegated to a virtual machine on a single core. That's actually how I've been running DF for quite some time. Native booting just to run DF would be overkill, but a VM might be worth trying. VirtualBox is Free, Linux is Free. On occasion, when trying to debug a fortress dying a lag death, I've directly compared performance in the VM to native performance, and found only a ~2% drop.

And what is TTTP exactly? Never heard of it, couldn't find anything as well.

Looks like it's a protocol created by the OP: https://github.com/SolraBizna/libtttp

Correct. I'd used various iterations of the original "dfstream" protocol in various unfinished projects over the years, so I decided to make a general-purpose protocol for such things. Changing dfstream to use it was a logical step.

[DeDeRon]

...Microsoft deliberately removed UTF-8 as an API character set, forcing the use of UTF-16 if you don't want to subtly break in "international" situations. Sigh...

didn't know that, this beats everything. i'm so happy that the world finally seems to agree on using utf-8, but as usual, microsoft still tries to enforce *their own* standard. it clearly shows how evil this corporation is and that one should avoid using ms software if possible.

when writing software i don't bother supporting windows either.

btw.: kudos for using c as programming language (even c99 compatible!).

one suggestion for the protocol documentation: use markdown instead of html (if appropriate).

[Pidgeot]

who doesn't hate Windows programming the way I do

Why the hate, though?

Honestly, at this point at least 50% of it is just that "it's not UNIX"; I've been a UNIX programmer basically forever. The rest is issues with tools (You have not signed the agreement, Visual Studio will now self-destruct), with the silly ways DLLs work (don't get me started), with weird kludges layered on inconsistent behaviors layered on ancient bugs... and I'm especially annoyed that Microsoft deliberately removed UTF-8 as an API character set, forcing the use of UTF-16 if you don't want to subtly break in "international" situations. Sigh...

Windows never *had* UTF-8 support as an API character set. UTF-8 didn't even exist when Microsoft started working on Unicode support (Windows NT was officially released in July 1993 and worked on for several years before then; UTF-8 was first made public about 6 months before that release - not nearly enough time to rewrite everything).

UTF-8 has a code page ID, so you can convert the data without too much trouble, but it has never been a supported locale for the "ANSI" (i.e. non-wide/non-Unicode) functions. If it's ever worked for anything, it's pure luck, because the functions were never designed for it.

[Solra Bizna]

...Microsoft deliberately removed UTF-8 as an API character set, forcing the use of UTF-16 if you don't want to subtly break in "international" situations. Sigh...

didn't know that, this beats everything. i'm so happy that the world finally seems to agree on using utf-8, but as usual, microsoft still tries to enforce *their own* standard. it clearly shows how evil this corporation is and that one should avoid using ms software if possible.

They still support it in the sense that you can convert to and from it, using their character conversion functions, but they didn't do the thing everyone else did and start using UTF-8 as their native character set (or near enough). That's the part that trips me up. Every other platform, use UTF-8 throughout and if it doesn't work on somebody's system it's because they configured it that way on purpose. Windows... write an entire layer to convert between UTF-8 and UTF-16 and use Microsoft's non-standard wide functions. Bleh!

Of course, mixed-script Classic MacOS was far worse, but I haven't had to deal with that in over 15 years... Get off my lawn?

UTF-8 has a code page ID, so you can convert the data without too much trouble, but it has never been a supported locale for the "ANSI" (i.e. non-wide/non-Unicode) functions. If it's ever worked for anything, it's pure luck, because the functions were never designed for it.

It was briefly usable as the system ANSI codepage, but for reasons unknown they explicitly disabled support for it some time before NT 5.0. And yes, I do remember those heady years when it was believed that 16 bits was enough, and (what would later become) UTF-16 was the simple choice. Windows and Java are the only widely-used systems that still carry baggage from that time.

btw.: kudos for using c as programming language (even c99 compatible!).

I'm old enough that I remember my first C99 experience. So many wonderful changes! So many small annoyances fixed!

one suggestion for the protocol documentation: use markdown instead of html (if appropriate).

The scancode info is HTML because it's a giant table. The main document, I could probably convert to Markdown, but as it's already complete I don't see much use for that. I use Markdown for a lot these days, but I didn't when I started designing the protocol all those years ago.

I'm sick in bed today, so I just spent a few hours slightly reorganizing dfstream's code and adding a bazillion comments. Coincidentally, I made it run on more machines and it no longer uses any GNU extensions. (That I know of.) It'll probably work on OSX now with nothing more than a few Makefile changes. Windows server support is still out of the question (because of that pesky PTH thing) but, again, Windows clients can connect freely. Now that the code is commented, maybe somebody will decide to make a Windows version. Or integrate TTTP support into libgraphics, using the code as a guide?