Pete Dowson

Strange. That does virtually nothing, just changes a timer, and it hasn't changed over several P3D versions. Thanks. I'll take a look now. Pete

You need to delete you XX files and the wxstationlist.bin. One of them has become corrupted. when you report crashes I always need to see both the FSUIPC4.LOG file AND the Windows crash data -- but only when using the latest version of FSUIPC (yes, 4,957 at present). Pete

Ah, okay. Sorry. Thought these controls were aimed at FS directly. Er, the "game calibration"? Which "game" is this? In FSX, the only calibration was not actually in FS but in the Windows Game Controllers. That most certainly is very important indeed, as that controls the values which are fed to FSUIPC in the first place unless you select "Raw" input". If you mean P3D, then I don't know. I think that added stuff of their own recently, didn't they? If so I don't think those will affect FSUIPC assignment. The game controllers setting will still be important though, again unless you select "raw". Pete

There are no "offsets" to do things like increment and decrement values. The offsets contain the values which you can read, change yourself, and write back. That's the whole point of providing such access in the first place! If all you want to do it by increment and decrement using the FS facilities for such, use the FS controls for these things. you can send FS controls via offsets too -- see 3110. Pete

Always download it in any case. Unfortunately it isn't my website and I cannot change the text, but the link always points to the current version. Enrico Schiratti is always asked to update the text, but he's not always very quick. Pete

It looks like the usual Weather corruption problem., but I really do need the Windows crash data you referred to here That message should not only contain the module name but also the error code and the location! Essential information! Just guessing as a consequence of missing information, but it is most likely a crash caused by memory corruption caused by by pointers or size values in data. Unfortunately the WX weather data files are not checked by FS when loaded. Of course, it could also be a corruption in one of the BGL's or textures loading for that scenery. To distinguish between Weather corruption and Scenery corruption you can stop FSUIPC reading the weather by using: WeatherReadFactor=0 which you will find, to change, in the [General] section of the FSUIPC4.INI file, in the FS Modules folder. Or,you can add NoWeatherAtAll=Yes tp the [General] section to stop FSUIPC having anything whatsoever to do with t. The only way then to correct the issue is to delete the weather files (.WX) from your Flight Simulator X Files folder in your Documents, and the wxstationlist.bin from the same folder as the FSX.CFG file. The WX files are simply where FS saves the current weather with its Flights, and the WXstationList.bin file will be rebuilt on the next P3D load. If the results are different between P3D 3.3 and 3.4 as you say, please show logs and crash data for both. Pete

Throttle is an analogue control. Any value can be set. Why not use Throttle Set or Axis Throttle Set with a suitable parameter? The fixed throttle values are just those used by the keyboard 1-9 key presses by default, hence in 10% increments. The analogue range for forward thrust is 0-16383, so 10% would need a parameter of 1638. BTW general support questions like this should be posted to the main Support Forum. This subforum is a specialist one for Paul Henty's .NET DLL. Pete

Any good reason you use key presses instead of the relevant FS controls? Key presses are looked up in the key press assignments list by FS and converted to the controls which you could assign to directly instead. Going so indirectly seems rather inefficient. No. One with the modifier selected as "pressed" and one with it not pressed. Otherwise the one with no modifier condition will always operate so you'd get two actions. Ah, I see you've done that anyway. That's good. The numbers on the left are just sequence numbers, so any free number in the list or one after the last, yes. They determine the order in which the lines are processed, so can be important when one sets a condition for another or you have a defined sequence of key presses or controls. They have no other significance. Just press it with the Buttons tab shown and see what FSUIPC identifies it as. To determine which FS controls to use instead of those key presses, enable Event logging in FSUIPC and see the controls logged when you use the keys. You can even (temporarily) run FS in Windowed mode and enable the FSUIPC console log so you can see them logged in real time. Pete

Yes, everything! Version 3.4 of P3D only came out this week, long after the release of FSUIPC 4.955c. A compatible version of FSUIPC was released the day after -- 4.957! Please ALWAYS check for updates. You can't expect things to work if you blindly go on using old versions of add-ons with new versions of P3D! Pete

There's never any need to uninstall, and the installer never changes any of your files or settings. It simply updates the DLL module itself, all of the documentation in FSUIPC Documents subfolder, and makes sure your settings in the FS/P3D file DLL.XML are correct. So, just run the installer. You can do that as much as you like. Pete

I've had a chance to look at this earlier than I expected, and I can't get any wrong results here. The code for recgnising the occurrent of the chosen end-of-block character is as simple as it sounds, and it just stops copying the characters to the result when it is seen. So, I'm rather puzzled. I could maybe try some extra logging in a test version for you, but before that, in case it is something simple, could you try using a visible character as the terminator instead. For instance the character 'X'? Pete

Not really. Masks are binary patterns of bits, designed to allow you to test for specific bit changes in a bit-oriented value, of which there are plenty (usually indicating conditions or switch settings). The number 10,000 in decimal is Hex 0x2710, so you can't even get close with a mask of x2000, which would trigger at 8192. Really it is easiest just to take all numbers and look out for 10000 or the first value you see above. If you really thought that might be detrimental to performance, use a Timer event instead, maybe for 100 mSecs, and read the offset on that to check. Pete

Okay. On the length restrictions, by default I get a range of runway lengths from 1503 (shortest) up to 16568. Of course those < 1500 are eliminated by default in any case. With />10000 I get 10001 to 16568. With />500 I get runways from 526 (yes, 526 feet!), again up to 16568. 07VT is the example with 526 feet runways. Finally, with \>0, I get runways from 33 feet, up to 16568. I'm sure the 33 foot runway is a dummy (it's for an add-on KTDW), one of those "ghost (invisible) runways thee to try and assert more control over AI traffic. One of the shortest with a proper runway is probably this one with just 150 feet:: <ICAO id="0WN5"> <ICAOName>Potts Field</ICAOName> <Country>United States</Country> <State>Wisconsin</State> <City>North Cape</City> <File>Scenery\0302\scenery\APX24160.bgl</File> <SceneryName>0302 Base</SceneryName> <Longitude>-88.048691</Longitude> <Latitude>42.799740</Latitude> <Altitude>815</Altitude> <MagVar>-2.000</MagVar> <Runway id="10"> <Len>150</Len> <Hdg>100.000</Hdg> <Def>Grass</Def> <ILSFreq></ILSFreq> <ILSHdg></ILSHdg> <ILSid></ILSid> <ILSslope>0.00</ILSslope> <Lat>42.799763</Lat> <Lon>-88.048965</Lon> <FSStartLat>42.799767</FSStartLat> <FSStartLon>-88.048965</FSStartLon> <ClosedLanding>FALSE</ClosedLanding> <ClosedTakeoff>FALSE</ClosedTakeoff> <ApproachLights>NONE</ApproachLights> <EdgeLights>NONE</EdgeLights> <CenterLights>NONE</CenterLights> <CenterRed>FALSE</CenterRed> <EndLights>FALSE</EndLights> <REIL>FALSE</REIL> <Touchdown>FALSE</Touchdown> <Strobes>0</Strobes> <LeftVASI>NONE</LeftVASI> <RightVASI>NONE</RightVASI> <ThresholdOffset>0</ThresholdOffset> <PatternTakeOff>Left</PatternTakeOff> <PatternLanding>Left</PatternLanding> <PatternAltitude>305</PatternAltitude> </Runway> <Runway id="28"> <Len>150</Len> <Hdg>280.000</Hdg> <Def>Grass</Def> <ILSFreq></ILSFreq> <ILSHdg></ILSHdg> <ILSid></ILSid> <ILSslope>0.00</ILSslope> <Lat>42.799702</Lat> <Lon>-88.048416</Lon> <FSStartLat>42.799709</FSStartLat> <FSStartLon>-88.048424</FSStartLon> <ClosedLanding>FALSE</ClosedLanding> <ClosedTakeoff>FALSE</ClosedTakeoff> <ApproachLights>NONE</ApproachLights> <EdgeLights>NONE</EdgeLights> <CenterLights>NONE</CenterLights> <CenterRed>FALSE</CenterRed> <EndLights>FALSE</EndLights> <REIL>FALSE</REIL> <Touchdown>FALSE</Touchdown> <Strobes>0</Strobes> <LeftVASI>NONE</LeftVASI> <RightVASI>NONE</RightVASI> <ThresholdOffset>0</ThresholdOffset> <PatternTakeOff>Right</PatternTakeOff> <PatternLanding>Right</PatternLanding> <PatternAltitude>305</PatternAltitude> </Runway> </ICAO> BTW I've done these checks by sorting the file into numeric order of the length value position (the wonders of a decent text editor!), so I'm very confident in the results. All in all, I can't find anything wrong. Sorry. In looking I've made a couple of small code improvements and may release 4.6991 soon, but it seems to do exactly what was intended of it. Pete

On this one, despite the fact that the BGL encoding for the surface type has been set to "Gravel", the nomenclature for the runway is W meaning water. The only choice for the runway is blank, Left, Centre, Right and Water. The selection /WaterOnly" selects all those with W, no matter what the surface is encoded as. Airport IN53 :N39:17:30.1378 W086:49:25.0249 710ft Country Name="United States" State Name="Indiana" City Name="Spencer" Airport Name="Miller" in file: Scenery\0302\scenery\APX24180.bgl Runway 36W/18W centre: N39:17:30.1378 W086:49:25.0249 710ft Start 36W: N39:17:29.9434 W086:49:41.0360 710ft Hdg: 89.0T, Length 2600ft Computed start 36W: Lat 39.291645 Long -86.828223 Start 18W: N39:17:30.3646 W086:49:09.0120 710ft Hdg: 269.0T, Length 2600ft Computed start 18W: Lat 39.291767 Long -86.819009 Hdg: 89.000 true (MagVar -1.000), Gravel, 2600 x 50 ft *** Runway *** IN530364 Lat 39.291645 Long -86.828224 Alt 710 Hdg 90 Len 2600 Wid 50 *** Runway *** IN530184 Lat 39.291767 Long -86.819008 Alt 710 Hdg 270 Len 2600 Wid 50 FSM A/P IN53, lat=39.291710, long=-86.823616, alt=710 On a similar vein to the earlier question: This is the same as the previous/y answered question -- only those two runways have defined thresholds, see: Airport EDCY :N51:34:37.1785 E014:08:13.2004 375ft Country Name="Germany" State Name="" City Name="Spremberg" Airport Name="Welzow" in file: Scenery\0601\scenery\APX51130.bgl Runway 13W/31W centre: N51:33:19.3997 E014:06:48.5307 375ft Computed start 13W: Lat 51.551655 Long 14.122732 Computed start 31W: Lat 51.559124 Long 14.104229 Hdg: 302.983 true (MagVar 2.000), Water, 5000 x 1000 ft *** Runway *** EDCY0134 Lat 51.551655 Long 14.122732 Alt 375 Hdg 301 Len 5000 Wid 1000 *** Runway *** EDCY0314 Lat 51.559124 Long 14.104229 Alt 375 Hdg 121 Len 5000 Wid 1000 Runway 4 /22 centre: N51:34:43.7221 E014:08:20.8349 375ft Hdg: 35.980 true (MagVar 2.000), Concrete, 6551 x 98 ft Runway 4L/22R centre: N51:33:18.3955 E014:05:51.2159 375ft Hdg: 32.301 true (MagVar 2.000), Water, 5000 x 1000 ft COM: Type=11 (FSS), Freq=134.85, Name="WELZOW" FSM A/P EDCY, lat=51.577000, long=14.137000, alt=375 The only other one to look at is the />0 option I believe. Since I've no idea what the smallest one is, I'll start with />10000 to make sure the length check is applied. Pete

I'm just starting to look at these things. Taking this first question, I am puzzled. As far as I can see, those runways without "Start Positions" designated (i.e. no thresholds for take off or landing positively identified) are simply not included at all in the Runways.XML. For instance, here is the entry for the default MYZ2: <ICAO id="MYZ2"> <ICAOName>Cape Eleuthera</ICAOName> <Country>Bahamas, The</Country> <City>Cape Eleuthera</City> <File>Scenery\0302\scenery\APX27230.bgl</File> <SceneryName>0302 Base</SceneryName> <Longitude>-76.300003</Longitude> <Latitude>24.783333</Latitude> <Altitude>9</Altitude> <MagVar>-3.000</MagVar> </ICAO> The same applies to the VHHX I thought I'd identified as another example, and also, in fact, to your AK02 example. I'm not really willing to make such drastic changes to the program in order to add unusable runways to the XML file. It would mean whole new structures internally, a more sorting routines. The current Runway data, included in all files, is dependent upon their having identifying thresholds for the majority of programs which use them -- for navigational information, mostly. I know some folks who wanted more from the files instead took to reading the log file (Runways.txt) instead, though if you do that you should search for airports from the end back because the later ones usually override the earlier one (depending on the "deletion" entries). BTW I note that in one of my previous replies I said it looked like I hadn't omitted such runways in the XML whereas I had in the other files. On checking again today I really think I must have been mistaken. Even the code shows that is impossible, as all of the runway stuff is written to all the filetypes at the same point, for each airport in turn. I'll look at the length and water restrictions now, but could you please back-check and make sure the results you got which seemed wrong were not partly because of the sheer omission of runways with no defined thresholds? BTW there is no option "/<", which explains why that had no effect. Pete

If you mean 4.955, then it doesn't work with P3D3.4. You need 4.956 released two weeks ago, and now 4.957, released today. Please always check for latest versions, especially when you are using a P3D only just released by L-M this week!!! (And note the specific fix listed "Made controls list scan complete set of Controls in P3D versions 2 & 3 -- previous list was missing some"). Pete

Sorry, which manual? The only ones about Lua at all are the Lua documents in the separate package. The Lua support is an add-on extra with FSUIPC, it is not covered at all in the main User guide, And in any case, how did you think FSUIPC knew what you meant? How would it identify your Lua program? Did it never strike you as odd assigning to nothing but a parameter? No control name, nothing? Pete

Yes, but not till next week. Sorry, I have a lot to do with the release of P3D 3.4 and other things. Have you tried the best solution, adopted by most -- that of using fixed length blocks as I suggested? If you don't really want to try that, remind me next week. But please note that I am away again for over 2 weeks from Thursday. Pete

Er, parameter 222 for which control? There's no "control" called "222". You need to assign to a control -- there's a drop-down list! They are all named, NOT numbered! See the drop-down list, which is in alphabetical order. Practice with a normal default aircraft first. I've no idea what your F4 is doing, but it can't use controls like "222"! Nor control 0 as you assigned here: You assigned control 0 (non-existent) with parameter 222! That simply is nonsense. Sorry. Here you contradict the above: Lua assignments all start with "Lua <name of lua file>", in the drop down list. Pete

There are two button assignments, one which aplies to all aircraft (i.e. not specific to a Profile): This control number is not valid. not sure why you selected <custom control> in the drop-down list and then entered "3". There's really no possibility of that being a valid control. The other is specific to the F14 and again it isn't valid, for the same reason! Both of these buttons are on the throttle device. I think you'd better explain what you are doing, step-by-step, because what you've done makes no sense. And no way will FSUIPC simply lose assignments -- they are saved in the INI file as soon as you press "OK" (but not if you press Cancel or Escape, of course). Note that with buttons and keys (not axes) general assignments apply also to profiles unless overridden. You select between them using the Profile checkbox on the Buttons tab. You can also use Button/Key logging to check your actions. See the Logging tab. Pete

Hi Jouni, It is the same here, though here it doesn't miss the menu at all. But I think that is just a matter of timing. I fixed it so it will work – the Window name had been changed, which is the reason. However, also due to the way the P3D screen is now drawn, more like FSX’s, is isn’t possible for me to hide the in-sim window. The best I can do is as with FSX – make it a bit smaller and more it top left (which luckily is out of easy site from my cockpit window). The fix will be in 4.957 which I hope to release later tomorrow, or at the latest on Friday. Pete

This will be because you are not entering the correct registration data. You need the name, email and key from your FSUIPC3 purchase. An FSUIPC4 registration is not valid for FSUIPC3. This will be a video driver problem -- FSUIPC's dialog is a standard Windows dialog. Try putting FS9 into Windowed mode (ALT + ENTER). Pete

Er, "SimConnectP3D3.dll is installed by the FSUIPC4 installer, it is NOT from the P3D SDK. You need to run the current FSUIPC4 installer, THEN copy over the FSUIPC4.DLL with the 4.956 version! Pete

Some possibly good news. I think it's due to a Window name change between P3Dv2 and P3Dv3. FSUIPC tracks the Window to see when it is closed. If it doesn't find it it assumes it is closed and sends the "clear" to Wideclient. The names were the same in FSX and P3Dv1, but changed in P3Dv2. I think they've changed again in P3Dv3! I'm just about to do some tests. If it is okay here after putting the new names in I'll give you a link to a test version, 4.956a. But I may have to go ahead tomorrow with 4.957 in any case.

I've just run thorough tests on this with FSX-SE, which is my normal sim. It works fine every time there. But then I ran P3D version 3.3.5 (not installed 3.4 there yet), and it looks like something has changed in this area of P3D, as it used to work fine. In my case it is worse that your experience. The GSX menu comes up in WideClient initially, but only lasts 2 seconds or less then removes back to being displayed on the P3D screen! I'm investigating, but if I cannot find a solution relatively quickly it will have to wait till maybe next week, as I must get a revised install package out very soon for P3D 3.4. Apart from myself, you are the only other person I've heard of using the text menu diversion option! Meanwhile, it would help me identify why my experience is different to yours to get some extra FSUIPC logging. Please add these lines to your FSUIPC4.INI [General] section: Debug=Please LogExtras=32 then reproduce the problem, in an exact sequence which you can write down, then show me the log, or ZIP it and send it to petedowson@btconnect.com. Thanks Pete