add Units::chopTree

[ab9rf]

this implements the bay12-provided entry point for chopping down trees

[ab9rf]

needs Lua API access (and accompanying documentation)

where does the "accompanying documentation" go? docs/api only has a section for Maps and that is dreadfully incomplete

[myk002]

Lua docs go in the https://github.com/DFHack/dfhack/blob/develop/docs/dev/Lua%20API.rst mega-file

[lethosor]

Random thought: I feel like this might make more sense for DFHack purposes as part of a "plants" module (which we don't have) or "maps", or "designations" (?), or maybe something else. The tree is the target, not the unit. But I realize we're wrapping a Bay12 function that takes just a unit and position, so making our own, "better" wrapper can wait for another time.

[myk002]

the coordinates are supposed to be for a tree, right? I got a segfault when trying this out:

#0  0x0000000001933374 in ?? ()
#1  0x00007ffff79b3ac3 in std::function<void (df::unit*, short, short, short)>::operator()(df::unit*, short, short, short) const (__args#3=<optimized out>, __args#2=<optimized out>, __args#1=<optimized out>, 
    __args#0=<optimized out>, this=<optimized out>)
    at /usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13/bits/std_function.h:591
#2  DFHack::Units::chopTree (unit=<optimized out>, x=<optimized out>, y=<optimized out>, z=<optimized out>)
    at /home/myk/src/dfhack/library/modules/Units.cpp:2363

[myk002]

hrm, it worked fine the second time. I wonder if the issue was that I chose the "wrong" tile of a multi-tile tree?

I see the effects of remote chopping on the velocity vector of the logs. They shoot across the map if the unit "responsible" for the chopping isn't nearby. We will probably want to wrap this with something that "catches" the logs and sets them gently down where the trunk was.

[myk002]

seems to consistently crash on multi-tile trees.

[ab9rf]

I see the effects of remote chopping on the velocity vector of the logs. They shoot across the map if the unit "responsible" for the chopping isn't nearby.

putnam did warn about this, and rumrusher has confessed to having weaponized this in the past

[ab9rf]

I wonder if the issue was that I chose the "wrong" tile of a multi-tile tree?

the same function that the function pointer points to is also called by organic code, in code that looks like this:

    if (iVar121 == 0) {
      uVar117 = (pjVar92->pos).x;
      uVar39 = (pjVar92->pos).y;
      sVar37 = (pjVar92->pos).z;
      tVar45 = world::getTileType(&world,uVar117,uVar39,sVar37);
      uVar108 = FUN_1401ebcf0(tVar45);
      if ((char)uVar108 == '\0') {
        unitst::clearPath(param_1);
        *(undefined4 *)local_1950 = 0;
        pbVar83 = (building_actualst *)CONCAT71((int7)((ulonglong)local_1950 >> 8),1);
        *param_2 = 1;
        game.minimap.mustmake = 1;
      }
      else {
        unitst::chopTree(param_1,uVar117,uVar39,sVar37);
        *(undefined4 *)local_1950 = 0;
        if ((param_1->job).current_job == (job *)0x0) {
          uVar56 = unitst::clearPath(param_1);
          pbVar83 = (building_actualst *)CONCAT71((int7)((ulonglong)uVar56 >> 8),1);
          *param_2 = 1;
          game.minimap.mustmake = 1;
        }
        else {
          pbVar83 = (building_actualst *)((ulonglong)local_1950 & 0xffffffffffffff00);
          *param_2 = 0;
          game.minimap.mustmake = 1;
        }
      }
      break;
    }

(iVar121 == 0 is just testing that the job completion timer for the ChopTree job has run its course, and FUN_1401ebcf0 is a tiletype classifier that returns true if the tiletype is a tree trunk of some sort)

[myk002]

Is pjVar92 the tree? I'll check what that says for multi-tile trees

[ab9rf]

Is pjVar92 the tree? I'll check what that says for multi-tile trees

no, pjVar92 is the chop tree job, so the coordinates should presumably match what you'd expect for what would be in the coordinates of a chop tree job designated in the "normal" way. getplants has fairly solid logic for this, iirc

[ab9rf]

i just dug through the chopTree code and there's some vaguely subtle issues that makes this call rather tricky to use

basically, after the tree is chopped, down, if the game is in dwarf mode, the game then does various things with respect to the current job of the unit that was chosen to do the tree cutting. if that unit has a job but that job is not a chopTree job (to cut down this particular tree, in all likelihood), it'll probably make a hash of that unit's current state. if the unit has no job (current_job is NULL) then there will be a mess of diagnostics issued, but the game should ultimately be ok with it

in short, this entry point probably isn't going to be useful to us until Bay12 detangles the "chop tree down" part from the "record that this particular urist chopped down a tree" part

[ab9rf]

closing this since the entry point is not actually useful anyway