Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  

Author Topic: Remote DT  (Read 1454 times)

Hello71

  • Bay Watcher
    • View Profile
Remote DT
« on: August 28, 2014, 09:18:49 am »

making new topic since I doubt most people follow the DT thread.

would remote access for DT be useful for anyone?
Logged

Putnam

  • Bay Watcher
  • DAT WIZARD
    • View Profile
Re: Remote DT
« Reply #1 on: August 28, 2014, 03:55:41 pm »

Yes, extremely. DFTerm, DFeverywhere and any other multiplayer DF programs would get a great boon from this.

Hello71

  • Bay Watcher
    • View Profile
Re: Remote DT
« Reply #2 on: August 29, 2014, 05:04:51 pm »

for remote DF coders:

what would be the best interface? I was thinking a regular TCP connection with a basic C program (less dependencies) on the other side. all it needs to implement is read_raw, write_raw, and remote_syscall anyways. something more flexible would be a local unix socket or something that could be attached to by socat or the custom transport used for DF.

there is a bit of a security concern, since the remote DT has effective remote code execution on the DF process; removing this concern would mean a significant amount of work for little gain.

thoughts?
Logged

Rayston

  • Escaped Lunatic
    • View Profile
Re: Remote DT
« Reply #3 on: August 29, 2014, 06:37:36 pm »

I envision something like remote nethack

http://nethackwiki.com/wiki/Public_server

though I would love one that was compatible with the various utilities like dfhack, dwarf therapist, stonesense overlay, soundsense, twbt, and abilities to customize settings including lua scripts and the like 
Logged

hazzey

  • Bay Watcher
    • View Profile
Re: Remote DT
« Reply #4 on: August 30, 2014, 07:04:37 pm »

I like the idea of the interface being coded in html5/JS.  Or maybe at least having the interface interact via RPC calls.  That could make it very mod-able.  It would allow the GUI to be completely separate from the backend. 

Of course this would make it a more complicated change from the existing codebase. Any progress would be interesting.
Logged