• Content Count

  • Joined

  • Last visited

Community Reputation

89 Excellent

About Chthonicone

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Step 1, automation is rail working off screen as normal. It's not actually moving the actual position of the materials when not looked at for performance gains. It only tracks where on the rail it would be. Step 2, Person looks at the rail causing everything to jump to where it should be. Step 2a, first the game moves all the materials to where they should be in the world. Anything trapped in a wall isn't moved from the starting tile in the rail. Step 2b, now the game builds the box for each item on the rail, and puts the item in the box. Step 3, now you have one or more empty crates on your rail, and at the beginning of the rail you have resources that should be in those empty crates but aren't, and they appear to be floating on the rail without a crate. This is the method to reproduce the bug. If you want to have an easy time to reproduce it have a rail that goes into and out of a checkerboard tile that is made to move slowly by an automation gate. Look away and let the automation run for a time, and then look at it and pause. You will see a bunch of empty crates in the walls, and if you let it run, it appears you have a floating resource near the beginning of the rail. To be clear, the resource is actually where it appears to be! All thermal transfer to and from the resource is exactly as you'd expect it at it's location, and it will stay like that until it falls off the end of the rail. Nothing comes out when the empty crates exit, and no thermal transfer happens with those crates. I don't know if the game is failing to move the item due to an exception, or if there's some assert saying an item can't be in a wall, but there is something preventing the items from actually being in a wall on a shipping rail when transitioning from off screen to on screen. My guess is it is an interaction with an optimization. See this thread for more information discussing this bug: See this thread for an example automation line that generates this bug: I cannot find the output.txt file at \Steam\SteamApps\common\OxygenNotIncluded\OxygenNotIncluded_Data\ as requested. It does not appear to be here. Edit: I added some pictures showing the empty shipping crates on the conveyor from the game not putting the ore in the right place as well as showing that the ore is showing over the conveyor loader instead. Also added my save game so you can test it. Leaky Dump.sav
  2. The search for several tiles is a simple flood fill algorithm. You start at a point and move outward. In this case you can stop the second you find the condition you want, so you don't even necessarily have extra computation time anyways. Originally, this was n=1 for 5 checks (the tile and the 4 surrounding tiles) Now it is n=5 for 41 checks (this accounts for the growth of the detection diamond, 1 + 3 + 5 + 7 + 9 + 7 + 5 + 3 + 1) As we can see, at this scale, it is roughly n^2 in complexity, but for small n it is negligible. After all, a thread on your computer will likely process several hundred million of these checks every second. Furthermore, because we can stop once we have found the conditions we want, likely we aren't doing any more checks than we used to in most cases. Add this to the fact that plants generally don't update every tick, but maybe once a second or longer, and this is not a frequent change. One thing that is likely to be affecting long computation times is path-finding for long paths. This includes dupes, and unrestricted critters, i.e. critters who aren't confined to a small space. This generally comes about digging out huge rooms, and just letting everything fall. Now any dupe trying to path through this area likely has many possible routes to choose from and has to figure out the best one, and critters from that area have a larger space to wander. Another thing that might be affecting long computation times is job priority sorting. The more jobs your dupes have, the more things they need to sort to decide what next to do. Good sorting algorithms are n*log(n) in complexity, which is better than n^2, but for larger n, this can become cumbersome. When your dupes have 32,000 hauling tasks from you digging out an entire area, it takes quite a few processor cycles for them to sort out their priorities upon getting a new task. Even if they keep a sorted list per dupe, adding a new item is at best n*log(n) time to integrate with some sorting algorithms, though this could be brought down to log(n)*m complexity with m being the number of dupes. In most cases here though, m would be small, and n would be the driving factor. This would be done by implementing priority as a skiplist, which has a log(n) search time, and 1 insertion time. From the way priorities are presented, I wouldn't be surprised if this wasn't already done though. Ultimately though, the devs are the ones who can tell what areas they need to optimize, as they can implement profilers to report back to them how much time is spent on things. Many of the things I mention above are things that can be run concurrently as well, as the path one dupe takes is independent of the paths other dupes take, and same for priority lists. Even the plants can be done each in their own thread that updates at a set frequency. With a thread manager to handle these threads, you can easily utilize more cores than currently the game uses (seems to be close to 4.5 cores) and improve the performance. The problem though lies in doing this, while ensuring that concurrency data problems do not occur. I.e. 2 dupes both sort their priorities and then select for the same task. This can be solved in other ways though which I won't go into. In short, you are right that this would cause more processing to be done, but the amount of processing done by this compared to how much is already done is tiny. It's a flea on a giant. There are bigger fish for them to fry than to deny such a small request that fixes other problems.