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.
I also noticed after some lfs update that I can't anymore feel endstop force generated by lfs on logi G29 wheel. Before that particulair update from a few years ago I could feel end stops in cars that had less rotation than 900deg (I used 1.0 wheel turn compensation).
However, on thrustmaster t300 I have the endstops. On my custom arduino firmware for ffb wheel, I also don't have enstops, so I have no idea what's going on. In all cases I'm using 2 ffb controlers plugged in, one of the comertial wheels + my arduino wheel firmware that I use only for load cell brake pedal. On its own, only t300 has working endstop from lfs, in its driver I have it set to 1080deg and lfs does the rest as it should.
edit.For ffb neard eyes only - the problem seems to be related in how lfs creates the endstop force. Some wheel firmware like the one in t300 which just use direct input API for ffb actualy have a few ffb effects alocated for this purpose called axis barrier and angle barrier. I have no way of telling if lfs utilizes those or just uses constant force effect to create the ilussion of endstop. In my custom arduino firmware, I can clearly observe that lfs send only constant force ffb effect. But there is nothing being sent at the moment where a full lock of particulair car is reached, this is before the wheel's actual lock (where it applies its internal endstop). If we could get more details from lfs devs about this matter, I could then test it in details and report the findings which may lead to some solution. Just like we did for issue where lfs would only send one sided ffb in some new wheels.
However, on thrustmaster t300 I have the endstops. On my custom arduino firmware for ffb wheel, I also don't have enstops, so I have no idea what's going on. In all cases I'm using 2 ffb controlers plugged in, one of the comertial wheels + my arduino wheel firmware that I use only for load cell brake pedal. On its own, only t300 has working endstop from lfs, in its driver I have it set to 1080deg and lfs does the rest as it should.
edit.For ffb neard eyes only - the problem seems to be related in how lfs creates the endstop force. Some wheel firmware like the one in t300 which just use direct input API for ffb actualy have a few ffb effects alocated for this purpose called axis barrier and angle barrier. I have no way of telling if lfs utilizes those or just uses constant force effect to create the ilussion of endstop. In my custom arduino firmware, I can clearly observe that lfs send only constant force ffb effect. But there is nothing being sent at the moment where a full lock of particulair car is reached, this is before the wheel's actual lock (where it applies its internal endstop). If we could get more details from lfs devs about this matter, I could then test it in details and report the findings which may lead to some solution. Just like we did for issue where lfs would only send one sided ffb in some new wheels.
Last edited by rane_nbg, .
I only see this work in situations like KY1 or similair tracks where one side of the car is heavily loaded while on the other side tires stay always cold. Maybe it would be worth a try to have asymetric tyre compound placement option included when togling it on for tyre pressure..
Would be good if we could also remove the missplaced reaction, not so easy to pinpoint a tiny thing with a finger on a small phone screen.
We're gonna be driving your škoda felicia kit car in our mod shakedown on this sunday. We'd love to see you there as an honorary guest.
I'll have to vote -1 for this idea.
FGED GREDG RDFGDR GSFDG