Pete Dowson

Check FSUIPC 4.295 (or 3.814), now with REV axes treated appropriately. Seems okay here with two sets of toe brakes. Note that the change-over between one set and another can only occur when a new value is received -- a change over the "delta" so that jitter doesn't play a part. So if one pilot is depressing the brakes and then the other one fully depresses them and then releases them, they are released -- even though the first guy still holds them depressed. He'd have to wiggle them a bit to take control. I know this isn't realistic, but it is really about the best I can do without a lot more fiddling about in the code, and i really don't want to risk the inevitably unreliability this will cause in the short term. Regards Pete

The conflicts with LevelD were present in 3.75 and removed later. There was always an option which fixed it in any case, but it wasn't realised it was needed. I simply reversed the option so it is defaulted. The current (supported) version of FSUIPC is fully compatible with LevelD whilst 3.75 might not be (depending on parameters). There's never ever been a need to redo any setups when upgrading FSUIPC versions. Not ever. Pete

I assume the PSS 777 implements its own autopilot and doesn't use the FS values, then? There is no such thing as "compatible" or "incompatible" in that situation. You might as well say the PSS777 is not compatible with FS. Since FSUIPC interfaces to FS, it allows all sorts of things to be read/written in FS. If the PSS 777 does its own private thing with the autopilot, not using the FS values, there is nothing FSUIPC can do -- that is private to PSS. For control, maybe using the Mouse Macro facilities, if they work on the PSS cockpit. Check the documentation -- the mouse macro system works well on the PMDG cockpits. The only other possibility is to use any keypress shortcuts which might be defined for the PSS 777. See their documentation to see if that is possible. You are writing an interface program using offsets? The MCP isn't seen as a set of buttons and knobs? For reading the values from a private A/P implementation, whether PMDG or PSS, you'd need to get information from the Makers. I know PMDG sell an SDK (very expensive I think) for hardware to interface to their cockpits, but I don't know about PSS. You'd have to ask them. Regards Pete

My own freeware program "MakeRunways" does this too. It can provide the latitude and longitude of the runway centre and each threshold. Yes, I use this information. for KSEA 34R it is N47 25.89' W122 18.48' Where on 34R? The threshold, in the centre of the runway? It is important to say WHERE on the runway. They are quite long and often wide, you know. N47 25.89 is, in degrees, +47.4315 W122 18.48 is, in degrees, -122.3080 These are, to the accuracy of the Shift+Z display, IDENTICAL to the values you got from FSUIPC: ongitude read out by FSUIPC: -122,307998333126 latitude read out by FSUIPC: 47,4314848334006 The only difference is that the FSUIPC values are much, much more accurate. To the inch. They will be identical -- though the readout from FSUIPC will be much more accurate (to a few inches in fact). Both the Shift+Z readout and the FSUIPC readout use exactly the same data. To convert Degrees and minutes to just decimal Degrees just divide the minutes value by 60 to get the fraction (there are 60 minutes in each degree, as you must know). So 47 25.89 = 47 + (25.89/60) = 47.4315 and 122 18.48 = 122 + (18.48/60) = 122.3080 (then negated as FS treats West as -ve, East as +ve). Pete

Well, it just must be due to the REV setting. I've worked out a way of detecting that where I do the arbitration and will upload a test version for you to try, maybe later today -- otherwise tomorrow. Because there's no arbitration, so no inputs are discarded in favour of others. How many of the other axes, dual-assigned, are REVersed, though? Regards Pete

Well, the button must be programmed for that somewhere. It's just a matter of looking. If you want the windows sorted by Aircraft I think you can do all the work in the PANELS.CFG file for that aircraft -- not precise placement, but certainly general positioning (I think they divide the screen into 9 sectors and assign according to those). I really can't see any easy way that FSUIPC would be able to do it automatcally. Each aircraft has its own set of windows defined, and many of them may not be actually visible/extant at any one time. It can ennumerate all the windows in the system (being a child of FS isn't enough), and those which belong to FS can be identified (they are class "FS98CHILD" or "FS98FLOAT") but these can include all sorts of "Windows" which aren't necessarily meant to be part of the cockpit (though maybe those wouldn't matter). It would get pretty messy, though, not something I would want FSUIPC to get involved in. Maybe this would be a suitable subject for a separate add-on -- even one outside of FS could do it by ennumerating all the FS windows. Perhaps you should suggest it to one of the other add-on producers like Luciano Napolitano? Regards Pete

As the documentation points out, it is NEVER a good idea to use the ALT key for anything, UNLESS you want to sent it to bring a Menu up. The order is irrelevant in the display, they all have to be sent together -- the ALT makes the combination a "System Key" operation. 3.44 is unbelievably out of date and hasn't been supported for years. Please do not come back for any more support until you have updated. Pete

FSUI.DLL is the main User Interface of FS. ("FSUI" = "Flight Sim User Interface"). This is nothing whatsoever to do with any of my software -- perhaps you have a corrupted install of FS. Why not ask in the FS2004 Forum, or Microsoft Tech Support? Not here for sure. Pete

You cannot read the "position of an airport", only the position of the user aircraft. What "text file" are you using? What is this "text file" giving you the position of? The difference here is 0.0001 longitude by .016 latitude. 1 degree Latitude = 60nm, so the difference you are complaining about is less than 1 nm (0.016 x 60 = 0.96). The runway is probably 2 miles long -- so where on that runway are you trying to find the position? It could be 2 miles different from one end to the other!! Please try to use some common sense. I have no idea where your source data is (this "tecxt file") but if you want positions in FS you have to read positions in FS, not is some other source! Use Shift+Z in FS and display the Lat/Lon of the aircraft on screen. Pete

Good, glad you got it sorted! Pete

It may be useful. I'd need to set up something here to get the same from GPSout for comparison. I don't use FS2004 any more, so it may take a few days whilst I sort something out. It would be quicker if you did the same as you've just done but with GPSout, to get a comparison. Set the 6 position option off -- I see that isn't using the extra precision. Pete

But you could do all that by assigning the axis as the Mixture control in FS's own assignments. You didn't need to use FSUIPC. And I thought you said it was a mixture control already? Remember? You said: So all you wanted to do was assign the mixture control as the mixture control .... Uh? :roll: :roll: :roll: Pete

MakeRunways wouldn't help with that -- in fact I don't know how you'd get that data. You need the terrain mesh format. Maybe it is included in the BGL format documents I found, maybe not. They are by Winfried Orthmann. Go to AVSIM, do a library file search on his name "Orthmann". You will find lots of utilities for analysing BGLs and good documents in PDF form. There's one for FS2004 and a later one for FSX -- if you can't find the latter and you need FSX let me know. Pete

It won't work until the WinSXS setup is repaired. You have to reinstall Acceleration to repair it! The uninstall didn't do much in any case. Seems it failed utterly to uninstall Accel and restore the SP1 editions of the FSX modules in the FSX folder. The FSUIPC log shows this: Version: 10.0.61637.0 (SimConnect: 10.0.61259.0) which is exactly as before, and which is the Acceleration release. Regards Pete

Well, if you can get ANY examples of GGA sentences which XCSoar accepts then I can see what fiddle I need to do to get it to accept mine. I looked at the XCSoar code and it looks like it should be fine, it actually appears to check for very little -- but it is a bit convoluted and I may have missed something. However, the code they release is for an older version, 4 I think. You are probably using 5, so that could very well be completely different. Also it may of course be different on a PDA. I only looked at Windows C source. In the end the quickest way would be to ask the XCSoar folks what they don't like about GPSout's GGA. I don't understand why they are so uncooperative. And GPSout is freeware, I make no money out of it at all, so they've got nothing to complain about there. Regards Pete

There's no way something happening on one axis affects what happens on another (i.e. left and right) -- each axis is distinct, the could just as well be rudder and aileron. The only arbitration going on is that the maximum value from the two inputs assigned to the same FSUIPC control wins. Of course your brakes probably give their maximum value when "off" (I assume you REVerse them in the calibration?). That may be the problem -- I suspect your left here and right there business is a red herring because there's no way there'd be a relationship between left and right, no way. To check whether the reversal is the problem, depress the currently operational pedal, to make its value lower than the non-working one, then move the non-working one. I think you'll find that it will then operate. (You may need two people to do this! ;-) ) This is also likely to be a problem with FS-assigned axes using the old method or false axis assignment, if they are reversed in FSUIPC -- but there's the option of reversing them in FS itself instead, which gets around it. I'm going to have to think about how to deal with this. The problem is that the part of FSUIPC which is detecting and assigning axes, and doing the arbitration, is not at all related to the part doing the calibration and therefore the Reversal. I may have to devise some sort of indication which the arbitrator can use. Pete

It's Dowson, actually, but call me Pete It really must be programmed to do so somewhere. There's no magic in this stuff. When you look in the FS assignments are you looking in them for the correct joystick controls? There's a drop-down selector for different controls, the tabs only show one joystick at a time. A lot of folks don't realise that. No, I never proposed any such thing, sorry. Especially when it isn't needed -- FS always saves all that when you save a Flight. Regards Pete

That's just an example of the mouse macro capabilities. You can produce those yourself, just following the instructions, for any part of the PMDG cockpit. Really? The overhead was just a part I did as an example. It isn't the facility. The facility is the ability to make Macro files, defining new controls for assignment, to many actions previously only possible using the mouse. Sorry, I have no idea whatsoever what an FDT Simboard is or does. If it produces button presses or keypresses which are recognised in FSUIPC's Buttons or Keys options, then you can use it to select any FS or FSUIPC control, and those include any added by Macro files. There's no such thing as "navigating to a Macro file", that means nothing. Macro files merely define names for add-on controls. You do the assignments in the Buttons or Keys tabs of FSUIPC options. Pete

That wouldn't be called "mapping" but "assignment", if FS treated "condition" as a separate distinct input, which it doesn't. For FS the mixture input IS the condition. Can't you see it moving in FS? Pete

Ok. Put a serial port monitor on that (eg PortMon from http://www.syssinternals.com), log the sentences it is producing, and let me see its examples of GGA. In fact to can log my GPSout samples too and compare them yourself. There may be an entry which I omit (as it isn't applicable to simulation) but which XCSoar needs "fabricating", though if so it'll be a first. You see, my current GGA sentences have been feeding Altitude correctly to an assortment of GPSs and mapping programs now for 11 years and I am not willing to change it in any way without good reason and knowing exactly why, otherwise everyone else will be upset. The best folks to comment on that would be the XCSoar authors, but evidently they are a totally uncooperative bunch. On your second message: It isn't very good then, is it? You've already proven GPSout is working with XCSoar to provide positional data. Pete

All of that is surely entirely irrelevant. If it gets the position, it is evidently reading the output. No amount of messing or other programs is going to change that. This obviously points to a bug in their GGA parsing, tha's all. And what sentences is that supplying? Pete

Since the read does nothing but add a request to your own data in your own process, it costs nothing. The Process call makes a process switch and costs a lot. So, what do you think? Lots and lots of expensive process calls, one for each data item, or lots of free data requests all then transferred in one process call? ;-) Please read the description of the Process I posted earlier in this thread. Surely that would have answered such questions? You should ideally be spacing your process calls out to more or less match the FS frame rate you are expecting. Say one every 40 or 50 mSecs , at most. Less if your needs are less. Pete

Ah, 60905 not 60985 as you said last time. Yes, those are FS versions, not SimConnect versions -- you'd see the same on every module of that issue. Yes, those are the SimConnect versions, as I said. However, the WinSxS system evidently isn't correct (something somewhere is amiss) because the logs still show that only the SP1 version of SimConnect is accessible. All of your SimConnect-using add-ons are using SP1, not SP2 or Acceleration. Well, you cut it off after 12 seconds worth (the number at the start of each line is the elapsed time in seconds). This of course is long before the PFCFSX initialisation and failure (107 seconds or so). But no matter. The problem is still the same. You'll need to delete the "61259" folder after uninstalling Acceleration, then re-install it. Hopefully this will repair the WinSxS system for SP2/Acceleration. No, not a factor. I think this is the root cause of most WinSxS installation problems. The uninstall makes a mess of Side-by-side library installations, it doesn't uninstall them sufficiently for them to be repaired. I think Microsoft should be ashamed of this whole mess. I have four separate FSX installations, two with acceleration, two with SP1 + SP2, on both WinXP and Vista systems, and having never once uninstalled it (never having any reason to), I've never had any problems. It just doesn't like being uninstalled and reinstalled. it makes a right mess! :-( Regards Pete

Where are those numbers from? The actual SimConnect version is 60905 (RTM), 61242 (SP1) and 61259 (SP2 or Accel - same version). You'll see these in the Folder names in WinSxS. The number you read for the File Properties Version is the release of FSX itself -- they simply renumber all the modules each time, even if they are unchanged. They should be: 60905 for RTM 61355 for SP1 61637 for Accel [There's a different one for SP", but I can't find it at pres) Pete

There's a few discrepancies there: From the FSUIPC4.LOG: NOTE: SimConnect Acc/SP2 Oct07 is supported, but it isn't installed. Running inside FSX (SimConnect SP1 May07) 8109 Running in "Microsoft Flight Simulator X", Version: 10.0.61637.0 (SimConnect: 10.0.61259.0) These are inconsistent. The probing of the Manifests show that neither SP2 nor Acceleration is available, yet when Simconnect responds it gives the Acceleration version (61259). Weird. The SimConnect log also shows FSUIPC4 using the SP1 version of Simconnect -- it is using TCP/IP. not the Pipe, which it would do if it could connect to the SP2 or Acceleration version. Unfortunately you cut the SimConnect log off rather too soon -- it is only part way through FSUIPC initialisation at the time. The PFC driver isn't loaded for a while after that --94 seconds according to the FSUIPC log. However, since the call to add the menu was rejected it may not have got as far as being logged. The error causing the Menu not to appear is: 102484 Failed on SimConnect_Open for PFCFSX, return = 0x80070057 That error number appears to mean, simply "Invalid Argument" (useful, eh?). Sorry, but it does appear that your Acceleration installation is wrong -- at least the SimConnect part. Try uninstalling Acceleration then re-installing. If that doesn't work, you may need to try uninstalling Accel again, then deleting those WinSxS folders (just the later two, SP1 and Accel/SP2 versions, 61242 and 61259) then re-installing Accel which should then put them right. I'm constantly amazed at the numbers of ways the Windows side-by-side system of multiple library versions can go wrong. I really do hope MS will sort something better out for the next version! :-( Regards Pete