Questions about performance: Cybran build drones
-
Because simspeed lag is one of the worst aspects of this game, anything we can do to ameliorate the problem is a great idea. I don't care how many cybran drone bots are visible. In fact, I would probably PREFER to see a laser beam similar to aeon because it makes it a lot easier to see exactly what the hives are assisting. Sometimes you don't notice they started assisting your smd or something else unimportant when that was your lowest priority.
-
I had the same thought as Brutus. Since 1 hive alone doesn’t cause a huge simspeed problem, let’s leave it as it is and only change the animation once the number of hives hits a critical number where you can’t tell the difference anyways.
-
@askaholic said in Questions about performance: Cybran build drones:
I had the same thought as Brutus. Since 1 hive alone doesn’t cause a huge simspeed problem, let’s leave it as it is and only change the animation once the number of hives hits a critical number where you can’t tell the difference anyways.
Although one thing to consider is that this will increase the complexity of this portion of the code quite significantly. So we also have to consider if this is worth it from a maintenance stand point.
-
Im pretty sure in OG FA the number of build bots is exactly as you describe it, 1/2/3 per tech level. ACU has smth like 5?
Then FAF changed it, it was scaled by build power. Then the lag started, so it got nerfed and now with your changes we're going full circle, back to the original values
-
@sheikah That question applies to almost all performance optimisations.
-
The key performance issue with Cybran build bots is rather simple - unit count. Every one of those drones is a unit - and they are being created, and destroyed, at a rather fantastic pace. This has two long term side effects - each drone creates a new entity (unit) which has to be initialized just like any other unit - and when it's finished a task - it is destroyed. This process, of itself, is not very hard on the CPU except for the intangible effects of garbage collection.
The garbage collection process of SCFA can, by the time a game is more than 30 minutes old, consume almost 20%, or more, of all the clock cycles available to the SIM. Why ? Because the creation of new units, and new tables and variables in the code are too intensive - and the memory used must be reclaimed - only to be used again - in very quick succession.
The largest of all memory allocations in SCFA is the creation of a new unit. Anyone who has ever examined a blueprint for any unit knows just how many variables are involved - and that is the problem in a nutshell. If you reduce the creation of drones down to a modest level, you minimize this problem quite a bit. Now - in the end - it becomes a simple matter of aesthetic versus performance.
-
FAF is reusing the bots, as long as there is another target to build right away, they dont despawn.
-
Is changing the speed that drones change target from .2s to .5s purely a visual thing or is that a nerf to how quickly they can change what they’re assisting or building?
-
Rookie game engine question here: how did you evaluate the increase in time to render ? What console commands and such?
I would like to just for fun have some people I know with “cheese or potato” PCs run it, along with my own, see what happens.
Overall though, as Sprouto said, it’s almost as simple a fact that more units are generated.
-
@exselsior said in Questions about performance: Cybran build drones:
Is changing the speed that drones change target from .2s to .5s purely a visual thing or is that a nerf to how quickly they can change what they’re assisting or building?
Purely visual. It is how often they choose a random location within the building they are 'building'. The resources switches immediately. The beams of the engineer would follow right away. The drones would follow shortly after.
-
@Morax use ren_ShowNetWorkStats in the console. Spawn in 150 hives and make them assist a quantum gateway while you have essentially no income.
-
@jip Figured that would be the case, thanks! I like the ideas
-
In order to push the conversation to a conclusion I'd like to sit down with people. I'd like to take out potential ambiguity. I assume that the people who upvoted the original post are positive to the changes.
I'll be on the FAF discord channel on Thursday 21:00 GMT+2 and on Friday 21:00 GMT+2 - please be there if you have questions. I intent to implement the changes this weekend - that way it can be inspected on the Dev branch starting next week and hopefully be live when September starts.
-
How hard would it be to make a SIM mod that does this? So we could test it for ourselves. We could test for performance or look at how it affects aesthetics so we can decide evaluate the trade-offs involved.
Also I assume that you would have to basically do the same work to prepare the SIM mod as to make these changes to the main branch of FAF itself. So there is essentially zero wasted effort in taking the time to make this SIM mod.
If you just plug the changes directly into the dev branch, it would be a lot harder to compare with/without the changes, because there may be other differences in the dev branch. And every time we load up a game with the dev branch, doesn't it have to download lots of files? Like if we wanted to go back and forth between regular FAF and the dev branch to test it, it would be a pain. But if you just make a SIM mod it would be easier for us to see the difference.
Alternatively: make a SIM mod that adds new units: a new hive with the changed animations. Then we could run a single game, cheat in some units/buildings, and put regular hives on one side and new hives on the other side. And then we could watch them work at the same time. So we could do a side-by-side splitscreen comparison of the aesthetics with both running. And then run only one side at a time to check performance with the other side hives paused.
-
The problem is time. I can spent all week on fixing this one performance issue and find something that we can all agree on, make a sample version, etc - or, I can spent a day on it and spent the other six days on other issues. There are hundreds of things that need to be looked at from a performance perspective - this is just one of them
.If I understood correct then due to recent changes only the changed files need to be downloaded. Therefore there is no large download anymore. But don't quote me on that, as it may not be 100% stable yet.
If you want to compare it side-by-side, launch the game with the FAF Develop version and then directly launch the executable of FAF found in the bin folder (Program Data/ForgedAllianceForever/Bin). The latter should use the default init file where as the former is running FAF develop. Then you can view the changes side-by-side.
edit: the purpose of this topic is to make sure the aesthetical change (which is, again - minor in my opinion) is accepted before I do the work. As I do not want to see my time go to the bin.
-
@arma473 if you enable caching in the client settings the download will only need to happen once. Also I think it won't need to happen multiple times without that because they are actually different files. But turn it on just to be safe.
-
We limit the number of unique targets. Instead of having each drone (and the engineer build arms) all have their own unique target, they all share the same target (as the engineers). With that we limit the number of entities (to 1 / builder) and the number of emitters (just 1 sparkle emitter / builder).
Do I understand this correctly, that this would make all the drones do their laser "welding" at the same spot?
-
@blackyps Yes - for each engineer / hive. Two engineers would have two unique welding points, ten engineers would have ten unique welding points - etc. But not each drone and each build arm having a unique welding point.
-
if you can increase the size or modify the look of the flying drones if function of their tech, then i'm all for reducing their number
-
@MadMax ?
A work of art is never finished, merely abandoned
