Pete Dowson

Seems Nico Kaan has been busy too -- see http://www.mycockpit.org/forums/showthread.php/24264-Lekseecon-for-737NGX-and-IOCPClient-example

All this must surely be down to poor connections or failing hardware. There's no way FSUIPC has of infliuencing USB connections or making phantom values. The fact that reiniitialising the USB devices revitalises them certainly indicates something is wrong in the hardware or its settings.Mmake sure that Windows has its USB power management turned off on every hub listed. If it is already off on them all, then I certainly think you have a faulty motherboard on your hands if it affects all devices (otherwise just a faulty device). Regard Pete

I was thinking more of local storage in your DLL. The NGX data is a fixed structure with a fixed size. Just store it in defined static memory in the DLL, and feed it on request. OR use an event system. The "get/set" global variable system is only needed for passing data from one Lua plug-in to another, as they run in different threads and each have their own stacks (which is their 'memory' -- DLLs and EXE's are different, they can own memory and keep stuff in it. Okay. I might write to PMDG in any case, for clarification. If I'm allowed to provide the NGX data via FSUIPC offsets, as I do for native FSX data, then I'll do so and let you know. Have a great weekend (or what's left of it!). Pete

Actually I did understand WHAT you were doing, just not WHY. It just seems rather complicated. Or maybe it's just me? Yes, that's what I find so complicated. How is this going to work for a user who wants to populate all his hardware displays with indicators and values from the NGX data? If you wanted to do it that way why not simply use a mechanism like my "event" system. Let the Lua program which is doing the "requiring" call an event function in your C DLL which provides it with the name of the function to be called when a specified value changes. You'd need to build a list of those. Then, at the end of that Lua program, instead of exiting back to FSUIPC, it would need call an "execute" function in your DLL which then processes the dispatches, in a loop as now. This way you don't need to execute a separate Lua plug-in, it is nice and tidy all in one Lua and one DLL, both running in the one thread. The only trouble is that because the thread never exits back to FSUIPC, that same Lua can't use the FSUIPC event system. (But that applies to your current method too). The other way is the way I proposed before, which is having a separate thread in the DLL which is maintaining the data copy with functions which supply values on request. The problem with that is how to detect that the Lua plug-in has terminated so that the separate thread can be terminated tidily. I'm starting to wonder if it wouldn't be much tidier to forget the Lua way of doing it altogether, and just have an EXE program which gets the NGX data and posts them to assigned FSUIPC offsets, which can then be read by any Lua plug-ins, and other programs, even on a WideFS client. I would actually consider building this into FSUIPC (it is easy as it already has a working SimConnect interface), but I don't like some sections of PMDG's EULA. I'd need PMDG's blessing first. Maybe I should write to Mr. Randazzo. Regards Pete

No, there's a default size and position anyway. Pete

The MS Visual Studio debugger can run FSX with your module. You just tell the debugger ot load FSX, copmile in Debug mode, put the DLL in the right place, and click the menu itsem to start debugging. Ah, hang on. The PMDG NGX code checks for a debugger running and causes a crash, deliberately I think to stop hacking. you have to get FSX started first, with the NGX running, THEN use the "attach to process" option in the Debug menu. Then you are okay. Pete

I browsed your code and I must admit I'm completely mystified as to what it is you are doing now. I thought you were simply making a DLL which contained a number of C functions to supply requested NGX data to any Lua program. Why is the DLL itself executing yet another Lua program? What's all this about callbacks? If you are trying to get around the problem of the loop calling simConnect's dispatcher, then that should probably be in its own thread.. In fact the DLL could create a thread which has the sole job of keeping a copy of the PMDG data up to date, in its own memory. The main DLL thread would provide the functions called by Lua to retrieve reqested data from that copy. This emulates the way FSUIPC works -- it keeps the data in the offsets up to date with dispatches from simConnect, and supplies those as requested to client programs. If you were to use the Windows message method I suggested, it would still need to be done in a thread -- and I think the message loop needs to be in the same thread as the message window. Regards Pete

I'd be interested to know the details of that crash, as I wouldn't want it to be anything to do with FSUIPC. Could you provide the details from the Windows error log please? Also the version number of FSUIPC. Regards Pete

I can't picture how you are assigning this. You should be able to define your three zones (using the right-hand side of the axis assignments) without any problem. How would the aircraft know you moved the lever down unless you had it sending something? Really? Why do you think that? You should be able to assign any control in the dropdown on the right-hand side. Can you tell me why you can't assign to macros there? If you cannot it needs fixing, but as far as I'm aware the code is the same for all the control assignment dropdowns. You most certainly can assign to Lua plug-ins there, for instance, and they are part of the macro setup as far as assignments are concerned. Regards Pete

I don't know if those other than BrainBoxes work, mind. Ah, okay. Thanks for pointing it out. The PFC driver does date back quite a few years now. The current PFC stuff is full USB, not serial port. Regards Pete

Not that I'm aware of. Why? I tested it here too the other day. ;-) Regards Pete

Are they correct? Most PFC controllers send some of their status messages at regular intervals, like every second or maybe twice per second. Okay, so far so good ... So it isn't re-initialising from the PC after a reset? I assume, then that the button codes don't get sent then either? I never had anything but problems with USB serial port adapters when I changed to Windows 7. I don't think any of their drivers are any good. You appear to have one that works for input and not for output. I gave up on them all (including a couple of quite expensive ones) and got a BrainBoxes PCI or PCI-Express serial port board instead. they work perfectly. I'm afraif I cannot recommend anything else. Regards Pete

No, you misunderstand how Simconnect works I think. I's a subscribe-and-wait system. You tell it what you want to know about then wait for it to supply data as and when it changes. You save the data to supply to your clients when they ask for it. It will only notify you when something changes. The method I recommend is to use Simconnect_Open with your message-only (HWND_MESSAGE class) Window handle as the 3rd parameter and a user message number defined by you as the 4th parameter. Then you call "CallDispatch" when you receive that message. This is bay far the most efficient method. Regards Pete

Yes, Windows own keyboard driver treats all keyboards the same. You can have as many as you like, but the keys are the keys which are the keys. Some add-on keypads come with drivers which you can program, but otherwise you have to have a program which not only reads them individually as US HID devices, but also hooks into the target program(s) to prevent them still being seen as normal keyboards. That's quite complex. I think HidMacros does it though. But they aren't buttons. They'll be seen in the Key assignments tab as keys from the keyboard. Pete

No idea. Are the keys visible to FS? It isn't a joystick type device then? Sounds like it needs its own driver. doesn't it come with any software? Ah, so they keys MUST be recognsed, then, surely? Earlier you said they weren't! I'm confused now. There is a program, which I tried once but couldn't get on with, called "HidMacros" which might do it for you. Ah, you found it! I think that's the only answer to multiple keyboards. Regards Pete

You don't need much of it. the example in the 737NGX SDK is enough, though i don't like their method of looping calling the dispatcher. That's not needed if you use a callback and defined Windows message. Regards Pete

Provided you don't mind 66C0 changes possibly affecting the other use, I don't see what the problem is. Why not continue what you are doing? Obviously if you are using the same rotary for two different inc/dec targets you'll need some way of selecting between them. You can't really do that with a keypress in place of the rotary because you'll either need two offset conditions (not supported), or a flag (only suipported for butons, not keys). Pete

This reply crossed with an amendment to my previous posting, where I worked that out. I said, if you refer, 2118 = x0846, and 1070 is it a key press -and release, so this is doing a key press and release of the F key which you are wanting as a result of pressing the F key? Why? It is a very very odd choice of programming! Why not just leave the F key be? I mostly used the 6xxxxx offsets (list of FS2004 controls.pdf) and started programming.[/CODE] Offset addresses only go up to xFFFF, so I assume you mean x6xxx here. What's the problem? It isn't as if the 66C0 value changing is going to affect anything else unless you press the key concerned with that other option. Regards Pete

Easy. use the Lua sound library. BTW the Lua updated documentation is now posted -- see the Download Links subforum. Pete

Sorry, there's no "P" either. Pleaase do see the Manual for the format. If you'd programmed the keys in the FSUIPC options in the first place you'd not get into all this mess and on-going discussion. This is what i get, using the options: 82=71,8,x510066C0,x00090001 So much easier and more relaible, surely? By all means mess with the INI for complex things but start off with a known base. Sorry, what do you mean "how to use the 2118"? What do you want to do here? Surely you approach this the other wasy around. You work out what you want to do THEN find out how to do it, not vice versa!? If you tell me what you are trying to achieve here, i can help. What's that "F+ x,y" business? 2118 = x0846, and 1070 is it a key press -and release, so this is doing a key press and release of the F key which you are wanting as a result of pressing the F key? Why? It is a very very odd choice of programming! Why not just leave the F key be? I don't understand you at all. Do you REALLY mean to say you've NEVER gone to the menu and opened the FSUIPC options dialogue? You don't EVERYTHING by editing the INI? Virtually the whole of the User Manual is concerned with using FSUIPC via the options dialogue. It's got loads of pictures showing it. how could you possibly miss all of that? All of FSUIPC's add-on controls are listed in the drop downs. It works fine. I used it and tested it in the first example above. 145 = x91. You aren't fopllowing the instructions! Why not please read up on these things before messing about? Please search for and read the boxed section entitled "Offset Increment/Decrement Controls" in the User Guide. BTW please make sure you are using an up to date version of FSUIPC. Some odd bugs were found a while back in some of the cyclic functions. Pete

Looks good. Oh, you've not looked at the calibration instructions in the User Guide? There are numbered steps to good calibration. You just need to set the minimum position on each axis away from its real minimum, i.e. pressed a little. Same with maximum, release a bit. Regards Pete

Here's how to do it (without the brakes as well -- not sure how you can use them for both, or at least not without writing a Lua plug-in to work it out). Assign both pedals to the rudder. Then edit the INI file. You can do this without closing FS. Find the [Axes] section and the two lines which relate to the rudder axes just assigned. Add this to the end of one of them: ,*0.5,+8192 and this to the other: ,*-0.5,-8192 It doesn't matter which way around at present. You'd need to check after ... Go back to FS, go to the axes assignments tab and press the Reload button, then go to the Joystick calibrations and calibrate. One pedal should now operate 0 to +16383, or thereabouts, the other from 0 to -16383 or so. if they move the rudder the wrong way, re-edit the INI, reversing the two additions. Calibrate with a reasonable dead zone with feet off or pressing slightly. When operating the rudder you'll only be pressing one of them at at time -- if you press both they'll conflict and the resulting rudder deflection will not be predictable. If you assign both via the "Direct to FS Calibration" method then FSUIPC will give precedence to the one with the largest divergence from 0. Regards Pete

Yes, well, but the example there is from Buttons. In Keys it wouldn't look like that. The definitions of the formats are given in their appropriate sections. Please refer to the ssection entitled "Keyboard Programming", where you will quickly see the part entitled "Format of Key Definitions". That's your reference, if you really want to do it the hard way instead of using the FSUIPC Options dialogue. Yes, of course. And you can program that via the FSUIPC options dialogue. Or don't use the "C" or "K" prefix for key assignments -- this choice doesn't exist for Keys. Pete

Have you tried setting them to be one axis. Most such pedals have either a physical switch to change from twin controls (for car driving games) to a proper continuous axis (for rudder), or an option appearing in the Windows game controllers applet. If neither applies it might get a bit complicated, but it can be done. I don't really understand what you mean there. Show me the Axis assignments entries from the INI file. I would think that the two inputs to the rudder axis will conflict in any case, and they'd need to operate in different directions. Regards Pete

Well, yes, you can use the DLL, but it would be nicer if you could usie a static library (lib) rather than a DLL, built into your DLL. Much easier for the user. I don't know if the Lua website fearures a static bindable version -- if not you could always simply compile the needed source into your DLL. You wouldn't need all of the modules of course, probably just the base, maybe some other essential modules. It depends on which Lua procedures you end up needing to call upon. So far you are only using luaL_register., so you probably need lauxlib.c and lbaselib.c. Regards Pete