Where did you get the names for these other 2 tracks that are in the works from? They sound so cool 
Edit: To johneysvk, I usually read all progress reports quite thoroughly, but I'm not sure how I missed to see mentioning these new track names..anyway, it's great that we'll have new race environments.
Edit: To johneysvk, I usually read all progress reports quite thoroughly, but I'm not sure how I missed to see mentioning these new track names..anyway, it's great that we'll have new race environments.
Last edited by rane_nbg, .
Do such crashes happen in any other gfx intesive app or a game? Can you observe your gfx card temperautre at the moment of crash, is there anything wierd about it? How much are cpu and gpu utilizitaion while game is running normaly? Are you using fps cap or vsinc in lfs? Is your ssd firmware up to date? Might be worth to post a crash log.
Last edited by rane_nbg, .
Well, I guess some of those weather properties will be adjustable through inSim. There may be some initial default values, like fixed or automatic 6x or whatever, while any manipulation with it may be through a corresponding inSim weather packet.
I'm sure that this will be a topic for a debate once it comes to that and our oppinion/input may be relevant. Such things are really just a matter of convenience, there is no rocket science in it. I'm glad you mentioned it, I was thinking about this a few years ago when wheater concept was first introduced in one of progress reports. How can we potentialy integrate it in airio without its source code will be a real puzzle. To be continued..
Last edited by rane_nbg, .
You explained good enough. Auto adjusted brightness is a good plan for self iluminated displays.
What fantastic news, thanks very much LFS dev team
My only wish is that LFS v2 gets the recognition it deserves outside of our community and emerges at the top of the sim racing mountain.
edit. I can't wait to feel the 1000Hz physics engine and ffb..so hyped about it.
My only wish is that LFS v2 gets the recognition it deserves outside of our community and emerges at the top of the sim racing mountain.
edit. I can't wait to feel the 1000Hz physics engine and ffb..so hyped about it.
Last edited by rane_nbg, .
Oh man, tnx so much I see it, that's exactly what I needed
What I did before is select each car in the session through the dropdown menu list...but this arrow shortcut is awesome.
What I did before is select each car in the session through the dropdown menu list...but this arrow shortcut is awesome.
Tnx for re-introducing round templates Scawen, it is good enough for now.
The rest is for sure not a priority and it can wait for another time, when and if you think it's something that should be improved - the ideas you mentioned all sound good, it seems like a good plan.
Last thing we want is to sidetrack you from current focus on the big update. We'll manage just fine for a while with this system.
The rest is for sure not a priority and it can wait for another time, when and if you think it's something that should be improved - the ideas you mentioned all sound good, it seems like a good plan.
Last thing we want is to sidetrack you from current focus on the big update. We'll manage just fine for a while with this system.
Last edited by rane_nbg, .
Please, can you put round templates back? Our event rounds have 12 items, it's quite tedious to create the round from scratch. Also can anything be done with selecting the mods/cars, for example some type of filtering/sorting, but with more letters? What I mean pressing more than one letter will start only showing mods that start with those letters. Selecting 12 times the same mod from a list of 300+ items is not fun at all. Our evens have a different mod in each round.
Moreover, if possible could number of car slots and item start times be included in the round template? Usualy scheduled events have these two fixed also. The date can be left as it is, but an option to link all items to the same day would much be appreciated.
I'm well aware that not all of this may be implementable without significant changes, but what ever you could do would greatly help to make round creation less of a tedious task.
Moreover, if possible could number of car slots and item start times be included in the round template? Usualy scheduled events have these two fixed also. The date can be left as it is, but an option to link all items to the same day would much be appreciated.
I'm well aware that not all of this may be implementable without significant changes, but what ever you could do would greatly help to make round creation less of a tedious task.
Last edited by rane_nbg, .
What guys are saying is the following. You created a layout on a certain track, say for example BL1. Custom track configuration is required for that and you have two options when loading a track from single player, one is called "x", other is "y". The 1st one reffers to a custom non-reversed variant, say BL1X, other is reversed BL1Y. Your layouts have to have this prefixes in ther name followed by an underscore, for example BL1X_something. To load a custom layout you must load track frist then you must select x or y variant in the track loading menu. I'm not sure how one loads a specific layout from single player.
In an online server, when using airio command is !axi to list all available layouts and !axo something to load say BL1X_something layout if you were already in BL1X.
In an online server, when using airio command is !axi to list all available layouts and !axo something to load say BL1X_something layout if you were already in BL1X.
Last edited by rane_nbg, .
Yes, set auto gear shift and you will not have to lift throttle when shifting gears. You will not even have to shift.
Well, I'd say that within margin of error your experiment is a succses. The problem is that AI's are not driving the car anywhere near the limit of tyre grip. That is why you see little to no difference in laptimes. If you play with engine settings that may yield better diversity.
This guys, we need community to utilize those inSim features and see what AI's can do.
Yeah, just use a deep learning neural network with about 1 billion neurons and it will beat Gabor every time. Just one tiny problem, to run it in real-time you'll have to use a quantum computer with at least 1k qubits.
Jokes aside, optimizing such AI is a huge task that goes outside of LFS itself. Compromises have to be made and the right combination of different techniques, maybe even including small neural networks could be a thing, but all this is in the far future of LFS.
Jokes aside, optimizing such AI is a huge task that goes outside of LFS itself. Compromises have to be made and the right combination of different techniques, maybe even including small neural networks could be a thing, but all this is in the far future of LFS.
Last edited by rane_nbg, .
How about this - let AI drive some car and you put air restriction in your. That way, you can fine tune AI to your pace.
Hi, I'm working on Arduino FFB firmware for quite some time - it's open source and free. It does exactly what you need, you may check it out. There are 2 parts, one is arduino firmware that turns it into an ffb joystick and the other is the GUI for PC to adjust settings. You will need to make a differential amplifier and use 2 external dac's - this will be your analog torque input for the driver. I've provided all documentation, wiring and manuals.
https://github.com/ranenbg/Arduino-FFB-wheel
https://github.com/ranenbg/Arduino-FFB-gui
https://github.com/ranenbg/Arduino-FFB-wheel
https://github.com/ranenbg/Arduino-FFB-gui
Last edited by rane_nbg, .
Very good suggestions and well written. I support.
Hi, we will use this one for our 2-hour event this Sunday. I'd appreciate it a lot if you could address some critical issues.
I propose 2 following fixes:
[1] lower center of gravity (the car can roll very easily)
[2] shorten the upper arm of the rear suspension (it needs camber gain on compression for better turning)
Otherwise, the car is very well made, thank you very much.
I propose 2 following fixes:
[1] lower center of gravity (the car can roll very easily)
[2] shorten the upper arm of the rear suspension (it needs camber gain on compression for better turning)
Otherwise, the car is very well made, thank you very much.
Last edited by rane_nbg, .
I'm reporting that a new option for bump stop works as expected also on my Arduino firmware (joystick). Tnx very much.
It's just a matter of fine tunning the spring constant in endstop spring effect (if he implemented it as a spring). Maybe it's just very stiff at the moment. Usualy all ffb wheel firmware allow you to set this, but that will not be automatically applied in lfs, because it creates this effect independently. But some time in the future, an option to adjust how strong lfs endstop is, could be a thing.
Here it clearly says generic desktop and joystick. This is exactly the same as how I have it my firmware, but lfs reports is as joystick. I'm not sure why your wheel is seen in lfs as first person controler.
Anyway, that's not gonna be relevant anymore once we get the override button.
Anyway, that's not gonna be relevant anymore once we get the override button.
This is in the case where one intentionally pulls the joystick all the way until the mechanical stop, where the end-stop force is maxed out. Obviously, letting go of the stick in such a situation will not end well.
But you are right, it should be kid-safe.The ability to manually override the controller type in lfs is all we need. A simple override button + a short description of what it does is enough. We don't need an entire selection of all other types, we just need the one that makes the end-stop forces work, therefore one button instead of a drop-down menu list. For example, your auto button is renamed to override, once pressed the type will be set to wheel. Unpressed will show the original device value from the HID descriptor.
edit. the quote from SIMUCUBE is exactly what I'm thinking. I'm using such DIY project to create a wheel and having it defined by simulation controls is very limiting, because then many wheel features would not be available. Those are for example D-pad hat switch, X, Y, Z axis and so on.
Last edited by rane_nbg, .
Yes, those generic HEX values are what you need. There is an HID descriptor tool that can decipher easily their meaning because this is part of the DirectX standard. You can get it from here:
https://usb.org/document-library/hid-descriptor-tool
You first select USAGE_PAGE (generic desktop or simulation controls), then under USAGE, you will see available types and properties like axis and so on. Once selected it will show the HEX representation and you may find if anything matches with the values you got from USBTreeView.
https://usb.org/document-library/hid-descriptor-tool
You first select USAGE_PAGE (generic desktop or simulation controls), then under USAGE, you will see available types and properties like axis and so on. Once selected it will show the HEX representation and you may find if anything matches with the values you got from USBTreeView.
Last edited by rane_nbg, .
Yes, let's not go off-topic now with FFB peak forces. Filtering, limiting, and compression can be done but let's leave that for some other time.
I understand well your rationale behind the decision to disable endstop forces other than wheel controllers. My point was that endstop force is not one that can cause the joystick or whatever to oscillate from side to side - actually, the ones that do are autocenter spring force or damper for example. Anyway, I respect your decision if you want to keep it that way.
Thank you for tackling the issue. What exactly will this selection of controller type do? I mean, a simple controller-type override button is enough. By default, you can leave it inactivated and the user can choose to enable it in order to get end-stop forces working.
I understand well your rationale behind the decision to disable endstop forces other than wheel controllers. My point was that endstop force is not one that can cause the joystick or whatever to oscillate from side to side - actually, the ones that do are autocenter spring force or damper for example. Anyway, I respect your decision if you want to keep it that way.
Thank you for tackling the issue. What exactly will this selection of controller type do? I mean, a simple controller-type override button is enough. By default, you can leave it inactivated and the user can choose to enable it in order to get end-stop forces working.
Last edited by rane_nbg, .
Tnx for this info Scawen, it is very useful as it reveals the specific lfs requirement for HID descriptor of an ffb device. Manufacturers use various values for USAGE, it can be wheel, joystick or gamepad, sometimes also first person controller. I will play with my firmware and see if it makes a difference if I change the usage in HID descriptor.
In my oppinion, endstop forces are not dangerous, because this is in essence a spring force. It's intensity depends on axis position, so the user can simply stop pushing against "spring" when ever he wants and it will not fight back. The dangeous forces are the actual ffb signals, where you for example smash the car into a wall which creates a huge peak in ffb one can't do anything about, as it's often quite unexpected.
In my oppinion, endstop forces are not dangerous, because this is in essence a spring force. It's intensity depends on axis position, so the user can simply stop pushing against "spring" when ever he wants and it will not fight back. The dangeous forces are the actual ffb signals, where you for example smash the car into a wall which creates a huge peak in ffb one can't do anything about, as it's often quite unexpected.
MOZA also just uses direct input API. If you can have a look at wheelcheck or DI view and expand the part which describe the ffb features, see what they have defined in HID descriptor. Would be interesting to see which ffb effects they have implemented. I'll show the examples of t300 and my arduino firmware soon.
FGED GREDG RDFGDR GSFDG