Print

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

[Kazimuth]

What do you mean "at once"?

As in, what portion of the map is sent to the client? How quickly do map updates happen? (My wording was kind of confusing, though.)

Also, would it be possible for you to give a quick overview of how the server works?
From a little bit of reading, it accepts connections using enet, and sends messages using a mix of a custom binary format (for maps?) and msgpack. Is there anything else going on / planned?

[mifki]

Well, the updated tiles are sent. And DF is set to render 5 frames per second only. Upon connection, the entire map for the current z-level is sent to the app.

Yes, it's enet+msgpack, excluding map/status updates and number of commands for historical reasons.
What are you going to do? I can give an exact description of message format and then it's fairly easy to see what each of the commands accepts/returns.

[Kazimuth]

I'm thinking about integration with Armok Vision. The current protocol it uses doesn't support most of the features dfremote's does, and is only really fast enough to work locally. I think switching over would be pretty awesome, and I like the idea of a unified DF remote protocol.

A description of the message format would be great.

[mifki]

ok, terrible description below


The command format is:

app to server: <cmd> <seq> <parameters>
server to app: 0x80 <seq+1> <response>

Historically, there are two types of commands.
Commands with numbers < 0x80 have raw binary parameters and return value and command number is send as 1 byte.
For other commands, command number is sent as two bytes (command/subcommand) and parameters and response are msgpack-encoded arrays.

Also, server may send:

0x82 <seq+1> <errorstring>

if there was an error (Lua exception) while processing the command.

For map and status updates:

<flags> <status1,status2><extended data><center data><map data>

all the fields are optional and present if corresponding bit of flags is set (0,1,2,3 from the left).

status1/status2 are sent only if changed and are the current game (UI) mode, extended data is msgpack-encoded additional data, sent only if changed. For example, for unit [v]iew mode it will be
24,0 if there's no unit selected and 24,1,unit_name if there's a unit.

center data is sent if the current view centre has been changed on server side (announcement, zoom to unit, following unit, etc.)

map data is current z-level followed by an array of x,y,tile,fg | (bg << 4) bytes

This will be changed in future! First, to support multi-level rendering and creature graphics, and second because currently it supports only maps <= 256x256.

If response is longer than 500 bytes, server will compress it and send:

0x81 <deflate()-compressed original reponse>


Connection sequence:

client connects and sends cmd 238 subcmd 4, parameters: protocol version that the client supports, password hash or empty
server responds with server version and game status - this is to query server status without actually connecting to the game

then, if the server version is supported,

client sends cmd 1 with parameters (in binary): token (4 bytes), protocol version, password hash
server responds with whether_the_token_matched, new token, server version. At this moment server will disconnect the currently connected client, if any, and clear map cache if tokens didn't match.

token is generated randomly in the app and the updated with the server version and is preserved, and is used to track a single session, so that app may disconnect and not need to reload map and some other data next time. if another client connects, this will reset.

then:
app sends <238>,<5> to get map info
app sends <15>,<dimx>,<dimy> to set map view dimensions to render
app sends <30>,<cx>,<cy> to set map center
app sends <238>,<1> to get list of designations
app sends <238>,<2> to get list of building commands
app sends <238>,<3> to get list of labors
app sends <17>,<block_number> to start preloading map for the current z-level and repeats that until server says there are no more blocks. If client does not want to preload map, it needs to send <17>,<255> because server also starts rendering and sending map updates when there are no blocks to preload


Commands/responses are never resent in case of network issues, all messages are sent with Enet's reliable flag and in case of disconnection and reconnection, if the token matched, they must be resent and responses to previous commands will be received. This is to preserve synchronisation of UI state between server and client - if some command is sent, the client will either receive a response and be sure that the server is in an expected state, or the client will disconnect.

[Rose]

I'm thinking about integration with Armok Vision. The current protocol it uses doesn't support most of the features dfremote's does, and is only really fast enough to work locally. I think switching over would be pretty awesome, and I like the idea of a unified DF remote protocol.

A description of the message format would be great.

Actually, the low update speed in armok vision has nothing to do with the socket speed. that's actually pretty fast. It's mesh generation and updates, mostly.

DF Remote just copies the tiles directly from the dwarf fortress screeen and displays them, while armok vision has to work with a lot more data.

[Kazimuth]

Actually, the low update speed in armok vision has nothing to do with the socket speed. that's actually pretty fast. It's mesh generation and updates, mostly.

DF Remote just copies the tiles directly from the dwarf fortress screeen and displays them, while armok vision has to work with a lot more data.

Oh, I didn't mean that it's currently causing slowdown - Armok Vision is hella fast for the amount of work it's doing. I meant that it would cause slowdown if you tried to run Armok Vision over a network. The problem is that it uses blocking RPC calls over TCP (...at least I think over TCP?), which can pump through gigabits locally, but will become a lot slower if you try to connect to a remote server, since you have to do a network round trip for every call. Using a remote server isn't an explicit goal for armok vision, but it would be nice to have. (Imagine running armok vision in your browser with the unity web client.)

EDIT: ...although actually reading through the protocol, it appears that df-remote is blocking too, so maybe my fears are unfounded   

[mifki]

What do you mean by "blocking"?

[Rose]

Means waiting for a reply before the program continues.

[mifki]

Means waiting for a reply before the program continues.

Continues what? If it's about UI, it has nothing to do with the protocol.

[Kazimuth]

Continues, like, sending messages - if you can only send one at a time, and have to wait for the reply before you send another, I would think of it as "blocking", even if it's not blocking the UI. Although that might be the wrong word.

One other question: Do you have to be synced with the in-game UI to do things in dfremote? Like, if I want to add a food at a kitchen, does the in-game building menu for that kitchen have to be open?

[mifki]

Continues, like, sending messages - if you can only send one at a time, and have to wait for the reply before you send another, I would think of it as "blocking", even if it's not blocking the UI. Although that might be the wrong word.

This is handled by Enet so that you don't do any blocking in the code. Some commands naturally require blocking the UI, like confirming something and closing a view when response is received, while others are just sent for each UI event without blocking, like marking items in a depot.

Commands are processed in order, but Enet supports several channels, so theoretically, for example, map updates can be separated from everything else.

One other question: Do you have to be synced with the in-game UI to do things in dfremote? Like, if I want to add a food at a kitchen, does the in-game building menu for that kitchen have to be open?

It depends. Most actions do not require any screens other than the map screen to be open, but there is some early code that does. However, specifically building actions currently do require the building to be selected.

Basically, the game always stays on the main screen, but its mode (df.global.ui.main.mode) is synchronised between df and app.

[Isaacc7]

This project looks amazing, looking forward to trying it out. In my dream world there would also be a version for the Apple TV. I have no idea how much code could be shared between an iOS app and an Apple TV app. I know you're a developer, have you jumped into that world yet?

Anyway, thank you so much for making it possible to play on my iPad!

[mifki]

This project looks amazing, looking forward to trying it out. In my dream world there would also be a version for the Apple TV. I have no idea how much code could be shared between an iOS app and an Apple TV app. I know you're a developer, have you jumped into that world yet?

Anyway, thank you so much for making it possible to play on my iPad!

But you can just connect computer or iPad to Apple TV...

[Isaacc7]

This project looks amazing, looking forward to trying it out. In my dream world there would also be a version for the Apple TV. I have no idea how much code could be shared between an iOS app and an Apple TV app. I know you're a developer, have you jumped into that world yet?

Anyway, thank you so much for making it possible to play on my iPad!

But you can just connect computer or iPad to Apple TV...

Well sure if you just wanted it to be bigger. There's a big difference between having your head buried in your phone or iPad while its up on the tv and actually playing it on the tv. It would be a very different experience. TVos allows native apps to run on the TV. I have no idea how good an experience it could be but it would certainly be different. Totally understand if you don't think it's worth the effort and headaches but I'd be interested in seeing it.

Actually, if it were possible to shoot just the game screen on the TV and handle the input on the phone that would be great too. Kind of like how apps like YouTube work where the chrome and information are on the phone but the video is on the tv. That would be cool too.

[Urist McCoder]

The apps interface is really intuitive. Definitely four dollars well spent. Thank you for this mifki.