Pete Dowson

Please find your "Caps Lock" key and turn it off. FS plans are simple text files. You can read the plan and find the information you want quite easily. For example, in this short plan: [flightplan] AppVersion=9.1.40901 title=EGCC to EGCK description=EGCC, EGCK type=IFR routetype=3 cruising_altitude=6000 departure_id=EGCC, N053° 21' 54.0756", W002° 17' 05.1699", +000256.99 departure_position=GATE 241 destination_id=EGCK, N053° 05' 59.7127", W004° 20' 32.3401", +000000.99 departure_name=Manchester destination_name=Caernarfon waypoint.0=, EGCC, , EGCC, A, N053° 21' 54.0756", W002° 17' 05.1699", +000256.99, waypoint.1=EG, WAL, , WAL, V, N053° 23' 30.9855", W003° 08' 04.0008", +000000.00, waypoint.2=, EGCK, , EGCK, A, N053° 05' 59.7127", W004° 20' 32.3401", +000000.99, you can readily see that the departure ID is given as the first field in the line "departure_id" and the destination ID is given as the first field in the line "destination_id". Pete

Attached. I don't think it's from Garmin. It appears to be only part of a larger document, but it was sent to me just like this. Sorry, I don't recall who by, it was many years ago. Regards, Pete Aviation GPS Format.zip

Problem? VSI too smooth? I think the VSI measures the vertical speed. To change what it measures needs a different instrument I think. If you actually want to change the VS so the VSI reads differently, then you must get the aircraft to rise or sink faster. Try writing values to the Y velocities or accelerations. FSUIPC does provide a facility to do this via the vertical wind component. It is used to simulate updraughts for gliding and so on. See offset 3478. You can use positive and negative values to make the aircraft rise and fall, so changing the VS. I think you misunderstand how simulation works. The current VS isn't "stored" but is computed based on the rate of change in altitude as the aircraft ascends or descends. All those values are computed, and therefore owerwitten, each simulation frame -- they are EFFECTS rather than CAUSES. Regards, Pete

If FSUIPC can see the buttons and you've assigned them, then when you press them they most certainly should be sending the keys or controls to FS. What are you actually assigning? You can enable Button logging in the Logging page of FSUIPC, test the buttons, then look in the Log file to see what happened. Show me that if you like. I don't know what a coolie hat is in terms of what FS/FSUIPC sees, but if it's a point of view control then FSUIPC should see it as 4 or 8 separate buttons (numbered 32-39). You should be able to program each separately. There's no generic POV programming in FSUIPC. Regards, Pete

Not that I know of. apart from the documented white test option -- if you can find any way of changing any of FS's own window fonts and colours, please let me know. As it says in the documentation, that new Window is produced by FS, not by FSUIPC. All I do is call the FS routines which display it. The AdvDisplay windows was a separate Windows Window, nothing to do with FS, which was why I could do as I liked with it and also why it was so problematic. The same goes for the Window produced by ShowText. Pete

I hope Pelle is monitoring, as this is squarely in his area. I do recall that FSInterrogate (1st version) had an "export" facility to assist in this, but I don't know about the new one. Sorry. If Pelle doesn't intercede you could try to reach him via the links in his programs. Regards, Pete

Perform calibration in the Sim, following the simple step-by-step instructions in the FSUIPC user documentation. Do NOT do it by editing the INI file! The INI file only keeps a record so that your calibrations are restored next time you reload FS, it is not meant to be the place to "calibrate". It cannot be done there. The values shown in your INI are still so "precise" as to indicate you really have not gone through any of the process documewnted on any axis. Why are you wanting to even consider using FSUIPC for this unless you actually make use of the calibration facilities? I don't understand. Regards, Pete

That is exactly the symptom you get with a bad user Key. Please ZIP up your FSUIPC.KEY file and send it to me at petedowson@btconnect.com for checking. Unfortuately your extract is cut short of anything informative. The "module identified" message always appears if the DLL is installed. The log extract shows nothing useful at all. Please do NOT perform your own extracts. Show it all, including FS being closed, otherwise there's nothing conclusive in any way. Regards Pete

Ah, right -- and FS uses DirectInput, which as a rule sees more than my metyhod does! Good luck! Pete

As documented in FS's own help, the mixture lean/rich operates the jet fuel switches. Pete

Sorry, but the current version is 3.65. Please try that first. Does FS recognise things? Are you using FSUIPC's Axes assignments, or do you simply mean the FSUIPC calibrations? The latter depend upon FS. Unplugging and replugging USB devices can cause problems with FS, I know. Why not leave them both connected? Do you only have one USB socket? Pete

Thanks! Pete

Very few companies do support by 'phone these days. You need to report it by email or via their Support website/forum. Pete

Hi Jose, thanks for chipping in here. For "IWillBeBack" I have a Key (5K36 1SAB YXPU) on record, issued on 4th October 2003. But it needs Version Info with "IWillBeBack" as the product name and "Jose Oliveira" as the Company name. The Log shown here doesn't show either of these! I assume, then, that either there has been more than one version, and the one folks here are mentioning has no Version Info, or you never got around to using the Key in any case? Best Regards, Pete

Yes, but they shouldn't have been there in the first place. I hope you at least sent details to GoFlight. They need to be aware they are doing things wrongly. You will need to take care, also, that you don't use any other add-ons which access FSUIPC in the same way -- e.g. some of the older gauges knocking around. If two or more programs, internal to FS, try to access FSUIPC using the same external access method they share the memory-mapped file for data exchange and each one's requests and returns will corrupt the other's, leading to odd things occurring. Regards, Pete

Please see my replies in the thread just below, entitled "Please Help, Access to an Unregistered copy of FSUIPC". It sounds like Jose has posted a bad version of the program, but I won't know till someone checks its Version Info. Pete

That's not the problem that the "white-out fix" fixes then -- that problem certainly does not happen in FS2004. You get visibility quoted like that ">20 miles". That's rather unusual. METARs usually give 10SM (10 miles) for anything greater, or 9999 (metres) in metric areas. Possibly some Wx stations with manually measured values give more, but not the automated ones as far as I know. Unfortunately, if the visibility is set at less than about 10.4 miles in FS2004, you get grey skies and a bland look to the underside of clouds. But that's another story. Before FS2004 that used to happen at about 4 miles, which was better. Sorry, I've no idea. I've never seen any incorrect/stuck visibility in FS2004, and no one has ever reported such to me before (and remember, FS2004 has now been in use for nearly 3 years). If you'd limited visibilities in FSUIPC's options, then they wouldn't suddenly clear -- unless, that is, the cloud cover changed too -- FSUIPC provides different limits for Clear, Cloudy and Rain/Snow. You say you are using ActiveSky 6. Have you checked its options? Did you notice what it was telling you about the weather before you landed? If you are flying in an area of dense WX stations, you can get changes more often especially if the different WX reports from near stations are from different times, as they often are it seems. You might wish to direct your questions to the ActiveSky forum -- there are folks with more weather expertise than I there, I assure you! ;-) Regards Pete

Okay. The program "IWillBeBack" was allocated a freeware key back in October 2003. But it needs Version Information which appears to be missing or inaccesible in the copy you have. Right click on the EXE and select "Properties" then "Version". The Product Name field should be "IWillBeBack", and the Company field should be "Jose Oliveira". If there's no Version data, or those fields are wrong, then the program is corrupted or it isn't the version which has been given the Key. Really in either case your only recourse is via the Author. See if there's a later version. There is no way for FSUIPC to grant access without correct Version information. You say you are the only one with this problem, so that means either you are the only one with a bad copy of the program, or all the others are using Registered installs of FSUIPC. Regards, Pete

Load up FS, run the program, get the error, close FS, then get the Log and show it to me here. It isn't that hard. Somewhere in the Log it will identify the program which is trying to access it. Have you any author details for this program? Why are expecting it to have free access to FSUIPC -- does it say it does? You haven't provided any more information in this message from the last. What is that actual program name, for instance? "BeBack.exe"? I cannot help without information. Have you tried asking the author from whom you obtained or purchased this program? Folks really need to support their own programs, I can't know and do everything I'm afraid. Regards Pete

Never heard of "BeBack". Any more details please? Seems it wants to use FSUIPC and doesn't have a license. You can buy a key for FSUIPC yourself if you like. Check the log, though, to be sure which program it is -- as the message does clearly suggest. Regards Pete

Thanks for the information! I may nip over there and take a look myself! ;-) Regards, Pete

What token or ID? The only identification for FSUIPC offsets is the offset, a hexadecimal number. There's a superficial relationship between some of the Gauge token variables and FSUIPC offsets, of course, but FSUIPC's data was defined from original FS98 global data structures, not from the Panels interpretation of them. Furthermore, except in a few cases, FSUIPC gets the stuff direct from the Sim Engine (SIM1.DLL) not via the Panels route, which can be rather precarious as it is only fully viable whilst an aircraft is loaded and ready, not the whole time FS is running. That depends entirely on your programming techniques, really, as the methods are different. But if you can get everything through the panels interface, please do so. I never intended or designed FSUIPC to be used for Gauges -- the latter should be fully supported by FS itself, and that is the correct thing to do. Same. Please write gauges as Microsoft intended. Don't use FSUIPC. Regards, Pete

If it isn't mentioned, I don't know about it. There is this in my document: But as it says I don't know whether it actually does anything. Regards, Pete

Yes, most of the engine parameters are the RESULTS of simulation, not the CAUSES. You don't "cause" things to happen by controlling N1, but by using the throttle, as you've found. The same goes for most things -- there are several causes and many effects. I'm not sure how a decent simulation could be written by allowing all the effects to be arbitrarily set irrespective of inputs -- what happens, for instance, if you set an N1 value far less or far greater than the current fuel burn warrants and, and what then of the other results? Do you expect more or less thrust as a result, with the same fuel flow? You must see the contradictions. There are variables further up -- e.g. 2010 and 2018 for Engine 1 N1 and N2 -- which MAY have an effect, but usually this would only last one frame, i.e. until the sim engine has completed the next computation cycle and written new values. Whether they have an after-effect is doubtful. You might be able to manipulate it more by putting the Sim into zero rate or pause modes, but then you'd have to do everything, including moving the aircraft etc. Regards Pete

This is for one of the default FS GPS gauges, I assume? If so, then I suspect many of the GPS controls Microsoft list aren't actually connected internally. Is there a keyboard command assignable to it in FS itself? If not it is possible that it's still a Mouse-only facility. The controls listed by FSUIPC are taken from a table in FS's CONTROLS.DLL, in an attempt to allow all those assigned by Microsoft to be listed correctly in each FS version, without my having to provide hand-made lists. Unfortunately, in every version of FS so far, the Controls they've listed have always been in excess of those actually supported by code -- I think they miss a cut-off date or something. I suppose you'd need new scenery for that. Sorry, it isn't my subject. You can't just move things about, they are defined in the scenery BGLs. Regards, Pete