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).
Translation of the first part of sebaalfa's first post.
I've removed the remaining posts as it's too far off topic.
I've removed the remaining posts as it's too far off topic.
Does anyone know what percentage of people have:
1) fixed or static IP (in this case, IP ban forces user to use VPN or alternative connection to get around ban)
2) dynamic IP (in this case, user simply restarts router to get new IP address)
In both cases, an IP ban is weak but in the first case there is at least some inconvenience for the banned user. Against users with dynamic IP, an IP ban is of little or no use.
Trying to verify, with an open mind, if IP bans really are that useful, or if they are more just a bit of misplaced hope to the hoster while a disruptive player simply gets a new IP to use with his spare account.
1) fixed or static IP (in this case, IP ban forces user to use VPN or alternative connection to get around ban)
2) dynamic IP (in this case, user simply restarts router to get new IP address)
In both cases, an IP ban is weak but in the first case there is at least some inconvenience for the banned user. Against users with dynamic IP, an IP ban is of little or no use.
Trying to verify, with an open mind, if IP bans really are that useful, or if they are more just a bit of misplaced hope to the hoster while a disruptive player simply gets a new IP to use with his spare account.
Last edited by Scawen, .
I don't actually know, but IP address is often referred to as personal information.
From my point of view, there are definitely some people I would not like to have my IP address.
I guess there is possibility of DDoS of a person's home? And maybe there is a hacking possibility depending if someone has left open ports?
Is that the case? I did wonder about this. As I think many game developers may do their own hosting, as we do now, I wondered if handing out personal data (IP address) of some customers (client racers) to other customers (hosters) was now a thing of the past, and possibly LFS devs were the only nutters freely handing out this information.
I really don't know how it is in other games, so I'd like to hear more about that.
What does this really mean? Are you talking about people who join and crash into people? You say "safety implications" but do you just mean rammers messing up races? How many times has it been that you can't simply get rid of them by an ordinary user name ban? In my previous post I was questioning how you really used IP addresses to solve such a safety issue. Could you post a brief description of a time you have used IP addresses to eliminate a hooligan or someone who affected server safety?
I'm not being sarcastic or anything, I think I need it illustrated by real examples (no actual user names though).
Maybe we should take a look at these, consider each point, how valuable it is and if there could be other solutions.
- When people are using multiple accounts
Yes, this can sometimes be detected by linking one IP address with multiple accounts. But users can get around that by changing IP address (dynamic IP or VPN).
- When people are using VPN
I don't know much about this, can VPN usage be identified from the IP address? And if so, what does that matter?
- When people are sharing one account
Right, when you see the same account on multiple IP addresses. But there are perfectly legitimate reasons why that might be the case so I don't think this is much use.
- When certain IP is sending requests to the server but not connecting (malicious actor)
I don't think this is seen these days, because of how the system works, but correct me if I am wrong.
etc.
Feel free to elaborate.
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?
FGED GREDG RDFGDR GSFDG