Nice find. If you ever see such read-only errors, you can assign me. #4257

The unintentional entity state modification you discovered was introduced by rP15375.
The issue never surfaced (until rP20100) because only this one place reads from that entity state property.

How about displayLocked = state.gate.locked to avoid the clone? (primitives are copied instead of referenced)
(Not a huge performance gain, but doing something odd and then undoing something odd seems odd to the reader when it could just set a bool)

If so, GATE_ACTIONS seems worth to delete, especially when looking how the only place that uses it, uses it. (If we want such a thing, it should contain filenames)
Those two hidden = setts could be unified.

That is much easier to comprehend!
!some = every
It might be irrelevant, but iirc the selection panel code is performance-critical and executed for all entities in the selection, regardless on whether it's a gate.
So either a quick performance test ruling out the performance aspect of using two loops, or use only one loop / array function.
(reduce could do it, but that is not always readable.)

In D1004#39776, @elexis wrote:

It might be irrelevant, but iirc the selection panel code is performance-critical and executed for all entities in the selection, regardless on whether it's a gate.

I think the issue we had was from calling GetEntityState() through the GUI Interface. Unless you're selecting a stupid amount of entities, I don't believe it'd matter in this case (then again, checking never hurts).

In D1004#39818, @temple wrote:

Alert does some() three times, that's where I got the idea.

Ah, that was rP18773. (That added a lot of overhead as it requested the extended entity state of all entities to determine whether an action is possible whereas before it only looked for the first selected entity, which can change easily depending on the selection order.)

For 100 entities, took 0ms or occasionally 1ms.

A cpu cycle consumes more than 0. We have Engine.GetMicroseconds(); for a higher precision.
We intend to reduce the turn length from 500ms down to 100-200ms eventually, so a millisecond is not irrelevant.
Also missing a comparison to using only one loop.

I don't know, I got a complaint once for doing two loops where one is sufficient. Someone else said it's ok because O(n) + O(n) = O(n).
Patch looks very good to me, I'll test it for correctness and performance later.

In D1004#39822, @elexis wrote:

In D1004#39818, @temple wrote:

Alert does some() three times, that's where I got the idea.

Ah, that was rP18773. (That added a lot of overhead as it requested the extended entity state of all entities to determine whether an action is possible whereas before it only looked for the first selected entity, which can change easily depending on the selection order.)

No it was rP18733...

In D1004#39826, @elexis wrote:

Not sure how you got to 1ms, it consumes < 10 microseconds on my end.

I have an old computer, plus I said "occasionally". :)

Fluctuates but maybe 25 microseconds with the patch, 15 with a loop, with 200 entities.

Thanks for the suggestions and review.

(Also there are many more possible performance optimizations. For instance Im not sure if creating an array in getItems and then parsing that in setupButton is better than doing both in the same function and updating the GUI objects directly.)
(jshint can find such things, one can run it from command line. ah well, we got it on phabricator meanwhile :P)

(Also I may not claim readability, but the formula is now in Prenex normal form following the !some to every change, so yay.)

In D1004#39823, @Imarok wrote:

In D1004#39822, @elexis wrote:

In D1004#39818, @temple wrote:

Alert does some() three times, that's where I got the idea.

Ah, that was rP18773. (That added a lot of overhead as it requested the extended entity state of all entities to determine whether an action is possible whereas before it only looked for the first selected entity, which can change easily depending on the selection order.)

No it was rP18733...

The three some calls come from rP18773 (last time I checked).
The second sentence would be more accurate by stating that rP18733 made it slow without a good reason and rP18773 added few more non-good reasons.
As I saw you assigned yourself to #4322, tell me if you need assistance.
(I expect it should be possible to do the GUIInterface querying more concisely (which is currently massive object construction + parsing from many simulation component JS objects + clone + all of that for hundreds entities).
For instance having a getter for each component of an entity, or getters for a set of properties (i.e. more groups than "simple" and "extended"). Needs exploration on feasibility and a performance evaluation though.)