- v50 information can now be added to pages in the main namespace. v0.47 information can still be found in the DF2014 namespace. See here for more details on the new versioning policy.
- Use this page to report any issues related to the migration.
Difference between revisions of "40d Talk:Fluid logic"
Squirrelloid (talk | contribs) |
Squirrelloid (talk | contribs) (→Help: Time Keeping, a counting problem: 'steps' in a day/month/year?) |
||
Line 50: | Line 50: | ||
:--[[User:Squirrelloid|Squirrelloid]] 13:00, 31 October 2009 (UTC) | :--[[User:Squirrelloid|Squirrelloid]] 13:00, 31 October 2009 (UTC) | ||
+ | |||
+ | ::Relevant additional question - Does anyone know how many 'steps' there are in a DF day? Month? Year? --[[User:Squirrelloid|Squirrelloid]] 13:19, 31 October 2009 (UTC) |
Revision as of 13:19, 31 October 2009
Can anyone explain how the XOR of the Mechanical-Fluid Gates work? I don´t seem to understand it...--Kami 17:34, 12 October 2009 (UTC)
- Sure. It assumes the pump is powered by a windmill on a map with strong wind (40 power). If neither input is on, the power is only transfered to the southeast gear assembly (total of 10 power consumed). If only the yellow gear assembly is connected (considered to be a logic high), then every gear assembly but the green input is powered (30 power in gear assys, 10 power for the pump). If only the green assembly is connected, the yellow assy and the white one to the north are both disconnected (25 power in gear assys, 10 for the pump). But if both assys are connected, the entire thing requires 45 power to work, and nothing turns. Easily modifiable with a huge number of gears for water wheel power. I believe a windmill farm would be necessary on a map with 20 or 10 wind. -Arrkhal 20:27, 12 October 2009 (UTC)
- Now I understand. But I think this should be mentioned anywhere. ^^
By the way, I don´t think this is a good concept. You´ll have to empower every single part of your "computer" by itself. And you´ll have to calculate your power well and build tons of useless gears. Complex logic will lead you to a state you can´t handle it anymore... I´ll think of it. --Kami 13:31, 13 October 2009 (UTC)- Probably not the best system, yeah. I was mainly just trying to think of a system which destroys a minimum amount of water, to be able to compute on a map with only murky pools. You may want to look at the mechanical logic page, too. That's where I got the XOR design from. If there's a better way to make an XOR with gears and axles, I can't think of it. -Arrkhal 23:36, 13 October 2009 (UTC)
- Just hook the inputs up to the same gear- gear assemblies toggle. You'll need to "invert" the pressure plate, though, since hooking up two levers to a gear assembly leaves them both off and the power on. With one lever pulled, the power's off, and with both it's back on. 23:34, 14 October 2009 (UTC)
- I think this is more mechanical computing than water computing, because in this case the logic lies within the gears and power. The water is only used to convert power into lever signals.
But I see the destruction of water is a problem you will have to solve if you have limited ressources. Did you ever consider to use hatches to control the flow of water? This would require more pumping, but could work?
An XOR with gears that is not based on underpovering can be made the same way you did for the infinite flow gates above. A XOR B = (A AND NOT B) OR (NOT A AND B) | A XNOR B = (A AND B) OR (NOT A and NOT B)
Oh, and here is an short example of computing I tested: http://mkv25.net/dfma/movie-1745-dwarfputerv01 --Kami 10:46, 15 October 2009 (UTC)
- Probably not the best system, yeah. I was mainly just trying to think of a system which destroys a minimum amount of water, to be able to compute on a map with only murky pools. You may want to look at the mechanical logic page, too. That's where I got the XOR design from. If there's a better way to make an XOR with gears and axles, I can't think of it. -Arrkhal 23:36, 13 October 2009 (UTC)
- Now I understand. But I think this should be mentioned anywhere. ^^
Help: Time Keeping, a counting problem
Ok, I am well-and-truly crazy, but I want to make a DF clock. One which accurately tracks days and month. (Additional awesome for tracking 'hours' within days, but that would be crazy). So, i think i know what to do conceptually, but i'm having problems making the leap from concept to a concept of execution in the game. (Part of this certainly results from my having had problems getting pressure plates to work properly before)
Thoughts:
So, there's going to be some minimal repeater, which toggles with a frequency of f. Each toggle of the repeater fills a 1x1 area with 7/7 water, or dumps that water.
The resevoir into which the water is dumped with each toggle is 7x1, causing it to fill to 1/7 everywhere the first time, 2/7 the second, etc... When it reaches 7/7 it dumps...
...into a 7x7, which similarly fills up to 7/7 over 7 dumps of the second level system.
Issues: How do i ensure perfect draining of a 1x7 area in relatively short time? A 7x7 area? How many iterations / what final depth on last iteration do i need to count out a day/month? (Ie, how short or long does a repeater tend to run per repeat, and what multiple of that is sufficient to count out a month?)
Biggest issue: It must work slowly enough to allow draining yet quickly enough to permit accurate counting of days.
I suppose after the 1x7 it could trigger another 1x1 repeater, and i could just parallelize that way, with each repeater being triggered slower and slower. The 7x1 could also be a 6x1 column with a 1x2 top layer (7 cubes, 6 vertical, 7th needs a floor to measure depth), which would help with rapid draining, but will it be rapid enough?
So, any thoughts? How can I build this and not go crazy?
--Squirrelloid 09:45, 31 October 2009 (UTC)
This has the potential to become the greatest dwarfputer ever!
Here are some suggestions:
- If you fill an area with 1/7 water you will encounter a problem with evaporation, especially when it takes more time until you add more water for example when you´re counting months.
- Possible solution: You could work with multiple of 2/7 water or use some system that adds an additional 1/7 water per field for the first time.
- You can´t totally drain an area, even it goes -1 z-level through a whole at one side a 1/7 portion of water will always stay there. One possibility would be to use a hatch or a bridge, but then you can´t use a pressure plate as trigger.
- Imagination: 6/7 would be perfect if you have an 1x3 area and want to use multiple of 2/7 water.
- Don´t use larger areas for each level like you suggested (1 7 43 ...). Use multiple small components connected via pressure plate in a row.
- Suggest to work with components like others used for their alculation machines. Using the height of water is not the the best idea comparing to pure binary logic with filled/not filled.
- I think the best repeater would be a that goblin one.
--Kami 11:18, 31 October 2009 (UTC)
- Ok, big first issue: I made a rough build of a single component as i proposed, just to see if it would work at all. It doesn't. For some reason I can't have a single pressure plate open the floodgates *and* close the hatches? Am i misunderstanding something about the way pressure plates work?
- So, i'm filling with pressurized water, meaning the 1x1 component goes to 7/7 instantaneously. This means it should open the floodgate to drain the 1x1 and close the hatch to prevent additional fill of the 1x1 at the same time. Flood gate opens fine but the hatch refuses to close... What the heck am i doing wrong? Shouldn't the pressure plate toggle both hatches and floodgates to the opposite of their current positions?
- If it toggles multiple times, maybe i could just open and close components with a 3/7-4/7 signal and it could just repeatedly toggle the components at some frequency that could be counted with other components... of course, then i need to time every component separately - now that sounds like a nightmare.
- This would be easier if screw pumps didn't create water, so their supply was actually limited by how much had gone in...
- Issue with lots of binary components - that sounds a lot more space intensive. It does, however, sound more foolproof.
- --Squirrelloid 13:00, 31 October 2009 (UTC)
- Relevant additional question - Does anyone know how many 'steps' there are in a DF day? Month? Year? --Squirrelloid 13:19, 31 October 2009 (UTC)