Factorio Forums

Due to a certain love I had for another space-themed overhaul mod, I have committed to the life of predominantly using Laser Turrets on my ships. I figured (perhaps erroneously) that relying on laser turrets would lead to less active projectiles, less explosions, less effects, etc etc, in the long run for UPS optimization

After recent optimizations surrounding asteroids and collectors, I was excited that my game may run more stable. I have recently disabled pollution via console command to increase performance, so all turrets on planet surfaces have basically become inactive.

I had/and still have 3 large ships running towards the shattered planet for collecting promethium. Across all surfaces combined, there seems to be some threshold of 'Turrets' where they start to massively degrade performance.

I have searched and noticed this has been mentioned one other time (120678). I can continue to attest that trimming down individual turrets does not seem to do anything in terms of performance - but I have not tried deleting entire ships.

I have attached a screenshot showing the turret UPS usage when all three ships are active. I have attached a link below to a Google Drive containing the save and the log file at the time of turret UPS usage being particularly punishing.

If this is not considered a bug I would greatly appreciate your team's or other user's guidance on tips for optimization. Appreciate all the work you do

https://drive.google.com/drive/folders/ ... drive_link

Thanks for the report however there is nothing to do with this. This is simply the performance cost of turrets with the amount of them you have built. When a turret goes to find something to shoot it will iterate all of the things in range of the turret and select the "best" one. The more things in range and the more turrets you have the more expensive this gets.

Thank you for taking the time to reply. I believe there to be something else at play here other than more turrets = more UPS time, but will do some further testing myself and update this post if I find something quirky. Have a happy new year

Rseding91 wrote: Tue Dec 31, 2024 4:51 pmThanks for the report however there is nothing to do with this.

It would be great if this could get added to the list of potential performance optimizations for 2.1. Right now promethium science is far and away the biggest bottleneck for megabases. Giving turret and asteroid collector updates the multithreaded treatment like you did for belts would make a huge difference.

See this thread for context. I've got ~12 CPU cores sitting there doing nothing. Put those cores to work!

spacedog wrote: Tue May 13, 2025 9:27 am

Rseding91 wrote: Tue Dec 31, 2024 4:51 pmThanks for the report however there is nothing to do with this.

It would be great if this could get added to the list of potential performance optimizations for 2.1. Right now promethium science is far and away the biggest bottleneck for megabases. Giving turret and asteroid collector updates the multithreaded treatment like you did for belts would make a huge difference.

See this thread for context. I've got ~12 CPU cores sitting there doing nothing. Put those cores to work!

That's not possible to do. They must first and always be deterministic: having multiple turrets scan and acquire targets in multiple threads is not deterministic and so we can't do it.

Rseding91 wrote: Tue May 13, 2025 1:36 pm That's not possible to do. They must first and always be deterministic: having multiple turrets scan and acquire targets in multiple threads is not deterministic and so we can't do it.

I take it this is the case even if they're on different surfaces due to scripting?

Jap2.0 wrote: Tue May 13, 2025 10:28 pm I take it this is the case even if they're on different surfaces due to scripting?

Well, in the case I linked above, that was in the sandbox with a completely empty nauvis, no other planets, and just the one space platform. Having it be multithreaded per surface would probably be an easy change with low regression risk, but I doubt it would make a noticeable difference if the issue is coming from a large space platform deep into a promethium chunk collection journey.

Rseding91 wrote: Tue May 13, 2025 1:36 pm

spacedog wrote: Tue May 13, 2025 9:27 am

Rseding91 wrote: Tue Dec 31, 2024 4:51 pm Thanks for the report however there is nothing to do with this.

It would be great if this could get added to the list of potential performance optimizations for 2.1. Right now promethium science is far and away the biggest bottleneck for megabases. Giving turret and asteroid collector updates the multithreaded treatment like you did for belts would make a huge difference.

See this thread for context. I've got ~12 CPU cores sitting there doing nothing. Put those cores to work!

That's not possible to do. They must first and always be deterministic: having multiple turrets scan and acquire targets in multiple threads is not deterministic and so we can't do it.

Oh, man... never ever tell a software engineer something isn't possible.

It's 100% possible, and fairly trivial at that. I completely respect that it may not be work the team wants to do, for example if it would require an intrusive enough change that the risk of regression is too high. But it's really not that complicated:

1. As preparation, you'd need to have each turret keep track of how many other turrets have overlapping firing ranges. This is mostly static, and only needs to be recalculated when turret placement/orientation changes (not when turrets are disabled/destroyed).
2. For each turret that is not disabled/destroyed or out of ammo (this is the multithreaded part), find the N+1 best targets where N is the number of turrets that overlap. For example, if a gun turret overlaps with 3 other gun turrets, find the best 4 targets. You're already scanning every possible target anyway, so keeping this list as you go is a very small additional overhead. But it allows fast resolution of contention later, because it guarantees you'll have at least one target that the other turrets won't end up targeting.
3. Once that's done, iterate over each turret again (single threaded, so it's deterministic). Go through the list of targets that each turret identified in the previous step, in order. Once a target is found that still has health remaining, subtract health per the turret damage.

I get the sense the logic for the asteroid collectors is more complicated than for turrets, but I bet a similar approach could be used there as well.

spacedog wrote: Thu May 15, 2025 9:21 pm Well, in the case I linked above, that was in the sandbox with a completely empty nauvis, no other planets, and just the one space platform. Having it be multithreaded per surface would probably be an easy change with low regression risk, but I doubt it would make a noticeable difference if the issue is coming from a large space platform deep into a promethium chunk collection journey.

In your case...

spacedog wrote: Oh, man... never ever tell a software engineer something isn't possible.

It's 100% possible, and fairly trivial at that.

https://xkcd.com/1831/

I can point you to further reading if you're interested.