Pete Dowson

Sorry, please clarify. Is that the ONLY thing you are changing? just the limit itself. Nothing else? Because, with just that set, there is no preference whatsoever for any specific traffic type or state, it is purely random. The likelihood of all ground traffic being removed, must be truly infinititesimal. However, bear in mind that BGL based traffic (unlike injected traffic like that from injection, like UT2 or UTLive), does mostly get spawned on the ground, and usually quite a while before departure time. Traffic spawned in the air will take longer to generate and will often start a long way away. However, even if all the deletions made are of ground traffic, you'd still have 50 left. Are you saying the traffic reduces to zero? Oddly, you say "if I set the limit at 50" but then "the same happens when I set AirportPreference at 5" as if these are alternatives. Without a limit set the other values don't do anything! I think you need to explain rather more about what you are doing and what you really want to achieve. Pete

Assuming it is plugged into an old-type (black) USB socket, this sounds exactly like a loose connection somewhere. even a very short-lived temporary disconnection with disconnect because it will disrupt the protocol. Reconnecting re-iniitialises the protocol sequences. But anyway, first try a different USB socket (making sure you choose an older type one -- not one of the new Blue or Red ones). Then, if it is replaceable, try first replacing the USB lead. After that it gets more difficult as it could be an internal connection. The one thing it won't be is FSUIPC settings or its or other calibration. Pete

Well, I wasn't really much help, so I'm very pleased it solved itself, somehow! Pete

Apart from WideFS what isn't working now which was earlier? Your wideFs problem is explained: the new Log shows: WIDEFS7 not user registered, or expired so you evidently have not transferred your WideFs registration. Mind you, the "Prev" log was the same. So are you sure you had WideFS working there? Pete

I've checked the code in FSUIPC and as far as the PMDG aircraft are concerned I can't see any changes up to version 4.975a which could stop this data being seen. I don't have those aircraft to test with, but I'll try to check further. Please get me some logging. Add these lines to the [General] section of the FSUIPC4.INI file: Debug=Please TestOptions=x400 run the sim and select you PMDG 737, 747 or 777 (one after the other if you have all three. Then close and ZIP up the FSUIPC4.INI, FSUIPC4.LOG, and the Options INI files from the PMDG aircraft used. I can't guarantee to solve this, but i'll take a look. You can try this version of FSUIPC. FSUIPC4974b.zip If that works please let me know. Pete

They'll most list be links, like to Gates. Look at a chart for the airport and you will see many taxiways like that, without names. There's a freeware program called ADE by Scruffy Duck which you can use to determine details of all parts of an airport layout. Pete

Why? Sorry, that really makes no sense. It is not likely that we can really support that version when the updates fix so many things and are free for you to move to! Pete

Why as a "custom control"? Isn't "FUEL PUMP" listed in the dropdown? That's 66237. Either way, it looks like they've not (yet) exposed the correct controls for this action. But before giving up for now, can you try assigning to FUEL PUMP but with parameters 0, 1, 2 (for off, low, high), just to see. I will do some tests here. But probably this will need to go on the list to report to ASOBO. No point in doing so yet -- we need to collate the responses from all FSUUIPC7 users, test them all after the next update from ASOBO, then report any still outstanding. However, when you look at how many panel operations for FX and P3D aircraft needed either Mouse Macros or L_Var access, I suspect many such things will need to wait until it is clear how those or their equivalents can be dealt with. Even if we had a module running within the MSFS process, AFAIK there's no way for it to connect with the outside (yet)! Pete

Sorry, I've no idea what the problem is, yet. I need to try to reproduce it here. At present I don't even know how to narrow it down using some extra logging. This could take a while. I might need to make several different test programs. Bearing in mind that WideClient has now been going since 1998 (for FS98) and has barely changed in all that time -- additions of new facilities, but mechanism, interaction with applications and with FSUIPC/WideServer, is all original stuff. It does seem to be some slight incompatibility with a Windows change, but tying that down will be a long job. AND there's all the work involved now with MSFS's release. Pete

Thanks! I'll take a look over the next day or three. Pete

My TrafficLook program reads akk the traffic stuff, but not both Ground and Airborne tables together, and certainly not that frequently -- for like 500 or 1000 msecs. However, the actual transfer on the Network is only ever the changes, not the whole table each time -- though if there's a lot of traffic and it is all moving I suppose that could be most. And if it is broken up there are the overheads of length and offset needed for each section, each byte or continuous sequences, containing changes. What is transferring the whole data each time is the interface between WideClient and your program. The offset map is maintained in the client and updated by messages over the network. Looking at the Log one thing puzzles me. The last part, the entries timed 300422, show a lot of separate transactions ("Process Message") all within one millisecond or so. Certainly a lot lot more than in the earlier times. What might be happening there? Is this all from one client application? It seems to be doing many separate Process requests rather than the usual once-per-cycle. I'll look to see if I can test the reading of a large wodge of data at least 4 times per second. That should be easy enough with FSInterrogate. But to do it with many separate process requests will take a bit longer. I'll have to knock up a small test program. Pete

Is that after a good Serial port has been identified AND recorded? Can you check the PFCcom64.dll INI file for me please? Thanks for the report. I will check how all these are configured internally. Meanwhile, is it possible for you to repeat tests but with logging enabled? In FSUIPC's logging options enable Event and ipcWrite logging, and in the PFCcom64 options I think there will be a log option for Decoded inputs and maybe FSUIPC writes. No harm in leaving these options set, but the log files may get large, so please ZIP them before attaching. Thank you Pete

Thank you! Pete

Hmm. That's very interesting. Like you, I wish I could understand why. But the only way I could work that out would be to use SimAvionics myself in the same configuration as you. Not really possible here I'm afraid. It took me several weeks work coding, testing and debugging, when I changed over from Project Magenta to ProSim for my system! Pete

Ah, yes. That makes a lot more sense! BTW do you know why a user with a VRI MCP panel using the SerialFP2, on P3D5HF2, should be having the problem of the process hanging when closing P3D down? I've suggested that he should try LINDA instead -- I assume that then does away with the need for SeriallFP2. Is that right? This is the thread: Thanks, Pete

Well, I had to look it up: The rotor brake assembly is a piston actuated, hydraulically operated braking device for stopping the helicopter rotor So, it's only for helicopters -- FSL have evidently re-used controls which otherwise aren't in use. The only relevant control listed for P3D is "ROTOR_BRAKE" (66587 ). for multi-use i guess they use the parameter value. You really need to ask these questions on the FSLabs forum. Using sophisticated add-on aircraft like those from FSLabs and PMDG takes you away from standard built-in P3D/MSFS subsystems and therefore the control methods are different and need to be determined for the aircraft specifically. For this the aircraft makers are the best source of information. Pete

Okay, thanks for letting me know. Seems to imply that the slight slowing down as a result of the logging actually stops something clogging up. You'd think it would make it worse wouldn't you? Ah well. Pete

Oh, I see. Native code not managed. Pete

Thanks! I think I have enough now to solve this. Pete

Use the AT annunciator (offset 6572, the "MCP_annunAT"), not the state of the button! In Lua either read it by ipc.readUB(0x6572) or for a permanently running plug in by event.offset(0x6572, "UB", "yourfunction") Pete

Interesting. None of the monitored offsets changing in either set of tests. Are you sure you enabled the Offset logging to go to the Log file? (a check box option on that tab). Anyway it probably doesn't matter now. i think we found the answer to enable those trims as axes generally. Pete

I don't think C++ is a .Net language. The .Net languages are the managed ones like C#. As John says, Paul's DLL does offer advantages when using such languages. ete

Ouch. So the adapter is built into the device. Shame. I'm not sure what else to suggest. I suppose we could have yet another thread which waits a few minutes and if no shutdown occurs can do the same ruthless termination as you'd do yourself via Task Manager in any case. Maybe trying an alternative USB port on your PC will help. One question on that: you aren't connecting to a USB-3 port (blue coloured) on the PC are you? If so, don't. Many older USB devices don't work well on USB3 ports. There used to be a VRI expert who used to visit here, but i think he packed up. I think now the only folks around here who know much about VRI devices are those doing LINDA. Did you stop using that for a reason? I think you don't need to use SerialFP2 if you use LINDA, which may well help. I was never happy with that driver. Pete

There's only one as far as I know. I don't have or use PDMG aircraft myself. On Boeing aircraft the AP controller is called the MCP (Mode Control Panel). It sits on the glareshield in the centre. Are you new to such aircraft? You are going to need to familiarise yourself with Boeing terms if you are going to be flying aircraft as complex as those from PMDG. See offsets 6540 - 657A in that document. Surely enough there for you? It is very comprehensive! Pete

Do I understand that you want the AP settings from your PMDG 777? PMDG implement their own subsystems, including the autopilot. The offsets you need will be listed in the document called "Offset Mapping for PMDG 777X.pdf" which you'll find in your FSUIPC documents folder. Take note that you need to enable this data in a PMDG settings file. Pete