Bug when assigning commands to a player, whose name contains "/" character
Hi,
LFS 0.7E brought a new update called:
While this is definitely useful, it has brought one unintended bug. If your driver's name has a character "/" or "\" in it, you can't use any commands where you can set [driver's name] as a parameter.
So, if your AI-driver has a name "LFS / ai-driver" (doesn't matter if there is a space between or not), and decide to use command "/ai LFS / ai-driver", LFS thinks you're first putting command "/ai LFS" and then another command "/ ai-driver". What this results is you get two error lines, first being "Parameter is not valid" and second being "Unknown command".
Similar thing happens, if your own driver name has that character. So if your driver's name is, let's say "Driver /Tankslacno" and try to put a Stop-Go penalty for yourself by typing command "/p_sg driver /tankslacno" you get those same two errors. If that name starts with /, and try to set that command, you get "Unknown command" twice.
Weirdly though, this works normally when I tried to set commands in LFS.net hosts activity-window. There I haven't had any problems!
To reproduce this, you can do this.
1) Set driver name either to yourself or AI-driver that has character "/" or "\" in it.
2) Put that on race
3) Assign any command on that driver, where you can set [driver's name] as a parameter. You should see that your command will not go through, because LFS thinks you set two commands in a single line.
LFS 0.7E brought a new update called:
While this is definitely useful, it has brought one unintended bug. If your driver's name has a character "/" or "\" in it, you can't use any commands where you can set [driver's name] as a parameter.
So, if your AI-driver has a name "LFS / ai-driver" (doesn't matter if there is a space between or not), and decide to use command "/ai LFS / ai-driver", LFS thinks you're first putting command "/ai LFS" and then another command "/ ai-driver". What this results is you get two error lines, first being "Parameter is not valid" and second being "Unknown command".
Similar thing happens, if your own driver name has that character. So if your driver's name is, let's say "Driver /Tankslacno" and try to put a Stop-Go penalty for yourself by typing command "/p_sg driver /tankslacno" you get those same two errors. If that name starts with /, and try to set that command, you get "Unknown command" twice.
Weirdly though, this works normally when I tried to set commands in LFS.net hosts activity-window. There I haven't had any problems!
To reproduce this, you can do this.
1) Set driver name either to yourself or AI-driver that has character "/" or "\" in it.
2) Put that on race
3) Assign any command on that driver, where you can set [driver's name] as a parameter. You should see that your command will not go through, because LFS thinks you set two commands in a single line.
Last edited by tankslacno, .
AI get stuck when exiting final pit stop boxes on Blackwood RallyCross Reverse
If you're having an AI-driver driving on Blackwood RallyCross Reverse (BL3R), they will face issues when leaving last or second (and maybe even third) last pit stop box at the pitlane. Issue is that they can't exit that pitlane after making that pit stop from those pit stop boxes! Instead they drive straight to that solid barrier in front of them and get stuck there.
It doesn't matter what cars they are using. This happens on all type of cars; cars which already did have that AI path generated, other standard LFS cars and modded LFS cars!
Even if AI is exiting third to last pit stop box, it may get stuck. There is a possibility it crashes to that barrier at pit exit, but can reverse and then exit that pitlane.
This doesn't happen at all if AI's are just leaving pit lane. So if you start qualifying, this won't happen.
If you want to reproduce this bug, best way to test is this:
1) Add 4 AI drivers, doesn't matter what cars they're using
2) Set race length to 2 laps and enable mandatory pit stop
3) They make that pit stop on lap 1. Then you can see that 2 or 3 of them get stuck when trying to exit the pit lane area!
I've attached a SPR about this where 4 AIs are driving standard RallyCross-cars. I haven't seen this kind of bug with AIs on other tracks.
It doesn't matter what cars they are using. This happens on all type of cars; cars which already did have that AI path generated, other standard LFS cars and modded LFS cars!
Even if AI is exiting third to last pit stop box, it may get stuck. There is a possibility it crashes to that barrier at pit exit, but can reverse and then exit that pitlane.
This doesn't happen at all if AI's are just leaving pit lane. So if you start qualifying, this won't happen.
If you want to reproduce this bug, best way to test is this:
1) Add 4 AI drivers, doesn't matter what cars they're using
2) Set race length to 2 laps and enable mandatory pit stop
3) They make that pit stop on lap 1. Then you can see that 2 or 3 of them get stuck when trying to exit the pit lane area!
I've attached a SPR about this where 4 AIs are driving standard RallyCross-cars. I haven't seen this kind of bug with AIs on other tracks.
I will clarify one thing about schedule this event has. You may have seen and even participated in a lot of practice sessions on different league races in LFS. However, separate Warm-Up session has been used very rarely. Here I am clarifying why we also have Warm-Up:
Question: What is the difference between Practice 2 and Warm-Up? Why we need additional practice session? Why it's called Warm-Up and not Practice 3?
Answer: There are three differences between these two:
1) Practice 2 lasts 60 minutes, Warm-Up just 30 minutes
2) Warm-Up determines wind speed that will be used both in qualifying and race. Practice 2 wind does not determine that (even though it will also have wind)
3) And here's the main reason why this is called Warm-Up and not Practice 3: in a scenario, where there are two or more drivers on the grid who didn't set time in qualifying and we need to determine their start positions for the race. We will determine their start order by first taking a look, who was faster in Practice 2. If either or both of them did not participate in Practice 2, we will look their Practice 1 times. Warm-Up session (and by that, lap times set in that session) is not used as a tiebreaker at all, that's why it's called Warm-Up!
Reason why we have an additional 30-minute warm-up session is because it is possible some drivers (especially since this event is open for demo racers as well) are not familiar with windy conditions in LFS, so Warm-Up - where wind speed is similar to qualifying and race - gives drivers a session to get familiar with wind that could possibly be significantly different from Practice 2. Imagine if wind speed in Practice 2 is only 4km/h but in Warm-Up it's 24km/h! (Or vice-versa.)
Question: But in IndyCar, Warm-Up is between qualifying and race. Why in here it's before qualifying?
Answer: you are correct that it's between those two in IndyCar. There are two reasons why it's before qualifying here:
1) Warm-Up here determines wind speed also for qualifying, not only for race. This is because qualifying and race will be held on a same day. If qualifying and race would have been on different dates, then sure, Warm-Up would have been held between those two sessions on a race day.
2) With that, we don't need to go back to the lobby between qualifying and race (aka during race preparation). So we don't need to manually adjust the starting order in the lobby unless it's absolutely necessary. Instead we can use qualifying results which makes this job way simpler.
PS: And yes, you remember correctly, Warm-Up was also used in Formula 1, but it got scrapped just before 2003 season started, due to Parc fermé conditions being introduced then.
Question: What is the difference between Practice 2 and Warm-Up? Why we need additional practice session? Why it's called Warm-Up and not Practice 3?
Answer: There are three differences between these two:
1) Practice 2 lasts 60 minutes, Warm-Up just 30 minutes
2) Warm-Up determines wind speed that will be used both in qualifying and race. Practice 2 wind does not determine that (even though it will also have wind)
3) And here's the main reason why this is called Warm-Up and not Practice 3: in a scenario, where there are two or more drivers on the grid who didn't set time in qualifying and we need to determine their start positions for the race. We will determine their start order by first taking a look, who was faster in Practice 2. If either or both of them did not participate in Practice 2, we will look their Practice 1 times. Warm-Up session (and by that, lap times set in that session) is not used as a tiebreaker at all, that's why it's called Warm-Up!
Reason why we have an additional 30-minute warm-up session is because it is possible some drivers (especially since this event is open for demo racers as well) are not familiar with windy conditions in LFS, so Warm-Up - where wind speed is similar to qualifying and race - gives drivers a session to get familiar with wind that could possibly be significantly different from Practice 2. Imagine if wind speed in Practice 2 is only 4km/h but in Warm-Up it's 24km/h! (Or vice-versa.)
Question: But in IndyCar, Warm-Up is between qualifying and race. Why in here it's before qualifying?
Answer: you are correct that it's between those two in IndyCar. There are two reasons why it's before qualifying here:
1) Warm-Up here determines wind speed also for qualifying, not only for race. This is because qualifying and race will be held on a same day. If qualifying and race would have been on different dates, then sure, Warm-Up would have been held between those two sessions on a race day.
2) With that, we don't need to go back to the lobby between qualifying and race (aka during race preparation). So we don't need to manually adjust the starting order in the lobby unless it's absolutely necessary. Instead we can use qualifying results which makes this job way simpler.
PS: And yes, you remember correctly, Warm-Up was also used in Formula 1, but it got scrapped just before 2003 season started, due to Parc fermé conditions being introduced then.
If you, as a demo user, get both a pole position and a win in this race, then yes
Win a free licence upgrade: The Blackwood Licence Upgrade Race
To celebrate Sport Racing Team Finland's return in organizing races in LFS for first time really in almost 5 years, we will organize a Single Event called: The Blackwood Licence Upgrade Race (BLUR). This event, which will be driven on that classic demo combo, is open to everyone!
In this race, any (non-S3 licenced) user can win a free licence upgrade!
Basic information:
When? January 19th, 2024 (Friday)
Where? Server is Sport Racing Team DEMO.
How to join? You can join in that server by clicking this link.
Track? Blackwood GP Track (BL1)
Car? Formula BMW FB02 (FBM)
Race length? 50 laps
Pit stops? 1 mandatory stop
Wind? Low wind (4-24km/h)
Schedule:
(All times are in Finnish time, UTC+2)
Practice 1: 15:45 - 17:00 (no wind)
Practice 2: 17:05 - 18:05 (with wind)
Warm Up: 18:10 - 18:40 (with wind, wind here determines wind being used in Qualifying and Race)
Qualifying: 18:45 - 19:45
Race Preparation: 19:45 - 20:00
Race: 20:00
Prize Structure:
In Qualifying:
Pole Position: £6 voucher
Best non-S3 licenced user: £6 voucher
In the Race:
1st Place: £12 voucher (free licence upgrade)
2nd Place: £6 voucher
3rd Place: £3 voucher
Best non-S3 licenced user: £12 voucher (free licence upgrade)
You can also stack these prizes! In other words, if you don't have an S3-licence and get a pole position, you have already won a £12 voucher (because you get £6 from pole position AND £6 from being a best non-S3 licenced user in qualifying) meaning you have already won a free licence upgrade!
So, if you are a non-S3 licenced user and you get a pole position and win this race, you will win a £36 voucher, meaning if you are a demo user, you win a free licence upgrade straight to S3!
And of course, this event is also open to S3-licenced users because they can still win those vouchers that they can use on this site. But because there are prizes for non-S3 licenced users as well, no matter what, at least one non-S3 licenced user wins a free licence upgrade! (And if a non-S3 licenced user gets a pole position, there is a possibility two different users win that free licence upgrade!)
Even though this event is open for everyone, remember that Rules of Clean Racing do apply! (https://en.lfsmanual.net/wiki/Rules_of_Clean_Racing)
Questions:
Question: During Warm Up, it's mentioned that wind used in that session determines the wind used in Qualifying and Race. What does that mean?
Answer: It means that if wind during Warm Up is 17km/h for example, wind in both Qualifying and Race will be 15-19km/h. We will restart those sessions as many times it's necessary (i.e. until the wind speed is correct one).
Because wind used here will be Low Wind, possible wind speeds being used are:
- 4-9km/h
- 10-14km/h
- 15-19km/h
- 20-24km/h
Question: Do I need to make sure anything else?
Answer: Yes, you need to make sure I can contact you privately here in LFS Forum in case you do win a prize. To do that, go to: https://www.lfs.net/account/settings and check "Allow people to send you messages on this website". With that, I can send you that Voucher code you can use here! In case I'm unable to contact you because of that, I will instead send those codes to the next placed user!
You also need to drive at least 80% of the race length and have that mandatory pit stop completed in order to be classified in the race. Because of that, mid-race joining is allowed for first 20% of the race, but after race leader starts lap 11, it will be disallowed.
Question: So I am a non-S3 licenced user, what licence upgrade possibilities I can have in this event?
Answer:
If you are a demo user and want to ensure you can get a...
...free upgrade to S1-licence, you need at least to:
1) Get a pole position in Qualifying OR
2) Be a best placed non-S3 licenced user in Race OR
3) Be a best placed non-S3 licenced user in Qualifying AND finish second in the race while non-S3 licenced user wins
...free upgrade straight to S2-licence, you need at least to:
1) Get a pole position in Qualifying AND be a best placed non-S3 licenced user in the race (position doesn't matter)
...free upgrade straight to S3-licence, you need to:
1) Get a pole position in Qualifying AND win that race
If you already have S1-licence and want to ensure you can get a...
...free upgrade to S2-licence, you need at least to:
1) Get a pole position in Qualifying OR
2) Be a best placed non-S3 licenced user in Race OR
3) Be a best placed non-S3 licenced user in Qualifying AND finish second in the race while a non-S3-licenced user wins
...free upgrade straight to S3-licence, you need at least to:
1) Get a pole position in Qualifying AND be a best placed non-S3 licenced user in the race (position doesn't matter)
If you already have S2-licence and want to ensure you can get a free upgrade to S3-licence, you need at least to:
1) Get a pole position in Qualifying OR
2) Be a best placed non-S3 licenced user in Race OR
3) Be a best placed non-S3 licenced user in Qualifying AND finish second in the race while a non-S3 licenced user wins
Question: After this event, what happens in this league subsection?
Answer: This is a one-off event. After this, Sport Racing Team Finland starts organizing races in its primary server, Sport Racing Team Finland, every Friday, Saturday and Sunday. (You can join that server by clicking this link.)
First public race there will be held on January 20, 2024!
Qualifying for that begins at 15:45 UTC+2 and lasts 4 hours. Race begins at 20:00 UTC+2!
Last edited by tankslacno, .
It was updated to 32 in LFS 0.6V:
https://www.lfs.net/patch-6v
At first, I'll need it for testing purposes. And I've occasionally hosted AI races online from 2014 to 2019 and again in 2021, so yeah, I'm considering that possibility as well.
My intentions are actually to have that number higher than 1. If necessary, I may adjust the amount, but in some situations it is essential for me to have that max cars per guest at 32.
And I bought that host with it having 79 slots.
Max cars per guest on LFS.net hosts is wrong
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.
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.
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:
Last edited by Scawen, .
Reason : fixed now, reduced quote
Possible to hide certain game messages when watching Single Player replays?
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:
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.
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:
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.
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:
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, .
Reason : Added fourth bug as well (bug #3)
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:
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:
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.
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:
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:
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:
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)?
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)?
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.
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.
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.
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?
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.
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.
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, .
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
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
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, .
EDIT: This is incorrect solution, but I left that so you can still download that attachement
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.
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, .
Two additional issues:
1) Related to this test patch:
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.
1) Related to this test patch:
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.
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.
FGED GREDG RDFGDR GSFDG