Pete Dowson

Ooops! Yes, I can reproduce this. Fixing it now -- look for 4.699 soon ... Pete

I'm sorry but I don't use LINDA and know little about it. didn't you find the crash details, which might help/ By all means try the next FSUIPC update, where I've changed the close down order, but it might be worthwhile also asking in the LINDA forum. Pete

This is where your P3D is. Right? This is where your DLL.XML file is: But the install log isn't finished. you end with: but the log should terminate properly, in some way similar to this: =========================================================== All installer tasks completed. Registration dialog 'not now' selected *************** End of Install Log *************** So, please describe what happens to make the installer fail early. What exactly happens? And where are you actually looking to find the documentation? It has most certainly been placed into C:\Program Files (x86)\Lockheed Martin\Prepar3D v3\Modules\FSUIPC Documents Pete

Okay. So how have you actually programmed this? The Toggle Master Battery control will do just that -- turn it of if on, and vice versa. It sounds like your device is sending the press twice -- but then, how does it turn it on? Pete

Output for GF devices can be implemented using special add-ons for GF -- mainly Lua plugins. FSUIPC provides special plug-in facilities for GF devices, as documented in the Lua library documentation installed with FSUIPC. However, GF's own drivers should meet most of your needs. Have you checked? Pete

Are you programming using the Client DLL for .Net? If not you are certainly in the wrong place! The only way to detect if you are over a runway is to read a database of runwats and comparing your coordinates! Pete

Hmm. Good question. No, it isn't a deliberate change. I'll have a look ... ... Ah. Seems when I moved one of initialisation functions to make it operate earlier (for some very good reason), I omitted to notice that sending the messages to the log depended upon a certain "Critical Section" (to avoid log file access clashes between threads) the initialisation of which also needed moving earlier! Sorry! It will be fixed in the next update, hopefully early next week. Pete

Which "infamous" crash is that? Where are the crash details, please? Are you sure it is FSUIPC? Perhaps it is something related to LINDA which I see you are running too. (I'm not sure why LINDA is logging so much -- is that a LINDA option?) If this line truly is the last line logged before the crash 230516 === DLLStop called ... then it isn't a "crash on exit" I've seen before. The original one and most common one is a SimConnect closing bug. Currently FSUIPC avoids that by simply not calling SimConnect close. With "LogExtras=4" (or 5) set, as you have, the normally seen sequence of closing actions on termination is this: 393388 === DLLStop called ... 393388 === About to kill my timers ... 393591 === Restoring window procs ... 393591 === Unloading libraries ... 393591 === stopping other threads ... 396212 === NOTE: not calling SimConnect_Close ... 396212 === AI slots deleted! 396212 === Freeing button memory ... 396212 === Closing my Windows ... 396212 === Freeing FS libraries ... 397226 === Closing devices ... 397226 === Closing the Log ... Bye Bye! ... 397226 System time = 26/08/2016 09:25:48, Simulator time = 12:24:48 (12:24Z) 397226 *** FSUIPC log file being closed The highlighted line is the point where the "infamous" crash occurs if I allow FSUIPC to call SimConnect close. I have of course reported this to L-M, but it isn't easily reproducible, despite being "infamous" for some folks. A crash between these two lines: 393388 === DLLStop called ... 393388 === About to kill my timers ... can only be related either to the forced terminations of programs being run (via entries in [Programs]) or the forced termination of Lua plug-ins and any associated External programs started by those plug-ins. Again, this points to LINDA or one of its offshoots. I'll try changing the order of terminations (plug-ins then programs they started then "Run" programs, instead of the reverse as now), but really iyt shouldn't matter which order they run in. FSUIPC does notify Lua plug-ins that things are terminating, and then allows 1 second for them to tidy up and close. I know LINDA has grown and become quite complex, so perhaps it needs longer? I will add a parameter to allow that timer to be changed, say 1-20 seconds? I don't want to increase it by default because P3D seems to take long enough to close down properly as it is. Pete

DSL file? Do you mean the DLL.XML file? You've only pasted a small section of the Installer Log. All the important information about locations etc is omitted! Please only ever paste complete logs. There's lots of information there which will help. The files are evdently installed correctly, as shown in your log fragment, so if you don't see them you are looking in the wrong place. With the complete log I can tell you exactly where everything is! Pete

The log files are text files. Just copy and paste the complete text into your message! Pete

Show me the Installer log, as I already asked. I cannot help without information. The log is made just to help answer these questions! Pete

Sorry, why are you worried about how the log looks? The fact that the function is called every time is surely proof that it works. Logging is asynchronous, and in a different thread, to your Lua plug-in. it is quite easy to get the logging from a Lua plug-in jumbled up. Why not actually program what you need to program in your "offset" function? Just logging something doesn't sem to actually do anything for you! Pete

I start UT2 in FSUIPC. It works fine. The "RunIf" should detect it if you start if in the EXE.XML -- provided it is established by the time FSUIPC checks for it -- but there's no point in having it in the FSUIPC list if you don't remove it from the EXE.XML, is there? The FSUIPC entry cannot do anything with it at all. Its options only apply to programs it starts. No. Pete

Version 4.968 of MakeRunways is now released, fixing this problem. Pete

Please tell me what you actually want to do, first. You seem to be making it much more complex that you should need to. For example, why have button operations dependent on another switch or button? Momentary buttons are quite normal and should present no problems. If you state the actual problem you are trying to solve, rather than present a "solution" to something I don't understand, I could help. Pete

Interim update 4.955h is now available, and includes the fix for the problem,. Pete

Wow! PFC have a UK dealer at long last! Shame they are all the way over in Norfolk. If they were nearer I'd go visit them! Anyway, I've bookmarked that site -- may come in useful in the future. Pete

Thanks for letting me know! It looks exactly like one I used to have, but which then was serial port connected. My driver PFDFSX.DLL was used with it. Basically the same system is also used in my PFC 737NG cockpit. Just the controller in the box is moved into the centre console and drives the radios etc too. Pete

Sending the keystrokes from a separately running thread or process works, but using ALT in any FSUIPC assignments doesn't work consistently well. As soon as ALT is sent the keyboard input transfers to Windows' menu system. The only really wworable way of doing it with FSUIPC is to send the keystrokes from a Lua plug-in. They run in their own threads so can continue when the keyboard focus disappears from the main foreground thread. I do not know of any way of doing it whilst withing the main FS thread, sorry. You'd need a Lua plug-in or a separate process outside of FS, even to interpret mouse clicks and send as ALT combinations. Many of the "events" take a parameter. To start with, all of those named with "SET" at the end -- those SET the parameter as the value identified. This is how Axis events work, for example, for aileron, elevator, rudder, brakes, throttle, mixture and prop pitch. In the case of an event such as the aircraft exits and engine selection the parameter would identify which one. Pete

No, not possible. The reason FSUIPC is not loading is simply that your missing roaming folder for P3D would contain the DLL.XML file which tells P3D which add-on modules to load. I've no idea how your system can get corrupted when it is switched off for days, but you might start looking at the possibility of bad hardware, like a failing disk or motherboard. Pete

In FSUIPC itself, in the drop-down assignment lists, the FS/P3D entries are almost all obtained at run-time directy from the tables in CONTROLS.DLL, a module of FS/P3D. Some older ones are added to the list, as also are a large number of FSUIPC-specific controls (of which there's a list in the FSUIPC Advanced User's guide) and entries for any Macros and Lua files present. The published list in document form is a static rendition of the list from CONTROLS.DLL and may not reflect the current versions of FSX and P3D at all times -- especially not P3D of course, which is still being developed. I try to remember to update it if I notice any significant additions. Not all controls are guaranteed to work or even do what they say. I remember some were even named in reverse, wrongly (small vs large increments, for instance), and some date back to FS98 or FS2000 and code for them got dropped in later versions but the controls not deleted from the internal tables -- maybe because their poisitions in the table had numerica significance. Sorry, but that is an assumption which isn't necessarily true. The ALT key is probably detected directly, not via code detecting it and looking it up in a table then sending the relevant event. Don't forget it is a standard Windows Menu function for ALT+ some letter to automatically select a menu item with that letter designated as its shortcut. This applies in FS just as much as in other programs featuring a standard Windows menu setup. Yes, it doesn't appear to do anything. Maybe they were thinking about making it assignable, but that idea fell by the wayside. Right. Using A:values in the XML is similar to using offsets in FSUIPC. Can you not write to them also? If so you could implement a Parking Brake On and Parking Brake Off, as you can with FSUIPC offsets. Pete

My own code. Just a sequence of "sprintf" formatting sections. I don't like XML at all. It's over-verbose and cumbersome/complicated, which is one reason, but a bigger reason is that one little error in its syntax often makes the whole lot invalid. I only made the XML files because folks asked for them. Don't know "JSON". Pete

Seems I need to do " ' < and > too! Pete

I've looked at this. It is very complex. The USB class number seems to be the only differentiator, and I can find no way of reading that except by referring to yet another part of the Registry, which is very obscurely somehow related to the stuff I'm reading. I was hoping I could read it from the USB interface itself -- it must be there someplace, but I'm blowed if I can find it. Really, with class "0xff" ("vendor specific") I don't know why it is coming through when I'm only inquiring about HID devices only. Seems a bit of an oddity in Windows to me. So, i'm going to leave it as it is for now. If I do come across anything more specific and easier to implement I'll look again. Pete

Thanks. Pete