Pete Dowson

The usual reason for this is that FSX is not closing down successfully. FSUIPC tends often to be the last part running during FSX close down (because it often has Lua threads and possibly WideFs client connections to close too), and therefore Windows ascribes the close problem to FSUIPC, which it usually ins't. It then makrs it as a "bad DLL" in the registry -- an entry which is cleared by FSUIPC's Installer. As well as checking the FSUIPC log at the end of what you consider a "normal" closedown (not after the next error to load, as FSUIPC isn't then really loaded), please have a look in windows Event Viewer and see if there are any crashes or hangs ascribed to FSX. If so, show the details here. Pete

The runways are seen: Runway 23 /5 centre: N70:40:53.6798 E023:40:38.0603 263ft Runway 23 closed for landing and take-off Runway 5 closed for landing and take-off Hdg: 55.980 true (MagVar 8.000), Asphalt, 16 x 0 ft Primary ILS ID = HA Primary ILS: HA 111.35 Hdg: 56.0 , Flags: DME BC "LOC/DME 23" Secondary ILS ID = HF Secondary ILS: HF 110.70 Hdg: 236.0 , Flags: DME BC "LOC/DME 05" but (a) they are both closed for takeoff and landing, and (b) there are no "start" positions defined -- i.e. places to put the aircraft for takeoff. The defaults (which have been deleted by the addon) has: Runway 5 /23 centre: N70:40:46.6826 E023:40:06.9889 260ft Start 5 : N70:40:38.9728 E023:39:32.5123 260ft Hdg: 56.0T, Length 2887ft Computed start 5 : Lat 70.677422 Long 23.658688 Offset Threshold primary: 135 feet Start 23 : N70:40:54.3925 E023:40:41.4640 260ft Hdg: 236.0T, Length 2887ft Computed start 23 : Lat 70.681847 Long 23.678527 Offset Threshold secondary: 138 feet Hdg: 55.980 true (MagVar 8.000), Asphalt, 2887 x 98 ft Primary ILS ID = HA Primary ILS: HA 111.35 Hdg: 56.0 , Flags: DME BC "LOC/DME 05" Secondary ILS ID = HF Secondary ILS: HF 110.70 Hdg: 236.0 , Flags: DME BC "LOC/DME 23" *** Runway *** ENHF0050 Lat 70.677422 Long 23.658688 Alt 260 Hdg 48 Len 2887 Wid 98 ILS 111.35, Flags: DME BC *** Runway *** ENHF0230 Lat 70.681847 Long 23.678528 Alt 260 Hdg 228 Len 2887 Wid 98 ILS 110.70, Flags: DME BC You see that there are Start points for both runways. Without those MakeRunways cannot compute all the data needed. Pete

Not the airport, the runways at the airport. Can you use Go To Airport to place your aircraft on the runway ready for takeoff? Pete

Do you mean "flying on autopilot" by any chance? I think you are seeking the wrong solution. That is why it is always better to state the problem you are wanting to solve than to ask for a solution without explaining the reasons. You still need controls, and most aircraft (even Sim aircraft) will not mind the odd movement of the controls without cutting autopilot out. But it is unrealistic to disable the controls altogether. In an emergency you need to be able to take over quickly, and that is by moving the controls more than just the odd nudge. If you cannot avoid moving the controls whilst on autopilot, or they are jittering and therefore causing involuntary A/P disconnect, then you just need a wider null zone -- i.e. in FSUIPC calibration terms, more of a range between the two "centre" positions you've calibrated. If you aren't calibrating in FSUIPC then just extend the dead zone in the sim. Pete

Yes, good. I am pretty sure that this is because it ISN'T the axis value you can use as the parameter. I think the parameter is a mouse action encoding, and those are listed in the same document from which you obtained the custom control numbers. There is no PMDG control which sets the number. It is only adjusted up (with one mouse encoding) or down (with another). So, you can only use your axis as if it were two buttons -- one to increase, one to decrease. This is why said an analogue axis is usually not suitable, and it seems especially so in the case of PMDG. Really, for more specific help with PMDG you'd probably be better served in the PMDG forum. What parameter are you setting? The word "parameter" isn't numeric. Only numeric parameters are valid! I expect you are sendng the control with a parameter of 0, and it's possible that the PMDG controls don't do anything on 0. you need the parameters for "!left click" and "right click". Ah, sorry. You han't anywhere said which version of FSUIPC you are using. The page number I found was for FSUIPC4, which is the one for FSX, FSX-SE and P3D1-3. Pete

But surely during flight you ALWAYS touch use your controls. That's how you control the flight! How are you flying without controls? Always using only the keyboard? If so, why have the controls? Pete

It sounds like there is something wrong with the AFD (airport facility details) BGL file. We don't need to whole log (Runways.txt). Just find all the sections for ENHF, by searching, and select and copy those into another text file. There will be the default one AND, hopefully, the add-on one. That selection should be short enough to show in a message here. (Use the <> button above the edit area to paste it in, so it looks boxed as I have done below). The ENHF from the default scrnery shows up (I don't have an add-on for that airport0. here's the runways.xml entry for it: <ICAO id="ENHF"> <ICAOName>Hammerfest</ICAOName> <Country>Norway</Country> <City>Hammerfest</City> <File>Scenery\0600\scenery\APX54060.bgl</File> <SceneryName>0600 Base</SceneryName> <Longitude>23.668612</Longitude> <Latitude>70.679726</Latitude> <Altitude>260</Altitude> <MagVar>8.000</MagVar> <Runway id="05"> <Len>2887</Len> <Hdg>47.980</Hdg> <Def>Asphalt</Def> <ILSFreq>111.35</ILSFreq> <ILSHdg>47.98</ILSHdg> <ILSid>HA</ILSid> <ILSslope>0.00</ILSslope> <ILSname>LOC/DME 05</ILSname> <Lat>70.677422</Lat> <Lon>23.658688</Lon> <FSStartLat>70.677498</FSStartLat> <FSStartLon>23.659031</FSStartLon> <ClosedLanding>FALSE</ClosedLanding> <ClosedTakeoff>FALSE</ClosedTakeoff> <ApproachLights>ALSF1</ApproachLights> <EdgeLights>HIGH</EdgeLights> <CenterLights>NONE</CenterLights> <CenterRed>FALSE</CenterRed> <EndLights>TRUE</EndLights> <REIL>FALSE</REIL> <Touchdown>TRUE</Touchdown> <Strobes>15</Strobes> <LeftVASI>PVASI</LeftVASI> <LeftVASIbiasX>21.04</LeftVASIbiasX> <LeftVASIbiasZ>170.08</LeftVASIbiasZ> <LeftVASIspacing>91.45</LeftVASIspacing> <LeftVASIpitch>4.70</LeftVASIpitch> <RightVASI>NONE</RightVASI> <ThresholdOffset>135</ThresholdOffset> <PatternTakeOff>Left</PatternTakeOff> <PatternLanding>Left</PatternLanding> <PatternAltitude>305</PatternAltitude> </Runway> <Runway id="23"> <Len>2887</Len> <Hdg>227.980</Hdg> <Def>Asphalt</Def> <ILSFreq>110.70</ILSFreq> <ILSHdg>227.9</ILSHdg> <ILSid>HF</ILSid> <ILSslope>0.00</ILSslope> <ILSname>LOC/DME 23</ILSname> <Lat>70.681847</Lat> <Lon>23.678528</Lon> <FSStartLat>70.681786</FSStartLat> <FSStartLon>23.678185</FSStartLon> <ClosedLanding>FALSE</ClosedLanding> <ClosedTakeoff>FALSE</ClosedTakeoff> <ApproachLights>RAIL</ApproachLights> <EdgeLights>HIGH</EdgeLights> <CenterLights>NONE</CenterLights> <CenterRed>FALSE</CenterRed> <EndLights>FALSE</EndLights> <REIL>FALSE</REIL> <Touchdown>FALSE</Touchdown> <Strobes>5</Strobes> <LeftVASI>PVASI</LeftVASI> <LeftVASIbiasX>21.04</LeftVASIbiasX> <LeftVASIbiasZ>169.17</LeftVASIbiasZ> <LeftVASIspacing>91.45</LeftVASIspacing> <LeftVASIpitch>5.50</LeftVASIpitch> <RightVASI>NONE</RightVASI> <ThresholdOffset>138</ThresholdOffset> <PatternTakeOff>Left</PatternTakeOff> <PatternLanding>Left</PatternLanding> <PatternAltitude>305</PatternAltitude> </Runway> </ICAO> Similarly the data is all in the Log and in the R4 and R5 CSV files, for example (R5): ENHF,0050,70.677422,23.658688,260,47.980,2887,111.35BD,98,8.000,70.679634,23.668608,135,, ENHF,0230,70.681847,23.678528,260,227.980,2887,110.70BD,98,8.000,70.679634,23.668608,138,, So, it seems you addon ENHF not only deletes the default details, but for some reason fails to add its own in a normally recognisable way. Maybe they are exploiting something in the BGL system which allows them to do unusaul things -- eg are the runways sloped? If they've made them sloped they may not be using actual runway definitions. See if the runways are properly listed and selectable in the World-Go To Airport menu in P3D. When you have the log data, we can see what is going on. Maybe I could examine the AFD file to see what is wrong. Pete

Have you checked that the numbers you get do increase AND decrease by 1 when you turn the knobs? Try with a regular FS control on a normal aircraft. What you are seeing sounds to be more of a specific way the PMDG controls operate. I don't use PMDG aircraft, but I thought their controls are simply versions of their mouse actions, and the parameters are NOT the values to be set, but an encoding more left and right mouse click codes -- in fact i think there's a list of those in the document which lists the custom controls. See how you change those values on screen, with the mouse. That is probably what you have to emulate with the custom controls. i.e. one of two parameters -- up or down (right or left mouse click). If so, what you are trying to do is not specifically possible. All you can do is NOT assign to the control on the left, but use the range facility on the right, use the whole range with "up" encoded with one parameter and "down" as the other. Really? Multiply and Add? Simple arithmetic? I'm not sure how to explain arithmetic, most folks learn that in junior school don't they? What exactly puzzles you? Pete

Using analogue axes to set exact specific values is really not a good idea. But: You could try using the RAW setting, and set the delta to 1. That should give you every input value from 0-255. After doing the assignment, in the FSUIPC INI file, you'll need to find the lines and add "fiddle factors" to scale 0-255 to the range you want. Check the FSUIPC Advanced User's guide, the section entitled Additional parameters to scale input axis values which is on page 45 or close. Pete

No. The "speed" of yoke movement (really "sensitivity" -- it isn't the "speed" of the yoke, but that of the controls movement -- i.e. ailerons and elevator), is controlled solely by your calibration. With FSUIPC you can calibrate to suit your controls and your needs. As well as setting the range of movement there are "slopes" which can make it less or more sensitive in the central area. Calibration, including slopes, operates on the controls in the aircraft, not on the axis itself, and can be used no matter where you assign the joysticks themselves. The assignment in FSUIPC is mainly useful for having different assignments for different aircraft, automatically changing depending on the aircraft being loaded. This is by "Profiles". The calibration facilities also fall into Profiles, so you can have more sensitive controls for stunt planes and fighters, and less sensitive for airliners. "fps" = frames per second, which is only a measure of the sim's performance on your particular PC system. It isn't related to yokes etc. Why have you got a yoke if you want to disable it to fly? What's the point? I think you need to explain your actual need, as what you are asking isn't making sense. Pete

Yes. Can't say any more at present, but I want to retire and actually fly more! not to mention my model railway, long neglected. Pete

Mostly it has to be a matter of experimentation, as it depends a lot of the sort of airports you use, whether there are other airports nearby those, and what traffic add-ons you use. I am always making small adjustments to my settings. You could use a higher limit, surely? 50 doesn't give your traffic programs much scope. The "GroundPreference=90" value means the likelihood of deleting ground traffic -- maybe the very ones you are wanting to see, is 90% -- i.e. 9 out of 10.. Also note that the "PlannedAirportsPreference=20" value is only used if you have loaded a plan, so that FSUIPC can determine these airports. Pete

Your long post seems centered on sceneries, which of course I do not make. I am just a scenery user, If you mean FSUIPC installation, then currently it is very VERY simple. An entry in the DLL.XML (only necessary to get it loaded) -- otherwise I interfere with absolutely nothing else in the user's installation. To my mind the least files in the least number of places I change the better. It is just that one, which is forced upon me in any case (unlike in FS2004 and before). As far as the scenery layering is concerned, with tools like AddOnOrganizer I am not worried. I can cope, and in fact most of my recent scenery updates or additions have used the new method, either because that's the way they operated, or because, as with UK2000, I had an easy choice. If you are referring to my not updating MakeRunways to the new system, that comes about f two main reasons. One is that I can't get my head around how the priority layering is now working -- there's just too may files involved with possibly conflicting leyering declaration. There appear to be conflicts or ambiguities I wouldn't know how to resolve. And, second, AddOnorganizer sorts it out for me with no extra effort on my part other than calling it with a command line option. Really super! Okay? Or have I missed a point somewhere? Sorry, I don't understand the question. Pete

Yes, but which VERSION of FSUIPC4? If not 4.974 you need to update! Generally, the way to move on from your problem is to 1. Reinstall FSUIPC4 with the latest installer, and 2. Keep retrying. Windows is remembering some problem you've had previously. Normally a reinstall with solve that. The previous prtoblem which causes this is not necessarily anything to do with FSUIPC, but a crash due to some other addon or corrupted file. Once you are using the latest version, and you still have a problem, I need to see the FSUIPC4.LOG file from the FS Modules folder, if there is noe, and the Windows crash data from the Windows Event Viewer, pertaining to FSX.EXE Pete

Aha! I see: 20=P4,20,CL2:D,0 -{LuaDebug ahCallFC}- 21=P4,4,CL4:D,0 -{LuaDebug ahZoomIn}- 22=P4,18,CL7:D,1 -{LuaDebug ahFC_ControlV4PD}- You are starting your Lua files with "LuaDebug" instead of plain "Lua ...". As described in the Lua Plug-Ins document. That then preloads "ipcDebug.lua" which, if loaded, does a number of debugging things, pretty much all of which are now superseded by the "Debug/Trace Lua plug-ins" option in the FSUIPC Options tab (see your pic above). That option preloads a ready-compiled version of the debugging Lua. Please use the Logging options facility instead of LuaDebug unless you really want to experiment with the Lua debugging in ipcDebug.lua. FSUIPC is defaulting to its internal one because it can't find ipcdebug.lua. Pete

No, I understood you! The ipcDebug.lua is used when you enable specific options for logging. It isn't used by the main "Trace Lua" logging option. That is why I asked you how you were enabling the trace debug logs you keep sending me. FSUIPC cannot open it BECAUSE it isn't in your Modules folder! Of course! Something in your setup, or what you are running, is enabling the Lua ipcDebugging option. I'd need to see your INI file and for you to list what you are running to know what. And why is it worrying you so? Haven't you finished debugging your Lua now? Pete

It is supplied in the FSUIPC Documents folder (in the Lua examples ZIP) but it isn't needed. Which logging option are you selecting? The simple Trace option for Lua doesn't need that file anyway. -- it used to and there is still an option to use it.

Yes. But I updated FSUIPC4 for you. You are asking about old posts. Pete

Sorry, I missed out the question mark. I was asking YOU which didn;t work! i.e."Which doesn't work, maximising the Window or send the key press?" But it doesn't matter now. I ploughed on regardless of an answer. Pete

Please try 4.974b now in the Download Links subforum. I found 4.974a worked sometimes, not others. The 'b' version is more consistent. Pete

No, mine are also Win 7-64 PRO, and it works fine 100% Which doesn't work, maximising the Window or send the key press. The Lua logging doesn't tell me that. I attach my working copy of your Lua. Not that the path to FS-flightControl is different, so you'll need to change that back to test. Please turn off Lua tracing log options. it doesn't show anything useful now. Pete ahFC_ControlV4.lua [LATER] I only just see you are usig FSUIPC4, not FSUIPC5. I'll need to install FSX-SE again to test that. The same changes were made to FSUIPC4 and FSUIPC5, and the FSUIPC5 changes work fine. I wonder if there's a 64-32 bit difference? I hope not. I'll check again tomorrow.

Better to use the logging in FSUIPC Options instead. Don't fret about offsets so much in looking at the hardware side as the PMDG code may be doing something with the internal values. When you get the problem happening, enable Axis logging, operate the throttle(s) again, briefly, bringing them right back, then dissable the axis logging (so the log doesn't get too big) and look at the Log file in the sim's modules folder. See what the actual axis value was at idle. You could also check the actual joystick input more directly by going into FSUIPC's Axes tab and seeing the IN value changing. From what you say it does seem like more of a PMDG question, so also try posting in their support forum. Maybe others have seen this and solved it. Pete

The updates are completed and available in the Download Links subfolder. Look for WideClient 7.141 FSUIPC 4.974a FSUIPC 5.124a as appropriate to your needs. Pete

Version 7.141 of WideClient is now released. Please use that. Let me know if there are stil problems. Pete

Version 7.141 of WideClient is now released. Please use that. Let me know if there are stil problems. Pete