Pete Dowson

No, it's hacked into a different part of FS, a part I know nothing about. Bit like Lago's FSAssist, if you remember that -- in FS2000 it fiddled with all sorts of things I've never found. There's different bits of expertise in different places. No one knows it all it seems! :wink: Pete

Because VB is rather odd in that when you run your program within its auspices, it isn't your process which is running, but VB's. So FSUIPC doesn't recognise you, and so the Key doesn't check. Please look at the FSUIPC LOG, it will be evident then. Sorry, but either you will have to only ever run your program on its own, or register FSUIPC so that it will accept all programs. Regards, Pete

All I have access to are the same controls as you could operate by sending controls or keystrokes, i.e. ZOOM_1X ZOOM_IN ZOOM_IN_FINE ZOOM_MINUS ZOOM_OUT ZOOM_OUT_FINE ZOOM_PLUS I'm not sure what they all do individually, but I doubt that any of them are "smooth". Have you tried. You may wish to ask the author of Active Camera how it is done. I think he must know a lot about that part of the innards of FS. I'm afraid it's an area I know nothing about, so it would realy take me a long time. The "Zoom" factor at 02B2 is, oddly enough, one of the few remaining original GLOBALS which FSUIPC doesn't touch. It doesn't stop you overwriting it either, it just seems to have no effect. Sorry, Pete

I'm really no good at graphics, sorry. Even those that do exist weren't done by me! Anyway, I don't particularly want in-your-face advertising! I'm one of those that cuts designer labels off clothes (they don't pay me to advertise) and peel "Intel inside" labels off computers! :lol: :lol: Regards, Pete

Yes, but sorry, there are no facilities to load a program, wait for it to be ready, then send it a key. Knowing when it is ready to accept one is a problem in itself. Most programs like that usually have some command line option to load and run with assumed settings, or similar. Have you investigated what can be done in the program? Pete

Do you know how to do it? I can add it if someone knows how. I'll investigate it myself when I get time. No promises though. Regards, Pete

Sorry, I don't understand. You are saying that "loading" and "running" this program are two separate things? Why, when you load the program, doesn't it run? Both FSUIPC and WideFS have facilities for loading and running programs (treating these as the same thing). There is no single facility which will load a program, wait for it to load and become ready (how could it tell?) then send it some keystrokes. The latter is certainly a separate action. Regards, Pete

But the FSInterrogate.exe I supply in the FSUIPC SDK comes with a valid access key embedded in its "properties" and will work with unregistered installations of FSUIPC. These are the details: FSinterrogate.exe Product = "FSInterrogate", Company = "Pelle F. S. Liljendal" Key = 161C 7AUZ D1BV If it isn't connecting for reason of registration, it will say so in the Log, and this would imply you have a pretty old copy of the FSUIPC SDK. However, I also give the above details in the "Freeware Key" list near the top of this Forum. Regards, Pete

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