About the local hostname, I looked into it anyway because I like the idea.
I've implemented it now, as a sort of "undocumented feature".
It only allows up to 15 characters for the hostname. Is that enough? Otherwise I'll need to start checking all the places that field is used.
How it works is this:
For the text entered in "Host IP address" on "Join Specific Host" screen, it checks to see if it contains a character other than 0-9 or '.' and in that case it guesses it is a hostname rather than an IP address. So it calls the "gethostbyname" sockets function to get the IP address from the name. If it finds the name then it checks if it's a local IP address as usual.
EDIT: By the way, I am talking about the "host name" of the local computer, not the host name (server name) specified in LFS. Without any use of master server, the only available name to connect locally is the local name of your computer as seen on your local network.
I've updated that, but probably won't list it in the U5 patch notes. Please can you check it looks correct in context when the patch is released?
I've done the IP display.
About alowing to connect locally using hostname (Pasci's request) I could do without any extra complication right now as I'm still working on things in the development version. Even though it's probably easy.
Well this is something I just don't want in my head at the moment at all. Any sound improvements would be a several weeks/months project and the current sound quality doesn't prevent us releasing the new graphical improvements.
Thanks. I've noticed a bug - when your car is sideways or upside-down, you will find in VR that moving left/right/up/down has the wrong effect. Also the mirror views are messed up in that case. The more sideways, the worse the effect.
I've fixed it in my version and hope to release another minor test patch tomorrow.
Thanks, maybe I'll change this myself if a translator doesn't notice it.
I think what I can do is show on the host screen, the local IP address(es) so it's easier to know what to type in on the guests. Would that help, so you don't need to run cmd and type ipconfig? I've done that in the development version already so can probably copy it over.
I do hope the new tyre physics can be released with the new graphics, otherwise I'll have to move a copy of the old physics into the new version. We are long past the point where the new graphical changes could be merged into the old version. Too much has changed.
Copying old physics into the new version is possible but it's not what I want to do.
At the moment I am trying to get the lighting to a reasonable state where it can be left for a while so i can sort out the tyre physics.
No, but what I am saying is that a good tyre physics model should produce a tyre that reacts in a reasonable way, similar to a real world tyre. So it should be able to reasonably simulate a lorry.
This feels like a communication breakdown. You are imagining that the karts would work OK in the current tyre physics, but I'm saying I've tried it and they don't. There are strange effects that produce the wrong outcomes.
Karts are very sensitive to tyre physics, particularly so because of the lack of suspension and lack of differential. The tyres are sometimes just touching / not touching the ground and there's a lot of skidding of lightly loaded tyres, particularly on the unloaded inner rear tyre. It just doesn't work properly with the current public tyre physics.
There is a solution, which would allow us to release karts. It's the new tyre physics model, which I'm working on.
Thanks for the offer. I really want to have karts in LFS when possible, and Eric does too as you can see with the kart tracks at Westhill. He likes to work from reference material when possible so your offer is interesting.
It's absolutely impossible to do it before the new tyre physics is working, for two reasons.
1) We can't add another delay to finishing the new tyre physics and graphics, for obvious reasons.
2) Karts don't work properly with the old tyre physics. I have some test karts in LFS and I use them as a test case for tyre physics. In reality, tyre physics works on a range from karts (or smaller) up to giant lorries, but the old LFS tyre model breaks down a bit when you go to those extremes.
So maybe we can talk again when the time comes. I can't give any estimates about when that might be.
The only sort of deal we can do is to put a car (or kart) in LFS without payments either way. We receive the reference materials / photos / drawings / 3D files / a lot of information about the setup and permission to use a real vehicle (without time limit). The vehicle provider gets some exposure in return, and that's about it.
We can't commit to anything at the moment, but it's an interesting thought.
The pit garage lighting is baked in vertex lighting, like the current public version but generated a bit more accurately. One of the tasks on my list is to separate the baked in lights that are always on (pit garages) and the ones that are only on in the night (floodlights / street lights). Also the way the lighting varies at the moment is just made up, but needs to more closely follow physical values.
Fair question, and I've already made a note about it after nacim mentioned it on another thread.
I'm interested to try it at some point and see how it looks but not really in a hurry to do it right now because I'm really busy trying to get some things finished in the development version. It's the sort of thing that would take a couple of days to think it through and get it working well and not clashing with other things.
The cool thing is how your comment, although you were talking about the 'old' shadows, got me into this anisotropic filtering experiment (that was on one of my lists) for the new shadows. It has resulted in a real improvement. See the before and after comparison in the attached shots. I implemented Andrew Lauritzen's fix for the glitch at cascade boundaries.
Do you mean the car shadows? I'll have a quick go at switching on anisotropic filtering for them. I've been experimenting with that on the new shadow system where there is a similar problem (but worse). Anisotropic filtering helps though I haven't yet dealt with the well known issue that comes up at the seam between two cascades. I can fix it by a brute force method but I'll be having a look at the other two documented solutions.
EDIT: I've tried that on the public version car shadows and it is helpful, in VR and not. So I'll include that. The car shadows will use the user setting for anisotropic filtering. There are no cascades to mess things up.
Yes that is hard to see, I managed to see the difference along the top of a light object against a dark background. It got rid of some faint ripples that were there with 4x. But as you say the supersampling was a lot more useful.
EDIT: Attached a screenshot. The top of that wall across the middle of the picture is a good example of the difference between 4xAA and 8xAA.