Print

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

[jaxad0127]

All I'm talking about is some sort of UI with the ability to load dfhack plugins written in some sort of scripting language. Doesn't sound like jaxad is really interested in the core concept of this so I will keep researching on my own....

That's doable with Qt, but for now, I'm working on the facade.

EDIT: I think we're talking about different things here. Do you mean plugins to DFHack that add support for more offsets, etc, or more tools?

[ral]

Just more tools.... For example, dfliquids written in a scripting language with something to specify a GUI for it. Scripting languages would seem totally unsuited to addressing anything directly in memory without some sort of abstraction on top of it.

Aside from the gui stuff, what makes me think that allowing dfhack tools to be written in scripting languages would be a good idea are things like dffusion and Dwarf Guidance Councilor (the developer of which doesn't know C++ and pretty much only knows php and javascript from what it sounds like).

I'll take a look at the python thing. I didn't manage to find that until you mentioned it.

[jaxad0127]

Just more tools.... For example, dfliquids written in a scripting language with something to specify a GUI for it. Scripting languages would seem totally unsuited to addressing anything directly in memory without some sort of abstraction on top of it.

Aside from the gui stuff, what makes me think that allowing dfhack tools to be written in scripting languages would be a good idea are things like dffusion and Dwarf Guidance Councilor (the developer of which doesn't know C++ and pretty much only knows php and javascript from what it sounds like).

I'll take a look at the python thing. I didn't manage to find that until you mentioned it.

QML will makes GUIs extremely simple. And not much overhead for just scripts. I'll look later into QScript bindings for DFHack, which will let you use Qt's javascript engine.

[devek]

That is where you guys are confusing me...

QML is useful for layouts yes.. but qt creator has that covered. It isn't advised to go beyond that.

If you're just wanting to write at QT program that can call scripts that call dfhack, why not embed python? You don't need to worry about the dfhack python bindings, cpython interfaces with c/qt just fine in the same way that jython interfaces with java just fine. In fact, when it was starting to become popular one of the touted features was just that.

[ral]

Just glancing at QtScript docs, it looks like you probably have to wrap everything in QObjects that translate data types, etc. If you need anyone to help with the grunt work of wrapping dfhack classes with QObjects that translate data types, etc, let me know when you get to that point. I don't know squat about Qt specifically, but I've done a bit of wrapping C for scripting languages so I'm familiar with what has to happen to make that possible.

Seems like some sort of template metaprogramming wrapper should be possible for some cases of this but I don't see any that anyone has developed, and I don't know squat about c++ metaprogramming at this point either.

devek: I'm not necessarily opposed to python either. Personally I like python and know it rather well.

[jaxad0127]

Just glancing at QtScript docs, it looks like you probably have to wrap everything in QObjects that translate data types, etc. If you need anyone to help with the grunt work of wrapping dfhack classes with QObjects that translate data types, etc, let me know when you get to that point. I don't know squat about Qt specifically, but I've done a bit of wrapping C for scripting languages so I'm familiar with what has to happen to make that possible.

Seems like some sort of template metaprogramming wrapper should be possible for some cases of this but I don't see any that anyone has developed, and I don't know squat about c++ metaprogramming at this point either.

devek: I'm not necessarily opposed to python either. Personally I like python and know it rather well.

I'm already working on that for the QML facade.

[Andux]

Urist McAndux withdraws from society...
Urist McAndux has claimed a Code Monkey's Workshop.
Urist McAndux has begun a mysterious construction!
Urist McAndux, Code Monkey has created dfmarmot, a DFHack-based map tool!

Still needs a bit of work, but it's more or less usable now.


I had some trouble with Context_Resume -- after calling it, the next Maps_* function call always gave me an access violation -- Context_ForceResume seems to work fine, though.

[Dante]

Nice, Andux. It's useful to have liquids + temperature functionality in one tool, for making ice walls. However, I did get one crash when I was changing the temperature of a patch of magma to 999 Urist. I don't know if that's a problem with dfmarmot, dfhack or df itself.

[Ethicalfive]

Quick question i'm hoping someone would be kind enough to answer, or even be pointed to other projects that may already do a similar thing.

Is it possible to read what the current menu in fortress mode is through dfhack?

For example, if I were to press 'd' and bring up the designations menu, is there a value that I can access through dfhack that tells me that menu is open?

[jaxad0127]

Quick question i'm hoping someone would be kind enough to answer, or even be pointed to other projects that may already do a similar thing.

Is it possible to read what the current menu in fortress mode is through dfhack?

For example, if I were to press 'd' and bring up the designations menu, is there a value that I can access through dfhack that tells me that menu is open?

There is function to grab what is being drawn on the screen. You can parse that output.

EDIT: Looking at the GUI module again, there is a function to get the menu state. We don't have an enum for that yet, but you could make one.

[Ethicalfive]

Sweet, thanks for the quick and informative reply

[peterix]

Sweet, thanks for the quick and informative reply

Note that those things are currently broken/have missing offsets. There's work that needs to be done for it to be useful again. Research has been done (scroll up a few pages). All it needs is someone to fix it.

[peterix]

I had some trouble with Context_Resume -- after calling it, the next Maps_* function call always gave me an access violation -- Context_ForceResume seems to work fine, though.

Well, if you use that, you can cause bad stuff to happen if the user does have a second tool running - something like Dwarf Therapist for example. See, each thread on Windows has a counter that says how many times it was suspended, so that multiple things that need the thread to stop executing get the expected behavior - each suspends once and resumes once when they need. When the counter reaches zero again, the thread can run. What you're doing here is that you force the thread to resume. This can break other tools, because they assume DF isn't doing anything with its memory while they manipulate it.

The fact that you *aren't* getting a segfault/exception from ForceResume is due to a bug, and the fact you are getting a segfault//exception from Resume is possibly due to a second bug. I'll go and fix those now. See, the modules keep some data around - read in one big chunk when you call Start. This data is valid for as long as DF is suspended. Resuming makes the data invalid and possibly dangeorus to use. Resume wiped it out, ForceResume didn't. Now it will.

So, use Suspend and Resume, and Start all the modules you need after the Resume again. ForceResume is there for dfunstuck, which is for cleaning up after crashing/too soon closed tools.

[Quietust]

Very minor complaint: the <Jobs> list in memory.xml is full of errors since it was borrowed from a version of Dwarf Therapist where they were completely wrong. The current version of Therapist has a corrected list.

[Andux]

While using dfsuspend to test some wait-for-resume functionality in dfmarmot, I found that Context_isSuspended was not giving the results I expected; I think I have a fix, though:

Code: (in DFProcess-windows.cpp) [Select]

bool NormalProcess::isSuspended()
{
    DWORD SuspendTally = 0;
    for(int i = 0; i < threads.size(); i++)
    {
        SuspendTally += SuspendThread(threads[i]);
        ResumeThread(threads[i]);
    }
    return (SuspendTally > 0);
}(Hopefully I got the C++ syntax right.)
That should detect when any program has suspended DF, and it doesn't touch the suspended flag, so resume() should still behave.