Dwarf Fortress Bug Tracker - Dwarf Fortress
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007071Dwarf FortressDwarf Mode -- Jobs, Designationspublic2014-07-11 11:372014-07-29 05:27
Reporterscriberman 
Assigned Tolethosor 
PrioritylowSeverityminorReproducibilityalways
StatusconfirmedResolutionopen 
PlatformLinuxOSDebianOS VersionWheezy 7.5
Product Version0.40.02 
Target VersionFixed in Version 
Summary0007071: Multi-level multi-tree chop designating fails to designate correctly
DescriptionAfter testing on another bug, I decided to clearcut the entire forest, which seems like a reasonably useful action. :> Unexpectedly, some of the trees were not marked for chopping.

Selecting an area over only one z-level seems to work fine. Once multiple levels are involved, the results vary (consistently).

It looks like selections involving the tree parts higher up than the base, cause the base to not be selected.

Debian Wheezy 7.5
uname -a:
Linux 3.2.0-4-amd64 <POUND>1 SMP Debian 3.2.57-3+deb7u2 x86_64 GNU/Linux

Also, same results with Windows 7 Pro SP1 32bit, updates current.
Steps To ReproduceProcess (4 repetitions tested, with consistent results):
1) Fresh unpack of Dwarf Fortress 0.40.02 SDL from http://www.bay12games.com/dwarves/df_40_02_linux.tar.bz2 [^]
2) Create new world (World Size Smaller, History Short, all other options default).
3) Start New Game, immediately press "e" to Embark, then ENTER to Play Now.
4) "d-t" to chop trees, multi-level area; six permutations tested (each test encompassing at least a few trees):

Bugged tests:
 a) Marker start at z+1, Marker end at z (relative to bottom-most tree trunk base).
    Result: base not designated for chopping, treetops designated. (Would have been cool to see lumberjacks climbing up to do treetop cutting!)
 b) Marker start at z+1, Marker end at z-1 (relative to base).
    Result: same.
 c) Marker from z-1 to z+1.
    Result: same.
 d) Marker from z to z+1.
    Result: same.
Additional InformationWorks fine tests:
 e) Marker from z to z-1.
    Result: works fine.
 f) Marker from z-1 to z.
    Result: works fine.

Just in case this is save-file dependent, I will upload the save from my last test. Loading up the save produces the same results.
TagsNo tags attached.
Relationships
related to 0006590resolved Toady One Root Mining Designation Not Graphically Noted 
has duplicate 0008504resolved Footkerchief Dwarf cuts down tree from second level 
related to 0006591new  Trees are always chopped completely, regardless of where chopping designation is given 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2014-07-11 11:37scribermanNew Issue
2014-07-11 11:38scribermanIssue Monitored: scriberman
2014-07-11 11:51scribermanNote Added: 0025813
2014-07-11 11:52FootkerchiefNote Added: 0025814
2014-07-11 11:52FootkerchiefAssigned To => Footkerchief
2014-07-11 11:52FootkerchiefStatusnew => needs feedback
2014-07-11 11:52FootkerchiefRelationship addedrelated to 0006590
2014-07-11 12:12scribermanNote Added: 0025821
2014-07-11 12:12scribermanStatusneeds feedback => assigned
2014-07-11 12:16scribermanNote Edited: 0025821bug_revision_view_page.php?bugnote_id=0025821#r9618
2014-07-18 20:53KarzimNote Added: 0026929
2014-07-24 19:33lethosorAssigned ToFootkerchief => lethosor
2014-07-24 19:33lethosorStatusassigned => acknowledged
2014-07-28 16:32lethosorStatusacknowledged => confirmed
2014-07-29 05:26lethosorRelationship addedparent of 0007648
2014-07-29 05:27lethosorSummaryMulti-level multi-tree chop designating fails to designate => Multi-level multi-tree chop designating fails to designate correctly
2014-08-10 09:53FootkerchiefRelationship addedrelated to 0006591
2014-08-10 09:53FootkerchiefRelationship deletedparent of 0007648
2014-11-02 10:00FootkerchiefRelationship addedhas duplicate 0008504

Notes
(0025813)
scriberman   
2014-07-11 11:51   
Save file http://dffd.wimbli.com/file.php?id=8877 [^]
(0025814)
Footkerchief   
2014-07-11 11:52   
0006590?
(0025821)
scriberman   
2014-07-11 12:12   
(edited on: 2014-07-11 12:16)
I did not test anything related to roots. However, I think this might be different, since in my tests, the visibly-designated tree bases got chopped, while the apparently-non-designated tree bases were not chopped.

In other words, from what I could see in my tests, the designation did not occur, but in 6590, the designation occurs, and is acted upon, but is not visually indicated.

EDIT: Confirmed, that a z+1 to z-1 (which includes roots) behaves as I originally indicated; none of the tree is chopped.
(0026929)
Karzim   
2014-07-18 20:53   
I've found that only a single trunk tile of an individual tree can be designated for chopping. If you try to designate a different part of the tree to be chopped, the first designation is canceled.

When you do a chop tree designation, the uppermost, easternmost, southernmost (in that order) part of each tree's trunk in that area will be designated for chopping.

A work-around would be to use single-level designations starting at top Z-level and working down which will result in the tree bases being designated for chopping and none of the upper levels.