Pete Dowson

Sorry, I don't understand much of this. Can you explain more? What throttle is it, and how is it connected, assigned, calibrated. And what N1 is set when you "Active Reset" throttles, and what do you mean by "Active Reset"? You do know you cannot use FSUIPC calibration for throttles with the 737NGX don't you? Pete

Water runways are included if you add the /Water parameter to the command line, exactly as documented under the heading "WATER RUNWAYS" in the Read Me text file supplied with the program! BTW the current version is 4.699 Pete

Hmm. That may not be easy to fix, because the detection of missing joysticks is much later than the deletion of the existing annotations, and because the joystick is missing the entries aren't processed to add to the look-up tabled. Without the processing no new annotation is generated. I'll have a look at this once I've aught up with the support backlog. Pete

Yes. Do so. Change each one -- eg 1 to 4, 2 to 5, 3 to 6, then back again if you prefer them to be 1, 2, 3. Doing this will correct the registry entries. Pete

Ah, so it needs the percentage of door opening! How strange. I'm sure real aircraft don't have such control over the door! ;-) Pete

You can assign in FSUIPC too for identical results. Just ensure you only assign to the controls named "Axis ...", which is what FS would be doing, and do not calibrate in FSUIPC. NEVER assign in FSUIPC if you haven't disabled controllers in FS -- and vice versa. It's one or the other. or you will run into weird problems. Pete

Hat controls revert to "forward" on release. I'm not sure what you'd do with a joystick or throttle assigned to pan view. After all, the input from a hat is 0-360 (or mutliples). That of normal axes is -16384 to +16383. I've no idea how FS would interpret Pan View with such weird numbers. However, you need that control with a parameter of 0 (=0 degrees) for a forward view. Pete

Version 9.xxx? I assume you mean 4.xxx? I'll probably need some logging to investigate this. The facility to send commands to AI aircraft certainly hasn't changed and works fine. There was a change to move the AI data reading, from SimConnect, into a separate SimConnect connection. This was done because it was discovered that on heavily loaded systems the notifications of AI being added and removed stopped arriving from SimConnect. Separating them seemed to help a lot. Please can you run TrafficLook (a utility provided in the Useful Additional Programs subforum) and see if you are actually getting traffic data read into FSUIPC? Then, before I look at providing a logging version, could you try my latest internal update, FSUIPC4957d.zip. Also try adding "UseAIClient=No" to the [General] section in the FSUIPC.INI file. This makes the AI data reading revert back to the way it was. Pete

POST MOVED FROM USER CONTRIBUTIONS SUBFORUM Yes, you can do what you want with a Lua plug-in. Apart from the documentation provided (in your FSUIPC documents folder) about the FSUIPC-specific additions for Lua, and the numerous examples in the ZIP in the same folder, full documentation for Lua, including tutorials I think, is provided by the Lua folks on their website. The link is provided in the FSUIPC Lua documentation. There are also books on Lua. Please always post support questions to this main support forum, not to the specialised sub-forums, otherwise they might not get noticed. Pete

We cannot solve it. It is a change in P3D 3.4. and needs reporting to L-M. Try sending traffic commands through Traffic Explorer. Try putting them into slew mode for example. The commands you can use are those listed in the List of Controls document in your FSUIPC Documents folder. Last message from me now for 2 weeks ... Pete

There's no way any program should be able to "block" access to any text file. Maybe what you mean is that you were using an edit program which doesn't "share" open files (Uedit32, the one I use, can read the log at any time). But it isn't LINDA which is blocking it, but the fact that P3D was still running. It is something LINDA is doing which is preventing P3D from closing down. Just because you see the P3D window disappear does NOT mean it is closed -- it will still be running, as a process, for many seconds after this. The Log most certainly shows that P3D is NOT terminating! FSUIPC ihas not terminated The log is not complete! If you are sure there's no Process called Prepar3D when you looked in Task Manager (and I do find that very hard to believe -- look in the Processes tab, not the Applications one), then P3D has crashed instead You need to get details from the Windows Event Viewer. You need LINDA support to work out what LINDA is doing which can stop P3D closing or make it crash. That is the problem. It is nothing at all to do with FSUIPC's "KILL" facility -- FSUIPC isn't getting that far. P3D is hanging or crashing beforehand. My guess would be something to do with DirectInput or some other one of your devices or their drivers. You seem to have a lot of logging showing VRI devices on COM3,, plus Saitek panels, etc etc. Try eliminating all of these then add them back one at a time to see which is causing problems. BTW why is there so much stuff in the Log from LINDA? Can't you turn that off? This will be my last reply for 2 weeks. Off soon ... Pete

I did say you might need to research elsewhere to get the right parameters. I know that some of the controls use a sort of "mouse status mask" as a parameter -- one which indicates whether left, right or middle button has been clicked, usually. I'm afraid I don't know much more about that, but I'm sure others must have worked things out so best to ask around. You could look further into that .h file too, to see if the answers are buried there.. The older 737NGX one I have contains these: #define MOUSE_FLAG_RIGHTSINGLE 0x80000000 #define MOUSE_FLAG_MIDDLESINGLE 0x40000000 #define MOUSE_FLAG_LEFTSINGLE 0x20000000 #define MOUSE_FLAG_RIGHTDOUBLE 0x10000000 #define MOUSE_FLAG_MIDDLEDOUBLE 0x08000000 #define MOUSE_FLAG_LEFTDOUBLE 0x04000000 #define MOUSE_FLAG_RIGHTDRAG 0x02000000 #define MOUSE_FLAG_MIDDLEDRAG 0x01000000 #define MOUSE_FLAG_LEFTDRAG 0x00800000 #define MOUSE_FLAG_MOVE 0x00400000 #define MOUSE_FLAG_DOWN_REPEAT 0x00200000 #define MOUSE_FLAG_RIGHTRELEASE 0x00080000 #define MOUSE_FLAG_MIDDLERELEASE 0x00040000 #define MOUSE_FLAG_LEFTRELEASE 0x00020000 #define MOUSE_FLAG_WHEEL_FLIP 0x00010000 // invert direction of mouse wheel #define MOUSE_FLAG_WHEEL_SKIP 0x00008000 // look at next 2 rect for mouse wheel commands #define MOUSE_FLAG_WHEEL_UP 0x00004000 #define MOUSE_FLAG_WHEEL_DOWN 0x00002000 You can use those, as they stand, as parameters. e.g 0x20000000 for single left click. Look at the actual aircraft on screen. when you operate a switch is it one click for off, or left, and another for on or right? This might give you a clue. Nothing wrong with asking, and I only close topics if folks start becoming offensive. Why are you regretting asking? I'm trying to help as much as I can with a product I don't know. Maybe the PMDG forum would be more suitable? I don't think any such thing. You asked how to calculate the addition of two numbers, and I asked if in fact you really didn't know, because I did not believe you wouldn't know! Hence my surprise you asked! You do read a lot which isn't there, don't you!? :-( Pete

The traffic ID is NOT the same as either the flight number or the tail number, which TrafficLook can display as well. The Traffic ID is the internal number used to uniquely identify that FS object. All objects have IDs. How do you think it can possibly do that without exercising any sort of control? Right, so its puts them into SLEW mode, as I suggested -- which is a specific FS control ("toggle slew"). Then it can move them about using the usual commands which you can do on your user aircraft in slew mode. All this is "control" and involves sending controls using the aircraft's ID to select it. Pete

Best usually just to paste the contents of the file into a message. Is this the complete log, after P3D appeared to finish? If so then the log shows precisely what the problem is -- FSUIPC never terminates, which means the P3D process is not terminating either. It is still running, presumably hung. Check in the Windows Task Manager. If it isn't listed as a running process, then the log you posted is not the final one. I would need to see the log after P3D is properly closed. Pete

Don't you know how t add two numbers, 69632 + 14024? Try using a calculator if not. I'm sure there's one on your PC. Pete

Just compute the number it states! The value of "THIRD_PARTY_EVENT_ID_MIN" will have been defined at the start of the list. This number is the "base" number it is using to separate all these controls from those used by FS (as listed in the List of Controls installed in your FSUIPC Documents folder). Then in Lua send it using the ipc.control function. It might need a parameter -- probably one to open it and a different one to close it. You could try 1 to open and 0 to close to start with, but otherwise you'll need to read more or ask around. Pete

No, sorry. I don't have any PMDG aircraft and have no idea what their L:Vars do, if anything. Are you sure using the toggle with a parameter value doesn't select other doors? On most aircraft you can have separate doors open/close with parameters 1 (same as omitted), 2, 3 and 4. Also, I thought that most every aspect of both the 737NGX and the 777X could be operated using the "custom controls" added by PMDG. There's a list in the .h document in the aircraft's SDK folder. I'v just found a copy of the older 737NGX file and it definitely contains these defined controls: #define EVT_DOOR_FWD_L (THIRD_PARTY_EVENT_ID_MIN + 14005) #define EVT_DOOR_FWD_R (THIRD_PARTY_EVENT_ID_MIN + 14006) #define EVT_DOOR_AFT_L (THIRD_PARTY_EVENT_ID_MIN + 14007) #define EVT_DOOR_AFT_R (THIRD_PARTY_EVENT_ID_MIN + 14008) #define EVT_DOOR_OVERWING_EXIT_L (THIRD_PARTY_EVENT_ID_MIN + 14009) #define EVT_DOOR_OVERWING_EXIT_R (THIRD_PARTY_EVENT_ID_MIN + 14010) #define EVT_DOOR_CARGO_FWD (THIRD_PARTY_EVENT_ID_MIN + 14013) // note number skip to match eDoors enum #define EVT_DOOR_CARGO_AFT (THIRD_PARTY_EVENT_ID_MIN + 14014) #define EVT_DOOR_EQUIPMENT_HATCH (THIRD_PARTY_EVENT_ID_MIN + 14015) #define EVT_DOOR_AIRSTAIR (THIRD_PARTY_EVENT_ID_MIN + 14016) I should think the 777X would have something similar defined. Pete

So, it seems that since the 3.4 release, P3D has a problem sending controls to specific AI Traffic by ID. It would be worth reporting this to L-M on their website -- but they'd probably need to know which specific controls are being ignored. It may not be all of them. I can only think of determining which controls work and which now don't by trying them. With FSUIPC, controls are sent via offset 2900. you'd need the ID, from Traffic Look. You could have a Lua program sending a different control each time you pressed a key or clicked a button and try to observe the effect of each, but really the first thing to find out is which controls AISeparation actually uses. Maybe it's then only one, crucial, one of those which is ineffective -- like trying ot control airspeed maybe. Not sure what control it would use for that. I also seem to remember that, at least at one time, you could only really control AI if you put then into SLEW mode. I think Radar Contact used to do that in order to stop AI runway encroachments when the user aircraft is on finals. I'm afraid I am away after this evening, until October 17th, so I can't really do much to assist in this at the moment. Maybe an appeal on the P3D Forum, or the L-M website, will elicit some feedback. BTW, in FSX days, the Traffic Explorer add-in, supplied in the SDK, had a facility to send controls to specific AI aircraft. I don't know if this is carried through into P3D, but it might be worth checking. Note that the traffic IDs used by that add-in are not the same as those in FSUIPC -- the latter ones are the 2's complement (i.e. the negative, treating the ID as a signed integer). This is historical, starting way back in FS9 days. Pete

In that case it certainly sounds like a change in P3D. Do you know for sure that AISpeparation uses FSUIPC? It does have a facility to send controls to AI aircraft, provided the correct ID nmber is retried first via FSUIPC's Traffic Tables (TCAS tables). Tell me, does TrafficLook show all the local traffic? That's where the information comes from. The ID is extracted from the TCAS tables, accessed via FSUIPC offsets, and controls sent to AI aircraft via offset 2900, which instigates normal SimConnect controls to affect the AI unit. Alternatively programs can interface directly with SimConnect to do the same thing, more efficiently (one less interface to go through). The only real facility FSUIPC offers in this area which cannot be done via SimConnect is the AI Traffic Zapper. Normally AI deletion can only be done by the program which created them. Pete

I suspect this is just LINDA complaining that FSUIPC is not responding. Please see previous message(s). Pete

You didn't say why you use "KILL" instead of the kinder "CLOSE", which is how you close it manually. I can't really help further till I see the log as per previous message. The KILL facility is most certainly working fine, so there's something odd and more information is needed -- hence all the extra logging I've added for you to get! Pete

Here's a link to the interim update: FSUIPC4957d.zip After tonight I will be away till October 17th, so there won't be a released update for a while. Pete

Here's an interim update. FSUIPC4957d.zip Please copy it into your Modules folder. Then edit the FSUIPC4.INI file, adding these lines to the [General] section: Debug=Please LogExtras=4 This will produce some extra logging when you close P3D. Here's an example from my system, with a program "FSInterrogate" successfully killed: ... 383247 === DLLStop called ... 383263 About to KILL process "\Device\HarddiskVolume6\FSInterrogate2\FSInterrogate2std.exe" 383263 === About to kill my timers ... 383466 === Restoring window procs ... 383466 === Unloading libraries ... 383466 === stopping other threads ... 386071 === Calling SimConnect_Close ... 386258 === SimConnect_Close done! 386258 === AI slots deleted! 386274 === Freeing button memory ... 386274 === Closing my Windows ... 386274 === Freeing FS libraries ... 387288 === Closing devices ... 387288 === Closing the Log ... Bye Bye! ... 387288 System time = 02/10/2016 12:31:49, Simulator time = 12:23:15 (12:23Z) 387288 *** FSUIPC log file being closed If the KILL attempt fails there will be different messages giving error information, so we can see what it going on. Please post the entire log so I can check the loading process as well. Please note that after this evening I will be off-line for two weeks -- back October 17th, so I'm sorry I'll be of no further help till then. Pete

I've found the reason. A parameter of 0 is indistinguishable from an omitted parameter, so no minimum is applied. The main use for assuming 0 is omission is so that input values, eg, from axis inputs, can be applied. I can see that this really wouldn't apply to limits. I can make this not apply to DEC and INC operations, though I'd be a little worried that this might adversely affect other applications of the facility where it might have been assumed that no limit means no limit applied. However, the documentation does state that the parameter sets the limit, so I've made the change in an interim version for you. I'll be uploading it soon and will post the link here. Pete

Are doors on the 777X operated by other than the standard FS "toggle aircraft exit" control? Pete