Print

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

[Urist Da Vinci]

Sadly, I just verified that carts with absurdly large volumes still only draw at most 2/7 fluid from a tile, and this fills them to their max capacity, which leaves no more than 7/7 fluid when dumped. So modding can make fluid generators easier (take 2/7, dump 7/7) but not much else.

[TerryDactyl]

A 350% improvement to efficiency ain't nothing to sniffle at. Looks like there's some hard-coded numbers & behaviours in the mix.

[Martin]

Any ideas?

Here's what I'd start with, and experiment to get it tuned.


Have two paths to the stockpile. You're making a one-way pathway. You'll have a normal pathway that dwarves will normally go in and out of. Just before a cart reaches the stop, it hits a pressure plate which triggers a number of things:


1) It opens a hatch over a pit two tiles from the stockpile along the normal hallway. One tile from the stockpile put another pit with a retracting bridge that is also hooked to the same pressure plate. Anyone going to the stockpile in the next 100 ticks will be blocked and turned away by the open hatch. Anyone going to the stockpile in the 100 ticks after that, after the hatch has closed will hit the open bridge and be turned away. Anyone falling in eihter pit will have a stairway back up to the hallway on the safe side from the stockpile. This keeps anyone from approaching the stockpile for 200 ticks.
2) Anyone on the stockpile is now trapped. Put a door on the other side of the stockpile that leads to a hallway back to the other side of the pit that's at least 20 tiles long. This is a one-way door. The door is normally closed and so nobody will path down those 15 tiles until a cart is arriving. Anyone on the stockpile won't be able to path over the pit but will be able to path through the door. 100 ticks should be plenty of time for them to pick put their stuff and acquire the new path. Anyone pathing back up the one-way hallway won't have time to reach the door in the 100 ticks before it closes. So, this lets people out, but nobody in.
3) Replace the hatch under the quantum stockpile with a retracting bridge. It has a 100 tick delay, allowing anyone underneath time to pick up their stuff and walk out through the door. Nobody can arrive in the next 200 ticks, so you have a buffer of time for the cart to get from the pressure plate to the stop, to dump, to open the bridge, for the stuff to fall, and for everything to reset.


I also have a design for a latched trigger that might be useful in a setup like this, though how is escaping me:

Code: [Select]

>P=<
*-**


>< rollers pushing east/west
P pressure plate
= track
* gears
- axle


Use two carts on the track. When pushed to the west, one cart sits on the plate and holds it down. When the west gear assembly is activated, it pushes both carts east and off the plate. Depending on how you are resetting the cart after a dump, you could use the carts arrival to seal off the path to the stockpile and the carts departure to open it up.

[chewie]

I got a question about sending carts up z-levels:
If I use the spiral ramp design provided in this post for, let's say 30 z-levels, carve a track and install rollers pushing carts upwards on each level and power them, will I be able to give the cart a single push on the lowest level and as soon as it gets on the ramp spiral with the active rollers it travels up all levels by itself?

[khearn]

Dunno, when I made that design I just had the dwarves guide the carts all th way up. I haven't tried rollers at all.

I think it should work, though. If that won't work then rollers don't sound very useful. Give it a try and let us know.

[chewie]

Give it a try and let us know.

Actually, I will. I'll make a new world with a bajillion embark points (because you know, ropes ), start a new fortress and try to do this . But not now. Tomorrow or during the weekend.

[TerryDactyl]

I got a question about sending carts up z-levels:
If I use the spiral ramp design provided in this post for, let's say 30 z-levels, carve a track and install rollers pushing carts upwards on each level and power them, will I be able to give the cart a single push on the lowest level and as soon as it gets on the ramp spiral with the active rollers it travels up all levels by itself?

I pulled that just the other day.

A 3x3 spiral up from the first cavern to the surface, hauling silver nuggets. One roller required every THIRD z-level. Activated once full with a little push.

[chewie]

Ok, I did it, and it works indeed. I actually made a double helix ramp spiral, whereby the cart rides down 60 z-levels on one helix and automatically (I made a loop at the bottom) back up on the other one in a astonishing 10 seconds and less. Although Terrydactyl said there's only a roller required every 3 z-levels I put one on every level just for the sake of it.

Have a sketch

Code: [Select]

█████
██▼╦█
█▲G╦█
█╚▼██
█████

G=gear assembly
╦=roller facing south (there's of course an upward ramp under the southern roller)

Next upper/lower level is basically the same layout rotated 180 degrees.
I'll upload a movie to the DFMA and post instructions later if there's interest for that. Actually building that thing involves some weird steps, mainly because the power supply for it is actually in the middle of the helix (the G).

edit: The record on DFMA

[xmoffitt]

Friction !!Science!!

I have done considerable experimentation in an attempt determine the precise model and constants used by the game for minecart physics.  Here are my results so far.

Design of Experiment

I created a straight track where I could measure the run-out distance in a variety of track features.  The route stop was at distance "0", and a push was used to start the carts.  At times, I also plotted the per tile delays on several of the runs.  I then wrote a python program to model those tracks and compare them to the observed results.

Findings

Here are results from an entirely carved track.

Spoiler (click to show/hide)

The X axis is the distance and the Y axis is the inverse of the delay in ticks.

It is interesting to note that the delays both increase and decrease as they are trending downward.  This points out the exciting fact that both position and speed are tracked by the engine with more precision than integer tiles!  However, if you change the X axis to time, you get an even better result.

Spoiler (click to show/hide)

The most exciting fact from this chart is speed is decreasing linearly with time.   This implies a constant acceleration (slowdown) due to friction.   One anomaly from the dataset is the ticks of delay at tile 1 (trimmed from the previous charts).  It took 2 ticks of delay to leave tile 1, but subsequent delays jumped up to 5 ticks.    The only explanation that made sense was the cart was placed at distance 0.5 by the initial push impulse.

Next, I tinkered with my model until I could precisely reproduce the observed results.  Here it is (simple model):

• Position and Velocity are stored internally as a real numbers (floating point)
  
• Push - positions a cart at distance of 0.5 from the stop and imbues it with an initial velocity of 200.0 milli tiles / tick. 
• Each tick:
  
  • Position (truncated to an integer) is used to lookup the tile properties (e.g. friction)
  • Friction is applied and the speed is updated
  • Position is updated based upon the current velocity
• The friction values for various track features are as follows (measured in milli tiles/tick^2)):
  
  • Regular Track (carved) = 0.1
  • Trackstop Lowest = 0.1
  • Trackstop Low = 0.5
  • Trackstop Medium = 5
  • Floor (smooth or rough) = 2
  • Turning Tracks = 1.77
• Friction only decreases the magnitude of speed, so the new speed is at least at zero.

Observations

• The effectiveness of a Track stop is subject to the integer rounding effects of the cart as it passes through the tiles.  This can lead to some counter-intuitive results!  Moreso, the actual speed or stopping distance of a cart cannot be determined without knowing the entire track.
• The initial placement of the cart at 0.5 means that track stops places directly next to the start will be about half as effective as ones placed one tile further.
• High and Highest track stops are sufficient to stop any push from a Dward on level ground.  Therefore, there testing will require adding accelerating features like ramps or rollers (see Future Work)
• It is arbitrary whether the engine use round() or floor() in looking up tile features.  I chose floor() because it made the explanations more intuitive for me.

Future Work

The best overall outcome would be to take this data and make a web-app that allows you to input the track and lets you know how it will work.  Fort designers could use it to engineer their forts for safety and fun.   Who knows if I'll ever get the time for that.

I do have partial results for the values of rollers and ramps.  Here is a small preview: rollers accelerate very quickly up to a maximum speed depending on roller strength.   Lowest is 131 milli tiles / tick and Low is 200 milli tiles / tick (the same as a push).  Unpowered rollers are the same friction as carved track.  Rollers moving "against the grain", even at Low are powerful enough to reverse the direction of the cart.

[Martin]

Push - positions a cart at distance of 0.5 from the stop and imbues it with an initial velocity of 200.0 tiles / kilo ticks. 

Very nice work. Thank you for taking the time.


This 0.5 distance also explains why pushing a cart with a 1 tile pit immediately next to the stop results in the cart falling into the pit, but putting the pit just one tile further away allows the cart to fly over the pit.

[Rafal99]

Awesome findings!
They should be added to the wiki!

I do have partial results for the values of rollers and ramps.  Here is a small preview: rollers accelerate very quickly up to a maximum speed depending on roller strength. Lowest is 131 tiles / kilotick and Low is 200 tiles / kilotick (the same as a push).

From my testing maximum speed the cart can get from Highest-speed rollers is 2 [ticks / tile] which is 500 [tiles / kilotick] in your units.
It seems that the cart can get such speed while passing as few as ONE tile of Highest-speed rollers. Further rollers don't accelerate it more.

[khearn]

It is interesting to note that the delays both increase and decrease as they are trending downward.  This points out the exciting fact that both position and speed are tracked by the engine with more precision than integer tiles!  However, if you change the X axis to time, you get an even better result.

This agrees with what I've been finding in my falling tests. When falling, a dwarf seems to start 0.7 tiles above the bottom of a z-level, and accelerates downward from there. I've come up with a value for g of about 0.03207 z-levels/tick².

Are you sure about your units? tiles²/kilotick doesn't sound right for an acceleration. I'd expect your deceleration units to be tiles/kilotick², or maybe tiles/(kilotick*tick) which is a little more awkard to write, but easier to calculate. Your unit of speed is tiles/kilotick, and the speed changes over time, so acceleration or deceleration should be '(distance/time) / time' or 'distance/(time * time)'  (both are the same thing, just different ways of writing it).

[xmoffitt]

Are you sure about your units? tiles²/kilotick doesn't sound right for an acceleration. I'd expect your deceleration units to be tiles/kilotick², or maybe tiles/(kilotick*tick) which is a little more awkard to write, but easier to calculate. Your unit of speed is tiles/kilotick, and the speed changes over time, so acceleration or deceleration should be '(distance/time) / time' or 'distance/(time * time)'  (both are the same thing, just different ways of writing it).

Thank you for catching that error.  I edited my post to have the correct units of tiles/(kilotick*tick).  The reason I chose such an awkward  units is because the values generally came out to such nice integers.   This, to me, was a strong indicator that they were in fact numbers that Toady may have typed into his source code.

[blue sam3]

Are you sure about your units? tiles²/kilotick doesn't sound right for an acceleration. I'd expect your deceleration units to be tiles/kilotick², or maybe tiles/(kilotick*tick) which is a little more awkard to write, but easier to calculate. Your unit of speed is tiles/kilotick, and the speed changes over time, so acceleration or deceleration should be '(distance/time) / time' or 'distance/(time * time)'  (both are the same thing, just different ways of writing it).

Thank you for catching that error.  I edited my post to have the correct units of tiles/(kilotick*tick).  The reason I chose such an awkward  units is because the values generally came out to such nice integers.   This, to me, was a strong indicator that they were in fact numbers that Toady may have typed into his source code.

The units are a lot less awkward if you right them as millitiles/tick²

[Xen0n]

--snip--
This could be used to make an above-ground structure (such as a floating fortress) have the ability to shoot magma from refilling storage tanks without having to build a pump stack. The "original" magma can be brought up by minecart.

Honestly, even without the quantum fluid replication effect, the liquid carrying capacity of minecarts has probably been the most exciting prospect for me (still using 34.07).  Even with the reduced number/height of caverns I use, magma is deep, and making magma pistons has been too time consuming to pull off successfully in any of my forts, and I've never even attempted a pump stack (or anything else requiring 'power'), since as I understand it all the methods used to generate the 'power' in the first place take a huge toll on your FPS, which I can't afford. 

Pulling 2/7 of magma one cart at a time up from the magma sea may not be terribly fast, but it seems like something I could set up very quickly and simply, and just let them slowly fill up a surface reservoir over the course of a few months.