Print

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

[bloop_bleep]

I think it’s to be expected. There’s no layer material defined in air zones, so the game chooses one at random when the tile is mined.

[ViolinAnon]

Ah, damn.
I guess I can try an alternative method, by creating magma then water to cast obsidian. It'll be very time consuming.

Thanks for the confirmation, though!

[PatrikLundell]

I fail to see how obsidianizing using magma+water would give a different result from spawning obsidian directly. The problem comes from mining out of a huge block, so spawn only walls (and build floors out of obsidian [blocks]). It's still more work to spawn parts rather than a block that's mined out, of course.

Also note that the biome in the air may differ from the one at ground level, so any farming may support crops different from the ones expected (the air biome is the one of the world tile to the NW of the embark tile [and there's a "shear" bug that causes random 16*16 areas in the air to take on any of the up to 9 biomes of the embark world tile and the 8 surrounding ones]).

[Roses]

Also note that the biome in the air may differ from the one at ground level, so any farming may support crops different from the ones expected (the air biome is the one of the world tile to the NW of the embark tile [and there's a "shear" bug that causes random 16*16 areas in the air to take on any of the up to 9 biomes of the embark world tile and the 8 surrounding ones]).

That's interesting, I didn't know that about air biomes. Now I kind of want to make a "hanging garden".

Ah, damn.
I guess I can try an alternative method, by creating magma then water to cast obsidian. It'll be very time consuming.

Thanks for the confirmation, though!

Like Patrik said, I'm not sure that that will produce any different results, but what you could do is use dfhack to manually change the tile type of the ramps and floors to obsidian. Also time consuming, and if you are going to do it a lot I would suggest writing a script for it. But definitely doable

[Rose]

Is there a function to find the center of the viewport that works with things like TWBT?

[ViolinAnon]

I fail to see how obsidianizing using magma+water would give a different result from spawning obsidian directly. The problem comes from mining out of a huge block, so spawn only walls (and build floors out of obsidian [blocks]). It's still more work to spawn parts rather than a block that's mined out, of course.

I just assumed, for some reason, that casting obsidian that way would change the tile from air to obsidian.
Since my final goal is to have the entire tower smoothed out, then engraved, I think I'll be able to just create the giant block of obsidian, mine out the inside to create the rooms and whatnot, then use the 'tiletypes' commands to replace the floors, ramps and stairs into obsidian.

[lethosor]

Is there a function to find the center of the viewport that works with things like TWBT?

Gui::getDwarfmodeViewDims() is modified by TWBT (specifically the map_* fields). I'm guessing you can use that to find the center of whatever you need.

[Clément]

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

Here it is. I tried to write some documentation (in README and headers), not sure if it is clear. It is also missing pkg-config or cmake find_package stuff so you'll have to add the compile and link flags manually. There is nothing special though, simply add the usual include path (-I/install/path/include), lib path (-L/install/path/lib) and link flags (-ldfhack-client-qt).

It is not much tested and the API may need improvements. Don't hesitate to report issues or make suggestions or improve it yourself.

[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

Here it is. I tried to write some documentation (in README and headers), not sure if it is clear. It is also missing pkg-config or cmake find_package stuff so you'll have to add the compile and link flags manually. There is nothing special though, simply add the usual include path (-I/install/path/include), lib path (-L/install/path/lib) and link flags (-ldfhack-client-qt).

It is not much tested and the API may need improvements. Don't hesitate to report issues or make suggestions or improve it yourself.

Thanks!!
I continued some time ago just where you finished with this repo.
I parse codegen,out.xml from DFHack and generate automatically a proto file and a remote C++ object for each df structure, so you write something like this

    rdf::DF_Instance d;
    d.connect();
    auto& global = *d.global();
    auto& world = global.world();
    auto& units = world.units();
    auto& units_all = units.all();
    auto& a_unit_pointer = units_all[0];
    auto& a_unit = *a_unit_pointer;
    auto& unit_name = a_unit.name();


But I fell in love with your qt.widget dfhack plugin. It's a wonderful solution to the problem of creating graphical DF tools. You just access the DF data directly from the plugin.
My solution works, but it's overengineered, used a lot of disk space and compilation times were atrocious.

I'm working in a graphical viewer for df structures (like gui-gm editor). I made it work in linux using my library, but, for the reasons mentioned above, I didn't publish it.

This changes now with your plugin. I can generate automatically a QAbstractItemModel and custom nodes for each df structure/field and recreate the graphical viewer easily without the overhead of my library.

So, again, thanks for your work and I hope that soon I could publish the plugin.

[Clément]

You just access the DF data directly from the plugin.

Not that directly. Don't forget you are running in a different thread. DF may change the data unexpectedly.

[Clément]

Does Units::getVisibleName really require a mutable df::unit pointer?

[lethosor]

A lot of functions in modules don't need to mutate anything but take a non-const pointer anyway. (Some are related to all methods from df-structures being non-const, from what I remember, even if they're const in DF.)

[Clément]

Should I change my code to use non-const pointers or can the functions be fixed? Adding const shouldn't require to much code changes, but it may break ABI (plugins are recompiled for each version, so not a problem?).

[lethosor]

Yeah, it'd change some symbol names. There would still be the issue of calling non-const virtual methods on a const object, though, which would be harder to fix (and would require codegen changes to work properly). It's not impossible, and a temporary solution could make only "const" additions that compile, but it's potentially tedious.
I think your easiest solution at the moment (even though it's bad) is to just cast away the const for library functions that require it.

[Clément]

Okay, I'll use mutable pointers, it is not really issue for me. I just wanted to know if it was an easy fix.