Cannot reproduce, but I notice that when I let the list load, click on a server and then exit LFS it takes an awfully long time to actually exit, leaving me staring at a black screen for several seconds.
This is exactly what happens when you average the view in a buffer as I described - it does NOT stay level with the horizon, but just "lags" behind the car's movement and smooths it out . If you start driving on a banked part of the road or up a steep hill, the view momentarily lags behind what the car does and then aligns itself with the car again. The "real life roll pitch insim" app already does this, you probably just didn't notice. Or you're talking about a different application that I don't know about (camlevel?).
Having this feature in LFS itself would be great. It makes you feel much more there when not 100% glued to the car. Suspension movements and track unevenness become much more apparent than the current view system could ever hope of achieving to show. I think this would be a very good addition coupled with the new tyre physics and/or Rockingham.
The funny thing is, at least through InSim the basic functionality is a dead simple thing to code as I've found when implementing my own version. All you do is instead of instantly applying the car's pitch/roll to the view, you average the values over the last X physics iterations (say a queue/buffer size of 20) and apply that instead, coupled with the automatic camera smoothing of InSim. Then add a proper over-/underflow handling (so the view doesn't go beserk when doing a barrel roll) and you're done. No need for actually simulating the driver's head in any way.
The only issue I can see for a proper implementation is what to do when the user presses the look buttons or uses TrackIR (= does not look into the same direction as the car is pointed), and for both occasions simply disabling the free-float or fading the effect out the farther you look away from where the car is pointing would work as a preliminary solution. The real solution would of course be a proper translation of the car vector to the look vector and all the calculations that go with that... I can see how a proper solution could be too much work for now.
Now personally I have no problem with just continuing to use InSim for that, but I think a lot of people miss out on this great little feature unless it's implemented in LFS itself.
But sorry for OT, this has really nothing to do with the test patch.
How do the pitstop points work? I assume the time for the extra points is accumulated over however many pitstops you make? So if you make two pitstops, the first taking 4 seconds, the second 7, you would get 4+7=11 => 4 points?
Is the pitstop time measured via InSim? What points do you get if you take exactly 10 seconds (3 or 4)?
When Scawen implemented the new multimonitor support, he also made it so that external views (Shift-U, etc.) only display stuff on the "middle" monitor. Apparently there are people who do want the whole screen width to be used and this option controls whether the view in external modes is limited or not.
Does it? Don't get me wrong, I never used SoftTH, but I always thought what it does is fake a display device that has a wider screen resolution. Then again, maybe for splitting the data it actually does create multiple D3D devices, sending a third of the output to each device.
No, because all the viewports are still "connected" and the maximum monitor angle is whatever you set your main screen fov to, which is in multi-monitor mode limited to 90°. So you would need three screens to allow a look-behind.
Technically possible? Yes. With the current GFX engine? Not quite.
Currently the engine relies on having one path through the track that it uses for visibility calculations, determining which parts of the track need to be drawn and which not. Of course, you could simply draw the whole track at all times, but the performance would be abysmal, or Scawen could work out a system that allows such free-roaming by making the visibility calculations work differently, but that would be a huge time investment for something that's just a by-product of the simulation to begin with.
PS: aroX, feel free to shut the hell up from time to time. Not even bad threads deserve your mindless spam.
That's because a cat is not your personal playtoy that lets itself be commanded around
But seriously, I think cat/dog preference depends very much ones personality. Calmer, passive people will tend to prefer cats, whereas active or more outsidey types (or people living in a house as opposed to an apartment) will have more fun with dogs that they can chase around and play with. Dogs are also far 'easier' to learn, as their language is much more direct and obvious. Being a pack animal they're instinctively used to having a leader and following orders, so you can get much more actively involved with them.
A cat won't give a shit about you throwing stuff in its general direction expecting it to fetch it or if you call it to come over (other than feeding time) unless they feel like it. Unless you grow up or spend lots of time with a cat you probably won't learn the much subtler cat language at all and will forever wonder why you approaching it like a dog will be met with nothing but disinterest. This is in my opinion also why dog owners are often frustrated with cats since their way of approach seldom yields a positive response, giving them the impression that cats are evil or dumb.
That said, if you ever need it, there is a remote control for cats. It's called a laser pointer.
That is because increasing minimum sleep limits the framerate. If you "do nothing" for 10ms each frame then the maximum achievable framerate would be 100. In combination with actual physics calculations and rendering, setting it to ~8ms will already suffice to limit the fps to < 100, and as we all know the bug only happens when the fps is > 100.
The whole point of minimum sleep is btw really to do nothing. This means that LFS doesn't use 100% CPU and other programs can catch up with whatever they need to do. I think it was first introduced when on some systems even the window message queue was blocked due to LFS using up all CPU and wheel / HID inputs were delayed or something similar.
Maybe they think they'll find a secretly uploaded S3 beta that way
The dirt indicator affects all three pads of the current tyre section (because there's only one contact point on the tyre and thus not enough information as to which pads were on the dirt), but each of the 16 tyre sections has an own dirt indicator.
I can see how this is not easy to recognise, since it rarely happens that you pick up dirt with less than a whole tyre circumference, but as ussbeethoven pointed out, you can scrub off the dirt of a few tyre sections by locking up your tyres. After you slowly start rolling again, you will see the dirt indicator jump up and down depending on which section is shown.
While being a repost, this is an extremely funny game. The contrast between the hero-of-the-nation music and the sheer ineptitude of the dude falling over in the most ridiculous way possible makes me giggle just thinking about it
I can hardly imagine that making much of a difference, really. I don't think it's even possible to do that if the tyre model stays relatively similar to the current one - having only one actual contact point on the road. I believe right now the tyre doesn't even collect dirt unless you're on the dirt with the middle tyre section (> 50% of the tyre width is on dirt), and by that point you really might as well have the dirt act over the whole tyre width.
That said, you do know that the dirt indicator only affects the whole tyre width, not the whole tyre circumference, do you?
An auto-generated top-down layout view of how the monitors are supposed to be set up according to the current view settings sounds like a great idea! This would very intuitively explain what the setting does, especially if it changes in real-time as you change the settings.
I wouldn't worry too much about help buttons not being 100% effective - no matter how many instructions you write or how big, red and bold you make warning texts, there will always be people who ignore it.
The only way I can think of to further minimize questions is an automatic tooltip-like popup (not necessarily positioned at the mouse cursor). If the very act of trying to change an option by moving the mouse cursor over it already results in a big visual change on the screen grabbing the user's attention (the text popping up somewhere), then you might have a chance of the user reading it.