Eric's been busy

Obligatory comparisons:

https://imx.tc-g.uk/so202009/01
https://imx.tc-g.uk/so202009/02
https://imx.tc-g.uk/so202009/03
https://imx.tc-g.uk/so202009/04
https://imx.tc-g.uk/so202009/05

https://imx.tc-g.uk/so202009/06
https://imx.tc-g.uk/so202009/07
https://imx.tc-g.uk/so202009/08
https://imx.tc-g.uk/so202009/09
https://imx.tc-g.uk/so202009/10

https://imx.tc-g.uk/so202009/11
https://imx.tc-g.uk/so202009/12
https://imx.tc-g.uk/so202009/13
https://imx.tc-g.uk/so202009/14
https://imx.tc-g.uk/so202009/15

https://imx.tc-g.uk/so202009/16
https://imx.tc-g.uk/so202009/17
https://imx.tc-g.uk/so202009/18

Quote from KevinRacer :

I really hope some capable guy will do a new tv director

Already on it. Nearly all Sim Broadcasts streams have been running early versions of my new director software (shameless plug).

There's quite a long way to go before it will be ready for a public release and it isn't yet able to do much useful when running standalone (it currently relies on other Sim Broadcasts software) but that will change in future.

Last edited by Degats, Thu, 6 Aug 2020 21:51.

MRT for #83

We've come across this a few times, which was noticed as it caused issues with the Simbroadcasts results overlay.


If a player leaves (Shift+S or disconnect) after finishing a race, but before the IS_RES packet is sent, the PLID in IS_RES is still the old, no-longer valid, PLID.

This is presumably a bug, as the documentation in insim.txt says:

Replay download (again, the same OEC replay as the other threads)


Compressed log: (more complete log attached)

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:

Last edited by Degats, Sun, 12 Jul 2020 23:28.

Can concur.
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.

For example:


(Ignore the absolute UTC timestamps, that's when the log was recorded, not when the race happened. Useful for relative times)

In this case, the pitstop time as reported in the PIF was 2.05s, whereas the actual time between IS_PIT and IS_PSF packets was 20.48s


There are numerous instances of this issue in the OEC replay: http://replays.newdimensionracing.com/mpr/OEC/2020/OEC2020_Round1_Race.mpr


There are a few other potential pitstop bugs in that replay, which I will report once I've properly made sense of them.

Quote from LakynVonLegendaus :

Thanks, I was looking for your post haha. First image seems broken btw.

If you mean the left third of the before shot, there's a low res wall in the way

Quote from MicroSpecV :

I see playing Russian roulette down into Turn 1 is a thing now

Could be worse, could be the planned London F1 route

Obligatory comparisons:

https://imx.tc-g.uk/so202006/01
https://imx.tc-g.uk/so202006/02
https://imx.tc-g.uk/so202006/03
https://imx.tc-g.uk/so202006/04
https://imx.tc-g.uk/so202006/05
https://imx.tc-g.uk/so202006/06

TC-R XFR #8 and #83

Quote from Flame CZE :

Do PNGs work in LFS?

Nope, I wasn't paying attention - too sleepy Fix'd

TC-R FZ5 #8 and #83

Last edited by Degats, Tue, 26 May 2020 16:35.

TC-R LX6 #8 and #83

Updated TC-R FOX #8 and #83

TC-R UFR #8 and #83

Quote from Scawen :

Thanks for the testing.

To my mind it is still possible that the bad collisions were related to lag and prediction causing excessive intersections rather than being related to VOB at all. As we know bad collisions can happen at any time between unmodified cars. It's true I could do a better job with that.

I understand you asked some people when you saw the collisions and often found out they were using VOB mods. But maybe these mods are just commonly used by people who go to cruise servers?

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.

Quote from Evolution_R :

What if I change the name of the car, remove all of the logos, badges etc. so only the base shape is the same? I'm not a very familiar with the copyright infringements, but something that Chinese car manufacturers do - copy the base shape and change some minor details.

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.

Last edited by Degats, Wed, 29 Apr 2020 21:41.

Quote from Evolution_R :

What if I remove all of the logos, badges etc. so only the base shape is the same?

Traditionally, this has often inadvertently also affected the collision behaviour. Since we don't know how the offending VOB mods get through the detection, we have a blanket ban to be safe.

Quote from Scawen :

This does not affect online usage.

The physics mesh (collision box) is included in the OOS check so the player is kicked if that is changed. That has been the case for as long as I can remember, otherwise such things would be used all the time. This change is only about allowing the discussing and sharing of mods.

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.

Last edited by Degats, Wed, 29 Apr 2020 21:19.

Race 2 10:15
#55 too hot into the corner, hit my car quite hard, pushing me wide and out of shape, causing me to lose positions to both #55 and #71

Race 2 10:25
#56 several avoidable full throttle taps into the rear of my car, unsettling my car several times losing speed

Race 2 11:55
#56 more tapping, followed by excessive bump drafting, nearly causing me to spin out

Race 2 12:05
#03 changes line and hits the back of #56 hard, which in turn pushed me wide causing me to lose a place to #56

TC-R XFG #8 and #83

#16

TC-R BF1 #8 and #83 (4096)

Quote from Scawen :

It's good to hear that D3D11 still can work on Linux, because I don't want to restrict users to Windows. But I'm not so pleased to hear that D3D11 support requires a DX12/Vulkan GPU.

I don't have any plans to set up a Linux computer with a super graphics card to test DXVK - we don't have those kind of resources! As in space, time, money, etc. But hearing all those other games run fine, I would be surprised if LFS didn't.

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).

TC-R v1

#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).