Ok, the important thing to understand is that the graphics update and new tyre physics are supposed to be released together in one update.

The main reason for this is that graphical update is happening in the development branch, and that branch contains all changes in tyre physics. It would be a lot of work to for Scawen to release graphical updates and physics changes separately, it's just easier to simply finish up the new physics and release them together.
Apart from that, even if it was possible to do, then all online stats and hotlaps would need to be reset because the tracks would change with the tracks/graphics update, and then these would have to be reset yet again because of the change in tyre physics - that's the second reason why it doesn't make sense.

Quote from pajkul :

Ok, the important thing to understand is that the graphics update and new tyre physics are supposed to be released together in one update.

The main reason for this is that graphical update is happening in the development branch, and that branch contains all changes in tyre physics. It would be a lot of work to for Scawen to release graphical updates and physics changes separately, it's just easier to simply finish up the new physics and release them together.
Apart from that, even if it was possible to do, then all online stats and hotlaps would need to be reset because the tracks would change with the tracks/graphics update, and then these would have to be reset yet again because of the change in tyre physics - that's the second reason why it doesn't make sense.

Pretty sure the new tyre won't just be "release and be done with it" kind of thing. It'll probably be further tested by the community, bugs/exploits/behaviors fixed & updated over a period of months and months. And with every update, charts will be reset. So I don't see the point in holding back this amazing graphics/tracks update that takes LFS from 2006 look and moves it 10 years forward. But of course, the cockpits would have to be upgraded as well, in the same update or the one following, because they are currently at PS1 level, though that's probably somewhat easier to do.

For example right now tyre heating/cooling behavior is totally wrong in LFS. A tyre will never stay that long at 190c (or cool down that slowly) while just sitting. As soon as you stop turning or unload that tyre, it'll go down to 100 or so very quickly depending on air/track/brakes temperature. Or that the tyre at thinnest thread won't give you the best laps. The only reason these issues are not fixed is because of the premise of new tyre physics. If this was the primary tyre model, those kind of fixes would be applied and all hotlaps would have to be deleted again each time. So I doubt Scawen cares about not deleting hotlaps anyway, nor should he.

Quote from nexttime :

Pretty sure the new tyre won't just be "release and be done with it" kind of thing. It'll probably be further tested by the community, bugs/exploits/behaviors fixed & updated over a period of months and months. And with every update, charts will be reset. So I don't see the point in holding back this amazing graphics/tracks update that takes LFS from 2006 look and moves it 10 years forward. But of course, the cockpits would have to be upgraded as well, in the same update or the one following, because they are currently at PS1 level, though that's probably somewhat easier to do.

For example right now tyre heating/cooling behavior is totally wrong in LFS. A tyre will never stay that long at 190c (or cool down that slowly) while just sitting. As soon as you stop turning or unload that tyre, it'll go down to 100 or so very quickly depending on air/track/brakes temperature. Or that the tyre at thinnest thread won't give you the best laps. The only reason these issues are not fixed is because of the premise of new tyre physics. If this was the primary tyre model, those kind of fixes would be applied and all hotlaps would have to be deleted again each time. So I doubt Scawen cares about not deleting hotlaps anyway, nor should he.

In other sims physics updates happen quite often so yeah, the charts will most likely get reset from time to time as you say. It's just that it's going to be released to the public as soon as Scawen concludes the forces generated and temps charts etc. more or less match the real thing and there are no glitches in some more complex scenarios that would spoil the fun. But obviously after it gets released we will going to see some fixes (but I assume it will obviously be released as a test patch first, so that phase itself might take a few months, because people will make various tests and will be trying to find flaws in it for sure).

The thing is that it's much easier to get both things done and release them together than just extract only the graphical/track changes and apply them to the public version we're using now, these are my thoughts and it's based on what Scawen has said before, so it's completely understandable.

Regarding interiors, please, we don't need any more delays right now really. I can even play with Game Boy Colour car interiors, we just need to allow for that first big step forward to happen, don't even suggest it's necessary unless it doesn't require a lot of effort on Scawen's part, because it's probably what Eric can work on when Scawen is busy with tyre physics again, but yeah there are most likely some additional changes to the game engine to improve interiors to the modern level, so I'd rather have it done after the big update...

and to be more realist, when the graphical update and the tire physics will be released (as a test patch(es) obviously), the next challenge after releasing the whole thing (indeed there will be some glitches I suppose) for Eric will be to release the two other tracks for S3 content ... so, interiors ...

Make a list of hosts that was visited previosly... quite annoying to look for server if there is no player in it so you have to refresh all servers and look for specific one in the list (because I filter empty servers)... there is some space in "Join specific host" page at the right or at the bottom.... I guess no need to show what car or track just name for fast host swap

didnt read all posts above so sorry if that was mentioned.

About GTR and rally thing is great idea I would like to see AWD XFR with rally tyres (tried it with tweak years ago was real fun felt like WRC car just need more suspension travel, we have xfr ralling on main menu ) but I think that last time when was introduces 45 deg steering on XRG XRT it gave some advantage to the cars for race and hot lap times.
So my suggestion is to introduce buttons RACE/DRIFT modes and Server host can set what modes it allows.
For RACE mode we have what we have now. And wr times could be set just with race mode.

And with one press of button you go into DRIFT/RALLY mode that gives options to set higher steering angles and rally/street tyres.

Test Patch U14 is now available.

I've been working on things to improve the prediction but they are mainly incompatible, so not included in this test patch.
This patch contains some compatible updates while I continue trying to improve the prediction system.

Changes from 0.6U13 to 0.6U14:

Multiplayer:

Command /showfuel (no/yes) allows remote car fuel load to be seen
Most admin commands with parameter omitted report current value
FIX: Car on pit speed limiter sent maximum packets per second
FIX: Remote car's tyre temperature over 200 appeared black (cold)
FIX: Remote tyre temperatures increased too slowly in skid or spin

MPR debug commands:

/mprlag X simulates online packet delay of X ms (+ no smoothing)
/mprsmooth X (0 or 1) to disable or enable input smoothing

CPU usage display:

In Graphics or Misc options (in-game) click the car icon then 'P'
You can now see CPU usage for Physics, Draw, Prediction, etc.
The "Pred" line shows CPU usage for prediction of remote cars
Prediction time also shows up in an MPR if /mprlag is set

Support for live multiplayer replays:

Replay identified as live when starting to watch an unfinished MPR
Does not exit replay after fast forwarding to current time
Catch up to live position by clicking >| button
Skins can be downloaded while watching a live replay
Save replay while temp_mpr is being viewed - copy instead of rename
Start new mpr while temp_mpr is in use - tries temp_mpr_1 (up to 9)
/mprflush X to flush mpr to file every X seconds (0 = disable)

VR:

Virtual keyboard is shown at dialog height if no dialog is visible
Space bar VR click auto disabled when you type with real keyboard

Misc:

Increased distance for car subobjects to become invisible
FIX: Free view roll is now reported in InSim IS_CPP packet

https://www.lfs.net/forum/thread/93185

Your CPU is probbaly not strong enough to simulate 21 AI.

Quote from Pasci :

Under certain circumstances, the outsourcing of AI drivers to the dedicated host would be a better solution than increasing the permitted number on the client side? It would be good if you could determine the "field size" and as soon as a real driver connects, the number of AIs is "dynamically" reduced (or increased if someone disconnects from the host).

AI on server would be good but our current DCon can't possibly do that, as it only has a very cut-down version of the tracks, not including the physical surfaces. It doesn't need them because it doesn't run physics. It is already possible with a full version of LFS running as the server but that requires a user name. A full version can run in 'dedicated' mode but currently runs in the same way as DCon. I think that option could be made to run physics but it's really beyond the scope of this minor update.

I only started this process to allow a wider range of settings. It's turned into a multiplayer prediction + various other things but I still want to get this done ASAP because there is a lot still to do in the development version.

Quote from THE WIZARD DK :

1. could this have had impact on the shifting thing?
2. i am using space bar with keyboard. will that be customizable?
or SPACE only?


also. i tried to go in single player mode.
with 21 cars (all types) and myself on track i still get those lagspike things at some times.
you asked me if i got that recently. it seems i do. patch u13. what can cause this then?

No, the packet sending rate due to speed limiter was only related to packets.

The space bar for VR click is not customisable and I don't have any plans to do so. This code was designed so that space bar when typing no longer interferes with VR click, for people with a VR headset.

I don't know why you have lags but I don't think it's related to this test patch. If it is to do with graphics card limitations (memory swapping) you could try lower texture resolution. Otherwise lags could be caused by other programs running on your computer.

Quote from THE WIZARD DK :

(it still will pop up if you are using forexample lfs strobe)(Patch U14)

It has been quite a few years now since I coded a special system to operate the lights in such a way that doesn't need simulated key presses. Sending 'lights on' and 'lights off' keypresses followed by the delete key just in case the user might be in a text dialog box was a useful solution at some past time but is really quite a dodgy hack and that's why I coded a proper system for external programs to switch lights. There is a 'proper' way to do it now.

Quote from TFalke55 :

Thinking of that aspect: Would it be possible then that the "live mpr" is on some server that streams it to clients that are connected to that server and watch the race as a spectator without having to connect to the servers?

That should be possible now. A server program needs to read the live MPR and broadcast it to a client program which keeps adding whatever arrives from the server. LFS on the clients would simply watch the live MPR. It would only be a small amount of data to transmit.

I remember someone doing this a really long time ago. I think it was called "LFS TV" - it actually worked but there were certain issues which weren't resolved until now.

Quote from THE WIZARD DK :

Intel I7 2.93Ghz 8GB Ram. 64bit, Nvidia Geforce GTX 1660 TI. and i am on a fiber optic internet connection.

if thats potato. then youre right...

i dont have graphic card issues at all. dont let gust get that thought into you.
LFS is the only game that does this. so pretty sure its a LFS thing not my card or CPU.

Never a good idea to mod your game in any kind then report any bugs/issues. AFAIK LFS don't have any Pontiac or such sky and whatever else you've modded that isn't possible to see from a SS. Try with clean install of LFS.

Quote from pajkul :

The thing is that it's much easier to get both things done and release them together than just extract only the graphical/track changes and apply them to the public version we're using now, these are my thoughts and it's based on what Scawen has said before, so it's completely understandable.

I don't know how it works with coding and which approach would be easier, but one thing I know is we'd probably wait for several months maybe even a year more for the tyres while graphics are already ready and that's where I don't see the point. And I'd personally like tracks/graphics update first, testing it with the old tyres, then the new tyres. That way 2 big updates would be seperated, and we'd better see the differences between the old tyre and new tyre. If all the tracks would change we'd only have Blackwood to feel what is actually different characteristically compared to the old one. Also in terms of laptimes, race strategies etc. Yeah you obviously don't need the same track but it'd be a better comparison that way.

Regarding the interiors, I doubt it'd take much time. Few cars are actually quite decent, but there are several which needs to be brought to todays standards. Like LX, UF, and several more. The two official cars need even less attention simply because they were done after a real design.

Quote from dekojester :

Scawen, I am curious if it would be simple to allow more connections to a server. 38 driver slots is just fine, but only having 47 total slots is a hindrance, especially for endurance racing.
...
I understand if it's not just a simple integer switch, but it would really help the endurance side of racing, and even those full grid weekly events would benefit from it, especially if trying to qualify > 38 cars

I've had a look into this now and unfortunately it is too hard for this patch. Some packets have reached their size limit because of limitations in the packet system. Not only between guests and hosts but also between hosts and master server.

I have some plans to overhaul the packet system to allow much larger packets but it's a big change and not something to be done in the old version.

Quote from Scawen :

Reservations:

It might be a bit unrealistic

keep everything realistic. do not listen to people who want it to become a game.

Quote from THE WIZARD DK :

Intel I7 2.93Ghz 8GB Ram. 64bit, Nvidia Geforce GTX 1660 TI. and i am on a fiber optic internet connection.

if thats potato. then youre right...

That isn't a very strong PC. If it's running at 2.9ghz base clock, that's going to probably be a 2xxx or 3xxx series i7 which is 8 or 9 years old. 8 GB of RAM is also very little if you're running a plethora of background applications. The "lag spike" that you indicate could be memory needing to be swapped to/from disk causing an interrupt.

Your GPU is the most modern part of your machine, but the rest sounds very very old. I struggled with a full grid of AI on my i7-4770 because the CPU load was too high, but that's also a 7 year old CPU.

Quote from Scawen :

Drifters have asked for the maximum steering lock to be increased and to allow the full range of tyres, for the XRR and FZR cars. We received a request to allow up to 65 degrees steering angle but it seems a bit much to me. Those two cars have double wishbone suspension so that seems to put a limit on the amount a wheel could turn before part of the wheel hits part of a wishbone with disastrous results. I don't have any real world reference for what maximum lock is achievable by drifters in real life.


It might be a bit unrealistic, allowing such tyres on those cars. The big GTR cars are obviousy not designed for off road use, but if it allows more possibilities for drifting and racing, then it seems like a good thing to allow.

Steering lock being increased a lot, with wide front wheels on double wishbone suspension, might seem to defy reality a bit. But I'm interested to hear what you have to say.

I like the idea of making drift cars out of GTR, like the choice of road or sports tires, increase the Steering lock to at least 50 is already enough in my opinion. Although examples of real suspensions by wisefab show that more can be achieved. And GTR is since the weight, power, and even body elements are similar to how drift cars are involved in reality at Pro competitions, but this does not look like TBO or LRF class as it happens in LFS.

Therefore, it would be correct from the point of view of a motorsport simulator, which is LFS, and drift is recognized by the FIA as motorsport.

Quote from Aleksandr_124rus :

I like the idea of making drift cars out of GTR, like the choice of road or sports tires, increase the Steering lock to at least 50 is already enough in my opinion. Although examples of real suspensions by wisefab show that more can be achieved. And GTR is since the weight, power, and even body elements are similar to how drift cars are involved in reality at Pro competitions, but this does not look like TBO or LRF class as it happens in LFS.

Therefore, it would be correct from the point of view of a motorsport simulator, which is LFS, and drift is recognized by the FIA as motorsport.

I absolutely agree with Alexander. The more variety and possibilities LFS has, the better.

Quote from Scawen :

I've had a look into this now and unfortunately it is too hard for this patch. Some packets have reached their size limit because of limitations in the packet system. Not only between guests and hosts but also between hosts and master server.

I have some plans to overhaul the packet system to allow much larger packets but it's a big change and not something to be done in the old version.

Perfectly understandable, thanks for taking the time to look. The extra slots, whenever you can manage it, will be a boon to endurance races with driver swaps for starters, I'm maxing out connections right now in our events with a full 38 car grid + 2 course cars + a full control + broadcast team. We make it work, but for endurance races, we reduce grid size back to 30 to leave headroom for swaps.

Quote from Aleksandr_124rus :

I like the idea of making drift cars out of GTR, like the choice of road or sports tires, increase the Steering lock to at least 50 is already enough in my opinion. Although examples of real suspensions by wisefab show that more can be achieved. And GTR is since the weight, power, and even body elements are similar to how drift cars are involved in reality at Pro competitions, but this does not look like TBO or LRF class as it happens in LFS.

Therefore, it would be correct from the point of view of a motorsport simulator, which is LFS, and drift is recognized by the FIA as motorsport.

+1

A while ago, skin sizes were changed:
Maximum upload resolution is now 2048x2048.
I think the plan was that 1024 would become standard and 2048 would be premium.
That should be possible as compatible update?

Quote from Scawen :

AI on server would be good but our current DCon can't possibly do that, as it only has a very cut-down version of the tracks, not including the physical surfaces. It doesn't need them because it doesn't run physics. It is already possible with a full version of LFS running as the server but that requires a user name. A full version can run in 'dedicated' mode but currently runs in the same way as DCon. I think that option could be made to run physics but it's really beyond the scope of this minor update.

I only started this process to allow a wider range of settings. It's turned into a multiplayer prediction + various other things but I still want to get this done ASAP because there is a lot still to do in the development version.

Oh! Of course - Thanks for your feedback/answer

Quote from Gutholz :

A while ago, skin sizes were changed:
Maximum upload resolution is now 2048x2048.
I think the plan was that 1024 would become standard and 2048 would be premium.
That should be possible as compatible update?

I agree this should be possible in a compatible update, but it's not so simple as changing a number 512 to 1024 and 1024 to 2048. On the skins downloads server it is guaranteed that there is a 512 and 1024 of every skin, but it's not guaranteed that there is a 2048. So there would have to be a system like "try to get the 2048 premium skin but if the server replies that it does not exist then try to get the 1024 skin". So there is additional complication that I could do without. Another possibility would be to upsize all 1024 skins to 2048 if they don't exist already, but this is a bit questionable regarding quality.

There would also be changes in the directories, I guess a new skins_z folder. There would be a few changes through the program but I don't feel keen to tackle this at the moment because there are so many important things to do. It's even more to copy from the public version back into the development version.

I think if the 512 skins don't look very good, maybe it's a good idea for people to pay the small amount to get the premium skins. I think it's fair enough for people to pay a few pounds each year to contribute to the servers. It seems quite reasonable to pay £1 for 2000 skin downloads. But I realise that doesn't fix it for people who want to see the 2048 skins.

Personally, I do not mind the idea of upscaling 1024 skins to 2048, if the price stayed the same.

Would LFS even need to know whether it was 1024 or 2048? Couldn't the web server just pick the highest resolution available of the two?

No, the different size skins go in different folders. It has to be done accurately and predictably. The web server counts the high res skins (because they are chargeable). I suppose going with your suggestion, the web server could avoid decreasing the counter if it delivered a smaller skin than requested. LFS could receive the skin, see what size it is and store it in the relevant folder. But that download might be pointless because LFS already had the 1024 skin - so every time it tries to get the same 2048, it would be sent the 1024 *again*. This is all complication I am trying to do without. My head is already spinning with all the other stuff and I haven't even finished the prediction improvements yet. I can't see how I'll ever get back to the development version if I try to do absolutely every request. I'm already doing dozens more than was ever intended. I'm sticking more with bugs and serious issues at this point. I don't want to start taking on additional complications.