Pete Dowson

PFC drives the 6 pack indicators in the same way as pmSystems 737 Logic, via offset 5530. These only affect the sixpacks, Fire and Master Caution indicators. The whole point of the change for 2.01 to 2.02 was to make the bit assignments compatible with the current assignments in PMS's SysVar.txt. The PMSystems functions in the PFC driver are pretty much restricted to those things handled by pmSystems logic when it is running. They've been driven in PFC.DLL now for nearly two years. This isn't a recent thing. These include: Offset 5530 for six pack, fire and master caution Offset 560F for APU Offsets 5642 and 5643 for lighting Offset 5645 for Strobe Offset 5610-13 for the starters Offset 5664 for pitot heat Offset 5657 for wing and engine de-icing Offset 5628 for the master battery Offset 561A for fuel cutoff/idle Offset 579B for the Parking Brake As above you mean? When I do a bit more work the Autobrake will go through pmSystems too, but I've not done that yet. It sounds very much like you are using PMSystems logic which isn't doing what it should. Can you tell me what you are using? If you have a custom written logic for your setup then we can sort out some small changes to make it work. What aircraft are you simulating? Backlighting? How does PMSystems relate to backlighting? Sorry, you will need to be more specific. Do you know how any of your kit works, or are you simply using stuff programmed by someone else? If you know, please get down to the detail of what offsets do what. I've put a lot of work in over the past two years to make the PFC stuff work properly with pmSystems, and I'm pretty sure all the offsets are used correctly. Can you please look to see why your pmSystems isn't using the standard SYSVAR.TXT defined values? Regards Pete

No, WideFS links computers NOT running FS to one (the Server) that is. WideClient won't run on a computer already running FS, because it provides an interface which looks identical to FS+FSUIPC. WideClient *can* be made to run on an FS PC, by changing a class name parameter so it doesn't clash, but then programs like Radar Contact wouldn't be able to connect to it because they'd be looking for an FSUIPC interface with the FS class name. Regards Pete

"Nothing" happened? You mean FSX didn't load, or just that Simconnect still didn't load anything? When you say "didn't work" do you mean the Installer didn't work? If so, where's the Install log, please? So there's no "file_next_index= ..." parameter added to your Simconnect.INI file? That's where it keeps track of the Log file numbering. Sorry, I'm all out of ideas. Most certainly Simconnect, that vital part of FSX without which add-ons won't work, is not running on your system. Why, I have no idea. Yours is the first case I've come across where a re-install using methods given doesn't succeed. I'm afraid you now only have recourse to Microsoft Support. Please send all these results to tell_fs@microsoft.com in any case, explaining all you have explained to me. But don't expect a reply from that direction. For actual tech support on FSX you will need to contact MS support. Regards Pete

That's what I thought you might mean, and that isn't the latest, only the latest on general release. Please re-read this part of my earlier reply: If re-installing Simconnect doesn't work, maybe fixing those files, by using the latest FSUIPC4 installer, will do the trick. Pete

Latest version of what? If you mean FSUIPC, can you check the Version number please? "Latest version" means nothing on its own, it just means "the latest I have downloaded". So, SimConnect isn't loading anytrhing at all. Ah! That apparently doesn't work! Please refer to the FSX Help Announcement above. You have to delete a folder first, else the repair won't touch SimConnect. That's why I posted the FSX Help Announcement in the first place, and why I referred you to it! Regards Pete

Thanks for the KEY file. I've tried that here and cannot make it fail at all. I'm really puzzled about this. The only thing I can think of is that the signature checking mechansim isn't working correctly on your system for some reason. Can you tell me what version of Windows you are using please? Can you also right click on the DLL, select Properties, and see if there's a "Digital Signatures" tab? If there is click it. It should show the DLL as being signed by me, Peter L. Dowson and have a Timestamp shown there of 14 December 2006 13:24:55 (you may need to change some field widths to see the time -- or just click "Details" and read it there). Note that if you are using WinMe or earlier this may explain it. I'm not sure that these facilities were implemented back then. Hence the IMPORTANT note in the Announcement. Regards Pete

What method did you use? Pardon? Try the SimConnect logging as suggested and show me the resulting log. Have you tried installing the later versions of FSUIPC4, like FSUIPC 4.064 available above? The installer now attempts to correct corrupted DLL.XML files and even fixes a wrongly installed Simconnect.xml file. if even your add-on gauges aren't working it must either be Simconnect not correctly installed or a Simconnect.xml file specifying remote connections only at the cost of local ones. Pete

Oh, I just checked the code. To log the GPS data arriving in WideClient you need to set Log=PartRx Not just Log=Yes as I said. Sorry. Pete

Sounds like SimConnect isn't installed correctly. Please see the FSX help Announcement at the top of the Forum. Pete

Erdoesn't it end? That part just seems to be the first part of the last log. What happened next? Did everything hang or FSX crash or something? Now that I examine this part alone (I didn't notice before), FSX seems to be taking an AWFULLY long time to start: That's nearly three minutes before FSX tells SimConnect to tell FSUIPC that it is starting? What is going on in that time? Then: A gap of another two minutes after loading the flight before it is ready to fly? Why is FSX taking five and a half minutes to be ready to fly? What is going on then? But, more relevant here, what happens afterwards .. the log ends here. Is FSUIPC4 continually retrying? Did FSX crash? Have you no description of what this log is supposed to represent? Regards Pete

Erand presumably axis 3 for engine 1 and axis 4 for engine 2? What about engine 4? Why have they screwed up the axes for this aircraft? Why don't they control Engine N with the Engine N axis? Weird! Hmmm. I don't know what you did but it couldn't have been anything directly to do with axis assignment. Possibly the controls used by this odd aircraft implementation were looping -- maybe it was sending them back to itself and getting into a loop that way. I'm sorry, but there is no way I can tell from here -- it may be something you have to take up with the authors of the aircraft. I don't know what you mean by "reinstallation", but nothing you do in FSUIPC goes further than the entries in the FSUIPC INI file, so you only ever have to delete that, or, better in this case, merely delete the Axes section for that aircraft. Yes. Go to axis Assignment. Before you start assigning anything, make it aircraft specific (obviously with the correct aircraft loaded), and move each axis in turn and clear the existing assignments. If you are changing them all you don't want duplicates left just because you forgot. Then assign as needed -- get each axis recognised and assigned as you want, in turn. Then go to the Joystick Calibrations, make that aircraft specific too, and calibrate them all. Note that, in the axis assignment you can choose to have the controls sent direct to FSUIPC's calibration, or to FS -- your choice. But one way may be better than another depending upon how this strange aircraft implementation uses these controls. I cannot say which is best, though the direct assignment is generally more efficient (it cuts a couple of paths out). Regards Pete

Well, thanks, but I cannot see how this differs from the information in the Windows keyboard "WM_KEY" messages which I currently process. And if I obtain key presses by other means than intercepting the Windows messages, FS will get the keys too unless I duplicate coding. I really don't see the advantage. Have you looked into the standard Windows keyboard facilities at all, to see why you think they are deficient? As I said in my last message, I think I can differentiate between left and right keys where applicable, but the question (need) has not arisen so far. Regards Pete

Okay. Exactly as I do with FliteMap. Okay, from this I gather that you think you have everything set up correctly, but it isn't actually doing anything? The "coordinates" are in the form of NMEA sentences. Have you selected the ones needed for AutoRoute? Do you want me to check the settings in the [GPSout] section of your FSUIPC4.INI file? You can Log the data WideClient is receiving. I think just setting Log=Yes will log the GPS data, though I'm not sure without checking the code. The question hasn't arisen before -- give it a try. Duh! Sorry, I didn't even notice those before! The WideFS logs are fine, but I don't like these in the FSUIPC4 log: These are occurring every 3 seconds or so, meaning that FSUIPC4 is never actually getting any data from SimConnect. Thus GPSout will never send any data. You unfortunately have the symptoms of one of FSX's Simconnect bugs at present. I'm surprised you even managed to get an Add-Ons menu in which to register FSUIPC4 and set these WideFs and GPSout options! Do you have other SimConnect clients loading? Please see the FSX Help announcement at the top of the Forum and see if you can get a SimConnect LOG. Maybe that will help. If you have no other clients running, try repairing Simconnect as explained in the same announcement. Regards Pete

You got FSX a couple of years ago!? ;-). I assume you mean FS9. Erwhich new software are you talking about? You must have changed everything? Autoroute 2007 instead of 2006 (why not try 2006 first, to be sure?), FSX not FS9, and presumably FSUIPC4 instead of FSUIPC 3 and GPSout? Eryou are using WideFS as well? Please, I think you need to start from the beginning. What are you actually using, and where? Please include version numbers. Info about what? GPSout, configured to send data via WideFS, is documented in the FSUIPC4 documentation. WideFS is documented in the WideFS documentation. MixW is documented in its own package -- it isn't mine. I assume you are using MixW to give you the two virtual COM ports on your client PC? It is very difficult to help on the basis of almost zero information. Please expand. Regards Pete

Can you point to your problem, please? Have you checked the key code list used at present in FSUIPC? It is in the Advanced User's guide. This certainly differentiates between Numpad0 (Numlock ON) and Insert, for instance. But the keycode for Numpad and Insert is the same when Num Lock is off. As far as I am aware this is a function of the keyboard driver at BIOS level. I think I can differentiate between left and right shifts and left and right CTRLs, possibly, but really the question has never arisen. There are so many combinations now available, with Ctrl, Shift, Tab, Window and Menu keys also being usable in combinations, that you can never run short. Furthermore, by intercepting and using the WM_KEY messages I can take over the key usage, whereas using other methods, when FS is using windows, will not be so easy or reliable. Maybe it would help if you explained the problem you are attempting to resolve? Perhaps there are better solutions? Regards Pete

Er .. that's nearly two weeks ago! The response now they are automated is almost instantaneous! not sure what you mean by "make the transfer"4 days later?? I think you need to get back online and raise a problem ticket. I have no part in the sales mechanism, and there's no way I can check into this. All I can do if you've actually paid (have you checked?) and not received anything is forward your messages to the SimMarket management. But waiting nearly two weeks for an automated reply system seems extraordinary. Please raise that problem ticket. Pete

Hmmm. Can't see any problem here. Can you ZIP your FSUIPC.KEY file and send it to petedowson@btconnect.com please? I'm now using a different compressor and the code is properly signed (for virus protection). This is using the same techniques as in my FSX version (FSUIPC4). There may be some sort of error, but I have tested it here and see no problems. Thanks, Regards Pete

That's what I thought he was saying, and most of both my replies were concerned with that. But then the question about separate buttons arose so it got confused again. Provided (a) the repeated keypress merely repeats the same Light ON or OFF control instead of a TOGGLE control, and (b) the fact of a key held down did not prevent any other keys working correctly (which seems unlikely), then the only disadvantage this has is that it is inefficient in performance terms. One big disadvantage I can think of which might occur is if CTRL, SHIFT or ALT were used for something else whilst this other key is repeating -- that could produce a combination which might do something completely unwanted. Regards Pete

You do not. There should not be any need to mess with FSUIPC INI. Why are you trying to do so? Please PLEASE just follow the documentation. You Register FSUIPC and WideFS in FSUIPC Options, pressing the appropriate buttons, as it says in the documentation! When WideFS is registered another button appears allowing you to enable ort disable it. PLEASE READ THE DOCUMENTATION! The instructions are easy enough! I am sorry, but (a) this contradicts what you just said above, and (b) is plain impossible. Registration must be done from inside FS, in the FSUIPC options. Please do not mess about with any INI files unless you know what you are doing! How have you got them there? I don't issue any file with UDP protocol set!!!? UDP protocol is faster, more efficient, but it lacks any error checking whatsoever and is not guaranteed. It is good if everything runs perfectly. But get it running first before trying it. It does advise you about these things in the documentation. It seems I waste my time writing this stuff, doesn't it? :-( Sorry, but I think you need to start again. I have no idea what sort of mess you are making, but it seems you've not looked at what is avaialble. Delete everything, install FSUIPC or FSUIPC4, whichever you are talking about, and follow the instructions. Thank you, Pete

Not much. I've implemented it for Axis assignment in FSUIPC4, but it only gives 2 more axes and 3 more POVs. Otherwise it is just much heavier (less efficient) code than the direct joystick interface Windows still supports. They do. It is used for all joystick handling and has been since FS2002. Ah, you mean for Keyboard? I don't see any advantage in using DirectInput for keyboard when the Windows WM_KEYDOWN and WM_KEYUP message system provides everything that is needed. Yes, and can you not? Whether Num_0 exists on a keyboard depends on the NUM LOCK key. Maybe you have that off? Regards Pete

Isn't that one of those gauges which is only mouse-controlled? If there are keyboard short-cuts (and therefore FS controls) for it, then, yes, of course, because you can send any FS controls through FSUIPC. If it can only be controlled by mouseclicks then you'd need something like Luciano Napolitano's Key2Mouse program. Then you'd use FSUIPC controls to send the keystrokes to control the mouseclicks. Of course you could write a gauge or a program to do anything you like, but how are you generating the actual ground stations which use this system? Have you checked whether you can compile new scenery files to operate such stations? Regards Pete

Eryes. I understood what you were asking. And I thought I explained. Did you not understand my answer? However, you "elaboration" actually make things more confused. You say they are buttons acting like keypresses. So where's the toggle switch? If you do still really mean you are connecting a latching switch, i.e. a proper toggle switch, to one keypress input, then my answers above still apply. I think there may be problems if you effectively hold one key depressed all the time, but if you've tried this and it doesn't cause any loss of other "real" keyboard functions, then the auto-repeating won't matter if you avoid assigning toggle controls. You need to use methods to switch lights on and off separately, as I said. If you really mean using one button to send a keypress to switch a light on, and another to send a different keypress to switch a light off, then of course that can be done too, and presumably without unwanted side effects from the keyboard matrix. That's easy to do in any case and I'm not sure what you are then asking. Of course, if you used a double throw sprung centre-off switch you could use one contact as on and the other as off via two separate keypresses. ErI think there's a total misunderstanding about what "toggle" means here. A hardware toggle switch has two or more latching positions. In the case of a single throw one, like a light switch, it is off in one position, on in another. That is what I assumed you meant and what my answers are about. If you mean to use a simple pair of buttons then I'm confused about what the question is -- where's the difficulty? Regards Pete

Ernot sure why you think you'd ever need a relay. nor do I know how a toggle switch is producing a key press. You'd need to explain a bit more. If whatever you are using does a key press without a corresponding key release, then, yes, that does cause Windows (or maybe it'sthe BIOS) to repeat the key until the release appears. Having a real key or key code kept pressed is never a good idea because it can affect other keys on the keyboard matrix. For a key which is repeating it wouldn't matter if the control it is sending is something other than a toggle. Some of the lights have separate on/off controls so they would be okay. All lights can be controlled via FSUIPC offsets though (eg there's a bit for 10 different lights in offset 0D0C) and you can make a keypress write to an FSUIPC offset via the Offset controls. So anything is possible, really. Regards Pete

Well, yes, mostly. You need to register and enable the Server in FSUIPC4's front page. Whatever used to go into the WideServer.INI file is now nearly all in the [WideServer] section in the FSUIPC4.INI file, but there's not a lot you should need to do -- possibly just set "ProtocolPreferred= ..." if you want WideClient connections to default to a different protocol than TCP (UDP and SPX are the others). For a long time now pretty much all of the Server parameters are best defaulted, and even most of the Client ones too -- for a completely WinXP setup you shouldn't need to edit the Client's parameters either. One other thing -- now that you can start and stop WideServer whilst running FS, without closing the session and restarting, you can actually change the [WideServer] section parameters and try things in the one session, so, for instance, to see which protocol works best in your setup. Though do take care - TCP still seems the most reliable if not the fastest. Regards Pete

I've been playing with the REVerse option in FSUIPC's joystick assignments, and I think I can see how it can be confusing and even difficult to deal with, especially when calibrating flap detente positions. I am experimenting with a different implementation of the FSUIPC "REV" option, where is reverses the INPUT value, so it would be the already-reversed values you calibrate to. I think this may make it easier to understand and deal with. My only worry with this change is that it may mess up folks current working calibrations, if they are using the REV option in FSUIPC already. It won't affect anything else. I will releasing a test version of both here (3.712 for FSUIPC3*, 4.064 for FSUIPC4), so please do look out for these in the Announcements above. Maybe these changes will help you with your Flaps problems. If the changes turn out okay I'll prepare new full user releases, as 3.72 and 4.10, but that will probably be after Christmas. Regards Pete * Version 3.712 is ready now and available in the "Other Downloads ..." Announcement above.