@penguin_ said in Reclaim Brush:
This can be implemented in a way that's not laggy and doesn't add too much processing burden - It can be done in a sensible way
The command queue is seriously limited in how much orders it can take care of. We'll take the ringing feature as an example.
Do the following:
- Spawn in 10 t3 RAS SACUs
- Make a t3 extractor
- Move away from the extractor (you can teleport using alt + t)
- Continuously try to ring the extractor with storages and fabricators (in rapid succession, just keep clicking)
- See how much the game stutters by looking at how the SACUs move
This means that making 130 (10 * (4 + 9) = 130) orders cause a noticeable stutter. Let alone if these happen two or three times in a row.
Now imagine if a player uses several (say 10) engineers to create some reclaim orders over a large naval battle they had in front of their bay. The ocean floor is populated with air wrecks, hover wrecks and boat wrecks. It can easily be 200+ wrecks for the average during the late game. That means we'd need to make at least 200 individual orders over 10 engineers. We likely want some redundancy, so lets say that every wreck is part of a queue of at least two engineers. That makes for 400 individual orders. And now imagine you missed a bunch of those reclaim orders because you forgot the offset with the ocean so you redo it, causing another 400 orders.
Tada, you have significant stutters .
Let alone that:
- you'd need to make semi-efficient choices for the engineers to determine their reclaim. How do you determine that? And what does efficient mean?
- the input size (engineers or reclaim) will always be a relative large set (anything between 50 to 500 individual reclaim instances is not unusual after a late game fight). Processing such a large set is not recommended when you are on a strict budget (and we are - very much so. Game still slows down!)
- there would be several people trying to issue these type of commands at the same time (say, within a few seconds after a battle is over)
And then we're assuming that there are no players with malicious intend .
and it can have limitations to its impact on processing, if desired (ie: small max brush size, tick-based limitations, max order limitations, etc).
A user should not have to deal with arbitrary limitations because the game can't manage it. If that is the case then it shouldn't be part of the game to begin with.
It would be consistent with FAF's precedent/pattern of adding UI improvements/features that reduce click count and improve QoL for most users - some examples:
o (1) spread attack
o (2) spread move
o (3) templates
o (4) hotbuild
o (5) gazui
o (6) advanced target priorities
o (7) eco manager
o (8) supreme scoreboard's 1-click resource sending
o (9) easy ringing of storages/pgens/fabs
o (10) automated mass fabricator behaviori:
Some of these cause significant performance issues: (1), (2) and (10) can flood the command queue quite easily, this can cause stutters during the late game. (7) is replaced by the automated mass fabricator because it could happily disable hundreds of fabricators, causing a jump in sim time. And (6) has some insanely detailed target priorities which turns out to be quite expensive on the sim, as I'm trying to tell you all in another topic.
These are not exactly great examples when we're talking about performance.
This is effectively the same as area commands which has already been heavily discussed on this forum here https://forum.faforever.com/topic/2054/beating-a-dead-horse-area-commands/12?page=1
and on the old forum which I will link when I find it
Edit: found em, have fun reading
https://forums.faforever.com/viewtopic.php?f=2&t=13632
https://forums.faforever.com/viewtopic.php?f=41&t=8471&start=20d this video in one of the threads:
Found a video in one of the topics:
I got to give it to them, it does look fancy .