Pete Dowson

Not the profile name, at least not at present. You can get the current aircraft title, but not the profile it is assigned to. But if it is useful I could add this, in the next FSUIPC4 update I should think. Pete

Okay. And presumably you are using a PFC 737 cockpit fitted with the motorised trim? And you are using the current version of the PFCFSX.DLL driver? Sorry, how does SIOC relate to PFC hardware? I'm lost! Pete

I found it very VERY difficult reading your miniscule script, so did not manage all of it, but you mention A2A. Have you seen this thread? http://forum.simflight.com/topic/78888-sudden-lose-of-assignments I think there must be something you've installed, probably with A2A, which is preventing any recognition of buttons using the normal DirectInput functions used by FSUIPC -- and, for that matter, fS itself. Have you checked to see if that detects buttons? Pete

No idea. It was a value available in FS98 and FS2000. As the Programmer's Guide offset list says it may not do anything in FS2002 and there's a question against FS2004. No one has ever provided any feedback on it. It isn't supported in FSX and P3D as clearly shown in the FSUIPC4 offsets status list. I don't even know if anyone ever used it in FS98! Pete

No. FSUIPC knows nothing about instant replays or their timers. The autosave merely saves Flights in exactly the same way as when you do it, via the menu or via pressing ; and entering a name. The only difference with FSUIPC Autosave is that it does it automatically and it generates the name for you. It calls exactly the same flight save facility. See if just saving a flight also "loses" you replays. If so, then that's just how FS is designed to work. Pete

Uninstalling / reinstalling FSUIPC never makes any difference as you are only replacing the DLL with the same DLL. The only thing making a difference for FSUIPC would be deleting the INI file, so removing all your settings. You could try just renaming it so a new default is made, then test the mixture axis. You don't lose anything as you can always rename the original back after the test. But on the whole, I would think it was drivers of one sort or another. Just not running their "front-end" programs may not stop them doing their own thing. You might need to uninstall them entirely. Pete

Try setting up with a default aircraft. If there's still a problem it is more likely to be conflicts with assignments elsewhere -- possibly FS. Check that you've disabled controllers in FS before trying to assign in FSUIPC. Pete

FSInterrogate as a reference is only as good as the data files (.fsi files) it is supplied with. I think the ones in the package are the originals, well out of date in any case and missing many of the later details added for FSX, and even some changed for FS9. According to the original Offsets list (the "programmers guide" in the SDK), 060E held a retractable gear flag, 0 if false, 1 if true. 060E had instead a numeric value -- 0 not, 1 retractable, 2 sliders. However, they are both marked as not applicable to FS2002 and FS2004 -- so only FS98 and FS2000. The use of 060C as 0 or 1 (only) was resurrected in FSX, as shown in the FSUIPC4 offsets status document. I think, maybe, 060E should have been used instead, but since both has been out of use for 6 years by then I suppose no one noticed or cared. Interestingly, and incorrectly, if you go to the Edit screen for 060E in FSInterrogate it shows it valid for FS98 and FS2000 and FSX, whereas 060C is marked as FS98 and FS2000 only. Evidently it was edited incorrectly at some time, probably 9 years ago. Really the data file needs re-editing, patiently and carefully by someone with time and patience. Meanwhile, best to use the documents provided, as you now say. ;-) Pete

It "suddenly stopped working" all by itself, just like that, with no change, nothing affecting it? Do you have any information to offer at all? First, simple stuff. What version of FS? FS2000, FS2002, FS2004, FSX, P3D, FSX-SE? Which version of FSUIPC? (If not the current one, 3.999z8 or 3.999z9 for FS9 and before, or 4.939e for FSx and later), then please update first, THEN report if you still have a problem! old versions just cannot be supported! And then, second: how do you identify FSUIPC as the culprit? Please also explain exactly what happened and how you arrived there. All you say is "in my opinion causing fatal errors". How do you arrive at such an opinion? Third is, yes, to provide actual information in black and white please -- the FSUIPC log file from the FS modules folder, the crash report from Windows event viewer, the list of other add-ons you were using at the time. Pete

No, at present FSUIPC also only receives data from normal joystick devices when something changes. I think, in theory at least, it might receive all 32 switches and 8 axes when any one of all those changes, because they are all in one structure, but I don't think there's a way to poll them instead of just receiving inputs like that. It can probably be done by directly accessing them as USB HID devices rather than using the DirectInput joystick API. That can be done using the HID facilities in the Lua COM library, as you can see from some of the examples provided. Maybe you can put together a Lua plug-in to do exactly as you wish? I'm very reluctant to mess now with the innards of FSUIPC's device facilities -- they have been developed and grown continuously for many many years and any changes I make to the code are precarious as I'm forgetting things nowadays! This is in fact why I added the Lua facilities, so that FSUIPC's capabilities could be extended without messing with its internals! If you decide to undertake such a thing, I will give you as much help as I can and hope that the end result might be useful to others and so be published in the User Contributions subforum, or even added to the range of examples in the installed Lua package. It''s using DirectInput and the Windows Joy API -- Simconnect didn't exist before FSX, and these facilities are older. But the reason SimConnect is thus limited is the same, it is more about the way DirectInput works. Regards Pete

No, the switches are only seen when they change state. I always start flights in "cold & dark" mode, and just ensure I set all my switches accordingly, normally before I shutdown, but if not at least whilst things are loading up. If not, here's an idea for a solution: Sorry I don't know if it is feasible since I don't understand it. What is reading the state of the hardware switches, and how? And what is "your aircraft's SimConnect Client"? Is that different to SimConnect running in FS and being used by FSUIPC? If your aircraft interfaces to SimConnect, wat exactly are you using FSUIPC for? Regards Pete

Does that add-on aircraft have its own autopilot? If so, if it doesn't use the FS one, then you probably cannot use FS controls to control it. Is there any documentation with it which suggests ways of controlling the autopilot without having to use the mouse? Apart from using standard FS controls, or assigned keystrokes, the only alternatives I am aware of are: 1. Mouse macros, which only work on gauges written strictly according to the Microsoft gauge SDK -- not much used these days, more likely in FS9. 2. Local panel variables (L:Vars), which are used more and more in XML gauges. I'm afraid I wouldn't know whether that add-on aircraft can support either of these alternatives. Regards Pete

I forgot also to suggest the use of event.timer to give your 30 seconds playing time. Use event.timer with 30 secs set when you start a sound, then event.delete for that timer call when you do stop it. Then the whole thing is ultra efficient ;-), being completely event based and therefore not actually occupying the processor much at all. I realised, afterwards, that if you don't do this change as well as what I suggested then what I suggested won't work, because events cannot be triggered UNTIL your program exits -- they operate on a program waiting for such, not on one looping continuously. Pete

I'm not sure how you are identifying this as an FSUIPC problem? Are you assigning in FS or in FSUIPC? You don't say. Are you using the CH control manager? If so I'd check thst, and maybe stop using it -- others say it gives problems. If you have assigned in FSUIPC, then it simply acts on values received from the connected device. Have you checked that Windows itself responds correctly, eg, in the Windows game controllers where you should first calibrate them? You supplied a log which was made without enabling any axis logging or stating what you were doing that the log is supposed to represent. The only interesting thing it contains is these three lines: 83367 ***** HID USB device reconnected: re-initialising FSUIPC connections 85832 ***** HID USB device reconnected: re-initialising FSUIPC connections 88406 ***** HID USB device reconnected: re-initialising FSUIPC connections showing devices which were presumably disconnected before this time (83 seconds into the session) reconnecting. Did you disconnect them? If not, and you have turned off USB power management in Windows, then I suspect you have a faulty device, or USB hub, or wiring. Please check whether the levers are actually working. Please also distinguish between assignments made in FSUIPC and in FSX -- you don't actually say what you are using FSUIPC for, and I cannot guess. Oh, please don't post pictures which are barely readable and don't really tell me anything -- especially with no explanation about what they purport to show, and rather than attach files it is best to simply paste their content into your message. Use the <> button above the edit area to enclose them. Regards Pete

Lua Kill merely ruthlessly terminates the thread running that Lua program. It can't stop some activity, carried out in this case by the sound driver, continuing doing whatever your Lua program instigated. "sound.stop" is the only function which will stop a sound set to loop. Interesting you went to the trouble of finding that function. You could have used the built in one, ipc.elapsedtime. If you want to stop the sound prematurely I suggest you use an event.Probably the best is to use event.param, and assign whatever button you wish to use to "LuaValue" to set the parameter. The event.param should call a function to stop the sound. In fact, if you have many sounds but you want to only play one at a time, you might find it neater to play them all in one Lua program, using the parameter value from an event to determine which one to play, automatically terminating the previous one. Note that event based programs do not terminate themselves, and you'd normally start the program using the [Auto] facility in the INI file to run it at program start up. It could just sit there waiting for the right parameter call to start a sound. Pete

The latest version is not 4.939d but 4.939e. FSUIPC has nothing to do with AI_Player excepting only that one hook, for AI deletion, and that isn't activated anyway unless you are using an FSUIPC client application which uses it, like AISmooth, AIDupe, AI traffic optimiser etc. Shouldn't you have updated your Prepar3D to 12944 by now in any case? Don't you think that would be worth doing, to get up to date both with P3D and FSUIPC? BTW, crash details in modules other than FSUIPC4 are generally of no use to me at all since I cannot support other folks programs and know little about the insides of most FS and P3D modules. The only use of the above report really was to show you are using 12943 instead the the current release 12944. Regards Pete

That was an error in placing the hook for AI traffic deletion, a facility used by some add-ons. And it was fixed, as it says. Pete

Sorry, I do not have any PMDG aircraft. Doesn't the documentation help? Can't you assign a key stroke in its options? Pete

No, FSUIPC does nothing to help or hinder AI_Player. Sorry. Usually crashes in that are due to corrupted textures in one or other of the AI aircraft being loaded. I've never known it to crash for any other reasons. Sometimes it's one specific aircraft livery and then of course only occurs when you are near enough to an airport or flight path of such an aircraft. I know there are some add-on airports which do come with a minor amount of traffic. Additionally, all moving airport ground traffic are AI -- you'd need to move the slider for that to zero too.. You could try reinstalling GSX as that is providing a lot of ground traffic. Pete

I don't know about "quick ILS", but providing you are using the latest MakeRunways, then there's no problem with any version of P3D. Although they've changed some files around in version 2.5, the scenery.cfg file is still in its correct place. Maybe you are one of the folks who are using P3D renamed to FSX, for some complex migration or installation reasons? If so, then MakeRunways will be looking in the wrong place, for sure! Pete

Hmm. I don't think that's an FSX message, it'll be one of your other Simconnect client programs. There's nothing wrong there, either. If you want to check that FSUIPC is doing what you ask, simply enable Button/Key logging and it will make entries in the log revealing the button pressed and the action taken. Ah, thanks for the clarification Paul. Pete

What is the "Simconnect error has been detected ..." message? Sorry, that's a new one on me. Can you be more explicit? How about showing me the contents of the FSUIPC4 log file? You'll find it in the FSX modules folder. Don't reinstall FSUIPC unless you are using an old version. Current is 4.939e. Pete

Sorry, I've no idea because I don't know why they disconnect in the first place. Nor do I understand why or how FSUIPC could possibly help in such matters as it uses precisely the same Windows API methods as FS and P3D. On the first point, again, I don't know. Those are questions best directed to L-M on their Forums. But on the second point, I and many others have dual installs of FSX and P3D (in my case, FSX, FSX-SE, P3D1.4 and P3D2.5+hotfixes), and there is really no way I see they can interact with each other. No. The joystick reading is direct via Windows, no SimConnect relationship at all. And each SimConnect DLL can be used independently according to how the application has been built. FSUIPC is flexible and uses any version, but for P3D it normally uses the one it installs itself in the Modules folder. It does that because by default P3D didn't use to install any Simconnect DLL in the Windows SxS system Regards Pete

I have received this advice for Win8.1 users, from my good friend Thomas. He says that with thse changes in Windows he has solved the spontanjeous disconnection of joystick and other USB devices: Action: - Open Energy Options (might be Power Options like in Win7) in Control Panel - Then go to change Energy Saving Options of the selected Energy Saving Plan - There like always everything should be set to always ON … - Then select Advanced Options on that page - On that new panel (Energy Options) under the selected Energy Saving Plan there are two setting to take care of o Energy Saving, again everything should be set to No saving/ Always ON .. o USB-Settings -> Selective USB Energy Saving -> Deactivated/ Disabled The first Energy Setting is just global and makes you to believe it includes USB but it doesn’t. The second one, Selective USB Energy Saving doesn’t give you any idea for what it really is or what it does but it needs to be Disabled to keep the devices alive. Not even the Help button does give any help about those settings … Hope this helps ... Pete

Yes, of course, though I didn't study every line in the attached files. I don't think I "assumed" that, I read it the words you wrote! But if you believe your USB connections are perfectly fine and something else is going on, perhaps you can explain what you really think? Okay. So what do YOU think could be going on? Well if you never updated P3D either then I suppose it doesn't matter so much, but certainly I cannot support old versions. I can only report on what I got from my friend, to stop USB disconnections. If really you are not getting any such problemsthen you need to be more explicit on what the problems are, because your message was explaining exactly that! Here is his recommendations for steps that have worked perfectly for him: - Open Energy Options (might be Power Options like in Win7) in Control Panel - Then go to change Energy Saving Options of the selected Energy Saving Plan - There like always everything should be set to always ON … - Then select Advanced Options on that page - On that new panel (Energy Options) under the selected Energy Saving Plan there are two setting to take care of o Energy Saving, again everything should be set to No saving/ Always ON .. o USB-Settings -> Selective USB Energy Saving -> Deactivated/ Disabled The first Energy Setting is just global and makes you to believe it includes USB but it doesn’t. The second one, Selective USB Energy Saving doesn’t give you any idea for what it really is or what it does but it needs to be Disabled to keep the devices alive. Not even the Help button does give any help about those settings … I will probably make a FAQ subforum entry for this, but do please let me know. Pete