Thank you for the feedback.

Quote from DarkKostas :

Once i click at Run LFS, game crashes instantly

Can you reproduce the crash every time? Does it happen even when your G27 is disconnected? If you start LFS without the controlling application running, do you also get the crash? Do you have any other gaming gadgets DirectInput might be picking up?
I'll look into this but ATM I have some other business to take care of.

Quote from DarkKostas :

EDIT: Is it possible to make standalone version without the Helper app again?

Using InSim or OutGauge from within the proxy DLL is rather problematic which is why I decided not to go this way. The plan is to make the controlling application launch LFS automatically, but I need to sort out all possible problems before I begin with implementing some extra functionality.

Quote from MadCatX :

Can you reproduce the crash every time?

After the first crash, LFS runs fine.

It's still not working but now the problem seems to be the outgauge port(yes my ports are fine, 30000 for outgauge). The led lights stay frozen to either "all lit" or to "flashing".

In this log i've run the game 3 times, 1st with crash and 2nd, 3rd that run ok.

Quote from MadCatX :

Using InSim or OutGauge from within the proxy DLL is rather problematic which is why I decided not to go this way. The plan is to make the controlling application launch LFS automatically, but I need to sort out all possible problems before I begin with implementing some extra functionality.

Making it work like it was before would be good, you could simply make a "list" with each version's reversed address and load the correct one based on lfs version.

I downloaded the Visual C++ redistributable 2012 from here: http://www.microsoft.com/en-us ... oad/details.aspx?id=30679

but it keep saying that the program can't start because MSVCP110.dll is missing from my computer

Quote from DarkKostas :

After the first crash, LFS runs fine.

It's still not working but now the problem seems to be the outgauge port(yes my ports are fine, 30000 for outgauge). The led lights stay frozen to either "all lit" or to "flashing".

My guess would be that the crash on the first attempt left the network sockets open which is why the controlling app couldn't connect to LFS. Can you try again after a reboot please?

Quote from Specht77 :

I downloaded the Visual C++ redistributable 2012 from here: http://www.microsoft.com/en-us ... oad/details.aspx?id=30679

but it keep saying that the program can't start because MSVCP110.dll is missing from my computer

msvcp110.dll is a part of the VC++ redistributable package, are you sure you installed the correct version for your architecture (either x86 or x64)?

Quote from DarkKostas :

Making it work like it was before would be good, you could simply make a "list" with each version's reversed address and load the correct one based on lfs version.

It is not as simple is it looks because even the LFS version string doesn't have a fixed position in the memory. If the OutGauge buffer becomes allocated dynamically at some point, it will make the whole thing even more obnoxious. Current approach is universal and it will work with anything as long as the OutGauge packet format remains unchanged. It will operate as seamlessly as the previous version did once it's finished.

Quote from MadCatX :

My guess would be that the crash on the first attempt left the network sockets open which is why the controlling app couldn't connect to LFS. Can you try again after a reboot please?

This was and is happening each time i run the program. First time it crashes and the rest ones lfs works, but leds are frozen to either full lit or flashing.

Quote from MadCatX :

It is not as simple is it looks because even the LFS version string doesn't have a fixed position in the memory. If the OutGauge buffer becomes allocated dynamically at some point, it will make the whole thing even more obnoxious. Current approach is universal and it will work with anything as long as the OutGauge packet format remains unchanged. It will operate as seamlessly as the previous version did once it's finished.

I see...Well then an update with the 0.6E addresses(rpm and car) would be enough for me.

(V 1.99A TEST) win8 x86 here. needed to install Visual C++ Redistributable package. everything works fine.

ps was it intended for lights to flash in the main menu?

thanks!

Quote from MadCatX :

msvcp110.dll is a part of the VC++ redistributable package, are you sure you installed the correct version for your architecture (either x86 or x64)?

My windows is x64, and I installed the "vcredist_x64.exe"


but for some weird reason, I found msvcp110.dll at system32, and I don't even have the x86 installer on my hard disk

Quote from ekzotic :

(V 1.99A TEST)
ps was it intended for lights to flash in the main menu?

It most certainly was not 1.99A doesn't zeroize certain area in the memory which is why the LEDs flash until you get OutGauge data. I'll fix it in a further version.

It's interesting that the mod works on Win8 but crashes LFS on Win7. I was able to reproduce this behavior, but I can't quite figure out what the problem is. Thanks for the report. Could you spend a few minutes testing another version I know that crashes on Win7? If there is a difference between Win7 and Win8, the mod has to take it in account.

Quote from Specht77 :

My windows is x64, and I installed the "vcredist_x64.exe"


but for some weird reason, I found msvcp110.dll at system32, and I don't even have the x86 installer on my hard disk

System32 on x64 Windows contains 64bit libraries, 32 bit libs are in SysWOW64 (how logical is that? ) Given the size of the x86 and x64 packages it's likely that you need the x86 packages on any architecture since the mod is 32 bit; sorry I didn't notice that before.

1.99A is rather broken in a somewhat peculiar way so don't get your hopes up too much

well, now at least I can open the helper (I downloaded the x86 stuff) but when I press "launch LFS", the LFS launch on a black screen for some seconds, and then it crashes

Quote from Specht77 :

well, now at least I can open the helper (I downloaded the x86 stuff) but when I press "launch LFS", the LFS launch on a black screen for some seconds, and then it crashes

It does the same to me.

Hey there!
Tried G27LEDS_1.05.zip but nothing happens. Enabled outgage mode. set outgage port to 30000 as well but still nothing happens. "runleds" launches well.

Tried G27LEDS_199A.zip but LED just flashes all the time while in game.

LFS 6E v

Quote from MadCatX :

It is not as simple is it looks because even the LFS version string doesn't have a fixed position in the memory. If the OutGauge buffer becomes allocated dynamically at some point, it will make the whole thing even more obnoxious. Current approach is universal and it will work with anything as long as the OutGauge packet format remains unchanged. It will operate as seamlessly as the previous version did once it's finished.

I've been thinking again about this and i found a solution. What if you MD5 the LFS.exe ? And have each MD5 as a version number.

Update to 1.99B. Although it doesn't do anything more that the old series did yet, most (if not all) possible crashes should be resolved now. It can launch LFS automatically so you don't have to click the "Launch LFS" button anymore, but be sure you have everything set up correctly before you enable autolaunch in the configuration.

Quote from DarkKostas :

I've been thinking again about this and i found a solution. What if you MD5 the LFS.exe ? And have each MD5 as a version number.

Although that would be much more reliable solution than version string matching, it still has all the major disadvantages I dislike about the previous approach.

Quote from MadCatX :

Although that would be much more reliable solution than version string matching, it still has all the major disadvantages I dislike about the previous approach.

Like having to find all the car and rpm addresses? Because i liked it just having a dll and can run lfs through external sites, like lfsw.

Anyway, i tested the new version and it worked perfectly. It looks like the password was causing the problem.

As always though there is a big BUT. I noticed some strange FFB effects especially after you leave pits for ~3 seconds, but i think some of them still existed after that.

1.99C will hopefully be one of the last testing versions. It now checks if there is a correct dinput8.dll file in the LFS directory. There is also a new pit limiter indicator function.

Finally back on my pc

The problem i had with the strange FFB Effects still exist... Like keeping the wheel at the left side or having less force in transfers between left and right.

RPMs are working nicely same with the pit limited thing. Still i'd love to have the program "portable" though!

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 MadCatX :

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.

After reading both topics it seems that,

If i have FPS Limit and VSync off, FFB only works at least when the first green led is ON. So if there are no leds on, FFB is also off.

But if i use FPS Limit, even on 100 which is the max LFS can go, FFB works nicely.

Good luck on fixing it

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.

It finally worked !! Thank you !!

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.

Quote from MadCatX :

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.

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

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

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...

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

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).

It still worked, even without having any leds on.
Also it was possible to set custom patterns, for example having only the 3rd led on. This looked so cool!

I can't seem to understand what exactly the problem is. But i'm sure it's something similar to that. At least for LFS. Because whenever my rpm was low, so i had no leds on, i had no ffb as well.

Because the previous attempt to get to the bottom of this has been unsuccessful, I uploaded a modified version of the testing tool.

- It is now possible to set the delay as low as 1 msec
- The tool can now use DirectInput as well as raw access. DirectInput accesses the wheel in the same manner as the G27LEDs mod.

See the original post for download link.