No, that's only the deleted WR laps.

However, not really sure why Lacko is keen to get the full list - wouldn't it be better for the LFS team to be working hard on more useful stuff like content and tyre physics?

Quote from Gutholz :

But at the bottom it is strange: Somehow the window refuses to fully stretch vertically, there is always some pixels gap.

This is when you've pushed the top of the window beyond the top of the screen, yes? It sounds like it's simply the annoying thing where Windows refuses to let you resize a window to make it wider or higher than the display. Linux doesn't do this, and I seem to recall that really old versions of Windows didn't either (Win98 perhaps). So yeah, this is exactly what the borderless mode will fix for you

I think I'm a little unusual in that I have the taskbar set to auto-hide, which sometimes doesn't play nicely with apps which don't expect that.

In games, I've only very rarely experienced it popping up. However, I think that you aren't talking about full-screen mode here (which I almost always use for gaming) but windowed mode, yes? I don't have much experience of that at all, and possibly none at all with windowed+borderless. My guess would be that it's not normal behaviour though

Quote from DANIEL-CRO :

I'd also suggest to use Spare byte in IS_PFL to report whether TC is currently turned on or off. Some other stuff can be packed up to that byte as well, like if lights are on, indicators, ...

As an insim-noob, that sounds good to me.

Something that struck me after my post: if we stick with the tweak that Scawen already coded (i.e. can't turn TC on after leaving pits) then I would worry that someone will just alter the setting in memory (LFSTweak-style) and switch TC back on anyway. Allowing insim to report the current TC setting might prevent that line of abuse...? (and thus render the TC change unnecessary)

Quote from Scawen :

many more important things to get done.

Quote from Scawen :

Well, you can still turn it off and on while driving, if it is enabled in the setup.

OOOOhhhh, hell, that didn't occur to me. OK, consider my objection cancelled! However the LFSTweak cheat may still be a concern to people who want no-TC competitions, if it's actually possible to hack the TC setting that way?

Last edited by Neilser, Sat 9 Jan 2016, 13:22.

Yeah, I read the original request but like Kid222 I thought that what was being sought was to allow insims to prevent it being enabled.

It's not a very big deal for me personally as I don't drive FZ5 or BF1 much, but being able to play with TC on/off during an outing has been useful to me in the past, learning throttle control...

Another way to make SETF_TC_ENABLE worthwhile might be to send a packet to the server if TC is enabled again? More work for you though :-/ [I'm not 100% sure I understand SETF_TC_ENABLE but it seems to be part of the flags that are sent by clients when they join (quick googling only helped a little) and thus if someone changes settings post-join then one or more of the flags is meaningless.]

Quote from Scawen :

If it is OFF in the car setup, you can not switch it on while driving.

Hmm, that feels wrong to me.

Quote from vitaly_m :

Autoclutch works with the specific speed which is say 0.25 seconds to travel from 0 to 1.
[...]


const float clutch_max_speed = 0.25 / 100;


It's fairly clear what you're trying to achieve here, but if you're gonna post actual code you should probably check over it first
In this case, you've miscalculated your clutch_max_speed constant (hint: it gets SMALLER if you reduce the time from say 0.25 seconds to 0.1, when it should get bigger...). The rest of it may or may not be OK

Quote from Flotch :

Hope it will not end like the roof option for LX and UF1000 : first it was giving a weight advantage (for the UF only) against a worse Cx ...

Really? I thought all real cabrios were heavier than the basic models because they need so much extra stiffening... It's all before my time in LFS :-)

Quote from sinbad :

It will be a good opportunity to fix all of these little loop-holes. I also think Button Clutch needs sorting (there should be no advantage over Auto Clutch).
I'd even go so far as to either limit cars to being RHD or LHD or ballast the cars so that the driver-side does not affect performance. (If you think it makes no difference, look at FernBay Club and Club Rev hotlap charts for XFG and UF1).

I have mixed feelings about fixing handbrake issues (mainly, why care?).

I agree that button clutch does seem like it needs fixing, though I admit I'm still a bit unclear about how it works etc (and why it makes a difference!... engine/clutch model needs a tweak? I'd have thought that making it equal to auto clutch ought to be trivial).

You've totally lost me on the RHD/LHD issue though: why on earth would you want to change that? It's entirely physically realistic for the driver position to matter...

Quote from SmokeyBanjo :

I could go back to 'J' but I couldn't access the multiplayer until id updated. So guessing id be stuck racing the AI.

Not great as I spend quite a bit of time racing a buddy of mine in a private server

Quote from Eclipsed :

Quote from Neilser :

Hmm, I had the impression that 0.6K was a compatible patch

No,it's not compatible online - you can put exe file from J version into LFS folder of K version and have no problems (of course there is no S3),but you cannot join K servers with J version.

Quote from Neilser :

Edit: SmokeyBanjo: you say you can't even access a private server via the multiplayer system using J? That seems even more surprising. Are you sure the private server wasn't using K?

OK, finally got around to doing some quick tests with J.
While running J, I can indeed see and use the multiplayer system - I simply have to hit "Cancel" when it offers me an update. It does only show me the J/H/earlier servers, as Eclipsed said above.
So, SmokeyBanjo, I reckon you can happily continue to run J and play against your friends as long as it's on a server running J or earlier

Aw, crap, that's a bummer :-/
No idea why the patch needs to be incompatible...

Edit: SmokeyBanjo: you say you can't even access a private server via the multiplayer system using J? That seems even more surprising. Are you sure the private server wasn't using K?

Quote from SmokeyBanjo :

The last LFS 0.6J update gave me the ability to turn on a lot of the detail and keep a playable frame rate. This update has put me back to where I was on 0.6H. I'll live with it for a few months and build a new system.

Thanks again everybody. I'm amazed I'm getting so much help on such a waste of time museum exhibit computer. It's awesome. I'm guessing its nostalgia more than anything. Lol

Hmm, I had the impression that 0.6K was a compatible patch (it certainly doesn't change any physics I'm aware of), so until you upgrade to S3 I believe there's no need for you to use it - just stick with J, no?

(Btw, you could tell your wife that the electricity bills on your P4 are so bad that a new machine will pay for itself in a year! )

Quote from Scawen :

It's simply that we don't want to add unrealistic things if possible.

Ah, cool, thanks for confirming.

Quote from cargame.nl :

My wish for quite some time already is to extend the color system to triple hex so you can assign any kind of color (input field).. For example grass-green so it blends in better and doesn't look so ugly. Also the 0.25 height/Z increments with LFS objects is sometimes too much. Being able to fine-tune would be nice.

Umm, if your attached pic was to say "e.g. I wish we could make these objects green" then yikes! Those rampy things look scary so probly best if they don't blend in (Haven't hit 'em yet but they look like they're designed to flip cars which slide badly off course, which is too damn easy at RO in a few places.)
If the pic was just related to the Z tuning, then I can breathe easily

Quote from michal 1279 :

As Dawedust says, it's because of licencing. Do you remember the last time you raced in opposite direction at Monza/Spa/MonteCarlo/etc.? Probably never as there was no game that offered it.

Yup, a few people have guessed (probably correctly) that it's a licencing thing.
Hopefully though Scavier will soon put this beyond doubt by saying something

As somebody already said, compare it to the price of eating out... And a decent wheel costs how much?

I reckon I've already had my 12 quid's worth and I haven't even driven all of the variants. (NB: I don't habitually burn money - I abandoned iracing cos it was much too expensive and limited...)

Well, speaking for myself, I've rarely been happier to part with 12 quid!
Christmas came a few days early

Woohoo!
Licence upgraded, downloading now...

(Am puzzled though that all customers weren't emailed to inform them of the new content. Any particular reason?)

Haven't come across NetWorx before, but a quick google suggests it has been known to mess up other games too...

Quote from Yisc[NL] :

It may not be related to your case, but do you have any bandwidth monitoring software on your pc?
We recently had someone on our servers, who couldn't see anyone on track, while all other people could.
In the end it turned out that he had bandwidth monitoring software installed, which caused this problem.
After switching it off, all was okay as it were before he installed it.

Quote from V A H I D :

Quote from Neilser :

Did you try disabling the network monitoring software you mentioned above, by the way?

Yessss!

Thank you for your experience and guide to me. You recommend to me that disable the network monitoring software.
I did it and The problem is completely fixed ! ! !

I'm delighted your problem is fixed! I can't claim any credit though - the idea was from Yisc... I simply noticed that you hadn't commented on whether or not it made a difference.

In fact it's kinda weird that monitoring software should have side-effects like this... What is the package you are using?

It's a long time since I had this kind of problem, but what you're experiencing isn't due to the ping time being a little bit high, it's down to packet loss (or at least very high delays, like seconds).

280 ms isn't great, but it won't stop you driving, and you won't get spectated because of "idle" just due to that.

When I had the issue, it was down to my ISP using "traffic management" which screwed certain packets (I was never sure quite which ones, could have been any combination of TCP and UDP on certain ports) when their network was remotely busy. Their game recognition software was designed to recognise game connections and ensure low latency but it couldn't handle LFS. I changed ISP, no recurrence.

Did you try disabling the network monitoring software you mentioned above, by the way?

Quote from Dygear :

Considing the amount of joy S2 bought me, I feel like I owe you guys more money.

+1!

Quote from DANIEL-CRO :

Quote from Scawen :

For some reason the Sleep command gives up less CPU time than requested.

Quickly measured time to complete Sleep(1); using high performance timers.
Minimum=1.00861ms
Average=2.02136ms
Maximum=6.17521ms

Well that would be consistent with the Windows API docs (sleeps for at least what you request, with a caveat about timer-tick resolution). What Scawen has observed is weird and inconsistent with the docs.
I'm a bit puzzled though that a shorter-than-expected sleep leads to a long pause

Quote from Scawen :

The Sleep time is adjusted every frame to try and hit the target. It doesn't take more than one frame to work it out. The settling period you are seeing may be just the frame rate gauge which measures the average frame rate over the last 18 frames. So when one frame takes a tiny bit longer there shouldn't be a glitch.

If you see GPU wait time while trying to run with limited frame rate then you are probably not going to hit the target frame rate. In order to successfully hit the target frame rate, all waiting time should be in the Sleep column. If you see anything in the Wait column (waiting for GPU) then you will not hit the target frame rate.

Sorry I think I was mixing up two issues.

When I run with vsync, I get plenty of GPU wait. When I tinker with something the wait time can do slightly odd things. Best example is to alt-tab out and back in again - then there is a large fraction of a second with no GPU wait shown, but things seem to be vsynced still, and then suddenly the wait time registers and I get a nice salmon-coloured (?) stripe in that column. Slightly strange. And now that I'm looking for it, I can see a variation in the FPS readout during this time (which will be the averaging you just explained), but it hits a solid 60 well before the GPU wait shows up. Perhaps the GPU wait probably is actually happening but just not being shown...

When I run with a limited rate, yes I do get only sleep. For that case, I'd need to do more testing to figure out what oddness I had seen before (But since vsync works so well now I'm using that almost all the time.)

Quote from Flame CZE :

I'm currently having an odd problem in H5. Whenever I go to the pits (Shift + P), there is a 1 to 3 second delay before it shows the garage GUI.

Not seeing it here...

Quote from DANIEL-CRO :

I can set 23, 24, 30, 50, ... Hz in LFS so it shouldn't be a problem. I guess you made custom resolution in a program like AMD CCC, in that case LFS will not display that resolution/refresh rate as an option. Only options are screen modes reported by Windows (that you can configure using just Control Panel).

I was going to try a custom mode, and then checked my monitor manual which says 56Hz is the minimum :-/

Quote from Scawen :

The real way to have graphical frames independent of physical updates is to use one thread for physics and another for graphics.

Yes, I can't believe I keep forgetting what LFS actually does!

One thing I have noticed, which may be something you plan to tune up: when the fps target is changed, there's a brief settling period where I'm assuming the program works out how long it needs to wait(?). After that, the GPU wait time stays pretty stable. When the CPU load changes, I'm guessing that this sleep duration isn't instantly adjusted and that therefore maybe this can contribute to jerkiness. (Should probably only matter much when the load increases I guess.) I may just be inventing nonsense reasons for what I'm observing - when I've driven H5 a bit more and made more sense of the graphs I may be able to describe the symptoms better.

Quote from DANIEL-CRO :

My idea is to store two car positions for each car, one that is updated every 0.01s and used for physics calculation and other one that is used for purposes of moving view/camera/car.

Embarrassingly, I thought that was what LFS already did...