Editing User talk:Hussell

== Assorted Devices ==

In the machines you've built, how does the water drop below 7/7 when input cuts off? [[User:VengefulDonut|VengefulDonut]] 14:40, 9 November 2009 (UTC)

Either it doesn't, because the 7/7 water is deliberately trapped in order to keep the pressure plate from sending a signal, or a door opens to allow the 7/7 water to spread into two or more squares, lowering it enough to trigger a change. Closing doors annihilate any water in their squares. [[User:Hussell|Hussell]] 14:48, 9 November 2009 (UTC)

:Oh, I see. I was thrown off since you have the drainage doors on the same side as the input control doors. This seems like it could cause unnecessary complications. In your [[User:Hussell/DataLatch|data latch]], for example, you will need to do some extra work to get it running for the first time since the closed drainage doors will prevent any water from triggering the yellow and cyan pressure plates. It seems this initialization problem could be avoided by placing the yellow and cyan doors to the right of the plates. [[User:VengefulDonut|VengefulDonut]] 23:03, 9 November 2009 (UTC)

:I'm aware that it's awkward to get the things running the first time. It's a disadvantage of using doors for everything. Unfortunately, it seems to be an unavoidable disadvantage. In the Data Latch, if the changes you suggest are made, then the output signals will both go to CLOSED while the clock signal is off if the data signal turns on and off. Even if the plate trigger threshold is lowered, turning the data signal on and off would eventually annihilate enough water to send both outputs to the CLOSED state. [[User:Hussell|Hussell]] 00:52, 10 November 2009 (UTC)

----
Bro, you should try some gear toggles.  They are instant, I think, and toggle.  Also, the pumps may actually only check for power every so ofton. Maybe this is the delay.--[[User:Zchris13|Zchris13]] 17:15, 13 November 2009 (UTC)
Good luck.

:The gear toggles do indeed toggle instantly. However, although logic can be done with power transmission, ultimately power only affects screw pumps and millstones, while pressure plates and levers affect a long [[Lever#On.2FOff_states|list]] of things. So a screw pump pumping onto a pressure plate will almost certainly have to be involved if one intends to use gears. My testing has shown conclusively that a screw pump continues to pump for 50 steps after losing power. This is true for both manual and automatic pumps. One way to see this is that the screw pump animation (which cycles between two characters every 25 steps, apparently using a modulo of a global time counter) changes to its inactive state exactly 50 steps after power is removed, regardless of when the animation would normally change. In addition to this, my tests have shown that water continues to be pumped for exactly 50 steps after power is lost, and no longer. I encourage you to do your own testing if you aren't convinced. Although I'm totally convinced, it would probably be a good idea for someone else to confirm my observations before the wiki article is changed. --[[User:Hussell|Hussell]] 18:38, 13 November 2009 (UTC)

Congrats on the repeater. And what you found out about stacked pumps can be used to make repeaters of very specific durations (eg: 120 divides into 1200). Based on the 100 tick pressure plate limitation, it seems that the ideal clock would output 100 ON / 100 OFF. [[User:VengefulDonut|VengefulDonut]] 15:56, 14 November 2009 (UTC)
----
Why don't you put it on the fluid logic page? --[[User:Kami|Kami]] 17:37, 21 November 2009 (UTC)

Still in the testing stage. A couple of my key dwarfs were injured recently, and it seems it'll be a few game-years before they recuperate and I can proceed. Meanwhile, I'm taking care of some neglected fortress-improvement projects. Also, it's not absolutely clear to me that these door-based contraptions are superior to the bridge-and-floodgate system, since the change in delay isn't that great, and it's a lot easier to synchronize bridges and floodgates. If there were no delay in pressure plate deactivation, it would be no contest, but as it is, some state transitions take a couple hundred steps, while others happen almost instantly. This can lead to problems in larger circuits if one isn't extremely careful. I've already had to revise several of my designs, and there are still some problems I'm aware of, but haven't figured out how to solve. --[[User:Hussell|Hussell]] 15:06, 22 November 2009 (UTC)

== Doodles ==

I think it would be significantly easier for you if you used used [[template:diagram]] rather than [[template:RT]] for your designs. Here's an example using your latch:
{{template:diagram|spaces=no|
      █      █      █      ██
[#00A]≈[#0f0]┼[#ff0]┼[#0ff]^█
      █      █      █      ██
[#00A]≈[#f00]┼[#0ff]┼[#ff0]^█
      █      █      █      ██
}}
[[User:VengefulDonut|VengefulDonut]] 13:12, 1 December 2009 (UTC)

Thanks for the tip; I hadn't known this template existed. I notice armor stands get interpreted as newlines. Should the templates be modified to use one of the [[Character_set#No_known_use|"no known use" characters]] for newlines?

I'm getting slightly better looking results with the RT tables than with Diagram. A Diagram is a '''lot''' simpler to set up though, and I appreciate that. I bet Diagram could be tweaked until it produces a table just as good. Compare this RT Table:
{| cellspacing=0 style="background-color: #888"
|-
|{{888}}
|{{888}}
|{{888}}
|{{888}}
|{{888}}
|-
|{{H2O}}
|{{RT0|┼|#0F0}}
|{{RT0|^|#F0F}}
|{{RT0|┼|#F00}}
|{{888}}
|-
|{{888}}
|{{888}}
|{{888}}
|{{888}}
|{{888}}
|}
To this Diagram:
{{diagram|spaces=no|color=#888|
█████
[#008]≈[#0F0]┼[#F0F]^[#F00]┼█
█████}}

The characters in Diagram poke over the edges of their background.

[[User:Hussell|Hussell]] 17:29, 1 December 2009 (UTC)

:Yeah. My typesetting leaves something to be desired. I wish I could just carry over the setup from RT verbatim, but RT wastefully packs lots of code into every single cell. If you have experience making things look pretty in web pages, please take a crack at it. All I need for reference is one table that looks nice and doesn't fill every individual cell with lots of style info. [[User:VengefulDonut|VengefulDonut]] 00:35, 2 December 2009 (UTC)


Alright, how about this:
{| border=0 cellpadding=1 cellspacing=0 style=line-height:1.2em;font-family:monospace;font-size:large;font-weight:bold;color:#888;background-color:#888
|-
|█
|█
|█
|█
|█
|- style=background-color:#000
|style=color:#008|≈
|style=color:#0f0|┼
|style=color:#f0f|^
|style=color:#f00|┼
|style=background-color:#888|█
|-
|█
|█
|█
|█
|█
|}
I choose to let the viewer use his/her default monospace font. If you choose to make Courier New the default font, a line-height of 1.1em will look good, but you should be aware that if the viewer doesn't have Courier New installed, several common monospace fonts have characters that are 1.2em in height, and thus will stick out of the background cell with a line-height of 1.1em. You should be able to vary the font-family, font-size, and font-weight of this setup quite a lot without breaking anything, as long as you don't change the line-height, cellpadding and cellspacing. Blank tiles (walls) should have a background-color equal to the foreground color (which is how RT manages it). Some sort of logic for doing this automatically in Diagram might be appropriate, since it's annoying to have a default foreground color equal to the default background color, even when walls are the most common tile.

I note, to my chagrin, that even this table is more compact than using RT. Apparently I picked the worst possible option for my diagrams. I did cheat a bit by putting style on a row. It might be nice if that were possible using the Diagram template too. Maybe when a color appears at the end of a row, it should apply to the entire row? The Diagram template also currently puts in color and background-color style on every table cell, even when it's blank (Try "View Page Source" on this page.) You should be able to get rid of that with use of #ifeq. Come to think of it, is there a way to shorten the color specifications? Some way to change a background color without changing the foreground color, and getting rid of the mandatory "#" symbol seems like a good idea. Maybe "!rgb" for foreground, and "?rgb" for background, since status icons are unlikely to appear in diagrams. "!rrggbb" and "?rrggbb" variants should be allowed too. Possibly color names too, although that would mean keeping the number sign to identify numeric color codes.

It would be nice if "spaces=no" were the default, since I can't think of any reason to ever use spaces in a dwarf fortress diagram.

If all my suggestions were taken (except color names), the above table could be created like this:
<pre>{{diagram|color=888|
    █    █    █    ██
!008≈!0f0┼!f0f^!f00┼█
    █    █    █    ██}}</pre>
Without the logic for dealing with blank tiles, and with color names, it might be:
<pre>{{diagram|color=gray|background=gray|
     █     █     █     █     █
!#008≈!#0f0┼!#f0f^!#f00┼?gray█?black
     █     █     █     █     █}}</pre>
Hmm. Maybe color changes should come ''after'' the tile being altered, so that row colors can be at the front?

Maybe I should make a version of Diagram myself. But not tonight.

[[User:Hussell|Hussell]] 05:46, 2 December 2009 (UTC)

Now that I'm more awake, I realize having color names is impossible without brackets of some sort so the parser can tell where the name ends and the next diagram character begins.

I've created a possible new version of Diagram at [[Template:Diagram/sandbox]]. You can test it at [[Template:Diagram/testcases]], and discuss it further on the talk page. Currently only three digit colors are supported, but everything else is in.

[[User:Hussell|Hussell]] 18:15, 2 December 2009 (UTC)

:The table design seems a little off. Certain types of tiles don't line up. While handling █ as a special case works, we can't attack the fuzzy ▓▒░ tiles and the wall tiles using the background color trick. For those to look good, they really have to stick end to end the way they do in DF. I like the idea of coloring an entire row. I was hesitant to add things like that before because I was wary that many regex passes would be more expensive, but it seems clear now that their cost for this use almost negligible. 
:Also, as far as colors go, I've been toying with the idea of putting DF colors in there rather than HTML colors. Most of the necessary tools for that have already been built. Does that seem too restrictive? [[User:VengefulDonut|VengefulDonut]] 02:15, 3 December 2009 (UTC)
@@ Line 120: / Line 120: @@
 :The table design seems a little off. Certain types of tiles don't line up. While handling █ as a special case works, we can't attack the fuzzy ▓▒░ tiles and the wall tiles using the background color trick. For those to look good, they really have to stick end to end the way they do in DF. I like the idea of coloring an entire row. I was hesitant to add things like that before because I was wary that many regex passes would be more expensive, but it seems clear now that their cost for this use almost negligible.
 :Also, as far as colors go, I've been toying with the idea of putting DF colors in there rather than HTML colors. Most of the necessary tools for that have already been built. Does that seem too restrictive? [[User:VengefulDonut|VengefulDonut]] 02:15, 3 December 2009 (UTC)
-==A bit of appreciation==
-Not sure if you're still active at all, but I just wanted to say that in my mind you're one of the heroes of DF engineering.  Thanks for sharing all of your inventions and research. --[[User:Vasiln|Vasiln]] 00:03, 15 March 2012 (UTC)