NFS: Porsche Unleashed crashes on race load

[sdether]

Following instructions from PCGamingWiki I installed dinputto8 v1.0.39.0 and devreorder to try to add support for my Fanatec CSL Elite Wheel.

However this combination crashes the game once you try to start a race. I did some experimentation to try to narrow down what causes this:

• without either dinputto8 and devreorder
  • can map buttons and analog controls of the Fanatec wheel in options menu
  • The race does not crash
  • The mapped buttons work, but the analog controls do not (this is what devreorder is supposed to fix)
  • Force feedback is working (can feel the forces and road in the wheel even if steering is unresponsive)
• with only devreorder
  • behaves like the previous case
• with only inputto8
  • can map buttons and analog controls of the Fanatec wheel in options menu
  • Race crashes on load
• with both dinputto8 and devreorder
  • the device list is filtered properly
  • can map buttons and analog controls of the wheel in options menu
  • if the mapped device is the Xbox 360 controller, race runs and controls work
  • if any button or analog control on the Fanatec wheel is mapped, race crashes on load

My guess is that there's something in the way the Fanatec uses Direct Input that is not compatible with the API mapping that dinputto8 does. If there is anything I can do on my end to provide a more useful bug report or diagnostic data, please let me know.

[sdether]

Tried installing dinput_debug for v1.0.39.0 to get logging, however that complains about a bunch of missing DLLs (including VCRUNTIME140.DLL). Seemed to track back to missing Visual C++ Redistributable for Visual Studio 2015, however I already have a redistributable called Visual C++ Redistributable for Visual Studio 2015-2019 which prevents the install of the former, so not sure what I'm missing to get the debug version working

[sdether]

Also tired dinput_debug v1.0.30.0 since that still had logging enabled. That one, however crashes NFS:PU on launch even when only XBox360 controller is configured which works with v1.0.39.0. Just in case this is the log it writes:

12592 10:25:32.439 Starting dinputto8 v1.0.30.0
12592 10:25:32.439 ASUSTeK COMPUTER INC. TUF H310-PLUS GAMING Rev X.0x (Desktop)
12592 10:25:32.440 Windows 10 64-bit (10.0.19041)
12592 10:25:32.440 "nfs5.exe" (PID:7788)
12592 10:25:32.444 Redirecting 'DirectInputCreate' IID_IDirectInputA version 0x500 to --> 'DirectInput8Create'
12592 10:25:32.508 Creating device m_IDirectInputX::m_IDirectInputX(04D33650) converting device from v1 to v8 using ANSI
12592 10:25:32.509 Creating device m_IDirectInputDeviceX::m_IDirectInputDeviceX(04CE6558) converting device from v1 to v8 using ANSI
12592 10:25:32.509 Creating device m_IDirectInputDeviceX::m_IDirectInputDeviceX(04CE64C8) converting device from v2 to v8 using ANSI
12592 10:25:32.509 m_IDirectInputDeviceX::~m_IDirectInputDeviceX(04CE6558) deleting device!
12592 10:25:32.509 m_IDirectInputDeviceX::~m_IDirectInputDeviceX(04CE64C8) deleting device!
12592 10:25:32.509 m_IDirectInputX::~m_IDirectInputX(04D33650) deleting device!
12592 10:25:32.509 DirectInputCreateW
12592 10:25:32.509 Redirecting 'DirectInputCreate' IID_IDirectInputW version 0x50a to --> 'DirectInput8Create'
12592 10:25:32.526 Creating device m_IDirectInputX::m_IDirectInputX(04D33608) converting device from v1 to v8 using UNICODE
12592 10:25:32.526 Redirecting 'DirectInputCreate' IID_IDirectInputA version 0x500 to --> 'DirectInput8Create'
12592 10:25:32.526 Creating device m_IDirectInputX::m_IDirectInputX(04D3AA88) converting device from v1 to v8 using ANSI
12592 10:25:32.527 Creating device m_IDirectInputDeviceX::m_IDirectInputDeviceX(04CE65E8) converting device from v1 to v8 using ANSI
12592 10:25:32.527 m_IDirectInputDeviceX::~m_IDirectInputDeviceX(04CE65E8) deleting device!
12592 10:25:36.370 m_IDirectInputX::~m_IDirectInputX(04D33608) deleting device!
12592 10:25:36.370 m_IDirectInputX::~m_IDirectInputX(04D3AA88) deleting device!

[elishacloud]

Here is the latest debug file. Go ahead and try this one, attaching the logs.

dinput.zip

[sdether]

Tried to keep the test cases as minimal as possible:
xbox360_dinput.log - only Xbox controller were mapped prior to this run. Game is launched, race is started. Shortly after it loads properly I exit

fanatec_dinput.log - Steering on the Fanatec wheel was mapped prior to this run, while the other Xbox bindings remained. Game is launched, race is started. Crashes on completion of load.

Didn't see anything obvious in the logs, except that the fanatec case had a couple of cases of two threads writing log lines at the same time, messing up line feeds, but doubt that's related to crashes. Hope the logs shed more light for you.

thanks!

[elishacloud]

Thanks for the help here. Am I correct in saying that the Xbox controller works fine?

I can see that Fanatec wheel calls the CreateEffect function and it looks like it is failing on this function. There may be something I need to convert to DirectInput8. I am not sure if this is why it is crashing.

I created an update with more logging here. Can you test this one and upload the logs: dinput.zip

[sdether]

Yes, when just using the Xbox controller everything works. And it does look like the Fanatec controller is failing on CreateEffect. There's a bunch of Trying followed by Failed entries in the logs now.
dinput.log

Not sure if this is helpful or related, but in case CreateEffect is related to Force Feedback, I should note that when running the game without dinput and mapping the Fanatec wheel the wheel is definitely receiving Force Feedback. It's just that the analog controls are not bound. But the game starts going straight on full throttle and you can feel the FFB pushing against turning the wheel and you can feel the texture of the road as its going down the road, so in principle the wheels FFB and what NFS:PU is sending seem to be compatible.

[elishacloud]

It looks like it is sending 0x80070057 which means a parameter is incorrect. I created an update to fix some of the parameter issues.

Can you test this one and upload the logs: dinput.zip

[sdether]

Took a little longer to crash. Usually it crashes as soon as it the loading bar gets to the end. This time it just hung there, making me think it had locked up. But a couple of seconds later it did crash. I see more debug information on the CreateEffect calls, but otherwise it seems like it's the same calls that are failing.
dinput.log

Really appreciating you working on this, btw. Pretty awesome that a game from 2000 can still be tweaked independently of the original developer.

[elishacloud]

There is still a bad parameter, but I don't know which one. I added more logging and tried a slightly different way of creating the effect.

Here is one more try: dinput.zip

[sdether]

Alright this is fantastic. Does not crash, mapping works, and it works in race.

dinput.log

That solves the main problem. I did come across two other issues:

• When in the controller mapping screens, the UI crawls for a couple of frames per second and inputs lag. Maybe that's just the logging I/O and it goes away with a logging disabled DLL?
• Force Feedback is gone. Since it was there before any of this patching, I know that NFS:PU does send the proper FFB info to the wheel. Of course that was before mapping worked, so maybe its just something that is lost in the API mapping you have to do?

[elishacloud]

It looks like the crash was coming from the failed CreateEffect function. The new way I am creating the effects is not a permanent solution, and it does not solve the core issue of invalid parameter, as seen by this log:

10204 23:20:56.703 m_IDirectInputDeviceX::CreateEffect (0B119838) tying 'SetParameters' hr = DIERR_INVALIDPARAM

For this update I hard coded some of the parameters based on Microsoft's SDK. This will help isolate the issue: dinput.zip

[sdether]

Back to crashing. Hope there's enough info in this one
dinput.log

[elishacloud]

@sdether, thanks for your continued help here! I have no other way to test this.

It looks like the issue with the parameters may be caused by a previous call to SetDataFormat. I added more logs there. I hope this will give me all the data I need.

Here is another test build: dinput.zip

[sdether]

This one works again. Input in configuration screen still super laggy and still no forcefeedback in-race, but otherwise the controls work as they should.

dinput.log

And I should be the one thanking you. I'm the one with the odd combination of old game and new hardware that's crashing after all. Gladly provide all the debugging support I can since my C++ is atrocious. I've sworn off all languages that require manual memory management, since the only thing I ever effectively managed to create was memory leaks and crashes :)

[elishacloud]

Input in configuration screen still super laggy

This could just because the wrapper is running in debug mode. Here is a release build to test with to see if it is still slow with the release build: dinput.zip

still no forcefeedback in-race

There are no errors and the functions seem to be passing, so I am not sure what is happening here. I added logs when the game tries to start the force feedback to see if it is getting any errors.

I should be the one thanking you. I'm the one with the odd combination of old game and new hardware that's crashing after all.

I would like to fix this if possible, since I have had reports of similar issues and I think they are related.

I've sworn off all languages that require manual memory management, since the only thing I ever effectively managed to create was memory leaks and crashes :)

I am afraid the maker of this game maybe should have done the same thing. The game fails to check the Effect interface address and uses it blindly, thus the crash. I fixed this by creating the interface with no parameters and then adding the parameters later. This way when the game uses the interface it does not crash.

Here is another debug test build. It just has additional logs: dinput.zip