Automation features and mechanics i discovered

[Arnadath]

So, i found out some interesting mechanics about automation that will be extremely useful to those of you that know a thing or two about automation in real life and would like to apply it in this game. This post is also a forword to a little something im in the making of and will soon be releasing to the community. How big? Well, this is how the map looks like: 

Spoiler

This is ARN Vortex v1.3, an 8-bit ARM inspired CPU, packed with 8 byte of ram and two BCD displays out of doors, with demux and bcd convertors. It is intended as a platform for educational purposes and for people that share my passion for digital design to experiment on. Like an arduino, but for ONI and in Assembly.

Why you ask? Well, because ONI crashes as much as Xilinx Ise on my laptop, but at least it has a much, much nicer enviroment.

 I will upload this map, maybe even later today as an alpha version for those of you that are a little bit more hardcore with automations. I won't be doing it right now, because i want to set up a proper demo first... and 1 or 2 details... y'know...

At this moment, the system supports ldA, ldB and Add. More on it soon though

And as a bonus, to the guy that liked my post about adding busses (like heavy watt wire, but for automation) and mux/demux, well i ended up with the peacefull solutions of relocating my dupes instead of evicting them with only a pool of lava to live in. And then i  proceeded with my "aggressive landscaping".  

But let's not get on a tangent. Our topic was my foundings on the mechanics of ONI regarding automation, and specifically, a little something, wether a quirk of the mechanics, or a pleasant little bug, that you could acctually try right now, if you have the game open in front of you, but ill guarantee that it might have a huge impact on how you see automation in this game:

If you pause the game, and trigger a state change in an automated circuit, then you can see state-by-state their internal buffering, irregardless of the game time of it's components, by selecting to build an automation cable, even on top of another automation cable, and for each individual automation cable build this way, you will see the next state of the system.

Sorry for the wording, but i wanted to be very excact. So, what do i mean by that, but with images:

Mind you, we have debug mode enabled. So this switch should turn on instantly when i press it. That would be the case, but the game is paused.

Then:

I press on an automation cable and copy it, then i click on top of the already existing cable. immediately the switch turns on. It happened while paused! I guarantee you i don't have some superhuman space bar pressing capability. 

One step further, the not gate, has propagated it's signal but the xor gate is still giving out a false. Hmm, i bet another click and it will give out true.

bingo, my prediction was correct.

So naturally, i ran some tests based on this newfound data, and here is what i found.

1.ALL gates, have a propagation delay of 1 frame, meaning that the output for the gate, after the signal is taken in, takes excactly 1 frame

2. The signal in a whole line or mesh of automation wire will arrive at all points (inports and outports)without any propagation delay.

3. You can write to a memory toggle on excactly the same instant you reset it, and it will retain the intended output. Meaning that if you give a 'true' input to a memory toggle and at the same exact instant reset it, both those actions on this and only this exact moment of time, then you will get a 'true at the output..

4. Buffer and Filter gate outputs, don't correspond excactly to the behavioural of the other components. 0,1 seconds, corresponds to one frame, but from then on, the timing seems to be based in some other time base. Also one thing to keep in mind, is that buffer and filter gates will freeze when the game is paused and they won't progress, even with the "build automation cable" trick, except if they are at the phase where they are outputing their state change. You might be able to do this if you manage pause at the excact same moment a filter gate has done it's loop and is about to turn 'true'. This, also applies to the 0.1 second setting  but with tests i've done with the game running, it seems to apply that the 0,1 second settng, is one frame.

So, keep those things in mind, next time you design a circuit, and especially keep them in mind if you are interested in the project im making.

[riwenna]

Ha, since the moment they introduced automation I was waiting for the moment somebody will build a CPU Congratulations. Also can't wait for you to actually upload the map.

Btw, since you managed to take circuit design so much further than I ever had time to, when you're taking a break from the CPU, if you feel like it would you mind giving a quick glance to the automation for my love it or leave it steam vent? It basically collects and compresses infinite water from a geyser, but the automation got a bit out of hand and I'm trying to see if I can make it any simpler and smaller (both in the number of gates used and space required...) and would be great to get an opinion from somebody who doesn't mind delving into it.

[riwenna]

Considering what you're trying to build there, not sure how much you read the forums before you started posting (and I'd really love to see some bits of that map of yours closer up), but this thread might be somewhat relevant to what you're trying to do:

"Automation timing unreliable" - somebody trying to build a mux (and apparently failing due to how the automation timing works; but to be fair I didn't get completely into details of that one).