Print

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

[Trabber Shir]

The wiki suggests that a minecart track for swim training only be 5 deep, but it does not explain why. I am hoping someone can clarify while my dwarves work on the science apparatus I have designed for testing this idea.

As the title suggests however, I am not just trying to train swimming, but attributes. Just for fun, I am maxing out some dwarves in various ways (legendary +5 in a wide range of skills, and as is important here, highest tier in any attributes I can figure out how to increase). And this sentence on the adventure mode part of the swimmer wiki page caught my attention:

Drowning itself can also be beneficial, as certain attributes, notably toughness and endurance, greatly benefit from the strain caused by the experience

I then found this forum post:
http://www.bay12forums.com/smf/index.php?topic=140163.msg8006324#msg8006324

I recommend jamming them into two tiles with 13/7 water - the half-time drowning will give about 550 points/month to toughness and endurance (doing three tiles with 776 will not boost this). Civ alerts are excellent for doing this for whole population.

This implies to me that I should be able to come up with a length of track using rollers, which if submerged 7/7 under a ceiling, but in air on both ends, will train swimming, toughness, and endurance while not risking death to the riders.

The apparatus I have designed will let me figure out how many rollers at what power are needed to keep the cart moving and push it up a ramp out of the water at the end. But I cannot find any data as to how long a very low stat dwarf can be drowning without dying. In the worst case scenario I should be able to come up with a safe length through save scumming, but I am hoping someone with a better understanding can save me some time on my research.

edit: I had forgotten how rollers work, should have done more research on that front before starting the design. Only real question is therefore how many submerged lowest power roller tracks can a dwarf ride before dying from drowning.

[anewaname]

The wiki suggests that a minecart track for swim training only be 5 deep, but it does not explain why. I am hoping someone can clarify while my dwarves work on the science apparatus I have designed for testing this idea.

The wiki section on loading liquids. So, if the liquid is 6+ your minecarts will fill up and it will stop being training.

[DwarfStar]

The wiki suggests that a minecart track for swim training only be 5 deep, but it does not explain why. I am hoping someone can clarify while my dwarves work on the science apparatus I have designed for testing this idea.

The wiki section on loading liquids. So, if the liquid is 6+ your minecarts will fill up and it will stop being training.

But are the dorfs supposed to be *in* the mine cart while riding it? I always figured they were hanging off the side, otherwise there wouldn't be any room for the goods. Or for that matter, I thought it was OK to ride a mine cart full of magma, which would cause drowning if that were a thing, not to mention other minor pyrotechnic problems.

[Trabber Shir]

Project got interrupted, but I see your point. Will be interesting to see if they get out of the minecart when it fills with water. Testing should commence later today.

Curiously, filling a minecart with magma does not injure a dwarf riding it.

From that same section on the wiki implies to me that it just makes the minecraft becomes effectively 459Γ, heavier which complicates impulse ramp designs. My choice to use rollers along most of the track should negate that drawback.

[Thisfox]

.....not to mention other minor pyrotechnic problems.

When I originally arrived at this !!hospital!! I could have sworn it wasn't on fire.

[gchristopher]

I've done this. At 5/7, you can make the minecart/swimming ride be as long as you like, and they train swimming while riding the minecart.

[Trabber Shir]

I have done the 5/7 track before, the dwarves only train swimming. According to the sources above, I should be able to give them the "drowning" condition with water deeper than 7/7 and that may boost additional attributes quite fast.

The test has been delayed again. I am not sure what took the fort from 75FPS to less than 20, but trying to troubleshoot that ate the day's play time away. I think all I am missing for the first run of the test is actually flooding the track though.

[Trabber Shir]

First Test with 39 submerged tiles most governed by slowest speed rollers (was supposed to be 17 tiles, but my pump was accidentally powered by a roller, so...):

• The test subject "Stukos" according to dwarf threapist is starting with 232 endurance and 1318 toughness.
• Drowning status was observed on entering the second 7/7 tile (although it may have triggered a few ticks sooner due to me looking at the wrong page of his details in prior ticks).
• He is separated from the minecart between the 3rd and 4th submerged tiles (the cart goes on the the 4th but he stays in the third, still alive and still drowning)
• Fully submerged it takes 10 steps (. key) for the minecart (unloaded) to advance 1 tile on a slowest speed roller in 7/7 water.
• As the cart reaches the 8th tile, Stukos is still alive and drowning in the 3rd tile. Dwarf Therapist now reports his stats as 233 endurance and 1319 toughness, so 1 point of increase to each in 80 ticks seems extremely promising.
• As the minecart reaches the 12th submerged tile, Stukos has successfully moved back to the second submerged tile. Stats are up to 234/1320
• As the minecart reaches the 19th submerged tile, which should have been the 17th and final if not for my accidentally powered pump issue, Stukos is still alive and still drowning in the second submerged tile with stats of 235/1321. So, assuming I can keep the dwarf in the minecart, it seems 17 was too short for the first test (assuming endurance and not toughness is the main limiting factor for drowning). I have designated an extension of my under construction improved test track to 40 blocks.
• The minecart got stuck on the first horizontal track without a roller (the 20th submerged one) am going to unpause to see if stukos manages to swim to safety. Now 236/1322
• The test subject did not survive.

Back-of the napkin math so far gives me about 1 point per 75 ticks. I am assuming I can raise those stats by a total of 4 in 300 ticks with a 30 block long submerged track. Turning around for the next stretch in 20 ticks (2 blocks) while the dwarf catches his breath and resets the drowning timer should be easily doable and gives up an average of 1 point in each of the 2 improved attributes every 80 ticks. Or 420 points per month or not quite 2 tiers. Which is quite a bit slower than Fleeting Frames got in his testing (linked in this thread's OP) from just forcing them to swim in 13 deep water for a month. On the other hand, it is an order of magnitude faster than military training in my experience and should not require any micromanagement to improve the entire population once fully designed and built.

I am now going to re-load and try with the lowest toughness dwarf in the fort. Expect those results tomorrow, also hopefully the first results on the new track where I can get more precise data to hopefully determine the longest drowning track a dwarf with 100 in all attributes can survive.

I am also wondering if this project is making this thread be in the wrong sub-forum, I seem to remember there being a special sub-forum for doing science, but cannot find it.

Also, final thought for the night. This does not seem to be adding any experience to any skill other than swimming, but the calculations on the attributes page of the wiki (https://dwarffortresswiki.org/index.php/DF2014:Attribute#Training_attributes) would imply that drowning is increasing these attributes at the same rate as using or training at least 60 skills simultaneously. Thus I am curious if it respects the attribute cap.

[Moeteru]

You may find that there's no way to make them stay in the minecart once they start drowning.
If that's the case then there still may be a way to do it. If you train them in swimming first using a normal minecart pool then they should (hopefully) be able to find their way out of the water once they start drowning. It should be possible to use statues to stop them from swimming back along the track, instead forcing them to take a longer path which gives them more drowning experience.

[Trabber Shir]

The abandoning of the cart seems to have been due to rollers on corners and/or down ramps. After cutting back to the strictly necessary rollers everything worked flawlessly. Next post with detailed results of the second test run will be up as soon as I get it formatted.

Spoiler: it works a lot better than my initial test suggested it would.

[Trabber Shir]

Second test subject: Calovi with a healthy 1396 endurance and a paltry 543 toughness is the most flimsy dwarf in my fort.

Calovi boarded the test track (repaired, a 17 tile long drowning track, then 3 tiles for breathing, then 17 more of drowning) on 129-03-20 with toughness/endurance of 543/1396.

• Drowning began on the second tick while submerged.
• cart and colovi advanced to the second tile on the 14th tick submerged
• the 15th step advanced them to the third submerged tile ... That was unexpected.
• next advance was on the 25th tick. I see a depth 6 tile moving about the chamber, it seems I did not get it completely full which risks colovi getting a premature bredth and causes flow which could explain the anomalous acceleration on the 15th tick.
• next advance on tick 36. Stats:544/1397. Will try to record on every tile advancement from now on.
• next advance on tick 46. Stats:544/1397.
• next advance on tick 57. Stats:544/1397.
• next advance on tick 68. Stats:544/1397.
• next advance on tick 78. Stats:545/1398.
• next advance on tick 89. Stats:545/1398.
• next advance on tick 100. Stats:545/1398.
• next advance on tick 110. Stats:545/1398.
• next advance on tick 121. Stats:545/1398.
• next advance on tick 132. Stats:546/1399.
• next advance on tick 142. Stats:546/1399.
• next advance on tick 153. Stats:546/1399.
• next advance on tick 164. Stats:546/1399. Calovi and the minecart are now on a "highest speed" roller to get up a ramp out of the water and around a bend which cannot have rollers due to the pump power issue.
• next advance on tick 167. Stats:546/1399. Although out of the water, Calovi is still drowning according to her wounds page.
• Rolled to the next square on tick 168 and is now showing as "winded" rather than "drowning". I wonder how that may affect her ability to survive the return trip.
• Rolled to the last dry square on tick 170.
• Back underwater on tick 173. Still winded (as opposed to drowning)
• As of tick 174 she is "drowning" again. Stats:547/1399. ... Interesting, the two attributes are not actually raising at the same time.
• next advance on tick 180. Stats: 547/1400.
• next advance on tick 181. Stats: 547/1400. I guess the 1 tick in a tile effect has somethign to do with the down ramp as it happend the same on the way north and south.
• next advance on tick 191. Stats: 547/1400.
• next advance on tick 202. Stats: 547/1400.
• next advance on tick 212. Stats: 547/1400.
• next advance on tick 223. Stats: 548/1400. Endurance incremented to 1401 on tick 226.
• next advance on tick 234. Stats: 548/1401.
• next advance on tick 244. Stats: 548/1401.
• next advance on tick 255. Stats: 548/1401.
• next advance on tick 266. Stats: 548/1401.
• next advance on tick 276. Stats: 549/1402
• next advance on tick 287. Stats: 549/1402
• next advance on tick 298. Stats: 549/1402
• next advance on tick 308. Stats: 549/1402
• next advance on tick 319. Stats: 549/1402
• next advance on tick 330. Stats: 550/1403. Now on the exit ramp.
• next advance on tick 336. Out of water. Still "drowning".
• On tick 337 she moved another tile and is now "winded".
• On tick 339 she was back on the track stop at the start of the track.

Final attributes were 550/1403 for a gain of 7 in both in 337 ticks with an un-optomized course. That would be 33600/337*7=698 (rounded) points per month for each if made a continuous loop rather than a single pass.

I have run out of space on my v2 test track, but with these results, if it turns out that flimzy and easily tired dwarves can survive a 44 tile drowning track I will be just building that folding back on itself 10 times for hopefully 70 points per ride (that is what fits on this map with all the other crud nearby, increasing it to a 700 point ride would require getting really creative).

Once I have a full sized track I will try to upload a quickfort blueprint for it. Will probably still need some cleanup because of the other stuff in the way on my map though. Also, if it turns out 44 is too long, I will post that here as soon as I know.

[DwarfStar]

BTW I'm watching this thread intently. I want to set one of these up myself!

[Trabber Shir]

This fort died FPS lag death. I still am unsure what the cause was, but continuing the project with fairly consistent 4 Frames per Second was too painful and slow. Will get a new fort set up to continue the testing and hopefully have more results by the end of the month.

[anewaname]

It seems important to determine if the FPS problems were caused by the minecart-system itself. Would you consider putting the FPS-dead fort up on dffd, with info about 3rd party stuff?

[Trabber Shir]

Sorry, just saw this. Out of embarrassment I will not be uploading the fort that died to FPS lag. I can be fairly confident that the FPS issue is not related to the minecart testing for 2 reasons:

• I have a new fort with a much more complex test rig that is still running comfortably at 100FPS.
• The old fort was already down to 70 FPS before I started on the minecart idea. The Gulag operation which brought my 20 dwarves of interest up to legendary+5 mining was definitely the cause of the initial lag. So, when I said "I have no idea" that was an oversimplification; there are about 30 different things going on in that fort which may have been the culprit in whole or in part and I am not sure which ones were getting worse as time went on, atom smashing a few thousand stone seemed to make things worse for example, as did mass slaughtering a bunch of animals. I wrote that apparent correlation up to confirmation bias or some other psychological explanation and decided the situation was far too complicated to continue debugging. Oh, and this was not the only water feature in the fort, that other water feature is another possible culprit, it relied on having done a diag5 exploration mining operation in a light aquifer layer, exposing every wall possible.

Results form the new test rig should be up later today. Quickfort blueprints for the test rigs should also be forthcoming if not today, then tomorrow.