Removal of the Blinking lights

Jip

@mazornoob said in Removal of the Blinking lights:

From what I understood of the explanation, it's possible to handle stalling/not stalling color change in a single loop instance, right? So that we pay a tiny fixed cost for the stalling/not stalling logic,

I've explained it in this post.

and the rest is handled by some shader magic.

Possible, but that doesn't remove all the issues as described in the post mentioned.

All the other logic like building units and such could then be placed in appropriate functions instead of being polled every tick. Then we'd keep the old behaviour without polling everything all the time.

If you don't poll enough then the results are not accurate enough to be reliable, and if they're not reliable then why are we having them change at all?

I've decided to keep the lights, set to a fixed color. There will be no changes to the lights once they've spawned in. I'm fine with any color, they can be faction dependent. Uveso and Zelda made some suggestions:

@uveso said in Removal of the Blinking lights:

I would obviously vote for yellow or blue.

Also nice; light in faction color

Or just white light (in this case yellow white like an old light bulb)

@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.

Any other opinions?

thecore

Another option is make the lights the player colour.

Uveso

@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.

BlackYps

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.

Zeldafanboy

@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.

TheVVheelboy

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.

LegionDarrath

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.

Caliber

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.

Morax

I’m in favor of removing them.

Jip

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 !

Brutus5000

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

Jip

@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