Pete Dowson

That crash is actually occurring in the GoFlight driver, GFDEV.DLL, but, oddly, during initialisation when it suddenly gets disconnected by the Server, so maybe it's some timing glitch there. The reason for the crash appears to be that the GFDEV.DLL driver was unloaded. at least according to the Modules list, which should be complete. I wonder why is it being disconnected so soon (300 mSecs) after connection was confirmed. Very odd. How does this compare with the log on the other PC, or with the log when you don't get the crash? 246451 Connection made okay! 246763 Connection closed by server! 246794 ***ERROR C0000005 at 70B57D42 Main WM_MYTIMER(0x00000000, 0x00000000, 0x00000000) Interestingly it does appear to continue and succeed in loading and using GFDEV AFTER the crash, whilst presumably the error message box was on screen waiting for your confirmation to terminate: 246965 Attempting to connect now 246965 Connection made okay! 247075 Using "C:\Modules\WIDECLIENT\GFDEV.DLL", version 2.2.4.3 247075 GoFlight GFP8 detected: 1 device 247075 GoFlight GFT8 detected: 1 device 247075 GoFlight GFRP48 detected: 1 device I'm not sure what to advise. Maybe try a different version of GFDEV.DLL, such as the one in the Download Links subforum? Maybe the error message box should offer an option to ignore the error and continue. That usually wouldn't work, but the way this has gone it may well work. I've not seen one like that before! Pete

FSUIPC really doesn't care when a device is closed, disconnected, reconnected or whatever, provided the serial port diesn't change. It would be up to the way it is handled. Have you asked the Linda folks? Better still, why not ask VRI support to help fix the device so it doesn't hang? Pete

Ah, you mean the synch positions in Calibration, where you can have many calibration points to make throttles match better? When you press OK to exit the options dialogue, all those synch positions are recorded in the [JoystickCalibration] section of the FSUIPC4.INI file. They cannot get lost, and are read during initialisation, when entering the Calibration dialogue again, and when changing aircraft -- the last matters if they are specific to one aircraft or one profile. If you think they are not being restored on restarting FSX, then maybe you made the synch positions when in a Profile or Aircraft Specific setting which is different from the one you then used on reloading? Certainly there is no difference to FSUIPC (or FSX) whether FSX is restarted or the computer is restarted. There's no way it can detect any difference in any case. If you want me to look at the INI and tell you what you've done, please just paste its contents into a message here. You'll find it in the FS Modules folder. Pete

Sorry, what do you mean by "I syncroized my two levers"? Nothing in FSUIPC changes, but the hotkey for throttle synch is only active whilst it is active, not forever. If you mean you set a number of synch points in the calibration, then these are all recorded in the INI file and never lost. Pete

And so it must be FSUIPC? Is that what you are saying? Pete

Hmm. Sounds suspiciously like they DO use it then. Who keeps it up to date for new scenery add-ons? Can you please point out what you think is wrong? Do you just mean this entry: *** Runway *** ZGNN0050 Lat 22.606976 Long 108.173378 Alt 420 Hdg 46 Len 8871 Wid 0 ILS 110.90, Flags: GS DME BC I'll look at the BGL data for that one, which I suspect is wrong or at least non-standard.You said "two examples". Where is the other? Note that the runway width field is the same data field for all relevant enties in the log. BTW I just ran the latest MakeRunways and these are the entries I get for those two default airports: *** Runway *** ZGHA0180 Lat 28.198427 Long 113.220970 Alt 217 Hdg 180 Len 8553 Wid 148 ILS 110.30, Flags: GS BC *** Runway *** ZGHA0360 Lat 28.174997 Long 113.222359 Alt 217 Hdg 360 Len 8553 Wid 148 ILS 109.90, Flags: GS BC and *** Runway *** ZGNN0050 Lat 22.606976 Long 108.173378 Alt 420 Hdg 46 Len 8871 Wid 148 ILS 110.90, Flags: GS DME BC *** Runway *** ZGNN0230 Lat 22.623917 Long 108.192299 Alt 420 Hdg 226 Len 8871 Wid 148 So, it isn't reproducible here, sadly. I can only conclude that either you are using an old version of MakeRunways (though I don't recall any error which could do this), or there's something corrupting data someplace. Maybe hardware memory or disk file problems or similar? Pete

Yes. This was always the original way. Assignments in FSUIPC came later, to enable different assignments for different aircraft types. Just go to the Joystick calibration tab and do it! (As documented). Pete

Thanks Al. I've posted this in the FAQ subforum for future reference. Pete

This is from a typical post I receive in the Support forum, complaining about one or more of the axes on Saitek throttle quadrants: "... looking into fsuipc, i noticed, that the max value 16383 was reached on the most right lever way before it should have." This appears to be a common Saitek problem, and I think it is usually easily dealt with by some registry editing Thanks to a contribution by Al ("Ark1320") I can now provide more explicit help. The details which used to be found here on the Saitek website are shown below: Hope this helps, and thanks Al. Pete ------------------------------------------------------------------------------------

I'll put it on my list. Pete

Well, evidently it can be done, as FSPS's fiber accelerator does it, but I don't know how to do it at present, and don't really want to find out for my own use in FSUIPC because FSPS deserves fair reward for their efforts. Pete

Ah, you mean the Stab Trim cut-out / override switches. Stab trim is the actual elevator trim operated by the wheels or the buttons on the yoke. Those aren't supported by FS itself, but they should be supported by the PMDG 737NGX, probably with extra control numbers. You'd need to find the correct control numbers in the 737NGX SDK document (the one of filetype .h) and assign in FSUIPC using the <custom control> assignment, which allows you to enter non-FS control numbers. Pete

The Ask facility just uses the default call which gives red. The only other choice would be white. I could add an option for white -- is that what you want? But first have you tried using the Miscellaneous tab option for "all non-scrolling messages to be white"? That should change the default, if I remember correctly. If you want to hack into FS code, be my guest. It's just a flag value in one of the parameters in the call used into the Window.dll procedure at exported ordinal 24 (in FSX), the one named "?show_message" in P3D 2.5. The parameters are: ShowMessage(pointer_to_string_to_display, display_options, display_time, 0) where the only useful "display_options" I found are: 4 white, 5 red, 6 scroll. This dates back many years. I've never had the urge to delve further. Pete

I notice it is only blurred on some images. Strange. Seems to be a conflict between the original resolution and the compression used by the PDF creation operation. I've changed the parameters it uses for that so on next release it will be fine, at the cost of a slight increase in size of the files. Pete

No, you misunderstand! Read the documentation again! FSUIPC does NOT "manage the battery state". There is no facility for switching it on or off except by assignment to switch or keypress. The battery life extension facility is merely a VOLTAGE manager -- if the voltage is at X (>0) it ether maintains it as X or lets it drop slowly, slower than FS's consumption would allow for, according to the number set in the dialogue. If the battery is off, so the voltage is 0, then it stays at 0. YOU have to switch the battery on. Switch the battery off and save the flight so that it is off when you reload. Or edit your flight files to do the same. Pete

The"custom commands" -- i.e. FSUIPC-added controls -- are all listed in the Advanced User's guide, under the heading Additional "FS" controls added by FSUIPC4.. It is actually listed in the contents list, the first page! Pete

This appears to be a Support question, so please post in the Support Forum, NOT in the FAQ subforum, where it won't get answers! I have moved it for you. Are you using the GoFlight software? If so you need to go to their support. If you are only assigning in FSUIPC, then there is no way it ever forgets your assignments, they are all stored in the FSUIPC4.INI file in the FS Modules folder. Maybe you've made them aircraft or profile specific and are loading different aircraft in which you do not have them assigned? Pete

[MOVED FROM FAQ subforum to the proper Support Forum] The PMDG aircraft are notoriously difficult to interface to a full blown cockpit, as they implement all of the systems internally. The NGX does have an SDK, but it will onvolve a lot of work with programming and so on. I would strongly recommend looking at a proper cockpit software package such as Prosim737 which is much easier for cockpit installations and probably already supports directly some of your hardware. No! 69961 is NOT an "offset". Offsets range from 0 to 65535, but are normally expressed in hexadecimal (x0000 to xFFFF). 69961 is probably an FS control, but even then it is over the end of the range FSX and P3D use internally, so it is probably one of the extension controls used only by PMDG. The encoding x01001149 is the FSUIPC encoding for the "Offset byte set" control, setting the parameter value you provide into offset x1149. The coding x0001149 certainly wrong and does not represent a valid FSUIPC-added control, so its results will be unpredictable. Please try to avoid editing the INI file yourself without first studying the FSUIPC documentation -- in partculr, for control encoding, the Advanced Users manual. But you should very rarely have to in any case! That's okay, with event logging enabled, but that is not where you saw the Offset byte set control! That is the erroneous result of your assignment to an FSUIPC offset control with an incorrect value. You should delete whatever you've done there as the results will be unpredictable and could easily crash the simulator. Offsets are relative addresses to a data area inside FSUIPC's memory, which can be read to obtain data and written to change it. Controls are requests to FS (or add-ons) to do something. You are mixing the two up, quite thoroughly I'm afraid. Pete

There's no way anything in FSUIPC itself can possibly do anything like that. You will need to go through a process of elimination to see which add-on you are running which is doing it. It may be using FSUIPC to do it, or it may be direct. But first I would most certainly look for an assigned trim axis which you may not realise is assigned. Try using FSUIPC's axis logging and see whether the problem is being caused by trim axis inputs. If you you need to look to see where that is happening. It could be assigned in FSUIPC or in FSX, maybe an axis you no longer have connected. In case it is random trim up/down signals, you could also enable event logging to see if those are being sent. If so that could be a button or key assignment with unwanted inputs occurring. If you don't understand the log output, paste the contents here (keep the test as short as possible). You could also paste your FSUIPC4.INI file here so I can check your assignments. But also check FSX assignments. If you are assigning in FSUIPC be sure to disable controllers completely in FSX. Pete

Assuming you have calibrated in FSUIPC properly (following the numbered steps in the user guide), the only other usual reason with the Saitek device is that the registry wrongly defines that axis causing Windows to change the values provided. There are lots of posts about that here, as it is a common Saitek problem, and I think it is dealt with by some registry editing documented somewhere on the Saitek support forum. I'm afraid those that have been there and found it have not bothered to come here and state what the answer is, but if FSUIPC does not see the ninput numbers change it cannot do anything about it. Pete

TRANSLATION: I understand what you say. What I mean is: the King Air C90B panel there is a "ingnition ENG AUTO" switch is not in the menu assignable buttons fsuipc Because there is no assignable FS control, as I said. Is the C90B an add-on aircraft? All I can find is the 350, and that has no "Ignition ENG AUTO". the Left and Right ignition switches are assignable there, as Toggle starter1 and Toggle starter 2. If "Ignition ENG Auto" is simply an implementation of the FSX autostarter facilities (Ctrl+E), then the FSUIPC assignment would be to Engine auto start. That applies to all aircraft. You can give it a parameter to say which engine (1 or 2). But add-on aircraft often do their own things, independently of FSX facilities. You probably need to consult their documents to see how to use them. Are there keyboard shortcuts you can assign, for example. Or maybe they will respond to mouse macro operations, or local variables (L:Vars) as I already suggested. I cannot really help with addon aircraft, you have to find out yourself as others do (see User Contrbutions subforum, for other examples). There's no way I'm able to purchase, install, test and document all add-ons! Sorry. Pete

TRANSLATION: But there are instruments king air that I find neither in the FS2004 default menu or menu buttons fsuipc. You can not add more options to fsuipc buttons? What instruments? The FSUIPC assignments include ALL of the possible default FS controls, plus extras for special functions added by FSUIPC. If there are functions in the default King Air that cannot be used without a mouse (i.e. no keyboard shortcuts either), then they either cannot be controlled from hardware, or you must try Mouse Macros or L:Var (local panel variables) to control them. But without you being specific I cannot help further. Your first example, Master Battery, is most certainly a standard FS assignable control! Pete

Nice! Well done! Pete

I replied to your Spanish original already. Okay? Pete

The FSUIPC interface for applications has always allowed you to read any offset in the range 0000 to FFFF. It cannot stop you. But if there's no data there the result will be zero. What are you trying to read in that large area? Have you tried checking it with FSInterrogate? For FSUIPCclient.dll questions you'd need to post in Paul Henty's Subforum for that. Pete