bug Relativity of time. Or Why you should not trust buffer gate

[NoOneInParticur]

To make a long story short. I tried to automate rockets space scanners to decrease power consumption. My idea is after rocket is launched to make space scanners active for 30 seconds every set interval of time. First image is my setup. Anyways it didn't worked correctly, most of the time i missed the rocket. So i tried to crunch the numbers and discovered that 10% rocket navigation efficiency is not equals 10% reduction of speed*. So i trained some dupes whiteout rocket navigation. Still the setup didn't worked. So i did some test with the new time sensor. Second image is a setup to test long time intervals. What i discovered that the buffer gate and filter gate are synced between each other. It isn't synced for time interval and global game time. Which makes counting time using buffer gate and filter gate unviable.

The test: buffer gate and  filter gate are set for 119 seconds, after it loops for 5 times.

First column is test number.

Second column total tame by time sensor.

Third and forth is precision to 5 times.

And the last column how much how imprecise in seconds it would be after 9 times (just simple multiplication).

Here are some test results:

1 594.3 4.994118 0.005882 6.3 2 592 4.97479 0.02521 27 3 591.2 4.968067 0.031933 34.2 4 595.9 5.007563 -0.00756 -8.1 5 469.1 3.942017 1.057983 1133.1 6 588.8 4.947899 0.052101 55.8 7 586.5 4.928571 0.071429 76.5 8 593.1 4.984034 0.015966 17.1 9 592.3 4.977311 0.022689 24.3 10 588.4 4.944538 0.055462 59.4 11 582.5 4.894958 0.105042 112.5 12 591.7 4.972269 0.027731 29.7 13 588.6 4.946218 0.053782 57.6 14 578.5 4.861345 0.138655 148.5 15 590.2 4.959664 0.040336 43.2 16 593.8 4.989916 0.010084 10.8 17 587.3 4.935294 0.064706 69.3 18 582.8 4.897479 0.102521 109.8 19 583.6 4.904202 0.095798 102.6 20 587.6 4.937815 0.062185 66.6

The colony is over 3000 cycles old. This happens on speed 3 the lower the speed the better buffer gate preforms relative to time sensor. There are no mods installed.
* if people need i got a complete list of exact time for rocket travel.

[gabberworld]

problem is in the Timer sensor it goes out off sync. like others suggested use the water  clock instead.

what happens with Timer sensor is that it stops run in some cases like game micro freezs, it's because they are not using world clock for that, instead they use ticks

[Gurgel]

There is absolutely no reason to mistrust buffer gates. There is reason to not misuse them for purposes they are not intended for. In particular, they are not intended or suitable for precise time-keeping.

[gabberworld]

2 minutes ago, Gurgel said:

There is absolutely no reason to mistrust buffer gates. There is reason to not misuse them for purposes they are not intended for. In particular, they are not intended or suitable for precise time-keeping.

its possible trust when they fix that bug till that yes no way possible use those as 100% accuracy

[Gurgel]

21 minutes ago, gabberworld said:

its possible trust when they fix that bug till that yes no way possible use those as 100% accuracy

I do not believe this is a bug.

[gabberworld]

33 minutes ago, Gurgel said:

I do not believe this is a bug.

for me it looks like bug. as i tested this with real time 1 cycle is 10 min. if some freeze happening at game then timer stops and then 1 cycle is less than 10 min for timer. but for game self the 1 cycle it's its still 10 min

timer i activated with cycle timer for see differences , more game freezes more it go out off sync. if there no freeze at all then clock is always 10 min in one cycle

how to fix this?, im guessing  they need stop also game own clock at game micro freeze time

[TheMule]

This is just the game engine skipping events to keep with the pacing of the game. We've seen this in dups pausing to decide what to do next, critter skipping movement/animation, etc.

[Gurgel]

1 hour ago, TheMule said:

This is just the game engine skipping events to keep with the pacing of the game. We've seen this in dups pausing to decide what to do next, critter skipping movement/animation, etc.

Exactly. This game has some (soft) real-time requirements in order to give a good experience. Anything not explicitly intended for precise timekeeping will not be precise. That is not a bug.

[Saturnus]

4 hours ago, Gurgel said:

Exactly. This game has some (soft) real-time requirements in order to give a good experience. Anything not explicitly intended for precise timekeeping will not be precise. That is not a bug.

However, you see the same discrepancies when using a timer sensor which I would argue is at least in concept is meant to be used for precise time keeping. I say in concept because without an automation reset option any timer is basically pointless except for very limited use cases where you just want to cycle on and off times.

The fact that we have to make water clocks for precise time keeping, especially over multiple cycles is counter-intuitive to new players and flies in the face of everything we know about automation from real life. Even if it isn't a bug, I definitely think the devs should look at it like it is, and at least try to improve the precision and reliability of automation in general.

[Gurgel]

7 hours ago, Saturnus said:

However, you see the same discrepancies when using a timer sensor which I would argue is at least in concept is meant to be used for precise time keeping. 

Obviously, it is not meant for precise time keeping. I mean, it very obviously does not keep precise time, so why are you assuming it is intended for that?  

That analogies from real life do not always work in ONI has been firmly established. Just accept it.

[yoakenashi]

Rather than using filter gates and buffer gates, or timer sensors, since they aren't accurate time counters - I've set up my rocket timer using actual cycle sensors. The idea is to have 10 cycle sensors each offset by 10% in activation time. You can then use this to accurately count the cycles down to 1/10th accuracy. The benefit here is that the cycle sensors are based on absolute day positions and not number of tics. I also realize this solution isn't perfect, since it could be off by up to 60 seconds, but it works for me at the moment.

10 hours ago, Saturnus said:

The fact that we have to make water clocks for precise time keeping, ... I definitely think the devs should look at it like it is, and at least try to improve the precision and reliability of automation in general.

Seems strange that the game can track movement of water to a precise 1 g/s rate (for example), but automation isn't tracked to a precise 1 s/s. I would have expected water flow to be based on game tics just like automation, but perhaps that's a bad assumption?

[OxCD]

 

[gabberworld]

29 minutes ago, yoakenashi said:

Seems strange that the game can track movement of water to a precise 1 g/s rate (for example), but automation isn't tracked to a precise 1 s/s. I would have expected water flow to be based on game tics just like automation, but perhaps that's a bad assumption?

code shows that they use different timer types for different objects, this i found out by making mod.

im guessing water draw clock uses same timer what world clock is using

[babba]

Precise real-time keeping may come in conflict with optimizing the game for speed, to have the game run fast and smooth for most people.

[NoOneInParticur]

It's weird that then i use a automation thing that says outputs green signal for x seconds and it doesn't output signal for x but for y seconds.
It's good to hear that drip clock(does drip clock still works then new pipes are being constructed?) would work as it lets us design around this thing. I guess i could redesign it using the time sensor, but rockets might have some down time.

[avc15]

On 10/25/2020 at 6:00 AM, Gurgel said:

Obviously, it is not meant for precise time keeping. I mean, it very obviously does not keep precise time, so why are you assuming it is intended for that?  

That analogies from real life do not always work in ONI has been firmly established. Just accept it.

And yet, what value is automation at all in creating any kind of state machine, if you cannot use a simple pull-down timer?

All state machines that rely on timekeeping must use a water clock?

This is what we call "failure by design"

[psusi]

On 10/25/2020 at 9:00 AM, Gurgel said:

Obviously, it is not meant for precise time keeping. I mean, it very obviously does not keep precise time, so why are you assuming it is intended for that?  

You seem to be arbitrarily adding this "precise" modifier and claiming that nothing says they are intended for "precise" time keeping.  Forget about "precise timekeeping".  They are intended to do things for a certain amount of time, and they don't. Therefore, it's a bug

[darknotezero]

My position on this is: this is a bug, but it's not worth fixing outside of a Major Update way in the future.

If what gkbrew stated in my other thread that brought this up is true:

Spoiler

I think it has to do with how the game works. My understanding of the problem is something like this:

ONI has two types of updates. Simulation updates happen 5 times per in game second (so 15 times per real world second on 3x speed). Most of the simulation happens during these "ticks": thermal simulation,  piping, machines(?).

But, 5hz is really slow for a video display, so there are also animation updates that happen in between simulation updates. Most things that happen during animation are purely cosmetic. For instance the visible movement of fluids in pipes, is just an animation. In the underlying simulation fluid packets move between pipe segments instantaneously.

Unfortunately some non-cosmetic things happen on animation updates too. For instance, dripping fluid only moves on animation updates. If you pause the game and use debug mode to do simulation steps, a fluid drip will never move, but liquid vents will keep emitting liquids so when do u pause, you'll have a big mass of drips that all hit the floor at the same time.

The timing of animation steps is much less deterministic, and I believe they get dropped when you have a lot of lag. (Or try to run the game on super speed)

I think some part of the buffer and filter simulation happens during animation steps, so when you have lag they get out of sync with cycle timers which are based on in-game time which is locked to simulation steps.

then trying to fix this bug is not a small fix as it changes a fundamentally base behavior of the way they designed the automation that would likely have ripple effects throughout the game. Given that there is a reliable and fairly straightforward workaround that *does* offer precise timing, i'd rather the devs work on other things with the limited resources that they currently have and not get stalled trying to fix this and then also fix what will inevitably break by trying to fix this.

Short burst or non-precise single cycle timing is where this stuff shines. When you need something more, use a water clock. problem solved. Let them fix the stuff that can't be fixed and/or work on finishing that Space update.

[Gurgel]

5 hours ago, psusi said:

You seem to be arbitrarily adding this "precise" modifier and claiming that nothing says they are intended for "precise" time keeping.  Forget about "precise timekeeping".  They are intended to do things for a certain amount of time, and they don't. Therefore, it's a bug

In actual reality, things have to be implemented and this comes with trade-offs. Also, _nothing_ is absolutely precise in physical reality, everything has tolerances. Just deal with it instead of complaining. You know, like an engineer would.

[OxCD]

On 11/18/2020 at 3:35 AM, Gurgel said:

In actual reality, things have to be implemented and this comes with trade-offs. Also, _nothing_ is absolutely precise in physical reality, everything has tolerances. Just deal with it instead of complaining. You know, like an engineer would.

If you look the bug I've linked above, over a cycle, 600sec, 3 filter gates set to 200sec, just go in 200sec.

That means 400sec are missing, over a single cycle.

I hope no engineer is putting up with a clock where 24h go in 8h. Otherwise remember me to do not trust and get anything from them.

[babba]

On 10/25/2020 at 1:23 AM, TheMule said:

This is just the game engine skipping events to keep with the pacing of the game. We've seen this in dups pausing to decide what to do next, critter skipping movement/animation, etc.

The collective dupe meditation starts to get longer and longer, at 100 dupes with lots of stuff going on in a map it can be several seconds.of collective Bork meditation block. Its also one reason why I dont run pet creature farms...It ends in another 500 things jumping around, which each thing running its tasks and checks.

I found it brave that Klei implemented circuits and player placed time keeping elements in to the game. Understandable that players want to have precisely elements running precise in the game.

There is so many things to consider from a development point of view, it would be much easier if it would not be a game and only a time management software/hardware. In real time computing a task is given a fixed amount of cpu time/component resources, processes which can not be delayed by any other hardware or software ( layer ) or other running processes of a system. An extreme wasteful resource approach as a lot of resources may remain idle to maintain exact precision, each running their tasks wih fixed time slots/cycles - No matter if not calculating anything or not in their allocated and guaranteed cpu share. The other demanding player faction is "Klei, the game runs too slow on my pocket calculator - Make stuff run faster".

IMHO this game will never have the time precision of Factorio, ONi has too many grown systems from too many minds with too many interacting grown systems and too little dev time. However, staff is clever and may find hacks or designed ways to achieve what players are asking for with budget and given dev time.

I`ll never forget when a new guy worked on multithreading the games pipe system and directly borked the game up for all.

Perhaps the devs could be asked if it is possible to deactive most systems with console commands, incluing all animation graphics...To see if the games timers actually run better.. Sometimes I do wonder why my map is still running and not errupting in to a black hole, it love all this crazy ONi stuff jumping around, exploding in fantastic colors. Devs also love if players ask for spreading fires during an ongoing software development...Not that it would kill a cpu

I so hope to someday have fire in the game

@OxCD Does the timer run better on a game map size of the timer cell size, a few cells, just with 1 timer and a few cell size of something connected ? I dont know how much access the coders allow players to mess with map sizes, it could be that such a tiny map attempts to run 100000% too fast and insta crashes. BTW - I recently discovered that they limited cell pressure damage, in the beginning of the games development I had gas peaking at 1 million kg/cell for a few milliseconds and then the game disappeared. But nowadays I just want to play the game, dont wont to get too involved with under-da-hood stuff of this great game.

I often swear myself to not use a forum, I broke my rule again. Its a nice community here

Just my 50 cents on a few things...Wishing everyone a nice time in the game.

@Oozinator where are you my friend, the world needs you back...Oooozieeee ! Square wheels will never be fun again without you Viva Viva la Duparevolution !

 

[Gurgel]

4 hours ago, OxCD said:

If you look the bug I've linked above, over a cycle, 600sec, 3 filter gates set to 200sec, just go in 200sec.

That means 400sec is missing, over a single cycle.

I hope no engineer is putting up with a clock where 24h go in 8h. Otherwise remember me to do not trust and get anything from them.

I did not see that. I saw the original measurements where there is once 470sec instead of 600 and the rest is pretty precise. Still, it is pretty clear that the delay gates may be badly off under some circumstances. Again, that is something to know and to take into account. In a wired sense it makes the game _more_ realistic and that is what some people always request. Jitter, thermal changes, noise, etc. are all facts of life for an EE.

As to your observation, 600sec -> 200sec sounds more like an issue with your circuit. Your old save does not load though (current preview). Can you make an updated save or post the automation overlay for it?

3 hours ago, babba said:

I often swear myself to not use a forum, I broke my rule again. Its a nice community here

That it is. Even when things sometimes get heated (and I still have some people on ignore), it is much, much nicer than what you usually find on the Internet.

[OxCD]

51 minutes ago, Gurgel said:

As to your observation, 600sec -> 200sec sounds more like an issue with your circuit. Your old save does not load though (current preview). Can you make an updated save or post the automation overlay for it?

There was no issue on my circuit. The cabling is more simple than adding one to one.

The bug isn't appearing on a freshly created map, as I should have said into the report. I guess the more heavy your base is, the more lag you get, the more seconds you loose.

Of course both has been launched at the same time. And I didn't even move my camera (and my eyes) from the timer while checking this.

Also 200sec was an approx value I gave to illustrate. In the report you have the value I had on the timer. Not precise as it's graphical only, but looks like 250secs approx.

 

[babba]

Can you perhaps run that circuit design in a 10 x 10 cell map,  or the next ratio compatible and supported cell size map format ? Perhaps its helpful to see if your findings would be exactly the same with a tiny empty map. If your findings are then exactly  the same, maybe its then "just" the design of the time system, game logic or bugs as there is no real map load interfering.

Oh I see a % value on your screenshots...It can be so many other things, but keep in mind that conversions and changing stuff to different formats make rockets and sateliites crash in reality. Do all second based timers run fine in the game after your findings ? Im no timer usage expert in this game...Perhaps its a % related conversion issue ? Behind the scenes conversions + passing time could perhaps lead to time sync issues ? Just guessing...

Perhaps it would be good to know if all second based times run exact in the game ?. I was head of QA in a games company btw, tracking down and trying to find out what coders where making to Spaghetti. My initial approach was often "Whats the current biggest **** with the engine, the game and your workflow ? Speak open, no hesitation. Here, a slice of hot pizza for you."

The devs should know what the timer system design and issues are, hopefully

[Gurgel]

12 hours ago, OxCD said:

There was no issue on my circuit. The cabling is more simple than adding one to one.

Well, I did just run this. The only difference I found is that you need to add about .4 seconds to the left side for wire delays. Each wire ads 0.1 seconds, I think.

I do not know what went wrong here, but your claim looks very much like a measurement or wiring error. That is why I asked for the overlay.