jabloomf1230

Ok, Thanks. I was trying to write a DLL interface to FSUIPC and I thought that there was. I apologize.

In MSFS, does this work with a SimObject with a material (RGB colors) rather than a SimObject with texture files? Thanks.

John, Also, could you contact Malwarebytes as they are reporting your zip files as containing a trojan? I excluded it, but you might have other people asking about this. This also applies to the link on SimMarket. Jay

Tom, I did that first before trying the old key file. The key for the version you referenced says it is valid until 3 November not 8 November. At this point I think I'll just wait for the RTM version on SimMarket. Jay

I read on the forum that the beta key was time based and expired, so I uninstalled FSUIPC7 using its uninstaller and then reinstalled using the installer. The version runs but does not have a registration key. I did save the old .KEY file in a different location but when I put that file in the FSUIPC7 folder and run the app it still says it is not registered. FSUIPC7.ini FSUIPC7.log InstallFSUIPC7.log FSUIPC7.key

Pete, A thank you from me also, as an fsaerodata user. Jay

Pete, I managed to get the Traffic Look 1.56 main window to display with P3d4 and Win10. I took a look at TrafficLook.ini and I noticed that the window settings were -8,-8, 2546, 1576. I changed them to 10,10,640,480 and the window displayed correctly. I'm guessing that the negative x/y origin location causes the window to not display. Jay

Pete, I don't know if you are back online or not, but I just checked TrafficLook 1.56 with P3d4 and the most recent version of FSUIPC5 and I get the same result as John reported above. It's not a big deal to me, but I just wanted to confirm his results that TrafficLook was reported as running in the Task Manager, but its main window does not display. I'm running Win 10 and not WideClient. Jay

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.

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.

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.

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, The door issue in P3d V4 has been reported elsewhere and has been supposedly worked around by adding the old FSX open/close doors panel gauge instead of using the sim's built-in recognition of the key sequence. Last I saw, the gauge was still available for download on Simviation.com.

Pete, I don't want to completely derail this user support thread, but here's a comparison of the "tail end" of the Runway entries between the V3 SDK: http://www.prepar3d.com/SDKv3/LearningCenter/environment/compiling_bgl.html#Runway and the V4 SDK (which can't be directly linked, so here's the entry): The structure (materialSet) that you referred to contains the seasonal material set GUIDs that allows differing materials to be used for runways during the 5 P3d "seasons". I apologize for not writing more clearly in my previous post above. I'm not sure why LM changed the IDs, but a few other utilities don't work correctly (yet) because of this change. Actually, the more that I think about it, this was to differentiate between runways with and without the materialSet entry. I could be wrong on that, though. Jay

The only item that was added to the BGL format that affects ADE is the ability to support P3d materials. It is of minor consequence unless a developer wants to take advantage of this new feature.