Yellow flag, user-configurable

[lowlyocean]

Wondering if we could make the yellow flag notifications more configurable? Perhaps bring some constants out as configurable parameters? In particular, the 3 seconds mentioned here:

[mrbelowski]

is there a specific issue this is causing? Are you getting yellow flag notifications when you shouldn't be, or is the app missing yellow flag notifications?

[lowlyocean]

Difficult to compare to the game's yellow flags because in VR I don't get the flags in my field of view. This was prompted by an incident on turn 7 at Watkins Glen (blind corner where an incident happened less than 3 seconds ahead). I also tend to get lots of false alarms on turn 8 at Daytona. In general estimation and detection are difficult problems mathematically, but this request is at least to expose the parameters of the current model so user can adjust ROC curve.

[mrbelowski]

ok, i'll have a think about it. Adding a configurable values for the various parameters is simple enough but it'll be pretty baffling for end-users

[lowlyocean]

Curious - do you have a way to compare against "truth" data from the game (whether an incident point was issued)? In that case, you could train the algorithm based on the truth data so that with a fixed probability of false alarm (say 1 in every 100) you minimize the probability of a miss. User would just provide their "tolerable" probability of false alarm, with the understanding that lower false alarms usually come with greater chance of miss. In motorsport it could be argued false alarms are quite tolerable because reacting to a non-existent incident up ahead might slow you down a couple seconds, whereas failing to react to a REAL incident may cost you the entire race (and in the best case, 4 seconds a lap of damage).

[Sparten]

The issue with daytona is related to cars spinning the wheel when coming on to the oval so game sends yellow flag, its a know issue with that corner and there is not much we can do about it.

[lowlyocean]

False alarms like the one on Daytona are not as troublesome as a Type II error (the one in blind corners). So making detection more sensitive would be the objective

[mrbelowski]

Nah, the game is sending yellow flag here. Regarding late calls (>3 seconds), wouldn't you expect a race engineer to get the data a second or two after the incident, and announce it a second or two later?

[lowlyocean]

Are we talking about realism? I'm interested in getting the information at the same moment as the game does, since yellow flags aren't in my view with VR. And I think you're saying that you get the yellow flags directly from the game, so I'm confused what the 3 seconds or 10 meters are used for. I thought you were calculating the yellow flags based on a bunch of data like speed, rotation, etc. But now it sounds like you're just filtering the yellow flags you get from the game? Which I definitely am trying to avoid

[mrbelowski]

I guess that single variable (time stationary before calling yellow flag) can be made available then the user can decide here. Of course, you'll have to accept some false positives as a result

[lowlyocean]

Nah, the game is sending yellow flag here so this means you are doing your own estimation of yellow flags, and on top of that also reporting yellow flags directly from the game engine?

[mrbelowski]

In some cases, yes (but it's a long time since I wrote this code so might be mistaken). It depends on the game. What are you playing?

[lowlyocean]

iRacing

[mrbelowski]

Iracing only uses the game data here. the delay is coming from the code that de-bounces the flag changes. Some games will switch between green and yellow rapidly for a second or two before the flag settles. Maybe we don't need this for iracing but I don't play.it

[lowlyocean]

That would explain why some yellows might not get reported. Wonder if it would be tedious to make the de-bounce optional?

[mrbelowski]

I'll take a look. The code is pretty grotty in that event but it should be possible to do something