Jump to content

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


Recommended Posts

3 hours ago, Gurgel said:

Measurement or wiring error.

None.

Again, the very high load of my save and the lag I had was needed to easily observe the same result. I've tried on other saves, heavy but not that much, and didn't notice it. 

That's why I had linked my save. So to observe by yourself, you'll need a release that can open it.

For you information, I have created this simple sample as I was trying to isolate a problem I've noticed on a much more complicated design, on the same map. An automated system for rocket take off and landing. A design I've worked on for a long time, that was showing same issue. Everything for the rocket return was happening maaany cycles before it was supposed to do.

 

 

 

unknown-20.png

Link to comment
Share on other sites

Well, I just ran this for > 50 cycles and the filter-version is about 1.5 seconds too fast on average (taking into account it should be 0.4 sec slower). 

And no, I am not going back to some historic release to test this. I guess the Klei people are not either. 

That said, if the system becomes sufficiently overloaded, the real-time properties come into play. Real-time does not mean high-performance. Real-time means things like dropping some actions from queues when things get overloaded so others are still assured to happen. The only way to fix this is to give the system more power or less load. Or to accept the dropping of actions.

Link to comment
Share on other sites

18 minutes ago, Gurgel said:

 And no, I am not going back to some historic release to test this. I guess the Klei people are not either. 

I never ask you to do so. I said "to observe by yourself, you'll need a release that can open it."

Too bad that when I've opened this bug, it was the released version. If Klei would have dealt with this bug, it would have been easier the period when it was opened. But hey, I did my part of the job, when I had to.

23 minutes ago, Gurgel said:

That said, if the system becomes sufficiently overloaded, the real-time properties come into play. Real-time does not mean high-performance. Real-time means things like dropping some actions from queues when things get overloaded so others are still assured to happen. The only way to fix this is to give the system more power or less load. Or to accept the dropping of actions.

Well, if I get it correctly, it's a complicated way to explain how this bug is working.

Maybe, I don't know. And I don't pretend to.

Link to comment
Share on other sites

1 hour ago, OxCD said:

Well, if I get it correctly, it's a complicated way to explain how this bug is working.

Maybe, I don't know. And I don't pretend to.

This says basically "this is a known limitation". The only thing Klei could be doing is add all (!) logic to the "must execute" class, with potentially drastic negative effects. This really is not a bug but a design choice. You cannot force your CPU to run as fast as you need, you must decide what must be executed (and if the CPU is too slow will slow down everything) and what is on the "drop if no time" list. 

The difference in Real-Time to normal code execution is that you have a "drop if no time" list and that allows you to keep things from getting bogged down. On the minus-side, anything on this list may get dropped under overload.

Link to comment
Share on other sites

Yeah, best practice is to share screenshots or save games. Once shared colony play between and with players is there ( praying for it ), then its easy to send player invites so that other players can help with colony and build issues. Also the fun...Give us also goods trading between players dear Klei :angel:

Link to comment
Share on other sites

1 hour ago, psusi said:

I do not understand this decision to drop actions and break the game in order to keep running fast.  If your computer bogs down, then so be it... at least it would still play correctly.

It is a design decision and the decision by Klei is an entirely valid one. "Correctness" (in the sense of adherence to physical reality) is of high value in a scientific simulator and meaningless in entertainment. It does not even have a definition there. In entertainment, if your game reacts sluggish and frequently locks up (and that is what we are talking about here), you lose most users and get bad reviews. In entertainment, what matters is the experience most (!) users get, not some border-cases. That some users cry "Gamebreaking!" is something hat is pretty normal. There are always some people that think their concerns are the most important ones, even if most other users do not care or do not find the issue serious.

And no, they did not "break the game". That is just hyperbole and they are right to ignore it.

Link to comment
Share on other sites

3 hours ago, Gurgel said:

"Correctness" (in the sense of adherence to physical reality)

Correctness has nothing to do with physical reality, but with the rules of the game.  If the rule is that a dupe can hold their breath for 60 seconds, then that is how it should be.  If they suffocate in 30 seconds because your computer is a little bogged down, that's not correct behavior.

3 hours ago, Gurgel said:

And no, they did not "break the game". That is just hyperbole and they are right to ignore it.

It's no hyperbole when the game literally becomes unplayable because dupes become unable to choose tasks and just hang there.

Link to comment
Share on other sites

5 hours ago, psusi said:

Correctness has nothing to do with physical reality, but with the rules of the game.  If the rule is that a dupe can hold their breath for 60 seconds, then that is how it should be.  If they suffocate in 30 seconds because your computer is a little bogged down, that's not correct behavior.

The "rules of the game" include that its world has a real-time nature with limited processing power available. This is a basis of the ONI "GUT",  just as quantum mechanics (maybe) is the basis of the Physical universe we are in. 

5 hours ago, psusi said:

It's no hyperbole when the game literally becomes unplayable because dupes become unable to choose tasks and just hang there.

There is limited performance available. Do you expect Klei to draw CPU cycles from thin air? I mean, they could have done something: Limit users to, say, 12 dupes and refuse to even start on slower CPUs. Or they could have made maps much smaller and still limit the number of dupes to something a bit higher.That would have worked and formally have fulfilled what you call for. But is that what you want? They could also simply not have made that game and waited a few more decades until single-thread performance is much, much higher. If that is even possible in this physical Universe. There are some pretty hard constraints on that and current CPUs are getting close to them. But this is about the set of choices available here. The design of real-time systems is always full of trade-offs, there is no way around that.

Instead they allow you the freedom to do much more complex bases with many more dupes, but that can cause breakages in a number of places. In a sense it is even in line with the spirit of the game: Air, then food, then temperature, then filtration medium, then computing power. Exceed what you have available for any of these and your base is in trouble. And, just as in the game, you cannot easily go back if you are overdrawing on the resources. Well, you can: Kill off enough dupes until things work again.

Now, if you ask for an explanation what is happening and why timers and logic are not high-prio "must execute" you got one. They may or may not revise that decision, but my guess would be they have tried this and found the effects unacceptable. I do not know, I can only speculate. A mod-maker may know more. If you say "this must be different", you got ignored by Klei and you get one more attempt to explain things by the likes of me. There are quite a few hard constraints here. ONI is, in a sense, high-performance computing and, at the same time, it is interactive. That is an unsolvable problem unless you have tons more computing power than needed or unless you put some drastic prioritization in there. The observed effects on delay-logic processing are one.

Link to comment
Share on other sites

ONi is like Doom or Quake back then, total hardware freedom with no gameplay limitations in the game - Max building for max ONi speed, its so much fun.

Old caravan photos at ONi/CitiesSkylines launch a few years ago, now got a different board which can draw much more power.

2KG aircooler for ONi/Cities Skylines on nowaways modified i7 7700k cpu with metal fluid between die and lid + metal fluid between lid & cooler + now new monster power board and everything much better nowadays. Will build a new ONi AMD computer in 2021.

image.thumb.png.523a6131fa9785139a3acd53eda765be.png

image.thumb.png.99603f5354e8e87d1300a45ef8ddd4dd.png

My former holiday gaming caravan ( took a whole day to set the computer stuff up ). Its was to switch off in nature. Upgraded the caravan electrics myself and added 3 internet satellite dishes on the outside. The big screens where heavy 30kg Plasma each, total power of screens all together was 2000 watts - Megaheat !

image.thumb.png.e72658810d461798ca053fc6d79985ae.png

Link to comment
Share on other sites

10 minutes ago, Gurgel said:

You seem to have accidentally tamed your screens and now they are multiplying...

How is in the land of the Alpha DLC dear Gurgel ? Klei has created division between us my friend. Ah, the bitterness ``

I`m playing Endzone now, all these players which have thousands of hours on the ONi clock...Barred out.

image.png.aff9e7e3dc9d827201f178859513e741.png

Link to comment
Share on other sites

image.png.e98433796fca4dbe67e10b6406e41b98.png

This is a bit pointless to argue.... Having a stance that automation timers aren't meant to be used as timers, that's really just totally silly.

Clearly the user thought they were getting a tree swing, clearly the developer built a tree chair instead. "Did they do that on purpose?" It's kind of an existential question.

Link to comment
Share on other sites

10 hours ago, Gurgel said:

The "rules of the game" include that its world has a real-time nature with limited processing power available.

No, they don't.  That's just an implementation detail.  The rules are things like dupes consume 100g/s of Oxygen, and CO2 sinks below Oxygen.  If suddenly all of the hydrogen on your map sinks to the bottom of your base, claiming it's not broken, it's just your CPU is too slow is kind of silly.

10 hours ago, Gurgel said:

There is limited performance available. Do you expect Klei to draw CPU cycles from thin air?

I expect that if it takes longer to run the program, then it takes longer to run the program.  The end result should be the same.  In other words, if you set the game to 3x speed and 1.5x is as fast as it can go, then that's the speed you get.  Likewise if you set it to 1x speed and 0.5x is all it can do.  It should not decide to run some things at 3x speed and stop running other things completely.

 

Link to comment
Share on other sites

Need more threads. Oh yeah gimme that 16 core goodness.

I hope that new DLC will be threaded a bit more than original game. But running multiple colonies now could warrant easier threading right? But more ram again.

Link to comment
Share on other sites

7 minutes ago, cpy said:

Need more threads. Oh yeah gimme that 16 core goodness.

I hope that new DLC will be threaded a bit more than original game. But running multiple colonies now could warrant easier threading right? But more ram again.

Its really nice to see you back @cpy :angel:

Would be nice to investigate core loads. It seems its possible to play smaller maps with the dlc, that will help a lot of hardware strugglers. If players have a choice to play small or big maps - Good :p

Link to comment
Share on other sites

17 minutes ago, cpy said:

Need more threads. Oh yeah gimme that 16 core goodness.

I hope that new DLC will be threaded a bit more than original game. But running multiple colonies now could warrant easier threading right? But more ram again.

I am thinking if you aren't the type to build mega-bases, build multiple bases to do the same thing instead, you should be able to get a lot more fps out of it.

The different simulations should be able to run in totally different contexts that rarely ever exchange data.

Though I can't actually try , yet hopefully

Link to comment
Share on other sites

25 minutes ago, babba said:

Its really nice to see you back @cpy :angel:

Would be nice to investigate core loads. It seems its possible to play smaller maps with the dlc, that will help a lot of hardware strugglers. If players have a choice to play small or big maps - Good :p

Oh yea! Smaller maps with distributed load would be easier on CPU with lot of cores! Imagine early game smoothness but all the way till the endgame!

I've been hibernating but not anymore!

17 minutes ago, avc15 said:

I am thinking if you aren't the type to build mega-bases, build multiple bases to do the same thing instead, you should be able to get a lot more fps out of it.

The different simulations should be able to run in totally different contexts that rarely ever exchange data.

Though I can't actually try , yet hopefully

I like big bases and I can not lie.

Link to comment
Share on other sites

Hehe :p

I had a look at the public alpha bug list, lots of issues which had been bugs in the base game ( pipe flows broken, resources set to zero etc. + of course gigatons of crashes ). They will try to repair stuff for a month. I`m really undecided to play the alpha, the key reason is that no saves can be used on dlc launch...But its great that people are helping to post bugs.

Would be nice to someday check the alpha performance and to give it a ride.

Link to comment
Share on other sites

1 hour ago, psusi said:

No, they don't.  That's just an implementation detail.  The rules are things like dupes consume 100g/s of Oxygen, and CO2 sinks below Oxygen.  If suddenly all of the hydrogen on your map sinks to the bottom of your base, claiming it's not broken, it's just your CPU is too slow is kind of silly.

I expect that if it takes longer to run the program, then it takes longer to run the program.  The end result should be the same.  In other words, if you set the game to 3x speed and 1.5x is as fast as it can go, then that's the speed you get.  Likewise if you set it to 1x speed and 0.5x is all it can do.  It should not decide to run some things at 3x speed and stop running other things completely.

 

Oh well, I tried.

1 hour ago, babba said:

Hehe :p

I had a look at the public alpha bug list, lots of issues which had been bugs in the base game ( pipe flows broken, resources set to zero etc. + of course gigatons of crashes ). They will try to repair stuff for a month. I`m really undecided to play the alpha, the key reason is that no saves can be used on dlc launch...But its great that people are helping to post bugs.

Would be nice to someday check the alpha performance and to give it a ride.

I think the alpha is interesting for a few hours, but that is it. Too much broken stuff. That is not a criticism, it is an alpha. It is expected to be just not too broken to work at all. My overall impression of what they are trying to do is pretty good though.

Link to comment
Share on other sites

On 11/19/2020 at 5:30 PM, psusi said:

at least it would still play correctly.

Which, since time is part of that, it's simply impossible. Currently the game skips certain events to be able to keep track of others. For example, liquid flowing in a pipe seems to be accurate.

Hiccups in the flow inside pipes would be much worse to deal with... most heat exchangers in petroleum boilers are quite vulnerable in rapid changes of the flow, leading to possible pipe breakage and leaking of materials where they're not supposed to be. 

If the game engine can't execute every task it should, correctness is already compromised. The point is only choosing what to be still correct about and what to let go.

Link to comment
Share on other sites

57 minutes ago, TheMule said:

Which, since time is part of that, it's simply impossible. Currently the game skips certain events to be able to keep track of others. For example, liquid flowing in a pipe seems to be accurate

Time is not part of that.  Time is relative since the game has selectable speed.  The base setting may be to correspond to 1 real second, but you can set it higher than that.  Who says it must never fall below the target speed?  If you are giving up things that won't be missed, such as a few video frames, that's one thing, but I'd say that critters and dupes deciding that they should move is not something that you can give up without missing... at least not for very long.  And automation should definitely not be on the list of things to sacrifice in the name of not going lower than the target speed.

1 hour ago, TheMule said:

If the game engine can't execute every task it should, correctness is already compromised. The point is only choosing what to be still correct about and what to let go.

Yes, but correspondence to a real clock is NOT important.  It's nice,  but not important.  Thus only things that are really of no import ( like getting only 15 fps instead of 60+, which is useless ) should be sacrificed to try to maintain it.

Link to comment
Share on other sites

4 hours ago, psusi said:

Yes, but correspondence to a real clock is NOT important.  It's nice,  but not important.

My apologies, I forgot. EvE player.

 

You see, I find the game barely playable at 3x. Hard to watch at 1x (not to mention playing it). 1x is super slow, unbearable mode.

I totally get where you're coming from, I've spent my share of time in Providence... even if I rarely experienced big events, and spent most of my time producing in high sec, in Derelik, Heimatar and later Devoid. I have 2,600+ hours in ONI, but that pales compared to my time in EvE.

Problem is, the only way would be to go below 1x, in "time dilation" realm. 70%, 50%, 20% Just no. Nobody would want to play with one cycle lasting 20 real time minutes, or 30, or 1h.
 

But of course, I'm also all for freedom of choice. There're would be nothing wrong with a MOD that introduces time dilation to ONI, I just wouldn't use it. Personally I think nobody would use it, but maybe I'm wrong.

Link to comment
Share on other sites

2 hours ago, TheMule said:

My apologies, I forgot. EvE player.

Ahh, I'm a former EvE addict myself.  Solar Storm, originally of ASCN ( alliance to build the first titan ever ), then AXEiom empire after the split.  Finally had to quit playing after I got married in 2010.

2 hours ago, TheMule said:

You see, I find the game barely playable at 3x. Hard to watch at 1x (not to mention playing it). 1x is super slow, unbearable mode.

Wow... I almost never go above 1x.  Even then half the time I'm paused and planning things.

2 hours ago, TheMule said:

I totally get where you're coming from, I've spent my share of time in Providence...

Ahh Providence... was good home after we got kicked out of the deep south by the mega Russian alliance, AAA.  Always lots of wanna be pirates to fight, and when there wasn't, plenty of work mining and building capital ships while consulting my spreadsheets and access database tracking my massive network of market orders.

2 hours ago, TheMule said:

Problem is, the only way would be to go below 1x, in "time dilation" realm. 70%, 50%, 20% Just no. Nobody would want to play with one cycle lasting 20 real time minutes, or 30, or 1h.

I hardly think it could ever get that bad.  I can see a little wiggle room with logic, but when it gets to the point that critters start drowning because they can't decide how to path out of water, and dupes stand there scratching their balls because they can't choose a task, I can't imagine how that could possibly be better than just running 25% slower.  And I can't believe that skipping logic calculations is buying you more than a few percent speed on everything else anyhow.  Before EvE officially added the whole time dilation thing, when too many people were in a system fighting ( hundreds or more ) the game just broke.  You'd be sitting there staring at at a frozen screen trying to fire or flee for a few minutes, then suddenly you were in a pod ( or more likely in a fresh clone in a station in another system ) and you didn't know why because you never even saw anyone target you.  Or sometimes you'd be in mid warp, and not even come out of warp and see the enemy before you woke up in a clone vat.  They decided a fight that goes in slow motion where you can still see the things happen that are supposed to happen was better than total freezes, followed by inexplicable glitch death, and myself and many others agreed.  I can't possibly imagine preferring the alternative.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

Please be aware that the content of this thread may be outdated and no longer applicable.

×
  • Create New...