Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Maximum Spin]

as Spin suggests confirmed even if Bumber suggests something not really as actively dangerous as I half recall

What Bumber mentions is exactly what I remember, yes. I'm pretty sure it did get fixed though, as the last time I designated tree cutting I didn't have this problem, but maybe dfhack was fixing it or something.

[Starver]

Well, I guess it is Vanilla-fixed, then, though I still avoid trying to invoke it - and don't work that way myself anyway.

Back to the suggestion, though:

Beyond the basic "clear this area, keep it cleared" I can see a need to sub-specify (either negatively or positively, perhaps in the dwarves-for-Burrow manner, but defaults to all active) tree-types to harvest, or not to. A fully-complete list (not like the Food-to-cook-with chooser that only picks up new things that now exist) so people can exclude fruiting trees that they may like growing there.

And though it is a comparatively recent addition, I would be personallg inconvenienced to lose the Priority level on (d)(t). Others may dislike losing the (M)ark-only element, and I can imagine that flooding a 3d box then vetting every marked-highlit tree is a viable practice at the moment, for those that don't mind/prefer doing this micromanagement.

The 3d boxing or terrain-following specification[1] would be good but I would be loathe to lose the (d)esignation control of such things, at the expense of the zone/area-based method (which I know Toady is looking at for all kinds of new things, possibly even workshops).

That said, in the UI shake-up, alongside/subsequent to the Steam expansion, it might be time to separate the non-digging (d)esignation items. I imaging many think (d)ig-c(h)annel, already ('digging' traditionally being downward process)  and maybe (d)ig-(d)riftmine.  Zoning the (d)(t) and (d)(p)lantgathethering (similar plant-type specification options?) might work. The (d)(s)moothing and (d)(e)ngraving could be revamped to better deal with the tricky wall-side nature of these[3] into a new submenu (and Track-carving, to make this linear-feature easier, but still allow the intentional disconnects currently exploited?). Traffic priority could be zoning, entirely and...what else? *flexes fingers to activate muscle-memory* ...ah, yes, (d)(b)ulk for melt/dump/etc or to undo those.  That'd be another cursory wiping (mouse or keyboard!) that might be .

So some sort of making (d)(p) equal to treefruit-picking, we say? And (with qualifications) tree-felling at least given a constrained auto-generation method of some kind (I know of Autochop, obviously, but it won't be a direct integration; likely more a similar system with slightly different focii). It might even be being already considered in the UI-shuffle (perhaps ask Threetoe on his relevent thread, that I've not read for a while), but with an eye for not totally ruining it for the more stuck-in-the-mud old-guard of players, hopefully.



[1] Maybe a combination of both? In cavern situations, an X/Y-floodfill that rolls over connected floors could easily (and should?) pick up two 'tree'-bases on the same X/Y tile but differing Zs. But avoid mid-trunk (woodcutter-accessible) tiles. Maybe. What of those growing out of the bottom of freshly filled cave-pools?

[2] (no longer footnoted!)

[3] Specify as a 'room' that applies the task to the walls it touches? Or even/additionally add it as an automatically area-decined task to the actual Room Designation that you're trying to improve, as that's quite often what you want it for. So long as you retain "free-zoning" for independent/preparatary smoothing/etc.

[PatrikLundell]

I don't think you can replace the current tree cutting designation scheme with zones without losing a lot of existing functionality. That does not mean tree cutting zones might be worthless, only that they can't be replacements.

Someone indicated cavern trees regrow faster than surface ones. The don't. They take the same 3 years to mature. However, they're not subjected to the sky visibility restriction (obviously) that the surface trees operate under (but still a two tile headroom one), so a lot more underground sapling become eligible for maturation.

My latest attempt to cut a tree above the surface level (a few months ago, using the latest DF version) ended in disaster as the moron decided to stand on the branch being cut rather than on the adjacent wall.

When clear cutting the caverns (which cannot be selected to get absolutely flat ones), I designate cutting from one corner of the embark to the opposite one on the highest cavern surface level, repeated for each lower level until reaching the bottom one. The newer designation on each tree replaces the older one, resulting in designations only at the surface level, regardless of what that level happen to be. An improvement to that logic so you can 3D designate with a useful result would fit the designation format, and so wouldn't need a zone one.

I can see a use case for zones to keep certain areas free of trees (using zones), but as soon as you want to tailor it it gets messy rather quickly. You could, of course, have a setting where you'd specify the keeping of all fruit brewable trees, all fruit trees, all seed bearing trees in some combination, or green list trees species by species, but you'd then most likely be pruning the result using individual tree designations, because you get more than enough of that species, or this tree, while of a desirable species, is located in an undesirable place, or simply too close to other trees.