Print

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

[Rose]

Nah, those two red text errors really shouldn't be errors. they should be logged when verbose logging is on, but that's about it.

[peterix]

There's no real documentation and the only example so far is dfhack-run.cpp - your best bet is to look at that and at the mentioned Remote* files. A bit can be understood by looking at the rename plugin, which extends the core protocol with some of its functions - look for "plugin_rpcconnect" in plugins/rename.cpp.

This looks great for C-based clients. But I don't think DFHack's RPC functions, as implemented, can be compatible with Java clients. This is because Java RPC clients rely on a service library compatible with the server. DFHack's RPC service appears to be homebrewed--I did not find any Java service library compatible with the style of function stubs it uses. (The stream object getting passed around in DFHack, seems to be the most serious hurdle here. Passing back return values as function arguments may be a problem, too.) Writing this Java service library from scratch would not be trivial.

This is disappointing, because I was quite hopeful that my Java application could make use of some functions in RemoteTools, especially SetUnitLabors().

Is there any intention of DFHack supporting Java client RPC in the future? I didn't see anything like "// Let's only support C/C++/C#!" when studying the code, which leaves me vaguely hopeful.

I know I can theoretically just write my own C++ middle-man to do RPC with DFHack, using protobufs service (or whatever) to talk to my Java app. (That would be a less intense headache than the other option, for me.) This could manage passing information between DFHack and my Java client. But in reality I doubt I would ever go this far. (This feature is not critical enough to the main function of my cross-platform application, to justify repeating any past "fun" I've had cross-platforming with C++.)

Well. Where to begin?

You send messages to DF and you get messages back (when it doesn't crash ). It's a network protocol. I don't want it to be bogged down with anything that implements any kind of RPC spec or conforms to anything with more than a few A4 pages worth of documentation required. And honestly, I'd much rather have just registered event handlers that can process and respond to *versioned* messages instead of actual 'procedure calls'. So this stuff may change when I actually start looking at it.

There's no part of this protocol that would prevent you from using it from any language with:

• Basic protobuf implementation. It's hard to find a language with no protobuf suport.
• TCP sockets.

Take a look at this for inspiration:
https://github.com/wjrogers/HeavyDuck.DF.DwarfDuck

I'm not sure how complete it is, but it's in C#, which should be reasonably close to Java (the DFHack protocol part is relevant).

[Antalia]

Well. Where to begin?

You send messages to DF and you get messages back (when it doesn't crash ). It's a network protocol. I don't want it to be bogged down with anything that implements any kind of RPC spec or conforms to anything with more than a few A4 pages worth of documentation required. And honestly, I'd much rather have just registered event handlers that can process and respond to *versioned* messages instead of actual 'procedure calls'. So this stuff may change when I actually start looking at it.

There's no part of this protocol that would prevent you from using it from any language with:

• Basic protobuf implementation. It's hard to find a language with no protobuf suport.
• TCP sockets.

Take a look at this for inspiration:
https://github.com/wjrogers/HeavyDuck.DF.DwarfDuck

I'm not sure how complete it is, but it's in C#, which should be reasonably close to Java (the DFHack protocol part is relevant).

I'm sorry, I must not have set out my question properly

Using TCP sockets in Java is easy.
And using protobufs objects in any language is easy.
These things I know

Sending a C struct as part of a handshake from Java to a procedure running in another language is not easy or trivial. (I might wager that's a reason libraries like protobufs exist.)
Sending a C stream object to a remote procedure call from Java is not trivial, either.
(The underlines are what I was concerned about. It seems odd to use protobufs if we'll have to delve into JNI to deal with the handshake and all the function calls anyway, from my side of things.)

Anyway I just wanted to clarify what I meant to ask--I don't require remedial help understanding sockets or protobufs. I suppose the answer is clear either way. For me, unless I find time to master JNI, my application won't be bothering with this. (It would have been nice, but it's not a big deal in any way.) Thanks for your guidance

[Quietust]

Sending a C struct as part of a handshake from Java to a procedure running in another language is not easy or trivial. (I might wager that's a reason libraries like protobufs exist.)

You're drastically exaggerating the complexity of the handshake "structure" - it's nothing more than an 8-byte character array and a 4-byte integer.

Sending a C stream object to a remote procedure call from Java is not trivial, either.

There are no "remote procedure calls" going on here, so this concern is completely irrelevant - all you are doing is constructing protobuf objects, serializing them, and pushing them across the TCP socket, at which point the DFHack server unserializes them, calls the appropriate local functions to do the work requested, then constructs a protobuf "reply" object and sends it (serialized) back to you over the TCP socket (which you then receive, unserialize, and interpret to get your results).

For me, unless I find time to master JNI, my application won't be bothering with this.

If you think JNI is required, then you've significantly misunderstood how this interface works - see above.

[ag]

Sending a C stream object to a remote procedure call from Java is not trivial, either.

There are no "remote procedure calls" going on here, so this concern is completely irrelevant - all you are doing is constructing protobuf objects, serializing them, and pushing them across the TCP socket, at which point the DFHack server unserializes them, calls the appropriate local functions to do the work requested, then constructs a protobuf "reply" object and sends it (serialized) back to you over the TCP socket (which you then receive, unserialize, and interpret to get your results).

And 'sending' that 'C stream' consists entirely in expecting to receive zero or more additional messages with text data before the main reply if something is written to it on the server.

[DrKillPatient]

I recently switched from Arch to Debian, and I'm having some issues building DFHack. When I run

Code: [Select]

cmake .. -DCMAKE_BUILD_TYPE:string=Relase -DCMAKE_INSTALL_PREFIX=(my DF folder)
I get:

Code: [Select]

CMake Error at depends/protobuf/CMakeLists.txt:60 (MESSAGE):
  Could not find a working has map implementation. Please update GCC.

-- Could NOT find Threads (missing: Threads_FOUND)
-- Configuring incomplete, errors occurred!
I have lib32gcc1 and GCC 4.4. Before I go on a wild goose chase and try to get a higher version of GCC from unofficial repositories... am I doing something wrong here already? Or is my version of GCC really insufficient?

EDIT: I should note that I am running 64-bit Debian stable/Squeeze/6.0.

[ag]

Code: [Select]

CMake Error at depends/protobuf/CMakeLists.txt:60 (MESSAGE):
  Could not find a working has map implementation. Please update GCC.
EDIT: I should note that I am running 64-bit Debian stable/Squeeze/6.0.

That error usually means you don't have all necessary 32-bit development libraries installed. Check stuff like libstdc++ and so on.

[DrKillPatient]

Thank you. The missing package turned out to be g++-multilib. However, although cmake completes, it still warns "could not find threads". I suspect this causes the remaining problem: when I make dfhack, I get this:

Code: [Select]

libprotoc.so: undefined reference to 'pthread_once'
collect2: ld returned 1 exit status
I needed lib32z-dev to get past an error before this, but now I can't find any references to the library necessary to fix the thread issues.

EDIT: Oh hell. From CMake's error log:

Code: [Select]

/usr/include/gnu/stubs.h:7:27: error: gnu/stubs-32.h: No such file or directoryI have libc6-dev-i386. and /usr/include/gnu/stubs-32.h actually exists. I've no idea what's causing this to happen...
Wait, that's not recent. I'm completely stumped now.

[kingubu]

I just built dfhack last week.  Used gcc/g++ 4.5.  Using 4.6 gave me a bunch of errors.  I am on 32bit Ubuntu Oneiric.

From COMPILE.rst "For building, you need a 32-bit version of GCC. For example, to build DFHack on a 64-bit distribution like Arch, you'll need the multilib development tools and libraries."

Wish I could be more help.

[peterix]

Thank you. The missing package turned out to be g++-multilib. However, although cmake completes, it still warns "could not find threads". I suspect this causes the remaining problem: when I make dfhack, I get this:

Code: [Select]

libprotoc.so: undefined reference to 'pthread_once'
collect2: ld returned 1 exit status
I needed lib32z-dev to get past an error before this, but now I can't find any references to the library necessary to fix the thread issues.

EDIT: Oh hell. From CMake's error log:

Code: [Select]

/usr/include/gnu/stubs.h:7:27: error: gnu/stubs-32.h: No such file or directoryI have libc6-dev-i386. and /usr/include/gnu/stubs-32.h actually exists. I've no idea what's causing this to happen...
Wait, that's not recent. I'm completely stumped now.

Looks like broken multilib support or some packaging issue. Are you sure you have all the multilib gcc packages?

[DrKillPatient]

It appears that CMake was confused due to all the packages I ended up installing as I went along. I deleted, redownloaded, and re-CMake'd (cmade?) DFHack, and it found strings this time. I needed to install another package, libxml-libxslt-perl, to continue the process shortly after.

As a resource to future readers who use Debian, I'll try to list all the packages I needed to build dfhack:

Code: [Select]

ia32-libs
ia32-libs-gtk
gcc-4.4-multilib
g++-4.4-multilib
libxml-libxml-perl
lib32z-dev
libxml-libxslt-perl
I may have missed some that I used earlier, because I had to install several multilib libraries to get DF working as well (tutorial here, by the way).

[Captain Crazy]

Sorry to pop in the midst of this discussion, but is there any repositories for cool DFusion plugins?

Also, is there plugins to restore those old dummied out Mountain Halls and Goblin towers from early versions?

[DrKillPatient]

Most of DFHack's plugins seem to work nicely now, but have one more issue. The Stonesense plugin, when started, just pops up a window called "Dwarf_Fortress" and sits there blankly. I can't find any sort of errorlog (I don't think stonesense.log was generated), so unfortunately that's all I can say about the problem. How can I at least get it to show some errors?

Sorry to pop in the midst of this discussion, but is there any repositories for cool DFusion plugins?

Also, is there plugins to restore those old dummied out Mountain Halls and Goblin towers from early versions?

Not sure about DFusion plugins, however, with regards to recreating the Mountain Halls and such, I think there's no way to do it with just a plugin. The only fix you might do is to change the goblin/dwarf/elf entity raws so that they live in towns like humans, and not their normal towers/halls/retreats.

[ZZmage]

Hey i've noticed something interesting on an empty magma forge that has had a lot of stuff constructed at it if you hit the changeitem here it registers stuff thats no longer there is this a thing of dwarf fortress not clearing memory on that tile or could it be something else? cause if you deconstruct the magma forge or any building thats shoing items in changeitem here info the center tile will still register it.

[Rumrusher]

Sorry to pop in the midst of this discussion, but is there any repositories for cool DFusion plugins?

Also, is there plugins to restore those old dummied out Mountain Halls and Goblin towers from early versions?

hmm well that takes someone to bring them back. also here the thread for dfusion's dfhack plugin