There was a thread
about tree growth that made me curious, so i made a very small test fort, in a 2x1 embark, clear-cutting one of the embark squares every year and deliberately harvesting trees in the other one for seven years or so.
Too short to be conclusive, but
a) harvesting large trees and leaving a few solitary ones to grow tends to give more wood per year than regular clearcutting, although the first clear-cut upon arrival gives a
lot of wood upfront.
b) the number of saplings that show up appears to ramp up massively after embark, so my grasslands/woodlands embark started to get filled up with young trees by year 4+, making careful selection rather irrelevant: since 15-30 young trees would mature per year and embark square, that meant 50-100 logs per year from the clear-cut square vs. 80-150 from the "select harvesting" one (which included a lot of weeding out spindly young trees to make room for new large ones).
Other observations: getting saddled with a king when only using the starting seven (no migration allowed) is sure interesting, esp. when it's a king with four item preferences - rings, spears, windows and gauntlets. Took a fair bit of attention to manage all those production orders, waiting for the yellow marker before fulfillment to postpone further mandates.
Dropping contents on a trackstop is the minecart's action, which means that if the content dumped was another minecart,
that one can also act in the turn it was dropped, e.g. dump items if it was in turn dumped onto another track stop.
Thus, a chain of trackstops allows "unfolding" a matryoshka-style stack of minecart in a minecart in a minecart etc.,
and if the minecarts are folded into the stack following build order - oldest cart outside, youngest deepest-nested inside - they can all unfold in the same game step. I tried it with twelve trackstops and thirteen minecarts, and while it took several in-game weeks of route and stockpile fiddling, it was quite satisfying to see a single minecart instantly transform into a queue of thirteen. Of course, this would be much more interesting if we could automatically load goods into carts (apart from fluids).
BTW: trackstops work the same on track and on ordinary floor; they seem to not work when "hanging" (built on constructed floor which is afterwards deconstructed; can be done with most buildings). They also appear to set a cart's "on track" rule when next to a downwards ramp - i.e. a cart coming from a tile with a track stop on non-track floor will still go down a ramp if not too fast, instead of jumping when coming off such floor otherwise. This applies both with operative and deactivated (invisible) track stop.
Switchback cart lift: carts coming from ordinary floor will jump over downward ramps, which allows a "switchback" direction change:
z0 z+1
═▲0 ═▼+▲0
visible
══0 ═.+═0
Track
A fast enough cart comes from the west on z0, goes up the ramp from z0 to z1, bumps against the wall or at least goes far enough into the ramp on the upper level, accelerates back west, crosses the flat floor tile and jumps over the ramp hole (since it comes from a non-track tile), then lands west of the hole and leaves west on z+1. Of course you can stack such direction-change arrays to make a one-line cart lift:
z(2k+1) z(2k)
0▲+▼▲▲0 0▲▲▼+▲0
visible
0 0
0═+▼╚═0→ ←0═╝▼+═0
track
Carts enter levels from the down ramp, leave to the next higher level in the direction of the arrow.
Most of the ramps need to be built, not carved, since cutting them from the stone would break the floors in many places.
The double ramps on each level are needed, since otherwise you'd either end up with carts losing speed and failing to clear the hole or going too fast and jumping into a bracing wall. And the whole thing is of no use anyway, since it's one-way, much slower than other cart lift designs, harder to build and not even particularly space-economic.
Author
Topic: Trivial findings (Read 463049 times)