Pete Dowson

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

I'm not yet sure why the old one behaved exactly as it did, but there are certainly worrying things wrong with it, here: [Axes] 0=0R,R1,D,21,0,0,0 1=0V,R1,D,27,0,0,0 2=0S,R1,F,66732,0,0,0 3=0T,R1,F,65760,0,0,0 4=0T,B,400,512,65595,0 5=0T,B,250,350,65597,0 6=0T,B,125,225,65599,0 7=0T,B,-512,-400,65603,0 8=1R,1,F,65696,0,0,0 9=1V,1,F,66387,0,0,0 10=1T,1,F,66388,0,0,0 11=2X,1,F,65695,0,0,0 12=2Y,1,D,2,0,0,0 13=2Y,B,16224,16383,65752,0 14=2Z,1,D,4,0,0,0 15=2U,1,D,5,0,0,0 16=2V,1,D,6,0,0,0 I've emboldened all the questionable settings. First, using RAW mode for all of the Joystick 0 axes is really bad. As it says in the documentation, RAW mode is only useful for software-controlled axes (like those from an EPIC or other program-controlled USB board), and is then useful for directly setting things like radio frequencies, MCP registers and bug positions, values which have to be precise. That is also the only time where a Delta of '1' comes in, to send every minute change through. All of your uses are for analogue values, where such precision is a nonsense and all you are doing in causing a hundred or more times more messages flying about in FS and between FSUIPC and SimConnect and FS. Terribly inefficient and really quite prone to things going wrong. To make things worse you have an odd mixture of some axes going direct to FSUIPC (and therefore avoiding SimConnect altogether) and others routed via FS controls, so using SimConnect three times per single change (as I explained before). It would be far more sensible to be consistent, and the most efficient by far would be to route everything direct with the only exceptions being (a) when you want to use a control not covered by FSUIPC's calibrations, or (b) when you are using an Add-On which needs to see and intercept the relevant FS control. Finally, you have in two instances, Flaps and Elevator, not only assigned an axis control to an axis but also FS controls based on Ranges. This is fine for non-conflicting uses, but having the same axis send a FLAPS_SET control to FS and, in certain ranges, also send FLAPS_UP, FLAPS_! etc controls is rather flabbergasting. Why on Earth try to make FS do two things at once with the same lever? What were you thinking? It just makes no sense and I cannot imagine your line of thought there. I'm not surprised you got conflicts. The other use of sending a control by an axis value is on the elevator: 12=2Y,1,D,2,0,0,0 13=2Y,B,16224,16383,65752,0 The control is "PARKING BRAKE". Why would you want to operate the parking brake with an extreme twist (16224-16383) of the elevator? Anyway, enough of that. On to your new settings: [Axes] 1=0V,32,F,66731,0,0,0 2=0S,32,F,66732,0,0,0 3=0T,1 4=0T,B,-16384,-16384,65595,0 5=0T,B,-10648,-10613,65597,0 6=0T,B,-5976,-5942,65599,0 7=0T,B,16383,16383,65603,0 8=1R,128,F,65764,0,0,0 9=1V,128,F,66387,0,0,0 10=1T,128,F,66388,0,0,0 11=2X,128,F,65763,0,0,0 12=2Y,128,F,65762,0,0,0 13=2Y,B,16288,16383,65752,0 14=2Z,128,F,65765,0,0,0 15=2U,128,F,66291,0,0,0 16=2V,128,F,66292,0,0,0 0=0R,32,F,65766,0,0,0 First, I still don’t understand why you don’t use the FSUIPC flaps notch calibration facility for your generic flaps, instead of the controls mapped to axis values, but at least you aren’t sending the Flaps axis value at the same time, so it is better. Second, why are you using such a low delta, like 32, for your aileron and rudder trims? This implies you have hardware axes capable of 1024 different positions, which would in turn imply they are extremely high precision and very very expensive. No commercial axis system I know of it capable of more than a resolution of something like 200 positions, and usually much less, less than 100 and most around 40 or 50. The default Delta of 250 allows 128 positions, but even that can be too low if there's any sign of jitter on the axes. By setting a delta too low you are simply wasting your PC's time with many spurious values which have either no effect or (because of jitter) an unwanted effect. Third, you still have extreme elevator values toggling the parking brake. I find that fascinating. Care to explain? Last, but probably not least, you are now using FS controls to the exclusion of any directness. Therefore every operation here involves lots of SimConnect activity (3 exchanges per axis change), so you are really gaining nothing by using FSUIPC assignments and certainly you are not benefitting at all from any of the improvements I made recently. I'm not sure why you've done this -- it is perfectly legitimate, just a bit mystifying. This is because, in order to calibrate axes coming from FS, as all yours are (because you directed them back to FS), FSUIPC has to place SimConnect intercepts on them. But it must only do this on the ones which are in use -- otherwise it risks wrecking things for add-ons like LevelD 767 and PMDG aircraft. Each time you load a new aircraft it clears down all the intercepts and waits for axes to be used again, so that it doesn't keep intercepting axes it shouldn't. How an axis behaves BEFORE the intercept is in place is in accordance with what FS makes of its value, without the benefit of any FSUIPC calibration or Reversal or Mapping, etc. FSUIPC's intercept will occur after the one reading, so it doesn't persist -- unless of course a second reading doesn't arrive (you don't move the axis and there's no jitter), in which case you might have a problem. This can be solved in one of two ways, one better than the other. The best way is to use Direct to FSUIPC calibration mode for every axis, all of them. This way there's no worries about interception, because they don't need intercepting, and, with the recent changes, SimConnect is not even used once, let alone three times per axis change as you have at present. On changes of aircraft you may still need to move a lever to get a reading set though, unless you take great care to save a starting Flight for each aircraft with things set normally, and load the aircraft by loading the flight rather than by selecting an aircraft. I think this can apply no matter how you use your axes. The other way is to tell FSUIPC to intercept axes regardless. If you are not using any add-ons which this would adversely affect, then this will work too. It doesn't make anything more efficient though. To do this use this parameter, documented in the Advanced users guide: AxisIntercepts can be set to ‘Yes’ to force the intercepting and forwarding of axis controls by FSUIPC4, even if this action is not needed for FSUIPC4 calibration (where it will be done automatically in any case). This action will be needed for some “fly-by-wire” aircraft only. Regards Pete

Sorry, don't know how to do that. Scenery / Graphics has never been an area I've hacked into. I had to look into the traffic stuff in order to provide TCAS information, and that was made easier by MS providing traffic Explorer. Regards Pete

I've just looked for you. The only sentences it has in common with GPSout are RMC and GGA, but these should be adequate (they have been for most every GPS and moving map program so far). Looking at its code for parsing GGA it should work fine. I suspect you've not tried the correct combination in GPSout.INI -- RMC and GGA. Pete

Sorry, 3.75 is very much out of date and not supported. Also you need to state the version of GPSout. If it isn't the current version (see the Current Versions announcement above), please update that too. The altitude is only provided in certain sentences (by definition). If you've tried them all it is likely that this XCSoar program needs one not supported by GPSout. You need to find out what XCSoar needs and see if GPSout can provide it. Every provision in GPSout has been made to fulfill needs of programs, and so far it has fulfilled every one. It seems unlikely the XCSoar is so very different, but you never know. If there's no or inadequate documentation for XCSoar, and it is "open source" why not look at that source and see what sentences it needs? Well they would blame someone else's code, wouldn't they, even though it's been proven good over a period of nearly 11 years! Also GPSout is freeware, not commercial, so they are probably wrong twice. Please don't come back until you are up to date, using supported versions. Pete

I need to see the FSUIPC4.LOG and PFCFSX.LOG files. Also it might help to enable SimConnect logging (see the FSX Help announcement above for instructions) and show me the first page or three from that. There's an update for PFCFSX (to 4.305) in the FSX Downloads announcemetn and also version 4.294 of FSUIPC4. It might be a good idea to install those first. Pete

This phenomenon is actually described in the documentation and is caused by the Server timing out later than the Client, so when the Client decides the connection has failed and re-connects, for a time the Server thinks there's another client, and so on. To find out what is going on you need to look at the Logs. That is what they are for. There will be a Server log and a Client log. if you don't understand them, show them to me. Pete