Pete Dowson

Good. Did you get FSInterrogate working too? Pete

It describes how you get degrees from the value provided. All it means is that the FS way of storing angles is to scale them so the biggest possible angle (360 degrees, or for bank +/- 180) fills the entire capacity of the space available. This gives the best precision in a fixed point number. So, 65536 * 65536 gives the total number of different values you can store in 32 bits (65536 is the number for 16 bits), and FS wants to use all those values to represent 360 degrees. Hence the scaling, for a value occupying n bits:: FS units = degrees * (number of values you can get in n bits) / 360, or degrees = FS units * 360 / (number of values you can get in n bits) You have to perform these calculations in such a way that you don't lose values by overflow or by truncation. The easy way out is to use floating point, but if you only want whole numbers of degrees, or some other approximation, then doing part of the division BEFORE the multiplication would be okay. Is FS running? Is the aircraft banking? If so you've certainly got something wrong there. Are all the values zero? Maybe you are not using the version in a recent SDK and haven't registered FSUIPC? Check the FSUIPC log. If you get used to using FSInterrogate to check your programming you will find it much faster and come to understand a lot more, more quickly. That's why it is provided. Regards, Pete

Sounds like you have an error then. Please check out FSInterrogate in the SDK. Use it with my FSUIPC.FSI file, also in the SDK, and you can see not only the value changing, but also compare all of its different "raw" forms depending how it is interpreted. My bet is that you are losing part of the value -- maybe multiplying the possibly very large integer by 360 and so overflowing? If so either convert the value to floating point BEFORE calculating, or do at least part of the divisions first. Regards, Pete

Since I've never done anything like that I can't really say if you can get it perfectly smooth. With enough computer power I don't see why not -- a lot will depend on how much of the detail and so on you have switched on in FS. For smoothest operation you want to be able to input just the right number of changes per second to match the "natural" FS frame rate. To start with I would set the FS Frame Rate Limiter to, say, 18 or 20 per second (18 is a natural figure as it is also the standard Windows timer tick second, used quite a lot in FS), then try to feed the data in at that rate. If you allow it to be adjustable you could try faster rates, or course. With versions of FS before FS2004 there were only three ways of changing all 6 values: 1. slew mode 2. paused mode 3. what I call "stopped" mode (setting the Sim Rate to 0) All these should be workable in FS2004 too, but in fact, as I think I say in the Guide, you can change them in normal flight mode now. Bear in mind that if FS is actually simulating then it will be trying to change things as well, so you then cannot allow it to run faster than you -- hence the use of the frame rate limiter. Regards, Pete

With which version of FSUIPC? Does the DF 737 need/use FSUIPC at all? There aren't all that many aircraft that do, especially not in FS2002 days. And it seems very unlikely to need it for something so simple and basic as the heading bug value, which would probably be the same as the one in the default FS2002 panels. See if the results are different without FSUIPC. If you are using FSUIPC 3, have you registered it? Look at the FSUIPC.LOG, see if that says anything avout the DF737. Regards, Pete

Is this with FS2002 or FS2004? Which version of FSUIPC? I am not aware of any issues with the DF737, but maybe others here can help. Maybe it is using FSUIPC and you have not registered it? Please look at the FSUIPC.LOG file (in the FS Modules folder) and see if there's any mention of it there. Have you tried it without FSUIPC installed? Regards, Pete

Ah, yesI've had those. Makes quite unpredictable crashes which you can never track down, mostly in something like FS which uses more RAM than most other things (except probably Photoshop! ). Good. Glad you managed to sort it all out! Regards, Pete

Oh, I see. No, I don't think you can do that without having a selectable extra position, as you suggested. But I am not an aircraft designer and this is not my subject. Maybe there is a way to design the aircraft in the way you suggest, but this will have to be part of the CFG, AIR or MDL files, there are no separate slat and flap pilot controls that I know of in FS. What do the "professional" (ie payware) AirBus models for FS do about this? Regards, Pete

Like over 90% of all "offsets" listed, they are "fake" in the sense that the value of the offset is completely unrelated to where the data is inside FS. Please just regard "offsets" as meaning "token numbers" or even "names" for the values. The apparent memory mapping is mostly an illusion, created to maintain compatibility with the original interfacing method created by Adam Szofran in FS95 and FS98, when it was really just a window to the FS "GLOBALS.DLL" data area. When you say "use" them I assume you mean read the values so you can have one of those multiple flap position indicator gauges on your EICAS screen? There's no other use I can think of, except maybe to figure out drag and lift figures your own way instead of relying on FS calculations. The different flap positions and so on are defined in the AIRCRAFT.CFG file in [flaps.N]. There are certainly several such sections defined for the default 737-400 and they are even commented. Is there not enough information there? Check the Aircraft Container SDK from MS. Otherwise that's really a question for aircraft designers, amongst which I most certainly do not number! :? The values most certainly do change with the default 737-400. I think they work for all aircraft, IF the corresponding flaps or slats are actually fitted. You cannot write to them, they are only read-outs -- FS does not provide separate controls for each flap section (nor probably do real aircraft), though on some aircraft ailerons also adjust some flap sections ("flaperons"?). Regards, Pete

FS crashing on exit has been a regular problem throughout FS98, FS2000, FS2002 and, less often as far as I know, FS2004. I don't know which FS you are using, but my normal advice is not to worry so much about this. It appears to be related to the order in which the modules are loaded -- not just mine, but all the modules. They are loaded in the order that they are listed in the disk directory blocks, on disk (NOT in the order you see in Windows explorer). Each time you change one or more modules the order probably changes, so you get different results. After many experiments with past versions of FS I discovered that some modules close down before others which may be calling them still, or have references to data which they own and release. Quite honestly, after many hours spent trying to track down these things I identified so many ways it could happen, all of them probably infrequent but possibly consistent with specific ordering or memory setups, that I gave up all hope of ever fixing it for good. At least it does no harm. If you are exiting you wanted FS to close in any case. And it seems very very rare in FS2004 compared to earlier versions, so things are improving. Regards, Pete

I think this is a question for Project Magenta support, it is not a WideFS matter. It sounds like a demonstration copy of Project Magenta, but check with them, please. If you have any WideFS problems they will show up in the WideClient or WideServer LOG files. You should find those and look at them. I can interpret extracts here if you think there's anything there that matters -- but on this matter it sounds 100% Project Magenta. You actually have official Project Magenta keys for both PCs? Regards, Pete

If you are reading "71" you are only reading the high word (2 bytes or 16 bits at 0B7E). With 56% capacity the value in 0B7C as a 32-bit value is 4698168. This would give 71 if divided by 65536 -- in other words the value in the high 16 bits is 71. But take your 71 (ignore the fractional part for now) and calculate that as a percentage of 128. (71 * 100) / 128 = 55.47 The missing portion of the true % value is lost in the fraction part. Take the full 32 bit value and do the calculation implied by the description: (4698168 * 100) / (128 * 65536) = 56.01% If you want the amount of fuel in US Gallons, read the capacity also (from 0B80 in this case and calculate 56% of that. If you want it in pounds weight use the conversion value given by the offset 0AF4 (the relationship will change slightly with altitude). Please look inside the FSUIPC SDK package, and find and install FSInterrogate. Run that next to FS and tell it to load the FSUIPC.FSI file I provide. You will find it very instructive to use FSInterrogate to learn about any of the FS variables you are interested in, and to check your own work. It will read any or all FS values and display them in a multitude of ways. You can also see the formulae I give actually work in practice, and so see how to do things. Regards, Pete

It's done (optionally) already by ActiveSky. But it does tend to hit frame rates rather hard. Pete

Re-enter the same details you had then. If you have the recommended backup of your FSUIPC.KEY file then the details are there, otherwise they are in your original email from SimMarket. If you have lost both then you can retrieve your Key from SimMarket by going to http://www.simmarket.com and going into your account. But you have to remember the name (your name) and email address (your email address) you used back then. Regards, Pete

This is a gauge you are writing? If so, this is wrong: FSUIPC_Open(SIM_ANY,&dwResult); You must use the module users interface (see separate ZIP in the SDK, and FSUIPC_Open2. Else your gauge will (a) only run on fully user registered copies of FSUIPC, and (b) possibly clash and fail if anyone else in FS is using the same EXTERNAL interface that you are! On this: AC_Lat = AC_Lat_int * 90 /( 10001750.0 * 65536 * 65536 ); AC_Long = AC_Long_int * 360 / (65536.0 * 65536 * 65536 * 65536); I don't know how the compiler handles "SINT64" (ie __int64), but maybe the conversion to double float is not working well because of the mixture of floating and fixed values you are using. Try: AC_Lat = (AC_Lat_int * 90.0) /( 10001750.0 * 65536.0 * 65536.0); AC_Long = (AC_Long_int * 360.0) / (65536.0 * 65536.0 * 65536.0 * 65536.0); just to make sure it is using floating point throughout. I added more parentheses to to make sure it is calculating things in the right order. You could also use your debugger to se what is actually happening. BTW, since you are writing a gauge, why not simply read the Lat/Long in floating point directly via the Gauge tokens PLANE_LATITUDE and PLANE_LONGITUDE? It seems a bit odd using the external application interface for FSUIPC to get stuff you can read directly inside FS! Regards, Pete

For each tank there is not only the capacity, but the percentage occupied by fuel. These are all in pairs for all possible tanks -- see offsets 0B74-0BA8, and 1244-1260. Regards, Pete

What problem? Please go get the latest PFC DLL version. There is nothing outstanding that I know of. You seem to have attached to a very old thread (October last year!!!). There have been lots of issues discussed and releases made since then! Regards, Pete

Nah, don't take it like that! The only stupid thing is not asking the question and suffering quietly instead! :lol: I don't mind, honest. I'm getting really relaxed over all this stuff these days. :) Regards, Pete

Well, it's been a long time since I was asked this old question! :( As it says in the FSUIPC User Guide: It works fine if you allow it to, honest. :) Regards, Pete

Yes, I think it is supposed to be. It doesn't appear to depend on the actual surface visibility, which is not good. It does change a bit when the cloud textures are replaced, but whether for the better or worse I can't really say. I ignore it by flying the aircraft and looking where I'm going, not where I've been! :) That's correct for FSUIPC because it should be smoothing the change between the 2 nm and the 20 nm. Try setting the rate of change of the smoothing to be a lot slower. You need to adjust things till you are happy. Try setting a lower maximum too. With the FS upper fog altitude being so low (2000 feet), lower limits suit things better, at least in Europe. In some parts of the world this wouldn't be so good. But on the transparency issue, you are right. Not only with fog, but clouds generally, Folks complain that even with lots of cloud you can see through them when above. And overcasts aren't! I actually get annoyed by seeing runways (only) as black bars straight through poor visibility and clouds, but I'm not sure whether this is only for my add-on airports or defaults. Maybe the add-ons (UK2000) are not defined in a way which allows them to disappear behind clouds. I've not seen any one else mention this phenomenon. FS2000 was, in my opinion, the best version so far for good visibility effects. The clouds weren't as good as in FS2004, but the visibility issues were all sorted. FS2002 was a complete disaster in that area, and FS2004 has recovered somewhat -- looking quite good sometimes -- but there's still some way to go. Regards, Pete

This is really a question for the Squawkbox folks, but it may simply be the differences in Multiplayer Protocol. The WideFS connection will probably look to SB like an FS98 installation (I don't think version 2 SB reads the FS version), so it will assume the wrong protocols. I think there will be parameters to sort this out in its INI or CFG file. For FS2004 you'll still need the relay program to convert to FS2002 protocol for SB2. Regards, Pete

It has always been there. It wouldn't be in "winds" in any case. It should really be in "Pressure" but as it would be the only option there it wasn't worth making a new page. It only affects the values being supplied TO FS, not what FS does with it thereafter. Regards, Pete

Well, yes, sort of -- but the "thin cloud" is supposed to look like the mist/fog covering the ground. Many folks don't like the effect at all, so I'm surprised you appear to not even see it. Replacement cloud textures may affect it. The graduating visibility that FSUIPC can apply should keep you in a diminishing fog in any case as you ascend. Perhaps you have one of the altitudes set wrong for that? Set the lower altitude to 0 to have it starting at the top of the FS layer. Pete

Sorry, you evidently have an error, but I cannot diagnose it from here. The values are used in very many programs with no trouble at all, including for instance my own TrafficLook which uses them to calculate distance and bearing to the AI traffic it lists. Similarly, Project Magenta, Squawkbox, and all the weather programs to name but a few. If you post a code snippet here I am sure someone can spot your error -- I am okay with C or C++ but other visitors know Visual Basic and some even Delphi, possibly. Regards, Pete

I don't know what weather you are using. The default FS2004 visibility layer isn't very deep, and when you fly above it you normally will get the default "unlimited" value. In FS2004 they did add a sort of thin cloud graphic to the top of the visibility layer, but I think that can look odd too. Some of the replacement cloud textures available change that or even may remove it. But is should fix the sudden changes. It certainly does here. Turn on the FSUIPC graduated visibility option. Use that in conjunction with the FSUIPC visibility maxima and the smoothing. It does nothing at all unless you are getting weather inserted from an external weather program, or you are forcing Global weather only at intervals in FS and have the FSUIPC technical option enabled to make FSUIPC fiddle with FS global weather. In those cases it overwrites the upper altitude set for the surface visibility layer with the value you put there. You might do that to set a higher value than the one being set by the weather program. I can't see why you'd ever want it lower, but you might if a weather program set fog up to 30000 feet! :) Your best bet is to enable all three options marked *** on the FSUIPC visibility page. Regards, Pete