LFS_External is dead, for a new project consider InSim.NET instead.

Thank you very much for your time, I believe I can extrapolate a bit from here

Quote from DarkKostas :

I've set delay(both delays cause there are 2 for a strange reason) to 8 and it was still working.

This would suggest that the command rate itself is not a problem which is good news.

Quote from DarkKostas :

I guess it's like that because you also send the force feedback effect. But in LFS you only send RPM effect.

This is a very likely theory which could benefit from further investigation.

Quote from DarkKostas :

Also as i have said, if there are no RPM leds on, there's no FFB on as well. So maybe you have to somehow make the wheel "accept" FFB effect even when you are not sending the RPM one. But this is weird because with FPS limit at 100 fps, everything was working fine...

Could you try to replicate this situation with my tool? You could set the LEDs to be off in both states and increase the FFB delay (the spinbox on the left) to maximum value while keeping the LEDs delay on 8 msecs.

Quote from DarkKostas :

EDIT: I had to install x86 libraries even though i have x64 bit windows.

This is OK as the tool is compiled as 32bit application.

BTW, is it possible to set the LEDs to "irregular" pattern where say only LEDs 1, 3 and 5 are on? (You can click on the LED buttons to toggle the on/off state).

FPS limiter or VSync enabled?

In an attempt to fix the force feedback issue some users reported I created a simple tool to test if the problem is triggered by the control commands being sent too fast.

Usage:
- Download VC++ 2012 libraries here (unless you have them already)
- Download the tool itself here.
- Launch the tool and set up the periodic effect and LEDs. Default settings should be fine for a first test.
- Click "Start", your wheel should begin to periodically turn left and right and the LEDs should start to blink in the pattern you have set.
- Try decreasing the "Update delay" values for both the FFB effect and LEDs and see if you can duplicate the problem.
- "Update delay" values can be edited on the fly, effect parameters and LED patterns cannot, you have to restart the effect.

This tool bypasses the Logitech drivers and sends raw commands to the wheel. Although they are believed to be fine, I take no responsibility for any hardware damage this tool could theoretically cause.

You should take this up to the programmer of the application. We can't really help you without any knowledge of the application.

Quote from deevil :

Why crackers don't get support ?

This forum is run by LFS developers. In fact they use money they earn by selling LFS licenses to run this forum. Using such a forum to get support for a product you've stolen is rather immoral, don't you think?
Other unofficial forums might be in business of assisting crackers, this one is not.

<OT>
FWIW I find the attitude towards crackers on this forum very pleasing. It shows that online communities aren't full of nutcase anarchists with no respect for ownership, copyright and law. Let's not ruin that guys, okay ?
</OT>

1) You have to be a programmer to write your own InSim applications. If you have no or very little idea about programming, you cannot do that. That's why this topic is covered in "LFS Programmers" section of the forum.
2) Get a license, crackers get no support on this forum.

Quote from seniecka :

What's is so stupid or funny about this? A person has problems unlocking LFS. The problem should be solved, but not shown as scoff.

The guy is having problems cracking LFS.

West California:


Buenos Aires:

Geez, this has nothing to do with the continent you're from but with the quality of the connection. I guess the only thing Dave could do is open another server with lower demands on the connection quality. Or maybe if you guys chipped in on a server located in South America and let Dave manage it for you...

Such behavior from a 20 year old guy? Sometimes I think that the world really should have ended on the 21th Dec. Just let it go, okay?

You can get players' IPs from the server log but not via InSim.

Since there is nothing more to be said in topic I thouhgt I'd comment a bit on this "benchmark".

Quote from John5200 :

Here is a nice benchmark with even cheap single core CPU's vs the expensive multi cure and thread CPU's.

This is one helluva idiotic test. DirectX doesn't support multithreaded display lists until version 11 so you cannot really benefit from improved rendering speed on multicore CPUs. GPU drivers are optimized for parallel processing but they can only do so much when the rendering engine is ultimately running as a single thread. The fact that gaming engines yet have to fully embrace the power of parallel processing is one of the reasons why Bulldozer performs so poorly at gaming - there is no point in having 8 cores when the game cannot use more that two. In workloads that can actually take advantage of all available CPU's it performs reasonably well.

BTW there are no threads on the CPU, "logical CPU" is the term you're looking for

Essentially yes, but it's a great learning opportunity. It will be substantially more work, but you will have a chance to avoid any design flaws the currently available cruise InSim applications have...

Testing according to Mercedes:
- Potential fire hazard - Check
- Crash test - Check

What do they have next on the list?

If you're considering running Prime or Linpack to test CPU and RAM, you should probably replace the video card with the backup one to rule out the possibility of the video card crashing your machine during the test.

If you're always getting image corruption like that you posted in the OP, I bet it's the GPU. I highly doubt that a faulty USB driver could cause this.

Reboot your computer and check if there is anything already using that port, some applications like BitTorrent clients like to choose ports randomly.

LFS is not NFS. Modifications to the cars' shape are not supported. It's possible to do that with the right tools, but it's not something a regular user can do. Modified car meshes cause problems when they are used online and discussion of such mods is therefore forbidden by the forum policy.

This sounds like a bug in G27's firmware (or perhaps drivers), but I cannot be sure. I'll probably have to write some sort of testing tool to find out how the wheel responds to various command sequences. In the meantime I'll appreciate any additional information about this problem.

This is very impressive, I'm looking forward to trying this out..

Something of this sort might be doable with a script that would toggle turn indicators off and back on instantly. It would however require a quite precise timing and it would probably run out of sync eventually anyway.

Is the FFB problem in any way similar to this or this? If the problem became considerably worse with 1.99 versions, I have a theory why this could happen. It might be interesting to see if limiting framerate in LFS to say 50 makes any improvement.

Quote from dhbora :

Well, exactly, they should steer the wheels in the direction of the car's motion, but it does exactly opposite thing. Let's say I'm turning left and I get oversteer and at that point my steering turns right to get the car out of the slide. I don't think, that's what's supposed to happen.

This is exactly what's supposed to happen. If you're turning in a real car and you take your hands off the wheel, it will begin to turn back and it will eventually center itself. The same effect (action-reaction principle) is what corrects a car when it oversteers. This effect is very prominent in LFS if you have a high end wheel like G2x or some Fanatec.

This is correct behavior. Forces acting on the front wheels will try to steer the wheels into the direction of car's motion. LFS simulates this effect very well actually.