jabloomf1230

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

Simon, I have a copy of PSXseecon Traffic and Real Traffic (note the correct spelling of the former). Real Traffic is $50/ year subscription that provides the location of real world traffic via their ADS-B transmitters. Sometimes this information has departure and destination airports, but it's almost always limited to altitude, airspeed, heading, airline and flight number. PSXseecon is a freeware package that takes the information from RT and creates SimObjects in P3d4 for AI aircraft, based on whatever models and liveries that one has installed in the sim. A further limitation is that not all airports and airlines require ADS-B transmitters to be active on the ground. Although it might be a nice thought to think about how STB could be linked to live ADS-B data, it's probably a lot easier for the average sim user just to access the free version of FlightAware.com for a specific airport. 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.

The amount of information available via SimConnect regarding individual AI aircraft is different depending on whether the object is controlled by either the P3d4 ATC or not. UTL does not use standard AI traffic BGL files as opposed to My Traffic 6 and freeware packages like WOAI and AIG which do. Somewhere on this subforum, the STB developer explained how he managed to retrieve as much information as possible from UTL regarding the aircraft that it controls. As an example of differences between P3d4 ATC controlled AI and other objects , if an object is under the control of the P3d4 ATC it will have the following potential traffic states: "init" "sleep" "flt plan" "startup" "preflight support" "clearance" "push back 1" "push back 2" "pre taxi out" "taxi out" "takeoff 1" "takeoff 2" "T&G depart" "enroute" "pattern" "landing" "rollout" "go around" "taxi in" "shutdown" "postflight support" STB converts these states into a smaller number of states for each AI aircraft's status. If an object is not under the control of the P3d4 ATC (for example, the object is being slewed by SimConnect in some fashion), the object will have far less types of traffic states: "Sleep" "Waypoint" "Takeoff" "Landing" "Taxi" This is also one of the reasons that STB can't discover any information about VOXATC AI aircraft, since the VOXATC ATC controls all the AI aircraft directly and does not expose information needed to fill out the board. Utilities like Pete Dowson's Traffic Look, AITA 2014 and the P3d4 Traffic Toolbox Explorer will show which AI aircraft information is exposed and which is hidden.

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

The only other possibility is that the ADE file is missing exclusions for some of the stock KSAN taxiway signs. Unfortunately I don't have the LVFR KSAN so I can't check this for you. If you open the LVFR KSAN ADE file in Airport Design Editor 1.75, see if you can pinpoint which specific stock taxiway signs are not excluded. This often happens when runway numbering is different between the stock and 3rd party versions of an airport.

Are you sure that the LVFR KSAN isn't missing exclusions for some of the stock taxiway signs? The only way to find out would be to open up the ADE file and look at it with Airport Design Editor.

http://www.fsdeveloper.com/forum/threads/simple-airport-scanner-1-70-beta.440300/#post-774821 It doesn't quite work with V4.1, but have SAS scan for all airports and not "multiple files". It WILL find extra versions of KMSP, KSAN etc. if they installed via scenery.cfg.

Before your eyes stay permanently crosed , try Simple Airport Scanner: http://www.scruffyduck.org/simple-airport-scanner/4584282795

It was difficult to figure out where the AI aircraft was since it was underground (or at least that what it looked like). The view alternated between the aircraft displayed over a light blue background and a moving greenish display that looked like a ground texture viewed from close up. I will try to reproduce this with a trace. I hardly ever use Arrive Now, but since I was debugging the SODE crash for JS, I decided to use both that and Depart Now.

I did notice a few times that "Arrive now" resulted in the AI aircraft ending up either underground (!) or at a nearby airport. Also, I sent a debug mode SODE log file to Jeffrey Stahl as he felt that SODE 1.5.3 was having an issue with AI detection in P3d V4.

Working as expected here also. The only interesting thing that has happened is that the sim CTD at DD KEWR, but the Windows error message was attributed to SODE losing its SimConnect connection. I've seen this before when the SimConnect channel was "flooded" by a 3rd party app, but I doubt that it has anything to do with STB. Just an FYI.