Pete Dowson

Actually my main source for BGL formats has always been the publications by Winfried Orthmann. He did very comprehensive guides for Fs2002 and FS2004. I seem to only have printed copies these days -- I think the original DOC files were lost on one of my older PCs a few years ago. If you Google on his name I think you may still find them. Regards Pete

Okay, I have checked into this to see what is going on. Basically it is all in the name of ongoing compatibility. The list of surfaces I gave above is applicable to the "new BGL" structures from FS9 onwards. The surfaces in the XML output are those which have been available in FS since at least FS98. MakeRunways has been going since then, or even before, and its files are compatible across the whoe range of FS versions FS98 to FSX/ESP. The translation from the more extensive new surface types into the old ones was rather arbitrary, and I may have got it wrong. Here it is: NEW TYPE OLD TYPE "CONCRETE" // 0 2 concrete "GRASS", // 1 4 grass "WATER", // 2 10 water "UNKNOWN 3",// 3 0 unknown "ASPHALT", // 4 3 asphalt "UNKNOWN 5",// 5 0 unknown "UNKNOWN 6",// 6 0 unknown "CLAY", // 7 1 dirt "SNOW", // 8 8 snow "ICE", // 9 8 snow "UNKNOWN 10",// 10 0 unknown "UNKNOWN 11",// 11 0 unknown "DIRT", // 12 1 dirt "CORAL", // 13 9 coral "GRAVEL", // 14 5 gravel "OIL_TREATED",// 15 6 oil-treated "STEEL_MATS",// 16 7 mats "BITUMINOUS",// 17 3 asphalt "BRICK", // 18 0 unknown "MACADAM", // 19 3 asphalt "PLANKS", // 20 0 unknown "SAND", // 21 5 gravel "SHALE", // 22 5 gravel "TARMAC", // 23 3 asphalt Now those on the right are all that are available to maintain inter-FS compatibility. Maybe I've made a bad choice there somewhere. For instance, should I class "sand" more as "dirt"? It depends, surely, how fine it is. And how firm? Firm fine sand is maybe more like dirt, but gravel is probably a more apt description for many beaches, and it may be safer assuming the worst case. As for tar/oil based gravel (or aggregate), for all those I only have asphalt as the closest. As far as I am aware "macadam" is closer to that than to any of the others. Again, from Wikipedia: Surely the "binding" stops it being loose (it "cements" it), so "gravel" would be inappropriate. It looks and acts most like asphalt compared to any of the others. As for Snow and Ice, there's no Ice choice for compatibility, but I think most ice-based runways are probably compacted snow in any case. If you really do think I've made a mistake, do point it out and explain, please. Regards Pete

"Map in FS9"? Sorry, I'm confused. You mean ASSIGN in FS? In your previous messages you weren't talking about FSUIPC's axis assignment facilities at all? Only calibration? Everything I was talking about was purely on the assumption you were talking about assigning axes in FSUIPC. You certainly don't need to assign in FS first. In fact it is very bad to assign in FS if you intend to assign in FSUIPC! Pete

I'm pretty sure all of the calibration facilities, including flap notches, can be accomplished no matter how you assign the axes. Really it is more efficient is all of your axes are via the same mechanism -- so all in FSUIPC with "direct to FSUIPC calibration" checked, or all assigned in FS (but then make sure max sensitivity and min dead zone in FS). The option for assigning in FSUIPC but still sending the values via FS controls is there for two reasons (1) there are many possible such assignments which are NOT covered by FSUIPC calibration in any case, and (2) there are some add-on aircraft panels which need to process the original FS controls and won't work with FSUIPC control methods. Maybe. ;-) Regards Pete

That's indeed very strange because the one call to Windows' "joy" API is used to obtain both button and axis values. Does it see the yoke and rudder axes, you only mention the quadrant? Is the driver for the throttle quadrant a default one, part of Win7, or one installed from CH installation disks? I suspect that something isn't updating the registry data from the quadrant correctly. Unlike FS9, FSUIPC doesn't use "DirectInput" but the original "joy" interface which has been standard on Windows since Win3. The same interface was used on FS until around FS2002 times I think. And evidently Win7 32-bit does support the interface otherwise you'd not get the buttons recognised by FSUIPC. Try the attached programs. "joyview" uses the same interface as FSUIPC, whilst "DIview" uses DirectInput, the same interface as FS9. FSUIPC4 uses DirectInput for axes, but still the joy interface for buttons. When I did the re-write of FSUIPC for FSX I changed over because DirectInput does provide up to 8 axes (instead of 6) and several POVs (hats) instead on only one. But the work involved in updating FSUIPC3 for this interface is quite forbidding. I suppose if FS9 is going to have the long life it looks like having I might have to find time to make the transition, though. If I do, updating users might have to do some re-asssignment of axes as the same axes don't correspond. There usually has to be at least an "inf" installation file, for the Registry, unless it is all purely default operation. Hmmm. It might be worth trying to find the relevant .inf file from the Vista installation. Maybe the Win7 RC version has some defects in the .inf's they included. I'm using Win7 RC 64-bit on my two FSX systems. Maybe, depending on your answers and results I can find the relevant inf and compare it with the Vista 64 versions (I have dual boot capability still on one system). To find the correct part of the .inf file(s) I'd need some more data from you about what the Quadrant looks like to Windows. For this, please run HidScanner, attached also, and show me the Log. It should list all of the HIDs (Human Interface Devices) with details. Regards Pete joyview.zip DIView.zip HidScanner.zip

I really don't know what you've got going on there. There's no difference in what FSUIPC is doing the each time. Please download the latest version (3.918) from the Updates announcement above, and try that again. It works fine here, 100%. If there's still a problem, possibly you have some mix up with setting aircraft or profile-specific options? Sounds right -- there will be defaults set from the #1 value, so you have min (#0) notch #1, and max (#2). Now you carry on and calibrate each of the 7 intermediate notches #1 to #7. You'll see the max notch number increase to #8 in the end. Seems like you simply are not doing the calibrations. Notch calibration is like doing centre calibration on the yoke -- except you have (for a 9-notch flap lever) 7 "centre" positions to calibrate. That's the whole point. If you don't have real notches for the flaps lever, and are happy to have FSUIPC compute evenly spaced-out values, do NOT use the detente calibration facility. I think you are misunderstanding what this is for, perhaps? Regards Pete

Two things: 1. FSUIPC 3.81 is so far out of date I really cannot comment. Please update to the currently supported version if you want support. 2. There's no difference for Win7. If Windows and FS can see your kit, so can FSUIPC. If they are assigned in FS then can be calibrated in FSUIPC. Maybe you've got no drivers installed? Regards Pete

Ah, but then FSUIPC for FS9 never had an installer! FSX changed all that by not even having a Modules folder and needing entries in the DLL.XML file in order to get a module loaded! ;-) Glad you've found everything now! Pete

Not for anything of mine. The keys enable the user facilities in FSUIPC and the Server capabilities of WideFS. You can have as many Client PCs as you like. Sorry, I just buy books on these things from a bookshop. Expensive option. Really all you should need is the help from Microsoft Windows. Yes, but I'm assuming this Netbook is running Windows? I notice some of them run some cut down version of Linux? If it isn't Windows, the WideFS route is a dead duck. You only need it if you are using WideFS. If you connect by serial ports then you have real serial port input to your moving map, not virtual. The point is that the Moving Map software will be expecting a GPS connection via a serial port, it isn't written to interface to Flight Sim! You have checked that the map software does allow input in NMEA 0183 or Aviation format? The documentation will surely tell you about setting up the serial port connection? Regards Pete

Almost no PCs, let alone Netbooks, have serial ports these days. But USB's can do anything., Yuo can get any and all manner of ports plugging into USB (even old extinct Game Ports!). A simple USB-Serial adapter can cost as little as a few dollars or pounds. There are two ways of linking the PC to the Netbook. The most useful might be to Network them -- connect them via an Ethernet cable, or use the Wireless connection on the netbook and get a Wireless card or USB adapter for the PC. ONce you have the two networked, you'd need to purchase a WideFS key, and you'd need a Virtual Serial Port driver in the Netbook. Details of this stuff are in the simple GPSout documentation. Alternatively, two USB Serial adapters and a null modem cable linking the two. (Actually the cable only needs 3 wires -- details are also in the doc). For FS9 and before, GPSout is a separate module. You have to install FSUIPC (version 3.xxx) as well, but it doesn't need purchasing. For FSX, GPSout is part of the user facilities which you pay for when you buy a key for FSUIPC4. Same as all my software, http://www.schiratti.com/dowson. Please also peruse the Announcements in this Forum. There's a lot of information there. Regards Pete

None taken, I assure you. Sorry if you got such an impression. Ah, the XML output was something not to my specifications but specifically to those provided by the person requesting it. Sorry if it isn't to your liking or is puzzling. It seems to suit the application they had. Not *my* XML, but the XML produced from the same data is accordance with requiremnets given to me for that specific application. There is a BGL2XML converter available someplace. You might wish to use that if you have more general or perhaps more accurate needs? Right. Sorry, I don't know why the user of the XML wanted those specific conversions. I can ask them if you like. Or maybe it is some sort of error after all. Now I understand you mean the XML from MakeRunways I can check. Note that each particular file output by the MakeRunways program was done for a specific application -- except for the TXT file which is done to help folks determine what they actually need (and for me to debug things in case of problems). The only file I actually use myself is the FStarRC one -- in fact I originally wrote the program to produce the database for my FStarRC program for FliteStar flight plan conversions. This is an example from the RUNWAY.TXT ... Hdg: 140.004 true (MagVar 0.000), UNKNOWN 254, 3610 x 75 ft {snip} Correct. The name of the surface type here is "UNKNOWN 254". 254 is the code which is unknown. The comma clearly follows! I think you misinterpret my responses as if I am upset or something. I am not. I certainly don't understand where you are coming from, what your criticisms amount to, or why you'd call them errors (which you do even in the subject title). The program is simply converting BGL data into different forms for different people/applications according to their stated requirements. If they are not happy, they tell me. Also, apologies for one misunderstanding, as I originally assumed you were using something like the freeware BGL2XML converter to compare my BGL analysis with another. Now that I understand your XML stuff was referring to the (very recently added and quite forgotten, sorry) extra file produced by the program, I will certainly re-check what tabulation it is listing for each to make sure there is no error. However, as far as I recall the conversions I provided to the user requesting the XML file were specifically to their spec. I might be wrong though and will re-check tomorrow. Thank you, Regards Pete

If you are dealing with FSX why are you looking in the FS2004 controls list? It is clearly listed in the List of FSX controls: AVIONICS_MASTER_SET 66701 Have you never seen the files installed for you by the FSUIPC4 installer, nor noticed the list in the User Guide where it is itemised thus: List of FSX Controls.pdf FSX controls list (Acrobat format) ? The list is generated semi-automatically from FS itself, part of my development process. In fact it changed a bit for each version of FSX (base, SP1 and SP2). The one automatically installed into your FSX Modules folder by the FSUIPC4 installer will be the one relevant to the latest version of FSX available at the time that version of FSUIPC4 was built. Regards Pete

If you mean the PFC quadrant which works via their digital control system and connects via serial port (or USB serial adapter) to my PFC.DLL driver in the PFC, then it isn't the "aircraft recognising the throttle quadrant", but my PFC.DLL driver operating the throttles and so on in FS. All aircraft do is obey the commands from FS, which are translated from whatever inputs might be present and assigned or programmed. What joystick assignments page? You mean the one in FS "options-controls-assignments"? That is for regular joysticks, connected and calibrated in Windows' "Game controllers". For PFC digital devices you assign and calibrate in the PFC dialgoue -- go to the Modules menu, find PFC and the quadrants are assignable there. No aircraft I know of ever reads hardware directly. They are merely obeying controls sent by FS itself. Regards Pete

As Joe said, one possible reason for this, which has occurred in the past, is some sort of weird interaction with the Kensington mouse drivers. It could also be due to an old Game Port driver which is hanging, but that should affect the Axes assignments tab as well (check Windows Game Controllers for anything wrong there). Finally, there may be something responding incorrectly when FSUIPC scans for an EPIC driver, so you could try eliminating that by adding this line to the main [buttons] section in the INI: PollEpicButtons=No Regards Pete

The only thing I know of that can cause such a symptom is if the button is continually repeating -- i.e. sending off/on messages so quickly that no others get a look in. The fact that other signals from the same device do (provided that button isn't pressed first) does make it sound like a hardware rather than software problem. What's a "hub reset"? You should try actually removing power from the GF46 and then restoring it, to reset its own hardware. I don't think the hub will be doing anything. Also see if it has a problem with GoFlight's own software -- the FSX module which allows you to use the GF46 without FSUIPC's involvement. The need here is to identify whether it is definitely hardware (in which case you'd need GF support involvement) or some sort of weird software interaction. Regards Pete

It isn't just that your SimConnect is out of date, but you have no working SimConnect installation at all. FSUIPC4.5xx can operate with any of the three versions of SimConnect, but chooses the most recent if it is available as that is the most efficient and error-free. Uninstalling and re-installing FSX actually makes things worse unless when uninstalling you take great care to remove the SimConnect parts too, separately. It's a problem with the uninstaller which doesn't actually remove the SimConnect libraries, so the installer then doesn't get to repair them when they are broken. Your FSX.EXE version number (61472) seems like the SP2 version (not Acceleration). Is that correct? If so, then you could probably get FSUIPC4 installed correctly by deleting only one folder then re-installing SP2. However, that would still leave other programs, needing the SP1 or base versions high and dry. So, I suggest that you start from scratch. Uninstall SP2, SP1 and FSX, in that order. THEN delete the three SimConnect folders from the Windows\WinSxS folder. Information about deleting the folders can be found in the Announcement at the top of this forum entitled "FSX HELP: Logging or Re-installing SimConnect". Then install FSX, run it to test, then SP1, run it, then SP2. Folks do advise running it once between each update, else the requisite files may not get created/updated. Regards Pete

Best if you quoted version numbers, please as "latest" just means the latest you've noticed, and I've had folks say that when it turned out they were using one over a year old! The only thing FSUIPC might be doing when entering and exiting its options is reading and saving sections in the INI file -- depending only on which tabs you visit. There's nothing FSUIPC does which should affect AI Traffic unless you use on of its add-on traffic controls, like the traffic density ones (which won't affect VoxATC injected traffic) and the Zapper. If you don't use those it won't (can't) affect anything. Of course, to get into the options it has to get SimConnect to change to dialogue mode. Possibly entering and exiting dialogue mode may stimulate some other part of FSX into action. Or maybe it is just the graphics which of course re-draw on exit. Perhaps you should try some of the other FSX dialogues, like the display options. They might get the same result. I've recently installed Ultimate Traffic 2 (UT2), which, like VoxATC, also injects the traffic via SimConnect rather than using Traffic files (BGLs). That seems to have a problem where all the traffic is removed and re-injected every time you go into any of the FSX menu entries and exit again. The authors are still looking for a solution, I believe. Maybe this odd FSX bug (because I think it must be) is affecting VoxATC too? Note that the method of injecting traffic does not get them visible immediately. You say "on launching Vox, I sse no AI Traffic", but do you wait some seconds to see if they are merely taking a while to appear? Do you try different views, to get the graphics updated? Sorry, I think you'll need to pursue it along the VoxATC support avenues. Good luck! Regards Pete

Oh, well done. Maybe I should provide this info in offsets. Could be useful. Oh, one little possible niggle. Because this is based merely on checking the Window size against the screen size, what happens if I make my FS window size slightly bigger than the screen size and positioned so that the title bar is off screen at the top? I used to do this sort of thing to get rid of the title bar view yet still have Windowed mode and so access to other programs. Maybe we can also check whether the title bar actually exists, just to eliminate this possibility. Regards, Pete

Don't worry, I don't see many actually silly questions! And then I'm entitled to a good laugh, aren't I? ;-) The "Offset Word Set" sets a 16-bit value -- whether it is signed or unsigned isn't relevant. Signs only become relevant when you interpret the value or use it arithmetically. When just setting a value there's no difference -- that's what all the Offset Set controls only have one variant per value size, whilst the increments and decrements has both signed and unsigned variants. Anyway, the Master Battery Switch is listed in the Offsets document at offset 281C as a 4-byte value (doesn't even say signed or not) -- that's 32-bits, or a "DWORD". So, just assign to the control "Offset dword set" with an offset of 281C and a parameter of 1 to switch it on, 0 to switch it off. Most of these non-FS-assignable controls were added in FS98 days by Tim Gregson (aka "Beatle"), one of the FS team in Microsoft, when he and I were bashing things about trying to make cockpits and FS work together with hardware add-ons such as those programmable EPIC cards (ISA ones, driven by a VXD of mine back in 16-bit days when such things were easy!). What actually got implemented and what fell by the wayside was largely a matter of luck, timing, and the randomness of bean-counter interventions. There's no logical explanations for many of the choices as to what controls are there and what controls are not! Regards Pete

The TXT file is only there for diagnostics, general information. The target database files are the CSVs and so on. Which of those are wrong? It looks like your BGL to XML converter cannot differentiate between Bituminous, Tarmac and Macadam for one, nor between Shale and Sand, and gets Unknown in several places. Your XML decoder is mostly different words for the same things. In the BGLs these are just numbers. If you don't like the words, use the numbers. I don't know of any application which is using this stuff, it is merely logged for interest. How can "macadam" and "asphalt" "... be (virtually) deadly .."? As far as I am aware they are quite similar things, and may even be the same.(Wikipedia: "Tarmac (short for tarmacadam, a portmanteau for tar-penetration macadam) is a type of highway surface. Tarmac refers to a material patented by Edgar Purnell Hooley in 1901. The term is also used, with varying degrees of correctness, for a variety of other materials, including tar-grouted macadam, Tarvia, bituminous surface treatments and even modern asphalt concrete." Als "Asphalt or bitumen can sometimes be confused with tar, which is a similar black thermo-plastic material produced by the destructive distillation of coal. During the early- and mid-twentieth century when town gas was produced, tar was a readily available product and extensively used as the binder for road aggregates. The addition of tar to macadam roads led to the word tarmac, which is now used in common parlance to refer to road making materials. However, since the 1970s, when natural gas succeeded town gas, asphalt (bitumen) has completely overtaken the use of tar in these applications.") Sorry. For one I don't see any "issues" here, and for another I have many other things to do. The databases produced by MakeRunways are suited to those for whom it was designed. The decoding was based on a well known document produced by analysis of BGLs, originally for FS9 and later updated for FSX. I think all this XML stuff was much later. If you prefer XML decodes, why not use those? [LATER] For your additional enlightenment, these are the documented definitions for FS9. Those for FS2002 and before are less extensive, and don't map directly. #define SURFACE_CEMENT 0x0000 #define SURFACE_CONCRETE 0x0000 #define SURFACE_GRASS 0x0001 #define SURFACE_WATER 0x0002 #define SURFACE_ASPHALT 0x0004 #define SURFACE_CLAY 0x0007 #define SURFACE_SNOW 0x0008 #define SURFACE_ICE 0x0009 #define SURFACE_DIRT 0x000C #define SURFACE_CORAL 0x000D #define SURFACE_GRAVEL 0x000E #define SURFACE_OIL_TREATED 0x000F #define SURFACE_STEEL_MATS 0x0010 #define SURFACE_BITUMINOUS 0x0011 #define SURFACE_BRICK 0x0012 #define SURFACE_MACADAM 0x0013 #define SURFACE_PLANKS 0x0014 #define SURFACE_SAND 0x0015 #define SURFACE_SHALE 0x0016 #define SURFACE_TARMAC 0x0017 #define SURFACE_UNKNOWN 0x00FE I translated this into: "CONCRETE", // 0 "GRASS", // 1 "WATER", // 2 "UNKNOWN 3",// 3 "ASPHALT", // 4 "UNKNOWN 5",// 5 "UNKNOWN 6",// 6 "CLAY", // 7 "SNOW", // 8 "ICE", // 9 "UNKNOWN 10",// 10 "UNKNOWN 11",// 11 "DIRT", // 12 "CORAL", // 13 "GRAVEL", // 14 "OIL_TREATED",// 15 "STEEL_MATS",// 16 "BITUMINOUS",// 17 "BRICK", // 18 "MACADAM", // 19 "PLANKS", // 20 "SAND", // 21 "SHALE", // 22 "TARMAC", // 23 You'll see there should be no comma immediately after "UNKNOWN" as there is a format number as part of the string. Regards Pete

I'm not a gauge programmer. Is that called only once per flight/aircraft load? I assume you mean dwResult is set to 9 somewhere else, not in the code fragment you showed, as I presume that is the reconnection sequence? Did you check the FSUIPC log? Does it indicate a FlightLoaded event occurring? If your aircraft is being reloaded then that "FsuipcMem" area may be relocated elsewhere. Or possibly your PC is short of memory and when you change modes parts of FS are being thrown out and reloaded afterwards. Shouldn't the memory area be one you allocate on the heap instead of reserving inside your gauge? Of course you have to free it when your gauge is removed, too -- isn't there are call for tidying up before exit? Well, apart from the possibility of the shared memory address changing, and not knowing what "PANEL_SERVICE_PRE_UPDATE" is, no. Regards Pete

With reference to that request, and my reply: I woke up Saturday morning with a bright idea -- of how to do it quite easily. So I have now done it and tested it. Please see the Updates Announcement above. With FSUIPC 3.918 or 4.525 you can assign axes to up to 2 offsets right there in the Axis Assignments tab. Regards Pete

AhI found the assignable control, in FS9's assignments, saying "Display/Hide Map" (which isn't assigned to anything by default as far as I can tell). But I assigned "K" and tried it, and, of course, it brings up the Modal dialogue showing the map. Despite the name "Display/Hide, pressing K again of course doesn't hide the map. Only the normal dialogue controls like escape and the dialogue buttons can do that. All FS menu-type dialogues are "modal", meaning they stop everything else. Nothing else in the main FS processing thread is running, can run, when it is displayed. This includes FSUIPC, which therefore cannot see your keys or buttons. Sorry. Regards Pete

I just received your PM, sent via the simFlight boss. Perhaps you did not see the little "PM" button on my messages here, which can be used for confidential matters? I understand why you cannot explain further how the folder protection affects the Ethernet interaction -- I only wanted to understand this odd effect in case others had the same problem, and this is why I lastly expressed my hope that no one else does -- precisely because I don't understand. However, I don't understand why you think my responses here are "curt". If you mean "short and to the point", then I would take that as a compliment, as I always try to be, but then you added something about not taking offense, which does rather confuse me I'm afraid. How would I have offended you? I've looked back over the entire interaction and can see nothing to warrant this. :-( Regards Pete

Curiouser and curiouser! Tell me, do you get the FLT logged by FSUIPC4 when this happens, because I cannot see how I can increment 3F02 yet bypass the flight logging. And the Flight logging only happens when I receive a "FlightLoaded" event from SimConnect, as that is where I get the flight pathname. It would be interesting to note if this is indeed the name of the last flight loaded. If so, I am wondering whether, somehow, the graphics involved in your panels, or possibly the plane modelling itself, are causing an auto flight reload, as you get after a plane crash (the same as CTRL+; I think). However, I would have thought that, if it were a genuine flight re-load you'd notice the time taken to replenish the scenery and the AI? Perhaps you should select a place with dense scenery and lots of AI, save a flight there, then change screen modes, just to see if you then notice it? Regards Pete