Hi!

I recently started a host on LFS.net.

Everything else seems to be displayed correctly, but I noticed that when you're looking extended settings on your host, it erroneously states that max cars per guest can be ranged from 1 to 3, even though you can actually set it up to 32.

Now, that wouldn't be too big of a problem, except when I stopped my host and started it again, I noticed that number went from 32 back to 3. I did save it beforehand when I did set that number to 32.

I noticed this decreasing happening both in-game when I started that host again and joined it as well as on extended settings when managing my host in LFS website.

Quote from Scawen :

...but in the case of actual bugs or anything that we would regret not fixing before this weekend's release, please do tell me if I seem to have missed or forgotten anything.

I posted few possible bugs in this thread few days ago. There is a possibility that you may have missed this one and I think this one is an actual bug introduced in D50:

Quote from tankslacno :

2) Related to this test patch: bug when using command /h_mass

If you choose a vehicle, which maximum voluntary added mass is less than 200 kg, and you decide to add a value that is higher than that vehicle's maximum possible added mass, LFS erroneously states, you have that much of added mass as a handicap, even though you don't really have.

...

Last edited by Scawen, Fri 15 Dec 2023, 17:10. Reason : fixed now, reduced quote

I did initially thought this was a bug, but there's a possibility it's not after all. I originally made a note about this in the newest test patch (LFS 0.7D60) when I first discovered it:

Quote from tankslacno :

Related to this test patch: bug when viewing replays

If you watch a replay of a session, where you have used /h_mass and/or /h_tres command on yourself, that cyan "Handicaps" message is still printed out on your screen...

So, here's a thing: if you're on single player and try to either:
A) Toggle on pit speed limiter or traction control when your current vehicle does not have one. (Doesn't matter if it's a mod or standard LFS car)

B) Use command /h_mass [username] [x] or /h_tres [username] [x] on yourself. (These commands were introduced in 0.7D50.)

What will happen is that if you watch a replay of a single player session where you have tried to done either of those on yourself, you still see that information message about it appearing on chat. If it's about toggling pit speed limiter or traction control, you see a message telling that your current car doesn't have one. If it's about using /h_mass or /h_tres command on yourself, you see a message showing your updated handicaps.

So let's say, you're in single player and you repeatedly try to toggle pit lane speed limiter or traction control on a car that doesn't have those, you will see that information message appearing repeatedly on your screen. If you watch a replay of it, you will still see that message flooding on chat.

Also, it's strange that only some of those messages appear again on replays; for example, information about your current InSim port does not appear anymore when viewing replay. This got me wondering, is it because they're displayed in different color (other than default color) being a reason why they're also displayed on replays?

I also tested this on 0.6V3, and same thing happened, so I know it's not a recently introduced bug. Either it's an old bug or a feature, but in any case, my question is: is there any way to hide these messages from appearing when viewing replays? And I mean permanently.

In other words, is there a setting in LFS or cfg.txt (or interface_cfg.txt) file where I can hide those informational messages appearing again when watching a replay?

I know I could use either press Shift + F twice or Shift + Minus to block them from appearing. But using those hides all other relevant information as well.

One thing I should mention is that I recently bought a new laptop and installed fresh LFS 0.7D and 0.6V3 into it. So it's possible, there is some kind of setting that causes this to happen. On my old computer, I don't remember seeing this happening.

And one thing to mention, this does not happen in multiplayer replays, only in single player replays.

In case you want to reproduce this, here's a best way to do it:
1) Go to Single Player

2) Choose car without speed limiter/traction control and start session

3) Press keys (either just once or repeatedly, doesn't matter) which would normally toggle those on/off to see that message it not being possible to enable on chat. If you have 0.7D50 or newer, you can also use those /h_tres and /h_mass commands on yourself to see that updated handicaps you currently have on your car.

4) Save a replay of that session and watch it. You will still see those informational messages appear on chat.

I've attached a screenshot about this situation to explain it better.

Hi, I found three four (possible) bugs, though I'm not completely sure this time are they how intentional after all

1) Related to this test patch: bug when using command /h_tres

If you choose a mod, which class is an object (like football), you can see it has no power unit. Therefore, the only handicap you can set to that is voluntarily added mass (and its position).

Here's a thing though: you can now use this command:

Quote :

/h_tres username X - set restriction for user's car

Which means, you can set restriction for user's object. Object that has no power unit!

Best way to reproduce is this:
1) Choose football mod (or any other object)
2) Type command /h_tres username X
3) You can now see that your object now has an intake restriction (it's even shown on F11 display), even though it should not be possible, since you cannot add that to objects while you're in the pits

2) Related to this test patch: bug when using command /h_mass

If you choose a vehicle, which maximum voluntary added mass is less than 200 kg, and you decide to add a value that is higher than that vehicle's maximum possible added mass, LFS erroneously states, you have that much of added mass, even though you don't really have.

Best way to reproduce is to do this:
1) Choose any vehicle, which maximum voluntary added mass is less than 200 kg (for example, UF1000). You can even use that football I recommended to use in the first bug, since that object's maximum possible added mass is just 20 kg.
2) Type command /h_mass username 200
3) You now see a message, that your handicaps is now 200 kg, even though F11 window clearly states something else (in case of UF1000, it is only 120 kg, so even if you type /h_mass username 150, you can still reproduce this bug).

And by the way, if you use object mod "ROAD BARRIER", you can see that you cannot add any handicaps at all to that object. If you use that mod and type that command /h_mass username X, you can see LFS stating that your handicap is now 1-200 kg (depending on the value you typed to that command), but nothing is shown on F11 display! Strangely though, your possible "intake restriction" is still displayed properly in that F11 window, when using that mod.

EDIT: Added this bug #3 as well, this wasn't originally here

3) Related to this test patch: bug when viewing replays

If you watch a replay of a session, where you have used /h_mass and/or /h_tres command on yourself, that cyan "Handicaps" message is still printed out on your screen every time you use those commands on yourself. And if you decide to watch that replay again, those messages will be also shown again.

Although there is a possibility that it's on purpose, I just don't get it why those new restrictions are shown as a message every time I watch that specific replay.

4) Unrelated to this test patch: small interface/display bug

(Although it's unrelated to this test patch, I happened to notice it while I found those other bugs, so I thought I might as well tell about this)

If you have enabled LFS logo to be displayed at top left corner of screen and decide to display Frame rate on that left side as well, LFS logo will overlap that FPS rate completely. So if you have chosen to display LFS logo in-game, displaying FPS counter on the left side of screen has a same result than not displaying FPS counter at all.

That caught my attention, because everything else (virtual start lights and small map), which can be shown on the left side are displayed properly regardless if LFS logo is displayed or not. It's just that FPS counter which is not displayed at all on the left side if LFS logo is also shown there.

Last edited by tankslacno, Wed 13 Dec 2023, 01:06. Reason : Added fourth bug as well (bug #3)

Quote from Bass-Driver :

Do the new commands require a new hostversion?

/h_mass username X - set added mass for user's car
/h_tres username X - set restriction for user's car
/teamarrows=no/yes - arrows on non-race small map use name colour

Because i get unknown commands by all of them.
And was adding some LFSLapper functionality with the new ISP_PLH insimpacket.
But cannot test it.

Yes, you need a new version and you can't start a new host with that version yet (I tried that, and it also reported that Unknown command by all of them)

Strangely though, you can use those first two commands in Single Player, but not that /teamarrows as that command still reports Unknown Command in there. I initially thought you could use that /teamarrows command so those arrows of AI drivers would change to that color each AI driver is using. But it isn't possible.

Can confirm that bug has been fixed now

However, I found a very strange glitch and also a crash:

Here's how to reproduce it.

1) Start a single player race where you are racing alongside AI-drivers - you can't do this on multiplayer replays
2) Make sure you save a replay of it - it doesn't matter if race is finished or not
3) Start the replay.
4) Now, here's the first bug: you can use commands in SPR-replays. So, if you use command /spec [AI-driver name], you can spectate AI driver from a replay. Now, soon you will encounter Replay OOS Error.
5) If you just exit that replay normally, nothing happens. However, if you start playing that replay again by pressing 1 and then exit that replay, game crashes.

Crash report:

Quote :

AppName LFS.exe
AppVersion 0.0.0.0
AppTimeStamp 65454617
ModuleName ntdll.dll
ModuleVersion 10.0.22621.2428
ModuleTimeStamp a899597e
ExceptionCode c0000005
FaultingOffset 0008fece
ProcessId 0x25e4
ProcessCreationTime 0x1da0e8cf3b78e69
AppPath C:\LFS\LFS.exe
ModulePath C:\WINDOWS\SYSTEM32\ntdll.dll
IntegratorReportId fe97f24c-b9b5-4122-a4e3-efdba67f0326
PackageFullName
PackageRelativeAppId

Now, here's how to get things a little bit ridiculous and hilarious to say the least.

Repeat the first four steps when trying to reproduce that crash. But after spectating that AI, press 1 to start that replay again. You will then encounter that Replay OOS Error. But instead of exiting, enter test drive mode.

What will happen is something really stupid. Game will merge you, and your closest AI driver together. What will happen, is following:

- If you're watching other AI-drivers, it runs normal speed. But if you're watching yourself, it enters double speed. Sounds are still enabled, though in extremely low quality. This means you can now increase game speed to 64X!

- Standings think you're watching both yourself and AI driver which merged with you.

- You can't use Shift+TAB when viewing yourself - in fact, one position is completely missing in the interface. For example, if game thinks you're in 2nd place, you can't Shift+TAB to view that merged AI whose in 1st place! And if you try to use TAB, it will skip that 1st place entirely!

And here's even more hilarious thing. If you pause that replay and then start spectating those AI drivers, you can spectate multiple AI drivers before you encounter Replay OOS Error. What will happen if you then enter test drive mode? Well, all those spectated AI's will be merged into you! What this happens that your car almost certainly starts flipping by itself and doing amazing stunts. Also game speed increases even more!

And when you exit that test drive, game crashes. Here's a crash report to that:

Quote :

AppName LFS.exe
AppVersion 0.0.0.0
AppTimeStamp 65454617
ModuleName ntdll.dll
ModuleVersion 10.0.22621.2428
ModuleTimeStamp a899597e
ExceptionCode c0000005
FaultingOffset 0004f786
ProcessId 0x3680
ProcessCreationTime 0x1da0e9109aaf070
AppPath C:\LFS\LFS.exe
ModulePath C:\WINDOWS\SYSTEM32\ntdll.dll
IntegratorReportId 7540f4af-17ef-4766-9dfe-a9603c4c507e
PackageFullName
PackageRelativeAppId

While part of me wishes that this bug won't be fixed due to how ridiculous and amazing it is, I think it's very important to fix these crashes and bugs.

And luckily, I think there is a very simple way to fix this. Prevent using commands when viewing SPR-replays. I don't think there is any purpose to use those as it seems that every command causes that Replay OOS Error at minimum, if not crash the game. In test drive mode I think using commands is fine. I spectated AI during that by command and while it stopped recording replay, I managed to restart the test drive with no problems at all.

I've attached a replay where you can test this bug, though you may need to download those five mods I mentioned when testing D47.

Scawen, I found a bug in this newest test patch. It's related to this:

Quote :

The four character version of a mod's name now appears in the results table instead of "MOD". It's an imperfect system in that more than one mod may end up with the same 4-character name, but it is useful as an indication of a mod when space is tight

It seems like with mods, their abbreviations on results table may change when someone improves a qualifying lap. I haven't tested, can this be reproduced on races, though. I've attached a SPR about this. You need to download following mods:
- POCHETE 118 GT3
- PROTECH 92 GT3
- LILLIA-X GTR
- RB GTR
- MRG V8 GTR

When you look at the replay, you can see, that at first, it works as intended. But when those cars drive that second timed qualifying lap, it changes another vehicle's mod abbreviation in that results table to something else, whenever somebody improves their best lap. Additionally, game renames those abbreviations to something else (in other words, to an abbreviation, that doesn't exist on any car on current grid).

Slightly OT, but this came to my mind, when I noticed this bug when testing: is there any reason, why that qualifying/best lap/results table is not shown at all during practice sessions (= when race length is 0 laps)?

Quote from Scawen :

I reproduced it, in my case 16 bikes at Aston Cadet rev, 6 laps race with pit stop.

I got an OOS in the replay at 4:36. I noticed a crashed bike there and watched that bike in the few seconds before the OOS occurred. It turned out that his engine was switched off about 2 seconds before the OOS.

I don't think I'll investigate more today but maybe the engine switch off is done in a way that can go OOS. Maybe if it's easy to check, you could see if the same thing happened in one of your known OOS replays.

I also get that on every replay, where OOS occured. I also noticed that could handbrake also be a factor to that? Because when they switch their engine off, they are also putting their handbrake on at the same time. Now they do have that handbrake putted on at race start, but I wonder does OOS occur only when both engine is shut down and handbrake has been putted on?

I noticed that on my replays, OOS occurres instantly when bikes rev meter needle drops to zero/minimum.

I also tested this with myself and didn't experience any problems.

Weirdly though, on FE1 bike "XINLIN 150" also shut its engine off and putted handbrake on. The difference was that AI wasn't fallen when it did that.

Quote from Scawen :

I need to be very sure, is there anything you are doing during the race? You talk about changing the AI brake balance. Have you done that or anything similar during the race? I haven't looked into whether things like that are safe for replays, but any such clues could help.

No. I didn't do anything to them, I just let them race. (Only thing I did was changing in-game speed with Shift+F2/F3, but I don't think that causes it - at least it hasn't cause that ever before)

When I talked about changing the AI brake balance, I did that on those races where modded GTR's drove and I had no problems. Additionally, on official patch, I've let AI's race with over 20 different modded single-seater cars (ranging from karts to F1) and I didn't experience any issues.

Quote from Scawen :

This is a concern. If it could be narrowed down to a particular mod or race setup, that would be very helpful.

Okay Scawen, this seems very strange. I don't think it's related to a particular mod. Instead, it's depending on how many different type of bike mods AI's are racing.

I did some testings: I downloaded every single bike mod. There are 50 of them and I sorted them by rating. Highest 32 rated mods were on first grid and lowest 18 were on second grid.

Track I used was Aston Club Reverse. Race length was 6 laps with mandatory pit stop.

And this what happened:
- When I tested with 32 bikes, I got Replay OOS Error. But when I did split those 32 bikes into four 8 bike groups, I got no Replay OOS Errors whatsoever! But when I did split those 32 bikes into two 16 bike groups, I got Replay OOS Errors! And when I let 15 highest rated bikes drive, I got no Replay OOS Errors!

- When I tested with 18 bikes, I got that error. When I did split those 18 bikes into two 9 bikes groups, I didn't get that error. For that, the cutoff point seemed to be between 11 and 12 bikes; there were no errors with 11 bikes, but that error occurred on 12 bikes.

I also should note that, usually, the more different bike types I had, the sooner I got that Replay OOS Error. When 32 bikes raced, I usually got that Replay OOS Error between 1 and 2 minutes. But when there were about 12 bikes racing in that second grid, it took about 10 minutes before it occured.

Quote from Scawen :

Improved braking prediction so less running wide at corners
- considers brake balance (which is not ideal for every corner)

This seems to work great. For example, before AI drivers seemed to always screw up corners if brake balance was too low or high. I remember FXR screwing up a lot, because I hadn't noticed it brake balance was set to 5%, resulting it spinning on almost every corner

Now when I tested on AS2R, only once modded car screwed up at the first corner, and even that was because I deliberately changed it to 5% just before it approached that corner Although I must say when I adjusted brake balance on other modded cars to too low, they seemed to go a bit wide on some corners. However, they never went too wide (= onto the grass) and they never spun off.

My question is that since changing Live/F11 Settings apply (almost) immediately to a car, how long before AI driver starts braking should we change their brake balance? Or let's ask it this way: how quickly does AI-driver now react to any brake balance changes in F11-window, if not immediately? What is the safe window to do that change?

Quote :

- was possible for a powerful car to overspeed shifting 1st to 2nd

Distance to vehicle considered safe is reduced at low speed
- should prevent long vehicles hitting the brakes on green light

These work! FXR no longer stall on green light at FE6! It also seems to reduce possibility to stall after finishing pit stop, which may occasionally occur if you force car with turbocharged inline engine to make a stop.

I also want to confirm that the Replay OOS Error also happens in replays recorded in this patch. And I'm sure a certain bike mod causes it, because when I tested D43 with modded GTR-cars, I had no problems when I watched replay of it, but when I did a test race with bikes on this patch, same Replay OOS Error occurred when I did playback it.

Quote from Scawen :

But about the replay OOS error, please can you tell me which versions you recorded the replay? Is it that you are getting the OOS, even if the replay is recorded in D42? Or was the replay recorded in an earlier version?

I recorded it in D42. I could possibly try recording it in previous test patch, where AI drivers can drive bikes, but I can't test it on official patch, because it seems to only happen when several AI's are driving with bikes.

On D42, I also did playback D41 replays, where I had 25 bikes racing and had no OOS errors whatsoever.

Only thing I could think is that is there a possibility that a certain mod could cause this? Why I'm thinking this as a reason? Because on those replays where that OOS error occurs, there are lot more of different bikes racing. When I had 25 AI's racing on D41, there were only 5 different bike types total racing. When I had 32 AI's racing on D42, there were total of 27 different bikes.

Quote from Scawen :

I've had some success with this new braking calculation.

So here is a new question: Can anyone tell me an example where a particular car always runs wide on a particular corner?

Doesn't matter if it's a default car or a mod (though default cars are quicker to get to). One of the best ways to tell me which corner it is, if not easy to describe with words, is you go into free view mode and type "/cp". The camera position is pasted to your clipboard in a text format, so if you tell me the track and config and the /cp text I can get to the exact corner.

I remember fastest cars (GTR, FO8, BF1) having problems at South City Long and Town Course + Reverse with one particular corner. I'm talking about that corner close to chicane in Classic, it's that second to last corner when driving Town Course in normal direction. I've noticed that XR GTR especially seems like it can barely make that corner when using default-setups.

If I have to guess, since they are driving downhill, they have too much speed coming to that corner and sometimes get stuck to that wall when trying to make that corner (and if someone rams them from the behind, it just increases chance of that happening). Probably having wind from wrong direction and/or using soft tires makes it even easier to reproduce it.

Now this doesn't happen on every lap, but I remember GTR-cars basically having their race end there, with some of those having puncture on their front tyre.

But, in any case, it has resulted me doing this: if I want AI's to have endurance race with those cars, I basically have two options:

1) I let them race on one of those three tracks with no wind and pray they don't screw up or
2) I use SO4R as a track as there AI's don't have any problem, because they approach that corner with much less speed.

Last edited by tankslacno, Thu 5 Oct 2023, 16:22.

Scawen, thanks for this D42 test patch!

Once again, I decided to create a PDF-document where I report my experiences and issues with this test patch.

This PDF has 6 pages and I've divided it into five parts:
1) Two issues I suddenly found out, one of them is related to this test patch cycle.
2) My experiences of these fixes presented in this test patch in general
3) My testing with your other fixes Scawen
4) One thing I realized as well when I was able to reproduce that bug when using /setlap command
5) General information about attached files

I've attached four SPR-files. Now, there is also a fifth SPR and one RAC-file which I've uploaded into Google Drive alongside those five other files in a ZIP-folder since that first one is too big file to simply attach it here and the second one is not permitted file type.

So you can find that ZIP-folder here - the files not attached in this message are named "D42_AS5_TestRace_Bikes.spr" and "D42_BikeTesting.rac": https://drive.google.com/file/d/1aT3_SOa_x_kPcxLDsAZcXXRjyO1CaOVj/view?usp=sharing

This PDF-document includes:

- Replay OOS Error happening - this is almost certainly related to this test patch, because I haven't experienced OOS Error for years now and it always happens when I playback replays where lot of different bikes are racing
- 1 other bug found when viewing mods - bikes in general, not sure can this happen on other type of vehicles
- My experiences to each of your AI update in D42
- My experiences with updated AI in general with this newest test patch
- 1 bug when using certain bike on a certain track, not sure have I accidentally corrupted this
- My testing experience to your other fixes
- Other information related to that /setlap bug I found yesterday
- General information of each file I've attached

Quote from tankslacno :

I found reason why that happened to me and there is a bug.

When I tested it, my driver name was written in Japanese code page. As I typed that /setlap command (using Latin code page) and used that driver name, which was written in Japanese, in there, it restricted the character limit of that second parameter to 3. That's why I got an error "This command needs 2 parameters" when that second parameter had 4 or more characters.

When I switched to driver name "Tankslacno", it worked properly.

EDIT: It seems like it only happens, if you use special symbols shown in Japanese code page as your driver name. I've attached a screenshot of my driver name. If you create a driver name using those symbols, you should be able to reproduce this bug then.

Sorry for double posting but this doesn't seem to be a solution to this bug.

This same bug happens with every single driver name regardless of their code page, if last character of that name is having other color than default color. If last character is in default color, this /setlap command works properly (it doesn't matter are other characters having different color in that case).

Here's how to reproduce this:
1) Create a new driver name and while naming it, apply some other color to it (other than default) at least to the last character of that name.
2) Go to single player and set race length either in hours or 1000 laps
3) Open connection list and right click on your player name. This allows you to copy that name with those colors included
4) Type /setlap, paste that name with Ctrl+V and type lap parameter with 4-5 characters. You see that error "This command needs 2 parameters" on screen.

Weirdly, if you just type that name without using colors, you can use that /setlap command with no problems. But if your lap parameter contains at least 6 characters regardless of colors, you see that error happening. Reason why I encountered that problem initially was because it was written in Japanese and used white color so naturally I just copied it by right-clicking it on connection list.

If I had to guess why this is happening, is it because whenever you apply a color to a name, it does apply that color code (https://www.lfs.net/faq/39) which contains a number to it.

EDIT: Technically that is not the 100% solution, but it's close enough. You can still have that last character colored of your driver name even if you copy it with colors from the connection list. You just need to make sure that before you type that lap parameter, you change your text color to same one your last character of your driver's name has.

So if your last character of your driver name is in cyan and you want to copy it with colors when typing that /setlap command, you can still apply that command correctly, but before typing that lap parameter, you need to make sure that parameter is also written in cyan.

Last edited by tankslacno, Wed 4 Oct 2023, 15:41.

EDIT: This is incorrect solution, but I left that so you can still download that attachement

Quote from Scawen :

About the /setlap command, I can't reproduce this. I've started a time-based race (/hours 1) then I was able to use /setlap up to 6000 laps, which is the designed limit. I could use negative values also to -6000.

With /laps 1000 I was able to use commands like /setlap AI 3 1000 or /setlap AI 3 -1000.

My testing was in single player.

I found reason why that happened to me and there is a bug.

When I tested it, my driver name was written in Japanese code page. As I typed that /setlap command (using Latin code page) and used that driver name, which was written in Japanese, in there, it restricted the character limit of that second parameter to 3. That's why I got an error "This command needs 2 parameters" when that second parameter had 4 or more characters.

When I switched to driver name "Tankslacno", it worked properly.

EDIT: It seems like it only happens, if you use special symbols shown in Japanese code page as your driver name. I've attached a screenshot of my driver name. If you create a driver name using those symbols, you should be able to reproduce this bug then.

Last edited by tankslacno, Wed 4 Oct 2023, 15:33.

Two additional issues:

1) Related to this test patch:

Quote from Scawen :

Simple versions of F11/F12 displays are now available during an SPR

Just noticed another bug in this. And it's related to this test patch, because this test patch is first patch where we can see F11 / F12 windows in test drive mode. Basically, you can use most, if not all, commands in test drive mode.

Here's that bug: if you're test driving from a replay of a hot lap session and decide to type command /laps 1-1000 (or /hours 1-48) and you do that before you start your first timed lap, F12 window thinks there is a race going on (it states that race length is X laps), but there is not a lap counter (it never appears) and none of your timed laps counts towards your driven laps in that "race". In fact, it seems like none of your test drive laps will ever count.

However, if you do it after you've started your first timed lap, it does turn your test drive into a effective race session.

This bug only occurs on replays which were driven in hotlap mode. This does not occur in practice sessions (in those, using command does turn that test drive to a race regardless of where you type that command).

So, in order to reproduce this bug:
1) Start a hotlapping session and save SPR of it
2) Open that SPR and enter test drive mode
3) Type command /laps 1-1000 or /hours 1-48 before you start first timed lap on that test drive.
4) F12 window thinks this session is a race, but lap counter never appears and that race never ends.

2) Unrelated to this test patch, could be on purpose, but has potential issues

In theory, command /setlap has potential issues. And that is to do with the fact that the second parameter (lap amount) of that command cannot contain 4 or more characters. What does this mean? Well, it does bring up two potential issues:

Ones not so bad, that is you can "only" subtract up to 99 laps per command. Command /setlap [username] [-100] does not work, since that second parameter has more than 3 characters.

The second one is the one where this command can become an actual problem:

I know this doesn't happen that often, but if you're having an endurance race on a very short or oval track, where race length is in hours and it's clear that lap amount will exceed 1000, /setlap command becomes useless for player who reconnects after an unintended disconnection and has already driven over 1000 laps. Why? Because /setlap only works up to 999 if you're having a race where length is 1000 laps or it's a timed race. (If race length is less than 1000 laps, it works up to that race length.)

That is because technically that command does not add laps for user, it only sets the lap amount of that affected user to that.

And yes, I know it may sound nearly impossible to happen, but it actually isn't. Think about you're doing a 24 hour endurance race in a team on track/car combo where average length of a lap is about a minute. After 5 hours, you've already driven about 300 laps. If one team would manage to have that average page of 1 lap per minute for that whole race, /setlap would become useless for them after about 16 hours and 40 minutes of racing.

I was just wondering that since that number can already be negative which subtracts driven laps, could it be also possible to make + sign work on that parameter? For example /setlap [driver name] [+2] would add two more laps to driver's current lap amount. Or alternatively, could it be possible to make the maximum lap amount on that second parameter so high in timed races as well as qualifying and practice sessions that it couldn't be realistically achieved by simply racing?

In any case, it also may seem a bit confusing that LFS states an error that this command needs 2 parameters if your lap parameter is at least 1000 (or -100 or lower). It's a bit confusing because you already have typed two parameters to that command.

Quote from loopingz :

One formula got stuck in the sand did not reset. Bursted tires and ended fuel pretty stupidly. One other car got stuck did not reset did not ended fuel.

In case you don't know, it has always been like that. Even if you've allowed a car reset, AI drivers pretty much only reset if they know they can't move anywhere and situation allows resetting a car. This means that they only reset if they're flipped, taken a wrong route/out of bounds or, in case of vehicles with motorbike gearbox, they're stuck and can't move forward. Being stuck in a sand does not make AI driver reset their vehicle, unless you use Autocross objects to force them to a position where they will reset their car.

Same thing has happened at least previously if they've destroyed their clutch or stalled their engine. Not completely sure how they handle this kind of situation in a current test patch though.

Hi Scawen!

Thanks for this D41 test patch. I tested it quite a lot yesterday and I have a lot of reporting about this. Because I don't want to make this post very large, I decided to create a PDF-document where I report my experiences and issues with this test patch.

This PDF has 8 pages and I've divided it into four parts:
1) Important/Test patch related issues
2) Other caveats with AI drivers
3) Other caveats/bugs I found
4) Information about SPR-files I've attached as well

I've attached four SPR-files. Now, there is also a fifth SPR which I've uploaded into Google Drive since it's too big file to simply attach it here. I've also uploaded these five other files attached here also there.

So you can find a link for that fifth SPR-file here, it's named D41_TestRace_SO4_Bikes.spr: https://drive.google.com/drive/folders/11nZcHfuKQMeACy-p-FW8X9EVzqiTG9jL

This PDF-document includes:

- 1 game crash
- 1 bug related to D41 update
- My experiences to each of your AI update in D41
- My experiences with updated AI in general with this newest test patch
- 3 other caveats related to AI drivers I noticed (1 of those could be on purpose though)
- Way to sort of bypass a restriction that disallows certain cars in Karting Tracks (WE4/WE5)
- Some other strange things (possible bugs) with Training Lesson Editor
- 1 other bug I found when autosaving replays.
- General information of each SPR-file I've attached

Quote from UnknownMaster21 :

Because this has turned up to A.I. update, and ppl are looking test patches, is there someone who knows how to get 40 AI racers like in past back then? ( by saving the grid and with command use with /ai something, which also included of changing their names ).

That bug has been fixed years ago.

The only way you can have 40 AI's by yourself is to buy another licence for another account, create multiplayer server which allows at least 20 drivers per player and then fill the grid.

There is also an alternative method, but it's very outdated and bizarre and I'm not sure does it even work anymore. If you really want to have 40 AI's by using single licence and don't care about mods. You could try using 0.6V and setup a local game, because until 0.7A, you could use same licence for two players with LAN.

Quote from Scawen :

Yes, maybe this is the reason.

But I think that purpose can now be covered by other means, as F11 and F12 views in "remote car" mode (as seen in an MPR and other people's vehicle online) is sufficiently restricted.

As far as I can see, it only reveals tyre choice, fuel level and handicaps, but no real setup info.

So I think should be fine for hotlaps and SPR if it uses the view already designed for remote cars.

I'm just wondering, what about test drives? Could it be possible to make a condition, where LFS checks who was the creator of that SPR (whether is it hotlap or session with it AI's)? If it matches the current username in use in-game, then those F11/F12 windows would be enabled in test drive. Otherwise, they would be disabled.

In any case, I don't see any reason, why they've been disabled even when you're test driving from SPR of your own hotlap/single player session.

Quote from Scawen :

Can anyone think of a reason why I shouldn't enable an MPR-style view in F11/F12 when watching an SPR?

I have a theory why it could've been thought as a good idea years ago: could hotlaps have been a reason why those views have been disabled? By disabling them, if user downloaded a hotlap replay from LFSWorld, they could not get more data from setup that user has used? I'm thinking this as a reason because if you try to test drive from watching an SPR, you still can't view F11/F12 windows. And this restriction applies to all kind of single player sessions, whether they are single player races or hotlaps.

I don't see any other reason for that than this.

Quote from tankslacno :

1) Possible bug when renaming a replay:
If I try to rename a replay on LFS by simply changing a letter from lowercase to uppercase (or vice-versa), it doesn't allow me to do that. Instead it says that the "Name is already used".

I also want to state that this same situation happens when you try to rename a skin or a setup. It doesn't allow you to rename them in-game if you're merely changing a letter's case from one or more letters of that name.

Tested D40 and noticed several things. Some are related to this test patch and some are not:

Unrelated to this test patch, but found when viewing replays:

1) Possible bug when renaming a replay:

If I try to rename a replay on LFS by simply changing a letter from lowercase to uppercase (or vice-versa), it doesn't allow me to do that. Instead it says that the "Name is already used".

For example: I had this replay I've attached originally named "KY1_MotorBikeTest_Cannot_Reset" and I tried to rename it "KY1_MotorbikeTest_Cannot_Reset" where the only difference in that name is it's named "Motorbike" and not "MotorBike". However, since that was the only change, it didn't allow me to rename it until I renamed it first by adding/removing a character and then renaiming it again.

I understand you can't rename a replay to a same name that other replay already has, but it shouldn't do that when you're simply changing a character from lowercase to uppercase or vice-versa. Is this on purpose that you can't do this in-game but you can do this when renaming those files in File Explorer?

2) Question about F11/F12 window when trying to view a single player replay:

Is there any reason why I cannot view F11/F12 menu when viewing single player replays, but I can in multiplayer replays? Because of this, I can never take a refresher from a single player replay when I want to take a look at their tires, restriction or skill level.

Caveats about AI's:

3) Bug on Westhill National Reverse and International Reverse with AI:

It seems like it's completely luck whether they can successfully enter a pitlane in Westhill National Reverse and International Reverse or not. When they enter pitlane, they usually make a weird "snake move" and may spin off and in worst case, get stuck at the wrong side of the pitlane. This happens especially when AI's are driving faster cars.

- I've attached a WE2R-replay about this one: there are 20 PRO-level AI's, each one having different standard LFS car. Take a look what happens to BF1, FO8 and XRR when they try to enter a pit lane. Also take a look what happens to LX4 and MRT when they try to exit their pitbox and UFR is in front of them, since that is related to another caveat mentioned below.

This "entering a pitlane" bug doesn´t seem to happen on other tracks aside from these two.

4) Caveat related to this fix Scawen:

Quote from Scawen :

- FIX: Sometimes applied brakes and stopped on track next to another vehicle

This bug seems to be partially fixed. I'm saying partially since this fix doesn't seem to apply in pitlane and pit exit lane? Ever since 0.6K was released, AI's have become way too careful in pitlane due to this:

Quote :

Now avoid ramming other cars when in the pit lane or lap of honour

What this has resulted that if AI driver tries to enter or leave a pit box and another vehicle/object is stooped on that pit box or one immediately before or after, that AI will stop completely, because it's too scared to enter/leave that pit box. Same thing happens if another vehicle/object is stuck in pit lane.

I've attached a SPR named "KY1_FootballTest" about this: these 20 same AI's are again racing in Kyoto Ring. But this time, I'm also participating as a football. I'm deliberately in the pitlane to prove that AI's do get stuck, if something is blocking their path in the pitlane.

This is happening on every track that has pit boxes.

5) Problem with AI's using bikes:

This applies to all AI's that are driving vehicles which have motorbike gearbox (like MRT5 and motorbikes). If you have disallowed car reset and they are near an object or another vehicle, they will very soon shut their engine off, thinking they cannot get anywhere past it since they can't drive in reverse. If they can reset their cars, they will reset their car and try again. Other vehicles don't have this problem since they can always reverse and try again.

I've attached two replays about this, one where resetting a car is disallowed and another where it's allowed. You can see what happens to them when they face that football on pitlane.

This and the previous caveat on D40 seems to happen in pitlane and also on pit exit lane, but weirdly enough, not on pit entry lane. If they're on pit entry lane, AI's just ram that object/vehicle out of the way.

I'm saying this has been partially fixed because I tried this with 0.7D and there, AI's got stuck also on pit entry lane.

Quote from Pasci :

Then I noticed the AI with the stalled engine.

Perhaps it's something to fix/should not happen I think? And yes, LFS is an online simulator I know.

This is a common problem with cars that have turbocharged inline engine. They're most likely to do this when they're pushing the gas pedal during a pit stop.

Easiest, but not surefire, way to reproduce this bug is to use XR GTR and do this:
1) Make sure it's pit stop is going to last more than 10 seconds (you can change AI's pit instructions in F12-window to make this happen)

2) Before last sector of a lap begins, issue a Stop-and-Go penalty for it (by command /p_sg [AI DRIVER NAME]

3) When AI driver is driving the final sector of the lap, before it enters the pit lane area, remove that penalty by command /p_clear [AI DRIVER NAME]

4) When AI driver is making a pit stop, after 10 seconds it starts pressing a gas pedal, because it wants to leave that pit stop, thinking it has completed it's "Stop-and-Go" penalty

5) I think this is more related to setup, but especially with XR GTR, there is a decent chance it will stall it engine after that stop is completed.

Quote :

Other question: Why the heck is the AI jerking left/right all the time?! (not only the one that stall the engine)

I'm not sure why this happens, but if you refer to the situation in the pit lane, a partial reason for this is due to an update presented in 0.6K, which resulted AI drivers being too scared in the pit lane:

Quote :

Now avoid ramming other cars when in the pit lane or lap of honour

Before that update, AI drivers were brave enough to even ram each other in the pit lane (this resulted AI drivers ramming behind other drivers in the pit lane), but because of this update, if they're too near each other in the pit lane, they're too scared to move forward.

Quote from PerShing16 :

Thanks!

1st option is already enabled, but when AI isn't flipped, they will not recover
2nd option have flaw, as it disables option to save replay after changing layout
3rd option is brilliant! Now i can revert car to pit, and set lap number that he had before recover!

Thank you!

Btw, is not so easy to find informations about /setlap in google, is there one place where all commands for lfs are located?

You can use the second option in multiplayer as you were talking about possibility of hosting server for AI only race. If you change layout in multiplayer, you can still save replays.

You can find commands here: https://www.lfs.net/host.htm

And by the way, there is a fourth way to reset AI driver which is useful in a situation, where it has wrong setup/car/etc. Spectate that AI-driver with command /spec [AI-driver name] and after selecting car, setup, skin etc. in garage, type command /ai or /ai [AI-driver name]. If you use that command with parameter, just make sure to include those colors used in that AI-driver's name (so if your AI-driver name is in white, you need to type that parameter for that command in white color)

If you don't specify AI-driver name in that command, LFS will add next AI driver found from your AI-driver list in game options.

EDIT: You can also find list of commands in your [LFS installation folder]\docs\Commands.txt

Last edited by tankslacno, Tue 18 Jan 2022, 21:10.