Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Kazimuth

Pages: 1 [2] 3 4
16
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?

17
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   :-[

18
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.

19
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?

20
This is amazing.

I have some questions about the server:

  • Is the API documented somewhere, or do I just need to read the code?
  • How much of the map is sent to the client at once?

22
No, I'm not against encryption, I'm just saying that currently it doesn't have it because there's higher priority stuff.
That seems entirely reasonable, given what a big project this is.

Also, it's not a simple HTTP or something that I can just "run over SSL" with one line of code. On the other hand, I'll consider adding a simple cipher like XTEA. The problem here is that individual messages are very short, while cipher operates on larger input blocks. I can pad data with zeroes but probably this will reduce security, I don't know.
LibreSSL actually provides a pretty simple library for using TLS with arbitrary buffers. I haven't actually used it though, so I don't know if it's easy to use.

Again, this thing does NOT allow to perform arbitrary dfhack/lua commands.
And surely dfhack has access to df process only.
Well, it also has access to the filesystem / the ability to run subprocesses. But if the protocol can't access those then things should be fine, barring fancy attacks.

The main reason I was asking about encryption was that people might run public servers, and they don't want to paint targets on themselves saying "use me for bitcoin mining!" But if the set of commands is limited to ingame DF stuff, that shouldn't really be a problem.

Seriously, though, keep up the good work - this project is great :)

23
PTW! This is really cool :)

A few questions:
  • Does the protocol support any sort of authentication / encryption? If it's going to be facing the internet, it really should; maybe using TLS or DTLS. (I don't really know security, but I know you're not supposed to do it yourself :D)
  • Is the Run Arbitrary Lua Code API call exposed? Because I would strongly suggest not exposing it. It's kinda scary.
  • How much does running the server slow down DF?

24
Some current screenshots I just took: http://imgur.com/a/bPmeo (linked for huge)

Also, if anyone is having trouble with the most recent OS X build, here's a version that should work:
http://dffd.bay12games.com/file.php?id=10803

26
Utilities and 3rd Party Applications / Re: DFHack 0.40.13-r1
« on: November 04, 2014, 08:06:31 pm »
A map block consists of a 16x16(x1) array of tiles. getTileBlock() returns the map block that contains a specific tile, while getBlock() returns a specific block.

Edit:
Spoiler: Example (click to show/hide)
getTileBlock(1,1) returns the block containing the red tile, while getBlock(1,1) returns the blue block.
Ohhh, okay. Duh. Thank you!

27
Utilities and 3rd Party Applications / Re: DFHack 0.40.13-r1
« on: November 04, 2014, 07:42:36 pm »
I have a DFHack API question: what's the difference between Maps::getBlock and Maps::getTileBlock? The only change I can see is that getTileBlock right-shifts its x and y indices by 4...
Going by that information, getTileBlock takes the coordinates of an individual tile, while getBlock takes the position of a (16x16 tile) map block.
I would guess something like that, except they both return a df::map_block*, and index into the same array. And each map_block seems to have a 16x16 array of tiles in it?

28
Utilities and 3rd Party Applications / Re: DFHack 0.40.13-r1
« on: November 04, 2014, 06:05:22 pm »
I have a DFHack API question: what's the difference between Maps::getBlock and Maps::getTileBlock? The only change I can see is that getTileBlock right-shifts its x and y indices by 4...
Also, how long will the return values of these functions be valid? They're just pointers into df::world.map.map_blocks, right? Will that ever shift its entries around?

29
DF Dwarf Mode Discussion / Re: .40.01: It was inevitable.
« on: July 09, 2014, 02:53:09 pm »
It is inaccessible from here.

30
This is awesome! Especially those drawings, Hounskull.
Can I be dorfed? 'Kaz' something, I don't care what prefession - it will be cool to have a dwarf here :)

Pages: 1 [2] 3 4