Removal of the Blinking lights

QuietJoy

Good lord yes, get rid of them, i don't think anyone knows they are there!!

magge

I vote to remove.

MarcSpector

For the first time I see this. Definitely delete.

Rowey

Yeetus Deletus

Giebmasse

There are blinking lights?

With the current energy crisis better shut them down.

OGW_PR_Outreach

I know of them and like them. Nomads units use a lot of blinking lights. The game has some visual details that you don't see zoomed out (tire treads, dust kicked up, wakes, projectile effects, some examples). As a game from 2007 it doesn't look great in 2022 but I appreciate the details it does have.

For removing things from the game I suggest you make a mod like Azroc did to remove BlinkingLights from blueprints.

Exselsior

I also vote remove. Didn’t know this was a thing so I’d rather not have it impacting performance as there’s no benefit to it

Anachronism_

@Jip
Regarding the blinking lights that are not hidden; can removal of the blinking lights be an option, and can you share gifs comparing some units with blinking lights vs without?
Regarding the blinking lights that are hidden; why do those even exist?

Zeldafanboy

Make the blinking lights bigger and more obvious

deletethis

This is very cool and now that I know about it I absolutely want it to remain.

Jip

@ogw_pr_outreach said in Removal of the Blinking lights:

I know of them and like them. Nomads units use a lot of blinking lights. The game has some visual details that you don't see zoomed out (tire treads, dust kicked up, wakes, projectile effects, some examples). As a game from 2007 it doesn't look great in 2022 but I appreciate the details it does have.

I understand and I agree: tire treads, dust kicking up, and everything else that has a purpose that can not be replaced will remain. And will be optimized. But this particular feature is widely underused (you're one of the first people that are aware of them), its purpose already has better alternatives (factory building unit, height of storages) and 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.

@emperor_penguin said in Removal of the Blinking lights:

can removal of the blinking lights be an option, and can you share gifs comparing some units with blinking lights vs without?

You can do this yourself in-game: just imagine the aeon land factory without those blinking lights. It doesn't really add that much to the structure. You can also start the game in FAF Develop, as the blinking lights are removed there right now until further notice .

@emperor_penguin said in Removal of the Blinking lights:

Regarding the blinking lights that are hidden; why do those even exist?

Probably legacy - maybe the unit was initially something different.

@zeldafanboy said in Removal of the Blinking lights:

Make the blinking lights bigger and more obvious

The purpose of the lights are already in the game:

they're yellow when the factory is building something (look at the building pad)
they're red when you're out of storage (look at mass extractors, they even work through the fog and these lights do not)

@deletethis said in Removal of the Blinking lights:

This is very cool and now that I know about it I absolutely want it to remain.

Can you describe why? Why do you want to keep a feature that you weren't even aware of after all these years?

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