This is pretty much what the LFS pth files are, it's a reference lap with nodes/lines saved at regular intervals (with additional geometry that isn't required for deltas).
For each lap you care about: save the position, direction, speed, and time since the start of the lap in whatever interval is useful. Compare that reference lap against the current lap/latest IS_MCI data and you can calculate the delta.
I can't remember exactly what the calculations are and I haven't got time to dig into it at the moment, but it uses a combination of speed and position of all cars from InSim, and measuring distances from the .pth node lines which are used as references.
LFS limitations for Simbroadcasts usage are mostly described here https://www.lfs.net/forum/post/2056282#post2056282. I don't think they're show stoppers, just make for more edge cases and added complexity that I will need to deal with.
I don't think they'd stop you from recreating LFS Lazy type stuff though.
Yes, DRLs have a sidelights switch (for LED ones anyway):
DRL: Front only (except Scandinavia where they also have taillights); bright enough to outshine the sun
Sidelights: Dim front to not blind people when it's darker + taillights.
Headlights: Normally still have DRL on in dim mode in addition to dipped/full beam.
Auto lights usually have the above plus an auto position.
Yeah, I was also thinking during the race on Thurs that separating engine damage to a separate InSim repair flag would be useful (though I imagine that would also involve changing it to a unique damage type as well rather than generic, which I assume was done to make implementation simpler?).
Not sure if this is relevant as I was on D42, but I just had a hard crash to desktop while joining a server with lots of mods.
I not sure exactly where in the sequence it was as I wasn't really paying attention, but LFS had to download a lot of mods when I restarted and connected again so must have been soon after clicking join.
FWIW, I have a real-time delta feature mostly implemented (but not enabled) in the Sim Broadcasts InSim. It can be quite accurate (tested down to at least 1ms from a replay) with some limitations and caveats (see below).
It uses a combination of the LFS .pth files (or compatible custom ones that I make as needed for custom configs and entirely new layouts) and car position & speed from MCI packets.
A note for those who are not aware, LFS "nodes" actually refer to lines which are described in the pth files, drawn to the left and right of direction vectors with coordinates (nodes) which make up an approximate racing line.
I haven't fully finished the feature yet, as we intend to use it for more accurate reporting of the race order, and there are a few problems/limitations that raise some tricky edge-cases when needing to implement a seperate timing system. We need this for a couple of reasons:
LFS has a "bug" where if two cars are close enough to eachother to be within the same node, LFS might show the cars in the wrong order (I believe it sorts them by PLID or something) causing the positions to flip around a lot when they physically aren't overtaking eachother.
In custom configs, we only get position changes from LFS at sector lines, which can get confusing for commentary.
So, to the limitations (may only be a significant problem for Sim Broadcasts'/T&S use, but they're why I haven't yet finished the feature):
The car positions from MSI packets are not always accurate. I need to do some proper testing, but I believe it may be significantly worse when running on a server (though it may be just as bad on the client, TBC). This comes from the fact that MCI packets aren't sent in-line with position packets sent client <-> server within LFS. MCI packets are sent at regular intervals, whereas the internal packets are variable rate. This means that the MCI positions are relying on the LFS prediction, which obviously can't always be correct. Under most condititions, this doesn't cause a major issue, but in cases of severe lag (especially combined with fast control inputs) or heavy collisions into walls etc, the positions can end up being quite wrong for one or more packets.
In default configs (and most custom pth files), the Start/Finish line (and maybe sector lines?) don't neccesarily match a node. It is often halfway between two nodes, which can be several metres away. There is also no way for InSim to find out exactly where the S/F or sector lines are with default configs, though they can be read from the layout for open config. This may not be a problem when calculating deltas to another car (the purpose of this thread I guess), but does throw a spanner in the works for a custom timing & scoring system (which is Sim Broadcasts' main use) or for calculating more accurate split times than 100th of a second.
InSim does not know when the actual start of the race happens, or (mostly for custom layouts) the correct order of cars at the moment the race starts. The initial REO isn't neccesarily the final starting order because of cars joining late/spectating. It's possible the REO gets updated later, but I've not yet tested that. This means that you can't reliably start calculating deltas until a car has crossed a split (or potentially some other line, but that would need to be configured per layout).
Now, the above may not be a problem if all you need is a mostly correct delta, don't mind not having data till crossing a sector line and can work around some other edge cases. It makes my uses quite a bit more complicated though
For qualifying the option to enforce HLVC, where a fail means the laptime gets deleted, would probably be the simplest solution - though that would involve fixing the HLVC bugs, if they still exist, and presumably wouldn't help for open configs - maybe having checkpoint/circle objects that can trigger HLVC fail would work there.
I suppose a time-penalty option would be needed for one-shot quali.
For races, I like the idea of being able to set somewhat arbitrary time penalties, to be served either at the next pitstop or by a race time adjustment (F1 rules).
However, I'm really not a fan of instant off-track/cut penalties during races as it's often not fair. When racing in close quarters with others, you could end up running afoul of it through no fault of your own and/or without gaining an advantage.
This is usually handled IRL by having a number of strikes where you can trigger a cut timing line x number of times before gaining a penalty. In endurance races, this is usually defined as x per hour.
tl;dr for some "easy" (hah!) wins:
Arbitrary time penalties.
- a) Race: issued by admin/InSim for served at stop/race time. (HLVC is too strict for this, we're not MSV I hope)
- b) Quali: issued by admin/InSim/HLVC.
Option to have HLVC delete a lap or add time penalty in quali
Control objects to trigger HLVC (behaviour as #2)
For racing, I think there are so many variables, it may be too complicated for LFS to have a good general solution. InSim preferred IMO (helped by 1. above).
An x strikes system based on race length *may* be doable without settings getting out of hand, but I'm not sure how useful it would be without built-in less-strict-than-HLVC detections.
That's exactly how I used to have my setup back in the day, it works well (though not tried it with mods).
IIRC, the idea with the power steering was to make the steering weight more consistent between cars. Like an overall target weight, rather than just a global force multiplier (which is all the ffb setting is).
Yes, hence it would need to be optional as a server setting.
It would only really be useful for organised events where you can enforce racers to have the *default* colour at the beginning of their name, which would mean the old colour behaviour (ahead/behind/lapped etc) would still apply to racers' arrows, but course cars with coloured names would show that colour instead.
Thought of a potential use for the arrow colours even when lap timing is available - though it would have to be a server option:
From what I can tell, if people use the default name colour, it uses the default arrow colour?
If so, it might be useful in organised races with safety/course cars to be able to enable the arrow colours. Racers would start their name with the default colour & have the default arrow colours, and course cars would pick up the custom colours. This means racers can easily see where the course cars are.
Not sure how good it would be for chases on cruise servers, as it will make it even easier for police to follow where a car is going on the map. Given the highly competitive nature, it would change the balance a bit.
Nice, especially now GRC/VHPA seems to have problems saving setups correctly these days.
Would it be simple to also mark where the shift point (ie when the shift light comes on) is for each gear? Maybe some kind of marker on the sliders?
To add to this and throwing it out there for the potential future overhaul:
I've been thinking for a while that it'd be really handy to have parametric objects, especially for anything linear like the armco/barriers. Being able to have (somewhat) arbitrary length & curve radius would be really handy.
Also adding a request for 3-high armco (ie F1 armco walls) while I'm here