Pete Dowson

The conditional part of the entry is the same no matter what the "action" in the tail end is. Why do you think it doesn't support it? There's no difference in any part before the "C" or "K" indicating "Control" or "Keypress".. I see one problem in your assignments, though. Look, when I pair things up for the same button it shjould be glaringly obvious what's wrong: 9=P66,4,CM1:10,0 15=CP(+2,0)66,4,CM1:4,0 11=P66,8,CM1:8,0 17=CP(+2,0)66,8,CM1:13,0 12=P66,10,CM1:7,0 16=CP(+2,0)66,10,CM1:3,0 What do you think happens when you press buttons 66,4 or 66,8 or 66,10, no matter whether you "shift" (2,0) is pressed or not? The first of each pair is set to ALWAYS operate. If the shift is pressed too, the so with the other of the pair. If that is not what you want you should have the condition "shift button not pressed" on the currenty unconditional one of each pair, i.e. 9=CP(-2,0)66,4,CM1:10,0 15=CP(+2,0)66,4,CM1:4,0 11=CP(-2,0)66,8,CM1:8,0 17=CP(+2,0)66,8,CM1:13,0 12=CP(-2,0)66,10,CM1:7,0 16=CP(+2,0)66,10,CM1:3,0 Pete

But those offsets, 3370-3373 are just diagnostic values provided by my PFCFSX.DLL driver, which is only useful with the appropriate PFC manufactured hardware -- the 737 cockpit, in fact, the only serial port device they made with a motorised trim. As for your SIOC declarations and so forth, I'm afraid they are lost on me. I do not use and never have used SIOC and i don't know anything about it. Sorry, Pete

If you'd like to wait for the next FSUIPC4 release, possibly next week, then I'll have added an offset for the current Profile name (if any). It will be 0x9540 and will be limited to 63 characters plus zero terminator. If the current aircraft is not assigned to a Profile, or Profiles are not being used, then this will be a null string (i.e. just starting with the zero terminator). Pete

I think the only problem with some of the PMDG axes is if you assign "direct to FSUIPC calibration", because that bypasses the part of the aircraft code which wants to read the values. If you assign to the regular FS controls (axis throttleN set for each engine N) then the PMDG add-on cannot tell the difference between FSUIPC assignment and FSX assignment. They may also not like some axes being calibrated in FSUIPC, because this results in a lower level feed into FS of the post-calibration value. this may differ from the value the aircraft code picked up earlier. so causing conflict and/or weird behaviour. Pete

Sorry, I really do know absolutely nothing about instant replay. I used to use FSRecorder on occasion, but these days the facilities actually built into the nVidia "Geforce Experience" package for snapshots, frame rate measurement and video recording, far exceed anything I've ever used built specifically for (or into) FS. Pete

Hmm. Sounds like clarification is badly needed here! Never have controllers enabled at all in FS if you intend assigning axes in FSUIPC, otherwise it is always a major source of conflicts! Just trying to de-assign them in FS is no good. FS will often reassign them automatically. The only safe way is to disable the controllers in FS altogether, -- and even check now and then that they stay that way (which they should, ... but!). However, if you aren't using FSUIPC to assign controllers differently according to aircraft type or profile there's not necessarily all that much advantage in assigning in FSUIPC in the first place. I'm not sure why so many do so "as a rule" rather than out of some purpose, like automatic selection of correct control configuration. It doesn't matter whether you assign in FS or in FSUIPC, you can still calibrate in FSUIPC if you want to -- and that was the original function of those user facilities in FSUIPC, not for axis assignment! Pete

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