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.

When Superman retired...

See John' Cook's FSUIPC Configuration Guide: http://www.tropicairvirtual.com/company/misc/utility/tutorial/fsuipc-guide-v1.pdf That's about the best one can do with it, unless someone has a LUA script.

Well, as it turns out, the VOXATC panel gauge DLL might not use an affinity mask. That setting is used by the VOXATC ATC server which is an EXE file. I only figured this out recently when P3d CTDed and the ATC server was still running.

Yep, That's the problem that I was having trying to understand how VOXATC does it. I suppose one could create a debug version of the DLL that had a looping thread that artificially creates a lot of CPU use. That might be a way of testing the AM. As to the VOXATC GAU DLL it is fairly CPU intensive in bursts as it utilizes the built-in Windows speech synthesis and speech recognition. On a recent CPU like my i7-6700k, AM doesn't seem to really matter though for speech stuff. Running the gauge on a single HT logical core, does seem to slow down the response time but it could also be my imagination. Jay

This would allow for fine-tuning the AI limit number. I suspect most people just pick a round number like 100 or 150 and then see what happens. Ultimate Traffic 2 has such a "frame rate" parameter and it seems to work okay. However, this improvement to the FSUIPC limiter would help out those people using My Traffic 6 and WOAI, etc..

I can't add too much except that it appears to work via my limited testing with a few flight plans and it doesn't seem to break anything either. I'm just curious, though, what happens when there is no flight plan loaded at all?

Yep, That's the problem that I was having trying to understand how VOXATC does it. I suppose one could create a debug version of the DLL that had a looping thread that artificially creates a lot of CPU use. That might be a way of testing the AM. As to the VOXATC GAU DLL it is fairly CPU intensive in bursts as it utilizes the built-in Windows speech synthesis and speech recognition. On a recent CPU like my i7-6700k, AM doesn't seem to really matter though for speech stuff. Running the gauge on a single HT logical core, does seem to slow down the response time but it could also be my imagination. Also see this VC extension (Concurrency Visualizer): https://msdn.microsoft.com/en-us/library/dd537632.aspx Jay

Pete, I'm sorry I didn't get back to you right away, but I just got home from a weeks vacation and our boiler's propane tank had run out of gas, so we had no heat. VOXATC is a GAU file which is added to the user's aircraft. The only exes that come with it are utilities for fine tuning the voice recognition and overall settings for the panel (text color, etc.). As to the link, your assumption is correct ( "SetThreadAffinityMask".). I apologize because I'm also trying "reverse engineer" in my head what the developer of VOXATC did to get a DLL to have a user settable affinity mask. VOXATC 7 is still in beta and version 7.2 is a free time-limited (60 days) download if you want to test it out, but you need a microphone on your PC. It's actually quite a clever piece of software, as it uses the built-in Windows speech synthesis and speech recognition for its ATC. It also creates its own AI aircraft and controls them. It scans all the AI traffic BGLs and then generates the AI Traffic. It works with My Traffic 6, WOAI and and UT2 . The only drawback is that it is thus not compatible with SuperTrafficBoard. As I said above, there is no way for a user to tell which threads of an app use which cores, unless it's like the time when LM staff broadly explained on their forum how they arranged the P3d threads on various cores. Jay

Luke, Pete doesn't seem too keen on adding this functionality, probably due to reasons that he stated. I'm pretty sure that any process can be assigned an affinity mask. As to a DLL, any thread that it creates can be assigned to a logical core. My guess is that is how VOXATC does it with its DLL. The assignment is not dynamic but rather it happens via the DLL reading a configuration file (created prior to running the sim by a separate setup utility that determines the number of logical cores and allows the user to set the AM).and then the DLL knows what cores to use. Based on what Pete stated above, it really doesn't seem worth it. Jay

Hah, actually I'm not sure, but FSUIPC does handle controller inputs and now does allow for management of AI traffic levels. Again, since FSUIPC is a DLL, there is no easy way to know (at least for me) how it affects CPU load. But keeping it off the first physical core might help P3d. It was just an idle suggestion for future consideration.