Isolate one of those, give it an extra blue color option and we can start decorate lights on pillars ourselves

Quote from just2fast :

It seems it had to do with the runtime 0.8. After going back to runtime 0.7 everything is fine and I can get some constant 75 fps.

I would be interested to know if you get better results with the LFSRiftVR.dll in the attached zip file.

This one is built with the 0.8 SDK and so requires the 0.8 runtime.

You just copy it into your dll folder. Better rename the existing one so you can go back if needed!

EDIT: I've uploaded two versions of the Rift DLL, both built with the 0.8 SDK. There is a slight difference between then but I can't perceive any difference and in fact they may perform just as well as each other.

Also here is an OpenVR DLL built with the latest OpenVR SDK and I was surprised to find out that it also works with the Rift (with 0.8 installed). I found this sometimes started up wrong though and had to exit and restart to get it right. I would be interested to know if this works without SteamVR needing to be installed (by selecting OpenVR instead of Oculus Rift). I have no idea.

in game chat while on server:

/m users
Online : DEMO 360 - S1 0 - S2 134 - TOTAL 494
/m hosts
Hosts : DEMO 194 - S1 75 - S2 238 - TOTAL 507

where s3 ?

Commands_Russian.txt:53
/autosve=0 missing 'a' /autosave=0
Commands_Ukrainian.txt
/autosve=0 missing 'a' /autosave=0

Quote from Scawen :

I would be interested to know if you get better results with the LFSRiftVR.dll in the attached zip file.

This one is built with the 0.8 SDK and so requires the 0.8 runtime.

You just copy it into your dll folder. Better rename the existing one so you can go back if needed!

EDIT: I've uploaded two versions of the Rift DLL, both built with the 0.8 SDK. There is a slight difference between then but I can't perceive any difference and in fact they may perform just as well as each other.

Ok, I have installed runtime 0.8 again for testing, but same behavior as before. Both 0.8 dlls perform poorly. Between 35 to 75 fps with an avarage of around 50 fps, depending what has to be rendered.
In the starting grid for example with only 5 cars it drops down to 30 something.

Maybe it has to do with the NVIDIA driver in conjunction with 0.8?

It´s the latest driver version 361.43. Graphics card is a GeForce GTX 750 Ti.

Quote from Scawen :

Also here is an OpenVR DLL built with the latest OpenVR SDK and I was surprised to find out that it also works with the Rift (with 0.8 installed). I found this sometimes started up wrong though and had to exit and restart to get it right. I would be interested to know if this works without SteamVR needing to be installed (by selecting OpenVR instead of Oculus Rift). I have no idea.

Nope, OpenVR can´t be initialized in lfs (note: SteamVR is NOT installed).

Thank you for the test. Sorry to hear it doesn't help. I am using the 358.91 driver.

Hey Scawen...Can I get another unlock please?

Yes, but please use the tech support email in future if you need an unlock.

This is what I get for not following test patches regularly enough.

I'm trying to run 0.6K and will download/install a test patch shortly to see if it is fixed but, in 0.6K I can't position a window with negative coordinates any more. Which means I can't start up LFS on the monitor I want, it seems to default to a config when ever negative position is used for window position in config.

Good suggestion. I think it's still coded for the XP style of desktop. I'd better make it work with Windows 7 style multi-monitor desktops. This has not changed in any recent test patch.

Scawen, I was spectating on blackbird's server, and since the server was really laggy, clipping was going completely crazy, check this out :

Quote from Scawen :

Good suggestion. I think it's still coded for the XP style of desktop. I'd better make it work with Windows 7 style multi-monitor desktops. This has not changed in any recent test patch.

Strange, patch Z, I think it was seemed to work flawlessly on Windows 10 before I had updated, so if nothing changed there, let me run more tests and get back to you, maybe something was just failing to save in the config or some other oddity going on.

Nacim, I believe the issue there is actually going to wind up my fault, and something I will take a look at later tonight when I get out of work. I believe the issue is with AIRS spamming insim with messages. I could be wrong, but after some players left the server, the tcp errors I was seeing went away completely and others reported the lag got better. I am almost certainly doing something stupid in there, and I had fixed it once, but I bet I used a frame counter that was frame based and so the problem came back once things ran faster.

Though the clipping thing is something I've seen, rarely in the years I've spent playing in LFS and is not new to this test patch.

Quote from blackbird04217 :

Strange, patch Z, I think it was seemed to work flawlessly on Windows 10 before I had updated, so if nothing changed there, let me run more tests and get back to you, maybe something was just failing to save in the config or some other oddity going on.

LFS now runs under DX9 instead of 8. How/If it interferes with your window position I don't know.

Quote from Scawen :

Thank you for the test. Sorry to hear it doesn't help. I am using the 358.91 driver.

No problem as long runtime 0.7 works fine.

BTW with other games/demos I have the same performance issues under runtime 0.8 (358.91 didn´t help either), so at least it´s not lfs related!

Quote from Whiskey :

LFS now runs under DX9 instead of 8. How/If it interferes with your window position I don't know.

At some point I coded it so that it wouldn't be off screen if you switched back from two monitors to one. I found it inconvenient to have to manually edit cfg.txt to get LFS to be visible.

I guess I can find Windows functions that will let LFS know if it really is off screen, and code this check in a better way.

Quote from just2fast :

No problem as long runtime 0.7 works fine.

BTW with other games/demos I have the same performance issues under runtime 0.8 (358.91 didn´t help either), so at least it´s not lfs related!

That's good to know. Yes, for now there is no incompatibility with the 0.7 DLL (and I don't plan to make it incompatible in the near future) so when you get the next patch, just keep your 0.7 DLL and copy it back in.

Quote from nacim :

Scawen, I was spectating on blackbird's server, and since the server was really laggy, clipping was going completely crazy, check this out :

That glitch has existed in LFS since day 1 pretty much. It happens when a client lags and their position changes to a section of track that your client hasn't yet loaded. The game falls out of sync until you reach the section at which you previously saw the car, then it'll return to normal. Long story short, it's nothing new.

Test Patch 0.6K5 is now available! https://www.lfs.net/forum/thread/88821

- Updated to the Rift SDK 0.8 and and OpenVR SDK 0.9.14
- Better multi monitor support and an option to allow input after clicking on another window

Quote from blackbird04217 :

I can't position a window with negative coordinates any more. Which means I can't start up LFS on the monitor I want, it seems to default to a config when ever negative position is used for window position in config.

That should now work properly. Also the option to allow input while window is inactive.

Amazing stuff Scawen, as always. I will get updated asap for these changes. Did you by chance use EnumDisplayMonitors for the window on monitor detection? I was going to try getting that to work and send it your way, but you beat me to it!

EDIT: Installed and seems to be working well for me!

Quote from blackbird04217 :

Did you by chance use EnumDisplayMonitors for the window on monitor detection?

No, I used this :

EDIT: That is to get the corners of the extended desktop, instead of just the main monitor part of the desktop. Then after reading the cfg file it does some comparisons with desktop_rc and the requested window position and if it's invalid or there isn't enough on screen (40 pixels) then it goes to a default 1024x768 window. That is to make sure LFS is visible if the desktop is changed or the cfg file is edited to invalid values.

As you are doing multi-monitor stuff, i have noticed that when you have 3 monitors, one left and one right (and the middle one),

the 2 side monitors can't have different width resolutions. For example when you change left's monitor, it will also change the right's one.

Can you make them independent in case somebody has 3 different monitors and want to combine them?

Input when not focused is genius +1

Today I tried something and got some good results. I started out just trying to improve the support for multiple monitors, which has never looked very good since Windows XP which allowed you to go full screen on multiple monitors. I have a dual monitor setup and it's the best experience on my computer apart from VR. It has the advantage of allowing me to type. The annoying thing was that I had to manually pull the window to the biggest size and then the title bar and borders were always visible.

Today's improved support so far (in my version) is a text command /window max which adjusts the LFS window to be the size of the entire extended desktop, with no border (style WS_VISIBLE).

I'm really pleased with the result. It works in single monitor mode as well. But there is a little strange behaviour with the task bar so I would like to ask here because many of you have experience with other sims and games.

What happens is when I go to the new full sized borderless window, the task bar may be visible. I can click on another program in the task bar and then minimise it - then the task bar vanishes. I can still use ALT+TAB to get to any other program. It's very nice that the bar vanishes but it can also be useful to see it. Sometimes the appearing or disappearing seems a bit unpredictable. Sometimes visible, sometimes not, sometimes visible for a second then disappearing. Is this normal behaviour for programs that use a borderless window?

Another point to consider: In these days of monitors which have a native resolution, I'm not sure we need SHIFT+F9/F10/F11/F12 to be assignable to four different screen resolutions. That seems like a relic from the CRT days. I am thinking that maybe SHIFT+F9 and SHIFT+F10 could be assignable as they are now, but SHIFT+F11 could go to full screen at native resolution (desktop resolution) and SHIFT+F12 could go to this new borderless window mode on the extended desktop.

I agree with the SHIFT+Fxx buttons, and the borderless window. However, I've never implemented that, so I really don't know what can be the problem for this unpredictable task bar.
When LFS is focused, the task bar disappear, right ? If so, everything is fine I guess.

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 Scawen :

...Another point to consider: In these days of monitors which have a native resolution, I'm not sure we need SHIFT+F9/F10/F11/F12 to be assignable to four different screen resolutions. That seems like a relic from the CRT days...

Few days ago I was thinking about the same.