Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
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.
Attached Files

- Relationships
related to 0006590resolvedToady One Root Mining Designation Not Graphically Noted 
has duplicate 0008504resolvedFootkerchief Dwarf cuts down tree from second level 
related to 0006591new Trees are always chopped completely, regardless of where chopping designation is given 

-  Notes
(0025813)
scriberman (reporter)
2014-07-11 11:51

Save file http://dffd.wimbli.com/file.php?id=8877 [^]
(0025814)
Footkerchief (manager)
2014-07-11 11:52

0006590?
(0025821)
scriberman (reporter)
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 (reporter)
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.

- Issue History
Date Modified Username Field Change
2014-07-11 11:37 scriberman New Issue
2014-07-11 11:38 scriberman Issue Monitored: scriberman
2014-07-11 11:51 scriberman Note Added: 0025813
2014-07-11 11:52 Footkerchief Note Added: 0025814
2014-07-11 11:52 Footkerchief Assigned To => Footkerchief
2014-07-11 11:52 Footkerchief Status new => needs feedback
2014-07-11 11:52 Footkerchief Relationship added related to 0006590
2014-07-11 12:12 scriberman Note Added: 0025821
2014-07-11 12:12 scriberman Status needs feedback => assigned
2014-07-11 12:16 scriberman Note Edited: 0025821 View Revisions
2014-07-18 20:53 Karzim Note Added: 0026929
2014-07-24 19:33 lethosor Assigned To Footkerchief => lethosor
2014-07-24 19:33 lethosor Status assigned => acknowledged
2014-07-28 16:32 lethosor Status acknowledged => confirmed
2014-07-29 05:26 lethosor Relationship added parent of 0007648
2014-07-29 05:27 lethosor Summary Multi-level multi-tree chop designating fails to designate => Multi-level multi-tree chop designating fails to designate correctly
2014-08-10 09:53 Footkerchief Relationship added related to 0006591
2014-08-10 09:53 Footkerchief Relationship deleted parent of 0007648
2014-11-02 10:00 Footkerchief Relationship added has duplicate 0008504


Copyright © 2000 - 2010 MantisBT Group
Powered by Mantis Bugtracker