FSUIPC %.12 Space bar problem P3D V4

[aeronauta]

In P3D V4 if you press the spacebar to get the mouse to move the view point , the mouse cursor jumps to the 0/0 position on your monitor and becomes unusable ( although it moves and changes to a cross)..

 this happened right after the install of 5.12... replacin the .dll with 5.113 fixes the problem..

 

Jorge

[Pete Dowson]

It sounds like you have FSUIPC's mouse look option enabled on the Miscellaneous Page. FSUIPC doesn't read the keyboard. The space bar is usually pre-assigned to mouse look in the Sim but FSUIPC doesn't operate that facility unless enabled.

Or maybe you mean that you ARE using the FSUIPC version of mouse look, but that it has gone wrong in 5.12?

Pete

 

 

[aeronauta]

Hi Pete thank you for the prompt reply, no the mouse look is not ticked and the mouse jumps to the corner when I hit space , also with mouse look ticked behaves the same..

for what is worth  Windows 10 Version 1703 for x64-based Systems (KB4038788)

Jorge

[Chris69]

I have the same problem after installing 5.12 in P3D V4. Switching back to an earlier version solved it.

[Pete Dowson]

I can reproduce this, but I'm stumped. FSUIPC itself is not interpreting the Space bar, nor is it setting the cursor position. The SPACE bar is, as it is defaulted in P3D, sends P3D the "MOUSE LOOK TOGGLE", as shown here in FSUIPC's logging:

  1048218 KEYDOWN: VK=32, Waiting=0, Repeat=N, Shifts=0
  1048218 .. Key not programmed -- passed on to FS
  1048218 *** EVENT: Cntrl= 66734 (0x000104ae), Param= 1 (0x00000001) MOUSE_LOOK_TOGGLE
  1048390 KEYUP: VK=32, Waiting=0

I've put traps in FSUIPC in all the places where the mouse might be moved (normally in one of the Mouse facilities enabled in the Misc Tab in FSUIPC options), but none are triggered.

So it is something else in P3D which is somehow being affected by some small change in FSUIPC. I don't know how to locate it, though. I might have to ask L-M to help explain what is causing P3D to do this.

One other nasty, which I'll need to report to L--M too. As part of my test I tried to change the assignment of the SPACE bar in L-M Options-Controls, but it crashes L-M with a great long error display!

First I'll see if I can undo one change between 5.113 and 5.12 at a time, to see if I can identify the trigger, but it still looks like a P3D problem which FSUIPC is somehow triggering.

This could take a while. :-(

Pete

 

[von]

Also noticed my P3Dv4 startup screen changed (FSUIPC v512) to this (screenshot) until I mouse right click the aircraft then the display returns to a normal windowed display:
Changing back to FSUIPC dll 5.113 fixed it.

https://imgur.com/a/TzZD3

Note:
I have Win7-64 with KB4038788 installed

Edit:
Just for info .. I also use Ezdok which uses the middle mouse button (depressed) to pan the VC .. it is working ok.

 

[Pete Dowson]

27 minutes ago, von said:

Also noticed my P3Dv4 startup screen changed (FSUIPC v512) to this (screenshot) until I mouse right click the aircraft then the display returns to a normal windowed display:

I think that's the same as the one reported in the thread entitled "5.12 and display problem".

This seems to be a result of the same error as ths main thread theme. I think I've narrowed it down enough now to fix it. Expect 5.12 to be replaced by 5.121 very soon ...

Pete

 

[jabloomf1230]

On 9/15/2017 at 5:44 AM, Pete Dowson said:

I can reproduce this, but I'm stumped. FSUIPC itself is not interpreting the Space bar, nor is it setting the cursor position. The SPACE bar is, as it is defaulted in P3D, sends P3D the "MOUSE LOOK TOGGLE", as shown here in FSUIPC's logging:

  1048218 KEYDOWN: VK=32, Waiting=0, Repeat=N, Shifts=0
  1048218 .. Key not programmed -- passed on to FS
  1048218 *** EVENT: Cntrl= 66734 (0x000104ae), Param= 1 (0x00000001) MOUSE_LOOK_TOGGLE
  1048390 KEYUP: VK=32, Waiting=0

I've put traps in FSUIPC in all the places where the mouse might be moved (normally in one of the Mouse facilities enabled in the Misc Tab in FSUIPC options), but none are triggered.

So it is something else in P3D which is somehow being affected by some small change in FSUIPC. I don't know how to locate it, though. I might have to ask L-M to help explain what is causing P3D to do this.

One other nasty, which I'll need to report to L--M too. As part of my test I tried to change the assignment of the SPACE bar in L-M Options-Controls, but it crashes L-M with a great long error display!

First I'll see if I can undo one change between 5.113 and 5.12 at a time, to see if I can identify the trigger, but it still looks like a P3D problem which FSUIPC is somehow triggering.

This could take a while. :-(

Pete

 

Pete,

What became of your discussions with LM on this? I'm asking because since upgrading to  any versions of 5.1x I am experiencing the strangest behavior in P3d4.1. Sometimes, when I start a scenario, any movement of the mouse in the P3d view temporarily reduces performance to 1-2 FPS. Moving the mouse outside the view (P3d menus, or the Windows taskbar) has no effect. My Saitek X-65F controller is active in FSUIPC 5 and all controllers are disabled in P3d. Once this behavior is encountered during a flight it persists. However, other times when starting a scenario, this behavior is completely absent.

There is nothing of interest (at least to me) in the FSUIPC5 log. Deleting Prepar3d.cfg and letting the sim rebuild it eliminates the issue, until I disable all controllers again in P3d. I tried rebuilding FSUIPC5.ini and that also had no effect. I tried switching between raw input and DirectInput in P3d and that had no effect. It happens whether using either with the default aircraft in  the P3d default scenario  or with  any scenario and any 3rd party aircraft. I even bought a new mouse and this had no effect on the behavior either. It almost seems like either Mouse Look or Mouse Yoke gets permanently enabled in P3d.

Anyway, you can file this away for informational purposes as it may not be related to FSUIPC5 at all.

Jay

[Pete Dowson]

On 11/13/2017 at 8:55 PM, jabloomf1230 said:

What became of your discussions with LM on this? I'm asking because since upgrading to  any versions of 5.1x I am experiencing the strangest behavior in P3d4.1. Sometimes, when I start a scenario, any movement of the mouse in the P3d view temporarily reduces performance to 1-2 FPS.

This certainly appears to be a P3D bug with certainly add-on aircraft. I have no quick references, but check the L-M support forums. It may well be fixed in the 4.2 update due soon (I hope).

On 11/13/2017 at 8:55 PM, jabloomf1230 said:

It happens whether using either with the default aircraft in  the P3d default scenario  or with  any scenario and any 3rd party aircraft.

Just having some add-on aircraft installed often enables DLLs they install, so you might need to test with those disabled.

I should add that I cannot reproduce andthing like this here, or any of my 3 systems running P3D4 (one on Win7, two on Win10). But then I don't have any 3rd party aircraft with their own DLLs installed.

Pete

 

[jabloomf1230]

Thanks Pete, I'm suspecting the RealAir Turbine Duke, but only because RA is out of business and thus there is no official support. All the other installed 3rd party aircraft with DLLs are deemed P3d4 compatible. Milviz staff have posted on AVSim that they are still trying to buy the rights to RA aircraft, so there is some hope.

If this is the problem. I'll see what P3d 4.2 brings.

[jabloomf1230]

Well... after much testing and fiddling I'm chalking this up to my hardware not being able to cope with my settings. The TrackIR 5 produces so many entries in the SimConnect log under precision mode (the logfile becomes GBs in size after only about ten minutes of flying), that I set the mode to "standard", which is really designed for TrackIR 4. This reduced the number of entries in the SimConnect log file substantially and also improved the mouse issue. I then set the joystick FSUIPC polling interval to 20 from 10 and that pretty much fixed the issue altogether. Either those two "fixes" compensated for what's broken or my CPU can't handle the SimConnect load, even though it's an i6700k OCed at 4.4 GHZ. Why this issue showed up all of a sudden, coincidently with a minor revision to FSUIPC5 and the release of P3d 4.1 is beyond my pay grade to figure out.The mysteries of flight sims.

[jabloomf1230]

Good news, I think I realized why this was happening. If one saves a scenario and then uses that scenario to start a new flight, the P3d4 scenario file (FXML) has a bunch of XML that initializes numerous variables. A number of them have to do with the last used VC cockpit state and aircraft settings. This appears to be similar to the P3d4 VC serialization feature, but it happens even if the box is left unchecked in the P3d UI. I'm guessing that one or more of those variables is corrupting an internal variable that is used by the TD. Eventually, this bad initialization leads to strange aircraft behaviors, like loss of flight control.

To test this, I tried opening the default sim scenario and changing only the aircraft type to the TD. Then I always used that scenario when starting and changed the location, etc. by using a PLN flightplan file which only contains minimal information. It seems like successively opening and saving the same scenario at different airports makes the probability of corruption higher and higher. This was a habit of mine to hop from one airport to the next in different sessions. I've learned my lesson.