TC-R XRT updated 8, 83; new 16

From what I can tell, it is technically possible and valid to send/receive a packet with a zero byte payload*, though I have no idea why anyone would try to send a packet like that.

It's possible CloudFlare does some header only communication for some reason, which doesn't require a payload. They do weird things with headers sometimes...



*I was researching this while trying to debug some Sim Broadcasts stuff

Something worth noting regarding the replay in my screenshot, that was a replay of a race I'd just been in. I don't think I'd restarted LFS in the meantime, so it may have been a download that was still stuck from the race itself.


Edit: Said race happened *before* Victor turned off CloudFlare, even if I couldn't load the replay sometime after. It's still possible that turning off CF has solved the issue.

Wild stab in the dark in case it is a CloudFlare issue - could it have been that the first time someone downloads a particular skin, CF's attempt to load and cache does something weird when someone requests the file the first time? All of the events I've been in lately will likely have had multiple brand-new skins uploaded for them.

Last edited by Degats, Wed 28 Oct 2020, 11:29.

Quote from Scawen :

k_badam says he is using the latest test patch. I guess it's not related to the test patch, because it has been going fine since April without any problem. But to confirm that, are any of you getting the same fault with the official version?

FWIW, I'm also using the test patch, though looking at my downloads I only changed from U7 to U11 on October 3rd. I've only noticed this issue over the last few weeks, so that *may* be related, though could be a red herring. I'd previously been using U7 since ~July last year with no issues.

Quote from Scawen :

The screenshot posted by Degats might be a clue. The negative number might indicate corruption (perhaps by a buffer overrun) or an unexpected way through the code.

Degats, would it be possible to share that replay? (Or anyone else who got that problem when starting a replay). If the same thing happens when I try to start the replay then I should be able to catch it. If this is reproducible by any means then I'm sure I'll be able to catch it.

When I reopened it after restarting LFS, it downloaded all the skins fine, so it seems to be somewhat random.

Here are some replays with a lot of skins, all of which at least one person had trouble with when on the server. It's possible you might be able to hit the issue purely based on the number of skins.

http://replays.newdimensionracing.com/mpr/LRL/2020/LRL2020_Round12_Race.mpr
http://replays.newdimensionracing.com/mpr/TBOC/2020/TBOC2020_Round2_SprintRace.mpr
https://tc-racing.co.uk/downloads/trr/BL2R_TRR2020_R40_R1b.mpr

I just had this when loading a replay (-12/8 screenshot attached).

The skins don't download over several hours; it gets stuck permanently until you close LFS from what I can tell.
It seems to be a random skin every time, restarting LFS will usually successfully download the one that was stuck, but may or may not get stuck with another.

Last edited by Degats, Tue 27 Oct 2020, 21:45.

Quote from Racon :

If I understand it correctly, more packets would also mean more physics processing, as each packet causes some recalculations to account for ping.

AFAICT, when a new packet turns up, it just corrects the initial conditions for the next physics loop.

More pps should mean that the prediction error wouldn't get so large, but I don't see how it would cause more physics processing.

It could potentially even reduce the distance to other cars where physics calculations could be turned off (assuming this is already a thing), as less prediction would be needed.



Edit:
Servers' connection speeds and bandwidth limits have increased a *lot* since the current pps settings were done. There's a lot of room for improvement.

I was talking to Pete about this a couple of months ago (along with other broadcasting stuff) and did some calculations - there should be plenty of bandwidth headroom to increase both pps *and* max number of cars on track a decent amount with no issues as far as we're concerned.

Last edited by Degats, Wed 14 Oct 2020, 21:45.

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