Pete Dowson

No, but that's not relevant in any case. The gyro heading is easy in FSX because SimConnect provides it ready-made and FSUIPC4 is completely table-driven around SimConnect's variables. It isn't so easy in FS2004 because it isn't available ready-made in the same way, and each new variable "mapped" from FS2004 and before needs extra code specifically written to compute it. Eryou've got something really set up wrong for FSX if you are getting such poor performance on your PC, a 3.2 gig machine with a Radeon 9800? FSX can be made to run pretty smoothly on such a machine. I know this, I've done it. You should be able get up to 20 fps at airports, certainly rarely if ever single digits. You can't have all those sliders up full -- turn off autogen completely, and turn down Traffic or invest in a faster traffic set like MyTrafficX. There are lots of good hints on getting the most out of FSX, and they are worth following. See the FSX forum. Yes, sorry. Anyway, in FSUIPC 4.086 (or whatever the next interim release will be) I've added the gyro compass value as a 64-bit float in FSX/FSUIPC4, at offset 2B00, so it will be ready for you when you do move on to FSX! ;-) Regards Pete [/img]

That gives the magnetic heading, subject to flying level. Isn't that what you wanted? The only other headings are non-drifting exact simulated values. Is that what you want? Otherwise, for the correct gyro reading you'd have to add the drift value (a separate offset again). The same formula, though. Ah, no. For your accuracy you only need the upper half of the 0580 offset, so it's the same multiplication for both: X0582 U16 * 0.0054932 You can combine the mult/div into one number too, as shown. That's 360/65536. So, it might have been possible to allow + or - as one of the two operations, with the understanding that it would be a strict left-to-right parsing, but ... ... the big problem is having references to two offsets, both of which may change independently, in one statement. The whole (simple) way GFDisplay works is to process statements only when THE offset they depend upon changes. To make this work with two offset references is pretty much a rewrite, maybe introducing local variables to make my data structures reasonably simple. It's all geared to maximum efficiency in processing, I'm afraid, not maximum user flexibility. Anyway, I'm not sure you get anything useful this way. Unless you also added in the drift you aren't getting a proper instrument readout -- or are you making a GPS display? Perhaps you should tell me exactly what it is you are trying to do. For FSX, at least, it would certainly be much easier to provide an offset in FSUIPC4 for it -- SimConnect provides the Gyro reading directly, I just need to map it to an offset, a moment's work really. Regards Pete

Ah, wellI've just added the Tailwheel lock switch to FSUIPC4 (FSX only) in version 4.085, released here tomorrow. It is at offset 29A0. It is waiting for you! ;-) Regards Pete

Thanks again Frank! You are doing a splendid job! Best Regards Pete

I've not tried that --- it may just makes defaults, anyway, but it would be worth a try. Back up the DEVICES CFG files first. Find the section(s) corresponding to your joystick names (as shown in FS assignments dialogues) in one or other of the DEVICES CFG files, and either remove the assignments or make them into ones that don't do anything or don't matter. Sorry, I really don't have any magic solutions. I don't know why you are getting deleted assignments re-made in any case unless every time you boot it sees the joystick as a new connection? WideServer.INI too, and your FSUIPC.KEY file of course. For scenery installation there's SCENERY.CFG. Most if my hardware controls are PFC, so not using FS assignments at all but my PFC driver. The one exception is an Aerosoft (Oz) GA-28R cockpit (a Piper Arrow III) which is driving FS through FSUIPC using an Aerosoft driver. I only have "normal" joysticks, cheap gamepads and the like, for testing. In terms of add-on software, I use all the Project Magenta Boeing package, and pmSystems, pmSounds, pmInstructor, plus Radar Contact, ActiveSky, AISmooth, FSRealTime, MyTrafficX (on FSX), Ultimate Traffic (on FS9), plus most of the best scenery, texture and mesh add-ons for UK and Europe. I use Jeppesen FliteMap to prepare flight plans for the pilot, PM's CDU and Radar Contact, and FliteMap is also used as a Moving Map. On my main sim I fly the PMDG 737-700 or -800, but without any of PMDG's panel stuff -- that's alll replaced by the Project Magenta parts. The 737 cockpit is the ready-made one by PFC (see http://www.flypfc.com) which itself has 6 mini-PCs driving it, under the hood, with four further PCs networked out side the cockpit running FS itself and the assorted external add-on programs. Regards Pete

Hmmm. I've never had that sort of problem, provided the joystick stays connected. Are you using winXP? There used to be problems with USB in Win98. Otherwise all I can think is that you disable the joystick in FS altogether and use only FSUIPC. There's one FS option for that -- diable/enable joystick. You don't need to de-assign things then. Pete

This is a general problem with many functions in FS cockpits. The best way to deal with those for which you only have a toggle is to synchronise to start with. Save a Flight with all the positions known and start your cockpit that way. The offsets do sometimes (in fact many times) provide a better solution, but certainly the tailwheel lock isn't one of those. in fact no one has ever asked for it before, in the 7+ years of FSUIPC. I just checked, and it is actually readable in FSX, so I can implement an offset for it in FSUIPC4 if you wish. Not FSUIPC3 though. Regards Pete

Yes, but please read the notes. You need to remember to write the value for the magneto setting after the engine has started. Generally, the starter switch is spring-loaded, so you just release it when you have a start, and the released position should write the magneto value (generally 3 for both, but dependent upon another switch). The actual values in 0892 etc are based on a typical Cessna type keyswitch which, as rotated, goes through 0-4, with the 4 position being spring-loaded not latched. From buttons or switches you don't need to use the offsets for any of this, there are FS controls. I don't really know what you are talking about there, but there's no "bits" to set or clear here. Those offsets deal in Word values (0-4), not individual bits. FSUIPC has no such thing. There's an FS control for it listed in FSUIPC as it appears in FS's CONTROLS.DLL. I've never tried it, no idea if it works. Never known a location in FS for it. Sorry. There are many things only accessible by FS control. I'm not sure why you are getting obsessed by offsets. Try using the controls as MS intended first. ;-) Regards Pete

Hey, thank you very much! It is really appreciated! ;-) Regards Pete

Well, the PayPal account is still open (petedowson@btconnect.com), but mainly I pay for my hobby with FSUIPC and WideFS sales through SimMarket. Regards Pete

Last chance todaytry 1.222 attached. Pete GFdisplay1222.zip

Please check the revised reply. The unedited one, you replied to, was sent in error. I still want your comments on that. Incidentally, regarding your comment "I fail to see how D02 is the same as D2, I should be getting to decimal places, right?", the problem was that I convert the number after the D to decimal, so I get 2 for D02 (or D002 etc etc). I have to treat leading zeroes as a special case. Another problem I just noticed is that the converted value is stored in an 8-bit value (byte). Since this only has a capcity up to 255, it explains the "overflow" results for your D3nn tests. The only problem I think I have left is the disappearance of the leading digits as the values are shifted left. I just cannot see why that is happening by inspection of the code. :-( Regards Pete

You are replying to an earlier edit of my message, now deleted. Please read the later one. Pete

Well, no versions of GFdisplay would have ever understood Dn (one digit) properly -- it isn't really valid. The - and the X were optional, but the i and f were always necessary. That's why I asked what you thought the Dn values should do. Anyway, I've decided for you. It now needs only 1 2 or 3 digits: 1 digit = i, number of integer digits. f and s assumed zero 2 digits = if, as before, s assumed zero 3 digits = ifs, the whole nine yards. Try 1.221, up replacing the attachment earlier. Regards Pete

Maybe i'm forgetting stuff but ... ... before you had no D parameter at all (meaning what?), now you have D with one digit. Is that supposed to do something too? How do you think that is supposed to fit into the D-Xifs format? I don't understand what you intend it to mean. Just checking, yet, I do have the 100's and units digits mixed up in one place, but I'm not sure fixing that will do anything for you if you only specify one digit. What do you intend "Dn" to convey? Dn00 or D0n0 or D00n?

Hmmm. Wonder how. Reading my doc again it seems like there should be a formating code, like D30 or similar? Maybe I resort to a default. From reading the document I don't think that's possible. Well, I'd be concerned about adding new bugs, as the code is now a couple of years old and doesn't look familiar to me at all. Also, I'm not using any GF display devices at all it isn't possible to test changes here either. Maybe the Dxxxx parameter needs an extra optional value: D-Xifs where s is the number of spaces to be left after the value (i+f+s must of course be less than or equal to the capacity of the display, or one less for signed numbers). If you want to risk new bugs I could try adding code for this, but you'd have to do all the testing. Thanks. I've reproduced the earlier explanation in the Appendix, so if I ever do make a new release it will be okay. Regards Pete

Okay. Not hearing anything from you so far, I've been checking. FSUIPC supplies two separate EGT values: 08BE (a 16-bit value), where it says "Engine 1 EGT, 16384 = 860 C. [Note that for Props this value is not actually correct. You will get the correct value from 3B70. The value here has been derived by FSUIPC to be compatible with FS2004, FS2002 et cetera]" and 3B70 (a 64-bit floating point value), where it says "General engine 1 EGT in degrees Rankine, as a double (FLOAT64). Convert to Fahrenheit by Rankine – 459.67. FS default gauges show Centigrade." Now, contrary to where it says "for Props this value is not actually correct" for the first value, it is, in FSX, actually correct -- the derivation FSUIPC is supposed to do is not actually being executed. :-( I suspect that SimKits are using the 08BE value, the incorrect one, and so, now having the correct one supplied, are displaying it incorrectly, if you see what I mean! ;-) I run some comparisons between the 3B70 and 08BE values on the Cessna in FS2004, and it appears the value for Props in Fs2004 is about 2.96 times the value I am reading in 3B70. It most certainly isn't a value is degrees C scaled so that 16384 represents 860C! None of the values I read in either FS2004 or FSX semed to tie in with the Cessna's own default EGT gauge, which is difficult to read but has tiny divisions with a label saying 25C per div. The third tick (idle) seems to represent about 150C and each subsequent tick seems worth about 100C, as by the 7th or 8th (full throttle) the true EGT is up to 1554R or 1094F which is 590C. Weird. It's a bit daft havng someone like me, who doesn't know an EGT from a XYZ, testing and trying to calibrate this sort of stuff -- this is where SimKits feedback would have been, er, useful ... Anyway, I am fiddling the reading in 08BE to be just as inaccurate/wrong as it was in previous FS versions, so hopefully your gauge will show something approximating the truth (?). This will be in the next increment (probably 4.084 or 4.085) which I will post in the FSX downloads announcement above. When you have tried it, please let me know. Incidentally, the FSX Cessna seems to have slightly higher EGTs than the FS2004 one in any case, espcially when idling (152C rather than 80C). Regards Pete

No one of that name is known to me and I've certainly never had any emails from SimKits or TRC about any problems with EGT. But I was on holiday on the 15th and when I returned found my father had died on the 11th, so a lot of emails had to be processed a lot later. There's a possibility that it got swallowed in the process, even by my spam eater! However, if it was important or they had done any testing you'd think they would have asked again, wouldn't you? I would need to know which offset they are reading so I can check it. First, please make sure you are using the latest version (4.08 or 4.081). Assuming it is still wrong, you could try establishing a known EGT (from the FS panel), then logging IPC reads (FSUIPC logging page) and emailing me the log (ZIP and attach, to petedowson@btconnect.com). Tell me what FS was reading. I'll tell you when I have feedback from those who use it. Unfortunately I cannot possibly test all of the offsets for all types of aircraft, even if I understood them all. As in all previous versions of FS since Fs2000, I am completely dependent upon feedback from those who use them, and I fix any errors as they are discovered. I'm afraid TRC and Simkits, although one of the main users, seem to be generally rather poor at testing and reporting problems, at least from where I sit, and although their use of FSUIPC gives me lots of work, they don't actually pay any license fees (I wouldn't mind so much supporting them if they did! :-(. ) Regards Pete

The broadcasting from the Server isn't working then. You never said whether both your systems are running WinXP. Pete

Okay. Thank you very much! Best Regards Pete

I'm afraid that you aren't reading it fully. In the Server parameters section it says There is no such parameter for Clients. As it says, the AutoShutdown simply tells WideServer to send the shut down notifications to all clients when FS closes, instead of only when you use the Hot Key. It doesn't force any shutdowns, it only sends the message. These notifications only have any effect on Clients (and the FS PC) if you ALLOW them to, using the AllowShutdown parameter. Using that parameter you can decide which ones to shut down and whether to shut the PC down or only the applications. The AllowShutdown parameter can be applied to Server and each Client, as you wish. It is a very flexible system, but you do need to read carefully, please. ;-) Regards Pete

Okay, I've fixed this in the next interim release, probably 4.084 tomorrow, in the FSX downloads above. The values are 0 for 0% and 16384 for 100%. It doesn't look like it has any other settable positions, like the Gear. The problem in the current version was in the scaling internally in FSUIPC4. Oddly it defaults to -16383 for aircraft like the 737-800 (-0.99% before scaling). Guess that's the same as "ain't got one, guv!" ;-) Good catch, that. However, you mean 3590/4/8/C not 3950/4/8/C which are assorted Engine 4 data. For 3590-C a typo in my code caused the section dealing with these (via FS controls) to be skipped! Fixed in 4.084. I need feedback like this to get everything fully working -- it's an almost impossible job testing every possible offset for read and write. I don't even know what they are all supposed to do myself even! ;-) Regards Pete

Sorry, I can only understand English, C and ASM. ;-) Hopefully someone will step in to help here. Regards Pete

It sounds exactly like you have not calibrated the throttle sufficiently well to guarantee you always have zero thrust set when you pull it right back. You will need to allow more "dead" space there. Alternatively, but more problematic, you can tell FSUIPC to let you set reverse thrust even when there is still forward thrust set. Check out the parameter MaxThrottleForReverser=n which goes into the relevant [JoystickCalibrations] section of the FSUIPC INI file. You can set any value there (up to max throttle, 16384) below which your reverser will still operate -- provided FS isn't seeing jittery changes if you have the throttle directly assigned in FS -- and that's another possibility: that your throttle is assigned in FS as well as direct in FSUIPC, and the FS value is interfering with the FSUIPC value. Regards Pete