To my knowledge, there are currently 2 issues with IS_OCO packets and lights in general:

• Response timing to IS_OCO packets is erratic at best (sometimes the lights switch almost immediately, sometimes you have to wait much longer, to the point that flashing lights (changing state every 0.5s) may keep the commanded light on or off for more than a full second (likely because it does change state at some point, but immediately reverts because of the new packet)).
  
• We don't have enough working and controllable lights (pit entry/exit, track-side lights (or LED panels for Blackwood).
  

The first issue forces InSim developers to use "backup lights" for custom starts (which isn't too bad in itself, as having GUI/HUD lights is generally a good idea), because the real lights typically change state late and are not reliable for reaction time (I won't get into 5-red-lights style start lights here, although having those on all tracks would be good as well). The issue is easily noticeable when sending a message right after sending the IS_OCO packet.

The second issue, which hopefully is planned to be addressed in the future (the lights are there after all, so we could have them accessible to InSim with index values other than 240, or identifier values for index 240) would really help to make the track more alive (having green lights/LED panels during a safety car period feels wrong, after all, and being able to use the blue lights at pit exit (or a layout object with a blue light) would also help).

Now for the proposed changes:

• If possible, having lights react more quickly to IS_OCO packets would be appreciated, as I don't really understand why they wouldn't be updated as soon as the packets are received. By the way, the issue is only visible with host InSim apps, in local apps, the changes are immediate.
  
• Whether the above can be addressed or not, it would be nice to be able to set lights to a flashing state, so we don't have to repeatedly send on/off IS_OCO packets (a period of 1s (0.5s between state changes)) should work for most scenarios.
  
• Valid index values are currently 149 (with 150 and 151 already reserved for new layout objects) and 240; just like layout objects have 64 identifier values, having some of those for track-side lights seems like a good option for controlling them.
  

As an additional note to that last point, maybe more lights could be added on official tracks; I checked around Westhill, the National configuration has 2 of those, and International has 4. I don't know how those lights are supposed to be placed in real life, but there is no light at all between the point both configurations converge and the main lights at the finish line, I feel there should be at the very least one.

I agree that more control of the existing lights would be good, including the pit exit lights and hopefully any other traffic lights. I didn't know existing lights were slow to react. I can take a look at that.

I'm interested in the LED light boards around the track but I forget if we've discussed them before in public.

I think they should be individually or globally controllable by setting a specific colour or two flashing colours via InSim and using an ID number in some InSim packet.

I guess a global usage would be good, to set all with one packet (e.g, red flag?) but individual would be useful too (blue, yellow flags?).

I'm guessing at this point that monochrome colour for the whole board is enough as it would be much easier to implement than any patterns/

I haven't discussed this with Eric yet (at least recently) though I'm sure he would be interested to see them working.

As some changes might be required in the light objects it would be nice if we could already have these in place before the release, so it's worth a bit of consideration.

Does anyone have any good information about how frequently the LED boards should be placed around the track?

Quote from Bokujishin :

Response timing to IS_OCO packets is erratic at best (sometimes the lights switch almost immediately, sometimes you have to wait much longer, to the point that flashing lights (changing state every 0.5s) may keep the commanded light on or off for more than a full second (likely because it does change state at some point, but immediately reverts because of the new packet)).

I very rarely change the trafficlight states any faster than 1s (< 1000ms). You mentioned it briefly;

likely because it does change state at some point, but immediately reverts because of the new packet

I'm thinking this is related to network latency, as i haven't ran into this issue at all with my timers/states. As you already said, it'll immidiately revert due to the new packet arriving.

Quote from Scawen :

I didn't know existing lights were slow to react. I can take a look at that.

From my experiments back in the DCON days (memory might not be 100% ) it seemed to be connected to the delay in objects appearing - I did a side-by-side comparison of changing the lights versus replacing one object with another and they were always synched, whether it was fast or slow to respond.

Quote from Scawen :

I think they should be individually or globally controllable by setting a specific colour or two flashing colours via InSim and using an ID number in some InSim packet.

I guess a global usage would be good, to set all with one packet (e.g, red flag?) but individual would be useful too (blue, yellow flags?).

I'm guessing at this point that monochrome colour for the whole board is enough as it would be much easier to implement than any patterns/

I think this could work with an identifier specific to lights/LED boards, 241 or something, with identifier 255 used to control all of them, and 0 to some value to control individual ones - which controls which one can be subject to some debate, as it could be numbers along the layout (but that could depend on the layout itself), or fixed numbers that we would need to list manually to get the proper lights/boards for our current layout.

As for the monochrome vs 2-color boards, I suppose the current way those are made corresponds to a single light bulb, and as such they're monochrome - switching to 2 separate textures/emissive textures (don't know what you're using, both currently and in your dev version) separated diagonally would work akin to 2 light bulbs and could be very nice to have, but probably not the priority.

I would even say that, in my opinion, being able to set lights to a flashing state would be more important, but I'll let others give their opinions about that.

Quote from kristofferandersen :

I'm thinking this is related to network latency, as i haven't ran into this issue at all with my timers/states. As you already said, it'll immidiately revert due to the new packet arriving.

If that's network latency, I would expect InSim buttons (sent just after the corresponding IS_OCO packets) to also have some kind of issue, but they're mostly perfect there, so it's very likely there's something specific to lights or IS_OCO packets.

I would make a small video clip showing the issue, but I won't have access to my actual PC for a few days, so I'll try to do that later this week. I'll also take this opportunity to check whether layout lights have the same issue.

Quote from Scawen :

... Does anyone have any good information about how frequently the LED boards should be placed around the track?

Lights should be controlled by sector as well as globally.

In racing, Yellow is used in affected sector, but Red to stop race is global.