v0.34 Talk:Minecart

References

Check this list before removing any content. --Dree12 (talk) 00:38, 17 May 2012 (UTC)

adventurer can take ride in minecart [1]
animals ignore traffic designations [2]
dwarf drops baby when boarding cart [3]
floors remove engraved tracks [4]
fluids are heavy and can kill momentum [5]
guided minecarts ignore rollers [6]
items falling out can hurt dwarves [7]
magma-filled cart doesn't harm rider [8]
minecarts can be stolen [9]
minecarts moving fast enough can skip over water [10]
minecarts have huge capacities [11][12]
rollers don't work if frozen [13]
rollers use two power per tile at highest speed [14]
skipping does not depend on weight [15]
Minecart derailment speed, Track Stop friction [16]

Cave-Ins

Carved tracks on a section that caves in will appear on the ground where they land (destroying ramps they land on). Feature or bug?--Nimblewright 12:34, 4 December 2012 (UTC)

Minecart Tricks

Has anyone considered compiling a list of unusual things you can do with minecarts, like dwarven rollercoasters or traps?

Sure. Here are a few examples:

The Stupid Dwarf Trick using a perfectly agile soldier to create metal could be done using a cart moving back and forth on rollers.

A clock generator using a pressure plate and a minecart can be made with on-ticks at easily adjusted intervals. Simply put a roller at either end, or, even more simply, make a loop track with a pressure plate in the middle and adjacent rollers pushing outwards. While the rollers are powered, the minecart will continue to roll back and forth on the tracks and trigger the pressure plate again and again.

Dwarves can be flung across impassable chasms using carts; this is similar to the H.E.L.P.

Squad cars: Have a powered system to move your military quickly to the front entrance of your fortress. Give all your military hauling jobs, and have a series of carts hidden behind a bridge; the lever closes them in and opens the cars, then the squad moves at extremely high speeds to wherever the track takes them. This is horribly impractical, but very dwarvenly. Note that full speed rollers move carts about a tile every two ticks, which is much faster than most dwarves. It's an insane amount of work to get it to work, but it might be worth it? The Real Marauder 01:23, 22 May 2012 (UTC)

I support the Squad cars idea; we may not be able to mount actual beasts into battle, but now we have the next best thing (I have a delirious/delicious image on my mind right now I wish you could see). Also, how about carving tracks running straight from one end of your entrance corridor to the other, with a lava moat on the innermost part so you could fling magma-filled minecarts to run down invaders? It could use a bridge-based minecart gate as suggested by The Real Marauder above. (This assumes carts drop contents on collision, as suggested by Toady's 05/10/2012 entry.) --Seikatsukan 22:52, 6 June 2012 (UTC)

How about minecart "landing pods" that actually launch the soldiers out of the fort into the middle of the battlefield, splattering enemies while delivering the soldiers straight to the fun? Could this be done safely? -Billw

Launching soldiers into battle is problematic, a straight forward shot would require a perfectly flat arrival zone and ballistic launches seem to be truly safe only if the cart is caught and stopped at the apex of its flight curve. It does make for a spectacular rollercoaster-type construction - about 70 tiles forward distance and over 20 z-levels ascent in free flight are possible, with perfect safety barring freak accidents.

Bridges versus Hatches

It's been noted that retracting bridges can be used as track direction switching points, as well as the fact that bridges will fling minecarts if they happen to be in the way while the bridge is switching. Would hatch covers also work for this? If they do, they would have the advantages of being instantaneous (rather than a 100 tick delay) and non-disruptive to minecarts (since they don't flingify stuff). --Quietust 03:59, 17 June 2012 (UTC)

Hatches have close to the same friction as ground thus making a poor substitute for track.

Hatches don't seem to have an own 'direction' that would overwrite underlying tracks (which is what allows bridges to operate as switches). At least in my test, a cart followed a hatch-covered track corner faithfully instead of continuing in a straight line. You can use hatches over downward ramps to switch a track between two z-levels, however, and for that purpose, hatches are probably superior to (1x1 retreating) bridges because of their immediate response. PS: hatches over downward ramps are of limited usefulness if the hatch can open while the cart is passing over it. It seems that a hatch opening under a cart forces the minecart to 'fall', nullifying its forward velocity. It will then roll off the ramp at much too little speed to climb back up a ramp. A cart propelled by a highest-speed roller can ascend a ramp and will 'bounce back' if the ramp exit is blocked by a closed hatch. This appears to be somewhat more useful for switching tracks with hatches. There are other options of using hatch covers as cart switches, but those are hard to pull off without abusing the bugs concerning ramps.

Capacity

We could probably improve by listing a few (verified) capacities of minecarts for common items. Are we sure about the volume numbers shown on DF2012:Weight , as it looks like you should have 83 blocks per minecart rather than 100. -- UristDaVinci 05:08, 26 June 2012 (UTC)

Physics

The physics section could use an overhaul/rewrite, with some numbers for track friction, track stop friction etc., since the first such are now available. Well, some have been available for almost a month, some are more recent. I can do at least some of it myself, but off to sleep for today. -- Snaake 23:32, 7 June 2012 (UTC)

I added a section on controlling speed and am using the m/s units to mean tiles/step as I couldn't see any already in use standard for speed. This is the units used in the second post you link, I think it is pretty good. --Billw 12:39, 13 August 2012 (UTC)

Weight

Seems like it doesn't affect their speed nor it does affect their slowdown. An empty feather tree minecart (lightest) seems to have the same speed as a platinum one filled with platinum nuggets (heaviest) when pushed/launched from roller. Also, they both are unable to scale more than one z-level when launched by a single-tile top-speed roller.--HYBRID BEING 07:52, 25 February 2013 (UTC)

I wouldn't be surprised if rollers aren't affected by weight. They are a relatively new feature (see ^Bug:5911 for an example). According to the article, minecarts do accelerate and decelerate based on weight, but not when guided by dwarves. They also aren't affected by weight when Skipping. Feel free to add a note of this to the article if you like (for example, under this section). --Lethosor (talk) 22:23, 25 February 2013 (UTC)

I didn't test driving them but as i said they moved at the same speed (i failed to notice the expected from such different minecarts difference in speed, at the very least) when pushed, no rollers involved. --HYBRID BEING 10:14, 26 February 2013 (UTC)

Actually, this is an interesting result of (real-world) physics. Gravitational potential energy is mass * gravity * height, while kinetic energy is 1/2 * mass * velocity². When you set these two formulas equal the mass terms cancel out. That means that two objects that start at the same height (and velocity) will have the same final velocity after rolling down the same hill (ignoring all other forces like wind resistance). I don't know how detailed the game's modeling of this is, but your result is mostly expected (though it does imply that rollers apply a "constant velocity" to minecarts). To find out if mass is being modeled correctly you can transfer the energy to something else. For instance, if you place a dog on the tracks at the bottom of the hill, the loaded platinum minecart should hit the dog and continue on at roughly the same speed. The featherwood minecart may hit the dog and stop completely, having insufficient energy left to continue moving. Or they may both do the same thing, strongly implying that mass is not being modeled. --Loci 20:27, 26 February 2013 (UTC)

Ah, thanks for the refresher course. The thing is i didn't use a slope for pushing test. Then again that doesn't really matter since deceleration is not dependent on mass. Friction, as the only force affecting the minecart (since normal force and weight cancel each out on horizontal surface), is mass * deceleration and equals to friction coefficient * normal force (mass * gravity) (F_F = a*m = µ_k*N = µ_k*m*g => a = µ_k*g)

So rather than affecting their speed/deceleration it should affect initial velocity. --HYBRID BEING 09:37, 27 February 2013 (UTC)

I filed this as a ^Bug:6296. I'll add this bug to the article later if no problem would arise. --HYBRID BEING 05:45, 28 February 2013 (UTC)

Magma-Safe

It turns out that nether cap minecarts are not magma-safe and can not be used for hauling magma.

Magma Transport

When trying to fill a mine cart with magma, apparently it is possible that the minecart can go under Magma fast enough where no magma will settle inside the cart. --James H (talk) 04:43, 18 April 2013 (UTC)

Are you sure that minecart does not just skim over the magma? I've seen similar symptoms: fast (well, relatively. after going one or two ramps down IIRC) minecart, no magma at the end of the route. But looking at it in step mode I saw that minecart never drops in magma to begin with. Best way is to just drop minecarts in magma from above, I suppose. --Elfy (talk) 12:29, 15 June 2013 (UTC)

Mess

This article is a mess, how can it be Masterwork? It even has redlinks. Sure, there is quite an amount of content and the examples are well done, but the arrangement doesn't make it easy for new players. It certainly isn't "aesthetically pleasing." The lede is random content dumped there:

"Since their introduction in version 0.34.08, a new hauling labor preference was added to all dwarves, called "Push/Haul Vehicles", turned on by default." does not belong in the lede either. Instead there should be a section ==Using Minecarts== that covers just such basics.

"If a minecart is moving fast enough, or if it has a rider, thieves will be unable to steal the minecarts." certainly doesn't belong in the lede.

"The invention of minecarts revolutionized the Science of Dwarfputing by enabling smaller, faster logic systems to be built." and then not a word follows in the article unless I overlooked it.

The section on tracks opens quite abruptly. The very least would be a sentence like "to do anything useful with minecarts you need to create tracks"

I would also argue against "Covers an important "must-read" topic".

Physics covers some really obscure details that might fit better with quirks. In any case both sections need a merge and/or reorganizing.

Capacity should be near the top as it is essential info for the player who asks: is it economically worth it? and certainly is basic info.

An article using an elven word like "boulders" should be auto-disqualified. I fixed this.

The Capacity section was worded poorly. I tried to improve it.

--Old Ancient (talk) 18:37, 13 April 2013 (UTC)

I have done some major rework and restructuring. Hopefully it's much better now. Sorno (talk) 21:58, 27 June 2013 (UTC)

Thanks. I somehow missed this post, but I like your improvements. :) --Lethosor (talk) 01:53, 28 June 2013 (UTC)

Much better now thanks you for your work. I did some extensive minecart testing and added some additional info to the numbers behind the scene. Feel free to reword my paragraph, as english is not my native language, but the info I added is accurate, so don't change it. fricy -(20 July, '13)

Rollers, power transmission

If you think the statement 'rollers transfer power in the four compass directions on the same z-level' is incorrect, could you provide an example? Because i've observed the statement to be true. For example: (image links) http://imgur.com/Qp5PR6Q this array, with a roller (on rough floor, no less) in the centre, shows these power requirements: http://imgur.com/qCH6eUV

four gear assemblies, four one-part axles, one roller. A sum of 26. They're all connected, through the roller. The observation also holds true with powered arrays: axles, gear assemblies and other rollers work when they directly touch an active roller on any of its sides.

Edit: tried this with an older roller, and that one _wouldn't_ transmit power in the 'wrong' direction. After i ripped it out and built it anew (N->S roller, offered power only through an horizontal axle from South, attached a gearbox north to show the effect; this had _not_ worked originally) the roller was active and transmitted power from the axle to the gearbox, visible 'rotation' and all.

I've no idea what's going on, it might be an effect of the location of the original power source, build order or maybe even saving/restoring causing a roller to delete these transmission options. After saving/restoring, the south-to-north transmitting roller still works and transmits power to the gear assembly. I'll amend the article for "it's weird", o.k.?

I do recall some issues with components from older versions of DF working inconsistently in v0.34.11, although I don't remember what they were. Was this "old" roller built in a different version (v0.34.08-10)? --Lethosor (talk) 16:51, 30 July 2013 (UTC)