I'm trying to weigh up the advantages to hosters, compared with the privacy of users.
Trouble is, I've asked in the hosters forum section, so answers are likely to be biased in favour of hosters.
But we have a genuine problem. Without wanting to name anyone (and I will not confirm or deny any user names, please don't ask) I believe there is a strong possibility of a hoster who will collect IP addresses and link them with user names for malicious reasons.
What I am really asking is if these apparently small advantages that you get as a legitimate hoster, from seeing IP addresses, is really worth the potential invasion of privacy and revealing of private data to malicious actors when we can easily prevent it.
Trouble is, I've asked in the hosters forum section, so answers are likely to be biased in favour of hosters.
But we have a genuine problem. Without wanting to name anyone (and I will not confirm or deny any user names, please don't ask) I believe there is a strong possibility of a hoster who will collect IP addresses and link them with user names for malicious reasons.
What I am really asking is if these apparently small advantages that you get as a legitimate hoster, from seeing IP addresses, is really worth the potential invasion of privacy and revealing of private data to malicious actors when we can easily prevent it.
I was really looking for simple solutions to a serious problem, which is why I suggested not revealing IP addresses to hosts.
Your post seems very much from the point of view of a hoster. No doubt it's fine if someone's IP address is linked with their user name on your system, and most hosters who will read this, but it's not you or them we are worried about.
I don't really think a warning when you join a host, warning about the issues of someone seeing your IP address, could really help. That would be about as much help as the ridiculous lengthy legal documents you have to agree to when installing software, or these stupid dialogs that come up every time you visit a website "We really care about your privacy so is it OK to send your personal information to 1000 legitimate businesses?".
Unfortunately this is no more than a dream. If we could remove bad people simply by removing their LFS license, things would be pretty easy. Unfortunately, the people who have caused the most disruption and destruction are easily able to obtain multiple licenses (and obviously IP addresses).
Sometimes it seems like people think that we have all the world's police forces under our control, waiting for us to snap our fingers and they'll jump into action and lock up the baddies. Actually we're just a couple of people on the internet trying to make a nice game and the police are obviously not interested. So holding people to account isn't really an option.
Yes that's easy and I'm sure it should be done, but as already mentioned won't solve the problem.
This would have to be more like assess on an individual basis and manually set the option. Just existing for a year isn't necessarily enough to be trusted. So we would then be in the position of answering requests for hosters via tech support, which puts us in a difficult position (some easy decisions, some not, it's the ones in the middle that are more of a concern - trying to detect deception in tech support emails is something we have to do but it's not a nice part of our life and really not something we want to increase).
Your post seems very much from the point of view of a hoster. No doubt it's fine if someone's IP address is linked with their user name on your system, and most hosters who will read this, but it's not you or them we are worried about.
I don't really think a warning when you join a host, warning about the issues of someone seeing your IP address, could really help. That would be about as much help as the ridiculous lengthy legal documents you have to agree to when installing software, or these stupid dialogs that come up every time you visit a website "We really care about your privacy so is it OK to send your personal information to 1000 legitimate businesses?".
Unfortunately this is no more than a dream. If we could remove bad people simply by removing their LFS license, things would be pretty easy. Unfortunately, the people who have caused the most disruption and destruction are easily able to obtain multiple licenses (and obviously IP addresses).
Sometimes it seems like people think that we have all the world's police forces under our control, waiting for us to snap our fingers and they'll jump into action and lock up the baddies. Actually we're just a couple of people on the internet trying to make a nice game and the police are obviously not interested. So holding people to account isn't really an option.
Yes that's easy and I'm sure it should be done, but as already mentioned won't solve the problem.
This would have to be more like assess on an individual basis and manually set the option. Just existing for a year isn't necessarily enough to be trusted. So we would then be in the position of answering requests for hosters via tech support, which puts us in a difficult position (some easy decisions, some not, it's the ones in the middle that are more of a concern - trying to detect deception in tech support emails is something we have to do but it's not a nice part of our life and really not something we want to increase).
Last edited by Scawen, .
This is not about people harming servers, it is about server owners gathering information about clients who connect to their servers.
What I am saying is, if we don't pass the guest IP address information to the hosters, they will not know it, and there is no possible way around that. So that is a security or privacy improvement for people going online in LFS.
This is not a suitable solution. I am talking about unscrupulous people with the means to rent servers and with their own database and possibly website. Please note that when I say "unscrupulous" this is really an understatement.
OK now we are talking about trying solve the (different) problem of guest troublemakers when IP address is not available (and isn't a good identifier anyway as people can keep changing it).
A PC-based identifier is certainly something to be considered, although no doubt that part of LFS could be hacked so it won't be a perfect solution either.
Do we really need to display client IP address?
Dear hosters,
I want to ask you about a privacy issue. I know there are good reasons to display the IP address of connecting clients (in the logs and in an InSim packet) but there is also a problem.
Unscrupulous people are able to start a host and obtain the IP address of any users who connect. We can't prevent this if we do provide guest IP information. If we ban a known unscrupulous user, they can always create a new user name and do it again.
But as we (LFS developers) are doing the physical hosting, we could provide complete privacy for the IP address of connecting clients. We could simply not show them in the logs or InSim packets.
What do you think? I know some of you have good reasons for using IP address information, but could you do without it? Please try to weigh up the upsides and downsides.
Thanks.
I want to ask you about a privacy issue. I know there are good reasons to display the IP address of connecting clients (in the logs and in an InSim packet) but there is also a problem.
Unscrupulous people are able to start a host and obtain the IP address of any users who connect. We can't prevent this if we do provide guest IP information. If we ban a known unscrupulous user, they can always create a new user name and do it again.
But as we (LFS developers) are doing the physical hosting, we could provide complete privacy for the IP address of connecting clients. We could simply not show them in the logs or InSim packets.
What do you think? I know some of you have good reasons for using IP address information, but could you do without it? Please try to weigh up the upsides and downsides.
Thanks.
Fixed some bugs and issues in F7 game and editor, updated to F8.
Available on the same links in first post.
Available on the same links in first post.
OK, that's fixed in Test Patch F8: https://www.lfs.net/forum/thread/110607
Forces view mode is no longer applied to object mods (e.g. track mods)
FIX: Fuel and damage settings were always default on non-route configs
Forces view mode is no longer applied to object mods (e.g. track mods)
FIX: Fuel and damage settings were always default on non-route configs
Thanks, I see the bug, even starting a race in single player in an XFG. Will check that out this morning.
EDIT: I see the fuel load is always 100% in game (bug) but don't see a problem with the setup, that seems to be the one I selected.
EDIT2: I've found the fuel bug. It only comes up when you are on an open config or in a place like a car park or layout square, where there is no path for a route. That explains why the bug wasn't found in previous test patch. It's start fuel, pit fuel, tyre change wear, pit repair option.
EDIT: I see the fuel load is always 100% in game (bug) but don't see a problem with the setup, that seems to be the one I selected.
EDIT2: I've found the fuel bug. It only comes up when you are on an open config or in a place like a car park or layout square, where there is no path for a route. That explains why the bug wasn't found in previous test patch. It's start fuel, pit fuel, tyre change wear, pit repair option.
Last edited by Scawen, .
Since the previous report in March there have been various updates. Most of the time I have worked on LFS but also had to do a few things outside of LFS.
I'm not sure how interesting it is but I can look through the list of updates I sent to Eric and add a few comments.
Towards end of March:
I worked on the render modes, which were kind of a mess and it took a while to reorganise the code a bit.
In the end I came up with 3 render modes: basic / SDR / HDR:
- basic: straight to backbuffer, no antialiasing / exposure / tonemapping
(good for lower-end GPU, uses exposure estimate based on time of day - not good in tunnels or car parks)
- SDR: uses SDR render targets, does antialiasing and exposure, no bloom or tonemapping
(exposure calculation is good but there is no glow around lights and no tonemapping to help with bright sky)
- HDR: visually the same as recent versions but now adding bloom and tonemapping in a single pass
(our best option for good GPU but there is a hit from the bloom processing and HDR render targets)
New system for different settings between VR and non-VR modes
MSAA settings "none" and 2X options in addition to 4X and 8X
Started to work on the Public build of the new version and had to work on the track selection screen. The limits are worked out differently now so some changes had to be made to align paths with map images.
Early April:
Retro tyre model:
FIX: Retro model was heating up tyres too quickly in longitudinal skids
FIX: Retro model could cause a crash with wheelspin at low speed
Implemented skid darkness from New model into Retro model
Both tyre models:
Smoke update - calculated only immediately (without temperature build-up)
Doubled intensity of dust (from dusty surfaces)
Removed the "skin temperature" thin edge on outer surface as no longer needed
Render modes:
Code cleanup allowed only downsize as much as needed for exposure in SDR mode
FIX: screen was sometimes not cleared for a few frames e.g. after pressing V
Vehicle editor:
FIX: Z buffer was not disabled when drawing wheel cross-section
FIX: Tyre cross-section was not shown if Retro model selected
Cars:
LX6 - restored public version tyre size
LX4 - restored public version tyre size / mass / engine power
Towards mid-April:
Shaders:
New compute shader included [think this was for the exposure histogram]
Exposure:
Dashboard brightness now constant regardless of exposure
Avoided black frames when changing views with V or TAB in game
- the black frames were while exposure was calculated on a hidden image
- now the screen is simply not updated during those few frames
Reduced overexposure after TAB/V/restart from dark place (e.g. tunnel)
- initial exposure attempt was then worked out from a whited out image
- the overexposed image didn't show the true excessive brightness
- issues are solved by targeting a standard brightness (after TAB/V)
Exposure is also reset and recalculated when switching Render mode
Exposure is also reset on entering or leaving Free view mode
More accurate histogram (now 256 bins - see in CTRL+E)
Graphics:
FIX: Corrupted lighting (normals) on 3D spectators with scale > 1
Misc:
Faster load of Octree when track is loading
Added progress percent for "Generating" stage
AI:
FIX: Divide by zero updating path for AI in EV (e.g. Formula XR-E @ BL1)
Early May:
I had some distractions in the second half of April but in early May sent another update:
VR: Avoided black frames when tabbing between cars in "TV in VR" view
Avoid debug message about DEFAULT lighting when car drawn as physics LOD
Added Misc option to show ms/frame instead of FPS (removed SHIFT+F5 key)
OPT: avoided setting main render target multiple times per frame
FIX: avoiding mysterious crash in SetForce after losing full screen
OUT OF BOUNDS now displayed if the spawn point is out of bounds
OPT: improved main render function saving around 0.2 - 0.3 ms per frame
FIX: Jittery freeview camera (graphics now synchronised with physics)
Summary:
I'm not intending this to try to stir up conversations, but more to illustrate all the small things I have to work on, in order to get the version finished. Most of these things, you (and I too) probably wouldn't think of but it takes a while to get everything ready after so many changes have been made in the program.
D3D11, HDR graphics, dynamic lighting, 1000 Hz physics, shadow maps, multithreading, non-path-based occlusion culling have meant a lot of changes throughout the program and while trying to get things finished, I keep encountering new things that have not been considered, or were thought of as "fix that small thing near the end" but then it is a bit harder to fix than expected.
Ongoing:
I still have to do some more work for certain headlight issues, add some weather options, finish building a releasable public version and whatever comes up in the meantime.
Eric has been doing some more work on South City and has to complete Kyoto Ring where there are still some holes around.
We still can't give a time estimate, we'll just keep doing the important things until it's ready for testing.
I'm not sure how interesting it is but I can look through the list of updates I sent to Eric and add a few comments.
Towards end of March:
I worked on the render modes, which were kind of a mess and it took a while to reorganise the code a bit.
In the end I came up with 3 render modes: basic / SDR / HDR:
- basic: straight to backbuffer, no antialiasing / exposure / tonemapping
(good for lower-end GPU, uses exposure estimate based on time of day - not good in tunnels or car parks)
- SDR: uses SDR render targets, does antialiasing and exposure, no bloom or tonemapping
(exposure calculation is good but there is no glow around lights and no tonemapping to help with bright sky)
- HDR: visually the same as recent versions but now adding bloom and tonemapping in a single pass
(our best option for good GPU but there is a hit from the bloom processing and HDR render targets)
New system for different settings between VR and non-VR modes
MSAA settings "none" and 2X options in addition to 4X and 8X
Started to work on the Public build of the new version and had to work on the track selection screen. The limits are worked out differently now so some changes had to be made to align paths with map images.
Early April:
Retro tyre model:
FIX: Retro model was heating up tyres too quickly in longitudinal skids
FIX: Retro model could cause a crash with wheelspin at low speed
Implemented skid darkness from New model into Retro model
Both tyre models:
Smoke update - calculated only immediately (without temperature build-up)
Doubled intensity of dust (from dusty surfaces)
Removed the "skin temperature" thin edge on outer surface as no longer needed
Render modes:
Code cleanup allowed only downsize as much as needed for exposure in SDR mode
FIX: screen was sometimes not cleared for a few frames e.g. after pressing V
Vehicle editor:
FIX: Z buffer was not disabled when drawing wheel cross-section
FIX: Tyre cross-section was not shown if Retro model selected
Cars:
LX6 - restored public version tyre size
LX4 - restored public version tyre size / mass / engine power
Towards mid-April:
Shaders:
New compute shader included [think this was for the exposure histogram]
Exposure:
Dashboard brightness now constant regardless of exposure
Avoided black frames when changing views with V or TAB in game
- the black frames were while exposure was calculated on a hidden image
- now the screen is simply not updated during those few frames
Reduced overexposure after TAB/V/restart from dark place (e.g. tunnel)
- initial exposure attempt was then worked out from a whited out image
- the overexposed image didn't show the true excessive brightness
- issues are solved by targeting a standard brightness (after TAB/V)
Exposure is also reset and recalculated when switching Render mode
Exposure is also reset on entering or leaving Free view mode
More accurate histogram (now 256 bins - see in CTRL+E)
Graphics:
FIX: Corrupted lighting (normals) on 3D spectators with scale > 1
Misc:
Faster load of Octree when track is loading
Added progress percent for "Generating" stage
AI:
FIX: Divide by zero updating path for AI in EV (e.g. Formula XR-E @ BL1)
Early May:
I had some distractions in the second half of April but in early May sent another update:
VR: Avoided black frames when tabbing between cars in "TV in VR" view
Avoid debug message about DEFAULT lighting when car drawn as physics LOD
Added Misc option to show ms/frame instead of FPS (removed SHIFT+F5 key)
OPT: avoided setting main render target multiple times per frame
FIX: avoiding mysterious crash in SetForce after losing full screen
OUT OF BOUNDS now displayed if the spawn point is out of bounds
OPT: improved main render function saving around 0.2 - 0.3 ms per frame
FIX: Jittery freeview camera (graphics now synchronised with physics)
Summary:
I'm not intending this to try to stir up conversations, but more to illustrate all the small things I have to work on, in order to get the version finished. Most of these things, you (and I too) probably wouldn't think of but it takes a while to get everything ready after so many changes have been made in the program.
D3D11, HDR graphics, dynamic lighting, 1000 Hz physics, shadow maps, multithreading, non-path-based occlusion culling have meant a lot of changes throughout the program and while trying to get things finished, I keep encountering new things that have not been considered, or were thought of as "fix that small thing near the end" but then it is a bit harder to fix than expected.
Ongoing:
I still have to do some more work for certain headlight issues, add some weather options, finish building a releasable public version and whatever comes up in the meantime.
Eric has been doing some more work on South City and has to complete Kyoto Ring where there are still some holes around.
We still can't give a time estimate, we'll just keep doing the important things until it's ready for testing.
I guess it could be OK, if forces view is not applied to object mods.
I wonder if forces view should only apply to the currently viewed vehicle, instead of all vehicles?
I wonder if forces view should only apply to the currently viewed vehicle, instead of all vehicles?
Improved support for Track Mods
Hello LFS mods users.
We have allowed through review a few "track mods" which use an "object" mod to represent the scenery of a track.
A small central physics object (LOD2 or LOD3) is created and sits on the ground, while LOD1 represents the scenery. There was a problem with the scenery disappearing if the viewpoint was too far from the origin.
Mod creators were able to get around this by using a hacked LOD distance, but we don't want to allow such hacks. It's better to release a fix for the issue.
At the same time, I had a note on my list for the development version about a bad calculation for the view radius of some mod vehicles with subobjects (that has become a problem since the addition of moving subobjects).
Two of these track mods have been waiting to be published and it seemed a good idea to help them and solve the view radius problem at the same time.
Now, the distance from an object is calculated as the distance from the object's bounding sphere instead of the distance from the object centre, which solves the problem. It is impossible for a lower LOD to be selected if you are within the bounding sphere of LOD1.
If you would like to join a server that has a track mod, you should use the new test patch 0.7F7 (or later) available in the test patch forum:
https://www.lfs.net/forum/thread/110607
If you are developing a track mod you should use the new editor test patch 0.7F7 available in the mods forum:
https://www.lfs.net/forum/thread/111321
Future development possibilities:
The track mod support is not very good at this time. It is a bit obscure as a player needs to "drive" the track mod and it has to enter as a physics object and settle on the ground. Our mods system was obviously designed for vehicles only. It would be nice to properly support such objects in the future, for example:
1) A new object type "solid" or "track" which does not enter physics at all and cannot move
2) Increased number of collision triangles for unmovable objects
3) Place a track mod as a layout object instead of using a player slot and start position
Examples (1) and (2) look quite easy to add (in an incompatible version) while (3) is a lot more complicated.
There is no time to develop such features at the moment. I am just pointing out that there is a possible future for track mods that goes beyond this current minor improvement. Track mods might not have to be a whole track but could be a bridge, a podium, or some other type of stationary object.
We have allowed through review a few "track mods" which use an "object" mod to represent the scenery of a track.
A small central physics object (LOD2 or LOD3) is created and sits on the ground, while LOD1 represents the scenery. There was a problem with the scenery disappearing if the viewpoint was too far from the origin.
Mod creators were able to get around this by using a hacked LOD distance, but we don't want to allow such hacks. It's better to release a fix for the issue.
At the same time, I had a note on my list for the development version about a bad calculation for the view radius of some mod vehicles with subobjects (that has become a problem since the addition of moving subobjects).
Two of these track mods have been waiting to be published and it seemed a good idea to help them and solve the view radius problem at the same time.
Now, the distance from an object is calculated as the distance from the object's bounding sphere instead of the distance from the object centre, which solves the problem. It is impossible for a lower LOD to be selected if you are within the bounding sphere of LOD1.
If you would like to join a server that has a track mod, you should use the new test patch 0.7F7 (or later) available in the test patch forum:
https://www.lfs.net/forum/thread/110607
If you are developing a track mod you should use the new editor test patch 0.7F7 available in the mods forum:
https://www.lfs.net/forum/thread/111321
Future development possibilities:
The track mod support is not very good at this time. It is a bit obscure as a player needs to "drive" the track mod and it has to enter as a physics object and settle on the ground. Our mods system was obviously designed for vehicles only. It would be nice to properly support such objects in the future, for example:
1) A new object type "solid" or "track" which does not enter physics at all and cannot move
2) Increased number of collision triangles for unmovable objects
3) Place a track mod as a layout object instead of using a player slot and start position
Examples (1) and (2) look quite easy to add (in an incompatible version) while (3) is a lot more complicated.
There is no time to develop such features at the moment. I am just pointing out that there is a possible future for track mods that goes beyond this current minor improvement. Track mods might not have to be a whole track but could be a bridge, a podium, or some other type of stationary object.
Last edited by Scawen, .
LFS Editor Patch 0.7F11
Hello Mod Creators,
Here is a PATCH for the LFS Editor. Editor 0.7F or later must already be installed!
This is not a thread for random requests regarding the mods system.
For mods suggestions, use the Mods System Suggestions forum section.
This editor patch is a minor update to help support "track mods" and includes a few fixes.
Changes in 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
Changes in 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
Changes in Editor F9:
FIX: Error in moving subobjects after one made invisible by layers
FIX: Object type 'spinner' was not working in Editor F8 (Test inputs)
LX4 - restored public version tyre size / mass / engine power
LX6 - restored public version tyre size
Changes in Editor F8:
FIX: View radius was sometimes reduced unexpectedly in the vehicle editor
Changes in Editor F7:
Improved vehicle view radius calculation (bounding sphere)
- LFS can more accurately detect if a vehicle is currently visible
LOD distance refers to distance from bounding sphere instead of object centre
- previous version did not work well for large objects, e.g. "track mods"
NOTE: This version of the editor actually uses the "RETRO" tyre model
- this is not expected to result in any noticeable changes in the editor
DOWNLOAD:
LFS Editor PATCH 7F to 7F11 [If you already have LFS Editor 0.7F or later]
Editor 0.7F or later must already be installed!
https://www.lfs.net/file_lfs.php?name=LFS_EDITOR_PATCH_7F_TO_7F11.zip (1.6 MB)
Here is a PATCH for the LFS Editor. Editor 0.7F or later must already be installed!
This is not a thread for random requests regarding the mods system.
For mods suggestions, use the Mods System Suggestions forum section.
This editor patch is a minor update to help support "track mods" and includes a few fixes.
Changes in 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
Changes in 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
Changes in Editor F9:
FIX: Error in moving subobjects after one made invisible by layers
FIX: Object type 'spinner' was not working in Editor F8 (Test inputs)
LX4 - restored public version tyre size / mass / engine power
LX6 - restored public version tyre size
Changes in Editor F8:
FIX: View radius was sometimes reduced unexpectedly in the vehicle editor
Changes in Editor F7:
Improved vehicle view radius calculation (bounding sphere)
- LFS can more accurately detect if a vehicle is currently visible
LOD distance refers to distance from bounding sphere instead of object centre
- previous version did not work well for large objects, e.g. "track mods"
NOTE: This version of the editor actually uses the "RETRO" tyre model
- this is not expected to result in any noticeable changes in the editor
DOWNLOAD:
LFS Editor PATCH 7F to 7F11 [If you already have LFS Editor 0.7F or later]
Editor 0.7F or later must already be installed!
https://www.lfs.net/file_lfs.php?name=LFS_EDITOR_PATCH_7F_TO_7F11.zip (1.6 MB)
Last edited by Scawen, .
Thanks, I reproduced this and it does also occur in the new version.
I'll make a note to consider it but I guess not with high priority.
Does anyone know if wheels sometimes drop underground at these locations?
I'll make a note to consider it but I guess not with high priority.
Does anyone know if wheels sometimes drop underground at these locations?
If someone could provide a very simple way to reproduce this (hopefully with a single object) then I could have a look to see if the same bug still exists in new LFS.
Thank you, we noticed this yesterday and Victor fixed it.
Maybe it could be:
The mods stored on the server and downloaded to LFS could be in an encrypted form that LFS game can read but LFS editor cannot read.
Then the only legitimate way to load things into your editor is by downloading the mod manually in editor form (not encrypted) via legitimate means, e.g. from mod's page when it allows derivatives, or direct from the author.
Problems with this:
1) All the mods currently on the server are in editor form and not ready to be downloaded in the proposed format. So a big switchover operation might be needed.
2) As mentioned before, this type of encryption, that anyone's S3 license can decrypt, can be easily cracked. Someone would release a decryption tool for encrypted mods, to convert game-ready mods into editor mods.
I don't know if this low level of security would be enough. It's not something I'll be doing in the near future though as you know what I am still working on.
The mods stored on the server and downloaded to LFS could be in an encrypted form that LFS game can read but LFS editor cannot read.
Then the only legitimate way to load things into your editor is by downloading the mod manually in editor form (not encrypted) via legitimate means, e.g. from mod's page when it allows derivatives, or direct from the author.
Problems with this:
1) All the mods currently on the server are in editor form and not ready to be downloaded in the proposed format. So a big switchover operation might be needed.
2) As mentioned before, this type of encryption, that anyone's S3 license can decrypt, can be easily cracked. Someone would release a decryption tool for encrypted mods, to convert game-ready mods into editor mods.
I don't know if this low level of security would be enough. It's not something I'll be doing in the near future though as you know what I am still working on.
I guess I'll have to go on thinking over time, as it appears the simple function is too controversial without other security measures, but those security measures are a much more complicated subject.
Maybe it's more like, the simple function should be in there, as a simple function and without its own security measures, but the protected model itself should be prevented from loading into the editor by unauthorised people.
But that is a whole new level of complication and I don't have any time to start trying to figure that out.
I also know in advance that is the least satisfying type of work, if I ever do it, I would have to work for many hours or days implementing things into the editor, the web server, the game, and all the while knowing that hackers will easily flip the switch, undo the encryption, etc. Setting out on a task that you know for certain will fail is never very enticing.
Maybe it's more like, the simple function should be in there, as a simple function and without its own security measures, but the protected model itself should be prevented from loading into the editor by unauthorised people.
But that is a whole new level of complication and I don't have any time to start trying to figure that out.
I also know in advance that is the least satisfying type of work, if I ever do it, I would have to work for many hours or days implementing things into the editor, the web server, the game, and all the while knowing that hackers will easily flip the switch, undo the encryption, etc. Setting out on a task that you know for certain will fail is never very enticing.
This seems impractical, I'm just talking about a simple function to export an OBJ. I can't even start to think how the suggestion could be implemented, somehow with the Editor connected online and having knowledge of where every model came from, and even track that if they saved out and reloaded the model? It's not really possible, I think.
This is only about a simple export from the modeller. As far as I know, this is a common feature for 3D software and I'm not sure if LFS Editor should be different.
I'm interested to understand what is the main concern.
Of course, LFS models can already be easily saved for reload in LFS editor.
So what is the main worry, is it that people might rip LFS mods and use them in other games?
(Although they can do it anyway but the new feature would make it easier to save a clean model)
I've asked the mod reviewers about this but we didn't come to any strong conclusions.
I'd like to consider a simple (and limited) exporter to OBJ format, from LFS editor, that allows the plain grey model to be loaded into other 3D software.
It wouldn't export the mappings. Our type of mapping isn't supported in the OBJ format. Although I think it is possible (but not really easy to code) to export mapped models, there is no way to read LFS style mappings from an OBJ model. So from LFS editor point of view it's not worth coding to export with textures at this time.
Although I haven't looked in detail, I think it is simple enough to allow an OBJ export of the points, triangles and normals. I understand this could be useful and I wouldn't mind doing a few hours on that at some point.
So we are left with, what problems could arise? The only issue I see is that someone could load a mod in our editor and export the plain grey model, which might be a breach of someone's "no derivatives" license. The proposed export function just makes it easier to get a 3D model out from an LFS mod, to be used somewhere else. It doesn't really allow anything that wasn't possible anyway, just makes it easier.
I'd like to consider a simple (and limited) exporter to OBJ format, from LFS editor, that allows the plain grey model to be loaded into other 3D software.
It wouldn't export the mappings. Our type of mapping isn't supported in the OBJ format. Although I think it is possible (but not really easy to code) to export mapped models, there is no way to read LFS style mappings from an OBJ model. So from LFS editor point of view it's not worth coding to export with textures at this time.
Although I haven't looked in detail, I think it is simple enough to allow an OBJ export of the points, triangles and normals. I understand this could be useful and I wouldn't mind doing a few hours on that at some point.
So we are left with, what problems could arise? The only issue I see is that someone could load a mod in our editor and export the plain grey model, which might be a breach of someone's "no derivatives" license. The proposed export function just makes it easier to get a 3D model out from an LFS mod, to be used somewhere else. It doesn't really allow anything that wasn't possible anyway, just makes it easier.
You click the function on the left, then select the axis to assign it to.
E.g. want to assign steering wheel.
- click "Steer"
- move steering wheel so you see which axis is the steering wheel
- click that axis (on the right)
E.g. want to assign steering wheel.
- click "Steer"
- move steering wheel so you see which axis is the steering wheel
- click that axis (on the right)
Maybe at some point I can summon the motivation to add a column to the table that allows individual ones to be deleted. Some investigation will be needed, for instance do all those duplicates refer to the same hotlap file (in which case only the table entries would be removed) or is the file itself duplicated (in which case each instance could have the full delete procedure).
Without knowledge of what happens behind the scenes, it looks like hours of investigation, webcoding and testing, so it's probably best for me not to stop the other things I am working on, unless at some point I experience a great feeling of motivation to go and work on LFSW code.
Without knowledge of what happens behind the scenes, it looks like hours of investigation, webcoding and testing, so it's probably best for me not to stop the other things I am working on, unless at some point I experience a great feeling of motivation to go and work on LFSW code.
Thanks for the info. I guess maybe you had to delete them both and then re-upload?
I'll explain why I am saying that:
I uploaded a hotlap, but at first couldn't see how to delete it.
I had to click on "Racer details" and there is a list of hotlaps, including a 'Del' link.
But if I have a look at xolan1993's page, there is only one reference to the hotlap which is actually duplicated (BL historic / FO8). So I guess it may be impossible for him to delete only one instance of it?
https://www.lfsworld.net/?win=hotlaps&whichTab=details&racer=xolan1993
Maybe we need a delete button in the table where you can see the duplicates, which I could make available for your own hotlaps, and developers could delete any of them so I could easily respond if there is a duplicate in future. I guess this is the only way forward.
I'll explain why I am saying that:
I uploaded a hotlap, but at first couldn't see how to delete it.
I had to click on "Racer details" and there is a list of hotlaps, including a 'Del' link.
But if I have a look at xolan1993's page, there is only one reference to the hotlap which is actually duplicated (BL historic / FO8). So I guess it may be impossible for him to delete only one instance of it?
https://www.lfsworld.net/?win=hotlaps&whichTab=details&racer=xolan1993
Maybe we need a delete button in the table where you can see the duplicates, which I could make available for your own hotlaps, and developers could delete any of them so I could easily respond if there is a duplicate in future. I guess this is the only way forward.
Seems you are determined to get me to look at this. 
A user can delete a hotlap, can't they? So I wonder why they leave duplicates there.
Bug still exists for xolan1993:
BL2 / FO8: https://www.lfsworld.net/?win=hotlaps&whichTab=trackcharts&track=bl&car=FO8&config=historic
...and also for ignacio molina 1:33.95 (currently positions 101 to 108)
BL1 / XRG: https://www.lfsworld.net/?win=hotlaps&whichTab=trackcharts&track=bl&car=XRG&config=gp
...but duplicate hotlap has been deleted for Viper:
SO chicane / FO8: https://www.lfsworld.net/?win=hotlaps&whichTab=trackcharts&track=so&car=FO8&config=chicane
Maybe Viper deleted his duplicate hotlap?
A user can delete a hotlap, can't they? So I wonder why they leave duplicates there.
Bug still exists for xolan1993:
BL2 / FO8: https://www.lfsworld.net/?win=hotlaps&whichTab=trackcharts&track=bl&car=FO8&config=historic
...and also for ignacio molina 1:33.95 (currently positions 101 to 108)
BL1 / XRG: https://www.lfsworld.net/?win=hotlaps&whichTab=trackcharts&track=bl&car=XRG&config=gp
...but duplicate hotlap has been deleted for Viper:
SO chicane / FO8: https://www.lfsworld.net/?win=hotlaps&whichTab=trackcharts&track=so&car=FO8&config=chicane
Maybe Viper deleted his duplicate hotlap?
I removed the link to the photo as it looked really dodgy and I didn't dare to click it.
Maybe you could have a read through instructions here:
https://en.lfsmanual.net/wiki/Options#Controls
If you still have a problem then maybe upload a picture using a legitimate image sharing site.
Maybe you could have a read through instructions here:
https://en.lfsmanual.net/wiki/Options#Controls
If you still have a problem then maybe upload a picture using a legitimate image sharing site.
It could be, when I looked I saw the duplicate hotlap appeared to have a different id, so it should be possible to add a function to delete it, either by a developer or the user.
Is it possible for the user who uploaded it, to delete one of the duplicate hotlaps, or does it not work that way? I'm asking in case you can give me more insight, in case it might save me a few minutes driving and uploading hotlaps.
This thread is not really "General LFS Discussion".
In future please use a more appropriate location, such as the mods in development forum.
I'll close this thread now as it is not of general interest for the community.
In future please use a more appropriate location, such as the mods in development forum.
I'll close this thread now as it is not of general interest for the community.
Last edited by Scawen, .
FGED GREDG RDFGDR GSFDG