Jump to content

It's faster if we all store it together.


Recommended Posts

I found a slightly interesting phenomenon.
Sorry if it's a known one.

 

The work of storing debris in storage is more efficient if multiple people do it at the same time.
Perhaps more accurately, doing it with multiple people will reduce the animation time for pick-up and delivery.

Spoiler

 

There is no level difference in everyone's Strength skills.

 

If you try it with Auto-Sweeper, it's easy to see the difference.

Spoiler

work speed : 1 < 2 = 3 < 4

 

By the way, it seems that two Auto-Sweepers are still faster than the one that speeds up by shining light on one Auto-Sweeper.

Spoiler

 

Just in case, I posted it on the bug tracker.
But I thought maybe this was a deliberate specification designed to create a synergistic effect of collaboration.

 

Link to comment
Share on other sites

This all seems pretty straight forward and obvious to me.

Not sure what you think is a bug here. The dupes have to go through an animation, in doing so their speed is restricted. More dupes/sweepers is more simultaneous animations = faster. Have I missed your point ?

 

*edit* Completely missed the point here, after looking over the vids above/below again its clearly some janky shenanigans afoot :D 

Link to comment
Share on other sites

16 minutes ago, Lifegrow said:

This all seems pretty straight forward and obvious to me.

Not sure what you think is a bug here. The dupes have to go through an animation, in doing so their speed is restricted. More dupes/sweepers is more simultaneous animations = faster. Have I missed your point ?

Try looking at the first example again. Four dupes fills four containers in about the same time as one dupe fill half a container. In other words about twice as fast.

All the dupes play out their full animation just faster when there are more dupes. Even the containers play the animation at a faster speed when filled by more than one dupe or sweeper. To the point where the container seems to even skip frames in the animation to keep up.

So maybe the answer isn't in the dupes or sweepers but in the storage containers?

Link to comment
Share on other sites

It's just a guess on my part, but I had a feeling that there was a bug (or a spec) where multiple pick-up events to the same target, or multiple delivery events to the same target overlap, and those animations end early.

I have prepared another example. Maybe it's a hint.

I prepared several Duplicants with the same movement speed and let them carry the debris.
If you look closely, you can see that the animation is shortened only when the pick-up and delivery overlap.
With this, you can see that the four people starting from different points are gradually aligned.

Spoiler

Next, I compared the time it takes to distribute the material to the monument base with Auto-sweeper.

Spoiler

In these cases, the central pattern has the fastest delivery.

Spoiler

If the pick-up source is scattered, it is slow.

 

Link to comment
Share on other sites

Sorry for asking you instead of doing it myself, but could you try the first test with N dups and N+1 bins? Like 1 dup 2 bins vs 4 dups 5 bins.
There might be more than one mechanism at play. We're looking at the actors here (dups or sweepers) and I'd like to rule out bins being the bottleneck is some way  (maybe indirectly).

To elaborate: say that after a delivery, there's a delay before a new errand is generated/acquired. This could be the dup's fault not looking around what to do immediately, like entering a idle state for a tick or two before updating the queue. We know queue updating is a low prio jobs for the scheduler, being one among the things that are hit more by lag.

Having N+1 bins ensures (at least until the first bin is full) that the dups' queues are never empty.

Also (I admit it would be weird in a cute way) maybe dups hurry up when they have multiple errands to run, and take it easy on their very last thing to do for the day.

Anyway good job.

Expecially the "synchronizing" dups is a very interesting finding. It is possible the devs have introduced some kind of optimization for large population colonies that leads to this.

Link to comment
Share on other sites

30 minutes ago, TheMule said:

Sorry for asking you instead of doing it myself, but could you try the first test with N dups and N+1 bins? Like 1 dup 2 bins vs 4 dups 5 bins.

I increased the storage bin by one.
With 5 Storage bins, 4 people have more time to move, but there seems to be no other change. Perhaps.

Spoiler

 

Link to comment
Share on other sites

Interesting phenomena. Here's some data and conclusions from two different tests to help out.

image.thumb.png.bad134cd2125490bf864a8912be9d709.png 

In the top test each sweeper group pulls from one pile and puts in one bin. The sweeper cycles through 3 activities. Picking up Sandstone, Storing Sandstone, and Storing materials. Used alt= to advance per frame and counted number of frames in each activity. Game was running at approximately 80 fps (important), counts varied by a couple frames +/-.

1 sweeper: 126 frames in Picking up Sandstone, 128 frames in Storing Sandstone, and 68 frames in Storing materials.

2 sweepers: 67, 66, and 28.

3 sweepers: 45, 47, and 68.

4 sweepers: 36, 33, and 8.

Picking up and the first Storing appear to simply be the task time divided the number of sweepers (roughly). The second Storing took me a bit to figure out, but it looks like the time needed to get to the next whole second. 1 sweeper spends ~3.2 seconds picking up and storing, then another ~0.8 seconds in the second storing. My guess is that the sweeper only looks for a task once a second, after finishing a task it idles until the next second comes around. This idling time is the Storing materials in the status display.

 

Bottom test explored the Picking up and Storing tasks. Sweepers picked up from separate piles and delivered to the same bin. Or picked up from the same pile and delivered to separate bins.

2piles1bin: 125 frames Picking up Sandstone, 65 frames Storing Sandstone, and 48 frames Storing materials.

1pile2bins: 67, 125, and 48.

Again the tasks with multiple users are divided by the number of users and the second storing task is the time to the next whole second.

 

My overall conclusion is something like each animation has a timer for how long it should run. Each frame this timer is advanced with the time elapsed since the last frame. The bug being that each dupe/sweeper interacting with the object advances all the timers instead of just their own. Or maybe they all share the same timer. Or something like that. Do we all remember the offscreen bunker door animation issue?

 

 

Link to comment
Share on other sites

Here's an interesting observation.

Regular and smart storages behave the same. And the maximum storage setting doesn't seems to matter either.

The interesting part is that 3 sweepers appear to be 3 times faster than 1 sweeper. Pretty logical so far. However, 5 sweepers appear to be 3 times faster than 3 sweepers. And having 7 sweepers doesn't appear to increase speed over 5 sweepers in any way.

Note that 10T of material is stored in each case. The difference in the storage meter is due to setting it to store either 10T or 20T at max to see if that had any relevance.

These results makes my initial instinct that the effect is not related to the dupes or sweepers at all but most likely the cause lies in the how storage errands are handled.

store20tregular.thumb.png.15462f6a9b862715903144a259f1ef38.pngstore10tregular.thumb.png.ba1cbf2ce20df60444f4be0a844bbeaf.pngstore20tsmart.thumb.png.e70ec67423ce26fa00ba4f16b7208605.pngstore10tsmart.thumb.png.7d3d2ecffb0677c394a35207d149d35c.png

image.png

To see where the limit was I tested again with 2, 3, 4, and 5 sweepers since we know from above there is no gain after 5 sweepers.

image.thumb.png.7e05f036eaab53f4fb8d57b81e63715a.png

Same test as above just with 20T of material instead of 10T

image.png.a7e57e82aefe438b57c1e126319a3fe9.png

With the original setup storing 20T of material we do however see a difference between 5 and 7 sweepers

image.thumb.png.59277d415b89c163f7d1db25ec6fb1a5.png

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...