Pete Dowson

Link to a 720p video, less than 8 minutes: Pete's Cockpit For those who are interested, this video shows two of my best friends, Ray Proudfoot and Thomas Richter, flying my 737-800 from Manchester to Heathrow in FSX with UK2000 scenery. I’ve cut out the bits between take-off and landing, and I’m afraid you can’t hear the ATC parts which are only on their headsets. The ATC is supplied by John Dekker’s Radar Contact version 4. The main cockpit is the PFC 737 from the Precision Flight Controls company based in Sacramento. The don’t supply it any more. The cockpit is narrower than the real 737, hence the omission of the lower display unit – the pilot and copilot CDU’s are adjacent. For the same reason the centre console isn’t fully realistic. But it does contain all that is needed. The motorised trim works well – especially with a recent upgrade by PFC, implemented by Thomas, which stops any slippage. The two yokes are linked as you should see. The overhead is a mixture. The forward section is by CockpitSonic, but with some modifications and a driver by yours truly. The aft section is by Sismo Solutions, again with a driver I’ve written. In fact all the hardware in the cockpit is driven by my programs, but the 737NG systems, the EICAS display and the PFD display is all enabled by software from Thomas. The rest of the displays – the NDs and the CDU’s, and the MCP/Autopilot and the associated logic is by Project Magenta. The operation shown in the video is raw and unrehearsed. there are a few errors made, which I spotted on viewing rather than live as I filmed, but I’ll leave viewers to discover these. I hope you enjoy the results in any case and thank Ray and Thomas for permission to show it. You can ask questions, criticise and mock (if that's your thing), in this thread. But I may or may not answer! ;-), But in any case, enjoy! Best Regards Pete Dowson

Sorry, there's really nothing FSUIPC can do. It is using standard DirectInput methods. Your entering and exiting FSUIPC option (which is what i assume you mean) merely causes it to repeat the scan it does in any case when it is starting. It simply calls the same procedure, absolutely no difference. Perhaps you should update to the currently supported FSUIPC version, 4.88. A while back, after the 4.86 release, an update was made which did the rescan whenever a USB device appeared to reconnect. Maybe that will fix it, but if so it does strongly suggest something wrong on your system. You may need to check with the folks who make them. Pete

Okay, that shows that FSUIPC is running fine, and the fact that you get the same problem whether registered or not shows it is definitely a problem with the Saitek software. Is it actually running? Do they use an EXE program or a DLL do you know? If they need something loaded and run by SimConnect then possibly you have a corrupted EXE.XML or DLL.XML file. I'm afraid there's no way I can help without more information, and as it now definitely appears it is nothing to do with my program, I think you need to get Saitek support on the job. Regards Pete

Something's evidently been changed, then. I need to see the logs. Both the server and client produce logs to shw what they are doing -- WideServer.Log in the FS Modules folder and WideClient.log in the same folder as WideClient on the client PC. Please paste their contents into a message here. Also the FSUIPC4.Log from the FS Modules folder. Close FS down first. There's never any point in doing things like that. It can even make things worse. But please make sure you are using the latest version -- 3.999z1 for FS9 or 4.88 for FSX or Prerpar3D. Regards Pete

One thing occurred to me. When your program is running and sending these keystrokes, FS does have the focus, doesn't it? It cannot receive the keystrokes if not. The way the facilities work is by using the "SendInput" Windows API, which emulates the actual keyboard. That way the correct processing of the KEYDOWN and KEYUP messages is performed by Windows, resulting, for instance, in WM_CHAR messages when these are a result. This also applies to the separate WM_KEYDOWN / UP sending facility at offset 3200. It too uses SendInput. As I've said, in any case, if the actions you want in FS are those performed by normal key assignment in FS, then you'll be far better off sending the controls themselves. FS doesn't have to have keyboard focus for those. Regards Pete

No, your registration is for the WideFS package which handles as many networked PCs as you wish. Pete

There's no "j" or "b" anywhere. Thse were just where the joystick number (j) and button number (B) go!! They are placeholders, that's all! Didn't you look at any of the actual examples? Pete

Strange then, because FSUIPC is doing exactly the right thing, and it works fine here. Sorry, I've no idea what's wrong on your PC. There is some more logging you can enable to see what happens after the messages are sent, but i can't look them up right now -- just going out. Sorry. What's wrong with using controls anyway? Pete

One of three things: 1. You are using an out-of-date version of FSUIPC (the ability to send the FSUIPC-added controls via 3110 was a later addition) 2. Those keys are being intercepted by something else, or 3. Those keys aren't correctly assigned. Please also use the Button and Key logging option in FSUIPC to track these things down. BTW the only supported versions of FSUIPC from today are 3.999z1 and 4.88. I still think you should send the FS controls, not keystrokes. Pete

I think you have something wrong there. The Clrbits and Setbits controls only change the bits which occur in the parameter. A parameter of 0 has no bits! So nothing is changed. Also, 3340 bit 0 would be Joy# 64 Btn# 0, the bits in byte 3360 are 32 x 8 = 256 bits later (3360 - 3340 = 0020 which is 32 bytes in decimal, 2 x 16). So all the bits in byte 3360 are Joy# 72 buttons 0-7. It's all quite simple. Each byte contains 8 bits, so represents 8 buttons. Bit 0 - bit 7. The first byte, at 3340 is joy 64 buttons 0 - 7, the next, 3341 is still joy 64, buttons 8-15, and so on. Each joystick has 32 buttons. The parameters used give the bit VALUE to be changed, not the bit number. Values of bits are 1, 2, 4, 8, ... 128, in each byte. Please read the FAQ subforum thread on bits, bytes and numbers. Pete

Yes, if the L is assigned to all lights in FS. More often it is better to send the actual FS control instead. Any FS control can be sent by its number via offset 3110. The one "L" is normally assigned to is "All lights toggle". There's a complete list of the FS control numbers installed in your FSUIPC documents folder. By sending FS a "psuedo control" which tells it to send FS a keystroke which FS in turn looks up in its list and sends itself "All lights toggle" you are making things much less efficient than they need to be. Send the control you want instead. Regards Pete

Sorry, no, there aren't any conditional facilities for keypresses. Don't forget key presses can be used in combinations already. How is one to differentiate Ctrl+Shift+X from alt + Y? The combined pressing of all those would be Ctrl+Shift+Alt+X+Y. Furthermore the matrix on keyboards often wouldn't allow X and Y at the same time. Buttons and switches are different in that they are each separate and can all be on or off at the same time. Therefore conditional processing makes sense for those. The only possible way out using buttons is to program your interface to operate the virtual buttons via offsets 3340 onwards. There are 288 bits there, each representing the state of one "virtual button" or switch. Regards Pete

Hmm. Sorry. Examples are probably best. The Lua plug-in "Record to csv.lua" uses the file library to write a CSV file, so may be of help. There are examples in the User Contributions subforum too, but I wouldn't have thought any use files. For basic programming you really need a good book. I don't know of anything on-line. The only tuitional book I have for Lua is "Programming in Lua". I have the 2nd edition published in 2006 by Lua.org. I see the third edition is out now. Both are available on Amazon, at over £20 each though. There is a "Beginning Lua Programming" book, cheaper and (it says) suitable for beginners in programming. That's also available as a Kindle edition which could be handy. Regards Pete

FSUIPC 3.999z1 and 4.88 versions, now available in Download Links, have this fix included. Regards Pete

No. Where do you get 100 as the keycode for the D key? 100 is the keycode for the Numpaad 4 key when numlock in on. D's keycode is 68. I think you must be looking in the wrong place! The shift code is okay, but when programming it's easier to understand the format when you consider the keycode is the byte in x3114 and the shift code is the byte in x3115. The "formula" 256*s + k is for folks needing a single decimal number to enter in the parameter field of the assignments. 868 = 0x0364 i.e 3 in the high byte, 100 in the low byte. Look at it that way, it is easier to see. You must also either write the whole 8 bytes as one FSUPC_Write (so use a structure or array), OR, possibly easier, write the 32 bit word at 3114 first then the 3110 value. But both before the next Process call. 76 is the keycode for L. Is that what you wanted? If you meant I (the letter beteween H and J in the alphabest) then it is 73. The latter is Shift+L, i.e. two keys, not just the L key. You are confusing characters, which have lower and upper cases, and keystrokes which do not. The former is okay, just the L keystroke, but a shift code of 0 is the same. You don't need the 8. That's optional and a result only of how Windows works. FSUIPC assumes the 8 if no other codes are set. Pete

Have a look at them, see which you'd be happiest reading and decoding. The only ones with the needed runway data in are: R4.CSV or R5.CSV: test format, includes runway centre coordinate, width and length, for precise testing whether you are on the runway. RUNWAYS.XML: text, but in XML format. Really more work to decode unless you can find a Lua-accessible XML parser. Looks like it, yes. I don't this there are any others. Regards Pete

You'd need to access one or other of the runways index files created by MakeRunways, searching for the runway whose coordinates most closely match your current position (read from FSUIPC offsets). To distinguish between close runways you'd need to go further and actually check that your position lies ON one of those runways. There will be some sort of trigonometrical algorithm for that, using the length, width and central position of the runways. Lua is fully capable of such things with a comprehensive maths library as well as file handling. Regards Pete

The FSX steering tiller is certainly listed in the FSX controls list. It is "Steering set". You only had to search for "steering". But f you want to use FSUIPC-added controls, including those which go direct to FSUIPC's calibration tabs, those are listed in the FSUIPC4 Advanced Users Guide, Just search for Additional "FS" Controls, or see the Contents list at the front. Pete

The link to the order site is given on the main download site on Schiratti, and in the FSUIPC user guide, along with full details. Pete

Your device is going to sleep. Turn off Windows power management. Pete

If the driver you are using writes and reads offsets directly then there's no where to include conditions except in that driver. You'd need to ask FDS. When I was answering I was assuming you were using FSUIPC buttons and switches assignments, where conditions can of course be assigned. You can't do it in the INI if there are no assignments in the INI! I think you are stuck with getting the driver (InterfaceIT) to do all this, unless you write a Lua plug in to handle it. You'd have the Lua program intercept the write to the offset (event.intercept function), then do its thing. Pete

Hmm. I don't use P3D, but I do have MTX 5.4b running without any problems. Not that I ever select a different aircraft -- my cockpit is a 737-800 and fixed as one so I don't get into those menus. It all simply means that whatever is wrong is causing corruption in some place which is not the same place when FSUIPC isn't running. Memory configurations are going to vary according to what is loaded. It's unlikely to be anything actually in FSUIPC or related to FSUIPC which is corrupted (when you are in the menu, FSUIPC isn't running unless you have some Lua plug-in threads going or WideFS clients active), but more likely something the menu process needs which is in a different place simply because the memory arrangement is a little different. Pete

Yes, or just ZapSound=piston_fail, as the example for 'Firework' shows. Why do you think the documentation doesn't tell you? I mean the traffic zapper with the DEFAULT settings. You asked what settings, not what zapper! ;-) Naturally the defaults are set to the values I found were best, so that's why I use them. Are you in the air then? Doesn't that tell you? It isn't complicated. You seem to be making it so. Air = you are in the air, Ground = you are on the ground!!! Regards Pete

All within range, as opposed to only the nearest one. If you want to kill all AI everywhere in the world just use the Traffic controls -- Traffic Density Set or Traffic Density Toggle. Pete

As documented in the Advanced user's guide. Just change the name. The default Zapper works well for me. Otherwise please yourself. The parameters are documented. Regards Pete