Pete Dowson

Isn't that where I referred you in the fist place? ("...the current view mode TYPE in offset 8320."). Remember? All I know is written in the documentation. And I only know that because Matthias told me. Regards, Pete

In what way? You can control the zoom at least. Probably other things using the discoveries by Matthias Neusinger which were added to FSUIPC recently. Have you checked? Pete

I don't have any pages anywhere outside this Forum. But equally I've never actually ordered any keys for my programs so I've never seen the order acknowledgment. If it is misleading you should raise a Problem Ticket about it so it gets amended, but I must say this is the very first time I've had such a query raised, and that is after 35 months of operation. I think that is automatic, whilst the key notification has to be generated by a human being. Hence the possibility of up to 24 hours delay, depending on workload, time-of-day etc. Regards Pete

Does it? I thought they only had names. However, I've no real way of getting information on which has focus other than the current view mode TYPE in offset 8320. Will that do? Pete

I think you must be misreading something. The keys will arrive in a separate email. If they don't within 24 hours, only then should you raise a problem ticket at SimMarket. I'm fairly sure it explains this on the site. Pete

Not sure how that can ever happen merely changing aircraft, but the throttle settings are saved in the FLT files, when you save a flight. Just set them to idle and save a flight, marking it as the one to be default so it loads automatically next time. Pete

Ah, Niko Kaan's program. Yes. I know of that. Sorry, there are so many programs that I do need context to identify them. I recall that he was, in an earlier version, using the same offsets as Project Magenta, but brought out a later one which uses offsets especially reserved for him. However, I am sorry, I do not know any more than the fact that the program has a set of offsets used to control his interface to the aircraft. As far as I knew everything was explained in his documentation. All FSUIPC is doing here is acting as a postbox -- one program (presumably your Phidgets software) will be writing values to offsets, and this FSConv program will be reading them and passing them on the the aircraft code -- and vice versa. You can, of course, enable IPC read and write logging in FSUIPC to see what data is being passed back and forth, but really, for this sort of application, that's about the limit of FSUIPC provisions. Regards, Pete

No, sorry. It is not something I have ever seen, nor heard reported. Mind you, I rarely run FS with the menu bar showing in any case. It is better without, and the menu comes back automatically if you press the ALT key to get into it. Sorry. I hope someone else may be able to help. Regards Pete

Are you sure you are asking in the right place? What is "fsconv"? Pete

The modules menu is not unique to FSUIPC or AdvDisp (my only two that use it). Have you checked to see what else is in there? Anyway, why not hide the menu bar (right click on the outside view and select Hide Menu) -- it only helps slow things down in any case. Regards, Pete

For FSUIPC delete the FSUIPC.INI file. For FS2004 delete the FS9.CFG file. No sorry. Regards, Pete

It sounds like they write directly to the FSUIPC offsets, rather than act like real joysticks or send Axis controls. This is the same as an external autopilot application would do, for instance. Yes, because if this is the case the control software is writing directly to the place where the end result of these goodies end up. In other words they bypass all manipulations and write direct to FS's simulation engine. Regards, Pete

Once calibrated correctly in FSUIPC (with a stable centre zone), just use the slope selection facilities. These allow you to flatten the central response (less sensitive) whilst maing the extremes more sensitive so you can still achieve full deflection. Slopes in the opposite direction do the reverse. Please check the documentation. There is even a picture showing a typical slope with a flattened centre. Pete

There are only two possibilities. Either there are two FSUIPC's installed, possible one with a different name, or you have had FS9 running before and it hung on termination (though the window disappeared), so that, in fact, it and FSUIPC are still running when you try to start FS9 again. To check the latter, do Ctrl + Alt + Del to bring up the Task Manager, and look in the Processes list for "FS9.exe". If it is there, delete it (select it and use the button bottom right). If this is the case then you have some add-in program (DLL or Gauge) which is misbehaving -- i.e. not termininating correctly when you close FS. You'll need to find out which it is (by trial and error) and either remove it or see if a fixed update is available. Early versions of ActiveCamera for FS9 did this, but that was fixed a long time ago. Only in the FS modules folder. Make sure you don't have one in the main FS folder. Delete FSUIPC.DLL. Then you don't have one. If you are merely updating it you don't need to delete, just copy the new one into the modules folder. If you have ever renamed it, you need to find the renamed copies and delete those. Never rename it. Regards Pete

Sounds like a faulty unit. You need a hardware repair I suspect. No way will the software make pot values drift all the time. Maybe it is something easy like the pot in the unit come adrift from its mounting and twisting. BTW version 3.53 of FSUIPC is very old now and is not supported. Regards, Pete

To be more precise, the Windows joystick API supports only 32 buttons, 6 axes and 1 POV, per joystick. devices like the EPIC get around this by simulating uo to 16 joysticks. No. It would need to be re-written to use DirectInput. Sorry, I'm not going there. I don't know. I will have enough on my plate with supporting the next version of FSX. Please ask again in a year or so. ;-) Regards, Pete

Sorry, now it is you misunderstanding me . I meant HOW are you measuring those forces? What information are you providing or expecting? There are force feedback facilities in FS, but I really don't know anything about those, and from what I've heard they don't do anything for you in this case. With typical sim controls (joysticks or yokes) the trimming merely allows you to remove your hands -- the pressure on these devices is provided by springs, trying to force the control back to centre. This is not "proper trimming" the way you mean -- so in the end it all comes down to the controls you are using. How are YOU providing the force? I cannot answer questions without understanding what you are asking. The way flight sim is with normal commercially available controls, the "in trim" setting is the one which allows you to fly in the attitude you want with the controls centred -- i.e. giving zero deflection. So, for such controls you can assume it is always out of trim when the deflection has to be held at any other point. the force needed to do so depends entirely on the springs in the controls you are using. Regards, Pete

Er .. what measures force on a control? I don't understand. If you just mean the value of the axis, then of course it is available in FSUIPC -- see the list of variables in the FSUIPC SDK. Regards, Pete

Yes, I know. Sorry, the FSUIPC limits are a function of the design and won't be changed now. But FSUIPC does include the nearest 96 in the air and the most significant 96 on the ground (nearest active, rather than sleeping). I haven't come across any aplication that cannot be satisfied with that. No, sorry. It uses the same interfaces, but it isn't limited to a form of memory mapping to support the communication of this information. Yes, but active planes are more important for most purposes -- extra sleeping ones are the first to be lost off the end of FSUIPC's list. What exactly is your problem? Regards, Pete

Yes, and it is either an old one (FS98 or very early FS2000), or one written by someone not following the rules for accessing FSUIPC, because it is using the external application interface even though it is a DLL or GAUge. This is the indication of this: 5312 Client Application: "fs9" (Id=2808) 5312 C:\Program Files\Microsoft Games\Flight Simulator 9\fs9.exe 5312 Product="Microsoft Flight Simulator 2004 - A Century of Flight" 5312 Company="Microsoft Corporation" 19500 Illegal read attempt: offset 0238, size 3 [P2808] 19500Program or module not accredited for use with this unregistered FSUIPC AIBridge is loaded later and is accepted okay: 21375 Client Application: "AIBridge" (Id=156) 21375 C:\Program Files\FSFDT\AIBridge\AIBridge.exe 21391 Product="AIBridge" 21391 Company="Jose Oliveira" 21391 Key is provided in comments field 21531 Client Application: "fs9" (Id=2808) Unfortunately, because the rogue add-in uses an unsupported access method there's no way of identifying it (it "looks" as if it is FS9 itself only because that is the process in which it is running). I'm afraid there are only two ways out of this: Either (1) find out what is doing it by a process of elimination. If it is a gauge, try changing your startup flight to one of the defaults with default aircraft and see if it still happens -- if it does it will be a DLL in the Modules folder, otherwise it will be one of the Gauges in your previous default aircraft. You will need to remove it, whatever it is. OR (2) pay for an FSUIPC key and register it. The makes FSUIPC bypass all application access checks. This will work provided you only have one such badly behaved DLL or Gauge. If ever two get loaded at the same time it is likely that they will both suffer corrupted data, as they will be sharing the same data exchange memory file. Regards, Pete

As documented quite clearly, you need to re-enter the registration details if you move to another PC or re-install Windows. Keeping the KEY file is good, as you can use it to cut-and-paste into the dialogue -- it is a Text file so any editor will be able to display it. Pete

Actually the current "new versions" are 3.617 and 6.616, respectively. I'm not sure what state WideFS 6.596 was in, that's from many weeks ago. Please check the Interim Versions announcement above and keep up to date if you want to try non-Release versions. Well, I can most certainly assure you that this isn't anything to do with that change. The relationship between the flaps and the PM indications are contained in the Aircraft files declared to PM. It really does sound like you must have changed something else at the same time. Please check your flap settings in a default FS aircraft such as the 737. I think you will find they are all fine. you may need to check your PM setup with PM support. I have no idea how you are setting or calibrating your speed brake, as you give no useful information whatsoever, but most certainly if you use the axis facilities in FSUIPC they work fine. Are you assigning them to spoilers in FS? Do they work without FSUIPC in FS? Please sort things out with default aircraft and panels -- calibrate things properly -- before blaming FSUIPC or WideFS for everything. Pete

Sounds like you simply need to recalibrate in FSUIPC. Follow all the steps again -- the idle area, where it currently stops, is the "centre" which should have two distinct values. The minimum calibrated value is the bottom of the 'feathered' zone. Pete

Sorry, I cannot write the manual any simpler than I have, else I would have done, wouldn't I? :-( You most certainly do not need any "advanced informations" in any case! You only need to go to the Buttons & Switches tab, press the button (as it tells you to), select for FS control, then find the control you want in the drop-down list. The FS controls are listed by their name in FS -- the altimeter Kollsman window setting (the one you call QNH, though it isn't QNH unless you set it to be!) is mis-spelled by MS as "Kohlsman" and the two controls are "Kohlsman inc" and "Kohlsman dec". (I don't know how MS came to use that incorrect spelling of the inventor's name, but it has been that way in FS as long as I can remember). Please tel me, what is so "advanced" about that? What is wrong with the descriptions of how to do this in the User manual? Surely this is even easier than understanding anything about flying a plane? :-( Pete

Yes, but WideClient and MixW only run on PCs, so your need a PC for each such 'remote device'. Well, I'm not sure about "proprietary", but I think such a solution might be a lot easier than trying to port complex applications which are very PC dependent and far more complex than needed just for this, onto a PDA. Don't forget, for WideClient this is simply a trivial receive-data-and-pass-it-on exercise -- its main functions, in its purpose as support for FSUIPC applications, are far greater. If you throw all that away what's left would be easier to write from scratch for a PDA. Additionally, as I said, I have no idea how MixW does what it does in the first place. I'm not sure where the "PDA application guys" come into it, unless you mean someone who knows how to program PDAs. You'd need someone like that in any case. I'm very sorry, but I am simply not interested in doing any development in this line whatsoever. The tools and information are available in the FSUIPC SDK to anyone who wants to take this on, but it won't be me. I have enough on my plate to last years as it is -- and, if fact, in future the GPSout function is likely to get absorbed into the FSUIPC user utility package in any case. Regards, Pete