Editing 40d Talk:Ramp

====Downward Ramp====
I am in my digging designation menu and I don't see an option to dig a ramp down? If I want to do that do I need to use stairs to get down, then construct ramps up? Then replace the stairs with ramps? --[[User:Ehertlein|Ehertlein]] 12:21, 29 August 2008 (EDT)

:One thing you can do is to dig one tile further than the ramp shall be, and dig a channel there.
:Then, your miners are able to dig from there an upward ramp on the level below:
:(side view)
<pre>
XXXXXXXXXXXXXXXXXXXXXXXXX                  
               cXXXXXXXXX Level Z              c (c)hannel here at first
XXXXXXXXXXXXXX>______XXXX Level Z-1            >  then place an upward ramp here
</pre>
:If anyone is able to explain this better, fell free to edit.--[[User:Doub|Doub]]
::I am going to load up a different game and try this out. :) I don't have anything built at Z-1 yet so I hope I can dig the ramp from higher up.
::Ok so this was simpler then I thought I simply changed the Z level one lower and designated ups. No channels, no stairs, just go one lower and designate the up. --[[User:Ehertlein|Ehertlein]] 13:57, 29 August 2008 (EDT)
:::Forget that complicated process - to dig a downward ramp, simply move the screen down one z-level and designate an upward ramp. --[[User:Juckto|Juckto]] 20:56, 3 September 2008 (EDT)
::::Indeed, you are right. How simple! Thx. --[[User:Doub|Doub]] 10:44, 4 September 2008 (EDT)
::  Quirk: if you designate a downward stairway, then a ramp instead of an upward stairway on the level below, the finished product will be a ramp. A bit of strangeness, I saw it on the forums, tried it myself, it worked and a stuck miner rescued himself, leaving only a ramp behind. Version 40d. --[[User:Jellyfishgreen|Jellyfishgreen]] 18:39, 9 January 2009 (EST)

== Current Oddities caused by ramp? ==

I'm gonna upload a new map on DFMA, Tongsgate. The savefile will be available. I'm having an oddity with a sealed artificial lake with a ramp in it (for transportation. It has a current just like a river. <small>&ndash; [[template:unsigned|unsigned]] comment by [[User:Erathoniel|Erathoniel]]</small>

:Speaking of ramp oddities, mine saved my dwarves life. I had a proficient swimmer dwarf fall into a river building a channel, and he just sat there being pushed with the current. With a little clever manipulation, I shoved him into 1/7 water quickly and had him build a ramp to the surface. He lived. Woo! <small>&ndash; [[template:unsigned|unsigned]] comment by [[User:Milskidasith|Milskidasith]]</small>

Currently, I have on one level ramps leading down, and the level underneath it is open space. Is there any way to fix this? It may have been caused by me clearing a lot of ground by using a controlled cave-in.--[[User:Sphexx|Sphexx]] 09:57, 22 March 2009 (UTC)

:Construction of upward ramps underneath the already present downward ramps should make them usable again, if that is what you want. --[[User:Elvang|Elvang]] 14:40, 22 March 2009 (UTC)

::I currently want to remove them. Right now they are submerged in magma, and cave-ins are not working. I might end up cooling it and just re-mine all of it, but if there is an easier way, I'd like to know. --[[User:Sphexx|Sphexx]] 20:17, 22 March 2009 (UTC)

== People don't use ramps? ==

I've put my trade depot a floor aboveground, with ramps then a bridge leading to it.  Wagons get there fine, but people never take the ramps -- they always get there through the auxilliary tunnels.  In fact if I bar the gates traders just sit in place, unable to find a path.  --[[User:Corona688|Corona688]] 16:16, 11 November 2008 (EST)

:Do you have traffic designations making the people want to go through the tunnels? Are the tunnels simply more direct routes to the depot? --[[User:Savok|Savok]] 00:32, 25 November 2008 (EST)

On a related note, I've never seen nor can I get goblins to use ramps. The entrance to my fort is usually a long hallway with ramps at the end and a second long hallway a z-level down with a depot at the end. To save time when hauling stuff from the surface there's a stairway with a door I can lock during sieges. Siege comes, I lock the door(only door to be locked during siege), and the goblins will move halfway down the first hallway and then just sit there, never approaching the ramps even if I station a dwarf on them. --[[User:Elvang|Elvang]] 22:30, 12 March 2009 (UTC)

== Picture is wrong ==
Just a bit: the upper ramp is valid, since it has supporting wall (diagonal one (even two of them)). Need to repaint it as floor also. --[[User:Dorten|Dorten]] 23:06, 24 November 2008 (EST)

== Wagon torque / horsepower? ==

Is there any limit to how many adjacent ramp squares a wagon can traverse?  Aesthetically, I had always placed 3 or more tiles of flat space between two ramps, on the assumption that the wagon needed to "level out" before negotiating another hill... but I've seen them do some crazy off-roading on their way to my fortress.  Can I have an underground depot at Z-6 that is served by a single continuous down-ramp?  --[[User:Jurph|Jurph]] 16:54, 4 December 2008 (EST)

:Yep.--[[User:Maximus|Maximus]] 17:33, 4 December 2008 (EST)
:...or a floodable pit through which everything coming in must pass, if you're not a bridge person. [[User:Sharp|Sharp]] 09:18, 26 January 2009 (EST)

== Downward only ramp ==

The following text has been removed for innacuracy: Dwarfs on the upper floor will be able to descend to the lower, by walking onto the ramp and then off of the ramp, but dwarfs from the lower floor will not be able to go up.
see [http://mkv25.net/dfma/movie-1649-ramptest ramp test video] --[[User:Kaypy|Kaypy]] 15:15, 2 September 2009 (UTC)

== Short Version ==

I wanted to add a simply summary because most of the examples and illustrations don't do anything for me, and I fear they may make it look more complicated than it really is. I originally posted this:
# The ramp must have a wall next to it.
# The space above the ramp must be open.
# The space above one of the walls next to the ramp must be open.
Someone added the following to it:
: The space above one of the walls next to ''and forward of'' the ramp must be open.
I took it back out because I have no idea what it was supposed to mean. If there's really some significant aspect I'm overlooking, it needs to be explained better, preferably as a separate rule. If not, can we please keep the "short version" as simple as possible?<small>&ndash; [[template:unsigned|unsigned]] comment by [[User:ManaUser]]</small>
+	
::Agreed that the examples and illustrations aren't clear. The "short version" should be the "main version". [[User:Cheepicus|Cheepicus]] 20:37, 10 October 2009 (UTC)

::In a word, "No".  Because, unfortunately, ramps are not simple.  That was my edit you deleted, and what it meant was that if the "space above the wall next to the ramp is open", the ramp may still (sometimes) fail - if that space is ''next to'' the ramp, and not in the direction of travel when going up the ramp.   A wall to the side is not adequate - therefore (unfortunately), "as simple as possible" cannot be as simple as your edit and still be accurate.  But your goal is shared - will try again.--[[User:Albedo|Albedo]] 20:31, 13 October 2009 (UTC)
::Just to clarify Albedo, are you saying that a creature may only move up a ramp by crossing it in a straight line? That's what I'm understanding when you say there must be a space above a wall "in the direction of travel." [[User:Njero|Njero]] 18:15, 14 October 2009 (UTC)
:::''Basically'', yes.  But that's not true for descending (where dwarfs can "jump down" from the side).  What's worse, is ramps are buggy, and so sometimes a "broken" ramp will work for a while (sometimes a long while!) before realizing it's not legal. Sometimes 45 degree jumps at the top are accepted for upwards travel. Sometimes a ramp supported only by another ramp (or, rarely, by nothing) hangs around. (And then there is the "one-way ramp" exploit.)  What's more, pathing seems to sometimes depend on more than the several tiles adjacent to the ramp - it ''looks'' valid, but no one uses it.  They are not a joy to use and ''still'' not perfectly understood, which is why we're (understandably) having a hard time nailing down the "simple explanation" that everyone can accept.--[[User:Albedo|Albedo]] 19:29, 14 October 2009 (UTC)
 Not all ramps need support, want to keep talk of support out of the usable part.
Ugh. Cheepicus - We're edging toward an edit war - not intentionally, I believe, but we each have different views on ramps. I undid your last until we can resolve this - some of it may go back in, but we need to find middle ground here first.  <br />
I believe that it needs to be said that ramps ''do'' need "support" - and that wall defines the direction of movement. Ramps without a supporting wall ''sometimes'' work, but are not guaranteed to work (afaik).  I also believe that the "wall = support = direction of travel" is a solid model for understanding and envisioning ramps - at least at a basic level.  <br />
Ramps are buggy, or can be, depending.  We need to find the "100% guaranteed this will work" model before talking about "Not all ramps need support". --[[User:Albedo|Albedo]] 19:37, 14 October 2009 (UTC)

:Albedo, you have done some editing of what other people have said on this talk page, including creating a misattribution (the original comment in this section is not by me), and you even deleted an entire section that I wrote! [[User:Cheepicus|Cheepicus]] 19:49, 14 October 2009 (UTC)
::I don't believe I edited ''what'' was said - but it appears I am guilty of the two you specify. Both were unintentional, and I never saw your edit - thought his was yours, not sure how it happened, maybe I cross-edited somehow - you should have repaired them, but I have now, adding your missing subsection below. 
:::I was going to, but my wiki-tech fu is not so strong. [[User:Cheepicus|Cheepicus]] 20:16, 14 October 2009 (UTC)

::Also, you caught me in mid-edit; to continue....

You have a ramp:<br />
▲<br />
That ramp goes "up", but is, as yet, undefined as to where it goes up ''to''.  Maybe left, maybe right - undefined.  The moment you add a wall next to it, that defines where "up" leads to - right? <br />
▲■ - this ramp leads to the right, that's obvious.  Because of the supporting wall.<br />
Also, if you remove that wall, the ramp (often) collapses - no definition, no ramp. (A ramp in a corner has two supports, and can work either way - odd to think of, but that's DF.)  And that's my model.  Sometimes buggy ramps seem to work around that, but not always - but if you follow that model, you get a working ramp, leading where you want, 100% of the time.  <br />
I'm sure there's room for improvement on that - what would you suggest?--[[User:Albedo|Albedo]] 19:37, 14 October 2009 (UTC)

:Well, there's a whole section about ramp collapse. I think it's a good idea if we mention it closer to the top with the important stuff, since it's such a common ramp experience a ramp-carver should be aware of. But I don't think it needs to be mixed in with the basics of what makes a ramp usable. (After all, not all ramps need support, "adjacent wall" is a perfectly clear term whereas "support" conflicts with construction support and mechanism support..). Another reason I don't think it should be is this:

:Ramp travel is a bit mysterious if you're going just by observed DF behavior. But for me, after absorbing ManaUser's simple rules, my expectations are now in line with how they operate in game. So I want the "using ramps" section to stay very clear, with a laser focus, and be about one thing and not mix in other stuff. To me that means keeping the list short, and keeping the list very close to the top of the section.

:As for some specific issues, here are my experiences.
#The direction of travel immediately before the ramp move is irrelevant. It's true that a dwarf won't do 180 "double back" moves, but that's a natural result of the rules; to do so he'd have to be standing inside a space that's supposed to be a wall, at some point. (And I bet with ridiculous timing on wall construction and dwarf pathing decisions, you could get a dwarf to do a 180.) As a result I think it's a bit misleading to talk about ramps having 'directions' that they 'feed'. A ramp is like a teleporter between the ramp bottom space and the tops of whichever adjacent wall the dwarf wants.
#I've never seen a dwarf hop down a ramp "illegally" as part of a normal move (i.e. when they wouldn't have hopped down a channel). In the example illustration on the page, the dwarf WILL be trapped up there.
#I haven't seen ramps be okay for awhile then stop working or collapse for no reason. I ''have'' seen the one-way thing but that's a bit of an edge case, and might just as easily be called a bug with floor deconstruction. Other edge bug cases may deserve mention too, but they shouldn't cloud the presentation of the basic rules and don't necessarily call them into question.
#Likewise I've not yet seen a ramp that looked valid, but was not used, that did not on closer inspection turn out to be invalid.
#Never seen a standalone (unsupported) ramp work, but of course after trying to get them to work for awhile, now I don't build them anymore :)
:Obviously some in-game examples would go miles but ''so far'' ManaUser's rules have been absolutely correct in my experience and in the slew of little experiments I did to verify them before doing my first edit. Though I also wanted to clarify them some (I prefer to say a space is 'walkable' rather than 'open' because Open Space is a game term and is very much not what is meant.) Can't resist tinkering sometimes. [[User:Cheepicus|Cheepicus]] 21:26, 14 October 2009 (UTC)

== Untrue Things on this Page, In My Experience ==
# Ramps support other ramps as if they were all one big ramp. (?!)
# Digging a ramp under trees is dangerous.
# Dwarves can dig from the bottom of a ramp up to a space that doesn't have a wall under it.
I've verified these in 40d. I might just excise them and clean up the page a bit. [[User:Cheepicus|Cheepicus]] 20:37, 10 October 2009 (UTC)<br />
Also, possibly, 4. Natural/carved ramps are "slopes" implying constructed ramps are true "ramps". DF calls them all slopes when you use {{k|k}}. I feel the terms are interchangeable, but ''ramp'' is preferable because it's the word used in the in the menus when your dwarves actually make them by both digging '''and''' constructing. [[User:Cheepicus|Cheepicus]] 20:49, 10 October 2009 (UTC)
:Okay - reading this for the first time (again, apologies) - agreed with all.  Except... ramps supported by other ramps ''sometimes'' (''eventually''?) collapse. That, and if they have no walls adjacent to them... where do they lead? Are they pointless, or are you imagining some arcane configuration?--[[User:Albedo|Albedo]] 20:02, 14 October 2009 (UTC)

::I haven't seen ramps support other ramps (and here we're talking about ramp-style support and collapse, not normal construction support and collapse).  It is ''possible'' to carve out unsupported ramps. The way players are most likely to see is when you have a single standalone "pillar" wall that you carve as a ramp. This happens when designating a large area for ramp carving. You can also do it by constructing a wall next to a natural wall or ramp, carving out all other support for the ramp, then deconstructing a wall.
::And yes a ramp without an adjacent wall is, as far as I know, totally pointless. Well, you can channel out the space directly above them from them, but you can do that with stairs too. [[User:Cheepicus|Cheepicus]] 21:26, 14 October 2009 (UTC)
::: I've seen collapses from doing mass ramping as an alternative to channeling. I predominantly have this issue when working outdoors. My working theory right now is that this occurs from trees or rocks becoming unsupported and fall a z-level. We will not discuss how many dwarves were slain to bring you this information. [[User:Doctorzuber|Doctorzuber]] 18:31, 31 March 2010 (UTC)
:::: Ramps are just floor tiles with perks; if other ramps are beside them without walls they're not 'supporting' each other, they're just two ramps that happen to be side by side. @Doctorzuber, digging ramps under rocks and boulders is fine, but if you dig under trees or stockpiles, the floor tile the obstacle is on does not disappear, so the cave-ins are not occuring because of the object falling but because there is a floor tile that has its support ramped away. Mass ramping is not a very safe way to dig in general; you really have to watch out for trees. A better way to dig an outdoor 1z pit would be to dig up-stairs underneath and then channel the whole thing out; even unconnected up-stairs will support tiles above it, and your dwarves will dig everything away from below. You still have to remove the trees, but if you mess up, there's no cave-in to deal with. --[[User:Retro|Retro]] 18:42, 31 March 2010 (UTC)
::::: I'm sitting here testing as I edit, After a number of collapses, I canceled my dig ramp commands and stopped to clear every tree and boulder away from the targeted area. I then resumed digging ramps. so far no collapses this time. As soon as the dwarves get around to digging it I'm isolating a single boulder on a single ground tile, I intend to ramp it. I anticipate a collapse. [[User:Doctorzuber|Doctorzuber]] 18:49, 31 March 2010 (UTC)
:::::: I'd attribute it to human error. I've had it happen too sometimes, generally when I've been digging in a hurry. If a creature is on a wall designated for ramping, either the dwarf will accidentally ramp them out and the creature falls a simply z-level down or the dwarf will not choose that mining job even if there is no other job left until the creature moves. --[[User:Retro|Retro]] 19:15, 31 March 2010 (UTC)
: Strange. Okay, isolated a single boulder above a single tile. Ramped the tile, and no collapse. Yet ramping a large area that contains boulders and or trees frequently causes collapses. Unsure of the exact configuration that causes the collapse. [[User:Doctorzuber|Doctorzuber]] 20:43, 31 March 2010 (UTC)
: Repeating this test with a tree. Isolated a single tower cap downstairs, single tree, single tile of obsidian below it. ramping the obsidian out causes a collapse. so there it is, verified, a ramped out tree can cause a collapse. [[User:Doctorzuber|Doctorzuber]] 20:54, 31 March 2010 (UTC)
: Repeating this test again using an Ensign Nefeklikot Redshirt accompanied by Logem Cattenkon, Baby on a single tile above a single tile of obsidian. ramping away the obsidian dropped them down a level but caused no collapse. I think there is an occasional indoor collapse scenerio yet, but this apparently isn't it. [[User:Doctorzuber|Doctorzuber]] 21:27, 31 March 2010 (UTC)
::Doctorzuber, again, it is not the tree but the floor tile that causes a collapse. Additionally, that information is already known and included on the wiki. Additionally, rather than repeatedly editing your own comments on the spot it would be better to finish your experiments and post the information here afterwards, ''after'' the last comment rather than inserting it in, to keep chronology right. As it stands I remain convinced you will not find something new about a random indoor collapse condition that nobody has yet discovered in the 3D version; if a tile is unsupported, it will collapse, and ramps are very good at accidentally causing cave-ins this way. The conditions causing these cave-ins are always simple human error derived from either not being careful or not knowing a few ramp rules, nothing more. --[[User:Retro|Retro]] 22:17, 31 March 2010 (UTC)