search

DFHack / dfhack

Memory hacking library for Dwarf Fortress and a set of tools that use it
Other
1.87k stars 475 forks source link

Quickfort unable to designate Tracks on excavated ramps #2004

Closed johnabsher closed 2 years ago

johnabsher commented 2 years ago

You are unable to designate tracks on upwards or downwards slopes. Some testing:

The blueprint :

#dig
T(1x2),#
      ,#

When run on a single 2-tile stretch w/ a stone floor to the south and an upwards ramp to the north

|^|
| |

gives me

|^|
|↑|

With just a single tile track pointing north on the southern tile, and no change to the northern one. I would have expected something like 

|⇩|
|↑|

With a N track on the bottom, and a S Ramp on top.

myk002 commented 2 years ago

Looking at the code, designating ramps on upwards slopes should work, but I expect nothing to happen for downwards slopes. The base game doesn't designate anything for downwards slopes either (IIRC). I'll try to reproduce this issue tomorrow, but just to check, the upwards slope in your example was a hard material, right?

Until I get this fixed, you can probably use single-tile track designations to work around the issue. E.g.:

#dig
trackrampS
trackN
johnabsher commented 2 years ago

Yep - hard stone channeled from the layer above

myk002 commented 2 years ago

I was unable to reproduce this in my fort. I similarly had an excavated ramp and applied the following blueprint (track.csv) with the cursor on a ramp (that is, an upward slope) with a floor tile to the south:

#dig
T(1x2)

I ran the following command and got the output:

[DFHack]# quickfort run -v track.csv
applying spreadsheet cell A2 with text "T(1x2)" to map coordinates (55, 46, 117)
setting priority to 4
setting priority to 4
run track.csv -n  successfully completed
  Tiles designated for digging: 2

Which is what I expected, and on the map I see a trackrampS and a trackN, also as expected.

Do you get the same output with quickfort run -v? Could you upload your savegame somewhere so I can see what is different about your setup?

johnabsher commented 2 years ago

So I've uploaded a little video to show what happens: https://user-images.githubusercontent.com/28197042/152809573-008ad57a-0636-4c12-96e3-73c686d43ebb.mp4 (Maybe it's something silly like not placing the cursor correctly?)

And here's a savegame: Download Link

Some other info if it's helpful:

myk002 commented 2 years ago

Thank you for the video and savegame -- it made the problem quickly clear to me. The issue is that there was a bug here, but I have fixed it since the latest official release. I just happen to have done a good amount of work on tracks recently.

You can pick up a recent dev build from https://dfhack.org/builds/ (click on the build badge under "Unstable automated builds" and download the build for OSX) or compile it yourself

It is possible that just updating the quickfort script itself will work. I don't think I depend on any recent DFHack core changes, but it's been a while since the last release and I'm not completely sure. You can try this first, though, and see if it works for you.

I'm going to close this bug report, since the issue has technically been fixed. Please feel free to continue this discussion on the forums if you have any followup questions.