Pete Dowson

The FSUIPC Lua documentation is in the same folder! Just place the Lua into the Modules folder, and assign a button or keypress to that ("Lua recordtocsv"). Or you can make it run automatically in one of several ways as documented. Pete

No, L-M have only implemented the capturing of the SimConnect texts and menus. This was really the main expectation. Inbuilt stuff like ATC is a different matter altogether. If this is a requirement in any demand then those needing it should tell L-M. I must admit that I've not found this to be the case -- most folks with such sophisticated needs have surely moved to better ATC solutions? There's no shortage. I don't get notification of that, yet -- same as when Menus are closed. This seems to be set to be fixed with the next P3D4 update though. Pete

There is already a lua plug-in supplied as an example which does that and more. Please see the Example plug-ins ZIP file you your FSUIPC Documents folder (in the Modules folder) where you will see one called "RecordToCSV.lua". It is currently set to record time (local and Zulu), lat, lon, alt, pitch, bank, hdgTrue and hdgMag at 20 times per second (approx -- depends on P3d loading of course). It would be easy to edit it to reduce the amount logged, and maybe increase the rate. Pete

I'm afraid that, if you have not previously assigned Ctrl+Shift+F2 as a hot key in FSUIPC, this cannot be anything to do with FSUIPC. There's no difference to it at all between whatever keys you use, they are just numbers and no difference is made for the different function or text keys. And in any case there is absolutely no way FSUIPC can cause your keyboard to lock up. Maybe you have some other software running which uses F2 in a combination as a "hotkey" and is doing something then. You'll need to check more thoroughly. Pete

Assign them to increment or decrement an FSUIPC User Offset (in the 66C0-66FF range), then use a Lua plug-in to send the value to you have changed to the relevant L:Var. Pete

FSUIPC can only off whatever Flight Sim provides, from its nuilt-in facilities, and I'm afraid scant attention is paid there to the pressurisation panel. Add-ons like PMDG's aircraft supply their own. You need ProSim's help with that, or elase Open Cockpits for details of how to modify their script to deal with your specific hardware build. I'm sure you should get advice for one or the other if not both. The only thing I can think off would be for you to get ProSim to write the values to an FSUIPC user offset (something in the region 66C0 to 66FF, an then write yourself a little Lua plug-in to convert that to the form you want, in other User Offsets. After that t should be easy enough to modify the Script to suit your build. You should never have to delete your setting! When you update just run the Installer!!! No settings are ever changed! Pete

I've moved your post to the FSUIPC Support forum, as you posted to the forum for the FSUIPC client.DLL, which is a programmers tool. Pleasedo choose the correect place in future. They are the same thing!!! The order of the shift keys is irrelevant as no action is taken until the main key is pressed! Not opposites, identical! Why do you think they are wrong? How do you think the order of keys detected and acted upon together matters -- only the main activation key, the text or function key, does anything. The ancillary or shift keys merely set flags saying they are pressed! Pete

Did it come with software needed for those planes it does support? If it is not a standard USB device, and i very much doubt it is, then it does need its own drivers to read and interpret the switches, and send the correct data to the displays and gauges. This can be done with a Lua plug-in for FSUIPC, but it is a true programming job which would also need fully detailed information about the encoding in the USB traffic. If VRI do not supply such information, then the only way would be via a careful investigation into the USB traffic between the device and the PC when it is being used normally by the software supplied by VRI. That needs a USB monitor program. I have done that sort of work before and it is quite interesting, but it is impossible without having the device itself. If you are not a programmer your best bets are: 1. Appealing to VRI to support the aircraft you want to use, or 2. Finding another user of that overhead who is also a programmer and who would be willing to take on such a task. However, if you only want to be able to use a few switches, like the lights, it becomes a little easier, but still involving a little Lua programming. The com library in Lua provides quite good HID facilities which allow simple Lua plug-ins to determine switch settings. See the HidDemo.lua plug-in provided in your Examples ZIP (in the FSUIPC documents folder). Pete

... Yes, because you let P3D install into its default place, and Program Files is protected. I always advise changing that install path. i use simple short paths like C:\P3Dv4, or better on a different drive, D:\P3Dv4. Much easier to find! ;-) Anyway, you solved it -- for Makerunways at least. There might be other programs with access problems. Pete

If there's a keyboard shortcut for it, then yes, you can assign a button to send that shortcut. If not see if it is susceptible to mouse Macro use -- if you are using P3D4 and the latest FSUIPC5 then it will be as now ALL mouse actions can be programmed. Otherwise the only thing I can think is whether it uses local panel variables (L:Vars). If so you can probably make a macro for it. Use the FSUIPC added control to list Lvars, or, better, the supplied lua plug-in to log them as they change. Pete

Not surprised, as you aren't really changing anything, are you? The symproms you describe more often apply to Saitek levers, but can happen to any. It's because in the Registry those axes are defined as "digital" (i.e. either on or off, not a continuous analogue input). With P3D it will depend what mode it is set to use. I think it defaults to "Direct" which bypasses the Windows DirectInput. This is not what FSX or FSX-SE do, nor FSUIPC, all of which use the DirectInput system and are therefore subject to what Windows dictates. Mostly I am told this sort of problem is fixed by uninstalling the device, driver and all, from inside the Windows Device Manager, then re-booting the system with the device connected. Don't install any CH software. If that doesn't work then it might be a matter of Registry Editing. The thread in the FAQ subforum will be of help there: However, where it says in items 5 and 7: Delete any folder inside the Direct Input folder that begins VID_06A3 or VID_0738, if you know the specific PID number or your device then you only need to delete the string that matches the VID and PID. use your device's details, seen in the FSUIPC Log thus: VID_068E&PID_00FA Pete

Ah, the authors would have had to "fiddle" it, as the sim doesn't support sloping runways (yet). The 3 feet part will be flat! ;-) Pete

I'm not sure the parameter will accept such ridiculous lengths. Try and see -- let me know. But in any case it won't include runway 15 for LFKX. For the commercial one I think you should report this to the authors or company. Pete

EDRM is defined with one 10ft long runways: Start 18 : N49:58:16.7341 E007:06:42.4181 919ft Hdg: 180.0T, Length 10ft Start 36 : N49:57:52.1144 E007:06:41.5910 919ft Hdg: 0.0T, Length 10ft Hdg: 180.000 true (MagVar -1.000), Grass, 10 x 3 ft In fact in this runway seems to be defined as a piece of Grass, 10 feet long by 3 feet wide! If you read the document which comes with MakeRunways you can see that you need a command line parameter to tell it to include short runways, but 10 x 3 seems too small even for a Helipad! LFKX has this defined: Runway 15 closed for take-off Start 33 : N45:24:21.7294 E006:34:42.9276 5638ft Hdg: 333.0T, Length 3ft Hdg: 11.000 true (MagVar 1.000), UNKNOWN 254, 3 x 3 ft This one has a missing Start point for the runway 15 end, and again it is too short at 3 feet (3 x 3!!!???) and uses an undocumented surface type code (254). I suspect these sceneries have been made for visual effect and are not intended for use by AI traffic or other external programs. You would be able to correct these things using something like ADE (freeware), but I'm afraid MakeRunways can only process the data it is provided with in the Airport Definition BGLs. Pete

That's as maybe, but that would definitely be a lot more work than I can contemplate at present. I would, in any case, have to start by having profile-specific LuaFiles index sections in the main INI ... [LuaFiles.<ProfileName>]. If I'm doing that it should probably also apply to the MacroFiles section. Once that is implemented it would fall naturally into the Profile Files path system. This isn't related the the simple LuaPath facility I've now implemented and which is in test. Anyway, I'll think about it when I've got more time to spare (and am bored flying for a change and want to get back to programming!). Sorry, but I've not actually managed to fly my gorgeous 737 cockpit now for weeks! Pete

My colleague Thomas has been hunting for examples where other than 1252 encoding is used in P3D. These are the only UTF-8 ones found so far (also a UTF-16!). Note that none are DLL.XML files: for P3Dv3 DefaultRecordAndPlayback.xml DISConfiguration.xml LWcfg.xml --> <?xml version="1.0" encoding="UTF-16"?> WaterConstantsV3.xml for P3Dv4 LWcfg.xml WaterConstants.xml Thanks Thomas! Pete

So they have a digital speedbrake with what, only off, armed, flight and landing? No intermediate positions possible? If so, you CAN still assign to those button actions using an axis. it's a bit more complicated. basically you use the right-hand side of the Axis Assignments dialogue instead, don't assign on the left to an axis control. You'd define positions (actually zones) on the slider movement where you want the different assignments to operate, on the way up, down or both. See page 37 of the FSUIPC5 User guide. Pete

Some examples: From the P3D3 Traffic Toolbox SDK: <?xml version="1.0" encoding="Windows-1252"?> <SimBase.Document Type="Launch" version="1,0"> <Descr>Launch</Descr> <Filename>dll.xml</Filename> <Disabled>False</Disabled> <Launch.ManualLoad>False</Launch.ManualLoad> <Launch.Addon> <Name>Traffic Toolbox</Name> <Disabled>False</Disabled> <ManualLoad>False</ManualLoad> <Path>SDK\Environment SDK\Traffic Toolbox SDK\traffictoolbox.dll</Path> </Launch.Addon> </SimBase.Document> From the P3D SimConnect SDK: (Meant as the base example to start from for addons like FSUIPC) <?xml version="1.0" encoding="Windows-1252"?> <SimBase.Document Type="Launch" version="1,0"> <Descr>Launch</Descr> <Filename>DLL.xml</Filename> <Disabled>False</Disabled> <Launch.ManualLoad>True</Launch.ManualLoad> <Launch.Addon> <Disabled>True</Disabled> <ManualLoad>False</ManualLoad> <Name>Addon DLL</Name> <Path>C:\MyPath\Addon.dll</Path> </Launch.Addon> </SimBase.Document> And, to go back a lot longer, from the FSX Traffic Toolbox SDK <?xml version="1.0" encoding="Windows-1252"?> <SimBase.Document Type="Launch" version="1,0"> <Descr>Launch</Descr> <Filename>dll.xml</Filename> <Disabled>False</Disabled> <Launch.ManualLoad>False</Launch.ManualLoad> <Launch.Addon> <Name>Traffic Toolbox</Name> <Disabled>False</Disabled> <ManualLoad>False</ManualLoad> <Path>..\Microsoft Flight Simulator X SDK\SDK\Environment Kit\Traffic Toolbox SDK\traffictoolbox.dll</Path> </Launch.Addon> </SimBase.Document> Quite honestly I think the vast majority of users have always had this 1252 setting, right back to 2006! It can't have done them any harm? Pete

Speed brake is known as "spoiler", so simple assign to the spoiler axis. Of course, PMDG might be doing their own thing and may need an alternative approach using their own added controls, but try the "axis spoiler set" control first. Buttons aren't really relevant for an axis. Pete

Actually, as my colleague Thomas has pointed out, when FSUIPC does need to amend the DLL it will replace that line. And it's line is with 1252 because that has always beem to my knowledge, the default for FSX and L-M. By all means, please check the Microsoft and L-M examples and defaults supplied in the SDK yourself. I didn't check them all, but all those I did check definitely had 1252. Not that I would know the difference in any case, to be honest. I didn't invent the number 1252, it was just the value I didn't want to change. Is it a problem in some way? Pete

I've had a look at the implementation, and to keep it easy and not involve quite a hefty rewrite in order to expand the tables to accommodate more encoding information (something I'm not willing to contemplate as it would compromise stability), I will only be implementing an "either/or" setup. i.e. you either have all the Lua files in the Modules folder, or in another. The limit will still be 127 and the numbering in the [Luafiles] section of the INI will still be based on the order of the Luas in the folder, as discovered initially (i.e when they first appeared). The numbering will stay the same if you merely copy all the Lua files out of the Modules folder and into the new one. The path will be specified by a "LuaPath" parameter in the [LuaFiles] section, and can be a subpath of Modules (in which case just give the subpath), or a full path anywhere elsewhere on the same PC (determined by seeing a ':' character in the path, denoting a drive spec). If this is not sufficient to meet your needs, please say so. I don't think I can offer more, at least not until there's a lot more time to spare to do a re-design of assignment encoding internally and plan the subsequent weeks or months of re-testing. This is really not likely to happen before I retire and hand over ongoing development. Pete

Okay. Thanks for the explanation. I understand more now, Seems you have really got into Lua in a big way!. I'm not anywhere near as sophisticated in my efforts, but then I have a dedicated 738 cockpit and Prosim737 does most of the heavy lifting, and my own C/C++ drivers handle the hardware itself (I'm a far better C programmer than a Lua one). I''m actually very pleased that the Plug-in system has proved so useful for the more ambitious users! I'll certainly see about adding a path scanning ability in the next update, but it might be an interim (DLL only) release. Pete

That isn't true. Check all the DLL examples in the FSX and P3D SDKs. They are have this first line: <?xml version="1.0" encoding="Windows-1252"?> If the file already exists the FSUIPC Installer (FSUIPC4 and FSUIPC5) merely reads the file, as a text file (not XML) and adds its own section then writes it back, as is, with no other change. It doesn't use any sort of XML editor or converter, just normal file I/O. The title line remains as it was when read. It has to! Perhaps you've been using some other XML editor or installer which is misleading you? Pete

Well, I don't really think your use of Lua plug-ins is likely to be the best way to go (especially if, as it sounds, each of those is loaded, compiled and executed each time an assigned button, switch or axis movement occurs, which it sounds like), but I'll certainly seriously consider doing what you ask in FSUIPC5. Mostly, especially for specific aircraft, most plug-ins can be compiled and pre-loaded, using the event system. that way there is the one extra thread ready and waiting for the signals it needs to operate. Also, macros can operate L:Vars with variable parameters allowing axis use. However, since you're obviously happy enough with what you've already implemented, I can understand your need. I just think it isn't such a widespread a need as you suggest. Well, Mouse Macros don't use the mouse at all except for their initial creation. That's the point -- to do without needing the mouse! I would have thought you needed to use the mouse to determine the way to use L:Vars in the first place? Or not? Anyway, I'll put yor request on my list. Pete

Version 5.131 is now available. Pete