Sorry to bump the thread. I initially thought LFS server converted a totally valid LFS-encoded nickname into an invalid one. I updated the title to match.

If you are not going to implement server-side checks (which I personally find it to be an overkill in this case), you probably shouldn't even bother implementing client-side checks unless you want to. Sure, invalid characters get displayed as squares and whatnot, but it doesn't cause any bigger issues than that on LFS side, as far as I can tell.

Without server-side checks, servers and InSim apps can still get invalid strings by other means, which kind of defeats the purpose. InSim developers should be aware of the possibility of receiving invalid strings. Might as well not bother with client-side checks for that reason. Your decision.

I have talked with Epicproes and issue became appearent. Long story short, he edited the cfg.txt file and saved it with UTF-8. At some point, Japanese characters A2 and A3 of the 'Ply Name' both turned into �, which ended up being encoded as EFBFBD.

In Japanese code page, LFS displays EFBF sequence as a square (no match) and BD as ｽ.


I had an assumption in my code that LFS wouldn't send invalid LFS-encoded bytes, which end up falling back to ? on the decoder, thus causing a round-trip data loss. This is my problem to solve. Apps in general should not rely on any external input being valid.

Editing cfg.txt is just one way of inserting invalid LFS-encoded strings into the game. Any code that runs locally can be altered. Any packets that get sent can be modified on the fly. Bad input can reach server side one way or another.

Ideally, on the server side, there should be checks/sanitizations at each input point, but... I assume that would be too much of a work for such a simple mistake that originated from cfg.txt being edited manually that led to a nickname to be an invalid LFS-encoded string.

I am hesitant to make suggestions but I will say, simply checking/sanitizing the cfg.txt 'Ply Name' should be a good start (and probably enough) and we can accept the fact that any LFS-encoded string can be improperly encoded (possibly by someone messing with memory and/or packets etc.). Maybe the 'Ply Name' can be passed through the clipboard paste logic that falls back to ? in case of unknown characters.

Extra: I searched the logs ('�') and found another person with EFBFBD, so this issue is rare but not one instance only.

Can you please check the LFSBRASIL server October 18th log?


The characters '�' perfectly match the EFBFBD sequence in Latin 1. His nickname is truncated to fit 24 bytes at some point, which reflects on the connect and disconnect messages; nickname is abruptly cut at "(G2" instead of being "(G29)".

Last edited by MizzMaster, Tue 21 Oct 2025, 13:13.

Context (somewhat irrelevant to the bug report): I have an InSim application written in C#, using InSimDotNet library. InSimDotNet offers classes that help convert LFS-encoded bytes into Unicode strings and back. I wanted to have a way of confirming that decoding and encoding operations are lossless, thus wrote a class called 'LfsEncodingChecker': a class that does a round-trip, and checks if input matches round-tripped data. For example: GetString() takes in bytes and gives a unicode string, then I use the string and call GetBytes() on it, and check if the original input bytes match the bytes generated from GetBytes(). Same check applies for GetBytes() function. In case of a data loss, it logs a warning message. I saw this in my logs: (explanation below)

Explanation: My checker worked as intended but the server sent me incorrect LFS-encoded bytes, which subsequently made the checker warn for a different reason. A player named Epicproes had a nickname ("｢OK｣ Epic (G29)") that contained Japanese (CP932) characters '｢' and '｣' which should have been sent as '\xA2' and '\xA3' respectively but they arrived as "\xEF\xBF\xBD".



Here are different representations of what I got and what the server should have sent:




Note: In all cases, nickname was truncated by the server to fit in 24 bytes with a null terminator. This is why the nickname ends with "(G2" instead of "(G29)".


I asked ChatGPT about this mysterious EF BF BD sequence, and it seems to be UTF-8 encoded "replacement character" represented as '�'.



I used Epicproes'es nickname and tried reproducing the same issue but InSim was working as intended. I tried locally (client), on a temporary server, and on the same couple (insim server & lfs server, though I had restarted InSim earlier for maintainance, which might have reset things on server side, I don't know) but couldn't reproduce it.

Quote from Scawen :

By the way, has anyone had a problem like they really think they copied and pasted the unlock code correctly, but it just says "Your unlock code does not match" after you click the unlock button?

I am not 100% sure if I copied the code correctly the first time but I had to copy it again just in case and it worked on my second unlock attempt. I doubt if I copied a space next to the code or not. Maybe there is a bug.

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