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.

Quote from Scawen :

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

This is from the FIM rather than the FIA, but the wording is similar to what I've seen in a few videos on this matter. In section 9.2, the general idea is that LED panels delimit each marshalling sector (with one panel at the start of each sector), the maximum distance between panels is 250m, and each sector should have line of sight to the previous and next sectors.

For some more details about the panels themselves, I found this FIA document, with Appendix 2 showing the standard messages in addition to the flags (but solid colors and "double-yellows" should be enough, with the standard flashing frequency being 2Hz rather than 1Hz as I suggested before).

Edit: Oh and to keep up with my usual "let's ask for one more thing" habit: if/when you do add the ability to control the LED panels, having them available as layout objects would be great (they're much more visible than standard lights, especially since relatively small light sources are a common problem in games, where they're barely or not visible at all despite being extremely bright, because of their sub-pixel size or when they cover few pixels, like tail lights and stop lights do already, since I doubt the graphics update will solve this despite the reworked emissive materials).

Thanks, that's some good information. I see, the variety of graphics that could be displayed is something to think about, though as you suggest it seems reasonable to stick to single and flashing colours if that is easier to implement.

It's not fully clear to me about maximum distance between light boards being 250m. It seems a lot, so I'm surprised. The wording doesn't clear that up for me as it seems to state that there must be a marshall post every 250m, but at the end of section 9.2 marshall posts can be:

- Track marshal post
- Flag marshal post
- LED panel controller marshal post

So I'm not sure yet if there must be an LED panel every 250m.

EDIT: YouTube video talking about it, that does seem to support that there is an LED panel at every marshall post.
https://youtu.be/_4UusnCaB6s?t=406