Print

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

[Warmist]

Question about the onReactionComplete eventful trigger. IIRC it only triggers when a product is actually created, is that still true? Also, if using both onReactionComplete and onJobCompleted will the always trigger in the same order, or will it be somewhat random which one triggers first?

Could be wrong but onReactionComplete(and the ing) is actually badly named (mea culpa). Should be along the lines "reaction product create". It triggers when reaction is creating a product. IIRC it does trigger more than once when it's doing reaction with multiple products and other strange stuff. onJobCompleted on the other hand is way different - it uses the eventmanager system where it periodically scans the jobs and sees if they changed (in this case got completed). Not sure on the specs of it (is it 100% accurate) there are some notes about false positives though.

[Roses]

Question about the onReactionComplete eventful trigger. IIRC it only triggers when a product is actually created, is that still true? Also, if using both onReactionComplete and onJobCompleted will the always trigger in the same order, or will it be somewhat random which one triggers first?

Could be wrong but onReactionComplete(and the ing) is actually badly named (mea culpa). Should be along the lines "reaction product create". It triggers when reaction is creating a product. IIRC it does trigger more than once when it's doing reaction with multiple products and other strange stuff. onJobCompleted on the other hand is way different - it uses the eventmanager system where it periodically scans the jobs and sees if they changed (in this case got completed). Not sure on the specs of it (is it 100% accurate) there are some notes about false positives though.

That sounds right, I remember looking into this a bunch a year or two ago and what you are saying is jogging my memory. I did forget about the multiple trigger, although if I had looked at the reaction-product-trigger script I would have seen that it explicitly says it triggers once per product.

As for onJobCompleted, looking at reaction-trigger it says that the frequency for the event needs to be set to 0 so that it ignores cancelled jobs. What does a frequency of 0 mean? I was under the impression that the frequency for the eventful stuff was just how ever many ticks in between the check (e.g. item-trigger has a 5 for INVENTORY_CHANGE, so every 5 ticks it checks for inventory changes), so is 0 a special case?

[Prismatic]

Reporting an issue with the "names.lua" script. Attempting to use it to rename a unit fails with the following error message:

Code: [Select]

...\Dwarf Fortress\DF 0.47/hack/scripts/names.lua:67: Cannot read field viewscreen_setupadventurest.adventurer: not found.
stack traceback:
        [C]: in metamethod '__index'
        ...\Dwarf Fortress\DF 0.47/hack/scripts/names.lua:67: in local 'fun'
        ...\Dwarf Fortress\DF 0.47\hack\lua\class.lua:98: in upvalue 'invoke_after_rec'
        ...\Dwarf Fortress\DF 0.47\hack\lua\class.lua:127: in global 'namescr'
        ...\Dwarf Fortress\DF 0.47/hack/scripts/names.lua:89: in local 'script_code'
        ...\Dwarf Fortress\DF 0.47\hack\lua\dfhack.lua:680: in function 'dfhack.run_script_with_env'
        (...tail calls...)


[lethosor]

Reporting an issue with the "names.lua" script. Attempting to use it to rename a unit fails with the following error message:

Code: [Select]

...\Dwarf Fortress\DF 0.47/hack/scripts/names.lua:67: Cannot read field viewscreen_setupadventurest.adventurer: not found.
stack traceback:
        [C]: in metamethod '__index'
        ...\Dwarf Fortress\DF 0.47/hack/scripts/names.lua:67: in local 'fun'
        ...\Dwarf Fortress\DF 0.47\hack\lua\class.lua:98: in upvalue 'invoke_after_rec'
        ...\Dwarf Fortress\DF 0.47\hack\lua\class.lua:127: in global 'namescr'
        ...\Dwarf Fortress\DF 0.47/hack/scripts/names.lua:89: in local 'script_code'
        ...\Dwarf Fortress\DF 0.47\hack\lua\dfhack.lua:680: in function 'dfhack.run_script_with_env'
        (...tail calls...)


Thanks for the report! I've figured out a fix, which will be in the next release.

If you're interested: creating the in-game name-editing screen is complicated, so instead of doing that, the script would create an adventurer setup screen, copy in the relevant name, and trigger that screen's logic to create the name-editing screen. However, the adventurer setup screen changed significantly in 0.47.01, to the point where this strategy is no longer possible (at least, I couldn't figure out how to set it up properly). Fortunately, the fortress setup screen can still be used for the same purpose, so I switched the script to use that.

[lethosor]

New release! https://github.com/DFHack/dfhack/releases/tag/0.47.04-r2 (Maybe some day I will update the changelog generator to produce a Bay12-friendly changelog too, but for now, you can find release notes there.)
This also means that the "stable" branch of the docs has been updated: https://docs.dfhack.org/en/stable/

I've been thinking a bit about how our release cycles have been going, particularly regarding bugfixes being delayed - for example, this one took a couple months to finally make its way into a release, which isn't ideal:

Regarding stonesense.. Is the expectation that it's currently supposed to be working, in -r1?  Or is that a future revision goal?
I've tried a default/brand-new install of both 0.47.04 + dfhack 0.47.04-r1, and attempting to launch stonesense crashes df and dfhack.

For reference, here is the issue. It's been around for a while, but Stonesense is large, complicated, and has few active devs (so thank you Rose for the fix!) so I didn't think it was worth holding off 0.47.04-r1 indefinitely for a fix. In retrospect, I probably should have made that more clear in the release notes. Our release notes are semi-generated now and really just focus on changes since the last release(s), not release-specific notes, but this is something we could improve.

At the same time, there is a weird and nasty bug on develop (well, hopefully just this one) that would definitely hold up an r2. Maybe we should start making smaller and more frequent "point" releases (like r1.1) with fixes like these, now that I think about it.

I've been using project boards on GitHub for a while to organize releases. They primarily have two benefits: keeping track of things that are part of a release (fixed issues, merged PRs), and keeping track of things that need to be addressed before the next release. The latter category has historically included lots of features, some of which can be time-consuming to get around to. Going forward, I think I would like to make smaller but more-frequent releases with whatever happens to be ready at the time (and maybe delaying for some important bugfixes). These would still follow the current versioning convention ("0.47.04-r3", "0.47.04-r4", etc.).

I realize this will impact third-party plugins, notably TWBT, because they will need to be recompiled more often due to DFHack requiring the plugin version to be compiled against the same DFHack version. I'm thinking of relaxing this restriction a bit, although I didn't think coming up with a proper approach was worth delaying r2 for. Once DFHack has reached stable status for a certain DF version, we usually haven't had structures issues that would warrant a plugin compatibility break, so I'm considering allowing plugins built for a stable DFHack version to be loaded under any other stable DFHack version for the same DF version (e.g. a plugin built for 0.47.04-r3 could load under 0.47.04-r4 and vice versa). We do already have a plugin ABI version indicator that we could use to prevent incompatible plugins from loading if the plugin ABI ever changes (although the last notable case I'm aware of was in 0.34.11-r4, when the structure of vmethod hooks changed). Open to suggestions here.

[PatrikLundell]

Thanks for the work!

I think smaller, more frequent releases would be useful, perhaps with an aim for one every month or so (assuming there's enough stuff to make it worthwhile, of course, resulting in less frequent releases as a version matures), with extra ones for the occasional "nasty bug" cases. If post Premium DF development results in minor releases of the current version results in monthly releases we'd get a natural pace setter there, but there is a way to go before we reach that stage.

[PeridexisErrant]

I'm a huge fan of frequent and thus small releases - I've known some open source projects to automate the whole process to automatically ship the stable branch from a weekly cron job if it's changed, or even cut a new release after merging every single pull request.

I'm also not too worried about external plugins - though a more relaxed approach where compatibility is based on ABI rather than exact version would be good.  It would be lovely if TwbT could be merged upstream into DFHack now that it's no longer under development too, which would solve that distribution problem...

[waterphage13]

https://drive.google.com/file/d/11L_co26cN2ba3ugrASdxN6zXydNUppdo/view?usp=sharing
<a href="http://www.imgzilla.ru/view-image/aac9956a425651da86cb009974a9345e.png" target="_blank">[/url]
What can cause this errors?
P.S.:
Found that path was not on a latin symbols.

[Roses]

Some questions about the lua API

1. dfhack.gui.getDepthAt(x, y) - This states that it "Returns the distance from the z-level of the tile at map coordinates (x, y) to the closest ground z-level below". I'm not really sure what it is tying to say, since it doesn't take a z level as an argument.
2. dfhack.job.getGeneralRef(job, type) - By type, does it mean something like "df.general_ref_building_holderst"
3. dfhack.items.moveToBuilding(item,building[,use_mode[,force_in_building]) - When using force_in_building, should use_mode = 2? Is force_in_building temporary?
4. dfhack.buildings.checkFreeTiles(pos,size[,extents,change_extents,allow_occupied]) - What is the format for size?

[Bumber]

How do I check the type of a block_events struct in Lua? I want the one of type df.block_square_event_type.frozen_liquid (if it exists for the block.)

I see the line <vmethod ret-type='block_square_event_type' name='getType'/> in df/structures, but I'm sure if I can call that in Lua.

Is there a proper way to do this, or should I just check for the existence of a "tiles" array (which only the frozen_liquid type seems to have?)


Found something odd in MapCache.cpp:

Code: [Select]

case SOIL:
{
    auto &biome = mblock->biomeInfoAt(pos);
    rv.mat_index = biome.layer_stone[mblock->layerIndexAt(pos)];

    if (getGroundType(rv.mat_index) == G_STONE)
    {
        int idx = biome.default_soil;
        if (idx >= 0)
            rv.mat_index = idx;
    }

    break;
}

case STONE:
{
    auto &biome = mblock->biomeInfoAt(pos);
    rv.mat_index = biome.layer_stone[mblock->layerIndexAt(pos)];

    if (getGroundType(rv.mat_index) == G_SOIL)
    {
        int idx = biome.default_stone;
        if (idx >= 0)
            rv.mat_index = idx;
    }

    break;
}
The checks for G_SOIL and G_STONE seem to be swapped. Is this a mistake or not?

[Warmist]

Some questions about the lua API

1. dfhack.gui.getDepthAt(x, y) - This states that it "Returns the distance from the z-level of the tile at map coordinates (x, y) to the closest ground z-level below". I'm not really sure what it is tying to say, since it doesn't take a z level as an argument.

Not sure, but it seems as it's for twbt and similar stuff. It reports it for current screen?

2. dfhack.job.getGeneralRef(job, type) - By type, does it mean something like "df.general_ref_building_holderst"

Nope it's df.general_ref_type enum

3. dfhack.items.moveToBuilding(item,building[,use_mode[,force_in_building]) - When using force_in_building, should use_mode = 2? Is force_in_building temporary?

Don't know this one. But only use_mode=0 or use_mode=2 supported and you can use it with use_mode==0 force_in_building. Does not help that both are my scripts :< . The lever one creates a lever with real mechanisms.

4. -- don't know

How do I check the type of a block_events struct in Lua? I want the one of type df.block_square_event_type.frozen_liquid (if it exists for the block.)

I see the line <vmethod ret-type='block_square_event_type' name='getType'/> in df/structures, but I'm sure if I can call that in Lua.

You can just do "event:getType()" as lua supports vmethods (even if it does not enumerate them when printing members).

As for onJobCompleted, looking at reaction-trigger it says that the frequency for the event needs to be set to 0 so that it ignores cancelled jobs. What does a frequency of 0 mean? I was under the impression that the frequency for the eventful stuff was just how ever many ticks in between the check (e.g. item-trigger has a 5 for INVENTORY_CHANGE, so every 5 ticks it checks for inventory changes), so is 0 a special case?

IIRC 0 is just every frame (i.e. triggers when tick==current_tick)?

[Bumber]

You can just do "event:getType()" as lua supports vmethods (even if it does not enumerate them when printing members).

Works, thanks!

[lethosor]

1. dfhack.gui.getDepthAt(x, y) - This states that it "Returns the distance from the z-level of the tile at map coordinates (x, y) to the closest ground z-level below". I'm not really sure what it is tying to say, since it doesn't take a z level as an argument.

Like Warmist said, it's for TWBT. Maybe the docs should read "distance in z-levels" or something. Basically, it's supposed to take in x and y map coordinates, and calculate the number of z-levels you would need to move down to reach a solid tile. This only happens when TWBT or another plugin is enabled that implements this behavior, though. The default behavior is to always return 0.

3. dfhack.items.moveToBuilding(item,building[,use_mode[,force_in_building]) - When using force_in_building, should use_mode = 2? Is force_in_building temporary?

force_in_building is only used here. It looks to me like the opposite of what you said - if you want the item to be "in" the building, and don't set use_mode = 2, you'll need to set force_in_building = true. I'm not very familiar with why this behavior makes sense, though.

4. dfhack.buildings.checkFreeTiles(pos,size[,extents,change_extents,allow_occupied]) - What is the format for size?

From its definition, it takes a df::coord2d. Not sure off the top of my head whether there's a shorthand, but passing in a table with "x" and "y" keys set might work.

How do I check the type of a block_events struct in Lua? I want the one of type df.block_square_event_type.frozen_liquid (if it exists for the block.)

I see the line <vmethod ret-type='block_square_event_type' name='getType'/> in df/structures, but I'm sure if I can call that in Lua.

Is there a proper way to do this, or should I just check for the existence of a "tiles" array (which only the frozen_liquid type seems to have?)

A couple other ways, in addition to what Warmist mentioned:

Code: [Select]

df.block_square_event_frozen_liquidst:is_instance(event)
event._type == df.block_square_event_frozen_liquidst

https://docs.dfhack.org/en/stable/docs/Lua%20API.html#struct-references mentions vmethod calls, by the way, although it is a very brief mention.

Found something odd in MapCache.cpp:
<snip>

The checks for G_SOIL and G_STONE seem to be swapped. Is this a mistake or not?

At first glance, I think it's intentional. In the soil case, it looks up the material at the specified position. If it happens to actually be stone, instead of soil, then it tries to look up the default soil type, and uses that for the return value instead if it's available.
Are you seeing behavior that would suggest that this is incorrect, or did this just look surprising from a read-through?

[Bumber]

Are you seeing behavior that would suggest that this is incorrect, or did this just look surprising from a read-through?

Just stumbled across it while looking up how base tiles are calculated.

[Silverwing235]

Not quite the place to do this, I know, but could the self-closing tag stuff be related to some of the problems that have arisen, or not? *

(*Exhibit 2.) Edit: all solved - just getting rid of an error that spellcheck did not pick up, and got into my freaking marrow to roast it when gazed upon.