Pete Dowson

I assume you are using FSUIPC 3.30 or later? If not, upgrade first. If so, this is best directed to the PM support folks. All FSUIPC does is set or clear or toggle the bits in the FSUIPC offsets used by PM, in accordance with the documentation on the FSUIPC offsets used by PM that you can see in the PM website. That part (the changing of bits) most certainly works. Different builds of different PM components do different things. Many of the functions did not work unless the MCP was running, but I think that was changed in some builds. The PM builds change faster than I can keep up though, which is why it is best for you to ask those that know these things, or at least post on the PM newsgroup. You should also be more explicit about which commands you are trying and what PM components you are using. Regards, Pete

Several? There's only one FSUIPC.ZIP surely? There are brief descriptions there too. Didn't you look at those? There's also a list of supported versions in the announcements at the top of this forum. Please scan those! If you don't know what it is for, you certainly don't need it and probably don't want it. If you are really curious, please just read the documentation. I don't see any point in printing it all here. Otherwise why not just forget about it? Regards, Pete

1. You don't need it. 2. Of course CH don't support it. It isn't their program, it is nothing to do with them. It is nothing to do with CH in general, in fact. 3. Whether you want it or not is entirely up to you. If you download it you can browse through the documentation and see if it strikes you as useful. That costs nothing. Then throw it away if you don't find it of interest or don't understand it. 4. You find it on http://www.schiratti.com/dowson. 5. You must always use the latest version, no others are supported. Please see some of the announcements above for details and to keep up to date. Regards, Pete

No, because I don't have a database of registrations. All the registrations are dealt with by the supplier, for instance SimMarket. Your notification from them of the Key will contain the user name and email address which you told them you wanted it registered under. Are you saying you've lost your received emails too? For a lost access key you can obtain it again from SimMarket by going to http://www.simmarket.com and opening your account there. But to open your account there you need the user name under which you established that account. If you are in the habit of using lots of different names in different places and can't remember which one is which you are in a bit of a sticky situation, as it is only by such details that you can be identified. Regards, Pete

Possibly. I'm not sure how DxDiag gets involved, but I think that the reason you get a crash and I don't is simply that there are different things in the memory which FSUIPC is assuming will contain the Engine 2/3/4 stuff. If something critical gets overwritten, you get to know sooner or later. If not, you don't. The problem in FSUIPC at present is that I only check whether the pointer I derive points to valid accessible memory, which it does. Before I prevent writing to these things altogether, I'll look to see how easy it is for me to derive separate pointers for each engine so I can nullify those which don't apply. Regards, Pete

It provides all of that and more. You can get not only pitch roll and yaw, but, much more to the point I think, the velocities and accelerations in all 6 degrees of freedom (X Y Z P B H), both relative to the aircraft body itself and to the world at large. Just download the FSUIPC SDK from http://www.schiratti.com/dowson and peruse the programmer's guide -- particularly the tabulated details of the data available. But you will need to do some programming! Regards, Pete

If it is indeed an FSUIPC access problem, and this doesn't prove it by any means, just enter the gauge name, in full, and the Key into the correct places in the dialogue you get when you press the "register an application" button. The gauge is an "application" in this sense. You can tell if it is an access problem by checking the FSUIPC.LOG file in the Modules folder after such a failure. If you are using an up to date version of FSUIPC you should get an error message coming up from FSUIPC telling you so too. Most maintained applications, gauges and DLLs for FS which have access keys do this stuff automatically. It is a shame not all programmers bother to make the small changes necessary for this to happen, but at least then they should really provide some instructions. :( Regards, Pete

Hmmm. Not sure where DxDiag comes into it -- how does that start to run? I thought that was a user utility to check for problems in DirectX. I've tried all sorts of tests here to make this crash occur, and I cannot. However, really you should be using the well defined and well established throttle controls in the lower areas. Most all of those upper areas are non-writeable or unpredictable if written. In fact now you've told me there is a problem with those I will be blocking writes to them, making them read-only, so please change your program. You may have noted that those were only recently "promoted" from the 2nd, unsupported table in the Programmer's Guide, to the first table, but I should really have marked most of those "read only". Many of them will certainly crash FS. The problem I have is time to test every location in every version of FS with every aircraft type. BTW the fact that you are getting FS crashing rather than a mere error being trapped by FSUIPC does indicate that in fact it isn't a memory access problem, it is just that whatever you are writing to is actually part of something else and causes the crash later. Thanks for the details! Regards, Pete

It wasn't me who sent it. That's all handled by whoever you bought it from, probably SimMarket. If you didn't re-install Windows then all you had to do was save the FSUIPC KEY file, as it says in the documentation. However, be that as it may, now you need to re-register and you must use exactly the same details -- same name, same email, same Key as before, exactly as notified to you. It sounds like you are making a mistake with the entry of one or more of these parts. Regards, Pete

No, no idea, but it is likely related to something FS is doing with invalid values. After all, the only valid values for the last digit of the frequency are 0, 2, 5 and 7. Try testing the last digit and increasing/decreasing by 2 or 3 depending on the current value. Your values are hard to check in decimal. It's the hexadecimal which is important. Your "9093, 9092, 9091, 9090, 9089, 9088 and then back to 9093" are frequencies 123.85, 123.84 (invalid), 123.83 (invalid), 123.82, 123.81 (invalid), 123.80. The next time you decrement you would get the invalid 123.79. Why FS should do more with that than the other invalid values I don't know, but try to give it proper values only and see what happens then. Regards, Pete

Those locations may not be so well checked -- I think they are directly mapped and intended for reading only, but I'll check that. Writing to them has never been tested, I'm surprised that this works at all. The supported Engine variables, compatible from FS98 through FS2000, FS2002, and FS2004, are those at 088C onwards. These are the ones almost universally used by third party programs. If FS crashes, e.g. with access violation, whilst FSUIPC is doing anything, like writing to such locations, it will not crash FS but the crash will be trapped in FSUIPC and logged, then things carry on. The log would show the error, but nothing else. But that's by the way. I've just loaded up the Cessna (as the default, just to be sure) and tried to replicate your crash by writing values to the Engine 2 throttle with no problems at all. In fact the values "stick" and can be read back, which is odd when you think about it. Yes, please, because at present it is not looking like FSUIPC's doing. BTW I assume you are using FSUIPC 3.30? If not please try it with the latest version, I don't care to try to track back to older code. Thanks & Regards, Pete

That shouldn't happen, as FSUIPC checks, not for the number of engines, but for a valid ultimate destination. It wasn't until FS2004 that FS separated all the engine stuff into up to 4 separate structures, and didn't bother to allocate the structures if they weren't needed. In FS2002 and before the setup for all 4 engines was in one bigger structure with other stuff. Same for helo instrumentation and other stuff not always present. Please tell me EXACTLY what you do that crashes FS so I can investigate. As I say, it should be covered. Regards, Pete

FSUIPC has no way of creating traffic. There are only two ways I know of, one is multiplayer and the other is compiling new traffic BGL files. Only multiplayer works "on the fly", but at a cost -- in multiplayer mode you lose FS's AI traffic and ATC. Ah, that's different! Yes, you can do that -- it is documented in a section near the front of the FSUIPC programmer's guide in the FSUIPC SDK. It is the facility used by AIBridge to get MP traffic seen by TCAS displays, but it will work without MP running and will mix with "real" AI traffic. Regards, Pete

Please just download it and read the documentation. Then ask questions if you don't understand. Yes, a normal latching toggle switch. Yes, of course. If the simulator does not actually support separate "ON or OFF" controls for a particular function you would have to program the same "toggle" function for both "press" and "release" and get the switches synchronised before you start. But for many functions, FS does off separate ON and OFF controls as well as Toggle. For instance, Strobes, landing lights and panel lights have On, Off and Toggle. However the other lights (Nav, Taxi, Wind, Logo) only have toggle functions so you'd need to synchronise them with your switches first. Check my lists of FS controls (http://www.schiratti.cxom/dowson) is you are curious. For a more thorough treatment, all the light switches can be accessed through FSUIPC offsets -- a separate bit for each one, set for 'on', clear for 'off'. There are FSUIPC controls which you can program on buttons to set, clear or toggle bits, so you can do anything you like. This is not quite so intuitive, and for FSUIPC offset details you need the Programmers Guide documentation, in the FSUIPC SDK (same website). Regards, Pete

Try setting Summer or Winter as the season in FS, see if it helps or not. If it was one of those when you crashed, try the opposite: i.e. Spring or Fall. But I think the CTD problem was related to transitional trextures so these are more likely. One CTD I came across was fixed by removing some apparently bad AFCAD files. These were Project AI related files I think The filenames were: PAI_AF2_?????_?????.BGL and AF2_????_????_???.BGL The sufferer mentioned that there were 77 of these on his system and after he removed them, no more CTDs. The only way to find bad scenery files really is to eliminate one add-on entry in the Scenery library at a time. Or, quicker, do a "binary chop" on your list -- i.e disable one half, see if you crash, if so, halve that and so on. If not, swap halves. This is quite quick, getting through 256 add on scenery layers in 8 reloads. However, the results will be ambiguous if you have more than one causing problems. Regards, Pete

The Key for what? You enter all Keys by going to the FSUIPC Options (ALT M F), as described in the documentation. For an FSUIPC Key you press the button to register FSUIPC. For a WideFS Key you press the button to register WideFS. For an application Key you press the button to register an application. If any of the buttons are greyed out then this has already been done, or there's no need. For instance, once your Registered FSUIPC as a user you never need to register any applications. Most applications register themselves automatically in any case. It is only dead programs (i.e. those which are not maintained by their authors) which may need manual registration. There, what is so obscure about any of that? Regards, Pete

No, as the documentation says, that is the pathname of the current air file. There is no facility to load an aircraft except by loading a FLT. Sorry. Regards, Pete

I get that too sometimes. I think it is an error in FS to do with textures at certain places, in certain seasons and at certain times of the day, with some video cards and some drivers. I have some routes which I never fly at night because I get that sort of crash most of the time, half way through. Yet it is okay at night. On a different PC with a different video card it is fine, never crashes. No, I don't think it can be. That's a very popular combination and there would be reports all over the place. I did hear of a 'fix' for a seasonal texture bug which does this, but I can't locate it now. But compare results flying at night versus day, Summer versus Autumn, etc. And maybe try different video drivers, not necessarily the latest. There jolly well ought to be! Before FS2004 I've never ever seen any program crash to desktop (CTD) with no message, no dump, no trace whatsoever. I really don't know how it is possible! Even if I have one of my debugging tools running it doesn't catch it. Incredible! During the Beta testing of FS2004 there were really many of these -- hence the abbreviation "CTD" -- but they did eliminate most (evidently not all) before release. Sorry not to be of much help. Please let us know if you do find any answers. Regards, Pete

Don't "reassign" them in FS, just properly assign them as toe brakes, as they should be recognised in any case if FS recognises your pedal set --which it should. If it doesn't you may want to try deleting the FS9.CFG file and getting FS to configure itself all over again. When you've calibrated them in FS and they work okay there, if you want to refine them further, THEN go to FSUIPC. But, in fact, you said they were inoperable!!? :? If they are working fine in FS, then in FSUIPC press "SET" to start calibration. It won't intercept them unless you do that. Pete

No idea without seeing the weather actually downloaded. Bear in mind that the weather you get from downloading is complex, it includes most of the weather stations, each with their own weather. I've no idea what you mean by "haze" -- you could be experiencing clouds rather than actual visibility limits. Weather in any one place is interpolated from all the neighbouring stations. When there's a haze layer, FS puts a very thin cloud layer on top, so you see the haze when looking down. Maybe some of your experienced changes were due to this thin cloud. If you flew through a different zone with a higher haze boundary that layer would have been higher and may account for you going through it twice. If you have a registered version of FSUIPC why not try to use the recommended visibility settings there -- limits, graduation, and smoothing? Of course, if it's clouds you are seeing this won't change anything. Regards, Pete

Yes of course. Even FS out of the box supports axis-driven spoiler setting -- check FS Options-Controls-Assignments. With flaps you'll need to tell FSUIPC which axis you are "stealing" for this (it's an FSUIPC.INI parameter -- please see the Advanced User's guide for FSUIPC), assign it to that (otherwise unused axis in FS, then calibrate it in FSUIPC. For specific flap detents you will need to mark them by testing -- they will be different for different aircraft with different numbers of detentes. Regards, Pete

You surely don't need to set negative V speeds? Anyway, the MCP IAS is not a V speed but the target speed setting for the autothrottle in the MCP. And it cannot be set negative. If you are thinking more of values like the Vertical Speed, then, yes, you need negatives. EPIC doesn't support negative numbers anyway, but if the recipient, as in this case, accepts 16 bit signed numbers then you simply sent the positive equivalent -- it will look negative when it gets there. In most all computers these days negative numbers are represented by what is called "2's complement". This is basically the "NOT" (logical bit reversal) of the positive number, plus 1. For example, in 16 bits: +1 = 0000 0000 0000 0001 -1 = 1111 1111 1111 1111 +120 = 0000 0000 0111 1000 -120 = 1111 1111 1000 1000 Arithmetically you can derive the latter from the former in a 16-bit capable system (like EPIC) by neg = (65535 - pos) + 1 Note that although this looks the same as "65536 - pos" you cannot use 65536 in a 16 bit word as it needs 17 bits. However, the following MAY work: neg = 0 - pos but I'm not sure what sort of checks EPIC applies -- this would "look" negative and it may zero it. I can't remember, but I have a horrible suspicion that it does. Last time I programmed EPIC was years ago. Regards, Pete

Are you using either FS2002 or FS2004? If so, are they recognised by FS? If so, simply assign them and calibrate them in FS (Options=Controls-Assignments-Joystick Axes). You don't need FSUIPC for any of this in FS2002 or FS2004, but if FS doesn't see them nor can FSUIPC. Once you have them working in FS you can refine the calibration in FSUIPC. If you are still using FS2000 then you need to do some assignments in the FS CFG file to get FSUIPC to see them. This process is defined in the FSUIPC User Guide. BTW, I really cannot see how a change in your graphics card can have any effect whatsoever on your pedals. Weird. Regards, Pete

No idea. It probably depends how the gauge is written. I don't know much about them I'm afraid. I'm afraid that there will be milliseconds between pushing the P key and everything pausing in any case, and if you are also reading things through FSUIPC there will be milliseconds there too -- process switching (twice), message processing, and so on. And in any case, if there were a millisecond local time count, how would you know that this was being stopped at the same time as the last time your VSI adjusted itself? It might be stopping before or after that. Since the only evidence you have of a so-called "time lag" is the movement of a needle on one gauge, only (?), I can't see how you can do it programmatically at all. You'd have to use a stop watch, or if your reactions are not quick enough, make a high speed film of you pressing P and the VSI needle still moving, then count the frames on the film. I really don't see the point though, I must admit. Regards, Pete

As far as I know FS doesn't maintain any simulated time in milliseconds, sorry. Why would you want this? If you are merely needing to timestamp something, to show the order of things and time between them, try the millisecond counter in offset 3378. This is the one I use in my Log files. It shows the number of milliseconds since FSUIPC was loaded (which is a little after FS starts of course). Actually, you could work out simulated time using that value, by noting it when the simulated second changes. But you'd need to scale it by the sim rate if that ever changes, and discount time in menus, time paused, etc etc. It's pretty horrendous. FS does also maintain its own "tick count" at offset 0310, but this is approximate, is only updated every 55 mSecs or so, and would still not reflect sim rate, pausing and so on. Regards, Pete