Script error when applying quickfortress.csv /surface2_query

[Trabber]

Preamble: I also cannot tell if the issue is with the blueprint, or with quickfort itself. But since this is one of the library blueprints I assume this to be the right place for the bug report either way.

DFHack version 0.47.05-r1 (release) on x86_64

There is a script crash in "/surface2_query" which prevents the hidden "surface2_doors" blueprint from being attempted:

applying blueprint: "/surface2_query"
...rtress 0.47.05/hack/scripts/internal/quickfort/query.lua:83: attempt to index a nil value (local 'pos2')
stack traceback:
        ...rtress 0.47.05/hack/scripts/internal/quickfort/query.lua:83: in upvalue 'is_same_coord'
        ...rtress 0.47.05/hack/scripts/internal/quickfort/query.lua:143: in field '?'
        ...ress 0.47.05/hack/scripts/internal/quickfort/command.lua:54: in field 'do_command_internal'
        ...ortress 0.47.05/hack/scripts/internal/quickfort/meta.lua:52: in upvalue 'do_meta'
        ...ortress 0.47.05/hack/scripts/internal/quickfort/meta.lua:59: in field '?'
        ...ress 0.47.05/hack/scripts/internal/quickfort/command.lua:54: in global 'do_command_internal'
        ...ress 0.47.05/hack/scripts/internal/quickfort/command.lua:120: in function <...ress 0.47.05/hack/scripts/internal/quickfort/command.lua:116>
        [C]: in function 'dfhack.call_with_finalizer'
        ...F\0.47.05-r02\Dwarf Fortress 0.47.05\hack\lua\dfhack.lua:72: in function 'dfhack.with_finalize'
        ...ress 0.47.05/hack/scripts/internal/quickfort/command.lua:114: in field '?'
        ...05-r02\Dwarf Fortress 0.47.05/hack/scripts/quickfort.lua:221: in local 'script_code'
        ...F\0.47.05-r02\Dwarf Fortress 0.47.05\hack\lua\dfhack.lua:680: in function 'dfhack.run_script_with_env'
        (...tail calls...)

Probably unrelated is a an error message in another query blueprint from the same file. "/storeroom2a_place" gives the following error: invalid key sequence in cell Z508: "x(1x1)" The same sequence in cell E508 does not cause an error and both correspond with an existing up/down stair.

[Trabber]

A few more details:

• At the time of the error, the cursor position seems to be the tile which maps to cell B185.
• The code seems to be assuming that the stockpile menu (or other menu which provides an in-game cursor) is open, however there is no such menu open and to get my cursor position after the script dies I need to open such a menu.
• That cell invokes a "bodyparts" alias which is not defined in aliasses-common.txt.

As my next step of debugging I am going to try making a custom alias with what I suspect bodyparts was supposed to be.

[Trabber]

That did resolve the error, so I would say there are 2 changes needed for this

• Add bodyparts: {refuseprefix}b{Right}{Down 2}p^ at line 194 of /hack/data/quickfort/aliases-common.txt
• add error checking and handling for undefined aliases

[lethosor]

Thanks for narrowing this down!

• add error checking and handling for undefined aliases

I believe this was addressed in https://github.com/DFHack/scripts/pull/263 already (which will be part of the next release). There are several files involved, so if you would like to test those fixes, you can probably replace your hack/scripts folder with the contents of https://github.com/dfhack/scripts (in this case, downloading the repo as a zip should work).

From a quick search, the bodyparts issue appears to still be present. cc @myk002

[myk002]

Thanks for finding this!

• I confirmed that the script error no longer occurs in current dev
• I changed the bodyparts reference to use the intended aliases: {forbidrawhides}{forbidcraftrefuse}. Sorry for missing this when I updated dreamfort similarly!
• stockpiles no longer rely on x to remove tiles over stairways. x is not yet implemented for #place blueprints (which is why it was generating a warning)

All these fixes were in the quickfortress.csv file itself. After #1839 is merged, you can get the updated file from https://github.com/DFHack/dfhack/tree/develop/data/blueprints/library

For reference, the missing bodyparts alias didn't generate an error because quickfort can't know what is intended to be an alias and what is intended as literal keystrokes. If an alias with the same name exists, it treats the string as an alias. Otherwise, it has to assume that raw keystrokes are intended. I realize that it makes missing aliases more difficult to figure out, but this behavior is inherited from the original Python quickfort and is required for compatibility.

You can force a string to be interpreted as an alias and not as raw keystrokes by surrounding the name in curly brackets: {bodyparts}. If it were written this way and the bodyparts alias were not defined, then an error would be shown. It's up to the blueprint author to actually use this feature, though.