Print

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

[Bumber]

Oh, and if you did it that way, you would only need a single north/south line, with many east/west lines branching off - cutting down even more on construction times (and still with the same travel time, as discussed above.) It becomes a little bit like the "40 branches at every station" tree idea.

Disadvantage, as with the binary tree approaches, is that, despite all the construction reductions, you would have to return to the mountainhome between every destination if you want to take the train there.

If you add vertical directional checks to the N/S line you only need to return to the N/S line instead of the origin. There's an away rail system and a return rail system, perhaps located alongside one another or on separate z-levels. If the weight of the N/S cart is too heavy/light for the direction it's traveling, it then switches direction to the other line. The E/W return branches contain no checks. Their purpose is to send you back to the N/S line without touching your carts.

Code: [Select]

        Away          |       Return
                      |
y=1  o<--o-->o-->o    |    o-->o<--o<--o
         ^            |        |
         |            |        v
y=0  o<--o-->o-->o    |    o-->o<--o<--o
         |            |        ^
         v            |        |
y=-1 o<--o-->o-->o    |    o-->o<--o<--o
   x=-1 x=0 x=1 x=2   |  x=-1 x=0 x=1 x=2To go from one station to another you depart on the return line, which takes you back to the N/S line, and the coordinates are read as usual. If you depart on the away line, you can reach a station on the same branch that you haven't passed yet using a single coordinate. For example, (1,1) to (2,1) requires a single '2' cart, while (2,1) to (1,1) requires returning to (0,1) with carts '1' and '2'.

I tried designing a multiple N/S line system, but it ends up too big and complex since it must be a complete and rectangular grid, due to my system not putting back coordinates after reading them.

[omega_dwarf]

If you add vertical directional checks to the N/S line you only need to return to the N/S line instead of the origin.

I like it

[Larix]

Concerning how many different weights of carts are usable for data storage: 84.

There are forty "weight groups" of 50 kg each, ranging from 0-50 to 1950-2000. Only 11 of those can be got by picking empty carts, so that implies a lot of calibrated cart loading already. In addition to those groups, you can also take a cart weighing over 2000. It'll activate an "any" plate, but no specified-weight one. This already brings us to 41 different weights.

A peculiar case occurs when a cart's weight is exactly the "limit" amount: the cart will activate _both_ the low-weight and the high-weight plate. I.e. a bloodthorn minecart will activate both a 0-50 and a 50-100 plate. Thus, we get extra options for the limiting weights 50,100,150...1950. Measuring gets harder, because now we have to differentiate between "0-50 and not 50-100", "50-100 and not 0-50" and "0-50 and 50-100", but we get 39 additional "states" to work with, bringing us to 80 total.

Finally, water can be loaded and dumped automatically and for four weight groups, an empty cart falls into the same weight group as a different-base cart loaded with water: empty lead - full wood; empty electrum - full aluminium; empty gold - full iron/bronze; empty platinum - full silver. For each of those weight groups, the cart could (after making sure it _only_ activates that plate) be sent over a dumping track stop and then measured again; if weight went down, it registers as a different signal and gets loaded with water again.

Summa summarum, eighty-four different weights that can be picked out by pressure plates. It's not the absolute limit, but it's already more than is practical.

NB: i haven't tried this out, i only verified in .34.11 that bloodthorn carts activate both types of pressure plates.

[escondida]

A naïve, non-computation solution could work, too, especially since DF isn't really constrained by things like material budget and civic planning as a real life project would be. Generally, posts in this thread assume that we want traffic in any given direction to share a single rail. Each stop on this rail has to do things like branching to accommodate multiple destinations or checking tokens to decide whether it's the correct stop. Though optimal in a traditional civic planning paradigm, in the worlds of Dwarf Fortress, why constrain ourselves with such petty rules as "don't carve the railway through people's homes" or "it's not practical to mine tens of thousands of tons of stone in order to build such a fanciful project" or "this rail system will clearly collapse under its own weight"? I propose an alternative:

Cover the world with rails. Are we not dwarves?

Why bother our boozed-up brains with complex computing systems when we could just do what we do best--adapt the world to our needs. True, we may need to raze forests and level mountain to build all of our tracks, but such is the price of progress.

With this system, the destination is determined the instant Urist chooses a cart, because each rail line has one destination and one destination only. At the end of the line, no checking needs to be done, because Urist is just unceremoniously dumped at the end of the track. The system can be as centralized or decentralized as you like, because to make a new local hub or add a destination to an existing hub, all you need is blocks, carts and labor. All routing decisions are made during construction.

Code: [Select]

                           -~-~-~
                           Legend
                           -~-~-~

A-Z     : Destinations
/       : Ramp up, because this may as well be a skyway while we're at it, no?
\       : Ramp down                         
=       : Rail
.       : Airborne trajectory
u       : Urist in a minecart
"Whee!" : What Urist says while riding the rail
-~-~-~-~-~-~

                               "Whee!"
                             .u
                            .     
                           .       
                          .         
                         /           
   /====================/              \
  /===============\                     \
 /==========\      \                     \
A=======B    \=C    \=D                   \=E


[omega_dwarf]

Finally, water can be loaded and dumped automatically and for four weight groups, an empty cart falls into the same weight group as a different-base cart loaded with water: empty lead - full wood; empty electrum - full aluminium; empty gold - full iron/bronze; empty platinum - full silver. For each of those weight groups, the cart could (after making sure it _only_ activates that plate) be sent over a dumping track stop and then measured again; if weight went down, it registers as a different signal and gets loaded with water again.

Summa summarum, eighty-four different weights that can be picked out by pressure plates. It's not the absolute limit, but it's already more than is practical.

Logical (and dorfy) extension of the water usage: magma. More values.

[Miuramir]

Cover the world with rails. Are we not dwarves?

Let's hope so, because if we were Devo, we might not end up satisfied   If this makes no sense to you, you may have to ask your parents.

More seriously, I suspect there are some limitations; it's not clear how serious they would be, however, unless you play very small sites.  Small sites both reduce the "surface area" to allow connections, and incidentally increase the number of possible sites on a map.  This problem is very similar to wiring up traces to connect chips on a circuit board; routing software designed for such could probably be used. 

You are suggesting a "fully connected mesh" topology, aka a "complete graph".  Number of connections would be n * (n-1) / 2.  Connections to a single site would be n-1.  An X by Y fort has about 2*47*X + 2*47*Y readily usable edge squares per Z level (IIRC you can't route out the corners without a lot more work). 

A large region is 257 x 257; each region square is 16 x 16 embark squares.  Consider a worst-case scenario (?), a grid alternating between 1x1 nano-embarks and blank squares for routing, for the whole map.  You should have 257 * 16 / 2 = 2,056,  squared = 4,227.136 embark sites on your map.  That implies about 8.9343 * 10^12 connections.  The corner embark will need to route all of those through only two sides (47 * 2), requiring about 95,046,142 Z-levels, which I'm fairly sure exceeds the max DF can handle.  (This is why the Internet is not fully connected topologically...)

What *is* the maximum possible number of Z levels in an embark?  Presumably the levels usable for tracks or routing would be at least one less.  Wiki says "well in excess of 600 levels", but that doesn't seem well documented or verified against current versions; it implies that worldgen is (or was at some point) limited to 400 levels of "terrain", but leaves open the question of how much "sky" you can force. 

[Magistrum]

On theory it goes up to infinite, but there may be bugs with overflow because of the way variables are store after some number.

[Larix]

Finally, water can be loaded and dumped automatically and for four weight groups, an empty cart falls into the same weight group as a different-base cart loaded with water: empty lead - full wood; empty electrum - full aluminium; empty gold - full iron/bronze; empty platinum - full silver. For each of those weight groups, the cart could (after making sure it _only_ activates that plate) be sent over a dumping track stop and then measured again; if weight went down, it registers as a different signal and gets loaded with water again.

Logical (and dorfy) extension of the water usage: magma. More values.

Hmm, i think that'd just add platinum with water vs. iron with magma and possibly (not sure) electrum with water vs. adamantine with magma. Both lose weight when dumping, but their empty weights are still different. Other than that, a cart with magma (only five types possible, two with the exact same weight) weigh more than the heaviest empty cart and are not usefully distinguishable from carts loaded with non-magma. Dumping measurements with other loads are not useful, because only liquids can be loaded automatically. If you dump stone blocks out of your cart, you need to stop it and have dwarfs cram the blocks back in to restore the loaded weight.

Actually, i think encoding sixteen values (four bits) per cart is around the point where higher information density isn't worth the added nuisance of handling.

Alternative approach: let each cart stand for a "position" within the bit stream and encode message by their presence/absence. You need a "marker" cart to signal that a message will be/has been sent, but the message can be sent along a single track, with carts just far enough apart that they don't collide (25 steps should be plenty): http://www.bay12forums.com/smf/index.php?topic=136981.msg5074064#msg5074064

[Meneth]

I might have missed something, but couldn't we just make the switching manual?

Rail would start and end at each station. The passenger would get out and walk to the next rail towards his destination.

Would require a bit more effort from the rider, but should be simpler to construct.