Automation Update - Binary Adder

[GrindThisGame]

It's like a Japanese toilet. Very complicated    It would be easier just to weigh the "waste" but we can't do that (yet).

[manu_x32]

Ok so a couple of other issues, I had to make more modifications.

Counting to 30 doesn't work because after the 15th visit (29), the dupe may try to clean the toilet right away before going out.  Or might do the same if locked inside. So I had to put a door under the outhouse as a foundation, and open it a couple of secs after the dupe is done with his business to disable the outhouse so he can't clean it. 

That seems to work but the outhouse does not want to spawn any morb even after reloading the scene a couple of times.  Not sure if Klei changed that or if I'm doing something wrong? How many cycles before it spawn a morb, and does it still work if a dupe has started to clean it, like 10% cleaning maybe?

Here's the design that stops at 29 instead of 30 with a small delay to disable the outhouse.  And that opens the door to another outhouse so they don't make messes everywhere.    Changed the locking mechanism to a d-latch and added another dupe to make tests quicker.

When loading the scene, the automation system is not in a good state, bug or something, like it doesn't remember the last save state for automation items.  I fix it with the switch beside the wash basin (d-latch reset).

EDIT:  it finally spawned a morb. Not sure how many cycles it took, but it was long.

Automation gadgets testing.sav

[manu_x32]

Morbs don't seem to spawn if the door under the outhouse is opened (no foundation), so I close it with the far right bypass switch. And when a morb spawns, I reopen it and it falls right into the trap that's been waiting for it, ha ha! 

Tried the air creature trap, doesn't seem to work yet for pufts. 

[noisycat]

I am currently building 6-bit computer using automation gates and full-binary adder was the first thing I built. I'll post some screenshots when Im back from work. I managed to do serial-style adder, adding number from top inputs to bottom inputs and outputting value next to bottom input.

Edit: I chose this particular design (add inputs from top and bottom, output bottom) because I really need to conserve space as ReadOnly memory component has already used up 1/16th of the whole map (and RAM will probably be physically bigger, even if I half the storage size). On my paper it looks like register selectors will be ran next to ALU, so having this very inputs/output directions allows me to pack wires more tight. Remember, you can run 6 wires next to one another, untill they have to cross something on their way... Then you have to double the total width of the data bus.

The thing is my adder can be just stacked one next to another to get N-bit adder. The design is cell based, and one cell with CarryIN, A, B outputs CarryOUT and Value right to the next one. Not sure, but I think its 3-wide/5-high and you can stack as many as you want.

Better help me find something that can be used as input with my pc that can be handled with single click  

[manu_x32]

9 hours ago, noisycat said:

I am currently building 6-bit computer using automation gates and full-binary adder was the first thing I built. I'll post some screenshots when Im back from work. I managed to do serial-style adder, adding number from top inputs to bottom inputs and outputting value next to bottom input.

Edit: I chose this particular design (add inputs from top and bottom, output bottom) because I really need to conserve space as ReadOnly memory component has already used up 1/16th of the whole map (and RAM will probably be physically bigger, even if I half the storage size). On my paper it looks like register selectors will be ran next to ALU, so having this very inputs/output directions allows me to pack wires more tight. Remember, you can run 6 wires next to one another, untill they have to cross something on their way... Then you have to double the total width of the data bus.

The thing is my adder can be just stacked one next to another to get N-bit adder. The design is cell based, and one cell with CarryIN, A, B outputs CarryOUT and Value right to the next one. Not sure, but I think its 3-wide/5-high and you can stack as many as you want.

Better help me find something that can be used as input with my pc that can be handled with single click  

Very nice!  But before going too crazy, consider that the automation systems don't seem to store their state when saving a scene, so anything you build may not remember things properly when you reload the save. Unless you have a special trick for bypassing that. 

 

[manu_x32]

I tried making a simpler water counter version, but after many different attempts, it doesn't seem reliable. The shutoff valves will not always output the same amount when turning them on for a specific period of time like 1 or 2 secs through a buffer gate. It's often ok, but will fail enough times that it screws up the counter.

I even tried setting it to a minimum like 0.2 seconds, but its still not reliable, and at different game play speeds it also gives different results or won't trigger at all in slow speed if the buffer has too small of a value.  Sadly we also can't type values under 1 in the buffer gates, and fiddling with the slider is almost impossible, only 0.1 is easy to get since its the min.  So I had to put multiple buffer gates in a row all set to 0.1.

I was hoping to have a solution where you can easily set the amount of triggers to count, and the shutdown condition using the aqua sensor, and also have the current state be saved in the sav file, which is not the case with the binary counter.

So at this point it seems like the only reliable solution is the binary counter. Only downside is having to manually set it to the right state when loading the sav file. Water version was fun to try (pictures below). If anyone tries and succeeds with water (looking at you @Saturnus), please share!  

 

[noisycat]

13 hours ago, manu_x32 said:

Very nice!  But before going too crazy, consider that the automation systems don't seem to store their state when saving a scene, so anything you build may not remember things properly when you reload the save. Unless you have a special trick for bypassing that. 

 

It seems to me that my ROM is persistent between loads since I use switches there and those seem to remember their state. With ram the problem gets more real as I intend to use flipflops, however it's a marginal flaw if you cannot save/load during execution of the program. There are no guarantees about the internal state of the computer when you run your program, so even if the ram is flipping until set it shouldn't be a major problem.

Also, sorry for the lack of screenshots, I got home really late yesterday.

[Saturnus]

@manu_x32 Have you tried the reverse? Instead of shutting off water coming in. How about using one of the new small pumps, and control how long time it is on, ie. much water is pumped out?

A more practical solution would be to store each bit separately. This 1bit store set up should work.

There's a small liquid pump at the bottom. At the store command/trigger it will should be on or not for a short while. This pumps water to the top and out the vent where it is sensed (or not). This is your stored bit. Either there is water or there is not. At reset open the doors for a set time so the water flows to the bottom. The bit is reset.

An easy water counter can be done with the same set up with two side by side by exploiting the vent overpressuring. When the first room is full the sensor in the 2nd will go off as it over flows into this. Allow a bit of time, probably set sensor to something like 500kg or so to make sure the first room is fully over pressurized. Then you cut the supply to the overpressurized room and empty it thereby resetting it. The exact amount that is in the overpressurized room, the vent, and the shut off valve should be exactly the same each time.

[Saturnus]

On 08/11/2017 at 3:50 AM, manu_x32 said:

EDIT 2: nah, it doesn't work, as soon as I added a dupe, foundation was not valid anymore.

Strange. It works for me. If you want to make sure they don't clean the outhouse right away. Set it up with one way doors. First going the outhouse, 2nd goes to a room with a wash basin (or sink) set on priority 8-9, and then one door leading out. That way the dupes are forced to use the wash basin right after doing their business, overriding the cleaning priority.

If you're still having problems with missing foundation on the outhouse for some reason then with the above described set up you can also count wash basin visits instead.

If you want to make sure dupes don't wander around in your "morb generator". Fill the whole thing with chlorine gas. Dupe generally don't loiter in areas they can't breathe in, and that also eliminates the risk of someone deciding to disinfect the area randomly.

[noisycat]

So, here is my design for stackable adder as I described earlier. It seemed smaller to me when I was thinking about it, everything comes out at 5x8 plug-and-play adder-cell.

 

This picture explains a some of the logic. Two lower gates evaluate the output value bit and the top 4 evaluate carry. The out bit is set to "A xor B xor Carry", and the carry is set to "(A and B) or ((A or B) and Carry)". This was the concept I used after drawing the bit tables for adder cell with inputs "A, B, Carry" and outputs "Value, Carry" and trying to simplify them.

The first important idea was that output is set to 1 when there is uneven ammout of 1 in the input and to zero otherwise. The carry is set when there is at least two 1's in the input, and those ideas are complete on their own, I mean that they don't influence each other in any way. Value can be set just by xoring 3 values together in any order, since xoring anything with 1 will flip it, so we get as many flips as there are 1's in the input.

The carry bit is a bit (pun intended) more complex, since the most straightforward way to say "at least 2 out of 3" is checking all pairs: "(A and B) or (A and Carray) or (B and Carry)", that gives out a total of 5 gates. My next thought was that I can reduce the size by one gate by using "(A or B) and Carry" (2 gates) instead of separately checking A/Carry and B/Carry pairs. The "A and B" has to stay in case Carry is zero and both inputs are one, and both expressions have to be or'ed in the end because any of those situations "A and B" / "(A or B) and Carry" guarantees that we will set the carry.

As a bonus, here is my ROM design, about 40% of it visible here, it's just a simple selector that will output one of 64 6-bit numbers according to 6 bit input. I'll elaborate more on the internals after Im finished with this project XD Actually, the bigger it gets the more crashes I experience, and with every crash comes frustration. I actually close my eyes while saving/loading and keep 2/3 backups of the save game XD!

Please, creative community, help me find a way for a nice pixel display and a nice input device that can be used with single clicks instead of two (select switch -> turn of/on is the most simple input you can imagine)  

 

[Saturnus]

14 minutes ago, noisycat said:

Please, creative community, help me find a way for a nice pixel display and a nice input device that can be used with single clicks instead of two (select switch -> turn of/on is the most simple input you can imagine)  

For the later part you have to remember that the game isn't really built for direct user input. It's entire constructed around the premise of dupe interaction so there's sadly no way to implement push buttons directly.

For the display I've been working on expanding my 4bit 7 segment display encoder into a 6bit 5x5 pixel (with line 2 and 4 double height) display based on the standard ASCII table minus 32 (so 000000 is SPACE or BLANK and 111111 is _underscore_). Using the official ASCII minus 32 would be ideal as everyone would have the same output.

Using 5x7 (row 2+3 and 5+6 the same) ceiling lights, it looks ok but needs cooling if run for extended periods. 2x2 cells with lamps or doors doesn't look good. And doors are far too slow for a scrolling text banner I intend to design. 

[noisycat]

5 minutes ago, Saturnus said:

For the later part you have to remember that the game isn't really built for direct user input. It's entire constructed around the premise of dupe interaction so there's sadly no way to implement push buttons directly.

For the display I've been working on expanding my 4bit 7 segment display encoder into a 6bit 5x5 pixel (with line 2 and 4 double height) display based on the standard ASCII table minus 32 (so 000000 is SPACE or BLANK and 111111 is _underscore_). Using the official ASCII minus 32 would be ideal as everyone would have the same output.

Using 5x7 (row 2+3 and 5+6 the same) ceiling lights, it looks ok but needs cooling if run for extended periods. 2x2 cells with lamps or doors doesn't look good. And doors are far too slow for a scrolling text banner I intend to design.

I also find doors too slow. I really like your design, but I think that I might need more space for the wires. I had two ideas, one to just connect every pixel to a latch outside the screen and control the latches like RAM memory - this way I don't really need gpu (more like display controller, but it sounds cooler XD), since I can just choose arbitrary segment of memory to be video memory just by connecting those cells to pixels. Easy. The other idea is that I can keep latches on the pixels and control them with crossing wires. This requires special decoder that should send commands to light up or shut down specific latches based on instructions from CPU. The advantage here is that I don't have to run so many wires allowing for much better display with better dpi (the limiting factor here is of course that you need to space out wires by one cell to allow arbitrary number of wires to cross). The disadvantage... well... the decoder would be another kind of computer. Very small and specific, but running it's own clock. Syncing this would be painnnnn...

Fun fact: I've talked about "Automation" with Etiam before the Oil was announced, we thought about a mod that could implement logic gates while discussing mod api XD

[Saturnus]

My general conclusion. After countless crashes. Literally hundreds of crashes. Some times the save file wouldn't even finish loading before it crashed. Is the best solution for now is to build autonomous independent blocks and find a good way to glue them together once the automation upgrade is out of beta. Right now everything is just too unstable to even attempt highly integrated solutions.

[noisycat]

14 minutes ago, Saturnus said:

My general conclusion. After countless crashes. Literally hundreds of crashes. Some times the save file wouldn't even finish loading before it crashed. Is the best solution for now is to build autonomous independent blocks and find a good way to glue them together once the automation upgrade is out of beta. Right now everything is just too unstable to even attempt highly integrated solutions.

I really think that I won't finish before automation is live  I'm currently sitting with my notebook designing instruction set while having in mind how I'll implement it... A lot of work ahead!

[manu_x32]

13 hours ago, Saturnus said:

@manu_x32 Have you tried the reverse? Instead of shutting off water coming in. How about using one of the new small pumps, and control how long time it is on, ie. much water is pumped out?

A more practical solution would be to store each bit separately. This 1bit store set up should work.

There's a small liquid pump at the bottom. At the store command/trigger it will should be on or not for a short while. This pumps water to the top and out the vent where it is sensed (or not). This is your stored bit. Either there is water or there is not. At reset open the doors for a set time so the water flows to the bottom. The bit is reset.

An easy water counter can be done with the same set up with two side by side by exploiting the vent overpressuring. When the first room is full the sensor in the 2nd will go off as it over flows into this. Allow a bit of time, probably set sensor to something like 500kg or so to make sure the first room is fully over pressurized. Then you cut the supply to the overpressurized room and empty it thereby resetting it. The exact amount that is in the overpressurized room, the vent, and the shut off valve should be exactly the same each time.

Very good idea as always, I knew you would have something.   I will try that!  And this kind of setup would persist through saves, awesome!

11 hours ago, Saturnus said:

Strange. It works for me. If you want to make sure they don't clean the outhouse right away. Set it up with one way doors. First going the outhouse, 2nd goes to a room with a wash basin (or sink) set on priority 8-9, and then one door leading out. That way the dupes are forced to use the wash basin right after doing their business, overriding the cleaning priority.

If you're still having problems with missing foundation on the outhouse for some reason then with the above described set up you can also count wash basin visits instead.

If you want to make sure dupes don't wander around in your "morb generator". Fill the whole thing with chlorine gas. Dupe generally don't loiter in areas they can't breathe in, and that also eliminates the risk of someone deciding to disinfect the area randomly.

I think some things have been fixed/changed in the last updates, the pressure plate and outhouse behave a bit differently in my tests.  At one point (maybe one of the updates) the outhouse was saying no foundation when on top of a door. Than if I deconstructed it, put real tiles, deconstruct then put back the door it would be fine for a little while, then break again...  but it doesn't seem to do it anymore.  

And I'm using the pressure plate under a crusher to control how much sand I'm creating with crusher on continuous mode. So maybe the outhouse will now work.  

As you mentioned, I've also been thinking about using multiple doors and multiple dependent pressure plates, to make sure things don't get triggered when dupes just wander.  Lots of things to test! Having fun with this setup outhouse setup and mini base.

[Saturnus]

3 hours ago, noisycat said:

I also find doors too slow. I really like your design, but I think that I might need more space for the wires.

I've been looking at it a little longer. In the 5x7 set up there's room for maximum 22 lead in wires at the top or bottom for 25 lamps. 20 if we want to set them up completely side by side. Seems it's not going to work, right? Well, maybe it will. I'm sure that when I bitmap the letters I'll find one or two unique pairs. There's bound to be at least one of the lamps that will only be on when another lamp or combination of lamps is also on. Or the reverse. Both which will cut down on decoder complexity and needed amount of connecting wires replacing them with logic in the display itself.

EDIT: Didn't take me long to find the first one. In a 5x5 display you only use the 0 column for letters and symbols that absolutely need it. Otherwise it's left blank for letter spacing. So column 0, row 2 and 4 will always be on at the same time. That happens in W, M, and #. That means column 0 can be reduced from 5 separate input wires to 4 unique positions which translates to 8 possible values meaning a 3bit signal. So that alone cut needed input wires to 23. I'm sure there are more.

[manu_x32]

15 hours ago, noisycat said:

It seems to me that my ROM is persistent between loads since I use switches there and those seem to remember their state. With ram the problem gets more real as I intend to use flipflops, however it's a marginal flaw if you cannot save/load during execution of the program. There are no guarantees about the internal state of the computer when you run your program, so even if the ram is flipping until set it shouldn't be a major problem.

Also, sorry for the lack of screenshots, I got home really late yesterday.

Maybe you won't have the problem.  The main persistence problem I've seen is related to the hack we use to store values in the binary counter.  that part does not persist and will maybe never do...  they need to had memory boxes and counter boxes.

EDIT: actually I just tested the last update, and it seems like everything gets persisted now, the exact state of the binary counter included the hacks loads back, so happy!!!

What we need is this: