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.
Although I realise a website bug is annoying, Victor isn't looking at it (it's his code) and I'm not sure it's worth my time to start trying to figure it out, if it's just an occasional hotlap that appears duplicated.
Unless it's more of a problem than I know?
On the other hand, if there is a known way to reproduce this then I could fix it. It's just really hard trying to debug something that happens very rarely, in someone else's code, with no known way to make the bug happen.
For old versions (before the mods) we did release dedicated servers.
But the cracked LFS community running on a pirate master server had grown bigger than the legit community and we didn't earn enough money to live on, which obviously could be a problem in the end.
There was one solution, make something new (mods) and stop releasing the dedicated server software.
It does seem like there isn't enough activity in the USA despite us having a good setup there. LFS seems to be more popular in South America. Hopefully there will be a bit more activity when we release the new update.
It's just a command that doesn't do anything but remains local. It's in the same place that local commands are processed, and does not get sent to the server.
I guess it can be seen in one of the messages that is sent out via InSim so an external program could use it for any purpose.
Our system is really not set up for shadow maps from street lights, the street lights are really just a source for ambient lighting.
Maybe interesting to know that there are two exposures going on.
Other than the image-based exposure that I have been talking about, there is also a calculation based on sun height and sky brightness, which can be used to produce a roughly suitable exposure level in an SDR mode that I am currently still supporting, that doesn't have bloom or analyse the image for exposure. That gives quite reasonable results in the day and might be a helpful option for people with a low powered GPU. That calculation is very simple and done every frame even in the HDR mode (HDR is not for HDR monitors, it's just that internally we process the image using a high dynamic range).
Anyway why I am talking about that, currently that is the value that is used to set the dashboard brightness. Without that, the dashboards were EXTREMELY bright in the night, so it was a quick fix at some point in the past. Anyway as discussed earlier, it's not working well and I might do something based on getting a lighting value from your car's environment map, to simulate a light sensor, or I may take a simpler approach (for now) and just set a direct value, so the dash appears just as it does in current public LFS. I am making decisions to get to release without getting hung up on details. That would be awaiting the better dashboard support where we could allow parts of the dashboard to be illuminated by the environment.
White balance is also based on the time of day rather than the current image. Instead of trying to analyse the image for white balance, it's simpler just to take some good values for day and night. If I used the day white balance in the night, everything would look too yellow, as we are using realistic values for the street lights.
Well here in England, we are quite far North so in May we have short nights and there is a bit of twilight at 3am. I could do a pitch black one but don't think it's really worth it at the moment, though I can make these videos quite quickly.
By the way, I have noticed your other posts. I have tried an ACES filmic shader, might show some comparison screenshots at some point, though personally I don't like it as reality doesn't look like a film, if you see what mean.
I haven't researched enough about AgX, the ones I found did look complicated and all the example shots I saw on the internet just looked like a purple version of the image, so I wasn't sold on the idea. But I'll probably follow your link to see if the simpler version you linked to is of reasonable complexity. At the moment I am using a simple Reinhard shader to reduce the sky whiting out.
I think the tunnel lighting is quite well balanced, compared with the street lighting. Eric has set the lighting values by observation, we haven't gone so detailed as to set watts or lumens per light. But you can judge for yourself in this similar video done in the night.
EDIT: This video time is 03:14 on 4 May so the sky is not pitch dark.
I'm not sure what you mean. Are you referring to a difference between the two versions?
They both have the same rate of adjustment.
The new one uses centre-weighted metering, which has two advantages:
1) Exposure based more on what you are actually looking at, instead of peripheral vision.
2) More stable because peripheral parts often have large bright or dark areas that have a bad effect on exposure.
OK here it is. I think that:
1) The sky brightness fluctuations are reduced a bit before entering the tunnel.
2) Slightly earlier exposure reduction at end of tunnel.
I don't think I can get involved at this time. It may be the people who write video card drivers don't do a lot of testing for Direct3D 9Ex these days, so errors might creep in.
It's better for me to continue spending my time on the D3D11 version that I am developing intensely already.
What changed a few weeks ago? Did you install a new graphics driver at that time? Can you try reverting to an older graphics driver? Nothing changed in LFS, so it sounds to me like a fault in the graphics driver or D3D.
Your thread title says "D3D device error" but you didn't include that in your report. If LFS gives this message it suggests that the instance of Direct3D 9 reported an error and had to be restarted. Could there be a problem with the D3D9 support, which is not used by most games now?
EDIT: It's possible there could be a clue in the deb.log file after the hang, a message including a D3DERR_xxx value.
Something like:
D3D device error : D3DERR_xxx
Maybe the missing part in place of 'xxx' can give us a clue.
Yes I think that should be possible, the two screen assumption could be avoided if the primary monitor rectangle matches the desktop rectangle. I've made a note about it.
Hi, LFS has taken a guess that you have a two screen setup.
You can correct this, in the Options - View screen.
There is an option "Multiple screen layout" where you will see it is set to 1 left screen.
You can set that to zero and then it will work as a single wide screen.
While I am sure your suggestions are sensible, I am not working on the vehicle editor as part of this release. the idea is to get the new version released, so I then have time to work on other things including vehicle editor improvements. Please feel free to post vehicle editor suggestions in the correct forum section: https://www.lfs.net/forum/532
The current plan is to avoid delaying the release for clouds. I love clouds and will miss them in the early versions of new LFS. But it's a big job with many technical difficulties and that's why there will be no clouds at first, although I do want to allow completely overcast (i.e. the whole sky is a cloud).
It's a tricky issue at the moment and that is one thing lacking in the vehicle system at the moment. We really need some way to separate the parts of the dashboard that are illuminated by the environment (in traditional dashboards that are not just a computer screen) and the other parts that are self-illuminated like lights and the modern screens. I'm sure that in real life these modern screens must adjust their brightness a great deal depending on the lighting conditions, to be visible in the day but not completely blinding in the night. In some way, all our dashboards in LFS are self-illuminated like the modern computer screens, so I think they will have to start out light-sensitive and self-adjusting, even if that is unrealistic. Awaiting the more proper dashboard support mentioned above. I've probably not explained myself very well.
It's a completely new system with D3D11 graphics, dynamic lighting, 1000Hz physics, multithreading, dynamic echo rendering. It's not a thing you could release half of.
To be honest that would be a bit like going to your BMW dealer after hearing they are developing a completely new car, and saying, I have lots of money, can you at least sell me the seats, steering wheel and some suspension parts, it would be great, I can stick it in my existing BMW that is from an entirely different era, it'll be no problem.
In fact, the whole thing goes together and has to be in one piece.
[ EDIT:
In case my rubbish analogy makes no sense, I'll say it straight: The new tracks are constructed in a new editor, for a new version of LFS. They cannot be loaded into an old version of LFS that is completely incompatible. And the new lighting system cannot be released without updated tracks. Think of it more like LFS version 2, it's completely different.
Three more points:
1) Many, many, updates from the new version HAVE been copied into the old LFS, just look at the releases of the past few years with so many updates! It's funny how people forget how much has been done in the past few years.
2) The idea is that when the new version is finally released, updates can be done more easily because I don't have to copy the same updates into two different versions of LFS and development can be finally back on track.
3) This development is a huge part of my life. If you are desperate for it to be released, try multiplying that feeling by 1000x and then you may understand how important it is for me to get it released.
There is no plan to release track editor in the near future. It's kind of a long term dream of something that may or may not happen. It would probably be a year or two or more of work like the vehicle mods. It's difficult to even imagine how it could work and the tracks would be distributed. It can't work like the vehicle mods. Anyway, I say this not to start a discussion about the track editor, that I cannot get involved in at this time, but to make sure people don't have false hopes. I simply added a few more features to help Eric use the track editor, as I have been doing for the last 25 years or so.
That message is probably because last time you started LFS, the headset was not connected. We need to see the openvr.log after a successful entry to VR.
In LFS there are only two options, OpenVR and Oculus Rift. I believe OpenVR is the only choice for most headsets, but all the Meta ones can use "Oculus Rift" which I should probably rename. But I'll need to know if it does work on Meta headsets... or maybe the whole option should be deleted.
To select Oculus, start LFS in the normal way (not VR) and then:
Options - View
At top of screen is a 3D button.
Click that button and you can select Oculus Rift.
It would be good to know if that works. If not, then try OpenVR again and you can paste that log result, I'll have a look and see if there are any clues in there.