Lategame lag is unplayable... suggestions?

[Ashpoker]

12 minutes ago, nets said:

Where the performance suffers is where there are a lot of buildings doing anything

This is perfect example of where my suggestion would be useful. To have the option to turn off building animations and turn off generating reports. because if you're not using them they're just performance hog. Also animations ... meh, couldn't care less.

[Gurgel]

4 hours ago, Ashpoker said:

 That's dev's job to reduce the lag. And knowing Klei and their "care" for Don't Starve ... no change is coming boys. Don't even hope for any improvements. 

Well, good for me then, since I do not have your problems. But since they seem to be almost completely self-inflicted, I have officially now stopped caring about your issues. The thought that there may be nothing Klei can do because they are hitting tech limits has obviously never crossed your mind. "Demanding" things are fixed gets you usually one thing though: You will be ignored, and rightfully so. 

[nets]

One thing worth mentioning on general lag issue with all you guys that see lots of lag. If i let my CPU's power configuration is set to allow maximum of 100% and not 99%, it will turbo and it will throttle and that causes severe - jarring - lag. If i leave it at 99% (3.5ghz), the lag is dramatically reduced, even if FPS is low.

[Nitroturtle]

3 hours ago, tzionut said:

@Ashpoker under you have my save game 1917 cycle....aprox. 5 minute loading of the game, 10 seconds saving in game and I am playing only whit 3x speed. Load it and tell us if is any difference from your 1000 cycle game in fps (except the loading time). I can play it whit my i3, 2 gh procesor, 8 ghz ram, and 1 ghz dedicated video card, so a more weak laptop then your. 

Utopia.sav

On my i7 8700k and gtx1060 it took me 45s to load from a freshly started game and runs at 40-45fps on triple speed (30-35fps on 10x speed).

[Oozinator]

3 minutes ago, Nitroturtle said:

On my i7 8700k and gtx1060 it took me 45s to load from a freshly started game and runs at 40-45fps on triple speed (30-35fps on 10x speed).

Then i am more then happy with my i2500k performance.
For 10 frames i put not so much cash on the table. ^^

[chemie]

20 minutes ago, Oozinator said:

Then i am more then happy with my i2500k performance.
For 10 frames i put not so much cash on the table. ^^

my i2500k gets way more than 10 fps.  more like 45 as long as I dont open up pipe overlay

[ToiDiaeRaRIsuOy]

This does give me an idea...

Let's do a benchmark thread with that save file!

[Oozinator]

1 hour ago, chemie said:

my i2500k gets way more than 10 fps.  more like 45 as long as I dont open up pipe overlay

 

+10 additional frames with an i7 8700k , i mean

[Ashpoker]

19 hours ago, ToiDiaeRaRIsuOy said:

Let's do a benchmark thread with that save file!

When or if you do the benchmark thread (great idea), drop a link please. I'll add my 2 cents  

[ToiDiaeRaRIsuOy]

2 minutes ago, Ashpoker said:

When or if you do the benchmark thread (great idea), drop a link please. I'll add my 2 cents  

 

[Ashpoker]

thank you  i'll post my specs/times in about 30h since i'm away from home now. However i can't help myself and i will add a note that quite big portion of the map is vacuum and there are no ranches (i will check first if that's true because i can't remember) .... and that the game should run good without these measures.

[TheGCat]

22 hours ago, Oozinator said:

+10 additional frames with an i7 8700k , i mean

6 Years difference. Not much in comparison. I would say, a disappointment.  Save your money 

[Stoned]

I am currently in cycle 3200 with 90 dupes. Couple of hundreds of slicksters, some hundred other critters. 95% of map uncovered and used somehow. I play 1x speed, I prefer the challenge of having more dupes rather than upping the game speed.

Hardware I7-7700k, 16 gb ram. I have lag of course, but it is okay.. In my experience massive frame drops occur during the start of a work shift when all dupes look for errands and try to find a path to their workplace. What really helped me was using shifts with the help of scheduling. That way I split my population in 4 equal parts. Also a tube network helps a lot, I think it greatly reduces pathfinding issues.

Worst lag is when a lot of dupes do work in the space biom in jetsuits. Also bad is extensive work on piping or vents.

Hope this helps a bit

[Gurgel]

8 hours ago, Stoned said:

I am currently in cycle 3200 with 90 dupes. Couple of hundreds of slicksters, some hundred other critters.

Impressive! I feel like a small-time amateur now...

[Cilya]

I've been tricked into starting a game in a larger map (x2 width and height, x4 area) by someone on this forum which claimed that the game was fast enough for large maps. Indeed, I've seen huge improvements since the days I started to play ONI.

However, the game began to be really slow. Only cycle 825 and 46 dupes, and I don't want to stop growing my colony there. I don't really care playing at 10 fps. If I need to give orders, I can just pause the game and give a lot of orders with a high fps. Most of the time, I do something else while the game try to run the simulation.

Here is the real problem for me : AI lags behind. When the game starts to run slow, you see your duplicants doing nothing, just waiting for the processor to compute his next task. The colony starts to be very inefficient. Duplicants can accomplish less and less tasks each cycle, staying idle most of the time. It seems critters are handled last. Actually it's so slowly updated, that critters forget to eat. If I pause the game and leave them the time to think, they will feed themselves when unpausing. This means less production from the critters, and unbalances in input/outputs of the colony.

It seems there is a lot of superstition about the game speed. Some people have seen improvements on some situations and deduce a causal relation where there is only a weak correlation. The physics simulation have been blamed, but tests in debug mode have shown no improvements while trying to reproduce the proposed strategies. A small calculation shows that the number of physical computation to do for a whole map is not that big for a computer. The path-computing problem has also been mentioned, with the particular aspect of loops. While it may be true, it is really surprising : loops are a problem for depth first search algorithm, but not for dijkstra/A* algorithms which are only affected by the size of the graph. There are also suspicions about the graphics hardware which should not really have more impact at cycle 800 than at cycle 100.

Back in 2017, I used the super slow mode to run the game. It works well to reduce the AI lag. I wonder if it is not buggy though, and if some actions may not be scaled down properly. Anyway, it's really slow. Do you know of ways to have a slow speed, between the one arrow normal speed and the super slow mode ?

[gracefool]

On 5/9/2019 at 1:22 AM, nets said:

I agree that the game needs much better performance. And looking at Factorio and the scale you can do things there on the same hardware, versus this game, in programmers perspective... Let's see what the release brings. I'm hopeful and can hardly wait!

Factorio isn't a straightforward comparison. Yes it can handle a far larger amount of stuff moving around. However those things are themselves very simple - things rarely interact with each other, those things that do interact en-masse only do so via inserters and robots. Therefore inserters and robots are the big bottlenecks. There's also almost no pathfinding to calculate. In ONI everything has temperature, pressure, mass and all interact with each other. Essentially, as a basic game concept, ONI isn't very scalable.

On 5/8/2019 at 8:51 PM, OxCD said:

Anyway, the OP point remains. And when your game goal becomes only to do not develop more your colony, but just adapt it for lower lag (cleaning everywhere, having small dups number, tiny (or zero) number of critters, reduced pathfinding, vacuum everywhere, etc...), i share it as a pain in the... bottom. 

Would you by a game that has this as a main description ? "Build into a world where ressources are abundant, get more ressources from space, then to achieve clean everything, get rid of the unnecessary, delete most of the colors, savors, & scents, and make it a world of emptiness. Only few souls, and the vacuum, will lead you to the road of glory."

On 5/9/2019 at 2:17 AM, Ashpoker said:

So, am i to assume that we as players (customers) must employ these borderline ridiculous measures (vacuuming the map, low number of dupes, no critters) just to play the game (product we paid for) ? That's complete insanity. We should be able to play the game as WE want, not as the game is forcing us to play. Speaking for myself i want ranches for meat and i simply refuse to kill every critter just to reduce the lag (only the flying ones can die).

This is a problem with all big simulation-engineering games, including Factorio. That's why any Factorio player knows that to have the biggest base you need to use robots, because it reduces the number of moving parts. And why Dwarf Fortress players know you have to do whatever you can to reduce pathfinding complexity for your dwarves (for instance limiting the number of doors that dwarves have to check for permissions).

It's an inherent part of simulation, there is absolutely no way around it. If it's large and complex, you can't just do what you want. Stop and think about what you're doing: simulating hundreds of thousands of objects, not just numbers, not even just visual objects, but physically interacting objects. Even if you have a computer at the theoretical upper limit of what's physically ever possible! We have a pretty good idea of this, because everything is subject to the laws of thermodynamics: if we had kept progressing CPU speed as we were until the mid-2000s we would've reached the absolute physical limit in under two hundred years - that is, where your CPU is a sun with a black hole as a hard drive (representing the physical limits of energy and density). Even then, you'd still have into this problem - there's a limit to the number of objects you can simulate, and it's an insignificantly tiny number compared to the number of logic gates in your computer.

Also Factorio has been in development for seven years. They've improved performance significantly in that time. In 2018 Factorio was in the top 100 games by profit on Steam, so they have the money to spend on it. ONI is not in the same position, so it's quite unreasonable to expect similar performance, and likewise it's unreasonable to expect Klei to continue significant development on it if it doesn't have really high sales.

 

On 5/9/2019 at 5:52 AM, Ashpoker said:

This is perfect example of where my suggestion would be useful. To have the option to turn off building animations and turn off generating reports. because if you're not using them they're just performance hog. Also animations ... meh, couldn't care less.

Yes. I don't see any reason not to do this, it could even be an unsupported option enabled by ini file...

[Stoned]

21 hours ago, Cilya said:

Here is the real problem for me : AI lags behind.

That is true. I don’t have issues with the frame rate or building orders. But the colony was about as effective with 45 dupes as it is with 90 due to this. As in real life, when you go from small business to large corporation.

[KittenIsAGeek]

On 5/7/2019 at 4:06 PM, Ashpoker said:

no sane person plays on slow speed. 3x speed is normal speed and i'm playing in superspeed all the time. ok then, under 30 fps it's unplayable. it takes them literally forever to do anything. the game is very very slow.

I suppose I'm insane then.  I regularly play on normal speed.  Of course, ONI isn't the sole focus of my attention, so...

8 hours ago, gracefool said:

This is a problem with all big simulation-engineering games, including Factorio. That's why any Factorio player knows that to have the biggest base you need to use robots, because it reduces the number of moving parts. And why Dwarf Fortress players know you have to do whatever you can to reduce pathfinding complexity for your dwarves (for instance limiting the number of doors that dwarves have to check for permissions).

It's an inherent part of simulation, there is absolutely no way around it.

Yes, this.  ONI is very heavy on calculating algorithms because it is an engineering simulation.  There's no way around it.  There's pathfinding for critters and dupes, gas and liquid interactions, temperature changes, gas and liquid piping, electric circuits, automation, shipping, rocketry, etc.  Preferably, all these algorithms will be logarithmic or better.  If any are linear (or exponential),  the old map-wide shov-vole pathfinding, for example, then you're going to slow to a crawl as your base develops.

Even if they're all logarithmic, there's so many of them that they're going to have an impact on your system performance as you continue to add to your base.

[Gurgel]

21 minutes ago, KittenIsAGeek said:

Even if they're all logarithmic, there's so many of them that they're going to have an impact on your system performance as you continue to add to your base.

Path finding is necessary linear or worse in the size of the map. Even if you cut search-paths fast (and then get a lot of complaints from players feeling entitled, but with no clue how this works), you need to look at each tile in the path. Partial path re-use does not really work, as the world is dynamic and the tasks change all the time. Sure, if you do not have real-time requirements, things get better. But a game may not just hang for a few seconds, that is worse than sub-optimal paths. They do have dupes standing around and "ponder", but it is not all at the same time. Quite an elegant solution IMO. 

Factorio is massively different: Most of the map does not change from one planning cycle to the next. Most activities stay exactly the same, with minimal pre-conditions, and their plan can just be re-used.

My guess is that too many people have heard too much about "AI" and now think computers are magic and anything that is laggy or not optimal with regards to result is just the fault of the coders. Not so. "AI" (which, incidentally, has no "I" to speak of these days, and may never have that), cannot get around problem complexity. It cannot get results faster. It cannot generate better results faster. It cannot generate better results in the first place. What it can do (and that is a huge factor) is massively reduce coding costs for very complex problems, but it universally produces worse results and is almost universally slower at that. It also comes with a few surprising pitfalls, which usually are non-obvious. It is pretty unsuitable for planning problems, unless you can live with some things just never being done. If you need "fairness" (everything at the same priority gets done eventually), you are back to queuing theory, one of the hardest theoretical CS subjects with massive real-world relevance. 

Most things the ONI kernel does are problems were the _problem_ complexity is linear or worse, even if you accept significantly sub-optimal results. This means there cannot be any algorithms in this universe (where we do not have magic) that are faster. Not possible and you can prove that. Concrete algorithms will often be _slower_ however. And then you add that this is a real-time simulation, which makes things a lot worse. 

I have some experience in the simulation space from my PhD. I am constantly amazed that Klei gets this high grade of performance, mostly reasonable plans, no lockups and pretty good real-time characteristics. They must have some very smart, very educated and very experienced people to get anywhere near the performance they deliver. So please stop claiming that "they should just optimize this". All that does is make you look clueless. 

Yes, I am aware that the "I think this is easy" -crowd will be all overt this again. It is not easy. And it is not even easy to explain why it is not. Do CS up to at least a MSc with specialization in algorithms, simulations or planning and then come again. At that time, you will understand what I am talking about.

 

[Nightinggale]

8 hours ago, gracefool said:

Factorio isn't a straightforward comparison. Yes it can handle a far larger amount of stuff moving around. However those things are themselves very simple - things rarely interact with each other, those things that do interact en-masse only do so via inserters and robots. Therefore inserters and robots are the big bottlenecks. There's also almost no pathfinding to calculate. In ONI everything has temperature, pressure, mass and all interact with each other. Essentially, as a basic game concept, ONI isn't very scalable.

There are two parts to "scalable" here. One is the pure number of calculations, the other being how related the calculations are. Take for instance combinators. Each tick they read the input, does their calculations and write to the output. However the output they write to is the signal for the next tick. This means if we have combinator A writing to a wire and combinator B reading from that wire, it doesn't matter if A or B is calculated first because B will read what A wrote on the wire last tick. This allows calculating both at the same time, which is a requirement for using more than one CPU core. Factorio is full of such independent calculations and is getting decent at spreading the workload to multiple CPU cores.

ONI on the other hand tend to have calculations, which depends on the output of the previous calculation. If one dupe decides to pick up something, because it's priority 9, the next dupe won't do it because it's already reserved. To make that truly parallel then it would be a requirement that both dupes would pick up the same item at the same time. Likewise temperature changes and gas/liquid pressures change according to temperature and pressure of surrounding cells. Once again this means the calculations are much harder to move to multiple CPU cores. As a result ONI is by nature of calculations depending more on single core performance than Factorio. It's not that there is something wrong with ONI, it's just that it's the result from the type of game it is.

Factorio's great performance come at a cost. There are plenty of tasks, which can't be implemented because it would slow down the game noteworthy. Pathfinding is near non-existing. Bots ignore everything and move in a strait line. Biters have a low CPU power pathfinding, which not only is horrible at finding a short route, it is not even able to find a route at all even if one might seem obvious to humans. As a result biters has a tendency to sometimes wander around seemingly at random, which has then made it into the game as a feature. It's not a problem until AAI vehicles modded in vehicles and gave it biter pathfinding. That makes the vehicles run into buildings, trees, each other and generally just get lost way more often than you would expect when you watch biters move around. There are plenty of other examples where Factorio is designed to be fast rather than for gameplay, but I can't remember any other cases offhand.

Train pathfinding is horribly slow in Factorio in certain designs. Particularly "roundabouts" where trains can turn around can be horrible if multiple are connected and the pathfinder decided to test what happens if the train goes back and forth between those two for a while.

[miauly]

2 hours ago, Gurgel said:

Path finding is necessary linear or worse in the size of the map.

Pathfinding looks like something that can be cached pretty heavily. As for other mechanics, I'd say that the biggest performance impact can be made on design step. Trying to add performance after the implementation is done is usually virtually impossible, but it does not mean that a game like ONI can't be implemented to run smoothly if you take performance into account when you design the mechanics in the first place. Maybe a way to do with gases is to rethink their motion rules, for example. A game does not have to be an accurate simulation of any consistent physics in order to be interesting and enjoyable to play, but it does have to be playable performance-wise to be enjoyable.

And saying that ONI is now fine is simply not true. The game requirements on the Steam page list 2 Ghz Dual Core. When I played on my laptop with 2.4 * 8, I got 7 FPS on cycle 50-ish. You can argue here that 30 is perfectly fine and I agree, but 7 is unplayable. People who benchmark here and report playable 30 are running on what, 4 Ghz? Now, how likely is for an average newcomer after a release to have this kind of CPU? And how likely it is for people to have a modern laptop with clock speed purposely lowered for heat and battery management? If the game is playable only on near-top desktop CPUs, then Klei might as well list those 4 Ghz it in the performance requirements on the Steam game page. Only they won't. And while 2 Ghz are here, those should be the setup to benchmark on, and on it the game clearly needs performance improvements.

[natanstarke]

5 hours ago, miauly said:

Pathfinding looks like something that can be cached pretty heavily. As for other mechanics, I'd say that the biggest performance impact can be made on design step. Trying to add performance after the implementation is done is usually virtually impossible, but it does not mean that a game like ONI can't be implemented to run smoothly if you take performance into account when you design the mechanics in the first place. Maybe a way to do with gases is to rethink their motion rules, for example. A game does not have to be an accurate simulation of any consistent physics in order to be interesting and enjoyable to play, but it does have to be playable performance-wise to be enjoyable.

And saying that ONI is now fine is simply not true. The game requirements on the Steam page list 2 Ghz Dual Core. When I played on my laptop with 2.4 * 8, I got 7 FPS on cycle 50-ish. You can argue here that 30 is perfectly fine and I agree, but 7 is unplayable. People who benchmark here and report playable 30 are running on what, 4 Ghz? Now, how likely is for an average newcomer after a release to have this kind of CPU? And how likely it is for people to have a modern laptop with clock speed purposely lowered for heat and battery management? If the game is playable only on near-top desktop CPUs, then Klei might as well list those 4 Ghz it in the performance requirements on the Steam game page. Only they won't. And while 2 Ghz are here, those should be the setup to benchmark on, and on it the game clearly needs performance improvements.

Agreed, the requisites on steam should change at least for recommended settings. I really wanna see oni succed and lots of mods, biomes and official contents i can see ppl loving the game at first and then slowly getting angry as they learn to reach late game and see that its definetly not possible to have 1 ranch for each critter because of performance or have jet packs. Thats why i really vote for we to be able to test it before launch to make at least the first contact ppl have to be supremely god for them to call even more ppl to the game and so on. " on the other hand oni is popular already and lots of ppl who wanted it probably already have it, therefore again no probs on having a preview test branch".

[Gurgel]

5 hours ago, miauly said:

Pathfinding looks like something that can be cached pretty heavily.

No, very likely not. And I am not even going to explain why. It is obvious when you have the background. 

[miauly]

2 hours ago, Gurgel said:

No, very likely not. And I am not even going to explain why. It is obvious when you have the background. 

Well, I do have the background and it's not obvious for me. Would you please elaborate?

My thinking is that there are not that many things that happen to change the available paths, aside from things like MOGOM-style automation, so the cache should not be that big if we use it to collapse parts of the the graph we navigate on. I do not know how the thing is implemented, but if it runs per-tile, collapsing it per-"room" should make graphs comparably small on simple-organized maps. Updating the cache is tricky, but can be simplified if we only cache what is easy to update. But of course this may be already implemented. Or not, because it would help jetpack lag and the thread about it now have how many comments that people avoid a cool mechanics because it lags the game?

Critters should also be not that complicated, poor things have how many actions really requiring pathfinding during a cycle? Go to eat, go to rancher. All the other time they just oscillate around, does it even need pathfinding? Are you for example familiar with how birds were "programmed" back in the days when 2 Ghz CPU was not anywhere near? Someone came up with basing their movement on rules of proximity and then later scientists discovered that's how actual birds and herd animals move. Hatches have one degree of freedom, or more accurately they have only two tiles to oscillate, at any point of time and bugs have slightly more, so of the top of the head we could roll after each step they make with some preference to keep going where they were that's declining. 

I would think that everyone would understand if for example thousands of critters and hundreds of dupes degrade performance, but not couple hundreds of critters and a dozen of dupes because for example the former share the pathfinding code of the latter.

[KittenIsAGeek]

21 minutes ago, miauly said:

Well, I do have the background and it's not obvious for me. Would you please elaborate?

My thinking is that there are not that many things that happen to change the available paths, aside from things like MOGOM-style automation, so the cache should not be that big if we use it to collapse parts of the the graph we navigate on. I do not know how the thing is implemented, but if it runs per-tile, collapsing it per-"room" should make graphs comparably small on simple-organized maps. Updating the cache is tricky, but can be simplified if we only cache what is easy to update. But of course this may be already implemented.

Critters should also be not that complicated, poor things have how many actions really requiring pathfinding during a cycle? Go to eat, go to rancher. All the other time they just oscillate around, does it even need pathfinding? Are you for example familiar with how birds were "programmed" back in the days when 2 Ghz CPU was not anywhere near? Someone came up with basing their movement on rules of proximity and then later scientists discovered that's how actual birds and herd animals move. Hatches have two degrees of freedom at any point of time and bugs slightly more, so of the top of the head we could roll after each step they make with some preference to keep going where they were that's declining. 

I would think that everyone would understand if for example thousands of critters and hundreds of dupes degrade performance, but not couple hundreds of critters and a dozen of dupes because for example the former share the pathfinding code of the latter.

Assuming that you have a robust method of caching frequently traveled paths, your big-O would still be worse than linear because you'd have to 1) check if your path is in the cache, then 2) check if your partial path is in the cache, then 3) formulate your new path.  Generously assuming that 30% of the time you get a hit for #1, you're still looking at however many iterations it takes to determine if your path is already in the cache.

One huge problem that plagues the autonomous control industry (self-driving cars, auto-pilot drones, google maps, etc) is the traveling salseman problem.  Basically you have a number of points that you must travel through in the shortest distance.  A human brain can solve the problem almost immediately, but a computer has to iterate through most* possible combinations.  This means that its generally an exponential growth problem.  I remember in the late 90s when a computer would be brought to its knees just by having 10 points to travel through.

I mention all of this because you're looking at the problem from a human perspective. To our brains, it doesn't seem to be that monumental of a task to figure out how a dupe gets from where they're at to the job they need to do.  However even a highly optimized pathfinding algorithm for the dupes will scale dramatically with both the navigable area of the map and the number of dupes.  One or two dupes with a dozen possible paths? No problem.  10 dupes with 300 possible paths?  Even if it takes only 1/10th of a second, it will adversely affect your frame rates because during that time, the game isn't doing anything else.  Add to that all the other calculating that has to happen (temperature, air flow, piping, etc) and its amazing this game works as well as it does.

On 5/8/2019 at 11:52 AM, Ashpoker said:

This is perfect example of where my suggestion would be useful. To have the option to turn off building animations and turn off generating reports. because if you're not using them they're just performance hog. Also animations ... meh, couldn't care less.

Building animations are practically nothing as far as your game performance is concerned. The vast majority of the "lag" in ONI is due to all the math calculations that are done on every tile every second.  Your GPU gets almost zero use.  Unless you're using software rendering, you wouldn't notice any difference between the animations being on or off.