Pete Dowson

No, there's no such facility in FSUIPC at present. In fact it has never been asked for, at least not a direct switch-over like that. Well, I assume some of that is to do with Airbus automation / fly-by-wire. It certainly isn't realistic for all that to happen on one button push in any of the aircraft I know, but then I know little about Airbuses I'm afraid. What direction does the throttle operate in to control reverse thrust? Surely not push forward for increased reversed thrust? That seems rather non-intuitive. The FSUIPC provisions allow for the IDLE to be set a chosen distance up the axis, so that when the throttle lever is pulled all the way back it provides full reverse. Exactly. It is certainly possibly to provide controls to re-assign axis uses, or simply to change the range of axes, as you seem to want. However, to provide general programing facilities like that with an easy-to-use interface is not a small job. For some time now I have had on my list a project for a separate module, or even program, to not only allow dynamic reprogramming, but also for having variable response curves and keystoke emission at different axis values (for Airbus throttle detente type operation. However, that's a big project to undertake and there's been too much other work to attend to. I'm not really sure of the true usefulness of just having the throttle being a foward axis or reverse axis, expecially not with the confusion of reversal of direction, but I can consider it. On the whole I would rather leave it and do things more comprehensively, later, when I get the time. Yes, that is important. You need a reliable non-jittery area for idle. Best to glue a small piece of rubber (say) onto the axis slot as a sort of "detente", just offering a little resistance so you can "feel" the throttle into idle from either forward or reverse settings. Regards, Pete

Sounds like either you need to thoroughly calibrate them in Windows' Game Controllers, or there is some fault in them or the connection. Oh, right. That's odd then, because both FS2002 and 2004 have the same joystick input routines. The main change was between FS2000 and 2002. You only purchase version 3. All the updates 3.xxx are inlcuded, you don't need to pay for each one. And 3.04 isn't supported, it's too old. I only support the current versions. Why not use the latest on both? Check the History document for all the changes and improvments you are missing otherwise. No, not unless you are using FSUIPC to calibrate, in which can you may be doing this better in one than the other. Just try copying your FSUIPC.INI from the good installation to the other. Make both of them 3.135 whilst you are at it. There are no values relating to joysticks in the Technical tab -- you mean the Joysticks tab? Simply press the "Reset" buttons on each axis entry, so they change to "Set", then FSUIPC won't be interfering at all in any of your joystick inputs. Regards, Pete

I only generated the key based on the information given to me at that time. In fact a Product Name or Product Description field is needed, so I don't know how the currently uploaded version (2.0) was ever used with the Key I published, even though this dates back several months already. I know Jose is near publishing a revised version which is (also?) compatible with FS2004 -- version 2.0 isn't, as far as I know. If this is not suitable or imminent all I could do, with Jose's permission, is patch the Properties in his version 2.0 to make it acceptable to FSUIPC. I can do this during the week, but perhaps meanwhile you could post this to him and see what he says? Thanks, Pete

Not that I know of. The best data I found, actually available in memory for FSUIPC to locate, is the GPS data now mapped in the 6000-61FF offset area. You can read the details of the previous and next waypoint, and the number of them, but I've not found the complete list nor the filename. There may be some other stuff in that area -- I've only documented what I recognised. Regards, Pete

Okay. The only reason there's not been a key for it is that no one has asked before. since all the information I needed was in the Log extract you supplied, I have managed to make a key without further to do: Application="Airport" Product="Airport for Windows" Company="Tom Hiscox (thiscox@msn.com), Pascal Meziat (pascal@simflight.com) " key=E590 W3BL YV9L I'll add this to the main list at the top of this thread. Regards, Pete

Sorry, what is "Airport"? Is it freeware? Pete

Right at the beginning of the FS2004 Beta phase, or even a bit before, if I remember correctly, MS did ask if I could produce a specification of what I needed, so they could produce a proper interface module. I was a bit taken aback, but quite pleased. So I responded with the Programmer's Guide I'd produced -- "look, these are all the things folks use at present. that's a start. But there will be more ...". They said, "... but we need an inclusive list". I said that there's no way it can be "inclusive" because there's always something else, some new application or need. I can't predict what that may be. You just have to look at the changes in the Programmer's Guide from version to version to see that -- when compared with what was available in FS98 it is astonishing what's been added. Not only that, they said that even if we agreed on some specification of the data needed, it would be AFTER release date before they could even start to look at it, and after the revised SDKs they normally produce as well, most likely. So, at that rate, maybe we'd be lookng at something soon, maybe by Summer or Autumn this year. I reckon that even if we'd agreed something, it would have had to be cancelled. The pressure on the MS team for ongoing developments is quite heavy, it's a small team, the SDKs are voluntary (not committed), and they will certainly have started working on FS2006 (?) by now -- it's Alpha testing will be starting in not so many months. The best bet for something more successful would have been if they could have put me on a sort of "trusted outsider" status (with an NDA of course) and let me see the header files and internal interface details. Some of the team thought that would have been a good idea, but management would never has stood for it. Then, when I found I had to go semi-commercial (reluctantly forced by changed circumstances), that was most definitely not an option for them and presumably will never be again. Regards, Pete

Disassembly (I use IDA Pro and PE Explorer) and Debugging (Soft-Ice mainly, MSVC Debugger and WinDebug for some things). In other words what used to be called "hacking", though that term has now come to mean, more usually, breaking into Internet or other on-line resources. I don't do the latter at all. :) It's hard work and takes a loooonnnngggg time! Thousands of hours goes into finding stuff in each release -- and it gets harder now they use C++ and COM a lot, the assembly code that produces is awfully convoluted. :roll: Not that easy. Much of the stuff I need isn't exported at all, even by the old FS5-type linkages which have always been the mainstay. I have to find not only the routines but also the correct "this" pointers to stuff into their "this" register (sometimes ECX, sometimes not!). Same with data -- in C++ there's not such a big distinction between data and code, it's all wrapped up tight in the protective black boxes they call "objects" these days. Ugh. :x I am at heart and by history an Assembler level programmer. C is about as far away from the nuts and bolts as I like to get. The sort of code produced in the name of Object Orientation is totally alien to me and makes me shudder! :( Regards, Pete

Not quite. In the UK the requirement is that all IFR flights in controlled (class A-E) airspace must file a flight plan. In uncontrolled airspace (F/G) a flight plan is not required Sorry, I was referring to FS. Pete

Sorry, I don't know any way to do that other than by calling the Load Flight routine. In FS2004 there is a "reload aircraft" control which you could send via FSUIPC, but that doesn't change the aircraft, only reloads the current one (presumably to reset its systems or conduct repairs). Regards, Pete

These are really questions for PM support. FSUIPC is merely the messenger, it doesn't read the contents of these things nor act upon them. However, as to your first question I think it means that his program has no way of telling that you want two successive characters the same if nothing changes -- the only way it knows you've done anything is because the value changes. So, you have to make a change that doesn't matter. It looks like the word "bytes" there should in fact be "bits" -- just change one of the unallocated bits in the high byte each time you send a character, then it will know about the change. Sorry, I don't know anything about the second question. Regards, Pete

Unlikely. Most everything in FS nowadays is procedural -- I actually have to monitor the writes to many many things and use the written data in parameters to calls into assorted FS DLLs. The problem is finding the right place and the right parameters for each need. It is made extremely complicated also by the fact that much of the code is now Object-Oriented C++, not the original ASM + C of FS95/98, and many things are inherited or polymorphed or otherwise OO-ised, necessitating finding the right pointers to the right structures/tables beforehand in each case. Sometimes an apparently simply thing takes several calls to several hacked entries in several different DLLs. Ugh. Yes, but when there's so much else to do in any case, trying to solve the same problem someone else has solved already is wasteful and not enticing. The quickest way would be for me to find out how ActiveCamera does it, but that is against my principles as well as wrong. Sorry. If the ActiveCamera author wants to volunteer the information "for the common good", then that is another matter. I can add stuff in that folks tell me about. That's how a lot of the stuff got in there in the first place, starting back in FS95 or even before. Regards, Pete

You still have to file a flight plan. All IFR involves flight plans. But you can specify your alternates and declare emergencies. Radar Contact does not handle VFR at all. The main difference from the old days of ProFlight and Radar Contact 2 is that RC is now a separate program, and runs fine under WideFS on a separate PC. This has several advantages, the main one for me being the separation of the ATC voices to a different set of speakers or, more realistically, a headset. Using one of the voice recognition programs you can actually then have ATC completely on headset without affecting the normal FS sounds on your main FS PC. Radar Contact is getting more and more sophisticated all the time and some amazing things will be seen as it develops. If you are really into ATC I strongly suggest you give it a try. The authors are very responsive to sensible and constructive suggestions too, so anyone who knows his stuff is always welcome and should ask to get on the Beta team to help development. Yes. But it doesn't know taxiways so you won't get taxi directions. It's up to you to find the runway for departure and the ramp/gate after arrival. Ah yes, you are right "Sidewinder Game Voice" it was called. It came with a headset (Microsoft-badged Plantronics) and a gizmo for connecting it to USB as well as sound card. It was the only one I ever found which would recognise things pretty consistently without even any training. Yes, but from what I've read here and there folks do seem to find that it works. As I said, Game Voice seemed pretty good, and I was surprised how well it worked even with the FS sounds all around me on normal speakers. Voice Buddy worries me a little as it seems to imply you have to have all the sound on the headset. Regards, Pete

If FSUIPC recognises the hat positions as buttons, yes. If not, no. Whether it does depends upon how it is programmed in the joystick driver, I think. Try it -- go to FSUIPC's Buttons page, and move the hat to different positions. See if those are seen as different "button numbers" in FSUIPC. If not, then I'm afraid I have no answer for use of the hat. You'd have to find some other buttons to share their functions. Yes, you'd still need a button (or key) to set the flag so that this special programming can be conditional. You could make the condition on another button being pressed at the same time, but that's a bit more awkward to use than toggling a flag, and you still need a dedicated button or key in any case. Well, maybe it didn't get enough attention, but however they implemented it you'd still need some means of selecting between choices, so I don't see how you'd do without some use of buttons or keyboard. I don't use FS's ATC. I find Radar Contact much more satisfactory. And it certainly is a lot cheaper than a radio stack. However, neither solve the problem of needing keys or buttons to select responses. One other solution you might consider is some form of voice recognition, so you can talk to FS to execute the responses. Voice Buddy seems the latest popular add-on for this, but it looks like, for that to work well, you have to have all sound via the headset. I did for a while successfully use Microsoft's own Game Commander package, which may not be available now but wasn't so restrictive. Regards, Pete

You can program the keystrokes to your buttons in FSUIPC's Keys page. That's all described in the User Guide. If you want the hat to be ignored for this purpose at other times you'd need to then edit the FSUIPC.INI to make those keystrokes conditional. You could make the spare button used to call up the ATC window (either by control or the keyboard '@ key, whatever) also toggle a Flag which would be the condition on the hat button programming. Details for this sort of thing are in the FSUIPC Advanced Users Guide. Regards, Pete

Ah, sorry about thatit's always been that way though. At least you won't make that mistake again! :) Regards, Pete

They are actually 'original' Global.DLL values, unmapped by FSUIPC, still in the same place over several FS releases. FSUIPC doesn't stop you writing to them, but I don't think that does you much good. Have you tried? Let me know if you can make it do anything. True, though without hacking ActiveCamera I don't know how it does it. I'm not going to hack into someone else's program to provide methods to bypass their code. That's unethical as well as technically illegal. It seems to be. I added these only because someone else told me about them. Since ActiveCamera already does such a good job, I know not how, this isn't really an area I would dedicate time to. Sorry. Let's solve new problems, not try to reproduce other's solutions, eh? :wink: BTW have you tried any of the "Eyepoint ..." controls FS offers? Don't they do anything useful? Regards, Pete

Download the current version from http://www.schiratti.com/dowson, and copy the FSUIPC.DLL from the Zip to your FS Modules folder. If the version installed by Flight Deck III is earlier than 3.00 then you may need to pay for and register the later FSUIPC, depending on what permissions Flight Deck III has. Sorry, I do not know. Regards, Pete

Okay. Thanks for confirming. I'll release it generally in the morning. Regards, Pete

It's a problem of DirectX 7, as used in FS2002, which had a limitation of 2048 pixels in any dimension. Provided your window is less than 2049 pixels wide it will work. You can use full screen at 1920 x 480 (i.e. 3 x 640 x 480) -- I used that quite happily on FS2002 from October 2002, when I got my first Parhelia, until FS2004 came out. For scenery only I found 1920 x 480 perfectly acceptable. Regards, Pete

No promises, yet, but I am now looking at dedicating a 256 byte area to string replies to a series of requests for path type data. So far there are only two of this type -- yours for the path to the FS default FLT folder, and another for the path corresponding to the Traffic ID used in the TCAS tables. But there will no doubt be more needs in the future, so it may be time for a generic solution. I think if I design a system of requests + answers, allowing a variety of types of reply, I can justify the offset space needed. I shall probably re-use some global space which appears currently useless in any case, e.g. 1000 - 10FF. I'll do some further investigation into all this and get back to you some time, maybe this week, possibly with a test version. Okay? If I do this it will work with WideFS too, of course. Regards, Pete

But they'll carry over from your current FSUIPC.INI file, unless you delete that as I suggested. Do I need FSUIPC.DLL in the modules folder in order to run my licensed version of WideServer/Client? Yes, WideServer will not work without FSUIPC. WideFS is an extension to FSUIPC to make its interface work over a Network. If your FSUIPC isn't registered, then none of its joystick facilities will be operative in any case. Pete

Hmmmthere are a lot of programs using those facilities without any problems. I need to see the logging to see if there's anything out of the ordinary. Ahare you Michael Garbers? If so, it has just arrived -- I'll look at it now. [later] Hmmm. It would have been a much smaller log if you had only enabled IPC write logging -- we don't need to look at reads. Anyway, I think you have made a rather nasty mistake. See this: 119592 WRITE0 3380, 128 bytes: 48 41 4D 42 55 52 47 20 44 20 32 30 35 33 20 41 ... 119592 WRITE0 3400, 32 bytes: 00 00 00 00 00 00 00 00 00 00 00 00 ... 119592 WRITE0 3420, 8 bytes: 00 00 00 00 00 00 00 00 119592 WRITE0 3428, 16 bytes: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 119592 WRITE0 3438, 32 bytes: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... 119592 WRITE0 3458, 79 bytes: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... You appear not only to be writing to the 128 byte message area at 3380, but also another 168 bytes, right up to offset 34A7 -- a total of 296 bytes!!! (You may be doing this in one "FSUIPC_Write" -- the reason they are logged like this is that each of the offsets you see listed is mapped internally to a different place within FS). Some of the offsets in the 34xx range are known and documented in the second table in the programmers guide, but the others could do anything in FS, and probably different things in different versions. you should never write to unknown offsets or write to offsets which are known but which you don't want to change. Your write to 32FA seems odd too: 119592 WRITE0 32FA, 2 bytes: 00 03 The value 0300 is 768 in decimal, saying "display this for 768 seconds". Are you sure that's what you want? Regards, Pete

FSUIPC doesn't touch anything to do with joysticks itself unless you've asked it do. EITHER go to each of the FSUIPC Joystick pages and make sure every axis has a button that says "Set" on the left -- if it says "Reset" press it to reset FSUIPC's calibration OR, possibly easier, either delete the FSUIPC.INI file to make it start over with defaults, or edit that file and remove the joystick section completely. If the problem still exists it is definitely something else which is accessing the joystick values, possibly through FSUIPC. Regards, Pete

Is the problem the same with non-scrolling test, or with a different delay specified? The fact that the same thing happens when you have AdvDisplay intercepting the request instead is strange -- the action is completely different then. Can you turn on FSUIPC IPC write logging and show me the extract, showing what you are doing? Maybe there's some obscure problem resulting in some corruption somewhere. Regards, Pete