Yeah, that would be really cool. I already tried to implement that before, but actually, alpha is 1 bit only, so a pixel could only be matt or shiny, and setting an alpha value other than 1 resulted in black dithered dots on the skin, so not really usable for skin creation. And online shaders were only shiny, since JPEG files don't have an alpha channel.
Yeah I know that, I'm saying that skins in LFS are using alpha with dithering, and even when I save the skin in DXT5 and make a gradient of alpha, it ends up with dithered black dot everywhere. I'll try edit this post and upload a screenshot of it today.
Any chance that you have an improvement of physicsClock(100Hz) to screenClock(typical 60Hz) micro stutter issue in mind?
I know that many don't see the micro stutter as a problem, in fact some claim they don't have it which cannot be true unless they of cause run 20,25,50 or 100Hz on there display, but for me after I found a way to clock my main monitor down to 50Hz and seen the smoothness of constant image change frequency, it hurt my eyes looking at the jitter composed by the 100Hz to (60Hz or 75Hz) "latest frame" sampling which LFS currently does. And I would bet many would see it as a very big improvement on immersion, if this issue was addressed somehow someday.
Actually this issue is why I have not dared to buy a VR headset yet because I would intent to use it almost exclusively with LFS but afraid that the 100Hz to 90Hz jitter would ruin my experiences because I know it could be more smooth. And eyes are very sensitive to jitter when image is scrolling, the brain know it is fake and not a real world image.
This actually stimulate your balance centre the wrong way compared to real world image, which the balance centre use among other things to keep track of your balance and avoid you becoming dizzy. Of cause maybe the micro stutter is not making anyone dizzy and pop but it sure is noticeable when compared to none stutter and much more important for immersion than getting the lighting of the scene or the 3D models more photo realistic or even getting the tire physics(almost back on topic :-) ) more realistic than it already is.
The funny thing is that implementing an interpolation between physics and graphics each thread running on separate CPU core would actually yield more headroom for both physics and graphics improvement and solve micro stutter at the same time. Of cause this is easier said than done on a SW architecture I would guess was developed before multi core CPUs became mainstream.
PS: nice bikes..same story here, quit smoking and began bicycling 5-6years ago :-D only road biking though.
...To prevent causing earlier issues about updating Westhill track, I hope that this does not effect on map area borders as several LFS'ers have created their layouts maxed out to the very border of play area, so if upcoming update will take an effort to optimization to scale area, I suggest to make alternative way. However, because everyone are developing to make some kind of things bigger on their own product, I do assume LFS will be no exception at all.
However, all of sudden I got worry about by thinking and remembering. Not because the update itself or I do not have anything else to do than creating layouts and using them ( involves other guys too, not speaking only myself ), but more like keeping the insane inner flexibility, which is indeed strong factor on LFS.
Also, I do keep it always on my mind that things may change while going forwards. LFS is still on alpha stage and even if being full product, things would still change. This seems to be happening on elsewhere as well, including real life too.
Please take this only as reminder, regardless of need or not. Anyway, I am sure the updates and fixes on mentioned track areas will be most likely excellent work for sure.
But yeah, this does not of course involve the new content which might come in some point. I did re-check again the discuss in test patch section. I see the reason why this happens is that indeed update pace is slow ( not everybody things it is too slow, though ), so messing around and finding some cool things like did happen on Westhill and already on new Blackwood as well is a joy.
But I am prepared. At least some of my layouts might not work anymore in some point, but that is not big deal. This will take an effort on physics update itself, not only track updates.
But of course! Sandbox area with absolutely nothing included would fix this.
Now, we wait! ( Yes, we know that. )
( Duh... I went straight to off-topic, like jumping on the gun, oh well. )
Actually, I also prefer disabling V-sync and cap LFS at 100Hz but if you do that on a 60Hz monitor, you will have screen tear randomly (like) all over the screen. Changing the monitor update to 50Hz will keep the screen tear steady in the picture and imo not so noticeable and annoying. And at 60Hz, part of the screen will still have the judder(constant micro stutter) where at 50Hz it will be smooth as butter only eye hurting at the screen tear lines.
When that is said, running with V-sync when monitor is at 50Hz is also very nice. As long as the general frames are steady. I usually set LFS priority to "runtime" in task manager and remove all speed step and power saving options in BIOS to keep CPU clock steady, this almost eliminate the remaining V-sync related stutter when running 50Hz, but also helps even if you run v-sync with 60Hz monitor.
IPS-type panels are much less prone to that sort of colour distortion. I haven't owned any other type of LCD since my FW900 died. The primary advantage of TN is its speed (primarily colour-change response time, but also input lag and refresh rate support) over IPS, but that advantage is significantly narrowed these days.
Now you can get a really fast IPS-type panel that runs at 100Hz or more, even at resolutions as high as 3440 x 1440.