Print

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

[Roses]

What's the best way to use a global global table (one that is accessed by many different scripts fairly regularly for both reading and modifying)? Right now I'm just using the dfhack.script-environment to get the table, but I wasn't sure if that was the best way

[thefriendlyhacker]

What's the best way to use a global global table (one that is accessed by many different scripts fairly regularly for both reading and modifying)? Right now I'm just using the dfhack.script-environment to get the table, but I wasn't sure if that was the best way

The "best practice" way to do it would probably be to refactor all your shared functionality into one or more lua files in dfhack's lua folder, and then require them in like you would with utils, plugins.eventful or syndrome-util.

[Putnam]

I use script-environment nigh exclusively for that, occasionally persistent storage.

[blackreaper666]

Could it be that

Code: [Select]

dfhack.screen.getWindowSize() is broken in the lua api?

As per Screen.cpp Screen::getWindowSize() returns a coord2d, so it has a x and a y field. Reference:

Code: [Select]

df::coord2d Screen::getWindowSize()
{
    if (!gps) return df::coord2d(80, 25);

    return df::coord2d(gps->dimx, gps->dimy);
}

but lua treats it as a single number.

Code: [Select]

dfhack.screen.getWindowSize() will just return the x value (width), but if you print it it will show x and y in the console but there is no way to select either x or y.

Code: [Select]

dfhack.screen.getWindowSize().x
dfhack.screen.getWindowSize().y
dfhack.screen.getWindowSize().X
dfhack.screen.getWindowSize().Y
dfhack.screen.getWindowSize()[0]
dfhack.screen.getWindowSize()[1]
...

all fail because of "attempt to index a number value" which makes sense because lua thinks getWindowSize returns a single number.

[Roses]

Could it be that

Code: [Select]

dfhack.screen.getWindowSize() is broken in the lua api?

As per Screen.cpp Screen::getWindowSize() returns a coord2d, so it has a x and a y field. Reference:

Code: [Select]

df::coord2d Screen::getWindowSize()
{
    if (!gps) return df::coord2d(80, 25);

    return df::coord2d(gps->dimx, gps->dimy);
}

but lua treats it as a single number.

Code: [Select]

dfhack.screen.getWindowSize() will just return the x value (width), but if you print it it will show x and y in the console but there is no way to select either x or y.

Code: [Select]

dfhack.screen.getWindowSize().x
dfhack.screen.getWindowSize().y
dfhack.screen.getWindowSize().X
dfhack.screen.getWindowSize().Y
dfhack.screen.getWindowSize()[0]
dfhack.screen.getWindowSize()[1]
...

all fail because of "attempt to index a number value" which makes sense because lua thinks getWindowSize returns a single number.

You sure it isn't just returning two values? x, y = dfhack.screen.getWindowSize()

[blackreaper666]

You sure it isn't just returning two values? x, y = dfhack.screen.getWindowSize()

  You are right! Thanks. Now I feel dumb... I didn't knew multiple returns where possible in lua and the error didn't really help. I would have expected a different kind of error that somehow indicates that there are multiple values returned and not just taking the first one and working with that. That's what I'm used to from other languages. Thanks again for your help!

[Roses]

You are right! Thanks. Now I feel dumb... I didn't knew multiple returns where possible in lua and the error didn't really help. I would have expected a different kind of error that somehow indicates that there are multiple values returned and not just taking the first one and working with that. That's what I'm used to from other languages. Thanks again for your help!

Yeah, it took me awhile to work out multiple return values versus returns of tables with multiple values and making sure that I was getting the right stuff from the dfhack functions

[Clément]

I've been experimenting with using Qt in DFHack plugins and it's mostly working (much better that I thought it would at first).

There is no issue that I could see on Windows. On Linux, it crashes on exit when SDL tries to clean up some X11 related resources. I understand it is an issue from Xlib no supporting concurrency. It can be fixed by using Wayland backend for the Qt part, or by replacing SDL 1.2 with SDL2 thanks to sdlcl (I guess the newer sdl12-compat would work too). I did not test with macOS.

I pushed the code on this github. The qapplication plugin manages the main Qt thread and provides a few basic commands for configuration or diagnostics. Other plugins can call addTopLevelWidget from include/TopLevelWidget.h to create widgets. qapplication needs to be enabled before Qt widgets can be created.

The labors branch contains a very basic DT-like plugin that can serve as a demo. If you want to try it you will need to have the default_gridviews.dtg file from DT copied in DF root directory. Data is only accessed when the game is suspended (use the "suspend" and "resume" buttons in the tool bar).

Multi-threading make such plugins a little difficult to write since you need to either suspend the game or copy all the data you need. But I think it is still easier than external applications since you can take advantage of all DFHack helper functions and you would need to copy the data anyway in an external application.

I currently only access/modify DF data when a CoreSuspender is locked, but I wonder if this could be relaxed. Can any assumption be made on some pointers validity with regards to state change events (SC_WORLD_LOADED, SC_WORLD_UNLOADED, SC_MAP_LOADED, SC_MAP_UNLOADED, SC_PAUSED, SC_UNPAUSED, ...) for read-only access?

[ragundo]

I've been experimenting with using Qt in DFHack plugins and it's mostly working (much better that I thought it would at first).


I pushed the code on this github. The qapplication plugin manages the main Qt thread and provides a few basic commands for configuration or diagnostics. Other plugins can call addTopLevelWidget from include/TopLevelWidget.h to create widgets. qapplication needs to be enabled before Qt widgets can be created.

The labors branch contains a very basic DT-like plugin that can serve as a demo. If you want to try it you will need to have the default_gridviews.dtg file from DT copied in DF root directory. Data is only accessed when the game is suspended (use the "suspend" and "resume" buttons in the tool bar).

So with this I could create a Qt application directly linked with DFhack and access all the data?.
This is great.
I tried to do something similar using protocol buffers, but perfomance suffers.
I can generate Qt models for every df structure in DFhack and visualize them. I'll play with your repository for sure!!
Would it work also with QML?

[Clément]

I don't know QML very well, so I am not sure. But in the worst case you should be able to embed it in a QWidget. The limitation is that there can be only one application object, it is of type QApplication and managed by the qapplication plugin. All other plugins can do is only creating more windows (top-level widgets) for this common application. QApplication inherits QGuiApplication which used in QML apps, so maybe it's okay and it just need the API to create windows from QML.

For protobuf you need to aggregate the messages as much as you can. Performance can become acceptable if you send few messages with a lot of data. I tried to quickly hack dfhack protobuf protocol into Dwarf Therapist once: first try was really slow (10 minutes or something to load DT), but with a simple optimization I managed to get it nearly as fast as the current DT (although the current backend could also benefit from such optimization and be even faster).

[ragundo]

Not working for me in ubuntu.
I opened a issue in github.

What a coincidence that I got working my plugin that sends everything via protocol buffers to a remote Qt application just when you published your work

[Clément]

I have a Qt-based library for dfhack clients I could publish too if you are interested.

[ragundo]

I have a Qt-based library for dfhack clients I could publish too if you are interested.

Yes please!
By the way, with this Qt application you could recreate Dwarf Therapist entirely in DFHack, isn't?.
No need for .ini files, etc.
Just curious why you still keep using the original way

[Clément]

Yes, I'm am experimenting with other ways to make Dwarf Therapist. But re-creating it is a lot of work, don't expect it any time soon. I am not even sure I'll do it. And the debugging API currently used in DT is not that bad, except on macOS where it seems to require root permissions whatever you try.

[ViolinAnon]

I was using the 'liquids' plugin to create a large tower of obsidian for a special project.
However, when mined out by dwarves, the floors/ramps left behind are made of other material, such as fire clay or random stone.

I was wondering if I was perhaps doing something wrong, or if it's to be expected from creating obsidian that way?