Funny that. I was just exactly there and the fence on the opposite side of the access road. Both seem to be solid for me.
I think I've found a workaround for this, and also for those that forget to connect their controller before starting LFS.
Go to options - controls and toggle between mouse/keyboard and wheel/joystick. This seems to reset the controller completely which also allows an undetected controller to be used.
But that will be the whole point of limited setups when they are introduced. My understanding is that server admins will then have the choice to allow full or limited setups to make it fairer.
When tweaks are used - which really is a hack - it starts to get a little more complicated. I guess from Scawens point of view, any bug reports may be rendered invalid because of some artefact that the tweak has introduced.
That's a good point crashgate3.
There was a good discussion on this some time back.
FOV - Sense of Speed
Which started before the introduction of multiple renders that Scawen introduced a few patches ago.
For my single screen rig which has a 17" 5:4 monitor, I have these settings.
7 renders 3-1-3
Main screen FOV 27°
Screen angle 12°
Which yields a total FOV of 149.4°
Values of 25° - 30° give just about the right amount of central detail for picking apexes, and judging distance to car ahead while the increased FOV of 74.7° - 74.7° either side gives a good sense of speed and peripheral vision.
It might seem odd at first, but you quickly become accustomed to it, and in my opinion is quite realistic. The problem here, is the bad distortion using the in car view, but setting custom view with body and wheels off, works really well.
That said, nothing beats a proper curved screen which totally fills your field of view.
There was a good discussion on this some time back.
FOV - Sense of Speed
Which started before the introduction of multiple renders that Scawen introduced a few patches ago.
For my single screen rig which has a 17" 5:4 monitor, I have these settings.
7 renders 3-1-3
Main screen FOV 27°
Screen angle 12°
Which yields a total FOV of 149.4°
Values of 25° - 30° give just about the right amount of central detail for picking apexes, and judging distance to car ahead while the increased FOV of 74.7° - 74.7° either side gives a good sense of speed and peripheral vision.
It might seem odd at first, but you quickly become accustomed to it, and in my opinion is quite realistic. The problem here, is the bad distortion using the in car view, but setting custom view with body and wheels off, works really well.
That said, nothing beats a proper curved screen which totally fills your field of view.
Within that scope, is it possible to disable pit lane infractions for layouts where an autocross start has been placed?
I fully agree that it should work for a full race grid, but sometimes the pit lane can be included in a time trial. The issue I'm having is the speeding penalty where the pit is actually superfluous in these scenarios. Looking at some of the cruise server replays, this is also a problem for them too, and the infraction is reset by resorting to scripting.
That looks promising indeed.
If, and a qualified if at that, we end up with a full set of paths and nodes native to open configs, I would like to see an option/command that disables flags and penalties for truly free roaming. At the moment we still have pit lane infractions which imho could be removed until such a thing happens too.
[OT] I wasn't aware of that, thanks for the pointer. I still maintain it is the hardware developers responsibility, and open standards are needed. Insim/Outsim anyone? Seems Codies have "nearly" followed this and it is very possible for hardware to communicate properly and bidirectionally using these. [/OT]
Nice spot
That is equally interesting, thanks for clearing it up, and I'm glad I could help.
Scawen never said never, just not this patch.
Also, I believe it is incumbent on Logitech to provide a means to control those LED's via their profiler. Every developer should not be expected to cater for every exotic piece of hardware out there, and rather the hardware developers should try and maintain or set some open standards.
Last edited by Squelch, .
Np, it caught me out too. It was pasibrzuch's last comment that made me recheck.
[Edit]
I just looked at first post again, and this feature isn't mentioned. Perhaps Scawen can amend the documentation for Z32? [/edit]
Last edited by Squelch, .
Reason : added postnote
I just retried by firstly following the car, and then locking the view. Backstepping works as expected with doing this.
I believe this is not a bug, but a misunderstanding of this newly introduced feature.
It's worth mentioning, that once the view is locked, any changes made afterwards result in jumping to that locked view when backstepping. To maintain the correct view, toggle the lock.
Nice posts gents.
The field of view becomes very important in the absence of other inputs when driving sims. We simply don't get the cues we have in real life through G forces and the like. As already pointed out, with a narrow <90 FOV we see much more detail in the corners. The problem here is it could be likened to driving with blinkers on. Don't try this at home, but I would bet that if someone tried wearing blinkers and drive, they too would find it difficult to judge speed in real life.
We humans judge our speed through something called optic flow. simply put, that is how fast something moves across our field of vision. A tight FOV loses the peripheral vision we rely on for speed judgment. We might not necessarily look to the immediate sides of the track, but we are aware of it, and this lack of information leads to overspeeding, and perceived lack of handling.
A wide field of view on a flat screen alone does not fill the gaps, and always looks distorted unless a curved screen is also used. It is a very complex matter to try and get a plausible effect on equipment (pc + monitor) that isn't specifically designed for the job.
I would say that while it appears abnormal, it is a result of how those tyres collision faces are made. (no collision faces on the ends perhaps?) They would not normally be expected to be hit from above, and in your replay one of the blue stacks is pushed through the track. This extreme camera angle shows it nicely.
I noticed the same. It seems whenever the replay has to start from the beginning ie back step, that the follow cam is reset.
While this patch series does suit cruising and drifting, I wouldn't say it is exclusively for them. A friend and I like to build rally style special stages or gymkhanas, and the Z3x patches suit this very well.
As for the missing ideal race line and wrong way flags, these cannot possibly be known for all of the combinations that are now available. The AI cannot use open configs either, the paths are just simply not there. As morpha says, it is really up to the driver to know the correct direction.
Thanks for the feedback on this.
I was was just guessing on it being network based by the problem appearing during multiplayer only. I have another possible theory though, and that is related to memory. Is the track completely loaded into memory or streamed? I ask because one of the reports seemed coincidental with other pc activity. My observations (which I dismissed because I was already aware of it) is that some skipping can occur when the machine is under pressure, though nothing as severe as the reports. This seems to happen around the track texture joins, and I'm unsure if this coincides with a track surface join. It may just be a result of what I was doing at the time, but could paging also be a possible culprit? I'm talking a local MP session here and prior to Z30. My remedy is to make sure to close any unneeded background process, which is often stated by most programs, and common sense anyway. More conjecture I know, and this doesn't require a response as I understand you are already busy.
I've played around with the open layouts quite a lot locally. The gantry problem is definitely fixed in both SP and MP for me, and the only possible related issue is the floating/beaching in the gravel trap opposite the new loop at Fern Bay as reported by others.
[edit] And that was a slick repost too
[/edit]
Last edited by Squelch, .
Reason : Response to crack nonsense - removed golfing reference
Those areas would not normally expected to be driven would they?
I've already explained my theory about why it possibly happens, but IMHO these particular ones do not need to be fixed, at least not right now, but maybe as an vestigial artefact of other "race specific" collision fixes. The same goes for the area around the stands.
This is related to the cross sectional area too, but also the direction of "entering" the obstacle (fence)
Many of the LFS objects appear to have one collision face. usually the one facing the track. It's already been said that hitting Armco from the wrong side does strange things, and the same is true for the catch fences. The other problem, is directly related to the cross sectional area it seems. If you hit the obstacle with enough velocity, it is possible to pass through it in between simulation steps. This means that you can end up completely stuck due to not being able to pass back through, or you get fired off into space possibly because of confusion over the force vectors being out of bounds.
Little experiment:
Drive up ramp2 and perform a car reset.
The momentary mid air crossing of the deck before the car lands causes the car to be sent airborne. I believe this same thing happens when we patially pass though an object between simulation frames.
Last edited by Squelch, .
Reason : clarification of point
Have you tried SHIFT+C - Restore controller?
It is suggested somewhere (readme?) that minimising should be avoided, and Shift+F4 used instead.
My controller ffb drops when LFS has been minimised too btw.
I've been thinking about this some more, and also understand your reasoning for the extreme angle demonstration.
My theory is that the problems lies not with the cars collision areas, but with the ramp in your example, and barriers in general. I'm pretty involved with, and familiar with another game (non driving) where there is a similar problem to this. It all revolves around the cross sectional area of the object being collided. Anything thinner than 200mm (scaled) suffers from collision geometry problems. I'm not suggesting the exact same process is happening here, but it looks too familiar.
Perhaps the ramp object could be made into a more solid object. Right now, the deck can be passed under, but if it was to be made into a wedge, the physics detection might have more success. The same goes for barriers - Armco ones in particular now - where the cross section appears only as thick as the actual rendered texture. If the whole barrier had a larger cross section, it would be interesting to see the results.
I'm aware I might be completely talking out of my arse here, but even the wackiest of suggestions can sometimes prompt enlightenment.
I've noticed the same. There is a list of the problems and enhancements that this patch addresses in the first post, can we all please try and stick to replies that involve them only? There is an improvement suggestion sub forum for other stuff.
Last edited by Squelch, .
Reason : speeling
AVG was one of the worst offenders for me, but this was prior to ver 11 where they introduced the suspension of scanning for full screen games. Other anti malware tools that check for suspicious file activity can also cause stuttering in my experience.
Rather than dwell on this and hijack the thread, is it plausible that the jump/skip problem during a multiplayer session could be caused by some other process/network activity? I would ask anyone that experiences this to double check, and at least include this in their report.
Scawen is intimate with the code and might be able to identify the exact mechanism here, however, unless its specifically looked for, it might have just gone unnoticed thus far. The graphical "join" where this happens makes me suspect this could be true, and the new collision changes might just have highlighted it more.
That blows that theory out of the water then.
Thanks for replying. I guessed at single core as this kind of thing might show more with a single core, and a multicore machine could possibly hand off the other activity to a non LFS core. Pure conjecture, but worth exploring all the same.
What about any other possible processes at the same time for you?
Is that reasonable?
Putting the ramps at that angle are hardly by design, and I believe they are the height and angle for a reason.
Adding more collision surfaces will increase the number of computations to detect collisions. LFS is very good at cutting these computations down to the bare minimum, and gives us the tight network coding that allows many drivers at once. There are compromises that we must suffer to enjoy this. No very steep ramps are one of them.
PS. How do you do that anyhow?
Check KY1 in SHIFT+U at the same place. The open configs only removed barriers and objects that are not common to all possible configs.
There is an exception, and that's at Blackwood where the chicane barriers have been specially removed by common request.
If you have access to a USB Wifi device, you could also connect to your network to unlock your machine. The use of a GPRS/3G mobile phone would also work.
Just to clear this up as it has also been mentioned before in this thread. The unlock only works on the machine and OS combination that it's performed on. It is not possible to unlock on one machine and expect that it will work on another. To do so would completely remove the purpose of unlocking, and we'd have people distributing unlocked LFS all over the place.
Looking at both of those replays makes me suspect they are very similar. In the first, the car is flipped up and to the left, and the second the car becomes airborne a couple of times before wiping out. They both have similarities in that it happens at a join in the track (or at least a change in texture) and they appear during a multiplayer session only. The first incident does not appear to have any forces involved, but the second definitely does when forces are viewed.
I postulated before that this might be caused by dropped packets or other networking problem causing a loss of sychronisation, and the report that an antivirus update was also happening during the second incident reminds me of a couple of similar incidents I have had while testing on my LAN. I have noticed in the past that some background processes can severely impact LFS during a multiplayer session, particularly where it coincides with network activity and high disk use. An antivirus update might just qualify in this regard, and even more so if it involves possible firewall changes or activity. The answer is to make sure no other applications or other background processes are running while playing LFS, but its interesting to note the problem appears at joins in the track.
My opinion is that this has possibly been a problem for some time, and has only just been noticed, or because of the recent changes to physics detection the problem has been exacerbated. In my case, I have dismissed this problem as I already knew that my system was under pressure and it didn't warrant further investigation, but it might catch some others unaware. I'd also hazard a guess that both of the systems in those reports are single core too.
Last edited by Squelch, .
Reason : added bits and grammar - speeling
I can confirm the skid marks and ghost collision issues are resolved.
You are absolutely correct
Yes, that is traditionally how individual stages against the clock are run in many motorsports.
I hope we can have open full race starts and the autocross/rally starts as per Boothy and maintain compatibility.
@dawesdust_12
That is some serious switch bounce if it is greater than 250ms. Have you got dodgy hardware, or another purpose in mind?
Last edited by Squelch, .
Reason : additional response
FGED GREDG RDFGDR GSFDG