You're not a very imaginative one then (no offence), it's very easy. Scan till you hit a damage block or yellow flag, pause the replay and focus the camera on one of the players involved. All done.
Of course it's not that easy for us, since the actual MPR data is not documented, but it's no biggie for Scawen.
€: You could actually scan for yellow flags and high angular velocity using InSim and 32x speed, wouldn't skip right to the next incident but it would be a lot faster than doing it by hand, especially since you can't watch the whole field at once but an InSim appilcation could.
Well, detecting contact and yellow flags is not that hard. But what about incidents where none of those are present? Or incidents that have them, but are not really any interest? How about if there are incidents in a big succession like example bump drafting? Is a blue flag an incident? What if there is multiple incidents at the same time in different spots of the track?
Also you most likely would like to start viewing a bit before the incident, but LFS' replay system has to always run the replay, you can't truly skip to any one spot. So you would first have to run it to the point of incident and then run it from the start to the time just before the incident. That could become a problem in long race with many successive incidents.
How much before the incidents is a good time to start viewing?
The yellow flag implementation is fairly reliable, I would code such a system under the assumption that it's sufficient to tell major and minor incidents apart.
Bump drafting doesn't cause a yellow flag, nor does it result in high angular velocity, unless something goes wrong which would make it an incident of interest.
Multiple incidents at the same time at different locations would simply be processed sequentially, in the order the CompCars were received in.
Pre parsing the replay once, perhaps with the camera pointed at the sky for maximum framerate, could solve the "incident intro" problem (start viewing ~10 seconds before the incident) and still be much faster than reviewing the entire review once "by hand".
I think it is close to 100% reliable, but if it's not, a node-based velocity lookup-table could solve that, although that would be A LOT of work.
Draw 2 rectangles representing the cars, facing the cars's direction at their relative directions onto a surface, if lines overlap, there is a collision.
I guess you are referring to significant crashes. But the thing is low speed bumps can effect race a lot too. Those are the ones not easy to detect reliably and without too much false positives.
A collision detection, but what does it have to do with the text you quoted?
I don't know what exactly triggers a yellow flag, but if it's insufficient, you could just use the collision detection and drop the yellow flag+angular velocity concept entirely.
People bumping into each other are colliding, are they not?
Collision detection wouldn't always work, because sometimes small bumps make a difference, sometimes they do not, sometimes you hit a other car on purpose multiple times (bump drafting). And not all incidents involve actual collisions.
I don't get the angular velocity thing either. You still would need to know what direction/speed combinations are incidents and determining that is the hard part.
Whether an incident is relevant or not is for the race officials to decide, the "next incident"-button is there solely to quickly jump to incidents so they can be reviewed more efficiently.
You don't need to know what direction/speed combinations are incidents, just the approximate maximum of the cars on whatever tyres they have on with a reasonable margin. Everything that falls between the actual maximum and the maximum defined in the application is extremely likely to slow the car down enough to cause a yellow anyway. If that's still not enough, you could use the drift angle as additional factor.
This application would certainly pick up more incidents than a human ever would, I bet most of the minor incidents you think of as hard to detect wouldn't be detected at all by humans.
I didn't mean they would be hard to detect. I meant it would be hard to detect what are actually relevant incidents. I think there would need to a be a some kind of relevancy check so that the "next-incident" button would be of use.
Anyway you talking about angles, speeds, margins and what not and us having this conversation, just proves that this is not a easy job to do.
It's significantly easier for Scawen since he can just use the already existing collision detection. This is an improvement suggestion after all, not an InSim app request.
I'd still consider the InSim implementation easy, seeing as we've got solutions to most problems in a mere 9 posts. Would take more time than I'm willing to spend though.
Scawen could add a packet to InSim that would report if a car collides (if it doesnt already). That way a external app could be made to gather that information.
But I just don't think there is a reasonable way to make LFS detect all incidents that might interest a person watching the replay. So you would probably have to go the replay through by hand to catch all incidents.
Incidents not resulting in either a collision or yellow flag, which would be really minor mistakes, can't possibly be relevant though, that's just racing.
Again, the InSim app can "watch" the whole field at once and catch pretty much all that matters if everything we came up with so far is implemented. A person would have to watch the entire replay at least once from each driver's view to gather the same amount of information.
A blue flagged person slowing down (so much it makes a difference to the race result) someone would be one that pops in to my mind. Surely a race marshal would like to see that.
Same goes for swerving on the straight or other dangerous movements that can cause people to slow down/lose positions without there actually being a collision.
PS. It's kind of annoying and insulting that you talk like I don't understand simple concepts like how collisions are checked or how InSim works. And that seems to make you also forget what you are quoting.
All of which would almost certainly cause a yellow.
I didn't mean to insult you, I was merely explaining how you could reconstruct data that isn't natively available from InSim by using data that is available. Collision detection cannot be done soley by using data available from the InSim interface, it's not something commonly done within InSim applications and it's certainly not a simple concept if implemented using the limited data we have.
Care to elaborate? Scrolling back up through the topic, I cannot find anything I posted that wasn't related to what I quoted
Yellow flags are only caused if a person is spun on the track or a lot slower than other people. So not all of those situation would cause a yellow.
When I talk about how you can't detect non-colliding incidents you answer by telling how insim works or how collisions are detected.
One would have to gather statistics on this, but in my experience, unexpected manouvers with significant consequences cause yellow.
Unfair driving would almost certainly be reported by the affected, so software to detect this seems like a waste of time to me. It can be done though.
Where in this topic would that be? No, nevermind.
Again, I didn't mean to offend you in any way, yet I get the feeling you took offense in my first reply to this topic and subsequently interpreted my posts as if they were written with hostile intent. They were not, I apologise for the unclear wording.
I don't think you're stupid either, several posts you made on here prove you know your stuff.
Let's just agree to disagree about whether it's easy or not and leave it at that
