For now, I have provided an option to show guest IP addresses.
Next time you restart your host, IP addresses will not be displayed by default. But you can switch them on with an option in the basic settings.
This is not what I was hoping to do in the first place, to really improve privacy by hiding the IP address, but it does (or can) help a bit.
1) Minimum disruption. People who want to use the IP address on paid hosts still can.
2) Reduce general visibility of IP addresses. They will only be there if the option is enabled, and never in free hosts.
3) The master server is aware of the setting, so I can make it visible in the list or show a warning to joining guests.
I'd rather not work on a unique identifier to identify the guest's PC or LFS installation with a random number at this time. There are too many distractions and not enough development time so some things will have to wait if I don't really have to do them at the moment.
Next time you restart your host, IP addresses will not be displayed by default. But you can switch them on with an option in the basic settings.
This is not what I was hoping to do in the first place, to really improve privacy by hiding the IP address, but it does (or can) help a bit.
1) Minimum disruption. People who want to use the IP address on paid hosts still can.
2) Reduce general visibility of IP addresses. They will only be there if the option is enabled, and never in free hosts.
3) The master server is aware of the setting, so I can make it visible in the list or show a warning to joining guests.
I'd rather not work on a unique identifier to identify the guest's PC or LFS installation with a random number at this time. There are too many distractions and not enough development time so some things will have to wait if I don't really have to do them at the moment.
Thanks for the FIA regulations reference. So at least in F1, it's the wheels that need to be inside the box.
I'd be interested to know if any other classes require bodywork to be behind the line. For practical reasons I could imagine that being the case in karting, but really have no idea. I wonder about classes that are not open wheel.
At the moment in LFS, the timing (at splits and finish line) is done when some arbitrary point of the vehicle crosses the line. Probably the model's origin. This is what I don't like at the moment.
Bear with me as I'd like to get this right if possible. I believe the coding to be relatively simple but I want to get this right by thinking it through.
What we have so far is that starting point, at least in some classes, should be based on front wheels behind the white line. Probably just aim for the yellow line. It would be interesting to know if some classes put the bodywork behind the line. And that leads me to a related issue I am wondering about:
Photo finishes.
I guess that photo finishes must be based on the front part of the bodywork, rather than the wheels? But the front overhang can vary a lot between different cars, up to a value of a few milliseconds depending on the speed. So this leads to the point that some cars might need to drive further to complete the race. Of course this is really of no concern with an ordinary grid, every car drives a different distance anyway, so who cares about a few inches. But what about a drag race? The start and end must depend on the same thing (wheels or bodywork). What method is used for the timing? At first I could imagine them using laser timing, but I guess that doesn't work if you have two cars overlapping.
So then we have the possibility that for a drag race, the bodywork should be behind a line, but on a grid start, the front wheels must be behind the line.
Should splits and finish line use the front of the bodywork rather than the front wheels? In real life racing what methods are used for the millisecond-accurate timing?
Hope I've explained this confusion enough, would be interested if anyone has knowledge or evidence to resolve the questions.
I'd be interested to know if any other classes require bodywork to be behind the line. For practical reasons I could imagine that being the case in karting, but really have no idea. I wonder about classes that are not open wheel.
At the moment in LFS, the timing (at splits and finish line) is done when some arbitrary point of the vehicle crosses the line. Probably the model's origin. This is what I don't like at the moment.
Bear with me as I'd like to get this right if possible. I believe the coding to be relatively simple but I want to get this right by thinking it through.
What we have so far is that starting point, at least in some classes, should be based on front wheels behind the white line. Probably just aim for the yellow line. It would be interesting to know if some classes put the bodywork behind the line. And that leads me to a related issue I am wondering about:
Photo finishes.
I guess that photo finishes must be based on the front part of the bodywork, rather than the wheels? But the front overhang can vary a lot between different cars, up to a value of a few milliseconds depending on the speed. So this leads to the point that some cars might need to drive further to complete the race. Of course this is really of no concern with an ordinary grid, every car drives a different distance anyway, so who cares about a few inches. But what about a drag race? The start and end must depend on the same thing (wheels or bodywork). What method is used for the timing? At first I could imagine them using laser timing, but I guess that doesn't work if you have two cars overlapping.
So then we have the possibility that for a drag race, the bodywork should be behind a line, but on a grid start, the front wheels must be behind the line.
Should splits and finish line use the front of the bodywork rather than the front wheels? In real life racing what methods are used for the millisecond-accurate timing?
Hope I've explained this confusion enough, would be interested if anyone has knowledge or evidence to resolve the questions.
Last edited by Scawen, .
You are right that this is a bit of a mess at the moment, something we've never considered properly. To fix it, we need to:
1) align the visual objects correctly with the invisible start positions
2) set the cars such that part of the car is aligned with one of the lines
Eric found the dimensions of the grid box and has provided me with an accurate start grid box object.
It's not clear to me what the actual rules are, regarding the positioning in the box. Is it the front of the car needs to be within the white lines, and the yellow line is just a sighting line for drivers (e.g. F1) as they can't see the white lines? Or is there something about aligning the wheels with one of the lines?
I'd be interested to see some evidence about what part of the car should line up exactly with which line, if anyone can find that.
1) align the visual objects correctly with the invisible start positions
2) set the cars such that part of the car is aligned with one of the lines
Eric found the dimensions of the grid box and has provided me with an accurate start grid box object.
It's not clear to me what the actual rules are, regarding the positioning in the box. Is it the front of the car needs to be within the white lines, and the yellow line is just a sighting line for drivers (e.g. F1) as they can't see the white lines? Or is there something about aligning the wheels with one of the lines?
I'd be interested to see some evidence about what part of the car should line up exactly with which line, if anyone can find that.
Posted by cuni on LFS Movies thread: https://www.lfs.net/forum/post/2126555#post2126555
A 16 minute history of LFS in Spanish by Jinx / @Littl3Jinx
A 16 minute history of LFS in Spanish by Jinx / @Littl3Jinx
Last edited by Scawen, .
Reason : added name of the video's creator
Editor F11:
FIX: wire overlay was not clearly visible especially in 2D views
32 layers are now available + scroll bar and option to show all
FIX: wire overlay was not clearly visible especially in 2D views
32 layers are now available + scroll bar and option to show all
Thanks, I see the same (it looks good in F but not F10).
That is probably related to the Z buffer change.
That is probably related to the Z buffer change.
Editor F10:
FIX: Rear caster angle can now be set in the base default setup
FIX: Avoided the jaggies on generated sky texture near the horizon
FIX: Rear caster angle can now be set in the base default setup
FIX: Avoided the jaggies on generated sky texture near the horizon
In my test that seems to be working as intended. Adjusting the "Lowest wheel height" misaligns the fork, but the misalignment is corrected with "Forward" in Suspension settings (at top left of screen).
Although it seems odd, this is also intended.
It's something like: the first setup defines the geometry but the second setup works like an adjustment.
When you delete the base setup, the new base setup defines the geometry, so if its lowest wheel height was different from the deleted base setup, you will then need to adjust the lowest wheel height or the "Forward" value.
Thanks for the report.
It looks as if that has been the case for a long time, I think since before LFS editor was released.
EDIT: Correction, it looks like the change was September/October 2022. I think the setup storage changes were related to multithreading. So it probably did work correctly in the earliest public versions of LFS Editor.
Without much investigation, I don't think it should be like that, but on the other hand I think it doesn't really affect anything much (given the current limitations of LFS suspension physics). I think it was an unintended result of a change around the way the live setup is stored. I'll have a look to see if it can be corrected.
It looks as if that has been the case for a long time, I think since before LFS editor was released.
EDIT: Correction, it looks like the change was September/October 2022. I think the setup storage changes were related to multithreading. So it probably did work correctly in the earliest public versions of LFS Editor.
Without much investigation, I don't think it should be like that, but on the other hand I think it doesn't really affect anything much (given the current limitations of LFS suspension physics). I think it was an unintended result of a change around the way the live setup is stored. I'll have a look to see if it can be corrected.
Last edited by Scawen, .
Fixes for moving subobjects in Editor F9.
Thanks for the report and test data.
The problem was related to a movable subobject that was made invisible by configuration layers. Any subobjects later in the list would go wrong.
The problem was only in the recent editor and not in the public LFS.
The bug is now fixed in Editor F9. https://www.lfs.net/forum/thread/111321
The problem was related to a movable subobject that was made invisible by configuration layers. Any subobjects later in the list would go wrong.
The problem was only in the recent editor and not in the public LFS.
The bug is now fixed in Editor F9. https://www.lfs.net/forum/thread/111321
OK, let's figure this out. For some reason the subobject you are trying to move has type "SLIDER" but the internal 'mover' that moves it has type "SPINNER".
But of course the mover should have acquired its type from the subobject it represents. So the question is why is that happening. Could it be you have reached a limit? How many moving subobjects do you have?
EDIT: Incidentally, object type 'spinner' was not working in the latest version of the editor (Test inputs) but I've fixed it now. But that is not related to Tuttu's bug.
But of course the mover should have acquired its type from the subobject it represents. So the question is why is that happening. Could it be you have reached a limit? How many moving subobjects do you have?
EDIT: Incidentally, object type 'spinner' was not working in the latest version of the editor (Test inputs) but I've fixed it now. But that is not related to Tuttu's bug.
Last edited by Scawen, .
Thanks for the report. The syncer had not been restarted after a recent server reboot.
You should find it works correctly now.
You should find it works correctly now.
If it's not a particular mod (or some particular mods) then the only thing to do is wait for the big release of the new graphics version.
In the new version:
Only the "physics" part of the vehicle is created when the player leaves the pits. The graphical model is delayed, and only created (on the graphics thread) when that vehicle comes into view. There may still be a small glitch at that point, but it will be less than in the old (current) version because no textures are loaded at that point. The textures are loaded one at a time over the subsequent frames, instead of loading them all at once.
In short, pit-out glitch is a well known and 'ancient' problem that is worsened by some mods, and I've already dealt with it by various means, for this reason. Unfortunately you still have to wait a while before you get the updates.
In the new version:
Only the "physics" part of the vehicle is created when the player leaves the pits. The graphical model is delayed, and only created (on the graphics thread) when that vehicle comes into view. There may still be a small glitch at that point, but it will be less than in the old (current) version because no textures are loaded at that point. The textures are loaded one at a time over the subsequent frames, instead of loading them all at once.
In short, pit-out glitch is a well known and 'ancient' problem that is worsened by some mods, and I've already dealt with it by various means, for this reason. Unfortunately you still have to wait a while before you get the updates.
That doesn't sound like anything new. It sounds like the pit-out glitch that has always been there, that I have already worked on in my new version of LFS that is not yet public.
I'm not really interested in the normal small glitches that have always been there and I have already worked on.
The original poster reported something new that has been going on, so that explains the thinking in my previous post.
I'm not really interested in the normal small glitches that have always been there and I have already worked on.
The original poster reported something new that has been going on, so that explains the thinking in my previous post.
LFS hasn't changed and this has nothing to do with compressed skins. Mods all come with compressed skins and textures, and downloaded skins are also compressed, so switching that option doesn't affect mods.
I believe the most likely explanation is poorly constructed mods. If you can identify a mod that causes a noticeable stutter when it loads, I can have a look to see what is wrong with it. If it's every time it loads, it's probably a poorly optimised model or some other model issue, or maybe audio files (or something wrong with LFS that mod shows up). If the mod only loads slowly the first time since LFS started, it might be related to excessive textures.
You could possibly identify a mod with such an issue by starting LFS fresh and watching an MPR. When you see a glitch, find out who just left the pits and check out their vehicle name that is shown in F11 or F12 menu. If the same issue happens each time with specific mods you could start to prepare a proper report.
I am very busy and will not get involved unless I am given a definite and reproducible example of a mod that causes a glitch when it loads.
Alternatively there could be a problem with your computer or Windows is checking files that are downloaded or something like that. I suppose in this case the problem would only show up the first time a mod is downloaded, rather than every time it is loaded.
It could be that your mods folder has become huge. You could use the cleanup on the mods screen i game to reduce the folder, or you could delete all the mods in the mods folder to see if it helps (I mean once, not every time you start LFS).
EDIT:
1) Please only report a mod that causes a *bad* stutter or glitch, not just slight ones. I can't emphasise enough how busy I am and don't want to go on a wild goose chase.
2) The new version of LFS spreads out mod loading and creation over more frames so ordinary loading glitches should be reduced. But that doesn't stop me taking an interest in mods that cause an extra bad glitch.
I believe the most likely explanation is poorly constructed mods. If you can identify a mod that causes a noticeable stutter when it loads, I can have a look to see what is wrong with it. If it's every time it loads, it's probably a poorly optimised model or some other model issue, or maybe audio files (or something wrong with LFS that mod shows up). If the mod only loads slowly the first time since LFS started, it might be related to excessive textures.
You could possibly identify a mod with such an issue by starting LFS fresh and watching an MPR. When you see a glitch, find out who just left the pits and check out their vehicle name that is shown in F11 or F12 menu. If the same issue happens each time with specific mods you could start to prepare a proper report.
I am very busy and will not get involved unless I am given a definite and reproducible example of a mod that causes a glitch when it loads.
Alternatively there could be a problem with your computer or Windows is checking files that are downloaded or something like that. I suppose in this case the problem would only show up the first time a mod is downloaded, rather than every time it is loaded.
It could be that your mods folder has become huge. You could use the cleanup on the mods screen i game to reduce the folder, or you could delete all the mods in the mods folder to see if it helps (I mean once, not every time you start LFS).
EDIT:
1) Please only report a mod that causes a *bad* stutter or glitch, not just slight ones. I can't emphasise enough how busy I am and don't want to go on a wild goose chase.
2) The new version of LFS spreads out mod loading and creation over more frames so ordinary loading glitches should be reduced. But that doesn't stop me taking an interest in mods that cause an extra bad glitch.
Last edited by Scawen, .
It sounds like the sort of issue that could happen with a mod that is not well optimised, resulting in a slow build of the in-game model or loading textures or sound files.
Please could you link to the information that gives rise to your summary points and the 'Rec' references? I only found the 4-page document on the page you linked to but that doesn't have the 'Rec' points and doesn't seem so dramatic.
EDIT: I found the link in the reddit thread: https://home-affairs.ec.europa.eu/document/download/1105a0ef-535c-44a7-a6d4-a8478fce1d29_en?filename=Recommendations%20of%20the%20HLG%20on%20Access%20to%20Data%20for%20Effective%20Law%20Enforcement_en.pdf
EDIT: I found the link in the reddit thread: https://home-affairs.ec.europa.eu/document/download/1105a0ef-535c-44a7-a6d4-a8478fce1d29_en?filename=Recommendations%20of%20the%20HLG%20on%20Access%20to%20Data%20for%20Effective%20Law%20Enforcement_en.pdf
I've got a feeling this will be the future for other games where customers can start their own servers.
Developers will not want to be held responsible for revealing user IP addresses to hosters.
Developers will want to provide more robust help for hosters to identify troublesome players.
Developers will not want to be held responsible for revealing user IP addresses to hosters.
Developers will want to provide more robust help for hosters to identify troublesome players.
Currently I am in favour of an identifier created based on some values from the client computer. And possibly also a country code sent separately though I haven't looked up how to do that yet. I know such functions are available on the web server but our master server is not written in php.
The idea is:
1) Avoid sending guest IP addresses to hosters.
2) Allows hosters to identify if someone uses multiple user names from one computer.
3) Allows hosters to identify if the same user name is used from multiple computers.
As far as I understand, this is why hosters have previously used the IP address, although as already discussed, it is a flawed method. No doubt the identifier I mentioned could be hacked too (by a persistent annoying guest) but I think it would have to be deliberate. IP addresses can change randomly on some connections so to some extent the computer ID should be more reliable.
I wonder if something as simple as a crc32 of some values obtained by LFS from the guest's PC locally would be enough. It would compress a few strings and numbers all into a single 32-bit integer so it would be impossible to reverse to obtain any information about the computer it came from, even if you know the algorithm that created the crc32.
The other thing about using a crc32: as a 32-bit number, it could be processed by the same functions as the current IP address field, by existing legitimate host programs. If could even take the place of the IP address in existing InSim packets, except that of course you cannot use it to identify the user's country.
It is possible that more than 1 computer could produce the same identifier but unlikely as there are over 4.3 billion possible values.
Please let me know if it sounds right, or if I'm missing anything.
The idea is:
1) Avoid sending guest IP addresses to hosters.
2) Allows hosters to identify if someone uses multiple user names from one computer.
3) Allows hosters to identify if the same user name is used from multiple computers.
As far as I understand, this is why hosters have previously used the IP address, although as already discussed, it is a flawed method. No doubt the identifier I mentioned could be hacked too (by a persistent annoying guest) but I think it would have to be deliberate. IP addresses can change randomly on some connections so to some extent the computer ID should be more reliable.
I wonder if something as simple as a crc32 of some values obtained by LFS from the guest's PC locally would be enough. It would compress a few strings and numbers all into a single 32-bit integer so it would be impossible to reverse to obtain any information about the computer it came from, even if you know the algorithm that created the crc32.
The other thing about using a crc32: as a 32-bit number, it could be processed by the same functions as the current IP address field, by existing legitimate host programs. If could even take the place of the IP address in existing InSim packets, except that of course you cannot use it to identify the user's country.
It is possible that more than 1 computer could produce the same identifier but unlikely as there are over 4.3 billion possible values.
Please let me know if it sounds right, or if I'm missing anything.
I do not reply to every single post. if I did, I would be full time forum support and no time developing. So, just like everyone else, you can make a point then just let me take it in and consider it. I will reply if I need more information.
Do you know, sentences or phrases in capital letters are seen as "SHOUTING" and are usually considered rude?
It doesn't look like you are being calm and reasonable, but instead you seem to be shouting at everyone.
Last edited by Scawen, .
A host that may have links to a particularly bad LFS user has been reported to us. It's hard to prove the link but it could be someone that you don't really want to know your IP address.
Something changed - we do the hosting now and can possibly protect our users a bit, instead of freely handing out their IP address whenever they join a host, which I am feeling a little bad about given the situation.
Maybe I should pump a lot of iron in the gym and fly around the world beating up baddies? Not going to happen, is it? Sitting here at my desk I can make a cool game but I struggle a bit to make bad guys feel the consequences of their actions.
But I could make a change not to freely hand out personal information of our customers, which is why I've opened this topic.
In case anyone wonders, I don't like this part of my job at all. Internet security and hackers are just the worst thing to have to deal with. This is no fun at all, but sometimes I feel I have a responsibility to our users, so this is why I'm asking if there could be alternative methods to help with the things that IP addresses can slightly help with (or maybe even something better, given that IP address checking is so weak and often fruitless).
FGED GREDG RDFGDR GSFDG