Quote from mbutcher :

We (Sim Broadcasts) also noticed some frame drops during our broadcast of round 1 last Sunday. We'll be trialling a new AMD CPU with a 50% higher clock speed for round 2 to try and combat this (3 cheers for AWS ) - Your experience would have been smoother than ours because you were driving, not observing 35 cars at full LOD all at once.

I can assure you my experience was not that smooth as my game actually *crashed* on both occasions (that's why I dropped out and had to start both races from the pitlane), though that was due to my Linux/wine not being properly configured and should not happen next Sunday (I hope, I'm not planning to install Windows ever again on my PC...).

The T1 incident with the Ferrari mod looks horrendous though, I've never seen such frame drops (or such T1 carnage ), it's definitely necessary to have sensible limits to avoid this kind of situation.

@Scawen I suppose the freezes occur while the game is loading the assets (car model and/or skin), would it be possible to load those on a non-blocking thread instead? And either keep the car invisible while assets are still loading, or load and display them from lowest LOD to highest, so that the game could still display something while it loads the higher detailed stuff, and avoid stuttering/freezing?

I know you don't agree with many modders about triangle count, and I understand the reasoning, though I don't personally agree that 65k triangles is *too much* - however I do agree that getting 65k for the sake of getting them, even if they don't bring anything visually, is a waste of resources. I just think that some other popular sims (think iRacing or ACC) manage grids larger than LFS, with cars that I believe are probably all more detailed than LFS cars (and probably LFS mods as well), and they seem to work pretty well; the engine running the games is different though (Unreal for ACC, not sure about iRacing), so while I agree modders should not abuse the limits, and I understand why you don't want to increase those limits, maybe there is still something you could do to alleviate this particular issue?

I'm not sure what the threshold is where the problem appears, I know some people talked about it after the NDR GT4 Sprint Cup with the N.400S GT4 (there were 35 cars racing + safety car and rescue vehicles), I didn't personally notice any stuttering but I do have a rather powerful computer (Ryzen 7900X, AMD 7900XT, 32GB of RAM, NVMe SSD).

Last edited by Bokujishin, Tue, 16 Jan 2024 22:13.

yes/21/Bokujishin

yes/21/Bokujishin

Here is #21.

I am making an InSim/OutSim/OutGauge library using the Godot game engine, so I went through the documentation as provided in docs\InSim.txt, and found the following mistakes, as of version 0.7E:

• lines 450-451: TINY_PING is in the wrong section, the same lines appear in the proper section at lines 487-488.
  
• lines 1043-1046: TINY_VTC is in the wrong section, and is already documented at lines 894-897.
  
• line 1769: typo: TINT_NCN instead of TINY_NCN.
  

I believe I went through the entire file and found nothing more, though I did not read all parts in full detail (such as AutoX).

21/Bokujishin/Cyril Bissey/France/no team

Great job on this update! I hope you take a well-deserved break, and feel free to make the next series of test patches as early as reasonably possible so we can test the tasty new physics and graphics

My understanding is that the rotator controls the angle (just like the slider controls the position), whereas the spinner controls the speed of rotation, or angular velocity.

Quote from Scawen :

The temporary download is http (not https) it's actually fine, no-one will hack your communications while you download this file. It's not a sensitive communication, just a publicly available file so if you can tell your browser not to worry about it that will be fine.

Yeah, I wasn't too worried, just thought it was unusual; anyway, in-game update works just fine, even on my Linux machine.

When I click on the link, Firefox tells me it didn't download because of a potential security risk, this never happened with the previous test patches.

Edit: In-game update worked perfectly fine.

Popup lights do not deform with the rest of the car. Yes, I drove straight into a wall, twice, to get this kind of damage. Probably not too important since wheels can appear to not be physically attached either.

Quote from ScammerGamerLOL :

Will there be graphics and night mode in the 0.7E? and how many days left until release?

No, 0.7E will only have what we have in the current test patches, new graphics/lighting is (hopefully) what the next series of test patches will be for.
I believe Scawen said he wanted to release 0.7E sometime next week or the week after.

Very nice! I wasn't expecting to see those popup lights working until the new graphics and especially night time lighting. Same as gu3st, I'm curious to see how people will abuse this, maybe for moving rear wings on some cars?

Quote from Scawen :

Daytime running lights that are always on when the engine is running, but dimmed or off when other lights come on. DRL may or may not have an equivalent on the rear.

On my car (Renault Clio 5), depending on the version you buy, DRLs also turn tail lights on. My lights switch has 3 positions: auto/side/low, and turning the side lights on dims the front DRLs without changing the tail lights.
Looking forward to what the new graphics will bring as far as lighting is concerned, especially night time of course

Quote from gu3st :

Are you using straight WINE or using Proton? Proton may work better as it should be using Vulkan for D3D rather than the Wine D3D system?

I'm using pure wine, on this PC the GPU is so old (GTX 560 Ti) it doesn't support Vulkan. I will try again either on a different system or when I'm back on my main PC in a few days.

Thanks Eclipsed, got it.
I'll have to assume my issues are on my side, as a fresh install updated to D45 crashes just as often now, though I'm really not sure why... I was planning to try out another Linux distribution on this PC, I'll update if/when I do that or when I get back to my usual PC if anything is still broken.

Would you happen to have a link to D45 somewhere? I just realized I deleted it after upgrading to D46...
I also restarted my computer and I still have those crashes (I guess Linux is more consistent than Windows here )

It actually seems less consistent than I thought - I still get a crash 100% of the time, but not always at the exact same time.
- First scenario where it always happened: previous track was Fern Bay Green, I changed that to Blackwood BL1. Vehicle was Reaper bike (stock), with a grid of 20 AI which I cleared to ride alone. Race was set to 20 laps. The game crashed after pressing the Go button, while loading (towards the end, just before displaying the game).
- Second scenario: BL1X, alone on the Reaper bike (stock), 20 laps (no checkpoints). Crash happens after the hairpin, before the chicane.
- Third scenario (somewhat different): from scenario 1 or 2, changing the vehicle (to XRR or BF1, only tried those 2), crash happens while confirming car choice or even before that, while moving the mouse.
- Fourth scenario: I went back to Fern Bay to avoid the car selection crash, switched to XRR, then went back to BL1X, practice. The game crashes as soon as I'm done turning after exiting the garage (I tried going the wrong way as well, same result). It's almost as if something in the field of view causes it.

As for the crash address/offset, I'll have a look if I can get that, running from wine I'm not sure how to open the Windows event viewer. I do have 2 crash dumps from wine itself, but nothing in there looks like the address/offset you want. As a side note, I'm on an old PC right now, not my main PC, not sure how relevant it could be, but I had D45 on that same old PC working with no issue.
I will try and downgrade to D45 and check that none of this happens, just to be sure.

Below is part of one of the crash dumps:
Unhandled exception: page fault on write access to 0x00000000 in 32-bit code (0x6ab275f5).
Register dump:
CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b
EIP:6ab275f5 ESP:054cf7e4 EBP:054cf808 EFLAGS:00010206( R- -- I - -P- )
EAX:00000000 EBX:1e62ef00 ECX:0016850c EDX:00000000
ESI:1fe00030 EDI:00000000
Stack dump:
0x054cf7e4: 1e5f4b88 054cf8b8 6ab2f0be 00000000
0x054cf7f4: 1fe00030 0016850c 1e62ef00 054cf8b8
0x054cf804: 1e5f4b88 1e62ee08 03424875 00000000
0x054cf814: 1fe00030 0016850c 40002000 00008892
0x054cf824: 1e5f4b88 012d7884 034425cf 012d7884
0x054cf834: 012a0f30 00000002 00000001 012c73cc
Backtrace:
=>0 0x6ab275f5 in ucrtbase (+0x675f5) (0x054cf808)
1 0x6ab2f0be memcpy+0x4e(dst=0x000000000, src=1FE00030, n=0x16850c) [Z:\usr\src\packages\BUILD\dlls\msvcrt\string.c:3063] in ucrtbase (0x054cf808)
2 0x03424875 wined3d_context_gl_unmap_bo_address(context_gl=012A0F30, dst=054CF8B8, src=054CF8B0, range_count=0x1, ranges=1E62EF00) [Z:\usr\src\packages\BUILD\dlls\wined3d\context_gl.c:3125] in wined3d (0x1e62ee08)
3 0x03424875 wined3d_context_gl_copy_bo_address+0x1a5(context_gl=012A0F30, dst=054CF8B8, src=054CF8B0, range_count=0x1, ranges=1E62EF00) [Z:\usr\src\packages\BUILD\dlls\wined3d\context_gl.c:3124] in wined3d (0x1e62ee08)
4 0x0341710f wined3d_context_copy_bo_address+0x47(ranges=<internal error>, range_count=<internal error>, src=<internal error>, dst=<internal error>, context=<internal error>) [Z:\usr\src\packages\BUILD\dlls\wined3d\wined3d_private.h:6589] in wined3d (0x1e62ee08)
5 0x0341710f wined3d_buffer_load_location+0x38f(buffer=1E62EE08, context=012A0F30, location=0x8) [Z:\usr\src\packages\BUILD\dlls\wined3d\buffer.c:666] in wined3d (0x1e62ee08)
6 0x0341866a wined3d_buffer_load+0x19a(buffer=1E62EE08, context=012A0F30, state=04AC002C) [Z:\usr\src\packages\BUILD\dlls\wined3d\buffer.c:902] in wined3d (0x012a0f30)
7 0x0341aa68 context_update_stream_info+0x148(context=012A0F30, state=<is not available>) [Z:\usr\src\packages\BUILD\dlls\wined3d\context.c:306] in wined3d (0x00000000)
8 0x034271ba context_apply_draw_state+0x20c(indexed=<internal error>, state=<internal error>, device=<internal error>, context=<internal error>) [Z:\usr\src\packages\BUILD\dlls\wined3d\context_gl.c:4244] in wined3d (0x012a0f30)
9 0x034271ba draw_primitive+0x43a(device=<is not available>, state=<is not available>, parameters=<is not available>) [Z:\usr\src\packages\BUILD\dlls\wined3d\context_gl.c:5151] in wined3d (0x012a0f30)
10 0x03437ab6 wined3d_cs_exec_draw+0xe6(cs=04AC0020, data=04DA6B00) [Z:\usr\src\packages\BUILD\dlls\wined3d\cs.c:1006] in wined3d (0x00000000)
11 0x0343b4bb wined3d_cs_command_unlock(queue=<internal error>, cs=<internal error>) [Z:\usr\src\packages\BUILD\dlls\wined3d\cs.c:3308] in wined3d (0x054cff28)
12 0x0343b4bb wined3d_cs_execute_next+0x53(ctx=<couldn't compute location>) [Z:\usr\src\packages\BUILD\dlls\wined3d\cs.c:3307] in wined3d (0x054cff28)
13 0x0343b4bb wined3d_cs_run+0x13b(ctx=<couldn't compute location>) [Z:\usr\src\packages\BUILD\dlls\wined3d\cs.c:3374] in wined3d (0x054cff28)
14 0x7b629ee0 in kernel32 (+0x29ee0) (0x054cff48)
15 0x7bc5c6e7 in ntdll (+0x5c6e7) (0x054cff5c)
16 0x7bc5cef0 RtlCreateUserThread(entry=0343B380, arg=04AC0020) [Z:\usr\src\packages\BUILD\dlls\ntdll\thread.c:306] in ntdll (0x054cffec)
0x6ab275f5 ucrtbase+0x675f5: movq %mm0,0x0(%edi)

And some thread info regarding LFS:
00000158 (D) C:\LFS\LFS.exe
0000015c 0
00000160 0 <== wined3d_cs
00000164 0
00000168 15 winepulse_mainloop
0000016c 15 winepulse_timer_loop
00000170 15 wine_dsound_mixer
00000180 0

I don't know if it's just me, but I'm getting a consistent crash when trying to race on Blackwood BL1 on patch D46, where D45 was working fine. I can drive on BL1X though.
I'm playing on Linux through wine, but was having no problems at all before D46 and now it keeps crashing (just happened as I was changing cars too).
On the bike handling side, I now understand what people said about D45, it's true that D46 makes bikes much more agile at lower speeds.

I haven't done much low-speed maneuvering (and not that much riding either), but I agree with Scawen on D45 low speed, D44 and before, the bike would make one or two big oscillations after a low speed corner, and now this doesn't happen anymore.
Very pleased with D45, bikes are pretty fun to ride, even though I'm terrible... At the very least, I feel this should be good enough until the new physics.

Last edited by Bokujishin, Sat, 28 Oct 2023 20:22.

I think the new safety margin on braking is a bit too high now in D44, to the point that when racing with the XRR, if I'm on the inside line but slightly behind an AI, I can basically slam the brakes slightly later than the AI and get right alongside, and still have enough grip to complete the pass before exiting the turn without running wide. Maybe toning it down a bit could bring good balance between safe braking and performance? Or maybe have that margin reduced with higher AI skill?

Another point I saw mentioned a few times, which was introduced around D40-41 I believe (when AI stopped braking for no apparent reason), is the tendency for AI to bump into you, typically when you're on the outside line, both on turn entry and exit, where they can push you wide. I much prefer the current behavior to the old one, but I now tend to "protect myself" by basically pushing back against the AI car so I don't end up in the grass.

Just to make sure: are AI driving the N400 GT mod actually super slow, or are they just driving on the default setup (which is using sports tires) while you are using slick tires? I just started a race around Blackwood with the slick tires, and noticed the AI were really slow, until I forced them to use my setup - they're still slow, but definitely not *that* slow on slicks.

Patch D41 is much much better with AI, they're not braking for no apparent reason anymore when side by side.
They still seem to get stuck behind other static cars however (especially those that run out of fuel and stop in the middle of the track), or on exit of some turns (T1 in Blackwood for instance, though they usually don't stop entirely there).

Quote from Scawen :

It sounds good so far. I'm sure most of the changes must be for the best. It's still possible that there are some negative side-effects.

Not sure if it's a side effect of the recent patches or not, but as tankslacno mentioned, AI have some difficulties in the pits, and this is exacerbated by their tendency to all pit on the exact same lap. Some variation in strategy would be nice, even if random, although I guess that's out of the scope of this patch.
Also mentioned by tankslacno, the "snake move" was rather common in previous test patches when they would try to overtake, it feels to me like they're driving with a PID constraining them to the racing line, and changing line or jumping into/out of the pits makes for a very brutal transient that they can't save.

The overall experience with AI racing is much more interesting none the less, but if I can bring up one more point, it would be their blindness to obstacles, as they make no effort whatsoever to avoid cars stranded in the middle of the road, or bikes lying on the ground.