The online racing simulator
Searching in All forums
(705 results)
Scawen
Developer
OK, I'm going to assume this isn't a new bug and isn't related to the slight change to debounce code.

If it's an old 'feature' that is unchanged then that is not really for me to look at today.
Scawen
Developer
Thanks for the report.

About the screenshot save, the currency symbols appearing in place of backslash is because that message is displayed in the selected language's codepage, and those characters occupy the backslash slot. It's fairly simple to fix but actually because it can be displayed in the "temporary message" slot in game, which doesn't yet have a codepage specifier, it's just a bit too complicated for today.

On the extra wide characters being truncated, that is expected and there is an explanation here on the November progress report thread:
https://www.lfs.net/forum/post/1942922#post1942922

The thing that was fixed is that characters which were not too wide were also messed up in some cases, and it looked wrong in a different way:
https://www.lfs.net/forum/post/1942787#post1942787
Scawen
Developer
I don't really know what you mean. Are you saying there is a bug?

The issue I am talking about, that debounce code should prevent, is for when you press a controller button once and you get multiple gearshifts (due to switch bouncing, not an LFS bug).
Scawen
Developer
Thanks for the testing.

I do think the new system needs shorter debounce time.

I think I'll reduce the minimum to 10ms and default to 20ms.
Scawen
Developer
No, the sort of thing this change can fix is when people get a double shift from a single press of a button or lever. It happens because the switch on some controllers reports off->on->off->on instead of just off->on, so LFS has to deal with that.

Actually that case was already dealt with. The new code also should deal with the opposite case when the button or lever is released. Instead of going on->off the switch goes on->off->on->off and LFS should now deal with that correctly.

The issue you linked to, it's the first time I've ever heard of it. It would be good if someone could remind me of it when we are doing physics updates.
Scawen
Developer
I'll close this thread as it's not tomorrow any more, it's today.

If you use any kind of game controller, please can you check out this thread about the gearshift debounce:
https://www.lfs.net/forum/thread/93158
New full version today - please test the updated gearshift code
Scawen
Developer
Hi, I've made a "last day change" that makes me quite nervous.

It's supposed to improve (and simplify) the way the "gearshift debounce" works. Some people still got an extra shift when releasing the shift button, and this change should solve that.

So, anyone who uses a wheel or controller, please can you try Test Patch T7 and let us know if it works fine?

Gearshift debounce setting has been reset to 40 ms so you may need to adjust that if you have problematic gearshift buttons.

https://www.lfs.net/forum/thread/93144
Scawen
Developer
Quote from Racon :Is it possible to increase the gearshift debounce upper limit?

Instead of that, please could you try the change in T7:
https://www.lfs.net/forum/thread/93144

I found out the old code didn't look very good. I'm really nervous to change it this late but I can't really see the sense in the way it was coded before.

I think the problem with it was that if you held the button down longer than the debounce time, then there wasn't proper debounce when switching from on to off.

Now, the "debounce timer" is held to maximum constantly while the button is held, so it doesn't matter how long you hold down the button.

The code now has this effect:
When you release the button, you must wait "debounce time" before pressing it again.
Scawen
Developer
Quote from nacim :Since you're developing / fixing small things for this small update...

I'm pretty much finished now, need to get back to the graphics work. At this point I'll only fix serious issues, although your suggestion is probably good. The only thing I have on my list is to allow down to 0.05 on the view lock filter time.

I think you can achieve a reasonable result using the /settings command. Have two differently named copies of cfg.txt and set up two shortcuts something like LFS.exe /settings=cfg_1.txt

Then one can have the setup for the wheel and the other has the setup for the gamepad.
Scawen
Developer
No, sorry. But it is OK to have an old version on your hard drive and you can use that any time for old time's sake.

It's not really possible for Eric to update old tracks with new textures, while also updating the track to how he actually wants it to be now.

And we can't have the old tracks just there with old textures either, as some kind of historical museum piece. Big grin Actually the old tracks don't even work properly in the new graphics system, which is why Eric has to go through all the tracks doing a big overhaul.

But the "museum pieces" are still there, you just have to run the old version. https://www.lfs.net/archive
Scawen
Developer
Victor is fixing the translation system and has replaced the Dutch file.

If anyone wants to use Dutch in T6 you can get it here.

Quote from nikopdr :The filtered mode works great, I like it since i couldn't use rotareneg's insim version at the same time with lfslazy Big grin Also AI seems to take up less CPU after driving around with full grid. Thanks for the test patch Smile

A small question though, would it be possible to adjust the minimum filtering time to 0.05 seconds and have this option separate for cockpit and free view?

I think it should be OK to reduce the minimum filtering time but I don't think I can do the separate saving for the custom views at this point. No real reason except that requires too many changes and I want to release tomorrow. Good suggestion though! Smile
Scawen
Developer
Hi, that's just the amount that can fit in a single packet. It could be possible to increase that number by using multiple packets but that would really be a big change.

Sorry but it's not just a number I can increase, because of the way it's coded as an editor that can be used online, with more than one person editing at a time and so on.
Scawen
Developer
Thank you, I've notified Victor about that. Seems there is still a bug in the online translation page.
Scawen
Developer
Hi Gavin,

We hope to release the full version tomorrow so if you have any time to check T6 this evening, to confirm if the TV cameras view works correctly now, that would be quite reassuring.

Thanks to you and emiljensen2 for the bug reports and testing.

I like the way OpenVR allows us to support more headsets as time goes on.
Scawen
Developer
If possible, please could you test this has been fixed?

I do believe it works but it would be good to hear from someone else!

Thanks for the report and testing.
New full version tomorrow (minor update)
Scawen
Developer
Test Patch T6 is ready for testing.

We are hoping to release the official version of this minor but important update tomorrow. If you have a little time, please try the test patch and let us know if you find any issues.

Info and download

Thanks! Smile
Scawen
Developer
Quote from racerss :...is it possible to investigate the reason as to why clicking the 'Game' tab option in the settings causes LFS to hang for the first time?

That's because of the Unicode characters. Do you get a long hang? On my computer it's just a split second.

Quote from racerss :Players above have also asked about the possibility of increasing the player limit, I think having 48 players on the track (as in 48 connections) would be awesome.

I've tested the patch and everything is working as expected (non VR features).

Thanks for the testing. We can't increase the number of players at the moment as it's a fully compatible version, just a minor update.
Scawen
Developer
0.6T6 is now available. I'm hoping it's the last test patch before the full version of this minor but important update. I want to get back onto the lighting in the development version.

If you have a little time this evening it would be great if you could test it, maybe go online for a race or two.

Thanks!


Views:

FIX: Offset mirror was not drawn offset in forces draw (F)

VR:

Minimum value for manual FOV setting reduced frmo 80 to 75 degrees
FIX: There was a loss of accuracy in the automatic FOV calculation

Misc:

More translations updated - Thank you translators!

Download:

https://www.lfs.net/forum/thread/93144
Scawen
Developer
Quote from Pasci :Technical? That should be 110°. But the driver/controller software is very bad. Can I read that value somewhere? Through SteamVR?

What I mean is the vertical FOV displayed in LFS.

If you select "Automatic" then the text to the left of "Automatic" will state the default vertical FOV (rounded to 1 degree).
Scawen
Developer
No, we are several months away from the graphics update.

The full version we will release is just like T5 with a couple more fixes.

It was extremely important to do this update because of the VR problems that made LFS not work, or in the case of the Odyssey+ could cause eye strain. We don't want that, so that's the reason for this small interruption in my Graphics development.

And the good news is we have this quick little update with quite a few fixes and a couple of new features.
Scawen
Developer
Quote from Pasci :It's because this headset doesn't have a positional tracking like Vive or other headsets have. This system use a special "carpet" to track such movements. But if I drive a car, that system is completely useless. There is no real room scaling as for example at Vive instead.

Even without positional tracking, there should be a 'correct' FOV (hopefully the one supplied by the drivers). You can see what I mean if you increase the FOV a lot, e.g. maximum, then just turn your head left and right. Your should perceive that the world seems to move left or right as well (and/or seems to warp a bit).

With FOV too low there is the opposite effect. But what is the default FOV from the AntVR? I ask because you are talking about numbers near 80 degrees, but 80 is currently the minimum user setting. Maybe I need to allow a bit less, for headsets with less vertical FOV.

I can reproduce the object culling issue at the edges when FOV is increased. It takes the culling from the default input values, and for some reasons it might be a bit tricky to change, or a bit too risky at this point. We hope to release a new full version tomorrow so I want to keep any more changes very small.

Quote from Racon :Not true! There were multiple viruses/malwares running on the last avast-protected computer I came across...

Some discussion about antivirus from Justin Schuh, Google Chrome security engineer.
https://twitter.com/justinschuh/status/802491391121260544
Scawen
Developer
I'll try that tomorrow in the Vive. But I'm interested to know, why do you want to increase the field of view? I would think that would just make it wrong, in the sense of being different from reality, so the world would seem to rotate around a bit as you move your head around.

In fact some people might say we shouldn't even have that setting in there, it's more left over from the early days of VR when I was writing it for the DK1 and had to give the users some control over it so I could understand how to set it correctly.
Scawen
Developer
Thanks, I've told Victor about the items that seem to be missing after the troublemaker's account was deleted. I guess the database needs to be refreshed in some way.


EDIT: Looks OK now, thanks Victor! Smile
Last edited by Scawen, .
Scawen
Developer
The rotated views on the virtual 3D TV should be fixed in T6:
https://www.lfs.net/forum/thread/93144
FGED GREDG RDFGDR GSFDG