Print

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

[Rose]

As far as I understand (and I may be wrong) Virtual functions are called via pointer in DF, so overriding those is as easy as replacing the pointer, but not all functions are virtual. Only certain ones that are part of certain classes are.

[PeridexisErrant]

@fricy - great to see you again, and I'm glad things are going better (even if you're just checking in :-))

@mifki - a few posts below that I did get owner-access, and there's ~10ish people with member access.  Fricy, I , and as of now Jecowa all have owner access to add new people too.  Is there something you'd like to do with the repos?

(http://www.bay12forums.com/smf/index.php?topic=155882.msg6926426#msg6926426 )

[mifki]

@mifki - a few posts below that I did get owner-access, and there's ~10ish people with member access.  Fricy, I , and as of now Jecowa all have owner access to add new people too.  Is there something you'd like to do with the repos?

(http://www.bay12forums.com/smf/index.php?topic=155882.msg6926426#msg6926426 )

Nope, I just didn't know.

[Cathar]

Thank you so much for the update !

[lethosor]

I assume it's about disabling the native pathfinding loop.

YIKES.
That's definitely something that can only be done in a plugin and through lots of reverse-engineering, if it can be done at all.

Relax, it might not be as bad as you think. We just need to think a little bit out of the box. By overwriting unit.path.dest, we managed to hijack the native pathfinding surprisingly easily, actually (for a very basic proof of concept). More about that on the other thread.

Now back to DFHack : the reason why I'm asking questions about the game loop sequence and when DFHack steps in, is to have a general idea of when some data is written to/from the world. The goal is to have a very vague idea of when it's (kind of) OK to read from it without a big-ass mutex, and if it's even OK to read from it at all because of any unforeseen issue (something like : gotcha, the game immediately overwrites the data you've just read because you're reading a very volatile, late game state meant only for just before frame rendering). If we'rte only trying to build some search indices from the world topology, then it's OK if it's not 100% accurate or up-to-date or real-time. And if it's definitley not OK to read anything (or set unit.path.dest) at the time DFHack runs, then my goal is to have a vague idea of when can I move (within a game loop) my processing. You have answered that part very clearly : with just a DFHack script, I can't.

So you said that with a plugin (a DFHack plugin I assume, there's not such thing as a DF plugin, correct?) I can intercept any call to virtual functions. By "intercept", do you mean detect or do you mean override? Are we talking DFHack functions or native DF functions? I can't imagine that you'd have entry points (headers???) to every native function, but then again I don't have a deep understanding of DFHack plugins. Quietust said (I think, I'm already forgetting who said this and if I'm quoting properly) that the only way to hijack the call to a native DF function is to patch the game; did I misunderstand what he said?

Yes, adjusting a unit's path is trivial. Patching the pathfinding engine is not, depending on what you want to do.

By virtual methods, I'm referring to these. Nothing in the pathfinding engine uses these, as far as I know. DFHack has a way to intercept calls to them (meaning call your own function instead of DF's), and a way to call DF's within intercepted calls, so it's trivial to make something just to detect calls.

If it turns out that you need to patch the pathfinding engine, you probably want to do that in C++. I suspect that running your own pathfinding algorithm after DF's can be done at any time (when DF's simulation thread isn't busy), but you'll also want to keep DF's from running, and run yours instead when DF expects pathfinding to be done. Technically, you can patch executable code from Lua as well, but if you're writing your own function for DF to call, that'll need to be done in C++.

[jeancallisti]

So if we assume that the pathfinding function is virtual and if we assume that I want to run my own code instead, written in C++ as a DFHack plugin, then what's the underlying code base? Like, would it be possible (without it being too clumsy or hard to maintain) to use stuff like C++11 and std::async ? (Don't worry about sync'ing the threads, leave that to me). Is 'std' available at all?

[Roses]

So if we assume that the pathfinding function is virtual and if we assume that I want to run my own code instead, written in C++ as a DFHack plugin, then what's the underlying code base? Like, would it be possible (without it being too clumsy or hard to maintain) to use stuff like C++11 and std::async ? (Don't worry about sync'ing the threads, leave that to me). Is 'std' available at all?

The problem is the pathfinding doesn't use virtual methods, unless Toady has changed it I remember looking into it with others a few versions ago and the results were that the only way to effect the pathfinding was to modify the units path itself. You are free to look into it of course, but I'm pretty sure the pathfinding engine doesn't use any virtual methods that you can hook into

[jeancallisti]

You are free to look into it of course, but I'm pretty sure the pathfinding engine doesn't use any virtual methods that you can hook into

OK so that settled it, no worries. We'll have to stick to our hacky method that overwrites unit.path.dest.

[PatrikLundell]

You are free to look into it of course, but I'm pretty sure the pathfinding engine doesn't use any virtual methods that you can hook into

OK so that settled it, no worries. We'll have to stick to our hacky method that overwrites unit.path.dest.

I'm not sure what that would achieve, assuming you're looking to improve performance, not change the path as such. Having DF first calculate the path, then calculate a path using an alternative method and then replace the original path with the hacked one is bound to be costlier. In order to replace the pathing you'd at least have to hack the DF code to produce a short fake path that your alternative can pick up, but if you've managed to do that you can just as well call your replacement code from that stub to produce a real path. Obviously, in order to do this you'd have to locate the relevant code, figure out what the parameters are (including variations), and find out what the results are (quite possibly an updated path in the unit plus some kind of return value to indicate success/failure (with possible indications of the kind of failure)).

If you somehow were able to determine when DF was going to perform a path calculation, replacing the destination in between it being set and the path calculated would allow you to ensure the native calculation produces a very short (and cheap) path, of course.

And now something completely different: How do you find out if a unit is a spy? I've tried to compare the visible name string with the normal one, without getting a single mismatch, so that's probably not it. It seems the gobbos have sent multiple spies to note cage trap locations along multiple entrance paths, and ripping up the traps not triggered during the last siege and placing new ones there did not seem to help for the current one, although the revealed path is slightly different.
I haven't decided what to do with the spies, but having 50% of the visitors being monks and peddlers is FAR to high a proportion for my liking (yes, I know that can be handled by not having dedicated temples, which I'm going to do in the next fortress, but not the current one).

[lethosor]

You are free to look into it of course, but I'm pretty sure the pathfinding engine doesn't use any virtual methods that you can hook into

OK so that settled it, no worries. We'll have to stick to our hacky method that overwrites unit.path.dest.

I'm not sure what that would achieve, assuming you're looking to improve performance, not change the path as such. Having DF first calculate the path, then calculate a path using an alternative method and then replace the original path with the hacked one is bound to be costlier. In order to replace the pathing you'd at least have to hack the DF code to produce a short fake path that your alternative can pick up, but if you've managed to do that you can just as well call your replacement code from that stub to produce a real path.

This is exactly what I meant by having DF call a custom pathfinding function (it's what I said requires C++).

Obviously, in order to do this you'd have to locate the relevant code, figure out what the parameters are (including variations), and find out what the results are (quite possibly an updated path in the unit plus some kind of return value to indicate success/failure (with possible indications of the kind of failure)).

If you're just writing something that computes unit.path.dest, you probably don't need any of that.

So if we assume that the pathfinding function is virtual and if we assume that I want to run my own code instead, written in C++ as a DFHack plugin, then what's the underlying code base? Like, would it be possible (without it being too clumsy or hard to maintain) to use stuff like C++11 and std::async ? (Don't worry about sync'ing the threads, leave that to me). Is 'std' available at all?

It is not virtual. There might be some virtual methods that happen to get called during pathfinding, but I doubt it, so don't count on it. You'd have to go back to the 1990s for the STL not to be available. As for DFHack's purposes, we support GCC 4.8 (and newer) and MSVC 2015 (exactly), so any C++11 stuff should be available. C++14 support is dicey, and C++17 is probably not something you can rely on.

[jeancallisti]

C++ 11

Perfect perfect perfect. Thanks.

I'm not replying to the pathfinder bit, as it's being discussed in another thread.

[Express]

When I used digtype on gold nuggets in the latest alpha build my game crashed. Its happened twice so I've stopped using it. Anything I can do to help with this report?

edit: ah I saw the github site where bugs are reported. still new to all this!

[fricy]

When I used digtype on gold nuggets in the latest alpha build my game crashed. Its happened twice so I've stopped using it. Anything I can do to help with this report?

I couldn't reproduce this. I designated a native gold vein for digging, gave the command and the dwarves started digging for me. How fast came the crash for you? Immediately, or a bit later?
For what it's worth I have to mention that I did use the 3dveins command right after embark on this map.
dfhack 44.07-a1, twbt, no raw changes.

[Express]

When I used digtype on gold nuggets in the latest alpha build my game crashed. Its happened twice so I've stopped using it. Anything I can do to help with this report?

I couldn't reproduce this. I designated a native gold vein for digging, gave the command and the dwarves started digging for me. How fast came the crash for you? Immediately, or a bit later?
For what it's worth I have to mention that I did use the 3dveins command right after embark on this map.
dfhack 44.07-a1, twbt, no raw changes.

I can replicate it all the time. I posted this bug on github along with my save, hopefully they find something there.

[PatrikLundell]

Which DFHack function is responsible for producing a text saying "Units removed from active: X"? It's presumably enabled by the LNP DFHack setting "Performance Tweaks".
The reason for the question is that my fortress has a large number of questers stuck in limbo (i.e. "dead" and incoming) but with their gear showing up in the inventory screen. At least one of these units (the one I get when I follow the trail of the first inventory weapon) is in units.all but not units.active, so I'd like to check what that script/plugin does, to see if it might be responsible for the stock (and item) clutter.

Edit: Corrected the text printed.