Small typo at line 2474:
> // CS_STOP_CONTTROL

Isn't having no differential the same as having a locked diff? LFS Editor allows only locked diff if you choose the vehicle type as kart.

Quote :

Same for suspension... Frame and axles takes this job but in LFS it's perfectly stiff

As far as I know LFS does not simulate chassis flex.

Quote from Pukyy :

And, why exactly is this necessary in a racing simulation?

Definitely not necessary, but "it would be nice.". Although the game is being branded as a racing simulator, one must realise that there is a great amount of players interested in the cruise/freeroam part of the game. Simply take a look at the server list.

My personal opinion is that features like this let the community come up with new tools, which makes the game more entertaining. More fun > more playtime > more activity > more people possibly buying the game because their friends are playing, etc. I don't know what kind of perspective you guys have, but I don't think these additions would damage the racing aspect or the community of the game. If I tried to join races with my little to no skill when I first started, I would get punished for my incompetence. For starters, cruise servers are a safe haven compared to racing servers, where people can at least learn to drive and get going. Not everyone is born a driver.

I believe such features would help the racing community grow as well in the long run.

Is there a way to engage starter motor in case gas engine stops? If not, Input 253 -> engage starter motor?

I have a feature suggestion considering the thread about AI controls: https://www.lfs.net/forum/post/2114646

It would be a nice complementary feature if we could cast ray(s) using InSim packets into touchable surfaces in the game to measure distance and/or test for a hit from a point and a vector. Programmers could use this data for machine learning algorithms, simulating parking sensors, or simulating emergency braking.

Programmer Info, LYT format, NOTE3: "The ground check is performed with a test ray starting from 2 meters above Zbyte"

When we reset our vehicle, casting operation apparently skips the vehicles underneath and hits the ground instead. Either track surface or layout object. This being called a "ground check" tells me that it excludes vehicles. Whereas, for example, tyre physics do take into account vehicle hitboxes as well.

If it is not tedious to implement, it would be nice to have an option to specify what kind of surfaces the ray can intersect with: track, layout, vehicle, etc. For example, an emergency braking system might only trigger on vehicles (radar, metal surfaces), while parking sensors would trigger on any surface (sonar, sound waves would reflect off of any surface).

This is a really nice addition and opens doors to new possibilities.

I have a feature request (I will post it on appropriate forum as well)
It would be a nice complementary feature if we could cast ray(s) using InSim packets into touchable surfaces in the game to measure distance or test for a hit from a point and a vector. Programmers could use this data for a machine learning algorithm or simulating parking sensors

Last edited by MizzMaster, Thu 23 Jan 2025, 21:58.

Safe to say the dev shall not going to spend time implementing such a feature. Without people having the freedom to launch their own servers independent from lfs to make profit off of such feature, there is almost no incentive that someone will try to hack their way into implementing AI traffic of some sort either. I dont understand why people are against non-racing but simulator activities

Quote from tumes925semut :

I need there formula what convert negative to positive...

If there is any abs() function, use it. (abs = absolute, if $a < 0 then $a = -$a endif)

I am not sure about the values and ranges in your code, but I can tell that you are actually measuring the angle of the car compared to its Direction instead of comparing it to the measurement line's Angle which probably what you wanted in the first place. Although this approach would give you the actual drifting angle of the car, there is no guarantee you will get 90 degrees just because you past the line like in the image. If you want that, calculate the difference between the Heading and Angle of the line instead of Direction.

In "Player Vars.txt", there are two variables that you need to use:

First, convert them to the appropriate format.
- They might be in a byte range instead of degrees [0-255]. Simply multiply them by 360 and divide them by 255. (x * 360 / 255)
- If both of them aren't clockwise or anti-clockwise, convert one to other's. (360 - x)
- Both of them start from the same axis (+y), so you dont need to adjust it in this case.
Final format: Both of them (C +y) or (AC +y), range [0, 360].

Then all you need to do is:
- Calculate the difference between them to get the angle. Angle = abs(Heading - Direction) [0 - 360]
- If it is greater than 180, substract from 360. Angle = 360 - Angle [0 - 180]
(In case of something like Heading is 350 and Direction is 10, Angle should be 20, not 340)

Keep us updated if it works or not.

"Can't add : invalid position"

Even if you don't select any objects and press O, lfs interprets it as a message anyways. (PMO_POSITION, see InSim.txt PMOAction enum). People can use this information in their InSim's to teleport people into the pointed location, for example. So, it is completely normal for this message to appear even if you haven't selected an object because you don't have to select one.

bruh

IS_OBH Zbyte is always zero even if the 'OBH_LAYOUT' is set in the 'OBHFlags'. The Zbyte inside the CarContOBJ does reflect the actual approximate altitude of the car.

(InSimDotNet library was skipping the Zbyte in the CarContOBJ but was actually reading the Zbyte in the IS_OBH. So, it is not a library related problem.)

InSim version: 9, Server version: 0.7D, Game version: 0.7D