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]

If useful should it not be on the page? If it is already the references should be inline on the page. If not useful no reason to list it? - AnnanFay (talk) 22:22, 3 August 2013 (UTC)

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?– unsigned comment by 50.104.53.154

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.– unsigned comment by 91.66.179.15

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.– unsigned comment by 24.35.132.170

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.– unsigned comment by 91.66.176.151 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.– unsigned comment by 91.65.219.68 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.– unsigned comment by 91.66.177.201

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.– unsigned comment by 89.210.64.176

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.?– unsigned comment by 24.134.31.29

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)

It was a current-version fort, but i ran into varying roller connectivity again and now think it's a matter of 'build order': when a roller is constructed, it seems to check neighbouring squares for available power sources, and if only 'perpendicular' sources are available, it will only accept and transmit power in that direction. If there are (also) 'parrallel' power sources available, it will transmit power in all four directions. Building or demolishing constructions offering or demanding power after the roller has been finished appears to have no effect.– unsigned comment by 24.134.31.29

It looks like you are right, something is going on, good catch. Here's my theory after a short testing: 1 tile rollers behave just like gear assemblies, they are directionless and can connect to anything in their neighboring tiles, even to the "invalid" edge of other rollers. I was able to reproduce this quirk consistently with 1 tile rollers acting as a power connection, but not with anything longer. Can you confirm this? --Fricy (talk) 09:51, 31 July 2013 (UTC)

Now that you mention it, yes, the one-tile rollers seem to be reliable in that respect. Well-spotted, that's half of the issue adressed actually. What's quite confusing to me is that i've built several longer rollers that transmit in both directions, but haven't yet nailed down the cause of that behaviour. Something to look into when i next end up playing with rollers. EDIT: yes, it appears to be a build order/build constellation issue. I've built an eight-length and a ten-length roller, both of which transfer power through their 'parallel' ends. The trick was building the 'connected' machinery - axles and gearboxes - _before_ building the roller. Long chains of lenghtwise-connected rollers would presumably not work, because each would require the other to be built first to give/take power. They could probably be connected through 1x1 rollers, though. It'd be grand if someone else could try this out and see if my observations can be confirmed/debunked/refined.– unsigned comment by 91.64.63.223

Update: 1x1 rollers, as pointed out above, reliably transmit power in all four cardinal directions.

Longer rollers always transmit power along their sides. They will also transmit power through their front and back ends to power-accepting buildings (gearboxes, pumps, horizontal axles...) which were built/made connective before the roller was constructed. They will not transmit to such buildings which were constructed after the roller, and they lose connectivity with gear assemblies when the assembly gets disengaged. It seems pretty clear that there's some bug here, either the possibility of transmission in parallel is unintended, or (less likely) the transmission loss or failure to transmit is a bug.--Larix (talk) 21:27, 26 October 2013 (UTC)

Collision damage?

What effects the damage caused by minecart-creature collisions? Weight, speed, quality, angle, etc? - AnnanFay (talk) 22:30, 3 August 2013 (UTC)

Weight (including cargo) definitely. Speed almost certainly. For the rest, i don't know. --Larix (talk) 00:37, 10 October 2013 (UTC)

Dumping clothes on minecart tracks

Dwarfs always dump their old clothes the moment they start "pickup equipment". This applies to _all_ cases where they just finished a job. Dwarfs can dump their clothes on minecart tracks after ending a ride, after pushing a cart, after building a track ramp, after engraving a track tile etc. I keep having this very problem all the time, and it's never connected to _riding_ minecarts. And i find the hatch cover suggestion extremely vague, rather like you have some very specific construction/layout in mind that's not at all explained by this single sentence. --Larix (talk) 19:01, 4 April 2014 (UTC)

Sure. But in most cases that is only a mild inconvenience; when combined with minecarts it becomes deadly. (I see a significant similarity to the baby-dropping bug--minecart rides are not the only time a dwarf loses their baby, but it's certainly one of the most problematic.) Counter to your experience, I have *only* had problems with clothing and ridden minecarts--but that's because I set up an automated swimming track. Incidentally, you can find an example of my hatch-cover workaround at that link too. But, ultimately, this wiki is intended as a guide for players; which article do you think a player is going to consult after receiving a report of an inexplicable minecart collision, minecart or clothing?--Loci (talk) 19:34, 4 April 2014 (UTC)

I'm not at all against referencing the problem here, i just find that mentioning _only_ riding of minecarts is wrongly specific; dwarfs dumping their clothes on minecart tracks and later diving under the wheels to save their socks is a general dwarfs+carts problem. Many people have the same type of problem but may find that the description doesn't apply to them because they (including myself) almost never set routes to ride.

I suggest phrasing it more generally - dwarfs have a habit of dropping old clothes on minecart tracks after performing minecart-related jobs. --Larix (talk) 20:33, 4 April 2014 (UTC)

Is that not how it is now? I left your generalized warning, but added back a specific warning and workaround for ridden minecarts. I don't consider a generic warning sufficient because, except for ridden minecarts, all the other cases can be worked around quite easily. You can manually check the tracks for any discarded clothing after construction, and know that no new clothing will be added without further construction. By separating your departure and arrival track stops, there is little risk when discarded clothing accumulates on a push stop. Guided stops may accumulate clothing, but guided carts aren't dangerous. Only when riding in minecarts do dwarves *always* drop their clothing on a tile that minecarts are guaranteed to travel to.--Loci (talk) 20:52, 4 April 2014 (UTC)

It still came off to me as saying that lack of traffic safety concerns is a problem because minecart riders drop clothes on track. It may not have been your intent, but the wording suggested it to me. I have had and keep having problems with my dwarfs calmly walking into speeding carts to clean, go on break or haul stone; never because of dropped clothes after riding.

I can see that an "always ride instantly" short track will be particularly plagued with dropped clothes, but that manifestation of the problem (and the solution) is very specific to this type of application, while the general problem occurs and is a headache in all uses of free-running carts. I edited the phrasing (including a link to your swimming track); i hope you're okay with that.--Larix (talk) 14:42, 9 April 2014 (UTC)