Print

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

[Graknorke]

Well there's no way I would know how to do it either way, so of course I'm going to say the more difficult one is better

[wierd]

Only if you are masochistic!

You would need not only a fully blown dwarfputer, like the one Larix designed (So far, the most compact general purpose computer to date in DF), you would also have to code a logic tape for it, THAT WOULD BE DIFFERENT AT EACH STOP.  (The logic to determine weather to unload or pass would be based on the ID of the station, which means that the code tape has to be unique to each station in that respect.)

Just the dwarfputer alone is a megaproject in itself. Writing its tape requires assembler and strong logic knowledge,  and you would have to do this FOR EVERY SINGLE DWARVEN SITE.

THEN build the interconnects!

No. Star topology is more than just harder and thus more dwarven. It is "OMG! WHY DID I DO THIS TO MYSELF!? WHY!?"

Toady would have a whole new release ready by the time you were half finished on anything bigger than a pocket universe.

Loop design, on the other hand, focuses mostly on the interconnects-- follows a very simple computer that takes up very few components and can mostly be built using quickfort templates, and will get you a "Functioning" rail system before you die of boredom.

Amusingly, One could use the mountain home as the "Transit Hub" and have nearly all of logic constrained to one site, with all other sites linking directly there on dedicated transit rails.

EG-- Say we have one major city, which is connected directly to all other cities.  The other cities only connect to the major city.  Riders from one minor city ride to the major city, ride the short version of the loop, and get shot out to the destination city.

Still token ring topology, still easy to implement, more practical for riders.

[Graknorke]

Only if you are masochistic!

Y-yeah... what kind of freak enjoys bad things happening to other people >_>
^_b-baka...

The hub thing does sound like a good compromise in usability and ease of building (having to cram all that on one site must put restrictions on space), still a huge undertaking.

[Aslandus]

Only if you are masochistic!

Y-yeah... what kind of freak enjoys bad things happening to other people >_>
^_b-baka...

The hub thing does sound like a good compromise in usability and ease of building (having to cram all that on one site must put restrictions on space), still a huge undertaking.

"Masochistic" would be you enjoy bad things happening to yourself, which is totally true if you planned to make a flipping computer on every station for your rail line...

[omega_dwarf]

Suggestion to simplify the "ID"s:

Correct me if I'm wrong, but for the purpose of easy signaling/redirecting, couldn't we use a star topology...but, like, with tree branching? Maybe I'm not clear from Wikipedia's descriptions of star topology vs. token ring. This would be starting with a hub, going out from the center. When you reach a certain radius (or destination), that path forks and becomes two paths at an acute angle, and then there's another break point farther down each rail, etc., until you get the system as far out as you want to go.

Then you could have a central hub (let's say the mountainhome.) You have, say, eight tracks to choose from there (each cardinal direction, and NW/NE/etc.) You get set up on whichever track leaves the mountainhome in the general direction you want to go. When you depart, a string of mincarts precedes you. Each one is a binary signal. When you reach a branching point, it's 1 or 0, left or right.

That car gets ejected from its holding loop to the back of the whole minecart caravan once it's passed, reverse-Indian-run style. The passenger has a different weight than the 1 or 0 carts, so when the passenger cart reaches a station first, you know to stop, because there aren't any more instructions. All the carts are still with your adventurer, and can be collected for further journeys (or every 10-15 years you could just reclaim the mountainhome and make some more carts.)

@wierd, is this what you were describing?

More ideas for the rest of the system:

Spoiler (click to show/hide)

For the return journey, it's dead simple: you don't have to make any decisions, you just need to have the carts follow the player back if you want to recycle them. Or you could stack them in front and use them as a counter for determining which stop to get off at (if you want to stop before the mountainhome; shuffle the front cart to the back of the caravan at each fork), but that would make each station much harder to build. (Otherwise it's just two pressure plates, a holding loop, and a simple unloading station. Loading station too if you want return journeys that don't just take you straight back to the mountainhome, but still simpler than the ones at the mountainhome, because only number of carts would matter. The only complication would be if you want to start outwards from a place that's not the mountainhome.)

As a practicality thing for passengers, you can have short a->b tracks linking adjacent destination cities or branching points. So the whole network would look almost like a spiderweb. It seems like it would be pretty efficient to me - at long distances from the mountainhome, it would be very close to a grid. It would be kinda tedious traveling along the radii, but meh.

You could avoid supercomputer status at the mountainhome by just having the correct cart sequences written down on paper and using a self-serve lever setup to pull down "1" or "0" carts in the correct order. Or...I mean, could adventurers just haul them into place? Then all you need at each launch site in the mountainhome is a lever that makes things go.

And you don't have to have the whole system perfectly circular, or with perfectly clean branches. You can have different parts of branches have different numbers of stops...if you enter the wrong number of carts, you'll just stop prematurely or be collected at the final station on the branch.

However, if you build it geometrically, you could easily determine, from the mountainhome, based on the location of your destination, what the combination of minecarts would be.

It's still a megaproject, but you might be able to just embark with supplies and finish up each station before your dwarves die. Nevermind, you need rollers. *sigh*

tl;dr - You could easily determine, from the mountainhome, based on the location of your destination, what the minecart "ticker tape" should be, and there's pretty simple station logic.

Should I upload an image of what I'm talking about?

[wierd]

Ok-- The issue at hand is "Complexity of the signal processing system needed at each site"  --VS--  Convenience of the rider.

Pure token ring uses a simple "Is it addressed to me? Yes/No" evaluation. If YES-- then accept the minecart and debark the rider. If NO, then pass the rider to the next station.

TokenRing assumes that all stations will be logically organized into a single ring, which goes one direction. (Most pictures have this going clockwise, but there are also anticlockwise implementations,)

Because it uses such a simple evaluation method, it does not need a sophisticated dwarfputer at the station. Just some logic to evaluate a unique ID of some sort. This can be hard wired logic that uses a few hundred mechanisms at most, for the full computer.


Star Topology on the other hand, branches out, and has many redundant paths.  It is more fault tolerant than token ring, and can have more direct paths for a given destination if planned sensibly. The problem is that a more sophisticated computer is needed at each site in order to use it.

Star Topology is basically how TCP/IP network routers work.  They have a number of "interfaces" on which they can accept or deliver a packet.  Depending on where a packet is destined, a TCP/IP router will look to see if the destination is local to itself, and not send it out any of its external interfaces. If however, it is not a local address, it looks at a routing table to determine where it is going to send the packet for further evaluation by the next device downstream.  This happens repeatedly until the packet lands in the target network's router. The global internet uses a 32bit addressing schema, which it has since WELL outgrown. (We are still using it, but are using all kinds of obfuscation tricks to do so.)

The basic problem comes down to having to implement added "Intelligence" into the routing part of the minecart transit system, along with a more sophisticated addressing schema than needed for the tokenring method.

Say for instance,  we have 9 stations, all laid out in a nice orderly fashion, where each station has 4 connections. Say, something like this:


 |   |   |
-A-B-C-
  |   |  |
-D-E-F-
  |   |  |
-G-H-I-
  |   |  |

(A is connected B, D, G, and C, since we presume "wrap-around" in this exercise)

Urist wants to go from A to I.
What is the shortest path?

Well, he could go from A to C to I..... 3 steps
Or, he could go from A to G to I .....  3 steps...

...

See the issue? There are redundant, equally expedient routes.  How does site A know to send Urist to C, or to G? It has to make a decision, and therefore needs more information.

The only real way to do this, is to have each stop have its own little cheat-sheet on which route is preferred for what kind of traffic, and which routes are secondary routes, used only when the first route is broken.  That's why you need the bigger computer, AND at EACH city. It has to do a hell of a lot more than just "Is this mine? No? Ok- pass the buck".  Instead, it has  to do "Is this mine? No? Ok-- Where is it going? What is my preferred route to get there? Ok- Is that route healthy? No? Ok, what's my secondary route? Is that route healthy? ... ... "  Surely you see the difference in the level of complexity needed for branched delivery, right?

The idea for the transit hub is more like this:

Inside the mountainhome, (which should be as geographically equidistant to all other sites as possible for efficiency) there is a circular track with a "stop" for each and every site in the civilization.  This circular track is kept as short as possible, and has all the "Is addressed to me? YES/NO" logic built into it.   Each of these stations has a bunch of minecart tracks leading from it to each and every one of the civ's sites, except the one corresponding to the mountainhome site itself. It just acts as the local termiinal for the locals. 

Each remote site has an "Encoder",  and a "Get on, Get off" area.  A destination is set using the encoder, which then tells the corresponding terminal at the mountain home where the rider is destined.  The rider gets on, the encoder sets the destination, and the address carts and the rider cart speed off to the mountain home, full steam.

When they get there, the rider is put into the station's "Idle loop" while it accepts the address cars, then determines if the car is addressed to this station or not. (If it is, and Urist was playing a prank, and put his own city's address in, he gets sent right back home.)  If it is not (which it shouldnt be!) he gets shuttled to the next station, and the destination encoding carts get sent to the next station.  Urist arrives at the next station, gets put into the idle-loop while his destination is processed and evaluated-- rinse repeat-- until the destination station is reached. (He has still not physically left the mountain home site yet. He's just been getting shuttled through the large central transit hub complex) Once there, instead of being passed on again, he gets sent down the connecting path from the mountain home to that city, as to the address carts.

Putting boulders in the cart or not can be used to encode binary states onto the address carts, and still have a means of determining that the cart has arrived.  Only the encoding system fills carts, and only the final destination empties carts.  The evaluation of weather a cart is destined for a station or not is done by measuring the weight of the cart.  Since all the carts are of the same metal type, all empty carts weigh the same amount, so we can set that weight as the 0 state, and all other weights as the 1 state.  a "did not arrive" is an error state.  each station needs all of the address carts to arrive before it can determine if Urist should disembark or not. So, it has him circle in the idle loop until all the address carts arrive, get parked in the evaluation stopoffs, and are checked.  Once the check is done, Urist is either disembarked, or passed to the next station, along with the address carts.

By having an "Abstracted" loop at the most equidistant city, we keep transit distance as close to the "mathematical average distance between cities".  A direct connection from say, SiteA and SiteB migh be faster, especially if A and B are back to back next to each other-- However, that again would require the more sophisticated computer system at each site to handle the addressing and routing.

The alternative to routing to a transit hub city, or using a branching star topology, is to have exactly 2 links between each and every site, and instead of an abstracted loop all compressed into a single site-- have one actual loop that is all jaggy connected all sites together. Now Urist might well ride all over Armok's Bloody Earth just to go see grandma, perhaps spending MONTHS on the minecart.


So, the benefit to cost comes out like this:

Branching Star:  Assures best possible route taken from any arbitrary source to any arbitrary destination in the network-- But requires a monster dwarfputer in the basement of every site to pull it off.

Transit hub with abstracted tokenring: Distance traveled bewteen any two cities is kept pretty static, with only a slight increase in distance traveled by going through the transit loop. Keeps the complexity of the dwarfputer to human-managable limits-- But has the downside that the shortest trip possible is slightly longer than a direct connection between the two most distant cities (From each other).

Pure tokenring:  Simple input and output, very little dwarfputing needed, but the distance that the rider has to travel can range from very short to being the equivalent of Visiting Every City Urist Did Not Want To See First before getting there.

Star Toplogy without any routing: Requires Urist to know which stations he needs to pass through to get to his city, and go to the appropriate terminals in each city he stops at and get on the next cart himself, each and every time. No automation. Fastest way to get there is assured, no dwarfputer at all, but tedious as hell.

[omega_dwarf]

- snip -

Wow, that's a very thorough explanation! Thanks

I guess I was a little vague with what I meant. Maybe a lot vague. I wasn't presenting my interpretation of either of the extremes; I was suggesting a compromise, a sort of middle ground, that basically eliminates the dwarfputing in your hub system. If I understand your hub system correctly.

Basically there's only one route from city X to city Y, and it has mountainhome Z in the middle. Adventurer jumps on the train and gets to Z. Then, at Z, he gets off, looks at his handy-dandy map and picks out all the left/right turns as necessary to get to Y from Z, and which main rail line he should start on (makes having unique ID's slightly more tolerable; all you need is a complete map of the rail lines.) That cuts down on dwarfputing.

At each station (outside of the mountainhome), dwarfputer action is only required if he's travelling outwards, and the action is choosing left or right or stop based only on the first minecart that comes through.

So the route is assumed to be "straight to the mountainhome" when he's traveling inwards. Thinking only has to be done on the way out, and it can be simplified to something like

Code: [Select]

if (heavy enough to be a rider) {
  stop;
} else {
  if (light enough to be "1") { // 1
    go to the left fork; // (and continue going outwards)
  } else { // 0
    go to the right fork; // (and continue going outwards)
  }
}
The only complicated part of that is keeping the first cart in a holding loop until the rest of the caravan has passed. The decisionmaking can be done with two pressure plates per stop, set to trigger at appropriate weights (first one at "anything heavier than the binary signals", second one differentiating between the two signals.) My point was to cut down massively on the dwarfputing, so it would be more feasible to build - not necessarily to provide the best route, or even the right route (a lot depends on Urist's map-reading skills here when he reaches the mountainhome.)

The alternative is

Code: [Select]

if (this stop's ID == encoded ID) { // Much harder to check than the individual left/right signals, and still requiring an index of location ID's
  stop;
} else {
  send Urist somewhere;
}
(The tracks along the radii would just be on separate systems, simple a->b, in case Urist doesn't want to go all the way to the mountainhome first to go to see Urist McGrandmother who lives one branch over. That's only going to be convenient if he only has to make a few stops; it's a non-automated token loop that intersects all the main branches of the hub-based system at a certain radius.)

Granted, it would be cooler if you could just enter an ID at any stop and go, but I think the easier assembly of this system would make up for it.

(Side note, my main suggestion would also cut down on rails required, if I understand you right. It looks like you're suggesting a separate line directly from the mountainhome to each site. Mine would use, say, 8 different tracks from the mountainhomes radially out to about a certain distance, then all the lines would experience a fork (with a station to decide if Urist has arrived, or which direction in the fork he needs to go) and there are now 16 tracks until the next radius at which there are forks in the branches. That's to make up for the increasing gap between the 8 original branches if they just went straight out and did not fork.)

So it doesn't require a supercomputer anywhere - just Urist manually ordering carts corresponding to the ID (in this case, the same thing as left/right directions) of his destination when he reaches the mountainhome. Since the ID has such a direct real-world meaning, it doesn't need to be read in full at each station. It's just simpler. Urist makes one more stop; the civ saves billions in dwarfbucks and many overseer suicides

[Miuramir]

Star Toplogy without any routing: Requires Urist to know which stations he needs to pass through to get to his city, and go to the appropriate terminals in each city he stops at and get on the next cart himself, each and every time. No automation. Fastest way to get there is assured, no dwarfputer at all, but tedious as hell.

I'm out of practice on this, but one variant of the above which makes addressing, processing, and transit easier but limits construction and expansion would be the case where the topology is a complete binary tree, and the address of a node is actually a bitfield encoding its position in the tree.  Each station would only need to check a few bits of the address around the station's own depth, because any single station has at most four routing options: up-tree, stop here, down-tree-left, and down-tree-right.  Most of the address doesn't need to be examined at any given stop, the higher and lower order bits than those around the station in question simply being passed along.  And Urist gets to ride the same cart with automated switching at each station. 

One implementation would be a binary string of heavy and light carts preceding the "payload" cart.  Given the nature of cart computing and the structure of the problem, 4-valued logic might be an obvious choice. 

[Bumber]

Maybe I'm being too simple here, but what if you forgo the fancy dwarfputing and just have a weighted cart line that triggers the appropriate pressure plate for the main cart line to disembark at? Add a second weighted cart with perpendicular rail lines and you have a Cartesian coordinate system.

You'd still need a bit of logic to accept only the signal of the first weighted cart, unless the second weighted cart travels right in front of the passenger cart or in its own dedicated lane. Actually, you could throw both the weighted carts in front of the passenger cart, as long as you accept only the first cart (i.e., there's an extra plate that disengages the weight check for a bit whenever a cart passes.) The first cart is removed from the track after the axis switch, or maybe sent behind the passenger so they can have it for additional trips.

[Arx]

Is it inappropriately practical to construct a large number of relatively low-order ring topologies where each destination has its own rail? You could then link the rings in central stations.

[Skullsploder]

I have an idea. There are 40 steps in pressure plate weighting for minecarts, yes? One could make a system where branching is fully possible, simply (but expensively). In short, you could have each path have an unlimited number of branching stations with each branching station haveing up to 40 branches, by launching a string of however many minecarts alongside the rider's minecart. Each time the rider and his companion carts come to a branching station, the first minecart is taken, read for one of the 40 possibilities by a pressure plate, and ejected backwards. (come to think of it, that would only happen at the very end) The branching station remains switched on the last course taken from it, which allows minecarts to return home from infinitely far away, with the launch station establishing a stop for the companion carts upon launch. Meanwhile the rider and remaining companion carts continue on their journey. With this system, each destination can have a unique address, consisting of a string of numbers which get more and more specific.

For example: 5-13-23-40-32-4 would mean 5th main hub, 13th hub region, 23rd Duchy, 40th County, 32nd Barony, 4th Outpost.

Each branch station would need a system of splitting each cart that makes up the address into its own little IF-series tunnel of pressure plates, at which point the station checks first if the rider is in the right hub, then region, then duchy, etc.

I.E the first cart's tunnel has a pressure plate for every HUB except the one the rider is in.
the second cart's tunnel has a pressure plate for every REGION in the current HUB except the one the rider is in.
the third cart's tunnel has a pressure plate for every DUCHY in the current REGION except the one the rider is in.
And so on.

If the first tunnel receives no signal, the second tunnel is considered. If the second tunnel receives no signal, the third is considered.
The highest priority signal received will redirect the rider and his companion carts.

If someone could figure out a way to implement this, it would mean you could have 40^address_length destinations arranged in an arbitrary topology without excessively complicated dwarfputing required at the branching stations.

[Snaake]

Maybe I'm being too simple here, but what if you forgo the fancy dwarfputing and just have a weighted cart line that triggers the appropriate pressure plate for the main cart line to disembark at? Add a second weighted cart with perpendicular rail lines and you have a Cartesian coordinate system.

You'd still need a bit of logic to accept only the signal of the first weighted cart, unless the second weighted cart travels right in front of the passenger cart or in its own dedicated lane. Actually, you could throw both the weighted carts in front of the passenger cart, as long as you accept only the first cart (i.e., there's an extra plate that disengages the weight check for a bit whenever a cart passes.) The first cart is removed from the track after the axis switch, or maybe sent behind the passenger so they can have it for additional trips.

Good of you to think of a simpler solution

Also, in focusing just on Star Topology vs. Token Ring, you're focusing too much on computer science/mathematics. Think like a public transport planner for a while: if you have lots of stations, a single loop clearly won't cut it, but several loops and/or lines intersecting them can cover a large network much easier than pure star topology, and requires far less logic, since each subset (loop or line) of the network has fairly simple logic driving it. It does of course require some changes of lines at stations etc.

[omega_dwarf]

Star Toplogy without any routing: Requires Urist to know which stations he needs to pass through to get to his city, and go to the appropriate terminals in each city he stops at and get on the next cart himself, each and every time. No automation. Fastest way to get there is assured, no dwarfputer at all, but tedious as hell.

I'm out of practice on this, but one variant of the above which makes addressing, processing, and transit easier but limits construction and expansion would be the case where the topology is a complete binary tree, and the address of a node is actually a bitfield encoding its position in the tree.  Each station would only need to check a few bits of the address around the station's own depth, because any single station has at most four routing options: up-tree, stop here, down-tree-left, and down-tree-right.  Most of the address doesn't need to be examined at any given stop, the higher and lower order bits than those around the station in question simply being passed along.  And Urist gets to ride the same cart with automated switching at each station. 

One implementation would be a binary string of heavy and light carts preceding the "payload" cart.  Given the nature of cart computing and the structure of the problem, 4-valued logic might be an obvious choice.

This is pretty much exactly what I was describing. Good job saying it in a way that people other than me understand

Making it four-valued is much more robust than the three I was working with, for sure. Just a tad more dwarfputing, which might be unnecessary - if you're heading farther out, the computer would never need to turn you around. You would be doing that after you disembarked at your destination, did stuff, and came back to the station. And if you're heading in, unless you want to stop short of the mountainhome, you wouldn't need any data to be processed at all, just have the rails switch into an orientation that facilitates your travel back to the mountainhome.

Edit: Actually, the way I described it, all the minecarts would be behind you once you reach your destination, still in order. So when you arrive at your destination station, you could just be sent off into a simple slipway...that launches you out in reverse when you want to leave again, back to the mountainhome. Assuming you don't want to go anywhere besides that one destination, and assuming that you intend on a return journey. That's the limitation of the binary tree approach.

Edit 2: The OP is going to be so confused by what happened to their thread

[Graknorke]

you're focusing too much on computer science/mathematics.

Come on, you can't have blasphemy like that if you want to make a megamegaproject.

[omega_dwarf]

Maybe I'm being too simple here, but what if you forgo the fancy dwarfputing and just have a weighted cart line that triggers the appropriate pressure plate for the main cart line to disembark at? Add a second weighted cart with perpendicular rail lines and you have a Cartesian coordinate system.

You'd still need a bit of logic to accept only the signal of the first weighted cart, unless the second weighted cart travels right in front of the passenger cart or in its own dedicated lane. Actually, you could throw both the weighted carts in front of the passenger cart, as long as you accept only the first cart (i.e., there's an extra plate that disengages the weight check for a bit whenever a cart passes.) The first cart is removed from the track after the axis switch, or maybe sent behind the passenger so they can have it for additional trips.

You know, this is actually a really good idea. Since we don't have diagonal rails in DF anyway (I'm definitely not thinking enviously of...that other game, no way ), there's no advantage to having non-grid paths. Travel times are the same whether you choose a "boxy" or "smooth" rail plan, so long as you never move away from your target while you're traveling.

This way does require an additional check at every station while you're travelling parallel to (or on) the first axis, compared to the method I suggested (since you don't have a simple "left/right" cart when you switch axes, you'll have to do some logic to see if the grid coordinate is to the left or right of the station [assuming the first axis is up/down, second is left/right.])

Or you could have three carts (or four, if you want to be fancy) instead of two to nullify what I just said. One finely-tuned cart weight to indicate the distance that should be traveled, and another cart that encodes whether the coordinate is up or down (left or right in the second pair) relative to the starting position, in each pair. So either one pair of carts for the position on each axis, or you handle the orientation on the starting axis back at the station, and only use a pair for the second axis.

(Further simiplification, with major benefits and drawbacks):

Spoiler (click to show/hide)

You could interpret that as having the origin at the mountainhome and the left/right or up/down carts as absolute positives and negatives on the coordinates. If you did that, you would only need stations able to make left/right decisions along the first axis itself (a north/south line running through the mountainhome.) All other stations would just be checking "does the finely-tuned cart match the distance that this station is coded for?"

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 wanted to be able to go anywhere from anywhere, without hitting up the mountainhome first, there would be a huge advantage in construction to using the three-cart system, since each station wouldn't have to "think" about whether to send the passenger and the second distance-coding cart left or right (east or west, assuming the first axis of travel is always north/south.)

The coordinate system would need to be all positive numbers that way, though, since each station you pass wouldn't know "how far to the left I am" compared to the (arbitrary) station of departure. So the origin would have to be up in some corner of the grid, and you wouldn't be able to expand the system past where you placed that corner. (Unless you left room to expand by not actually building the origin corner, just a piece of the grid farther out and centered around the mountainhome [which, for clarity, still isn't at the origin of the grid.]) But if you need to expand it beyond the grid (in any direction; you're also limited by the distinct weights you can make), you can just start a new grid and separate rail system that shares a border with the original. Urist disembarks and jumps trains, then keeps going.

I think this is the best approach so far (ease for builder and passenger.) [It also finds the fastest path because, again, there's no advantage to diagonals, and this method doesn't require you to go out of your way to the mountainhome - just sends you straight there, one direction, then the other.]