40d Talk:Computing

I created this page because I think it's a very interesting part of the game for advanced players. I'm not at all familiar with creating wiki pages, so if someone else who was familiar with the concepts could write a section or two themselves, that would be grand. Right now I think it's been proven possible to create logical input and output gates using fluid dynamics, axles and gears, and even the movements of dwarves utilizing pressure plates.

It was on the 4th of Galena 1097 that the Fortress 'The Net of Skies' became self-aware. Panicked mechanics attempted to disengage the mechanisms, but the fortress interpreted this as an attack and designated all Dwarves as hostile... --WyldKarde 13:17, 23 November 2007 (EST)

A suggested component: The one-use lever.

ó _X_ ___ / = ramp X = door
#" ¯ /### " = bridge
#########

The lever has a Pull The Lever repeat job on it. The door only opens when access is required. Upon being pulled, the lever opens the bridge and drops the dwarf that pulled it. -- Zaratustra 14:56, 23 November 2007 (EST)

Problem detected: the lever doesn't obstruct, so the dwarf can be left hanging on the lever's tile.

I think we should strive to include an example of an NAND gate and/or a NOR gate for each style since that's the bare minimum for operation.--AlBorland 22:09, 23 November 2007 (EST)

Machine logic

The machine logic gates as they stand are incomplete. The inputs are levers, but the outputs are machine components. In order to connect a machine logic gate to another gate, the machine signal needs to be converted back into a lever signal. The only way I can see to do that is with a water tank, a pump, and a pressure plate. --Peristarkawan 12:38, 28 November 2007 (EST)

Anthills

Kudos to whoever mods ants to be trainable for borg machines... Hex anyone? :D N35t0r 20:28, 8 December 2007 (EST)

This would make that person my favoritest ever. --Geofferic 01:36, 9 December 2007 (EST)

Agreed. Madmadmadmage 15:13, 9 December 2007 (EST)

More specifically, Langton's ant...--Yrael_Talk^{11:04, 25 11 2024 (EDT)}

Fluid logic gates

Link to original information is at User:Madmadmadmage/Logic_Gates. Moved to clean up page.

Have you tested these at all? I translated your multi-level NOT gate into a form I could understand better after designing some gates myself, and looked at it. It doesn't look to me like it would work at all - First, water flows diagonally, so the water would just flow around the floodgate. Second, if water didn't flow diagonally, and you opened the floodgate because of an input signal, water from the reservoir would then hold the floodgate open by covering the pressure plate even if you shut off the input signal. You'd also need to do something other than just have the drain always open or you might not even trigger the pressure plate because it's draining too fast. --SL 19:17, 23 December 2007 (EST)

No, I did not test any of these. I forgot that water flows around corners; I usually work with straight passages and put my gates in places where it doesn't matter. I'll fix that. As for draining water, you're correct on one point: the water would drain off too fast to trigger the plates. It would drain out to one, so the part about it not draining out isn't a problem. The draining-too-fast problem can also be solved: set the plate to activate on any depth-two water. That would mean it would take a tiny bit longer to drain (although not much), but it would also make it open if any water at all were coming to the input. Additionally, minimizing delays would be very, very useful. Remember, these don't have to be all separated like I have them. You could design these with everything compressed into three-long channels (the minimum length of a NAND gate plus an input), which would greatly optimize performance. Maybe using something like an aquifer for the water source would also help. I'll have to build a fortress specifically to test fluid gates (translate as: dig through aquifer). Give me a few weeks. Madmadmadmage 02:14, 27 December 2007 (EST)

I've finished my own logic gates now - designed, built, and tested them all. They transfer signals between gates using mechanisms rather than water flow, but use water internally for processing logic. In addition to the standard gates (NOT, AND, OR, XOR, NAND, NOR), I've also made repeaters (repeatedly toggle two output signals) and memory gates (one input signal sets the gate's output to ON, the other input signal resets it to OFF - this is useful to replace one-use pressure plates with resettable versions). They only need to be built on top of a murky pool (with water in it), or an aquifer, brook, stream, river, dwarf-made cistern, whatever, and require power for one or two pumps each. I've posted them here User:SL/Logic_Gates for now, with all the information needed to build and use them, and advice on doing so. --SL 13:30, 4 January 2008 (EST)

These look really good to me. Since I rarely use screw pumps, I never even thought of using using them. They're slower to build than simple channels, but they're faster, more efficient, and far more predictable. Good idea. Secondarily, I'm moving my stuff to another page to make everything neater. Links to User:Madmadmadmage/Logic_Gates here and at the top of the section. Madmadmadmage 20:19, 4 January 2008 (EST)

Practical applications

One-way door

Hi! I'm new here and I am not sure where to put this, but I thought that it may be helpful, and it could use some refinement, and I couldn't find it anywhere else...

I noticed when trying to stop my civilians from having fun that if I locked the door whenever a dwarf was about to escape that they would find something else to do and give up on clearing that trap... While the dwarves outside generally just mill about waiting for the doors to open on account of having nothing else to do...

So I made a door which closes whenever a dwarf walks up to it from one side, and has a lever to keep it open regardless...

The one-way door:

#  - wall
D  - door
R  - bottom of ramp
-> - screw pump (west to east)
<- - east to west
_  - open space
o  - vertical axle
W  - unlimited water supply

1 - door connected to plate 1
2 - lever connected to door 2
3 - pressure plates connected to door 3, triggered by friendly dwarves(weight6)
---------------------------
################
2 D3333333331  D
  D3333333331  D
################

This is my current mechanism(lowest ground to highest ground):

1 - pressure plate connected to doors 1, triggered by water depth 0-2
2 - door connected to lever 2
3 - door connected to pressure plates 3
---------------------------
#######
# R####
# #####
#     #
#######
---------------------------
#######___
## 123<-__
###D###___ ####
## <-_#     <-_W
###D###    ####
---------------------------
#######
###  o#
#######
##_->
#######
---------------------------

:it could probably be compressed into something more like this:
---------------------------
############
# 132<-_<-_W
############
---------------------------
############
#_-> o _o  #
############

I have two requests, firstly, could this please be formatted and moved to somewhere good. And also, would someone please calculate how far a dwarven acrobat can travel before this will trigger, I have plates about 10 deep and some still get through...

Be advised that if anything is in the door when it is triggered it will remain open, to reset it the water must be removed from plate 1, this can be done by toggling lever 2 or persuading the dwarves to get off the plates 3...

RAM 04:33, 1 March 2009 (EST)

I'm not too keen on attempting to read your diagram, so here's what I would do to create a door which closes when a dwarf steps near it but stays constantly open when a lever is set.

Do tell me if you build it or need more details, optionally through #bay12games! --Zort 20:51, 12 May 2009 (UTC)

Base 8?

It says in Fluid Logic, "Fluid logic allows for computing in up to base 8." How does this work? Pressure plates cannot be made to distinguish between the 8 different water levels... Of course, you could use many counters in such a way as to simulate base 8, but base 2 would be more natural. --Zort 20:04, 11 May 2009 (UTC)

Pressure plates can distinguish between different levels, and can be set to go off at a range between any two numbers. They can also determine the difference between water and magma. It is at the bottom of the trigger menu. i2amroy 22:48, 11 May 2009

Exactly. They can detect a range between two given numbers, but, if a plate is set to 0-4, it cannot distinguish between 5, 6, or 7, levels of water. --Zort 12:20, 12 May 2009 (UTC)

One way that computing in base eight could be possible would be to have a pressure plate that triggered at 7-7 water and whenever you were going to 'add' something, you add a certain number of water 1/7's to that pressure plate. Then, whenever the pressure plate had 7/7 water, it would trigger the pump once, drawing out one 7/7 block of water. This could then activate another pressure plate that would add one 1/7 block of water to another pressure plate. This then means that each 1/7 of water in the second pressure area equals seven 1/7 blocks of water in the first. This allows adding in base eight. Highly complicated, but it still works. i2amroy 7:56 (MST), May 12 2009

Er, do you mean this:

Or do you mean a row of 8 pressure plates, each set to 1-1 (or some other level if I haven't thought about it enough)? This row of plates I would personally consider to be binary, I suppose it doesn't matter. Complexity is no obstacle for Dwarfputing. Zort 22:00, 12 May 2009 (UTC)

A practical use for borg logic

• I think that you could easily use borg logic in a (living) fortress to make a randomly changing labyrinth. Have dozens of plates strewed across the floor of your main feast hall; each is connected to a 'memory' switch that does something random in the labyrinth, and/or clears a different switch. Memory switches are very easily constructed should you have a chasm, where you can use gravity instead of a pump; said chasm is also often useful in populating said chasm with dangerous creatures. If you're clever enough to be able to build a 'clear all' switch, you can eventually make it so that the labyrinth inhabitants themselves are doing the computations for you! (something that's necessary if you want it to work in adventurer mode!)

--Arkenstone 12:50, 9 August 2009 (EST)

Water Clock Questions

I was thinking about creating a water clock for my fort so that I would not get surprised by the seasons every time. However, there are a few items that might pose a bit of a problem for me here (not the least of which is the fact that this would be my first attempt at water logic) so I thought I would ask around and see if anyone knew some answers that might help me out.

First, is the rate of water evaporation constant, or random? If it’s random, I’m not sure this would work. I’m pretty sure I would need a constant value for the rate at which my various reservoirs would fill up.

Second, does anyone know the number of steps in a season, how many steps it takes for a 6/7 tile of water to spread into two 3/7 tiles, and if steps are the right unit of measurement here?

Thirdly, there is no thirdly. That’s it. Thanks for any input in advance. Frewfrux 19:26, 17 November 2009 (UTC)

The rate of water evaporation is random. This is easy to test by filling a large area with 1/7 water and watching it evaporate - it doesn't evaporate nicely in the order it filled. I'm not sure about the answer to the second question. --LaVacaMorada 00:57, 18 November 2009 (UTC)

There's another article about creating a system of pumps that basically pumps one level of water (or maybe two?) constantly creating a never ending waterfall. It's apparently "neverending" because the pumps will pump the water faster then it can evaporate. This means, from my perspective, that the rate of water evaporation must have, at least, a minimum timeframe for it to exist before the code tests to see if it might evaporate (otherwise that neverending waterfall wouldn't work). And *that* means that it should be possible to fill at least small areas with water quickly enough that you don't need to worry about any evaporation rates. If that's true, then perhaps I can do this water clock thing after all. All I really need to figure out is the rate at which all this will happen. If there is anyone who's figured this out (I haven't seen the info I need anywhere in the wiki) then please let me know. Otherwise it will be a little while before I can do the needed tests. --Frewfrux 01:27, 1 December 2009 (UTC)

ROFLOL. I didn’t even see the calendar on the inventory screen until just this morning. Well, I guess I can still try for a water clock, but I will need to somehow make it useful. I think I could have it dump a tile worth of water over top of my magma vent at the start of spring each year. This will freeze the game due to a “cave in” (the produced obsidian floor falling to the bottom of the vent) and alert me that it’s time to get my winter-working dwarves inside before the start of the first season’s goblin ambushes. So I guess there is still a point to creating a water clock.

In case anyone was wondering I tested out the length of days in steps, and comparing my tests to what is mentioned on the article under “calendar”, I am fairly certain that the length of a day is 1200 steps.

Also, I think I’ve figured out how to not have to worry about evaporation; make use of water pressure. If I build all the logic gates for my clock on a low enough level, and have them be filled from a multi-level cistern fairly high up, then the water pressure should cause the water to spread fast enough that evaporation won’t be an issue. If it works the way I’m thinking it will, then there definitely is a way to build all these logic gates in a way that is dependable from a timing standpoint. --Frewfrux 17:16, 1 December 2009 (UTC)

Hmmmm. I think all this talk might be better handled on my user page. I will attempt to sort through it and figure out what to leave here and move the rest over at a later point. --Frewfrux 17:24, 1 December 2009 (UTC)

This is either a very good or a very bad idea.

Is Dwarf Fortress Turing complete? If so, some very interesting ideas are in order.

Starcraft is Turing complete - i'm guessing that makes DF so. (Admittedly, one can program Tetris in Starcraft, and that seems hard in DF... no wait, i think i could make something that was logically equivalent, but it would *suck* to play it). --Squirrelloid 22:24, 1 December 2009 (UTC)

I'd say it is turing complete, but it's hard to proof. (Btw, I like the tetris idea...) --Kami 09:05, 2 December 2009 (UTC)