Pete Dowson

You are right! It IS wrong, and has been wrong for, well, for all of FSUIPC's 9 year life, or at least since I added Slopes which was many years ago! The bitmaps for the display are generated okay, as are the look-up tables for the conversion of IN values to the OUT values, but the indexing of the one is done differently to the indexing to the other -- the negative values are indexing backwards! Huh, shows how many folks don't use that area! ;-) This is a very good catch. I'm fixing it now. It will mean, unfortunately, that anyone who is already using the -ve slopes will have to re-select the 'correct' one now. If you want to test the interim version with this fixed, please email me at petedowson@btconnect.com. Thanks & Regards Pete

No. Offsets are mainly for VALUES rather than ACTIONS. For most all actions you use CONTROLS. Those keypresses will be translated inside FS into FS controls, then re-sent to itself and obeyed. Keypresses can be re-assigned, so they aren't generally a useful way to refer to things. Find out what controls they are. With FSUIPC (registered or not) this is easy to do -- just enable Event logging (in the Logging tab), operate the keypresses and view the Log file to see what controls it used. You'll find both a control number and a name. Alternatively use the list of FSX controls installed for you in the FSX Modules folder. It lists names and numbers, in order of both. You can send any FS controls (and almost all FSUIPC-added controls) via offset 3110. You only need those numbers. Regards Pete

Are you sure it accepts positional data in NMEA form, replacing its own antenna input? Most Garmins I know of don't, except the Aviation ones, and they need "Aviation 400" format (also supported by the GPSout facility). USB ports look like serial ports but have strange names, not COMn. Please refer to the GPSout notes in the documentation. In order for any program other than your Garmin Synch program to actually get to that port, however, you will probably have to terminate it, otherwise it will grab the port exclusively. Pete

Ah, so it isn't the graphics you are saying show anything wrong, but only the results? I didn't understand that from your original post. The actual look-up tables for the slopes are generated once, when the program first loads, then used by the index. Maybe the indexing for the -ve numbers is wrong. I'll check it out here. If it is wrong it has been wrong for about 8 years. I suspect no one before you has ever wanted to make the response more severe than default. Most folks want more precision, for delicate adjustments and precise flying, near the centre, so the usual curves are those with flattened centres. One more question before I go checking this myself. You DO have the null zone, in FS, set to minimum, don't you? Otherwise the middle part of the curve, the bit you are talking about, isn't really having any effect in any case, and it's the shape of the tops and tails which you are experiencing. That will be quite misleading. For all FSUIPC calibrating operations, if you are assigning in FS, you need minimum dead zone and maximum sensitivity, else it is mostly a waste of time. ;-) Regards Pete

You cannot, unless you delete your FSUIPC registration (the FSUIPC.KEY file, in the FS Modules folder). The point of the name and email address (or any address, really) is to identify YOU, uniquely. Both WideFS and FSUIPC, used on the same installation of FS, need to be registered to the same person, and different names or addresses defeat this objective. It does explain this in the FSUIPC documentation. If you have purchased WideFS using a different email address to the one used to purchase FSUIPC then you should raise this as a problem with SimMarket (a "problem ticket", and they will issue you with a new key for one or the other. You may then need to delete the FSUIPC.KEY file and register both. Regards Pete

Not an option, no. FSUIPC uses the same control as you are using, so it can't do more. I suspect that it is restricted because of the projection problems this would give. There's a lot of distortion already at 0.31. Maybe the computations or approximations MS use in working out the views break down at some point, so they restrict it specifically to avoid this? Regards Pete

If you want to send view commands, why not send view commands? Why send keystrokes? Oh dear. What has WideFS got to do with it? If you are writing a program to interface to FSUIPC, it will interface to FSUIPC if you run it on the FS PC. If you want an FSUIPC interface on a Network you need to buy and register WideFS in any case -- that is absolutely nothing to do with programming, but is required to use WideFS in the first place! You need to know how to program a Windows program. Then look up the Windows message WM_KEYDOWN and WM_KEYUP in the normal Windows programming references, where all these things are explained. Sending keystrokes via FSUIPC is must easier if you use the FSUIPC controls supplied for the purpose. See the Advanced Users guide. You can all FS controls, and almost all FSUIPC controls, via offset 3110. For most purposes, FS supplies controls to do what you want. Keystrokes get translated inside FS into FS controls in any case, so why not use the controls in the first place? Also users can re-assign keystrokes, so you may not get the result you expect, whereas FS controls are designed to control FS (oddly enough! ;-) ). Pete

Actually, there's no similarities, but it is indeed quite possible that this Ariane gauge, or some other component of the aircraft you are using, has a bug which is resulting in memory being corrupted. the end results of that will vary enormously depending on the particular configuration you are running at the time. When checking for an error in a particular program it is best to narrow it down by only using defaults first. If ASA + FSUIPC doesn't cause any problem with a default aircraft loaded, but does with that Ariane one, then it is more likely to be a problem with the aircraft than either ASA or FSUIPC. No, this log shows you were using ... no sign of any different aircraft being loaded. Give up on add-on aircraft for a few tests, use only defaults. I cannot believe, at present, that this is anything to do with either ASA or FSUIPC. If you supply any more data for FSUIPC please be sure to use the latest increment as I requested, not 3.85. Regards Pete

Why are numbers bothering you? Use the slider on the right and view the fraphic, not the number! Slide it up and down. At 15 (with the slider at minimum, lowest position) you have the FLATTEST centre response. i.e very slow centre response. As you slide up the curve flattens, at 0 is it straight -- a 45% slope from one corner to the other, a perfectly linear response. The negative values then make the centre stepper and steeper, nearer vertical as it gets to the top of the slider at -15. At that setting the central response is to fast and the response at the extremes slow. The -ve values are almost the exact inverse of the +ve values. for a control with no centre, like the single throttle, only the upper half of the S-curve is used, but the principle is the same -- the steepness is at the low end, from idle. Please, try to understand it by the shape of the curve rather than by a nominal and otherwise meaningless reference number! Pete

For FS9, runway surface type is available in offset 31E8, and condition (normal, wet, icy, snow) in offset 31EC. The former should also be working in FSX (but isn't tested), but the latter definitely doesn't work. Check Thomas Richter's work on his "Autobrake" program. http://www.technical-service-richter.com/ Regards Pete

Hi Bill, Okay, almost there. I've just about completed an update to FSUIPC4 to implement "control profiles", for Keys, Buttons, Axes and Calibrations. It will be carried back to FSUIPC3 as well, after some more testing. I tend to implement new stuff on FSUIPC4 first as the code, being much more recent, is cleaner and I can see how to implement it tidily there. Only when it works in FSUIPC4 do I apply the same (sort of) changes back on FSUIPC3 (which of course is code grown up from the original FSUIPC1, dating back over nine years now! Are you using FSX + FSUIPC4? If so I could supply you with an interim update to help my testing, probably on Monday. If you are only on FS9 I'll try to transpose the code but it would probably be later in the week. Let me know, please. Regards Pete

Okay. I think I understand all that. I hope you succeed. The pictures are looking good, I agree. Regards Pete

I've now installed ASA on my FS9 test PC and have had it running on a flight for some time without any problems. This is with FSUIPC 3.858. I have no FSUIPC options selected in Winds, Visibility or Clouds, and I've not touched any options in ASA. Maybe it needs some combination of options in one or the other of FSUIPC and ASA, so I am desperately in need of more information from you -- all of the options (your FSUIPC.INI file would help -- just the [General] section) and a note of anything you've changed in ASA. I'm sure HiFi Simulations would have tested ASA with FSUIPC and FS9 quite thoroughly before the released it, so it is going to take some help from you to narrow this down and determine the cause. Regards Pete

You too? Sorry to read that. My impairment is Retinitis Pigmentosa (RP), but it is the type which progressively kills all my peripheral vision but leaves me my central detail (severe tunnel vision), so I can still work on a computer and read books, but fall over things, bang my head all the time, and can't go anywhere without crashing into people and shop displays! No driving of course, nor real flying. But i suppose that's reveals the "good" side -- it was because I couldn't get my medical certificate for flying (it was on that test I discovered my impediment, which wasn't so bad back then) that I got so deeply involved in simulation instead. ;-) Regards Pete

What says FS doesn't use it? Of course it "uses" it. It is an essential part of all aircraft and always has been fully supported in FS for as long as I can remember! Regards Pete

That's okay. You quoted the version number, -- the leading 4 denotes it as FSUIPC4. Are you able to post to Captain Sim support to ask / suggest that they contact me with more details so this can be resolved? I don't like having third party problems being blamed on my software and will be glad to help them resolve it. It won't get resolved by burying heads in sand! Regards Pete

That's the "Kollsman window", named after the German company that first started making altimeters with the viewable QNH adjustment window. Microsoft misspelled this as "Kohlsman" in their control names. If you download the FSUIPC SDK, which is what you need if you are playing with offsets, you'll find a "Programmers Guide" (or for FSX an "Offsets Status") document, which lists all of the offsets set by FSUIPC. A search for "altimeter pressure" in that would have immediately found it at offset 0330. Please do use the documentation supplied. It would be rather quicker than making fancy pictures! ;-) Regards Pete

Not exactly random if they always have the same details! ;-) Registration shouldn't have anything to do with it. This is the first report of any such problem, so I'd need details. 1. Is this only with ASA running? 2. How long does it take, after starting ASA, before a crash, typically? 3. Do you have any weather options set in FSUIPC? Maybe there's some sort of conflict with something ASA is doing? Try temporarily removing your FSUIPC.KEY file from the FS Modules folder, so that it runs unregistered and so with no weather options active. Let me know. Finally, could you try it with the current interim Beta version, 3.858, available in the "Other Downloads" announcement above, and let me know. Please include the same sort of details, which might change a little. Regards Pete

There should not be any difference, and if these is it most certainly needs fixing, not running away from. No one from "Captain Sim" has ever asked me about this, and unless I get enough details to enable me to fix it, it won't get fixed. Obviously. :shock: Surely this add-on aircraft doesn't use FSUIPC? If it does no one has asked me for a license. :twisted: Pete

I experimented with execute_calculator_code() but couldn't get it to return anything recognisable for any of the variables I tried. I was particularly interested in getting the aircraft's LLAPBH that way so that synchronisation with other things could be made more precise. In that case the method I thought of (well, I woke up this morning with the solution in my head) will be fine. Regards Pete

Further to this, I've thought of a nice easy and neat way to do spoofing of any offset or group of offsets for FSUIPC4 / ESPIPC, and could implement this for you very quickly if you need it. And it would work for WideFS and other direct-accessing programs too. But it will not work for FSUIPC3 and, to be honest, I cannot see a way of doing it in FSUIPC3 which I would at all be happy about. If you want to proceed, please write to me at petedowson@btconnect.com and I'll explain the details and soon provide a Beta version for you to test with. Regards Pete

You could assign keypresses to the FS "FLAPS SET" control, with the parameter set correctly to get you to the right flap setting. Note that these are not in degrees, though, but in the proportion to 16384 of the flap detente position (i.e. 0 flaps up, 16383 full flaps, 8192 the 'centre' detente if there is one) . So "Flaps 10" would have a different parameter value depending on the particular aircraft. With FSUIPC you can change the key assignments automatically according to the aircraft loaded ("aircraft specific" assignment), so it can still be done. You'd need to work out the parameters, or use trial and error, for each aircraft. Regards Pete

Ouch. What a horrible thought! So nothing would ever be able to read the real values, at least whilst you were doing something somewhere? Well, it certainly isn't possible at present with FSUIPC alone. Of course, if your program were running in-process in FS, as a DLL or Gauge, it could subclass the FS98MAIN and UIPCMAIN windows (either or both might be used by clients), and alter data in the memory-mapped area on its way back to clients. That's messy but certainly possible and would give complete control to the program doing it -- but it wouldn't work for WideFS clients of course as WideServer gets its stuff directly. To actually provide a general facility, controlled via offsets, for this wouldn't really be on, simply because those offsets would be included in the general class of things to be spoofed. On the other hand, maybe a limited set -- say a defined subset or range -- might be reasonably feasible. Or maybe a specified list of pre-defined definitely limited size. Would you care to expand on your idea more fully, bearing this in mind? And can you limit it to, say, FSX and ESP rather than have to go back to FS9 and so on? It is far more difficult with the way the memory for offsets is re-mapped in FSUIPC3. In FSUIPC4 it is made a lot easier by the way things are implemented internally. It is still problematic for WideServer, even though it is built in, and my other direct-loaded drivers (PFCFSX, EPICINFO, GA28R) because of the direct access techniques they employ, but even there it is infinitely easier on FSUIPC4 than FSUIPC3. What's meant by "A vars" BTW? Is that an XML gauge term? Regards, Pete

No. Not at present. What is the purpose? Regards Pete

I expect he's using "slew" mode, which has no sound. I thought that was an optional way of operating. I've really not been near WidevieW for a long time. Best to use Teamspeak on the client in any case. FS sound routing is possible with a 5.1 or better sound system -- at least on FSX -- as the sound is located correctly for such effects. I use pmSounds from Project Magenta for in-cockpit sounds, and Radar Contact on the same client PC. Regards Pete