Measuring Time and Distance in Death Stranding

From w.mfi
Jump to navigation Jump to search


Time Measurement

You don't need these to have a great time playing the game. But advanced players can use them to good advantage:

Game launcher time

Your Steam or Epic library for DS will show total time across ALL your games of DS, as well as any menu or AFK time, or even sitting at the Title screen. The Launcher doesn't hook into the game at a deep level... all it knows is that the software is running. Thus, this is a "big picture" number.

The Epic Launcher shows it down to the second (days, hours, minutes, seconds). To find it, go to your Epic Library, find DS, tap the three dots to lower right, and look for "You've Played". Sadly, you can't see it while playing; you have to shut down DS. (Grr.)

The Steam Launcher shows total hours good to one decimal (unless you get to 1k hours). So it's good to ± 6 minutes.

Total Play Time (TPT)

Found in your Bridge Links / Delivery Stats, in the middle of what you first see. This number only applies to your current playthough. It also includes all time spent in menus and/or AFK.

It's pretty useless for very fine testing, such as speed testing or timefall degradation. For the latter, I had to bring up the inventory and take a couple of minutes to write values for everything on or near me, for each two-minute time mark of a 20-minute time test. In other words it took 40 or 50 minutes to do a test of 20 minutes of game time. Total Play Time would be wildly inaccurate here relative to actual in-game time.

TPT gets loaded when you load a savegame (which is what DS does when it starts a session).

TPT doesn't record the total time lost, if you reload back to some previous point. Or for me, doing a lot of testing where I load particular savegames, play them a bunch, write down numbers, then ditch that play and load the same savegame to start more testing.

If you compare your total Launcher time to the sum of Total Play Time for all your DS games (TPT from latest point in each game), you can get an estimate of how much time you've lost to reloading.

For the record: When you look at TPT in Bridge Links, it's a static number. But only because it's a static output page; that clock is still ticking. Bounce around your menus and come back to Bridge Links TPT and you'll see. Remember, TPT includes time in menus.

Orders Screen showing game time and distance travelled for a particular order

Order Time a.k.a. Game Time

Order Time is the most useful measure of time for testing as it does not reflect time spent in Map/Info, knot terminals, cutscenes, or alternate story locations (Cliff's wars, the beach). It's also the time that matters for timed deliveries.

To measure Order Time, bring up the cufflink menu and go to Orders. At the bottom right you will see the time and distance for each Order since you first took it. These are very accurate numbers that reflect in-game time.

You can also take it to the next level if you want (see total time spent in game world, below).

How it works

Accept an order and place the contents in a private locker, Safe House, or Postbox. So long as you never deliver the cargo or cancel the order, you will have a running tally of Order Time from that point forward.

You don't have to be carrying the order physically; the packages themselves can be left anywhere. Every existing Order still tracks your time and movement, even if you're not carrying it. The game uses this tracking for timed deliveries and is undoubtedly part of the little display that shows your path when you make a delivery. Fortunately, all Orders show it, no matter what type.

If you want to time how long a particular event lasts, make a delta on a given Order's time: write the start and end time, and get the difference.

I used it for highly accurate times (down to the second) with timefall, boot duration, and speed testing. If you have the menu up a lot to check time or other things, game-world progress (and Order Time) freezes. It's great if you need to check values or copy info.

I also used Order info for speed testing: Here you have time down to the second, and distance down to the meter. Both in one nice place. Yes, you have to delta them both. But if you're doing this right, you'll already be entering lots of data into a spreadsheet anyway, shrug.

Using Order Time to get your total time spent in game world

If you spend a lot of time in menus and/or AFK and would like to know how much time has actually passed in the game world itself since you started, Order Time can help. Just take some order / any order that you will never deliver and stick it in a Locker early in the game. Or better yet, a Postbox or Safe House, so you don't accidentally deliver it (laugh). Level up the structure so it doesn't poof in the big storm toward end game.

If you're already in the middle of a game, it's not too late to start. At least you'll have it from then on.

If you really want the best estimate: Also check Total Play Time (TPT) right when you first take this special Order. Mentally think through how much of that TPT was actual in-game time, and how much was menus and cut-scene time. Write all this down, including your TPT. And from then on you can add the two to get your best estimate of total in-game time.

Obviously you want to do this as early as you can; as soon as you get your first Standard Orders. (All the Sam Orders have to be completed.) So you will already have gone to the incinerator near Capitol KC by then, etc.

It's not perfect. But still, it's an option for anybody interested.

I didn't realize its power until half-way through my second game. I latched onto my Order 183 (which was convenient at the moment) and have been using it ever since. I even stuck it in somebody's Safe House at Craftsman's. Thus "O183 GT" appears in many places in my spreadsheet of game testing. I don't care that it's got high hours on it; all my testing times are deltas anyway. Who cares about a couple more digits to collect, on tops of dozens of whole values for some tests.

If you ever want want to deliver your "timer Order", you can always get some other Order to replace it. Make a note of both their times, then deliver the first one. Much as with the initial TPT estimate, now you simply have another value to add to your new Order's time. As long as you keep track with some running notes in a file or spreadsheet, it's real easy.

Game Time and Interface Lag

If you use Order Time for things, you'll find that it usually adds about a couple of seconds to anything you're timing.

Try this:

  1. Bring up the Map, go into Orders, and write down the Time on your top-most Order.
  2. Now go in and out of the Map (back to the game world) ten times in a row, as fast as you can. (All that really matters is the time spent in the game world; time is frozen when anywhere in the menus on the map.)
  3. After you've hit the world ten times, bring up the Map and compare the time on the top-most Order.

I usually get a difference of about 16 seconds. If you divide by ten, that's ~1.6 seconds of interface lag for each time you cycled in and out of the Map.

In my extensive boot-duration testing, I always recorded about 2-3 seconds more time than expected relative to the stairstep function. Some of it was interface lag, and some was the slight lag to hit Tab the instant the boot was used up.

You should subtract interface lag (or at least be aware of it) if you do any precision testing with Order Time.

Game Time and Real Time

In my boot testing, I often used a stopwatch in addition to Order Time. This helped serve as a check that I didn't typo the game time.

But what I found is that sometimes game time is not the same as real-world time. Most of the time, it's within a couple percent. But every now and then, real time was higher. A few times it was more than 10%. The highest was ~20%. Usually, time passed slower in the game compared to the real world. For instance, in boot testing, Order Time once said 20:03 (a clear Step 1), but the stopwatch said 22:36 (not any step).

I don't know what caused this. Maybe heavy PC background processing? (The game was in the foreground for almost all testing.) Maybe lots of in-game processing? (But when my tests include time, I'm usually doing something pretty boring. Never any combat or whatever.)

Anyway, it happens. Stopwatches can be unreliable relative to true game time, if you want to be precise.

When I do use a Stopwatch

There are a very few places where I only use a stopwatch. The best example was getting speed on ziplines:

  • When you're hanging off of a zipline, you can't bring up the Map to see Order info.
  • But you know exactly the distance to your destination. That's one part of what Standard Orders usually shows you (time and distance), but here, you can't look at Orders... so it's great that ziplines show you Distance very clearly.
  • If you tried writing down Order time and distance before getting on the zipline, then got it again after getting off the zipline, there are two problems:
    • Each cycle (on/off) adds 18 m to Order distance. (Try it: Write down some Order's distance. Get on and off a zipline, without zipping. Look at Order distance again. Kind of goofy!)
    • It also adds a fair number of seconds, when we're only measuring ~22 s max anyway (for a 350m run).
  • So I just wrote down the distance, and used a stopwatch.

I also tried using a stopwatch for Generator recharge times, but found it to be pretty variable. I could've used Tab for this and looked at Order Time, but since Sam recharges 1k SBUs in just 5 seconds, having an extra 2-3 seconds added twice (at beginning and end) is unacceptable.

Slo-Mo Time is One Tenth of Normal Game Time

When you open any equipment wheel, you can see that time continues in the game, but at a much slower rate.

This slow-down was pretty easy to test using Game Time a.k.a. Order Time. But there's a real twist: The 2 – 3 seconds of interface lag, perhaps combined with time to enter and exit the wheel itself, really messes with these measurements. Consider:

  • If you did a test that was 60 seconds in real time, but equipment-wheel time (wheel time, laugh) slowed that to only 6s...
  • ... now your 2-3 seconds of interface lag, plus maybe a couple more for enter/exit the wheel might add, say, 4s, for a total of 10s.
  • If you then compared 60s of real time to 10s of in-game measured (Order) time, you'd conclude it goes 1/6th as fast (10/60). Not real accurate.

For my tests, I got Order Time before and after, but also using my phone's stopwatch for real-world time, while I kept a quick-menu equipment key pressed down (via a flat backscratcher with a weight on it, laugh). I tried 8 minutes, 10, then 15 and 16, and the X factor progressed like 9.3x to 9.7x to 9.8x, etc. As times got longer it approached 10x, but never quite got there.

So finally I ran it for 10k seconds (more precisely 2:47:02 or 10,022s). Order Time said only 1,004s had passed (16:44). That's a time ratio of 9.98x (10022/1004). FWIW I have also found in other long tests that Game Time can vary from real-world time sometimes, so I'm not worried that it was slightly off.

Also I did brief tests on all four wheel keys (1 to 4 on the PC). They were all the same: Slightly under 10x, and probably actually 10x in reality. Or at least for all practical purposes.

So there you have it: Time goes ten times slower when an equipment wheel is open.

FWIW if you're really into testing, you can use this to slow down the game:

  • I slowed down generator recharging, to measure its charge speed better.
  • You could even do video capture while constructing or deconstructing something to see how well the structure's hologram countdown in seconds, compared to real-time counts. (Would it really be exactly 10x longer?) That's the only clock-like thing I can think of in the game. I haven't tried this.

What Order (Game) Time does and doesn't Count

It does count all time passing in the "standard" game world itself (the three regions).

What it doesn't count:

  • Time in all menus. This includes knot interfaces, the Map, Inventory, menus inside the Private Room, etc.
  • Cutscenes and time in other "worlds". (Tested: Cliff's wars. Not yet tested: Time spent on Amelie and Higg's beaches.)
    • In one of his wars, you will have an Order specific to the War. This particular Order's time will pass, showing you how long you've been fighting. But all your other Orders' Elapsed Time will not change while there.
    • Oddly, although Cliff's wars don't increase the time on Orders, it does increase the elapsed distance on Orders. Huh. Is that good or bad? ... does it even matter?

Other notes about game time:

  • Each time you enter the Private Room (just when you enter, not exit) and if you Rest at a Prepper, it adds 30 minutes to game time.
    • If you fast travel to a different Private Room, it does not add another 30 minutes.
  • In a Private Room, time spent sitting on the bed or in any "free look" scenarios still moves the clock. Things like looking at the display cases, table, or plastic figures.
    • But time spent in a menu in the Private Room doesn't count. Like if you're arranging your backpack or choosing a War to replay.
    • Time in front of the mirror also doesn't count, but moving to and from the mirror does. Likewise, moving to and from anything else increases time a few seconds. Even Fast Travel only adds a few seconds to game time.
    • You can always use "Access Terminal" (the map on the wall) to check your Order Time in the Private Room. So it's easy to confirm what does and doesn't add time here. You can also save and reload there.
      • Reloading a Private Room savegame is super fast! And great for testing, e.g., different backpack accessories or loadouts, how the mirror works, or if you want to jump to different regions or knots to check on things.

Measuring Distance and Coordinates in Death Stranding

There are several ways to do this.

Orders Screen showing game time and distance travelled for a particular order

Order Distance

As discussed for Order Time (above), Orders also show distance down to the meter. This is great for testing or anything else. You can go from place A to place B and see how much distance elapsed for that Order.

Every single outstanding Order will show this info. I choose one near the top of my Orders that I'll never deliver, and use its info. This way I have an "absolute" meter for game-world time and distance. Or at least, it's good since the point that that order was taken.

Because you're usually doing deltas for testing anyway (ending time and distance minus start time and distance), you can use any Order you want.

X, Y Coordinates

Reading the Map

The X, Y coordinates are shown on your Map in the upper right, under the word "Online". (It also shows the zoom level of the map.) They're faint and hard to see unless something dark is under them. A few work-arounds to see it better are:

  1. Watch closely when you bring up the map and you'll notice you're zooming in on the cufflink on your wrist. Try to have something dark near you that's lower down so that it will then be behind the upper right of the Map, when you flick your wrist to look down at the cufflink.
  2. The corners of the map are dark, so you can also try zooming all the way out. Or maybe something dark will be in the right place if you play with the zoom.
  3. Wait a few seconds and the Help popup for the Map appears right under the coordinates. It makes their background slightly darker.

Unfortunately, in the mountains, there's an icy outline to the map that adds to its lightness. (Right when you're often in snow, too! Grr.) You might stand next to a structure or dark boulders, put something dark on the ground, or even build a throwaway structure if desperate.

How the Coordinates Work

DS uses an X, Y system where the first value is west (negative) to east (positive), and the second number is north (positive) to south (negative). It's just like a math or science X, Y chart – both values are positive in the upper right, both are negative numbers in the lower left, etc.

The origin (0,0) is just a touch northwest of the Weather Station. If you zoom all the way in, you will actually see the horizontal and vertical axes cross at this point, in faint etching on the map. This is part of a grid overlaid across the entire map (read on). However, it's so faint that it doesn't really help you, and is little more than a curiosity.

A little about the map gridlines

These are best seen where the map is dark, although they exist across its entirety. Look at the tar-lake crater north of Craftsman's Ruined Mall. You'll see a major gridline intersection just left of the center of the lake with coordinates +896, +2688. (Note that 2688 is 3 x 896... we'll be hearing more about this number.)

The map has major gridlines every 896m, minor ones every 224m (4 for every 896), 16 even lesser ones within these minor gridlines (so, every 14m) and then, very faintly, 5 more gridlines within every 14x14 box (which makes them 3.75m each).

If you go to the very far corners of Central, the coordinates are ±3,584 (that's 4 x 896). (For more info, see The size of the world.)

Don't ask me why they did it this way... maybe it's some standard. Maybe it was easiest for their fantastic Decima engine. Maybe it just fit with what they'd designed. Or maybe they simply wanted a "digitized map" feel, and slapped together something good enough.

I don't find much use for the gridlines. They're too faint, they don't have tick labels (like lat-longs on a map), and they use unusual subdivisions.

Anyway, there it is. The map has gridlines.

Testing DS's measuring capability

For the fun of it, I set up a little torture test of DS's measurements, with the time and distance seen on an Order. I went to the round bowl structures outside Lake KC (and other KCs) and used markers and Compass sighting distance to estimate its width, from one side of its outer "lip" ring to the far side. I estimated it at 65.0 to 65.5m wide, but I couldn't get a perfect read because the big rod in the center of the bowl blocks a direct view.

I figure it's a torture test because if you run laps around it, you're constantly turning. If the game is lopping off even a little of your turn to simplify its math or record keeping, it should show up.

So I put down a blood bag for a marker, wrote down an Order's time and distance, did eleven* laps, and brought up the Order the instant I crossed the finish line. *I wasn't sure I had done 10, laugh.

In 6:22 (382s), I ran 2,249m. That's 5.89 m/s (21.2 kph or 13.2 mph), and the distance divided by 11 (the circumference) is 204.5m. Using 2pr we get a radius of 32.54m and a diameter of 65.08m. That's versus my estimate of 65.0 to 65.5.

I'd say the Decima engine is pretty damn accurate. And that Order time-and-distance is great for testing.

But then why wouldn't it accurate? If it can ray-trace around the fine edges of rough objects from hundreds of meters away, move your POV at high rates of speed, and many other things, I guess it ought to be.

Anyway. Test concluded.

It's round.

Question: That big bowl has something like lips.

What's going on with that big rod?

The Compass and the Z coordinate

Using the Compass for Distance

You can put a marker on the map, and it'll show your distance. It also shows the distance to structures and knots. It will even show distance all the way across the map, to a far corner that isn't showing any game-world "ground".

More Distance, Scanner, and Compass Factoids
  • You can use the targeting reticule in the middle of your POV and the distance will be shown. This has a max range of 800m.
  • The Odradek scanner has a distance of 200m for cargo, but only 50m for chiral crystals and cryptobiotes.
    • It appears to be a vertical cylinder (not a sphere) centered on Sam; it still radiates out 200m horizontally even if you're on a steep slope.
    • You will only see HUD tags for lost cargo within this radius.
  • Sometimes you can see previously-scanned CXls and uncollected Cryptobiotes on the map and your HUD for hours and hours, and up to 370m away. If you go past this distance, you have to scan them again to see them.
  • With your Compass up, you can hit the middle mouse button to set a marker and get an instant Traverse Graph for it (see below). It can be pretty handy, especially for testing.
  • When on a zipline stopped at a support strut, you can usually put the cursor (your hand holding the zipline) onto any zip structure you can zip to at the moment, and the game will provide a distance and traverse graph. Just like if you had set a marker on it and viewed it with the Compass. It only works when you're hanging on a zipline. It doesn't work for ones that are out of your current zipline's range, but does work for ones in range but blocked by obstacles.
    • But it's a little buggy or something. Sometimes I can't get a single reading (traverse graph) to other zipline structures, when at a particular one. But if I dismount/remount it on the spot, I almost always can. It's some little bug that randomly happens to your current zipline structure maybe 10% of the time.

The Traverse Graph of the Compass and the Z Coordinate

If you put down a marker on your Map, then find it with your Compass, it shows a "traverse graph" of the vertical ups and downs if you went in a beeline to the marker.

The Traverse Graph's Dot Chart
Traverse chart - South KC lobby to three markers in the exact same direction at near, medium, and far distances

The little chart with dots (the dot chart) is an overlay graph with a fixed horizontal width corresponding to 1000m (1 km). You can still track markers that are farther than 1 km; it just won't show the trace line past that point. You can tell it keeps traversing past 1 km because it keeps updating the up and down values until it reaches the end, and then gives a little electronic sound when it got all the way to your end point.

  • This chart has 24 dots horizontally; 25 including the axis bar on the far right. The far left axis bar is 0, your starting point. (Think of a meter stick that starts at 0 cm and ends at 100.) Thus each horizontal dot represents 40m (25 x 40m = 1000m).
  • It also has 9 rows of dots in the vertical direction. These can be hard to see (see inset). Measurements make pretty clear that they are 25m each. So it's 200m high if you start from 0 at the bottom (dot 0 to 8).
    • This means that the vertical axis is emphasized 60% more... 200m only uses 5 dots horizontally, but 8 dots vertically. It's common for maps to emphasize vertical detail when it's helpful, such as here.
  • Although the dot-chart itself says 0 to 1000 along its X axis, be careful. This 1000m wide by 200m high dot chart is a fixed graphic that appears every time you use the traverse graph. No matter whether you are measuring far more or far less than that. It's a fixed standard intended as a measurement aid, which does not scale up or down relative to your traverse. It's always 1km horizontally and 200m vertically. And it probably always has the same pixel layout for a given hardware setup. (On my PC's 4k monitor, there are slightly less than 16 pixels between each dot-chart dot, horizontally and vertically; the 1000m stretch is 397 pixels.)

mw-collapsed

Finer points of the traverse chart

The inset with the distances (near, medium, and far) tells a lot about how the traverse and dot charts work.

  • I carefully laid the three markers along the exact same vector (direction) from Sam. That's why the A, B, and C are in a vertical column. (Sam himself didn't move as I did these.) The reason for doing this is so that the traverse line itself (the squiggly line) is covering the exact same terrain and therefore is showing the same details... it's the same traverse in all three. (Lining all three up is harder than you might think!)
  • After getting the three screen captures, I used a boxing graphic to arrange them so that the traverse line (which ends at "82") are all at the same vertical height in the collage image. IOW, if you hold a ruler horizontally, they're all at the same place.
  • In this way, these charts demonstrate that the traverse line itself does not scale, no matter how much verticality is contained in the entire traverse. Said another way, the first kilometer's traverse is the same height in pixels regardless of whether the highest elevation in the entire traverse is 184m or 1297m. Check it yourself: download the graphic and put something like a cropping box across all three and you'll see. I did not change the scaling of the three charts; they are all straight from my screencaps.
  • It also shows that the game always places the dot chart itself relative to the high-altitude number (the 184, 623, or 1297). That number is always in the upper half of the dot-chart overlay. But you can also see it's kind of squeezed to the top of the dot chart in the left-most chart (when there isn't much elevation difference), but relaxed in the other two.
  • Given the fact that the dot chart itself has fixed scaling (relative to pixels on your screen) for the first kilometer, I expected the distance between the elevation numbers (the double-headed red arrow) to also have fixed scaling. Makes sense, right? But I found that this is not true.
Traverse chart looking south from the north side of the Port KC building, across its container lot
  • Let's back up a little. Consider this simple little insert showing a completely flat traverse. To get it, I went to a place with a very wide, flat field and made a traverse chart across its extent; I deliberately made a "traverse" with as straight and long a line as I could. Notice that the high and low altitudes (148 and 147) still have a healthy amount of space between them vertically. IOW the devs deliberately prevented them from overlapping so that they'd be perfectly legible even in the extreme case of a completely flat traverse.
    • This means that the low-altitude number is below the lowest point on the traverse, and the high-altitude number is above it. So if you want to verify or test an elevation distance using pixel counts from a traverse chart, you have to count the pixels between the high and low altitude. You can't start from, e.g., the middle of the elevation numbers. (Or the top or bottom.)
    • Look at this dippy little dot chart again. The traverse itself has almost no vertical distance to speak of, but there's still significant space between the two numbers. Said another way: the numbers include a non-trivial number of blank pixels above and below them, just like the letters on a page (the body height in typography). These extra pixels should not be counted, if you're trying to figure out how many pixels are "between" the high and low elevation numbers.
    • You can also see this in the "Near Marker" chart. Look at where the diamond of the end-of-traverse is. (The traverse is only 994m, so it doesn't go past the 1-km Y axis; what you see is what you get.) Notice how the corner of the diamond is above the "82", just a little. Again it shows us that the font for the numbers has some extra space above, and that's where the squiggly line ends... that's where the actual value of 82 is, whereas the digits saying what the elevation's value are below that. (You see the same for the "184" if you put a horizontal ruler to the screen capture... the "184" is above the highest squiggle on the traverse line.)
    • To make a long story short: if you want to count pixels such as in the first dot chart example (with the near, medium, and far markers) you have to count pixels from the "inside" of the high and low elevation... from the tips of the double-headed arrow. Not from somewhere inside the numbers themselves.
  • Even taking all this into account, though, I could not find a way to get a constant scaling of the space between the two elevation numbers that corresponded to a nice neat number of meters per pixel. Even if you allow for a healthy body height for the numeric digits (like in the dippy inset), I still got measures as follows:

Value A B C Notes
High Elevation 184 623 1297 Stated values from each dot chart
Δ Elevation, m 102 541 1215 High Elevation - 82, the low elevation for them all
Pixels 60 202 424 Pixels between (inside) the elevation numbers (the 2-headed arrow)
Δ Elev. m / Pixel 1.70 2.68 2.87 Ratio of C/A (2.87/1.70) is 1.69, not ~1.00

In this table, I got the delta elevations (first two rows), then made pixel counts for the three charts using the "inside the numbers" method described above. Then divided delta elevation by pixels to get meters per pixel for the three charts (last row).

If there was a consistent number of meters per pixel, the last row would all be almost equal (with some very small variation for rounding from the pixel counts). And the ratio of C/A on the last row (2.87/1.70) would be almost 1, if they were the same. But they aren't.

I did a similar evaluation for where the "final diamond" is relative to the low elevation (the 82). It, too, did not have roughly the same meters per pixel.

So, for what it's worth:

I looked at whether the elevation numbers and the final diamond used a fixed scaling factor, like the dot chart itself does.

But it looks like they don't.

Thus, maybe they do vary the scaling for high elevations and diamonds (relative to the low elevation) depending on the distance being represented. So that they don't get extremely large (i.e., far apart on your screen) when looking at great differences in elevation.

But if true, I don't see why they felt the need to do this. The vertical distance from a pretty low place on the map (the lobby of South KC, elevation 82) to the highest point a player can get to (838 m) is only 756m. (Careful - the 1297 altitude on chart C was way off the map near its northwest corner; it's not a real place you can get to.) Heck, even chart B isn't hard to look at.

It seems to me like they didn't really need to vary the scale for these.

But it's also true that almost nobody does pixel counts from their traverse charts.

And maybe I'm just missing something, or did something wrong.

Shrug.

The Z Coordinate (a.k.a. elevation or altitude)

Off to the right, the dot chart shows high and low altitude values. These are the highest and lowest points across the entire traverse, even if they're farther away than the 1 km shown on the line tracing.

Careful, the two altitude numbers are not placed super accurately (and sometimes not even logically) relative to the trace line or the dot chart. Most of the time they look pretty close, but in certain situations they're obviously way off. So don't try to take a screen capture and then count pixels in order to extrapolate based on where these altitude numbers appear relative to the dot chart. Use the trace line or the dot chart itself for this (if you can). Still, the values themselves are accurate, even if their placement relative to the dot chart isn't always accurate.
  • These elevation values are the ONLY way I know to get elevation values in the game. Combine them with the X, Y coordinates from the Compass map to get all three spatial coords for Sam or marker points.
  • You or your marker must be at either the highest or the lowest altitude in the whole traverse in order to get a valid altitude with it.
    • It's easy to get Sam's altitude - just click on anything near you that is lower than you, with nothing higher in between, and take the high value. Or vice-versa if you're lower than most things around you. (Try to keep within 1 km, unless you're sure that the path past 1 klick can't be higher or lower than the elevation you're going to use.)
    • Getting it for a distant marker may be more complex, but one way or the other, work it so that it is the highest or lowest point of the entire traverse. You only need to be within 1 km to see the traverse trace, to be sure. But still, for complete confidence, go to the point itself and take the measure using Sam as the origin.
      • If you try to place a marker via the Map, note that it can be quite a few meters away from where you really want it. (It's a pretty low-resolution Map.) This can make a real difference anywhere rough, like the mountain! So stop complaining and start trekking to your measure point, Sam Porter Bridges. "How you doin, Sam?"
  • There's also a diamond against the right axis that shows the elevation of the destination/marker. If it seems to be at the highest or lowest elevation but is past the 1 klick trace line, you should get to within 1,000m if you want to be sure you're getting the elevation right.
Measuring Slopes Angles with the Traverse Graph

Ever wanted to figure out the steepest slope in the game? Or the steepest one you've been on? (with a zipline or not; doesn't matter)

Here's how...

You can use the dot chart to get the average slope between any two points. You can read it directly in the ideal situation that you're at the highest point of the entire traverse, and the other place is at the lowest (or vice versa). Basically, there can't be anywhere higher or lower, or you'll be seeing the elevations of those other places, not the elevation between your two targets. You only want their elevations, or your calculations will be wrong.

Usually, traverses are ragged. Or maybe it's simply hard to tell. In this case, you'll have to measure the elevation of each end individually, and then compare (delta) them to each other. See the previous section re: getting a solid altitude.

Also, ziplines have a built-in traverse graph. To see it, position your hand (holding the zipline) over some other zipline you're connected to (see inset).

Warning 1: Ziplines have a built-in elevation "discrepancy" of ~10m.
Warning 2: Sometimes the traverse chart doesn't appear when you're on a zipline; don't ask me why. If it's not working for a particular connection you want to gauge, just hop down a sec and get back on the zipline, and it will probably work now.
Also: You must be within 300 or 350m of (connected to) the target zipline to see the chart. It won't appear for ones farther away, even if you can see them with your eyes just fine.

All right then. Let's look at an example of measuring slopes angles with the traverse graph:

Traverse chart for Zipline - Halfway down from Geologist going to Veteran Porter - Zoomed in
OmniCalculator's Right Triangle for the Traverse Chart

1) Take the length of the zipline (347m in the inset).

2) Then subtract the high elevation from the low one, a.k.a. the rise distance. Here, 450 - 248 = 202.

3) And use something like the right triangle aid at OmniCalculator.

You only need those two values:

c = the zipline length of 347
a = the rise distance of 202

The calculator fills in the rest. As you can see, our slope angle is 35.6°.

Be aware that you have to add 5 to the height difference if you're on the higher zipline (and looking down), and subtract 5 if on the lower one (and looking up). I didn't actually do it here (yet) so this example is actually wrong, lol. For more details, see the expandable Handling the elevation discrepancy of zipline traverse graphs section of Zipline Speeds.

Also: There should not be any places in the traverse graph that are lower than the base of the lower zipline.

  • If there are, then they'll count as the lowest elevation, and bust your numbers.
  • In this case, you're going to have to measure the elevation level of the lower one by hand. (Go to it and do a little traverse very close to it, as described in the previous Z Coordinate section.)
  • You don't need to do it for the higher one. There can't be anything higher between you and the lower zipline, or it would block the zipline and you couldn't have made it!

More on the Traverse Graph

  • Below the graph are what I call "excursion values" for the amount of up and down travel you'd encounter if you made a beeline to your marker. (Crossing sand dunes on a plain that's otherwise flat on average still has plenty of vertical travel.) In brief checking, these excursion values aren't always accurate.
    • Standing on the cliff above the Cosplayer's river (below the waterfall), a traverse graph to the river surface said it's 82m below me. But if I put a marker on the far bank (west of me) at about my elevation, the traverse graph said I would go down 74m (hmm... kinda close) but only up 38m (nowhere near close) to get to that marker.
    • I guess it has trouble with sheer cliff faces, or anything past vertical (like overhangs). But if it does, then excursion values have issues on the mountain, too. (Probably less than my test case, but they're still a little iffy.) The way the game often jumbles big blocks together to make cliff faces and outcroppings probably makes for plenty of little overhangs.
    • Thus, the excursion values can give you a good feel for what you face, but don't take them to the bank.
    • Also, if you put a marker somewhere way off the walkable ground of the game world (like, a farthest corner of the map), you'll sometimes get crazy high altitudes (read on), but the excursion values won't hardly reflect them. Clearly it can't deal with undefined parts of the map. It doesn't have any impact on actual play, but still, there it is.
  • When the traverse reaches the endpoint, you'll hear a very faint ping. It's helpful if the target is far past the 1k you can see with the trace line.

Fun with Maps

This and That

The highest point in the game (what I call Highpoint) appears to be right above the First Prepper, coordinates -282, +767, +838. If you put a zipline right on it, the Highest Altitude Reached on your Bridge Links will say ~842m. (Getting on a zipline puts you several meters above ground.)

You can see a couple of peaks from Highpoint. Are they higher? No. The one ~110m west is 836m high, and the one ~91m northeast is 834m high. You're welcome.

For the helluvit, open your Map and put a marker in the very farthest corner from you. ALL the way, way past the edge of "usable" ground. Now go into your Compass and view that marker. Make sure you are facing it (look at your pointer on the Map) or you may have trouble finding it.

When I'm at South KC's terminal, the farthest corner (upper left) is coordinates -3584, +3584 and 7048m away horizontally ... and altitude 1297m! Apparently they didn't plan on points this high... the dot-chart graphic is up in the air (near your marker) but the traverse line is drawn much farther down on your screen. It still shows the high and low altitudes to the right.

In this example, don't be confused by the "1000" appearing a little below the upper altitude. That's still the hardwired dot-chart for the first horizontal km. The dot chart usually appears near the center of your traverse (vertically), but this particular destination is so "off the charts" that its placement is a little crazy here.

Game World Stats

The size of the world

The Eastern and Central maps both have max coordinates of 3584:

  • East to West (the X coordinate) is +3,584 to -3,584
  • North to South (the Y coordinate) is +3,584 to -3,584

Notice that 3,584 is four times the major gridline measure (4 x 896).

Since it extends from negative to positive, each dimension is actually two times 3,584m which is 7,168m (4.454 miles). Square this for total area and you get 51,380,224m2 (51.38 km2 or 19.84 miles2). However, as you can see from looking at the Central map zoomed all they way out, the playable (walkable) area is far smaller than this. Maybe only 15%? Eastern looks like considerably less, maybe 5%.

Compare how the inner, usable space of a refrigerator is only about half the volume. Seems low, right? Even though their outer walls are relatively thin, they comprise the entire outer surface; its widest dimensions. A similar situation happens with the DS map, but even more, because the unplayable outlying areas are often quite large.

The Western (Edge KC) map has max coordinates of 1,792 (2 x 896), or 3,584m (2.23 miles) for one entire direction (negative to positive). Squaring this number gives 12,845,056 m2 (4.96 miles2). Yet the Western map mainly has a narrow corridor you can use, so it's probably more like only 5% of this smaller map is playable (walkable). Its overall size is a fourth of the other two maps.

I leave it to someone else to trace the playable parts of maps and get better numbers for actual playable area in square kilometers for each map.

Lake Elevations

Here's the altitude of many of the larger lakes:

Region Body Elev. (m) Notes
Eastern Water N of Capitol KC 129
Eastern Water SE of Port KC (to Lake KC) 142
Central Water NE of Lake KC (to Port KC, at LKC start dock) 168
Central Great North Tar Lake, W of Lake KC (outer ring) 166
Central Great North Tar Lake, W of Lake KC, inner ring 153 In the crater. Only the near parts give sensible readings. Farther away altitude jumps to elevation 1002m, maybe off the defined map or whatever.
Central Great North Tar Lake, N of WS N of MKC (outer ring) 162
Central Great North Tar Lake, N of Incinerator (outer ring) 162
Central Great North Tar Lake, N of DC N of MKC 166 Close points are 166. ~500m away is 162. >1k are like 1002 or 1297 high.
Central Tar S of Chiral Artist (to South KC) 124 Near the north shore is 124m altitude ...
Central Tar N of South KC (to Chiral Artist) 115 ... but most of it is 115m. Okay, shrug.
Central Tar S of Cosplayer 76 Where the river of Cosplayer's waterfall has merged with the ocean
(actual point measured +990 -2180)
Central Tar S or SW of Timefall Farm 80
Central Tar S of Chiral Relay (to Edge KC) 76
Western Tar N of DC N of Edge KC (to Chiral Relay) 104 If you measure from the DC terminal, it says 98. If you go out of the DC or to the beach, the tar's altitude is 103 or 104. (This is the ocean to N, not the lake on the way to Edge KC.)

I was expecting/hoping that it'd be the same for "connected" bodies, like from Port KC to Lake KC. And I was curious what altitude other bodies would have. As you can see, connected bodies aren't at the same "sea level" (altitude). I don't know if that's intentional or was just past what they bothered with.

Anyway, it doesn't really matter. But I checked it. Now we know.

Zoom levels in DS

On the Map

Your Zoom or Magnification level is shown in the upper right, below "Online". It's pretty dim; see Reading the Map for tips on seeing it.

  • You can zoom from 5.00 (all the way in) to 0.20 (all the way out), a difference of 25x.
  • If zoom is lower than 0.90 (zoomed out), you can see icons for cargo and vehicles, but can't see details.
    • This means you can't see details on your own vehicle, too. You have to zoom to 0.90 or higher.
    • The cursor will "auto-attract" to Sam. Then hit the Up key to see details on your vehicle (and nearby Orders and cargo).
  • For what little it's worth, changing zoom levels shows hysteresis (drift or imprecision). If you try to go back and forth to a particular zoom level multiple times, the exact zoom level changes a little over time (becoming 0.89 instead of 0.90, etc.).

Zoom levels in Sam's Field of View

  • In the ordinary interface hit Zoom (T on PC) to get 2.00x zoom.
  • The view in the Compass is 1.33x normal field of vision.
    • Hitting Zoom (T) when in the Compass is ~2.67x (2 x 1.33).
  • All guns except Rocket Launchers have 1.50x zoom when aimed.
    • Both Rocket Launchers have ~2.25x zoom (1.5 x 1.5) when aimed.

To summarize:

  • In regular play, use T to zoom in 2x
  • For a little more zoom, go into the Compass and hit T. It's a third more than normal T (2.66/2.00 = 1.33 = +33%).

Testing details

Zoom was tested by:

  • Finding flat perpendicular surfaces (walls) with very regular features at or near eye level, which extend as far as you can see in lowest-level zoom (regular vision).
    • The chain link fence at the wharf to north of Isolation Ward at Cap KC worked fine for this.
    • But you can't aim weapons there, so for that I used the big rusty wall out back (north) of Lake KC (go around its energy wall).
  • Took screencaps at various zooms.
  • Got pixel counts for regularly-repeating parts of the surface, then extrapolated those repeated parts to the edges. Examples:
    • On the chainlink fence, I could see 10 whole sections of fence (separated by fenceposts) plus 0.130 of additional sections on left and right (total: 10.130).
    • Using T, I could then see 4 whole sections plus 0.621 on the left and 0.248 on the right (total: 4.870).
    • 10.130 / 4.870 = 2.08, or 2x zoom.

This crude method covers more ground at the edges (think, drawing in perspective), so the ratio I derive depends on how much of each screencap was at the edges. Anyway, it's a close approximation, even if not exactly right. The devs seem to have made many simple choices under the hood, so I imagine that's what they did for zoom, too.