Removal of the Blinking lights

FtXCommando

@jip said in Removal of the Blinking lights:

it blocks the implementation of another feature that will be another performance saver: the keeping track of energy to disable / enable intel / shields / stealth with maintenance.

This sounds like implementing an auto pause on things that cost energy to maintain when you stall?

Jip

@ftxcommando said in Removal of the Blinking lights:

@jip said in Removal of the Blinking lights:

it blocks the implementation of another feature that will be another performance saver: the keeping track of energy to disable / enable intel / shields / stealth with maintenance.

This sounds like implementing an auto pause on things that cost energy to maintain when you stall?

No, allow me to explain. Currently there are loops such as these:

Each unit has their own loop running, continuously (read: every tick for shields, and every five ticks for intel) checking throughout the game whether or not you, as a player, have the energy in storage to sustain the shield or intel. When you don't, the loop breaks and the shield / intel is turned off (but still consumes maintenance)

This is a bit of a waste, especially late game when there can be a hundred to a thousand of units doing these checks. A few examples of units that rely on these checks:

Any unit that has a shield that relies on maintenance: static shields, mobile shields, personal shields
Any unit that has intel that relies on maintenance: mole, stealth fields, radars, Cybran ASF

I've been wondering myself: what is going on when we're running at my -1 on Setons Clutch, but there's no battles, just units existing and being created?

And one of the previous answers were Cybran build bots. Now the answer is blinking lights (to a lesser degree, of course) and these shield / intel threads that continuously query the brain and the unit to check if they can be sustained or not.

I'd like to re-use the implementation of the blinking lights (it doesn't allow for multiple triggers at once ) to remove and* replace all of these threads of individual units. Instead of having each unit check individually, we check once using this built-in trigger system and turn off (but still consumes maintenance) all the maintenance-based units. Then, once the player has more than 5% energy in storage (or some other arbitrary threshold) the units are enabled again, where intel is enabled immediately and shields first have to recharge.

With this new implementation we'd also prevent the 'blinking on and off' of shields and intel when you have no power. Instead, they remain off (but still consume maintenance until toggled off) until you actually have something in storage again. This can happen when you have missile-building structures, such as SMD, SML and TML.

To sum it up: I'd like to re-use the triggers of the blinking lights to do something more meaningful .

edit: I can't type early in the morning :sad_cowboy:

deletethis

While these little details won't impact much on the gameplay on the whole, they are part of the charm of the game—and I definitely enjoy learning about them.

Definitely don't let me stop you from doing what you have to, but I am personally against removing things—unless the gains are really worth it (see the recent Cybran edits).

BlackYps

How about a compromise? We get rid of the complicated color changing logic but keep the lights. We just have to decide on the color we want them to have.
I think a lot more people are aware that the lights exist than know that they change color on conditions. And I agree that keeping them for visual detail would be nice

MazorNoob

Is it possible to change light color globally in some way, some shader magic or such? We could then have a single loop that checks stall status. All the factories and such would then only have to change the color when they start/stop producing, which is probably cheap.

nine2

How much performance impact does the blinking have?

Curious how you measure the performance before/after this change reliably, because that sounds quite hard to do.

Probably not possible but would be cool if blink effects didn't affect sim state - then enabling such fx could be a setting. And then we could have adaptive performance where the game automatically reduces settings when your fps sucks.

Jip

@blackyps said in Removal of the Blinking lights:

How about a compromise? We get rid of the complicated color changing logic but keep the lights. We just have to decide on the color we want them to have.
I think a lot more people are aware that the lights exist than know that they change color on conditions. And I agree that keeping them for visual detail would be nice

I'd be fine with this compromise - as long as it entails it is a 'run and forget' action and no intermediate updating. There is really no value in that especially considering the low number of people that were actually aware of these lights to begin with.

@nine2 said in Removal of the Blinking lights:

How much performance impact does the blinking have?
Curious how you measure the performance before/after this change reliably, because that sounds quite hard to do.
Probably not possible but would be cool if blink effects didn't affect sim state - then enabling such fx could be a setting. And then we could have adaptive performance where the game automatically reduces settings when your fps sucks.

It isn't about the frames per seconds, it is about the simulation speed.

It involves logic that can cause a desync, but one that can be ignored as we're just skipping on emitters and not doing less damage or anything like that. Therefore one can make a comparison by running a saturated replay twice on the fastest possible speed: one with the blinking lights and one without and compute the difference in time. I've done this in the past for other pull requests - it is possible but tricky to setup.

Note that the expense is not so much in the lights itself, it is in the bookkeeping of the lights:

inserting a new unit with blinking lights: https://github.com/FAForever/fa/blob/deploy/faf/lua/aibrain.lua#L329
removing a unit with blinking lights: https://github.com/FAForever/fa/blob/deploy/faf/lua/aibrain.lua#L349
and the update procedure: https://github.com/FAForever/fa/blob/deploy/faf/lua/aibrain.lua#L361
and of course, the actually change of lights: https://github.com/FAForever/fa/blob/deploy/faf/lua/defaultunits.lua#L775
that involves re-allocations of roughly the same emitter and tables: https://github.com/FAForever/fa/blob/deploy/faf/lua/defaultunits.lua#L275

All of these involve table operations, in particular when changing the lights. And to make matters worse: the table.remove has a complexity of O(n). Every factory and storage has these lights (but is not limited to those) the table can easily have dozens if not more than a hundred entries. And as the destruction of factories and / or storages are not unusual this has an additional load on the simulation when fighting.

@mazornoob said in Removal of the Blinking lights:

Is it possible to change light color globally in some way, some shader magic or such? We could then have a single loop that checks stall status. All the factories and such would then only have to change the color when they start/stop producing, which is probably cheap.

Yes, this is possible in a similar fashion to what Nomads did. But that would be on an individual basis. But again - for what purpose? You can see a unit is being made by looking at the factory. The lights do not work through the fog of war.

I'll re-iterate what I've said in the past: there is a line where we as a community have to choose between features and performance. Some features are so critical that we take a hit on the performance and in return we get better gameplay. One example is the overspill feature, that we managed to improve with a factor of ~ 7 last month (going from 60 ms /tick to 10 ms / tick with a base line of 2ms / tick). Other features are so key to visuals (like tank tracks, explosion effects) that I too agree that it is best to take a hit on performance in trade for some visuals.

But is this feature worth taking a hit on the performance for?

I'd say no .

Anachronism_

@jip
Wouldn't it be relatively low-cost to do something like have a loop that runs once every X seconds, and then for each player, gets the player's relevant eco data, determines the blinking light status, and then if the status is different from what it was the previous cycle, sets the blinking light status for that player's blinking light units? I imagine this could be done in a way that does not conflict with what you want to do to improve intel/shield processing.

Alternatively, if that wouldn't be relatively low cost, perhaps we should just do blinking lights by player color.

Giebmasse

The simulation is already run for each client, where the info is grabbed from currently afaik for the lights. That loop sounds like just another layer on top or replacement of current control system, just added complexity and not really resolving the need for the mentioned bookkeeping? If the loop would process each factory you'd have to bookkeep the factories to be included and run them in a batch or start a separate loop for each factory and kill it once not needed anymore.

I'm not familiar with all the technical bits regarding the lights, but in general triggers that rely on game engine functions are usually way more optimized than manual loops done on the scripting side.

And all that complexity for lights that most don't even know about

Deribus

Are the lights all or nothing, could we get rid of ones some units but not others?

I think the blinking lights when storages are near empty are kinda cool

Sprouto

LOUD removed those lights pretty much at the first release - they were never missed. No one even noticed until it was pointed out. Just saying......it's a great deal of code execution for a whole lot of almost nothing.

Uveso

Well i know those lights and saw them from the beginning.
But i am colorblind (red/green) and i never see to what color those lights change.

So my personal opinion;
I like the lights, it makes the game more "colorful", but they don't need to change
or show something special with their color, i can't see it anyway.

I'm still mourning the removal of SACU wrecks
They looked good and were removed as a balance decision due to mass on reclaim. A crime in my eyes!
(Setting the mass inside the wreck to 0 would have the same balance change without removing grafics from the game.)

Please try to hold as much effects / grafics as possible in the game.

My suggstion:
Create those lights when a unit gets created and let them shine in a fixed color.
So we still have nice grafic, and less CPU power used for unessisary colorchange checks on many events.

Jip

SACU wrecks are still part of the game.

TheWeakie

If they wouldnt be you'd have me crying about it all day

Aulex

Sleep tight blinking lights, jip is gonna flip the switch off.

Uveso

@jip said in Removal of the Blinking lights:

SACU wrecks are still part of the game.

well, they were removed on 25 May 2020
https://github.com/FAForever/fa/commit/dbaf939f45671a9f77d9cabe099e25068729d452

But it looks like those changes were reverted half a year later (25 Nov 2020).

Ok, the SACU wreck question is solved, lets get back to the blinking lights.

Jip

I'm fine with having some form of lights, made once when the unit is finished and then 'forgotten'. But I'd like to stress: if only a few individuals actually knew about the lights, then why do we bother .

Eternal-

What the lights? Player with low graphics settings

BlackYps

@jip said in Removal of the Blinking lights:

But I'd like to stress: if only a few individuals actually knew about the lights, then why do we bother

Because we try to preserve the game SC:FA here. If there is no pressing reason to remove nice details then why should we do that?

If we remove the color changes that are a performance hog, then what do we actually improve if we completely remove the lights? At that point we are just taking stuff away for no good reason.

Jip

Fair enough - I'll add them back in but without the color changing. Suggestions for a color?