1
Utilities and 3rd Party Applications / Re: DFHack 0.40.19-r1
« on: December 30, 2014, 09:02:42 pm »Yeah, the map is divided into blocks of 16x16 tiles.
Got it! That makes sense. Numbers seem perfectly reasonable then.
Bay 12 Games Forum
- April 18, 2024, 08:41:05 am
- Welcome, Guest
News:
March 6, 2024: Dwarf Fortress 50.12 has been released.
News: February 3, 2024: The February '24 Report is up.
News: February 4, 2021: Dwarf Fortress Talk #28 has been posted.
News: November 21, 2018: A new Threetoe story has been posted.
Forum Guidelines
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.
Pages: [1]
Got it! That makes sense. Numbers seem perfectly reasonable then.
2
Utilities and 3rd Party Applications / Re: DFHack 0.40.19-r1
« on: December 30, 2014, 12:13:39 am »Okay, added very basic unit loading to Armok Vision, and RemoteFortressReader. All it does is get a list of the coordinates of all units in play over the network.
Just saw this post and pulled down your changes. Cheers!
I finally got some time to start working on this during vacation. The first thing I noticed was that the MapInfo x/y coord's seem low. Maybe it's an issue with my understanding of how the DF map is structured though.
I did a default embark (4x4 I believe?), but the cord's came back with map size of 12 for both X and Y. The Z size is correct however (204). I placed a breakpoint on the DFHack side and that is what it's getting back from MapInfo object, so I'll dig deeper tomorrow. I would have expected to get something in the range of about 150-200 units.
3
Utilities and 3rd Party Applications / Re: DFHack 0.40.19-r1
« on: December 10, 2014, 10:54:11 pm »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.
4
Utilities and 3rd Party Applications / Re: DFHack 0.40.19-r1
« on: December 10, 2014, 01:55:31 pm »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.
5
Utilities and 3rd Party Applications / Re: DFHack 0.40.19-r1
« on: December 10, 2014, 03:04:21 am »
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.
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.
Pages: [1]