Pete Dowson

Yes, you are reading a 16-bit signed value into a 32-bit one, so the higher 16 bits stay zero including the sign bit. Offset 07F2 is 2 bytes (=16 bits), so it is a "short int" -- I don't know what that would be in the language you are using. 64836 in a 16-bit signed integer is actually 64836 - 65536 = -700. Note also that by reading 4 bytes (32 bits) instead of only the two, you are reading the lower 16 bits of the next value (at 07F4) as well. That is "RPM Hold". If the RPM hold is ever set your value yould be 65536 bigger again, because you'd get the "1" from the "RPM Hold On" flag`. Please ALWAYS take proper note of the size of each FSUIPC offset and use the most appropriate variable to match! The A/P heading value is also only 16 bits (2 bytes), so if you are doing the same for that you are only seeing success because you have the Altitude Lock switch off -- otherwise that too would read high. Pete

No. What's a "fast reply" consist of? I see your message above in this thread which seems to be merely quoting the previous one form two weeks ago. Pete

Good. Folder sharing isn't relevant to WideFS. I'm afraid I've no idea what "Wireshark" is. Maybe I'll look for it. [LATER] Okay. Found Wireshark and looked at the capture file. most of it is gibberish to me, but I see a mailslot once per second. However, it says the source is 192.168.2.7, your Server, same as Wideclient logged above, but the destination is 192.168.15.255, which doesn't seem even legal to me (255 isn't allowed, surely?), let along on the same subgroup. Maybe the destination for mailslots are simply ignored or used for something else. From the other entries there it seems your client is 192.168.2.10. The data in the mailslot contains the server name ADER, which is correct, but obviously WideClient isn't seeing the mailslot at all. The mailslots are set to use Port2 as defined in the INI files both ends, defaulting to 9002. I don't see that mentioned in the capture -- in fact it says source and destination ports are 138, which makes no sense to me. I assume you didn't change those parameters? Regards Pete

The mailslot message is used by WideServer to tell listening clients where the Server is. It provides the Server IP address and its preferred protocol. It won't try sending anything until it knows the Server name or IP Address. That log shows it isn't seeing the mailslot. This is always either due to the two PCs being in different workgroups (in which case Windows won't pass them on), or, less likely, because of a firewall. I don't see any log of this. You shouldn't need to add anything, but the log would have been useful. No, none at all. The mailslot system works from XP SP1 onwards, the explicit ServerName or IP Address works even as far back as Win95. Note, though, that if you specify the Server name or IP address you must also specify the Protocol parameter, as the mailslot request is then ignored. Regards Pete

Ah. Thanks for the clarification! Pete

That;s designed to fix the opposite problem, where a panel is sending so many of its own messages that the fast repeats (hold) of a user press or click don't get seen an an acceleration -- so you only get the small increments, not the bigger ones. Regards Pete

Most of the examples were actually contributions by users. There are a lot more in the "User Contributions" sub-forum. I'd prefer to keep it that way. There are an infinite possible applications and variations I could possibly provide examples for, and I am never going to be lucky enough to find the few to please enough folks. User contributions are much better and will reflect general user needs better that I could do -- I am most certainly not a "typical user"! To that end, when you have a fully working example I would be grateful if you will add a couple of notes to it to explain what it does and post it in said sub-Forum. You can add comments to the Lua code to make it self-documenting. Comments are lines starting with -- (two minus characters), as in: -- This is an example of a widget squeezer invented by Joe Soap, 20th October 2010. Thanks, Pete

Just change the "ShortAircraftNameOk" parameter, in the [General] section of the INI file from being "=No" to "=substring", then find each aircraft specific section heading giving your PMDG aircraft name and change the name to, say, just 737, so it'll get applied to all 737s. In other words [buttons.PMDG 737-700] (or whatever) to [buttons.737]. Same if necessary for [Keys. ...], [Axes. ...] and [JoystickCalibration. ...], but if it's only the M-Panel you are concerned with it'll all be in the Buttons section. There is an Appendix in the documentation, contributed by a user, which goes to great length to show how to use the aircraft specific facilities more flexibly. In general, for classes of aircraft using different equipment you'd be better off in the long run using Profiles, assigning any new aircraft to the most appropriate profile when you first load it. Regards Pete

The default FSX 737-800. The variation I am about to try isn't much different as far as I know. I'm only checking it out on my set-up because during start-up the PMDG one needs the fuel cut-offs set to idle at around 19% N2 which is not right, it should be nearer 25%. Pete

Sorry then. Have you tried an aircraft based on the FSX airliners instead? I was using one based on the PMDG 737NG for FS9 -- without this ILS problem -- but have recently changed to one based on the FSX 738. I've not flown a complete flight yet with it, though, as I am still re-calibrating the trim indicator scale on my quadrant. Regards Pete

Sorry, I don't know the insides of PM's autopilot to know which of the many possible FS variables he is following. For all I know he could be computing by dead reckoning (but that is most unlikely). You need an exchange with PM support. Regards Pete

You have the gist of it correct, but you aren't following the syntax correctly. And the offset 0BC8 is correct but the value is 32767 not 32768 -- when doing any sort of "programming" you need to be precise and therefore read carefully. function set_brake(0BC8, 32768) event.offset(0BC8, SW, set_brake) gfd.SetLight (GFRP48, 0, 6) To start with a function is a routine which contains code. In this case the function is set to be CALLED by the event, so the event cannot be inside the function. The end of the code in a function is indicated by "end". Secondly, the contents of the ( ) of the function definition are variables which are given values when the function is called. You do not define them except to give them a name, exactly as shown in the document. Thirdly, all strings (non-numeric strings of characters other than names) must be enclosed in "", otherwise they look like names. Hexadecimal numbers, like the offset 0BC8 need a prefix 0x to tell the system it's hexadecimal. Putting this together with your snippet would look like this: function set_brake(offset, value) if value == 32767 then gfd.SetLight(GFRP48, 0, 6) end end event.offset(0x0BC8, "SW", "set_brake") Of course this is only going to turn the LED on. You need to turn it off in the case that offset 0BC8 is not 32767, so the full code would be: function set_brake(offset, value) if value == 32767 then gfd.SetLight(GFRP48, 0, 6) else gfd.ClearLight(GFRP48, 0, 6) end end event.offset(0x0BC8, "SW", "set_brake") If that works to your satisfaction you can simply add other functions and events to the same Lua to drive the other LEDs. BTW it is worth perusing the example Lua programs provided in the FSUIPC package (alongside the documents -- see the plugins Zip). Even if you are not going to use any of those, it would have shown you some of the things I've mentioned and corrected some of your code quite readily. It is still worth doing so even if you are happy with the above. If you are at all interested in reading more about Lua itself then please follow the links to the Lua website, where there's lots of help and a reference guide. Regards Pete

Windows and FSUIPC numbers buttons 0, 1, 2 ... whilst FS numbers them 1, 2, 3..., so they are the same. However, you should NEVER have the same buttons programmed in both FS and FSUIPC. If the FS assignments are okay, why are you bothering with FSUIPC? You should delete one set or the other! Of course. Num7 and Num1 are the default keyboard assignments for trim -- they have been for as long as I remember, right back to FS2 or FS3 days for sure. There is no way anything you do in FSUIPC will change any assignments in FS. You simply have not bothered to delete any FS assignments. FSUIPC has no control at all over what FS does in these areas -- it is entirely up to you!! Pete

Sorry, I don't know "GFKeys". But the documentation for the GFD library in the Lua plug-in facility is only just over two pages long, and the commands to light LEDs or extinguish them only amounts to gfd.setLight and gfd.ClearLight, so there really isn't very much to get your head around, surely? Why program a button to send a keystroke when there's a perfectly good parking brake command you can assign? It is always much more efficient to send the commands. All that sending a keystroke does is make FS look up the keystroke assignment and send the control itself, which you could have done directly. It is well worth reviewing the FS controls available to you -- a list of them is installed in the FSUIPC Documents folder, inside the FS Modules folder, for this very purpose. And FSUIPC adds many more, as listed in the Advanced User's guide. There are two ways to do that. One, possibly the easiest, is simply to call the Lua script as well as send the command or keystroke. You can either do that on the button release (part of the Buttons assignment dialogue) -- so pressing it operates the brake and releasing it changes the LED, or you could edit the FSUIPC INI file to make the double action on the press only. The Lua scripts are all listed in the drop down for control assignments. If you've only ever bothered to look at assigning keystrokes you'd have missed them all. The second and superior way of doing it is to get the LED switching driven by the status of the parking brake rather than you simply operating the switch. Then it reflects the setting on flight reloads or when the brake is operated by mouse or true keystroke. This is done by looking up the FSUIPC offset for the parking brake (for that you need the FSUIPC SDK, in which there's a document listing all of the offsets), and having your LED switching code in a Lua function called by an event.offset command. Such a Lua program would be named "ipcReady.lua" so it got loaded automatically as soon as FS is ready to fly. Have a think about this and a read of the bits I referred you to, again, and come back when you want more. I can do a little example of the last method for you, but show me what you've done yourself first. Regards Pete

FSUIPC3 is for FS9 and before (right back to FS98 and CFS1), whilst FSUIPC4 is for FSX, ESP and Prepar3D. If you want to use FSUIPC for calibration (or any other user features) you would also need to purchase a registration key. Instructions are in the User Guide too. Without registration FSUIPC reverts to its original purpose only, that of interfacing applications to FS. Pete

What versions of windows are you using on each PC? serveripaddr=192.168.000.009 Why not simply give the name of the Server? i.e. "ServerName=..."? I am not sure how fussy windows is about how you spell the parameter names, but the above should be ServerIPAddr=192.168.0.9 as shown in the example in the User Guide. Of course, if both PCs are using WinXP SP1 or later, and they are in the same WorkGroup (as recommended), then you don't need to specify the IP address or the Name -- it is all automated for you. 218 Trying TCP/IP addr 255.255.255.255, port 8002 ... 218 Error on client pre-Connection Select() [Error=10049] Can't assign requested address I've no idea how WideClient ends up with getting 255.255.255.255 as the Server IP Address though. Are you absolutely sure that INI file is in the same folder as the WideClient you are using? Yes. The version of FS is not relevant. By the way, there's a much later version of WideClient available in the Download Links subforum above. Check the Updates. WideClient is universally copmpatible with FSUIPC4 and any recent WideServer. Regards Pete

Everything you set or do in FSUIPC is recorded in the INI file (FSUIPC.INI or FSUIPC4.INI) which you will find in the FS Modules folder. All you need to do -- with a couple of provisos -- is keep a copy of that safe and install it yourself when you change. The provisos are: 1. When you re-connect your control devices, yokes, pedals, throttles etc, they will not necessarily have the same Windows ID number (0-15) as before, so all of the assignments will be to the wrong device. There is a solution for this -- use the facility in FSUIPC to do the assignments by Letters instead of the ID numbers. FSUIPC will then automatically track ID numbers for matching device names and "GUIDs" (those funny long strings which make no sense but which are supposed to be unique). 2. When moving from FS9 (or before) to FSX (or later) some of the Axis names (X Y Z R U V) may change -- normally R U and V get jumbled. There's not a lot can be done about that automatically as it depends on the USB configuration of the device. The difference comes from FSUIPC3 using the older Windows "joy" API and FSUIPC4 using DirectInput. Regards Pete

I cannot explain more here than is already done at great length in the User Guide. Just go to the chapter on Calibration and follow the steps outlined. It is pointless and stupid reproducing documentation here which you already have installed on your PC after installing FSUIPC. As for "feel" that's a matter of trial and error -- it's a personal thing as the controls we use in simulation are really nothing much like the real thing as far as "feel" is concerned.. There are about 30 different response curves provided (under the term "slopes") so i'm sure one will meet your needs. Pete

Oh, good. I didn't realise they'd done one. I'll have to look it up -- I was waiting for the promised 737NG from PMDG. [LATER] Oh, is see it's only 737-300/400/500 -- no good for my NG cockpit. Never mind. Good! So that "helper" was part of the Wilco 737 install, and even re-installing it didn't help fix it? I hope Wilco has been told about this problem! Regards Pete

Well that is truly weird. There is nothing in that part of FSUIPC that is at all related to what version of FS is being used. In fact the same modules are compiled into both FSUIPC3 and FSUIPC4. Sorry, I don't know offhand. I'd do a search. There's probably a [sound] section in their someplace. Regards Pete

:-( Download FSUIPC, then run the Installer. It installs FSUIPC and all of the documentation -- you will see an "FSUIPC documents" folder inside the Modules folder. It does tell you this in the brief instructions inside the FSUIPC ZIP file which you should follow to install and register FSUIPC! Pete

As far as I am aware it is not still a "known problem", so no solution is being sought. It was a bug, for sure, but fixed a long time ago in PM updates. Glideslope acquisition works okay here UNLESS I am too heavy for the speed, or too fast for the weight, or I'm not flying level when acquiring the GS. In those cases it can fail to acquire, for sure. I also do not even engage APP mode till both GS and LOC diamonds go solid. Prior to that I use VOR LOC. Regards Pete

There's no difference in the DirectSound code I use for any device, so there may not be a lot I can do about that. I don't really understand how any program can get sound from that device if the standard "Play" facilities in DirectSound don't work. From your Lua logging this part: 3197844 LUA: Y:\FS9\MODULES\ahPlaySound.lua:26 3197860 LUA: Y:\FS9\MODULES\ahPlaySound.lua:27 3197860 LUA: Y:\FS9\MODULES\ahPlaySound.lua:28 3200860 LUA: Y:\FS9\MODULES\ahPlaySound.lua:27 3200875 LUA: Y:\FS9\MODULES\ahPlaySound.lua:28 3203875 LUA: Y:\FS9\MODULES\ahPlaySound.lua:27 3203875 LUA: Y:\FS9\MODULES\ahPlaySound.lua:32 indicates that as far as FSUIPC was informed, the sound sent to device 2 did play -- that play command is on line 26, and the subsequent wait loop was executed twice before exiting (as shown by the line 27 28 repeats). This length of time seems to accord with the Device 3 play back of the same WAV file, so evidently DirectSound certainly thought the sound was playing! Is device 2 also the defalut device? If so have you tried with device numbers 0 or 1, or omitted? There is some Sound action logging in FSUIPC. To enable it add the following to the [General] section of the FSUIPC.INI file before running FS: Debug=Please LogExtras=x20 I suspect, however, that this will show everything apparently working from the FSUIPC end of things. You could also check settings for the sound card. Maybe it is set in some mode which isn't compatible with what FSUIPC is asking of it, though this sounds very very unlikely. The most I could do, I think, depending on the FSUIPC Log results you get, is add responses from DirectSound calls to the log -- maybe one of them returns an error number which will be useful. Regards Pete

Sorry, no. I did have another go, but gave up again after getting nowhere in several days of really complicated analysis. I guess my poor aging grey matter isn't up to it anymore! Regards Pete

Maybe, but you are using an old unsupported version of FSUIPC. Please update. The earliest supported version for FS9 is 3.98. Yours is so old I can't even tell you exactly what your problem is, but it is likely that its GlobalSign license has expired and therefore doesn't match your probably more recent registration. Regards Pete