Print

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

[Nopenope]

My two cents: there is enough DFHack content to merit its own forum but there isn't enough 3rd party stuff that isn't DFHack to merit its own forum so it may as well all get lumped together.

Actually there's plenty, it just tends to be buried by all the dfhack stuff since dfhack development is much more active and needs constant updating. I think a separation could benefit both sides. Other third party utilities would have greater visibility and user support for DFHack (since it's lacking somewhat in documentation) would be easier.

[rmblr]

My two cents: there is enough DFHack content to merit its own forum but there isn't enough 3rd party stuff that isn't DFHack to merit its own forum so it may as well all get lumped together.

Actually there's plenty, it just tends to be buried by all the dfhack stuff since dfhack development is much more active and needs constant updating. I think a separation could benefit both sides. Other third party utilities would have greater visibility and user support for DFHack (since it's lacking somewhat in documentation) would be easier.

This is my opinion as well (except the documentation bit, I think DFHack is quite well documented from a users perspective). A separate forum would enhance DFHack support while unclogging this board for the other 3rd party utils. Though TBH, I think for user support forums are atrocious at it, a very mid-200s solution, when more efficient things exist like DF on Stackexchange Gaming. But that's another topic.. ignore me.

The "there's not enough discussion about non DFHack utils" argument doesn't hold water IMHO, just look at the Wiki board which is very quiet yet still merits its own place. Separate would ensure non-DFhack topic aren't lost in the "noise".

[rmblr]

@expwnent - Could you please edit the first post to remove the line "This must be downloaded separately for technical reasons." from the stonesense line. Stonesense hasn't had its own release since 2010, and its been bundled with DFHack releases for awhile (except of course the recent non-availability due to bugs).

Elsewhere (Reddit and StackExchange) people are confused about how to get stonesense because of that line ([snide_comment]apparently some people read user docs![/snide_comment]).

[Iced_Eagle]

Hey guys,

I'm trying to use the DFHack remote client in a C# application. My end goal is to be able to query DFHack and the remote client using protobuf in Unity. In the documentation it mentions there is a C# client which exists, but I haven't been able to find it (doc is wrong or I'm blind!).

Has anyone else done something like this? I didn't see anything mentioned in the thread.

The first issue comes in to play in that you supposedly can't use PInvoke on native classes and members for pulling in RemoteClient to the managed side. I would assume that it would work fine if you're importing into another native project though. If I'm mistaken about this, please let me know with the dwarfiest horn you can find! All signs I've read point to "you can't do this".

My initial approach was to create a separate managed C++ dll which would be a wrapper around RemoteClient. I seem to get memory corruption errors when calling connect() that I wasn't able to debug. I'm not familiar with managed C++ so I wasn't sure the best place to start looking. It very well could have been an issue with the way I was compiling my project or something like that.

Instead, I'm thinking of just writing a C-style wrapper around remote client and expose only functions which would first return a handle to the created object, and then all function would take in a handle, in addition to their regular parameters. I should then be able to use PInvoke on this wrapper, ideally without the memory corruption. :-) The pro to this method is that it's a bit simpler and I'm more familiar with the method. The con is of course things like type safety you get from having the wrapper be in managed code.

One thing which was easy of course was pulling in all of the protobuf work into C#, so once I get the client connection portion worked out, I'm imagining the deserialization of the messages is going to be a bit more straightforward (I hope).

Any thoughts are appreciated! Let me know if I also missed anything major or in my approach.

[Rose]

https://github.com/JapaMala/armok-vision

This is a little something I threw together to read DF map data into Unity.

The way it works is that there's a DFHack plugin that accepts RPC calls over sockets, and returns data to the client. Right now it's just basic map reading, but it can be extended to anything. The important part is that the RPC language used is independent of DFHack version, so even if DFHack adds or removes features, the RPC protocol either is unchanged, or changes more intelligently, to maintain compatibility (This has already happened at least once so far)

Then the unity side does what it wants with everything.

My goal with this was to have a 3d visualizer that worked with multiple versions of DF at the same time. (In comparison to stonesense, which is locked to one DF version, so if you want to view older forts, you have to use an older stonesense, and all that implies)

[rmblr]

Anyone know how to use the job plugin and/or workflow to produce a specific type of rock crafts, specifically amulets?

[cdombroski]

I noticed that fix-armory and the related binpatches are missing. Are the underlying issues fixed in DF?

[expwnent]

@expwnent - Could you please edit the first post to remove the line "This must be downloaded separately for technical reasons." from the stonesense line. Stonesense hasn't had its own release since 2010, and its been bundled with DFHack releases for awhile (except of course the recent non-availability due to bugs).

Elsewhere (Reddit and StackExchange) people are confused about how to get stonesense because of that line ([snide_comment]apparently some people read user docs![/snide_comment]).

Whoops. Thanks.

[Iced_Eagle]

https://github.com/JapaMala/armok-vision

This is a little something I threw together to read DF map data into Unity.

The way it works is that there's a DFHack plugin that accepts RPC calls over sockets, and returns data to the client. Right now it's just basic map reading, but it can be extended to anything. The important part is that the RPC language used is independent of DFHack version, so even if DFHack adds or removes features, the RPC protocol either is unchanged, or changes more intelligently, to maintain compatibility (This has already happened at least once so far)

Then the unity side does what it wants with everything.

My goal with this was to have a 3d visualizer that worked with multiple versions of DF at the same time. (In comparison to stonesense, which is locked to one DF version, so if you want to view older forts, you have to use an older stonesense, and all that implies)

Cool, thank you! So it looks like you recreated the RPC protocol within C# instead of linking to the RemoteClient library. That definitely works and would remove the tight compatibility with the DFHack version. I'd assume that if you were to change the server output, you'd change the request/response or something like that in case formatting changes or something like that then.

Just curious, but have you tried having a truly real-time connection to DF? It looks like you're grabbing everything on start-up, creating meshes and then disconnecting. I'm not sure of the performance of the remote client, and how quickly it gets map data, so maybe it's not feasible, or I would just need to get creative on the best way to do that given that there's no eventing or things like that. I don't recall there being an API to return dwarf positional data, so that may be something else I investigate further so we could see our friends running around. :-)

I'm pretty sure I've seen you on the IRC channel, so I may have additional questions later on, especially if I make any changes to your code that would be good to check-in for others to use.

[Rose]

Only reason that wasn't realtime is because I was more working on making sure things were connecting right and rendering. There's no reason why it couldn't do updates more often. The communication is pretty quick, in any case.

Regarding events, something clever could be done with them, maybe, but I think it'd be simplest just to poll for changed values of stuff.

Things like dwarf positions would change far more often than terrain data, after all.

[Iced_Eagle]

Only reason that wasn't realtime is because I was more working on making sure things were connecting right and rendering. There's no reason why it couldn't do updates more often. The communication is pretty quick, in any case.

Regarding events, something clever could be done with them, maybe, but I think it'd be simplest just to poll for changed values of stuff.

Things like dwarf positions would change far more often than terrain data, after all.

Well I'm home from work now, so it's time to start experimenting! Great work with this Japa. Reduces a lot of the framework I was thinking I was needing to write to get the RPC connection working.

[rmblr]

Only reason that wasn't realtime is because I was more working on making sure things were connecting right and rendering. There's no reason why it couldn't do updates more often. The communication is pretty quick, in any case.

Regarding events, something clever could be done with them, maybe, but I think it'd be simplest just to poll for changed values of stuff.

Things like dwarf positions would change far more often than terrain data, after all.

Well I'm home from work now, so it's time to start experimenting! Great work with this Japa. Reduces a lot of the framework I was thinking I was needing to write to get the RPC connection working.

A request from a fellow dev and non-windows user: whatever you're creating for DFHack, if you plan to mass release it, please keep it compatible with the Mono libraries so non-windows users can use it.

[Severedicks]

Or better yet, stay away from C#.

[Putnam]

Or better yet, stay away from C#.

why

[Rose]

Only reason that wasn't realtime is because I was more working on making sure things were connecting right and rendering. There's no reason why it couldn't do updates more often. The communication is pretty quick, in any case.

Regarding events, something clever could be done with them, maybe, but I think it'd be simplest just to poll for changed values of stuff.

Things like dwarf positions would change far more often than terrain data, after all.

Well I'm home from work now, so it's time to start experimenting! Great work with this Japa. Reduces a lot of the framework I was thinking I was needing to write to get the RPC connection working.

A request from a fellow dev and non-windows user: whatever you're creating for DFHack, if you plan to mass release it, please keep it compatible with the Mono libraries so non-windows users can use it.

So far, we're doing it in Unity, which uses mono, and releases linux binaries, so not a problem.