Print

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

[Llamageddon]

Was about to say the same thing. I now await with bated breath 

[lethosor]

I mean, it's a pretty typical pattern when an initial feature release has nasty bugs. Also, DFHack hasn't technically dropped support for 0.44.06 yet.

[DaSwayza]

I know I knew at some point, but I can't get the create-unit script to work. -civId and -localId \\LOCAL is not working

[jeancallisti]

General question about dfhack: what's its inner timing in regards to the game's engine inner timing?
- At what point of the game loop does DFhack read and update its properties?
- Or, if all the properties are direct access to actual value in memory, then at what stage in the game loop do dfhack scripts get executed?
- what is the liberty of the scripter to move its script execution earlier or later in the game loop? (Is the timing different with DFHack plugins? Are there several native game events that can trigger a script execution from DFhack or do they always play at the same stage in the game loop?)
- can you do a very rough presentation of the order of computations that take place inside a native game loop?

[Rose]

As far as I understand, there's one fixed point in the game loop where any dfhack commands are executed, which is where the DF exe polls the number of connected joysticks through SDL, which happens every frame.

[lethosor]

General question about dfhack: what's its inner timing in regards to the game's engine inner timing?
- At what point of the game loop does DFhack read and update its properties?
- Or, if all the properties are direct access to actual value in memory, then at what stage in the game loop do dfhack scripts get executed?

They've been direct access since DFHack moved to being in-process. I don't remember when exactly this was, but it was probably around 2009-2010.

Like Japa said, SDL_GetNumJoysticks() is called once per game tick (corresponding to the "FPS" indicator), on the simulation thread, and DFHack hooks into that to run anything that needs to access DF data. This includes most plugin commands and all scripts.

- what is the liberty of the scripter to move its script execution earlier or later in the game loop?

Impossible, and I don't know why you would want to. Is there something specific you're trying to do? If so, there's probably already a way to do it that doesn't require hooking into the game loop at different points.

(Is the timing different with DFHack plugins? Are there several native game events that can trigger a script execution from DFhack or do they always play at the same stage in the game loop?)

Plugins have access to C++ features and can do whatever they want - they can spin off separate threads, for example, and run things whenever they want. However, the whole point of the per-tick hook is that it's safe to access game data at that point, because DF's simulation thread isn't doing anything else.

Plugins can intercept virtual method calls, which is usually safe. Scripts can't do that. In theory, a plugin could call a Lua script from an interposed vmethod (with some limitations, like being unable to make screens, I think).

- can you do a very rough presentation of the order of computations that take place inside a native game loop?

Nope. Disassembly could reveal some stuff, but it would take a lot of effort.

Again, is there something specific you're looking for? These questions seem like they have a purpose that isn't specified.

[fricy]

Again, is there something specific you're looking for? These questions seem like they have a purpose that isn't specified.

Hey, long time!
I assume it's about disabling the native pathfinding loop.

[lethosor]

New alpha build! https://github.com/DFHack/dfhack/releases/tag/0.44.07-alpha1

Hey, long time!

Welcome back!

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.

[mifki]

Again, is there something specific you're looking for? These questions seem like they have a purpose that isn't specified.

Hey, long time!

Wow, welcome back!
Now we will get proper access to DFgraphics repo finally 

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

That's what I was thinking about it for a long time but didn't have time to dig so deep.

[fricy]

Wow, welcome back!

Hey thanks, don't get your hopes up, just checked in, heard there's something new. I see you're still hammering on the gfx.

Now we will get proper access to DFgraphics repo finally 

What do you mean? Did I not gave access to others? Sh!t. 

[mifki]

Wow, welcome back!

Hey thanks, don't get your hopes up, just checked in, heard there's something new. I see you're still hammering on the gfx.

Real life happened or lost interest, may I ask?

Now we will get proper access to DFgraphics repo finally 

What do you mean? Did I not gave access to others? Sh!t. 

AFAIK only you had full admin rights.

[fricy]

Wow, welcome back!

Hey thanks, don't get your hopes up, just checked in, heard there's something new. I see you're still hammering on the gfx.

Real life happened or lost interest, may I ask?

Now we will get proper access to DFgraphics repo finally 

What do you mean? Did I not gave access to others? Sh!t. 

AFAIK only you had full admin rights.

RL. Some depressing shit happened I had to deal with, by the time it was mostly over I had some other stuff on my mind.
And Peredexiserrant seems to have GOD mode turned on in the repo, so you did have someone to bugger after all. 

[mifki]

Wow, welcome back!

Hey thanks, don't get your hopes up, just checked in, heard there's something new. I see you're still hammering on the gfx.

Real life happened or lost interest, may I ask?

Now we will get proper access to DFgraphics repo finally 

What do you mean? Did I not gave access to others? Sh!t. 

AFAIK only you had full admin rights.

RL. Some depressing shit happened I had to deal with, by the time it was mostly over I had some other stuff on my mind.
And Peredexiserrant seems to have GOD mode turned on in the repo, so you did have someone to bugger after all. 

Hope it's better now.

I'm talking about this http://www.bay12forums.com/smf/index.php?topic=155882.msg6921078#msg6921078

[fricy]

I'm talking about this http://www.bay12forums.com/smf/index.php?topic=155882.msg6921078#msg6921078

Hmm, IDK. He is owner now. I checked the permissions, there are only two levels: member/owner. I seem to remember I did give him admin rights back then, so it beats me.
I'm sure he'll chip in soon.

[jeancallisti]

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?