You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, Armok Vision assumes remotefortressreader listens from TCP port 5000 (or the env DFHACK_PORT if it exists) on localhost.
However, AV has the potential to serve as a DF network client (multiplayer at last! /s). Could you add an option in the startup prompt to specify to a remote server/port? Currently the prompt only asks for a preferred resolution, graphics quality, keybindings (which seem to be ignored on macOS), and whether it should be windowed.
It's probably possible to work around this with a SOCKS proxy, but an explicit option to specify a remote hostname/port would be much simpler (and require less overhead).
The text was updated successfully, but these errors were encountered:
While it is true that DFHack allows outside connections now, the RFR plugin requires quite a bit of work before it is suitable for using with more than one person at a time.
RFR isn't used merely for polling and pushing changes? What sort of client-specific data is stored during connections?
Though even without multiple connections, it'd still provide an interesting way to run DF from a server & play remotely, jumping from client to client as needed. (That applies even without AV, for a generic DF client that uses RFR)
Right now, it keeps track of what the client already knows. It would have to keep that data separate per client, or be re-written to be more intelligent about it.
Currently, Armok Vision assumes
remotefortressreader
listens from TCP port 5000 (or the envDFHACK_PORT
if it exists) onlocalhost
.However, AV has the potential to serve as a DF network client (multiplayer at last! /s). Could you add an option in the startup prompt to specify to a remote server/port? Currently the prompt only asks for a preferred resolution, graphics quality, keybindings (which seem to be ignored on macOS), and whether it should be windowed.
It's probably possible to work around this with a SOCKS proxy, but an explicit option to specify a remote hostname/port would be much simpler (and require less overhead).
The text was updated successfully, but these errors were encountered: