Print

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

[Exponent]

If tracks will need to be laid out in lines, will constructed rails function tilewise like walls and floors, or will they work more like axles and bridges?

I don't remember the exact statements, but it sounded to me quite conclusively that constructed rails would be function very similarly to constructed floors.  That would still allow stops and rollers to be built on top of them, along with other ordinary objects, like doors and floodgates.  I would speculate that they would also function as a normal floor for walking purposes, but who knows, maybe not?

[MaximumZero]

Grazi, Footkerchief.

[NW_Kohaku]

I wonder what will make us to build rails at all? Why not to build bridges, a few tiles from 1 stone, everywhere instead? It's faster and cheaper.

Which brings the question.

If tracks will need to be laid out in lines, will constructed rails function tilewise like walls and floors, or will they work more like axles and bridges?

One of the things Toady has been saying is that you can engrave rails directly into the floor.  As in, it costs you nothing but time from an engraver. 

Especially if moving stones around becomes harder (and requires, say, rails to do), then that alone would make not needing to move around stones to make bridges valuable. 

Also,

Yeah, the track connections are between the tiles you designate, and it only lets you designate 1xN and Nx1 rectangles.  Ramps are a little weird -- you have to include the ramp wall or the ramp space when doing the floor above to ensure the connection is placed, but you can tell from the designation symbols how you've done.  You can draw designations through other designations to make 4 way intersections, and designating on top of an active job updates everything correctly.

In order to preserve directionality, they have to be designated multiple segments at a time, so they are designated in the same way walls, bridges, and roads are designated now.  That means there's nothing hypothetically stopping a "1 stone for 3 tiles of rail" system.

Of course, if we have metal rails as well as stone ones, that implies that there must be some reason for the physical property differences to matter. 

That was why there was talk earlier of things like adamantine rails having almost no friction, and allowing more speed, or else rails requiring maintenance, as that's the only rational reasoning for using metals like steel in rails.

[Askot Bokbondeler]

Of course, if we have metal rails as well as stone ones, that implies that there must be some reason for the physical property differences to matter.

no it doesnt. metal rails are probably as different from stone rails as metal constructed walls are different from stone constructed walls

[NW_Kohaku]

Of course, if we have metal rails as well as stone ones, that implies that there must be some reason for the physical property differences to matter.

no it doesnt. metal rails are probably as different from stone rails as metal constructed walls are different from stone constructed walls

And once we have sieges that involve siege engines that can destroy walls, or we have sapping where people constantly talk about how metal walls would be more difficult to destroy...

[Askot Bokbondeler]

i'm certainly hoping for that, but not expecting it anytime soon. i don't think a future goal implies anything about a feature that is being implemented for the next version. i'm figuring toady just thought about what material it might make sense to build tracks out of, or simply enabled any construction material. hell, i'm expecting soap bars to be usable

[Miuramir]

That might be the way you guys play, but it's not the way I play.  And I'm not so strange that nobody else plays the same way I do, either. 

Do you pretty much just wing it? cause thats about what i do.

You can't just wing it when you are trying to build a cartputer, though.  Unreliability kills the whole point of the processor. 

I take a somewhat different view, perhaps because I was involved with a real-world megaproject to build a seemingly impossible computer with limited resources and a bunch of idlers (System X), and keep up somewhat with what companies like Google, Amazon, Netflix, etc. are doing.  Once you start building large enough systems, parts fail... not just occasionally, but frequently.  Some are extremely random, like cosmic ray hits to memory; other are more predictable with enough data, like hard drive failure rate curves; other are a serious wildcard, like natural disasters and other people's processes in the same data center going nuts in a way that causes collateral damage.  Designing your system so that it handles minor and routine failures as a routine event, and degrades gracefully under pressure from more extreme events, is a major part of system design. 

"The best way to avoid failure is to fail constantly."  In one particularly interesting example, Netflix has managed to weather problems with AWS far better than other companies, because they designed with failure in mind.  Netflix Tech Blog post:

One of the first systems our engineers built in AWS is called the Chaos Monkey. The Chaos Monkey’s job is to randomly kill instances and services within our architecture. If we aren’t constantly testing our ability to succeed despite failure, then it isn’t likely to work when it matters most – in the event of an unexpected outage.

Also worth reading: Blog post from StackExchange
Translated to DF, they deliberately set up the equivalent of a tantruming dwarf in their control center, breaking floodgates, pulling levers, and generally being a pain... and designed the system to work *anyway*.  That's what real system design is; not trying to get to some OCD world of perfection; because not only will you never actually get there, but your system will be brittle when (not if) failure does come. 

[NW_Kohaku]

That's what real system design is; not trying to get to some OCD world of perfection; because not only will you never actually get there, but your system will be brittle when (not if) failure does come.

The thing about real-life systems is, however, that you can generally just make things cheap and small and unreliable, so that you can just rely upon having enough back-ups in your RAID to compensate for the failure rate. 

In future technologies, people have speculated about specially grown molecular computers that basically have a fail rate of 70% or so, but compensate by just testing the paths that actually work, and shutting down the others. 

In DF, however, lacking those black boxes I was talking about earlier, every single logic gate is going to take up multiple tiles and have an FPS cost associated with every moving piece.  There's only so much fortress you can build without having the whole thing come to a glacial crawl. In fact, there's only so much fortress you can build, period, without 64 bit memory.

Ultimately, it's not much of a cartputer at all if you have to manually order your dwarves to move the actual bits around.  Somehow rigging a start/stop that works automatically without a dwarf having to manually run up and push is the lowest necessary component of an automated system.

[Miuramir]

Ultimately, it's not much of a cartputer at all if you have to manually order your dwarves to move the actual bits around.  Somehow rigging a start/stop that works automatically without a dwarf having to manually run up and push is the lowest necessary component of an automated system.

My personal favorite option is to have the "rollers" take 4 states: powered forward, neutral (aka free-spinning), powered backward, and locked (aka brakes).  Powered forward & backward are obvious, neutral would have only a little more friction than a normal tile, and locked would add a lot of friction.  But DF tends to handle mechanically linked things as having only two possible states; within that limitation it is trickier. 

I think you can partially handle it by having two mechanism-controlled states, "engaged" and "freewheel"; plus the presence or absence of (enough) gear-shaft power.  If "engaged" && "powered", it accelerates; if "engaged" && "no/insufficient power" it is locked and acts as brakes; if "freewheel" it applies neither acceleration nor friction (and consumes only the power of an ordinary gear, rather than however much power the acceleration function costs).  The default option, if not lever (etc) linked, would be "engaged", like the default state for a floodgate is closed.  This should mesh well with the way waterwheels and existing mechanical logic seems to operate.  To use, if you want the cart to sail past the point without stopping, you'd set the mechanism to "freewheel" (off).  If you wanted the cart to stop, you'd set the mechanism to "engaged" (on), but cut the power supply at some upstream point; unless the cart has way too much momentum it would come to stop on the rollers.  You then do whatever you need, and when you want to get it moving, (re)apply power to the rollers and it will get the cart moving again.  Suitable design to handle carts that are out-of-parameters (too fast, too heavy, etc.) should be doable with more work, parts and space, given the above.  This is already drifting into suggestions territory rather than speculation on announced systems, so I'll close this out.

[Arkenstone]

I've been doing some thinking lately, and I don't believe we need anything new that hasn't been mentioned yet provided the things that do work a certain way.

If it's possible to build bridges on top of tracks after all, then we already have the means to build switch junctions; I've already designed a 'cloverleaf' intersection that would fit in a 6x6 room using 8 1-tile retracting bridges.  But even if not, we still can build rail splits by having pits covered by bridges instead; such that carts will fall onto other rails.


As for mechanical logic, I've postulated about using the cart bumping mechanics and rollers to make cart-based logic systems and even an auto-launch.

First, a simple clock pulse can be made with a 3-tile long straight with walls on each end.  Each side has a roller facing towards the center, where a pressure plate sits.  As long as the rollers are powered, a cart on this track will go back and forth and output a continuous pulse.

A similar setup might work for an SR NAND-equivilent: instead of one cart, two carts of different weights are placed on the line, and power to the rollers are controlled by the inputs.  Only one of the two carts is the right weight to trigger the pressure plate, so when the apposing roller is activated the other cart bumps it off.  While the possibility depends heavily on the (currently unknown) specifics of minecart physics, I am optimistic that with enough tweaking this setup could be made into a very compact JK flip-flop.

To try and catch speedy carts, I've thought of two kinds of brakes.  One is for high speed, and consists of several rollers pointing in the direction of deccelleration.  In between are the 'fake' T junctions; eventually the cart is pushed backwards by one and is sent down the parallel track to the other side of the brake.  The other brake is for places carts shouldn't be going too fast, but you don't want to risk it.  After catching them flying off a corner, it 'drops' them into a 1x1 hole to stop their momentum, then drops them again onto rollers which push it off at a more reasonable speed.

The last thing I had thought worthy of mention is an automatic cart launch system.  The trick would be to have a cart on a roller directly behind the stop: is this roller were to be activated for exactly one tick, then it might push the cart out without itself moving off its tile.  If this is not possible, then the best bet I would think would be to build the stop next to a roller and try to push the cart out of station with the next one in line.


Overall, I don't see anything that can't be done with the tools we currently have.

[NW_Kohaku]

That's assuming cart bumping works reliably, however, and doesn't just cause derails. 

I think a setup where unpowered accelerators act as stops is not too hard to include, and worth having. 

Pressure plates linked into accelerators so that you can directly measure when something is sitting on an accelerator stop is convenient, even if not necessary.  It is something that can be worked around with additional mechanics, but if we don't need to do that sort of thing, then it's best to just have a tool that just performs that function straight-up.  Like I said before, every moving part in the system is another chunk of fortress real estate and hit to FPS. 

It's like how we can do things with fluid mechanics, but if we could just have a "is this gear powered" sensor that would work like a pressure plate does in triggering other mechanics, then we could construct entirely mechanism logic processors that work significantly faster than fluid logic systems in more compact space and with significantly less FPS drag.  It's the difference between one nut making a working 8-bit processor and a nut making a 16-bit processor.  (Which they did in Minecraft, because it has tools specifically designed to make basic processing possible.)

[Arkenstone]

Hey, I didn't say I didn't agree that it wouldn't be nice to have all those things; only that they weren't neccessary. 

I'd order every dwarf in my fortress down an addy tube in the buff (and win) if I thought it could get me a gear-controled lever.

[dree12]

I've been thinking that there might be a now-possible repeater setup:

x-axis is Z, y-axis is X

Code: [Select]

▓▓▓▓▓▓▓
▓▓▓▓▓▓▓
▓▓╔.▓╔▓
▓▓▓r▲▓▓
▓▓▓☼▓▓▓
r: roller to the right, pressure plate activates on cart and sends signal
The point is that the roller speeds the cart up until it reaches its destination above the starting z-level, which by then has disappeared. So the cart falls through the open space and speeds up again from the roller. This should be low power and efficient (not to mention with a low minimum speed and high degree of customizability), no?

[NW_Kohaku]

I've been thinking that there might be a now-possible repeater setup:

Or you could just make a cart that goes around a track with accelerators and have a pressure plate at timed intervals. 

Of course, the problem with the pressure plates is that you need to keep the cart ON the plate for 100 ticks to make the pressure plate reset properly.

[Chagen46]

I love how the release with minecarts hasnt't even been released and we're ALREADY trying to snap the physics in half.