Can Someone Explain How ONI Loads Automation?

[Empy3]

I am working on designing a high-turnover Pacu farm, and have been running into problems for several days because of how the automation loads (or doesn't load) when turning on the game. Sometimes automation wires start out as the wrong signal entirely, sometimes they start the right signal and flash very briefly to the wrong signal before reverting to the right signal, sometimes they don't flash at all but the game seems to think that they did because it operates destination buildings just like it had briefly received a different signal. Can anyone help me understand how the game determines what to do with buildings connected to an automation wire when the game loads? I am really frustrated that this machine design isn't working because of brief-but-wrong signals that occur when the game loads.

[Nxf7]

Did you have any specifics.
I noticed upon load that critter sensors will send the opposite signal for up to 0.4 seconds. As in, I saved the game with one critter sensor turned off and one turned on, reloaded the game several times. They would both toggle for a duration between 0.1-0.4 seconds.

For my build I figured the only solution was to account for it, and have a filter/buffer at 0.5 duration or higher.

[sheaker]

42 minutes ago, Nxf7 said:

For my build I figured the only solution was to account for it, and have a filter/buffer at 0.5 duration or higher.

Agree. That is what I am using for some of my critical designs. But for me problem was rather with memory gate which was sending short green signal after reset (or maybe xor gates were sending the signal during memory gate reset). After all filters/buffers as a delay mechanism is a normal thing in real life so why not in ONI?

[Empy3]

It is definitely critter sensors that is giving me problems. I have about 20 in different parts of this machine, and there's no consistency about which ones signal incorrectly when the game loads. This automation is already so complicated that I don't know if I have room to throw in more filter and buffer gates for all of them, but I guess I'll see what I can do. It strikes me as really strange that the critter sensors specifically do this. Do you know if Klei has acknowledged that it's a bug, or is it somehow working as intended? I don't think I've ever noticed this with other automation input buildings.

 

[mathmanican]

13 hours ago, Empy3 said:

when the game loads

There are all kinds of things that are adversely affected by save/load. Automation is just one of many. 

36 minutes ago, Empy3 said:

Do you know if Klei has acknowledged that it's a bug

They've seen posts about save/load issues for years (I'm very confident they keep up on basically everything on the forums). It wouldn't be a bad idea to find one directly related to the issue you are having, and adding comments to that post (and linking back to this page). It wouldn't surprise me if they have a large internal list of save/load issues, and fixing it just hasn't bubbled to the top of the priority list yet. 

[Empy3]

10 hours ago, Nxf7 said:

For my build I figured the only solution was to account for it, and have a filter/buffer at 0.5 duration or higher.

How did you account for this on lines where there are already buffer gates involved in the automation triggers, especially if the initial signal that trips the line is very brief to start with? Sorry for the dumb question, my brain is just just no longer working with the additional problems this presents after a week of trying and failing to make this design work. 

1 hour ago, mathmanican said:

They've seen posts about save/load issues for years (I'm very confident they keep up on basically everything on the forums). It wouldn't be a bad idea to find one directly related to the issue you are having, and adding comments to that post (and linking back to this page). It wouldn't surprise me if they have a large internal list of save/load issues, and fixing it just hasn't bubbled to the top of the priority list yet. 

Thanks, I will see what I can find. I was looking for something similar to this issue in the bug forums before making this post to see if I was just programming the automation wrong and didn't find much, but having a better idea of what the problem is may help.

[BaloneyOs]

21 hours ago, Empy3 said:

Sometimes automation wires start out as the wrong signal entirely

You're right, this happens consistently with critter sensors in that they always briefly signal green their opposite on load. Screws up a lot of stuff for sure but it does seem to be a long standing bug.

Edit: I see memory toggles in your spaghetti, so reversing the entire logic chain could mitigate the problem (or make green signal the less destructive one, since it always loads on green).

[Empy3]

2 hours ago, BaloneyOs said:

I see memory toggles in your spaghetti, so reversing the entire logic chain could mitigate the problem (or make green signal the less destructive one, since it always loads on green).

I actually don't have memory toggles in it anywhere, just AND/OR gates. But I did go back and check something after your comment, because many of my critter sensors definitely are not loading green, and I noticed that while all of the buildings connected to one do seem to have some kind of reaction to the sensors on load, the ones that, at some point, run through the automation ribbon react so briefly that they don't actually allow their downstream buildings to do more than flicker (the automation signals don't appear to change color at all), and don't seem to actually trigger airlocks/chutes/vents to open long enough to allow anything through, even if unpowered. I may try to see if I can run all of my critter sensors in the bottom half of my machine through an automation ribbon at some point to see if that effect is reliably able to be replicated, especially because it may allow me to cut out some of the spaghetti and extra buildings involved in working around unwanted pulses resetting signal counters.

[Nxf7]

2 hours ago, BaloneyOs said:

since it always loads on green).

  This has not been my experience when testing this. They flipped to the opposite state they were saved in, for 0.1-0.4 seconds until flipping back.

5 hours ago, Empy3 said:

How did you account for this on lines where there are already buffer gates involved in the automation triggers, especially if the initial signal that trips the line is very brief to start with? Sorry for the dumb question, my brain is just just no longer working with the additional problems this presents after a week of trying and failing to make this design work.

Basically there's two situations, the game is saved while the critter sensor is in the off state, and another when saved in the on state. If it's critical that you stop the state flip in both situations then you need critter sensor > filter > buffer, in that order. Otherwise you only need a filter to stop off-on flip, or a buffer to stop on-off flip.

Alternatively you can have the signal ANDing with something else which if it weren't for this bug may be pointless to you.

It just so happened for my critter sensor, while both state flips impact me, the critter sensor is on for 99% of the time and the only side effect is it triggers another algae feeding unnecessarily, so I don't care if I get unlucky and save the game when it's off.

[BaloneyOs]

Just double checked too and I was wrong about it always loading on green, when it does in fact briefly flash the opposite signal on load. Must've confused it with the overall function of my ranch because reversing the entire signal chain worked on my design in mitigating this bug.