Pete Dowson

Hmmm. Nor can I at first glance (the FSUIPC4.LOG won't be copied in any case -- it isn't relevant, it's a run-time log of what FSUIPC does in the sim so it's specific to that sim). There is one odd anomaly, but it might be explained: This part: Checking if there's already a version of FSUIPC4 installed in: C:\Program Files (x86)\Lockheed Martin\Prepar3D v2\Modules\FSUIPC4.DLL ... No previous valid version found. Prepar3D v2 Modules folder already exists. Okay -- installed FSUIPC4 into "C:\Program Files (x86)\Lockheed Martin\Prepar3D v2\Modules\FSUIPC4.DLL" shows an existing Modules folder (made by what? A previous FSUIPC4 Install?), but with no FSUIPC4 module actually in it. Did you delete stuff in the Modules folder before running the Installer (again)? Although you found your way past the failure to copy those files, I am concerned and would like to fix whatever it is which could cause this to happen, so I will undertake some experiments here. Could you tell me whether you have UAC turned off or not in your Windows setup? Did you run the Installer with the right-click "as administrator" choice? I may have to add more logging to the Installer to show the copying of the files from the first through to the other folders, with results logged too. I might come back and ask if you'll test it for me. It would be with version 4.924. Not many changes from 4.923, but still. Thanks, Pete

Controls are controls, not values. They cannot be "read". They are merely encoded messages to FS to tell it to do something. I don't even have 66879 listed, nor anything called "launch bar".. Is this an add-on control, not even an FS one? If so then it's no wonder there's no "offset" for its status. If you want status values for add-on implementations you'll need to check their documentation or ask their developer. FSUIPC is an interface to FS. It knows nothing about add-ons (with few exceptions, like Project Magenta and the PMDG 737NGX). Some add-on implementers use FSUIPC offsets to provide access to things. Some provide other means. Maybe the one you want is encoded inside their gauges as an L:Var, and L:Vars can be read in Lua. Try logging L:Vars and see if it's there. Regards Pete

You must be using a very old FSUIPC Installer because all versions for a while now have accepted a different email address for WideFS. Your name must be exactly the same, though. Pete

There are two ways: 1. Enable Event logging in FSUIPC's logging tab, and use the switch or control and view the number and name in the log file, or 2. Just look in up in the List of controls document installed in your FSUIPC Documents folder. Just ipc.control(control number, parameter) (you can omit the parameter if it doesn't take one, or if zero is okay). This Lua function isn't a test of anything. There's no point in using "if" on it. What condition are you trying to test? Pete

Take a look at the FSUIPC4.LOG file, in the Modules folder. I think you'll find that there's been a SimConnect disconnection, and FSUIPC is trying to reconnect. This can happen when FSX is really overloaded and FSUIPC doesn't see responses from SimConnect for too long. It shouldn't happen at all, and when it does happen it is usually recovered withing a second or two. But if it persists then the Menu entry will disappear because there's no communication between FSUIPC and FSX via SimConnect. You can lengthen the timeout before FSUIPC begins the reconnection attempts. If the situation isn't too dire this may help. but the best thing to do is find the cause of the problem. Something is not allowing SimConnect to service all of its clients. Maybe a SimConnect log will help determine what (but beware, a full SimConnect log for a busy system will be really huge!). The FAQ subforum has a thread showing how to get a SmConnect log. The parameter to set the FSUIPC SimConnect timeouts is SimConnectStallTime=1. That's 1 second. Try 2 or more if you like. Pete

Good. Best Regards Pete

I think it would be a good idea for Linda to extend its button recognition to include the virtual buttons. It wouldn't be so difficult. Or maybe I can extend the Lua button test facility and events to cover virtual buttons also -- and maybe all the other button numbering which occurs for PFC serial devices and for joystick connections on WideFS clients. Perhaps you could ask such a question on their support forum? If they explain to me how they currently test for button presses I'd be happy to extend Lua support in such a direction as that would benefit everyone. Sorry, I really wouldn't know where to start either for add-on aircraft. They are all different with different techniques needed depending on how they are imnplemented. I don't actually use any add-on aircraft myself. Maybe you can find out by pulling apart the Linda code, but I don't think that's the right way to proceed. There are a number of aircraft supported by contributions in the User Contributions subforum. You could check therer, as a start. Regards Pete

Didn't you even bother to try logging as I suggested to see what controls, if any, the aircraft panel uses? That's generally the quickest and easiest way! Looking in the list of FSX controls (see your FSUIPC Documents folder) there are these: Toggle alternator1 Toggle alternator2 Toggle alternator3 Toggle alternator4 Did you not search on the word "alternator" at all? If you want specific separate On and Off you might find the Generator switch offsets in FSUIPC do the job. There are separate offsets for each engine generator. You'd assign to an Offset control in FSUIPC for those. Macro files can contain any normal FSUIPC control actions. The "mouse" macro variety, however, depends on the code in the Gauge. If it isn't suitable, it isn't suitable. It's black and white. Pete

I've now downloaded and installed the complete package from that thread, and tested it on COM and ADF radios, and it all works perfectly well. I am normally using FSUIPC 4.924 (to be released soon), but also specifically loaded the released version 4.923 with the same good results. I also see nothing in any of these Lua scripts which would invoke anything changed between version 4.92 and 4.923. Most of the changes between those were only in the Installer itself, and the others are internal hook changes for P3Dv2 affecting things like wind smoothing and mouse macros. There's also no apparent difference in any of the scripts which could account for two particular keys (. and 0) being treated any differently that the others (1-9), nor any differently between the different radios. So, sorry, I can't help. Perhaps you need to update to the latest package in that User Contrinutions thread I mentioned? Regards Pete

No backups? You don't need your copy of FSUIPC because you are always best downloading the latest in any case. I don't have anything to do with registrations and don't have any codes. You need to log into your account at SimMarket and retrieve your key from there. Same applies to anything you bought from SimMarket. Regards Pete

The DLL.XML is okay. Is the FSUIPC4.DLL in the FS Modules folder? If so is there an FSUIPC4.LOG file there? If so then show it to me please. If not, then FSUIPC4 is not being loaded, so it's something to do with it's Trust status or SimConnect. Did you tell FSX it was okay to run it when you first ran FSX and installing FSUIPC4? And then confirm it should be trusted? There will also be an Install Log in the Modules folder. Maybe that would help too. Pete

You don't say what aircraft this is with. Mouse macros only work on gauges written using the FS2004 C/C++ gauges SDK. Very few are these days, they changed to xml. Even most of the default Microsoft gauges can't be used in this way because they themselves did not stick to the Gauges SDK rules. Hang on, you just said you can't create a macro because the screen for testing it and naming it does not appear. Which is it? Ah. Two votes for no naming screen, one against. I assume your middle comment was talking about naming the File, not the specific macro? (Macro files can contain all of the macros needed for a specific aircraft, or indeed many aircraft). Ah, now we get to it -- you are using the default Baron? In that case almost all of the switches will correspond to specific FS controls which you can assign directly, without macros. Certainly the two switches you mention, alternators and fuel pumps, will have proper FS controls. Have you not looked for these? A quick way to determine the name of the FS control which is used for a switch action is to enable Event logging in FSUIPC's logging page. If you temporarily run FSX in Windowed mode, you can also enable the Console Log on the same page so you can see the effect of operating switches in real time. Certainly some of the functions in the Baron which relate only to the modes of specific gauges won't use controls and won't be programmable. That's because they only have local effect, on that gauge, and don't have any other consequences. For a complete cockpit build that shouldn't matter because your own instrumentation and displays would presumably have their own controls for these. For example, my 737NG cockpit uses Project Magenta software and it obviously controls its own displays. BTW doesn't the PM GA software handle all the switches you need? Or is that only in PMsystems -- do you have that package too, for GA? Regards Pete

Ah, you don't actually understand these scripts? Have you tried asking the author for assistance? I don't really understand what they are trying to do -- the assorted "ipc.get" and "ipc.set" actions imply they are part of some bigger control part. Additionally, neither of these actually set anything to the radios in FS -- they READ the current radio values, but all they then do is display the values in a message on screen.for 8 seconds. Evidently there's more -- there's nothing in these to go wrong excepting maybe get the message wrong ... does the ADF message look wrong? How do you use them? In other words, what do you assign in FSUIPC and how do you operate? Are there instructions anywhere? If the ADF is not getting set correctly it is because of an error in another part, somewhere, not in these as they do't set anything. Nor do they appear to try to change anything, for that matter. BTW next time you post code samples etc please use the little <> button above the editing area here with the code all selected so it wraps it in a selection box -- this keeps trhe formatting intact and makes it easier for me to save and use as a file. [LATER] Are the scripts you are using related to the ones downloadable from the User Contributions subforum here, in the thread "Setting FSX Radios, OBSs and the Autopilot Using the Keyboard Numberpad"? If so then yours looks out of date. Can you try the latest one there, less than a month old now? Thanks, Pete

I see no scripts, and to be honest I don't have time to plough through Lua programs to find the bit not working. I would be grateful if you'd just supply a little example of what doesn't work, please. Try pasting stuff into messages. Trying to attach things here is problematic. I was hoping to release an update on Monday, so if you are quick enough, and succinct enough, I might be able to sort it for then. Otherwise it goes back another week. Regards Pete

They don't confide in me, but there was a reply to one of my reports in the LM Forum which implied they would fix the hings I mentioned, that one included. In FSUIPC 4.924, due for release next week, I have added an option "P3Dv2Fiddles=Yes" which will make FSUIPC implement workarounds for the little problems I found so far: 1. Using the Key event for toggling the master battery, because the SimVar writing for ELECTRICAL MASTER BATTERY now does nothing, and 2. Saving FLT fdiles in Autosave so they can be reloaded by my Load menu entry, and 3. Not offering to try to load .FXML files in that same facility. I might retain (2) even when the LoadFlight for FXML files is fixed, as specifying .FLT for saving appears to save both FLT and FXML formats, which might be useful. ;-) Pete

"The latest version" is meaningless. Please always give the version number. FSUIPC doesn't touch any controls unless you tell it to. It sounds very much like you have the yoke assigned both in FSX and in FSUIPC, and the two different inputs are conflicting. Only use one or the other place for assignments. Pete

Okay. And ...? Did you run WideClient on your non-FS PC? Did you start FS on your FS PC? What programs are you trying to run on WideFS on your client PC? Did they connect or not? I'm trying to get you to tell me what the problem is -- what you are doing, what you are not understanding. You are not telling me anything. Regards Pete

When you say you "installed WideFS", what exactly do you mean? There's no installation to be done on the FSX PC, only entering your registration in the FSUIPC Installer. On the Client you simply place WideClient wherever you want, then run it. That's it. Pete

Hmm. That's strange. When I get a moment I'll check into that. Should be able to do that easily. 55 mSecs is a lifetime in any case, and if the command is actually processed it should operate. Maybe I'm checking the terminate flag BEFORE execution rather than AFTER -- but even then, there's loads of time. Pete

I'm not sure I understand what you mean. You only need to use the Rescan to make it find another joystick axis once it has seen one. If you are not seeing any why is the Rescan relevant? What does "look crazy" mean? Well, FSUIPC depends entirely upon Registry entries to relate Windows Joystick API device numbers (0-15) to the actual DirectInput devices. When FSUIPC scans for devices and identifies them in the Registry, it updates the joystick names section of the INI file with the numbers, names and GUIDs of each device it finds. Are yours there? If so then it the registry should be fine. If not, then that's the problem. To be sure it is actually setting those, however, delete the existing section and let it build again (don't delete the letter assignment lines if you are using joystick letter assignments). A reinstall of what? Windows, FS or FSUIPC? I don't think the latter two can make any difference. Maybe unplugging then deleting the devices from the Device Manager, then re-booting and plugging them in again might get them re-registered. If you add the following to the [General] section of the FSUIPC4.INI file then it will log details of exactly what it is doing and seeing: Debug=Please LogExtras=x200008 Regards Pete

Why not use the facility to remove the menu immediately (see para starting "When you no longer need the menu entry ...."). Is it always -32000,-32000? I can't simply change any negatives because folks with multiple screens and a centre one as default can place windows in negative coordinate territory. Better, I think, if I can, is detect that it is minimised and not change whatver coordinates were last saved. Regards Pete

Sorry, I need more information. Nothing's changed in any area of FSUIPC which could affect this. I casn't imasgine what would be different with ADF compared to others in terms of character recognition. Can you show me the code which doesn't work? I'd need to be able to reproduce it here. Pete

There's no action in FSUIPC to try to fix any G3D crashes in P3D version 2 -- I'd hoped they'd fixed the only one I found and trapped. I'd rather not have to do this again. And in any case, there have always been a lot of G3D crashes which FSUIPC couldn't help with. Since P3D v2 is being actively supported and developed, please report these errors to Lockheed Martin on their Forum, along with all those details. They'll probably need to know exactly what add-ons you are using -- especialy aircraft, scenery and AI traffic, all the things which invoke the 3D graphics machine. Pete

Yes, of course. Gradually little errors in the document are coming to light. I've corrected it here so it will be okay on the next release. Thanks, Pete

Yes, the same as here -- see my previous reply. This happens to me as well even without FSUIPC installed, and with 4.92 and 4.923. I gave my explanation in that previous message. It's over to Wilco now. It is not related to FSUIPC at all. I did not ask you for the files themselves -- you only need t paste their contents into your message, as I said. But it does not matter now -- please read my earlier message which I think you missed. Regards Pete