Removal of the Blinking lights

@zeldafanboy said in Removal of the Blinking lights:

I think the blinking lights should contrast the faction color— i.e. Cybran should have yellow blinking lights and Seraphim blue blinking lights. Aeon should have red lights and UEF green lights.

yes, i think this is the best solution.

You just shuffled the faction colors around and I can't even figure out the logic which color goes to which faction, this isn't really contrast in an aesthetic sense. Using the player color seems like the better solution.

@blackyps

I wasn't aware the lights could obtain the individual player color, but my logic for the color selection uses "contrast" in a loose sense (for example, if Cybran is "red" the opposite color on the color wheel is green, not yellow) but I took the actual coloration of the factories and structures into account. Only UEF factories are actually blue, Cybran is black, Aeon is white, and Seraphim is chrome. I think yellow stands out on black better than green, so I used yellow instead of the actual contrast color, and then I shuffled the rest of the colors around.

I also think that having the light colours be the player colour would be the best idea, it also adds to the already lackluster customization options in game so it would be a nice change of pace to see it happen.

Having the lights be the player color just adds more of the same color to the building. Having them be the faction color is a nice little nod to the "lore" while also not looking samey to all the other color the units/buildings already have.

Occams Razor.
Most players dont now this exists.
Players now cant decide whether to keep them or change its function or change its colours ect.
Remove altogether would be the simplest solution.

I’m in favor of removing them.

The blinking lights are re-introduced again since 3810. See also #6263 for all the changes and the reasoning.

We're looking for someone to improve the position of the blinking lights on all factories. No programming is required, but you do need a development environment to test and verify your changes. You can use #6266 to understand what type of changes it could involve.

If you're interested then do respond either here or introduce yourself on Discord. Then we can help you get started !

Nice!
Can you tell us a little more how the new implementation avoids the performance issues of the original one?

@brutus5000 said in Removal of the Blinking lights:

Can you tell us a little more how the new implementation avoids the performance issues of the original one?

Great question!

In general I don't think / am able to observe a significant performance issue with the previous or the current implementation when I reviewed it last month. In comparison to other changes such as #4539 or #3857 or the fact that a single formation (every order that involves some form of movement (!)) happily allocates 4kb of memory and can take several milliseconds to complete. I made a mistake by removing the blinking lights and by re-introducing it I'm rectifying the mistake .

In general the current implementation follows a few principles:

• (1) No unnecessary memory allocations. Especially the type of 'use and forget' is exceptionally painful for performance. Not only is memory allocation on the heap slow in general, it also unnecessarily flushes the CPU cache.

• (2) No unnecessary table access. Everything in Lua that involves : or . is not as 'cheap' as it is in compiled languages and involves a hash operation in combination with following a pointer into (random) memory. This expensive! And it compounds since our Lua is interpret and not compiled. As a quick example #5524 increases the performance of the score graph at the end of the game by several factors and the primary reason for this was to cache table accesses.

And unrelated to performance:

• (3) All logic is now isolated to components. One component for the brain. One component for units. This makes it easier to maintain and understand.

I hope that answers your question