Print

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

[Vigilant]

0.6 is looking functional! I haven't run into any new problems yet.

[Adeon]

Added DF 0.31.14 support to dfterm2 0.8. I think I've released 3 versions in less than 24 hours. Maybe my record.

[Vigilant]

Added DF 0.31.14 support to dfterm2 0.8. I think I've released 3 versions in less than 24 hours. Maybe my record.

It really is quite impressive

[Tagert]

Hmm. Can't seem to figure it out. Running 0.8, 0.31.14 on a Linux server. Print mode is text. Is there something I need to do to be able to get colours working? (Using Putty to telnet in, UTF-8, allows colour encoding, courier font.) Also I'm assuming colour works because of the screenshot. >.>
Edit: Picture added by way of explanation.

Spoiler (click to show/hide)

[Adeon]

Hmm. Can't seem to figure it out. Running 0.8, 0.31.14 on a Linux server. Print mode is text. Is there something I need to do to be able to get colours working? (Using Putty to telnet in, UTF-8, allows colour encoding, courier font.) Also I'm assuming colour works because of the screenshot. >.>
Edit: Picture added by way of explanation.

Spoiler (click to show/hide)

It looks like TERM environment variable is wrong. Ncurses in DF does not use colors if this variable is not correct.

On the machine where you run dfterm2, set TERM=xterm.

E.g.

Code: [Select]

export TERM=xterm
./dfterm2

I think you can also add that to the df script in DF installation.

[Tagert]

It looks like TERM environment variable is wrong. Ncurses in DF does not use colors if this variable is not correct.

On the machine where you run dfterm2, set TERM=xterm.

E.g.

Code: [Select]

export TERM=xterm
./dfterm2

I think you can also add that to the df script in DF installation.

Excellent. Added it to the df script and it runs fine, though it still looks a bit off. (Appear to be missing the up/down slope icons) What font are you using in that screenshot?
Edit: 'nother screenshot.

Spoiler (click to show/hide)

[Adeon]

It looks like TERM environment variable is wrong. Ncurses in DF does not use colors if this variable is not correct.

On the machine where you run dfterm2, set TERM=xterm.

E.g.

Code: [Select]

export TERM=xterm
./dfterm2

I think you can also add that to the df script in DF installation.

Excellent. Added it to the df script and it runs fine, though it still looks a bit off. (Appear to be missing the up/down slope icons) What font are you using in that screenshot?
Edit: 'nother screenshot.

Spoiler (click to show/hide)

This time it looks like your locale settings for DF are not correct. If you look carefully, you notice only standard ASCII symbols are shown. Use an UTF-8 locale by setting an environment variable.

Check what locales you have by writing "locale -a" in a terminal. You need a locale that has UTF-8 in it (locales called "C" and "POSIX" are not good). Then, in the DF launch script, add this:

Code: [Select]

export LC_ALL=en_US.utf8
Replace en_US with what you had in locales. On my Linux system, I have a Finnish locale which is called fi_FI.utf8.

If you don't have any UTF-8 locales (I think almost all modern distributions have them by default), you need to set them up.

[Tagert]

Much better. Set it to en_US.utf8

Thanks for the assist!

And if anyone wants to give it a shot, see: http://www.bay12forums.com/smf/index.php?topic=66823.0

There's some connection instructions in there too.

[kaolbrec]

This might bear putting into the OP, for future reference. Came from either facepunch or somethingawful, I think. Can't remember. Very helpful though.

http://i.imgur.com/wvucu.png - Putty settings in screenshots.

[Adeon]

Little guide for Linux users, in case dfterm2 crashes:

You can compile a version with debug symbols in it by writing:

Code: [Select]

$ cmake -DCMAKE_BUILD_TYPE=RelWithDebInfo .
$ make

The build will be optimized but will also have debug symbols in it.


Then, you can enable core dumps and if dfterm2 crashes, a core dump file is created. Usually you enable them by setting a core dump file size limit with ulimit. The limit is usually zero by default, meaning no dumps will be created.

E.g.

Code: [Select]

Set maximum size for core dumps to be 512000000 bytes.
$ ulimit -c 1000000

Note that that setting is bound only to the current process and it's children and root is usually needed (so you may have to put the line somewhere deep in /etc init scripts or something). Your distribution may also have some other methods of enabling core dumps (also man core has information). In any case, I'll be able to debug much better with core dump files, because then I'll get to know exactly what the program's state was when it crashed. I'll also need the binary file (dfterm2 executable). Note that passwords and/or other information you may not want to make available may be present inside the core file (if they were in the program's memory at the time).

Linking this post from first post.

[Deon]

Thanks for this, I am going to try it now.

[PTTG??]

OK, here's a thought:

you could have multiple people logged into the same game simultaniously, if a bit sticky, in this way:

The server saves the camera position, cursor location, and any other relevant info, for each player. Let's say there are three, Players A, B, and C.

First, it moves the camera and cursor to A's saved location. You'd probably need memory hacking to do this fast enough. It sees what's there, and sends that info to A's client. A's client sends any new commands at this point, such as changing a dwarf's jobs, designating tiles, and of course moving the view.

At this point, it moves on to B's Client. Meanwhile, A's client still can recieve orders; it queues them up for later sending. While B's client is working, C is still waiting for it to be it's turn.

Hopefully, each client update, from moving the camera and cursor to openeing and selecting the right point in any menus, to transferring the commands and screen data, and finally finishing the update, would take only the equivalent of one in-game frame.

Of course, full-screen menus would automatically pause the cycle and give one player control.

Sound plausible?

[Deon]

We already play with a few people. Or do you mean something else?

[JanusTwoface]

I think he's looking for truly simultaneous control / true multiplayer.  Basically faking it by make the server track the game state for each player and switch between each of them when sending the frame to the clients.

My opinion: It's a great idea in theory.  It will explode horribly in practice. 

Basically, you're splitting the frames so you only get 1/n of whatever framerate you were getting earlier.  In addition, you have to keep track of a lot more information and update the game with that information each frame which will require one or more frames (to move the cursor, etc) which will cut into that even more.  So even if it works (and stays in sync), the framerates are going to be amazingly poor.

That's not saying that it's impossible, of course.  Just difficult.  And Adeon's done some rather impressive work so far, particularly with how flexible the slot system seems to be.

[Adeon]

The exactly same idea of multiplayer has been discussed before, I think twice. It'd be cool sure, but too much work to get right. So you won't see me trying to do this :-)