Another bug report based on the OEC R1 replay, as promised here. Replay download (same as other thread)
There are some cases (potentially only when a Takeover happens) where an IS_PSF (Pitstop Finished) packet is not sent.
While looking into this, I also spotted something strange and potentially related - in this specific case where IS_PSF wasn't sent, it seems an extra IS_PLA was sent. I'm not sure how often this happens; I'll have another scan of the log when I get some time.
In the log below, we have:
Cyan: A pitstop with TOC & PSF (bold) as expected. PSF STime is wrong as reported here
Green: A pitstop with TOC, but no PSF. Has an extra PLA (bold) instead.
White: A "normal" pitstop, no TOC.
More reports to follow when I'm more awake.
Text version of log if you find it helpful:
2020-07-12 22:38:16.651 UTC CSC: [excellent15] [^101 ^7R. Takahashi] STOP @ 01:05:12.550 2020-07-12 22:38:16.652 UTC Pitstop Started: [excellent15] [^101 ^7R. Takahashi] Work: 141474 2020-07-12 22:38:17.371 UTC Entered Pitlane: Fact 1 PLID 66 [excellent15] [^101 ^7R. Takahashi] 2020-07-12 22:38:27.612 UTC Entered Pitlane: Fact 1 PLID 72 [narkoze] [^134 LLM. ^7Ripe] 2020-07-12 22:38:31.252 UTC Entered Pitlane: Fact 1 PLID 53 [zapphord] [^142 ^2CR^0^v^7Eisbaer] 2020-07-12 22:38:33.452 UTC CSC: [zapphord] [^142 ^2CR^0^v^7Eisbaer] STOP @ 01:05:29.260 2020-07-12 22:38:33.453 UTC Pitstop Started: [zapphord] [^142 ^2CR^0^v^7Eisbaer] Work: 141474 2020-07-12 22:38:34.203 UTC CSC: [narkoze] [^134 LLM. ^7Ripe] STOP @ 01:05:30.210 2020-07-12 22:38:34.203 UTC Pitstop Started: [narkoze] [^134 LLM. ^7Ripe] Work: 141474 2020-07-12 22:38:35.742 UTC TOC: PLID 66; Connections: 8 [excellent15] [^101 ^7R. Takahashi] -> 18 [fastlt] [^101 ^7K. Takahashi] 2020-07-12 22:38:37.131 UTC CSC: [fastlt] [^101 ^7K. Takahashi] START @ 01:05:32.970 2020-07-12 22:38:37.132 UTC Pitstop Finished: [fastlt] [^101 ^7K. Takahashi] 00:02.050 2020-07-12 22:38:51.742 UTC Left Pitlane: PLID 66 [fastlt] [^101 ^7K. Takahashi] 2020-07-12 22:38:53.192 UTC TOC: PLID 72; Connections: 29 [narkoze] [^134 LLM. ^7Ripe] -> 31 [sobis] [^134 LLM^0.^7Sobis] 2020-07-12 22:38:53.452 UTC CSC: [sobis] [^134 LLM^0.^7Sobis] START @ 01:05:49.260 2020-07-12 22:38:55.872 UTC Missing splits: we have 0 splits, new split is: 2 2020-07-12 22:38:56.101 UTC Entered Pitlane: Fact 1 PLID 72 [sobis] [^134 LLM^0.^7Sobis] 2020-07-12 22:38:59.052 UTC CSC: [zapphord] [^142 ^2CR^0^v^7Eisbaer] START @ 01:05:54.840 2020-07-12 22:38:59.052 UTC Pitstop Finished: [zapphord] [^142 ^2CR^0^v^7Eisbaer] 00:25.580 2020-07-12 22:39:01.231 UTC Left Pitlane: PLID 72 [sobis] [^134 LLM^0.^7Sobis] 2020-07-12 22:39:04.741 UTC CSC: [lacko86] [^299 ^4LFS.HU ^7Lacko] STOP @ 01:06:00.600 2020-07-12 22:39:04.742 UTC Pitstop Started: [lacko86] [^299 ^4LFS.HU ^7Lacko] Work: 141474 2020-07-12 22:39:04.912 UTC Entered Pitlane: Fact 1 PLID 61 [lacko86] [^299 ^4LFS.HU ^7Lacko]
There were numerous cases of this in the first round of the current OEC series, which uses pitstop time for Balance of Performance, where knowing correct pit timing automatically is helpful.
TBH, I wouldn't hold out any hope in finding an actual VOB file that can bypass the check alone - as you said, the checks done by LFS itself should probably find any issues.
My concern is that there are tools that mess with the LFS client (or network) in some way that fools the server into thinking that the mesh is the correct one. Considering the many weird and wonderful physics hacks we've seen over the years that don't get caught by OOS checks, I'd imagine it would be (relatively speaking) trivial for similar tools to load un-fixed VOB files on the client, but just trick the server into thinking that the mesh is fine.
We know of a few tests that can be done to check whether issues are lag related or not and LFS itself is pretty good at letting us know what kind of lag issues an individual has. Typical VOB-related issues are also subtly (and sometimes not so subtly, depending on the mesh) different from lag, though it does often require specific testing that we usually don't have the luxury of doing - people don't tend to hang around once they think they've been busted breaking the rules; the number of times the problem goes away after the suspicious player "accidentally" disconnects/loses connection when questioned and returns shortly after is remarkable.
Rockstar seem to be able to get away with it to a certain extent in GTA, though most of them have a similar level of "inspiration" as some of the stock LFS cars (though Rockstar use much more blatant names).
Chinese manufacturers have been known to be sued for copying designs, however the local courts normally side with the local companies and the cases don't go anywhere. It would be very different in western courts.
Edit: See also: Nikola vs Tesla (truck design), Apple's infamous "literally nothing more than a rectangle with rounded corners" patent.
That's certainly the theory, and there were a lot that got caught by the OOS check soon after the collision mesh was added to it, however based on our (extensive) experience, it seems to be possible to get around this somehow.
There are a few things that we look out for and checks that we make that strongly indicate there is still an effect on collisions for at least some VOB mods.
There are still several other physics related hacks that seem to get past the OOS detection last I heard, so it's possible that some of the VOB related issues we have also involve .exe/memory hacks/something else to fool the OOS check.
Either way, the end result is that we still get collision-based weirdness (that's different from lag) where, more often than not, it turns out that the player involved has a VOB mod on the car they're driving (it's harder to check if they have a VOB loaded on other cars, but it causes the same issues).
We had considered lifting the TC ban on VOB mods after the OOS check was added, but it didn't sufficiently resolve the issue, so the ban remains.
FWIW, DirectX 12 (albeit in a lower feature set mode) works from nVidia Fermi (600 series, 2010) and AMD GCN 1.0 (HD 7000 2012).
Vulkan supposedly works on cards supporting OpenGL 4.x and up, which means Radeon HD 5000 (2009), though still Fermi.
Not entirely sure how all that applies to DXVK, but since it seems DXVK claims to only need a Vulkan capable GPU (and driver) it may well work on some more older cards.
I think I have an old HD 5000 series knocking around somewhere that I could use to test (though I've never tried using DXVK before). I do have a 4000 series, but that supposedly won't work (OpenGL 3.3).
#80 Race1 10:45 L7:
Unsafe rejoin across the whole track onto the racing line, forcing me off the track resulting in me hitting a tyre and spinning out.
#12 Race1 17:00 L10/11:
#12 Very slow at the start of the straight after deciding against pitting. #12 Moved over in front of me under braking, blocking my path with no way to avoid a collision.
#72 Race2 07:24 L5:
Hit in rear into T2 chicane, causing me to go off track and lose even more time. I lifted to avoid hitting #34, but #72 was already going ~10mph faster than me before that - would have hit me anyway (lift only slowed me by ~3mph before impact).
DirectX 10 was a complete rewrite, throwing out a lot of legacy code in order to improve performance and efficiency.
Adding to that, modern GPUs and drivers tend to focus on the more modern APIs, features and techniques when optimising performance, sometimes sacrificing the legacy stuff (which they can largely brute force in older games). They are now pixel/vertex shader machines.
Both of these probably contributed to the improved performance somewhat.
DX10+ is also able to handle multiple threads better, which has the potential to reduce the reliance on a single, fast CPU core.