Print

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

[Adeon]

I'm going to build a feature to dfterm2, that will allow linking separate dfterm2 servers together, so that games on both can be watched on either.

With that, a cluster of computers can be used to host a server that looks like a single one.

Some scenarios where I think it might be useful:
1. LAN of computers on which lots of DF are running. Let's say computers A, B, C, D and E. Only A is directly connected to the internet. You can run dfterm2 on all of those computers, and computer A then acts as a lobby for them.

2. Two friendly admins are both hosting dfterm2 servers. Then they decide they want to link them together. They link each other's slots on themselves, and then players who connect can play on either, and chat with users on both servers. Playing might be harder because of an added source of lag, but for watching it should not be a problem.

edit: anoying speling fixses

That sounds pretty freakin' awesome... but I'm skeptical as to how much it'd actually be used... Sounds like it'll be a bitch to code too...

The way dfterm2 is coded, it's not that hard to implement. It'd work by a special slot type.

Currently I have these slot types:
- Grab a running DF slot (win32)
- Launch a new DF process (win32)
- Launch a new process in a pty (linux)
- Grab a running DF slot and use DFHack (win32, developer version, still buggy)

I will add another special slot type:
- Linked slot

In this slot type, you have an additional setting to set remote server address and slot ID number. The dfterm2 server in the remote machine will get a notification, where the admin can then either accept or reject the linkage. The linked slot will be linked to another slot on a remote server.

After that, the server where the linked slot is automatically connects to the remote server when needed. In case the other server is down, it refuses to launch.

The feature is very doable. It does need some work but not incredibly. Personally I think the feature is interesting, even if nobody would use it.

[SolarShado]

Wow... even more awesome... I figured it'd be a massive undertaking, involving a lot of changes, but if it's so straight-forward... cool

[alficles]

(I've read through a fair portion of the thread, but I don't see the issue I'm having. I hope I'm not duplicating...)

I can't seem to get Shift+Arrow (really, Shift+Key) working. Capital letters work as expected but the fast move and the few places that use Shift+Enter don't work for me.

I'm using DF 31.12 with DFTerm2 version 0.3 (according to version.txt) running on Windows Vista 64-bit. I'm using PuTTY on Linux (Ubuntu 32-bit, fully updated), but its not impossible that I set something up wrong on the PuTTY side. Any ideas?

[Adeon]

(I've read through a fair portion of the thread, but I don't see the issue I'm having. I hope I'm not duplicating...)

I can't seem to get Shift+Arrow (really, Shift+Key) working. Capital letters work as expected but the fast move and the few places that use Shift+Enter don't work for me.

I'm using DF 31.12 with DFTerm2 version 0.3 (according to version.txt) running on Windows Vista 64-bit. I'm using PuTTY on Linux (Ubuntu 32-bit, fully updated), but its not impossible that I set something up wrong on the PuTTY side. Any ideas?

Short answer: It's impossible to get shift+arrow and many other shift+combination keys working.

Technical answer: This is because in vt102 there are no escape sequences for shift+arrow keys, and some others. Dfterm2 has no way to distinguish these keys from their non-shifted counterparts.

You can work around it by rebinding some keys in DF. For example, you can bind ctrl+arrow keys for fast movement.

[kaolbrec]

Code: [Select]

kaolbrec@iProstitute:~$ git clone git://genodeen.net/dfterm2
Initialized empty Git repository in /home/kaolbrec/dfterm2/.git/
remote: Counting objects: 1402, done.
remote: Compressing objects: 100% (636/636), done.
remote: Total 1402 (delta 958), reused 1100 (delta 765)
Receiving objects: 100% (1402/1402), 2.50 MiB | 292 KiB/s, done.
Resolving deltas: 100% (958/958), done.

kaolbrec@iProstitute:~$ cd dfterm2/

kaolbrec@iProstitute:~/dfterm2$ git submodule init
Submodule 'dfhack' (git://genodeen.net/adeon_dfhack) registered for path 'dfhack'
Submodule 'trankesbel' (git://genodeen.net/trankesbel2) registered for path 'trankesbel'
kaolbrec@iProstitute:~/dfterm2$ git submodule update

Initialized empty Git repository in /home/kaolbrec/dfterm2/dfhack/.git/
remote: Counting objects: 7175, done.
remote: Compressing objects: 100% (1598/1598), done.
remote: Total 7175 (delta 5521), reused 7136 (delta 5499)
Receiving objects: 100% (7175/7175), 1.85 MiB | 291 KiB/s, done.
Resolving deltas: 100% (5521/5521), done.
fatal: reference is not a tree: 3a33e64acc4da7270eef30ef595fc6f82eb72efc
Unable to checkout '3a33e64acc4da7270eef30ef595fc6f82eb72efc' in submodule path 'dfhack'


Trying to build this on 64-bit Debian... any help would be much appreciated. Judging by google, what it's looking for doesn't exist on the server?

[Adeon]

Code: [Select]

kaolbrec@iProstitute:~$ git clone git://genodeen.net/dfterm2
Initialized empty Git repository in /home/kaolbrec/dfterm2/.git/
remote: Counting objects: 1402, done.
remote: Compressing objects: 100% (636/636), done.
remote: Total 1402 (delta 958), reused 1100 (delta 765)
Receiving objects: 100% (1402/1402), 2.50 MiB | 292 KiB/s, done.
Resolving deltas: 100% (958/958), done.

kaolbrec@iProstitute:~$ cd dfterm2/

kaolbrec@iProstitute:~/dfterm2$ git submodule init
Submodule 'dfhack' (git://genodeen.net/adeon_dfhack) registered for path 'dfhack'
Submodule 'trankesbel' (git://genodeen.net/trankesbel2) registered for path 'trankesbel'
kaolbrec@iProstitute:~/dfterm2$ git submodule update

Initialized empty Git repository in /home/kaolbrec/dfterm2/dfhack/.git/
remote: Counting objects: 7175, done.
remote: Compressing objects: 100% (1598/1598), done.
remote: Total 7175 (delta 5521), reused 7136 (delta 5499)
Receiving objects: 100% (7175/7175), 1.85 MiB | 291 KiB/s, done.
Resolving deltas: 100% (5521/5521), done.
fatal: reference is not a tree: 3a33e64acc4da7270eef30ef595fc6f82eb72efc
Unable to checkout '3a33e64acc4da7270eef30ef595fc6f82eb72efc' in submodule path 'dfhack'


Trying to build this on 64-bit Debian... any help would be much appreciated. Judging by google, what it's looking for doesn't exist on the server?

I probably forgot to push the latest revision of trankesbel library to the server.

You can use 0.3 source tree that should work for now. I'll fix things when I can.

Code: [Select]

$ git checkout 0.3
$ git submodule update

EDIT: Should be fixed now. Also, I really meant dfhack library.

[liquidhot]

I just wanted to say thank you and dfterm2 is really great.

[kaolbrec]

Thanks. It builds just fine now. Only problem is getting DF to run in text mode... it just won't (Library hell)

[gamegreen33]

I keep getting an error when I launch DFTerm. I'm on XP and using the latest versions of DFTerm and DF. The error reads as follows:

"The application failed to initialize properly (0xc0150002). Click on OK to terminate the application." Thoughts?

[ShadowDrake]

I've got a suggestion for a couple of features...

Would it be possible to adjust the number of lines that the chat box displays by default? Or disable it on server alltogether? I often connect to my friend's copy of DF/DFTerm running on his PC/laptop and he doesn't run the same screen resolution I do. I'm primarily playing from a netbook (1366x768) so it doesn't leave me with much vertical screen real estate. When my friend plays with his window sized up a little bit, it explodes my display via DFTerm. I can sneak by by lowering the font size in putty, but we still need a little compromise.

We never chat using the built-in chat... we just use AIM/ventrilo instead. If we could remove that chat box all together (because it takes up a valuable 10 rows even with the borders turned off) that would be fantastic.

[Adeon]

I've got a suggestion for a couple of features...

Would it be possible to adjust the number of lines that the chat box displays by default? Or disable it on server alltogether? I often connect to my friend's copy of DF/DFTerm running on his PC/laptop and he doesn't run the same screen resolution I do. I'm primarily playing from a netbook (1366x768) so it doesn't leave me with much vertical screen real estate. When my friend plays with his window sized up a little bit, it explodes my display via DFTerm. I can sneak by by lowering the font size in putty, but we still need a little compromise.

We never chat using the built-in chat... we just use AIM/ventrilo instead. If we could remove that chat box all together (because it takes up a valuable 10 rows even with the borders turned off) that would be fantastic.

At the moment you can't disable it. The best you can do is use CTRL+F, and then CTRL+R on DF window to make it take all available space.

Something I can easily implement is CTRL+H (or some other key), that hides the currently focused window. What do you think?

I keep getting an error when I launch DFTerm. I'm on XP and using the latest versions of DFTerm and DF. The error reads as follows:

"The application failed to initialize properly (0xc0150002). Click on OK to terminate the application." Thoughts?

I have no idea. Quick googling says something may be up with DLL files and service packs.

EDIT: I tested in a Windows XP virtual machine to check that dfterm2 isn't broken on this OS. No problems observed. I'm afraid you are on your own.

EDIT2: Since it was so easy, I have implemented hiding windows in the current source tree and the feature will appear in next release. It will be on CTRL+X (CTRL+H conflicted with a very useful key).

[ShadowDrake]

I've got a suggestion for a couple of features...

Would it be possible to adjust the number of lines that the chat box displays by default? Or disable it on server alltogether? I often connect to my friend's copy of DF/DFTerm running on his PC/laptop and he doesn't run the same screen resolution I do. I'm primarily playing from a netbook (1366x768) so it doesn't leave me with much vertical screen real estate. When my friend plays with his window sized up a little bit, it explodes my display via DFTerm. I can sneak by by lowering the font size in putty, but we still need a little compromise.

We never chat using the built-in chat... we just use AIM/ventrilo instead. If we could remove that chat box all together (because it takes up a valuable 10 rows even with the borders turned off) that would be fantastic.

At the moment you can't disable it. The best you can do is use CTRL+F, and then CTRL+R on DF window to make it take all available space.

Something I can easily implement is CTRL+H (or some other key), that hides the currently focused window. What do you think?

I keep getting an error when I launch DFTerm. I'm on XP and using the latest versions of DFTerm and DF. The error reads as follows:

"The application failed to initialize properly (0xc0150002). Click on OK to terminate the application." Thoughts?

I have no idea. Quick googling says something may be up with DLL files and service packs.

EDIT: I tested in a Windows XP virtual machine to check that dfterm2 isn't broken on this OS. No problems observed. I'm afraid you are on your own.

EDIT2: Since it was so easy, I have implemented hiding windows in the current source tree and the feature will appear in next release. It will be on CTRL+X (CTRL+H conflicted with a very useful key).

Sweet! I didn't know about ctrl+f, but it's pretty helpful. Glad to see this added

[Adeon]

I've released dfterm2 0.4 with Windows DF 0.31.13 support.

You can read the changelog from first post. There are not many visible changes in this release, except for new CTRL+X key combination for hiding and unhiding windows.

I've worked on a p2p feature (related to the networked linked slots) but because the time I've spent working on dfterm2 has decreased a lot lately, I did not get it ready by the time DF 0.31.13 was out. I'll probably get it ready at some point.

There has also been work on dfhack backend but for the moment it's too buggy for use. It is not enabled in the release.

I've also removed public server list, because the servers were much less up than I hoped.

[Vigilant]

This is awesome... although i might not be able to use it until there's SSH since i think my university network dislikes telnet They say there's a port open for external access to servers, but i still can't seem to access my DFterm server unless i'm using the internal subnet IP.

EDIT: Actually this gets stranger since i did a canyousee me and the port check sites says they can see the service on the external IP and that port, but no telnet client can successfully connect to it...


Also : could we have it give ****'s when entering passwords? If i can get my server to ever play nice i might be using it in public which means i'd like people not seeing my password (even though sniffing telnet is easy lets not make it easier...

[spokehedz]

I'm going to build a feature to dfterm2, that will allow linking separate dfterm2 servers together, so that games on both can be watched on either.

With that, a cluster of computers can be used to host a server that looks like a single one.

Some scenarios where I think it might be useful:
1. LAN of computers on which lots of DF are running. Let's say computers A, B, C, D and E. Only A is directly connected to the internet. You can run dfterm2 on all of those computers, and computer A then acts as a lobby for them.

2. Two friendly admins are both hosting dfterm2 servers. Then they decide they want to link them together. They link each other's slots on themselves, and then players who connect can play on either, and chat with users on both servers. Playing might be harder because of an added source of lag, but for watching it should not be a problem.

edit: anoying speling fixses

That sounds pretty freakin' awesome... but I'm skeptical as to how much it'd actually be used... Sounds like it'll be a bitch to code too...

The way dfterm2 is coded, it's not that hard to implement. It'd work by a special slot type.

Currently I have these slot types:
- Grab a running DF slot (win32)
- Launch a new DF process (win32)
- Launch a new process in a pty (linux)
- Grab a running DF slot and use DFHack (win32, developer version, still buggy)

I will add another special slot type:
- Linked slot

In this slot type, you have an additional setting to set remote server address and slot ID number. The dfterm2 server in the remote machine will get a notification, where the admin can then either accept or reject the linkage. The linked slot will be linked to another slot on a remote server.

After that, the server where the linked slot is automatically connects to the remote server when needed. In case the other server is down, it refuses to launch.

The feature is very doable. It does need some work but not incredibly. Personally I think the feature is interesting, even if nobody would use it.

Now all you have to do is make a centralized server (or decentralized using a P2P protocol or whatever) and you would have quite an awesome product indeed.