Set your LFS and G27 rotation to be the same (minimum 720 degrees*), and in LFS set wheel turn compensation to 1.0.
If you've done it right, your G27 will match every car in LFS 1:1. The only downside is that you'll loose the FFB soft stops in several cars, so beyond full lock your wheel will keep turning and FFB will be a bit weird.
*Side note for people from the future: VWS is 900 degrees, so you'll need 900 instead of 720
If you've done it right, your G27 will match every car in LFS 1:1. The only downside is that you'll loose the FFB soft stops in several cars, so beyond full lock your wheel will keep turning and FFB will be a bit weird.
*Side note for people from the future: VWS is 900 degrees, so you'll need 900 instead of 720
Is that through wine or natively? CS:GO is native on Linux & Mac, using OpenGL instead of DirectX - it will run slightly better than on Windows in some hardware/driver configurations, whereas DirectX via wine will in theory always be slower to some extent. Again, how much slower depends on the game/wine version/hw/drivers.
The node values in InSim would probably be pretty good for lap percentage actually. IIRC they were generated by driving the track and logging position every 0.2s. They can be a bit out in places due to cars' different acceleration/braking performance though.
In LFS, the outer physics loop (currently) runs at 100Hz. There is (again, currently) no interpolation between physics updates. Therefore no position updates of the cars/view/whatever will happen more often than 100Hz, so if you render faster than 100fps you will get duplicate frames.
Go watch a replay at 0.125 speed and the effect will be obvious.
Ah, I remember seeing that now. Forgot about it then noticed it while doing some skin stuff the other week.
Mind like a sieve and all that...
No AF on car skins
Speaking of AF, I noticed something weird with skin rendering since 6F3.
The top image is from 6F (6F2 is the same) and the bottom one is from 6F6 (6F3 and above are the same).
In this particular case, the vertical lines are blurred, but it affects any detailed skin when viewed from a shallow angle.
All graphics settings are the same, only difference is the exe. AA & AF are at maximum.
If I turn off AF on 6F, it looks the same as 6F3+, so I assume AF isn't being applied to car skins for some reason.
The top image is from 6F (6F2 is the same) and the bottom one is from 6F6 (6F3 and above are the same).
In this particular case, the vertical lines are blurred, but it affects any detailed skin when viewed from a shallow angle.
All graphics settings are the same, only difference is the exe. AA & AF are at maximum.
If I turn off AF on 6F, it looks the same as 6F3+, so I assume AF isn't being applied to car skins for some reason.
Last edited by Degats, .
I made an imagemagick script for that; feed it a 2048 png and it'll spit out a high quality 2048 jpg for LFS and the best quality 1024 jpg that'll fit in 400kb for LFSW.
It'd be nice if I could upload 512 ones as well, because I'm sure I could generate something with better quality than the smudge that LFSW comes out with - I have the CPU cycles to burn to do that, not something I'd expect LFSW to spend the time doing.
Product means content level, ie Demo/S1/S2, that's pretty much what I meant by content.
If I understand correctly, the server mode restricts the specific content that can be loaded on that server. As it's fairly common for InSim to be setting things like cars & track (yes, even client side InSim if it's a helper program for admins) it would be important for an InSim app with that functionality to be aware of what can and can't be loaded.
I guess it could be useful to have an additional field to report the licence level of a client, but the two would certainly mean different things.
(Either way, we're getting rather off-topic here
)I assume it reports the level of content that is available at that time. If you're connected to a demo server, there's no point in the InSim trying to do something with S1/S2 content that it has no access to.
Knowing the /mode setting of the server could be useful to automatically reduce functionality of the InSim app to what is actually usable.
There is no vibration as such on the G27, or LFS for that matter; it's all FFB.
And no, it's not possible to disable some sources of FFB in LFS, because it's all simulated based on forces in the steering rack.
The best way to stop what you describe is to not hit anything
And no, it's not possible to disable some sources of FFB in LFS, because it's all simulated based on forces in the steering rack.
The best way to stop what you describe is to not hit anything
The absence of recovery trucks for endurance racing would be a prime example I think - wait a couple of laps and spawn a stranded car back in the pitlane somewhere for them to do whatever repairs they want/need. Yes, the pitlane command kinda does that already, but that fixes damage as well which isn't always a good thing, especially as things like engine damage can't be repaired in a pitstop.
Another use might be some of the stunt based layouts where it's easy to get stuck somewhere where the normal reset doesn't help at all. A few safe places for the InSim to reset the car to, especially keeping damage, would be pretty good for that.
IMO it would be a bad idea to be able to spawn a player who isn't already on track somewhere, as there's a good chance they won't be ready for it - the act of joining the track would be a clear indication that the player is ready to drive and can then be used to trigger an InSim app to move the car.
There's also the complication that the player/car isn't in a known good state until they're actually on track. You have no idea what car/setup/skin etc they have.
16bit programs won't run under 64bit windows, even XP/2003 http://support.microsoft.com/kb/896458
This used to be a fairly common problem, where the software itself was 32bit, but had an old, 16bit installer. The software itself would run fine, you just couldn't install it.
---
One potentially relevant thing I noticed while researching SM2 v SM3, is that it was rare for SM2 cards to have more than 256MB RAM, and often only 128MB. This probably isn't much of a problem currently, but if the new Westhill is using more/higher res textures then it might become an issue. I don't know the specific numbers of cards still in use, but based on what was available >256MB didn't really become common until SM3.
Also to echo someone else here - provided you have a PCIe capable motherboard (again, circa 2004; seems to have been a big shift in all types of hardware around then) you can pick up a new 1GB GPU for £20 that'll monster any DX9c era card (it'll even run Crysis at medium-high).
---
Regarding the shader issue in Linux, I had already installed D3DX9_43 (d3dcompiler_43.dll, d3dx9_43.dll) using winetricks, as someone had suggested in the 0.6F threads.
However, there is an option for: "directx9 - MS DirectX 9 (Usually overkill. Try d3dx9_36 first)". I haven't tried installing the full DirectX9 yet or a newer Wine version - I'll try to test over the weekend if I get chance.
It uses the positioning of a couple of potentiometers to emulate button presses, yes (although I can't remember how it distinguishes between 6th and R).
The problems are generally caused by:
1. worn/dirty POTs producing noisy/wrong values (more obvious in the spiky pedal issue).
2. a small, soft-ish metal part scraping along a much larger, harder metal part every shift into, or out of, gears 1/2 or 5/6/R. Said soft metal part is vital for the alignment and eventually gets sanded down after a fair amount of use, causing it to lose alignment and randomly jump out of gear.
In some earlier G25s, some people had wires break because they were too short, but I haven't heard of that problem for a long time, so they probably fixed that one at least.
It might have helped if he'd mentioned auto gearbox and described how to reproduce it then
"going from 5th or other to reverse by itself" sounds just like a *very* common hardware issue, and nothing like the actual problem.
AFAIK, shifting 4->5 isn't really possible currently, because it's operating the same manual gearbox simulation, which *must* go into N to actually change gear.
Ignoring the user's shift requests while it's in the process of operating the gearbox (I think that was your other suggestion) may well be the best way to deal with it. Alternatively, in the case where the autobox was shifting one way and the user requested a shift the other; abort the current shift operation and shift in the direction the user requested (eg auto tries to shift 3->2 and the user requested an upshift it should shift 3->4 instead). This may be more intuitive rather than just ignoring the input regardless.
Last edited by Degats, .
Sounds like the infamous "Crap Logitech Hardware Bug" that's been causing problems with G25s and G27s for years now.
In all seriousness, what you describe sounds exactly like the problems the G25/G27 shifter has, caused by worn and/or dirty components (some parts are very poorly designed).
I personally have never heard of any shifting issues unique to LFS.
I seem to have the same shader issue in Linux. Mine throws an error message though, which might help (see attached).
OS: 3.13.0-32-generic, Xubuntu 14.04 x64
Wine: 1.6.2
GPU: Kaveri (APU) R7 200 Series, fglrx (proprietary driver)
I've yet to try the open source driver.
OS: 3.13.0-32-generic, Xubuntu 14.04 x64
Wine: 1.6.2
GPU: Kaveri (APU) R7 200 Series, fglrx (proprietary driver)
I've yet to try the open source driver.
The vast majority of LCD monitors are still only 60-75Hz max. 120Hz CRTs used to be fairly common (at lower resolutions at least), but mainstream LCDs still haven't caught up.
The main reason for the 100Hz limit is because that's what the outer physics loop runs at. There's generally no point, other than for sync reasons, to run any faster than that as things will only change on screen at max 100Hz.
Sure, you can brag you're running at 300FPS, but only 1 in 3 frames will actually be different, so all you're doing is stressing your GPU and wasting power.
My best guess so far
(most of it worked out yesterday, but I just spotted something extra in one of the screens a few mins ago)
Colour code:
Black - Original
Red - New, with good views from the screens. I'm pretty sure I'm close
Blue - Wild guess, I haven't spotted any decent clues yet. Not sure where else National would go though
Yellow - I'm pretty sure this has been re-profiled a little, but I haven't attempted to work it out yet.
(sorry for the garish colours
)
(most of it worked out yesterday, but I just spotted something extra in one of the screens a few mins ago)
Colour code:
Black - Original
Red - New, with good views from the screens. I'm pretty sure I'm close
Blue - Wild guess, I haven't spotted any decent clues yet. Not sure where else National would go though
Yellow - I'm pretty sure this has been re-profiled a little, but I haven't attempted to work it out yet.
(sorry for the garish colours
)This has always happened after anything to do with the control input has changed - the update probably triggered it, but it always happens to me after I run LFS without my wheel in or a different controller.
As Daniel already said, go to axis options, hit recalibrate, move all axis to the full extents then hit lock. This will save the calibration until whatever caused it happens again (which will be very rare if you always have the wheel plugged in before starting LFS).
It seems to run fine in wine (1.6.2) for me, after installing the dll.
Framerate seems to be same/slightly better with dx9 (50-90FPS on an empty track), even with AA'd mirrors.
AMD A10-7700K APU using onboard graphics, I did find that the official AMD driver works better than the open source one on this machine so far (several games, not just LFS).
Framerate seems to be same/slightly better with dx9 (50-90FPS on an empty track), even with AA'd mirrors.
AMD A10-7700K APU using onboard graphics, I did find that the official AMD driver works better than the open source one on this machine so far (several games, not just LFS).
Yep, that seems to have fixed it 
Found a bug with the latest DCon:
If the config file has for example "/track=KY3X", KY3 will load instead of KY3X.
Typing "/track KY3X" or "/track=KY3X" in game works fine.
If the config file has for example "/track=KY3X", KY3 will load instead of KY3X.
Typing "/track KY3X" or "/track=KY3X" in game works fine.
On the subject of the DCon, ever since we switched to the DCon on our servers (or possibly the new network code, I can't remember), we've been noticing a *lot* of "UDP ERROR (20) : WOULDBLOCK" messages in the log (number varies usually 20-30) - so many that we can get more WOULDBLOCK messages than anything else when the server is busy or the CPU is running something else as well.
We've tried all sorts of things to solve the issue, including tweaking kernel buffer sizes, but it seems like some other buffer somewhere is somehow getting full for a tiny fraction of a second - it's next to impossible to catch the system buffer with more than a handful of bytes in it because it gets cleared very quickly. Because the buffer seems to be cleared out so fast, there doesn't seem to be any noticeable ill affects other than an almost constant flood of messages in the log.
The cause could be LFS, WINE or something crazy in the custom version of the linux kernel that our host uses, but we gave up trying to solve it ages ago. I'm pretty sure that turning InSim off didn't make a significant difference.
Would it be possible to have an option to remove these messages from the debug log? As I understand it, UDP WOULDBLOCK isn't actually an error anyway and there don't seem to be any problems caused other than the error messages themselves.
As a side note, has anyone else had this issue, or is it just something funky with our server/setup?
(Running 0.6E DCon on Ubuntu 12.04.4 via WINE 1.4, haven't tried this latest DCon version yet, will do later)
We've tried all sorts of things to solve the issue, including tweaking kernel buffer sizes, but it seems like some other buffer somewhere is somehow getting full for a tiny fraction of a second - it's next to impossible to catch the system buffer with more than a handful of bytes in it because it gets cleared very quickly. Because the buffer seems to be cleared out so fast, there doesn't seem to be any noticeable ill affects other than an almost constant flood of messages in the log.
The cause could be LFS, WINE or something crazy in the custom version of the linux kernel that our host uses, but we gave up trying to solve it ages ago. I'm pretty sure that turning InSim off didn't make a significant difference.
Would it be possible to have an option to remove these messages from the debug log? As I understand it, UDP WOULDBLOCK isn't actually an error anyway and there don't seem to be any problems caused other than the error messages themselves.
As a side note, has anyone else had this issue, or is it just something funky with our server/setup?
(Running 0.6E DCon on Ubuntu 12.04.4 via WINE 1.4, haven't tried this latest DCon version yet, will do later)
FGED GREDG RDFGDR GSFDG