Pete Dowson

They are totally unrealted and do completely different things. I think you are mixing WideFS up with WidevieW. Certainly, from what I know, MaxiVista may be an alternative to WidevieW. I have no idea what the performance is like though. If you are interested in WideFS, just download it and read the documentation. See if it does anything you want. Regards, Pete

That's because FS knows nothing about your j10b0 flag, so it does not change, and FSUIPC cannot stop FS interrogating the buttons and so on on the joysticks. It has no way to intercept these. You either have to program it in FS or in FSUIPC, not both. So you would need to de-assign the Hat functions in FS and use whatever similar effecting FS controls you can find in the FS controls drop-down list -- check those named PAN something. Then make those conditional on the j10b0 flag not being set. Regards, Pete

Joystick settings don't affect anything else, and vice versa. They are independent. In fact each axis calibration in the Joystick section is separately enabled -- the button top left in each section reads "Set" when it isn't doing anything, and "Reset" when it is -- i.e. it tells you what happens when you press it. Alternatively, if you've done a lot of messing in the Joysticks section and you want to get rid of it all, you close FS, edit the FSUIPC.INI file and delete the entire Joystick calibration section there. Regards, Pete

Yes, there are step-by-step instructions on calibrating in FSUIPC -- in the supplied user documentation, of all places. :wink: I wouldn't reduce the sensitivity in FS too much -- in fact keep it at maximum, and the null zone to minimum. Then calibrate in FSUIPC, following the instruction step-by-step. Check that it's all okay (it may still be "touchy", but this will depend a lot on flight models used). THEN apply one of the slopes -- FSUIPC offers a set of response curves which allows you to reduce the sensitivity near the centre and increase it at the extremes to compensate. Please check the documentation I provide. It takes many hours to produce and it does embody all this sort of stuff. I really shouldn't have to reprint any of it here. Regards, Pete

You misunderstood me. I know it can use the keyboard, but from what everyone has told me this is not "normal" in the sense that it gets the keys from normal Windows keyboard messages, such as those WideClient can produce. I think it must be using direct keyboard access -- interrogating keys in real time, not processing them via the message queue. I know what you want, that's what I replied to. (BTW I thought your "joke" (ha-ha) was a misprint last time. We spell and pronounce it "yoke"). What's a specific PTT program? I did not mention any specific program. As far as I know, it is not possible to do what you want at present with TeamSpeak, only with RW and AVC. Please press your requirements on the TeamSpeak authors. I can accommodate anything reasonable, but there is no reasonable solution at present. Regards, Pete

Actually, that's 1 out. And al that stuff is only because EPIC (still?) doesn't support negative numbers. The binary representaion of -1 in 16-bit hex is FFFF (i.e. all ones). As an unsigned 16-bit number this looks like decumal 65535. So -1 is 65535. Your -100 would be 65436. So your formula all in 16 bits should be (65535 - (value)) + 1. This is something you need to take up with the EPIC developers (Ralph Robinson should be able to help). I don't even remember there being a "~" function when I used EPIC. Regards, Pete

Roger Wilco and AVC are easy. So far TeamSpeak has not proven possible. I have asked users if they can get TeamSpeak to add facilities for PTT to be controlled from another program or via normal keypresses, but nothing has happened in months. Both RW and AVC provide registered messages to allow PTT on and PTT off, and these can be driven either directly from FSUIPC (using the PTT on/off controls it adds), or through WideFS using the KeySend facilities -- specific examples are given for this already. But at present TeamSpeak is not amenable to any treatment I can dish out with any of my programs. It does not appear to accept keyboard messages sent to it normally. I assume it captures true keyboard events only. Regards, Pete

Sorry, I don't know any such panel, and really FSUIPC is not involved in panels much at all. What Key are you trying to use? I don't know of any Key I've suggested for a "panel" as such, as panels don't use keys for themselves. Keys are used by programs such as EXE, DLL and GAU types. Of these GAU (gauges) feature in panels, but most panels may have many of them. Perhaps there is a gauge in this panel you are trying which uses FSUIPC, and that needs a Key? Have a look at the FSUIPC.LOG file, it should tell you what is wrong there if, indeed, it is anything to do with FSUIPC access at all. Regards, Pete

Good. It'll be in the next official user release, which I was aiming for early next week but now looks though it may be a bit later (due to other things, not this). Please remember to update to an official release when it is available. Regards, Pete

I'm not sure what you mean by that. I use FSRealTime for that function -- I run it on a Client. When it first sets the time correctly it certainly makes FS reload scenery -- any change of more than a short time does that. But it doesn't crash anything. What exactly are you doing to "synchronise FS time with local time"? I suggested a process of elimination by moving things around, to see if it related to that Client or is more something to do with an application. I also couldn't make sense of some of the things you said in your initial report, and I asked you about them. As I pointed out, the Log you provided didn't match what you were saying. I haven't been able to make use of anything you've offered here I'm afraid. Are you simply going to retreat to older versions with no further explanation of what you were talking about? Anyway, you do what you have to do, but, I'm sorry, but I will not be supporting old versions. Regards, Pete

I'm sending an interim test version of FSUIPC for you to try. It seems to work well here -- I zero the elevator on AP Alt engagement and disengagement. Probably only the latter was needed, but I think it helps make sure the AP doesn't use stupid trim settings too. Let me know how you get on please. Check the "Technical" options page for the new feature. It's only there for FS2004 -- but the facility is usable on earlier versions. For those you have to edit the FSUIPC.INI file (ZeroElevForAPAlt=Yes). Regards, Pete

Great! I'm glad you resolved it! Regards, Pete

I think that .tmp thing is part of the protection system -- same as the CD-being-there check, but it also watches for Debuggers and the like. You don't get that process with the "no CD" hack. I think that's pretty normal anyway. In fact FS is generally famous for soaking up all the idle time -- it sounds like you have a P4 processor with hyperthreading? I think FS only uses one of the virtual processors, hence the 50%. Did the FSUIPC Log file show anything more by then? By the sound of it, you also need to check other processes running on your PC. I'm sure there have been others with similar problems which were resolved by removing or killing some other process, but I can't find the references now. Sorry. Regards, Pete

Aha! You should have said soyes, in that case you are probably correct. It isn't something I've ever investigated. Sorry. How would you expect FSUIPC to deal with the problem when you disengage the A/P? By experiment here it looks as if the keyboard-set elevator value is retained when the A/P takes over. And in fact it seems that the keyboard elevator is still effective with A/P ALT control operating -- all that happens is that as you change the elevator via the 2/8 keys, the A/P compensates by changing the trim. The problem seems to be that it doesn't zero the elevator (as a joystick centering would). Maybe if there were an option in FSUIPC to zero the elevator position automatically when A/P is engaged or disengaged, this would help? I'll try that here. Regards Pete

Odd. Others have certainly included pictures on occasion. ZIP it and attach it to an email to me at petedowson@btconnect.com. Did you try in Windowed mode and look to see if there was an error message? Regards, Pete

Pardon? I certainly wasn't!It wasn't me using !!!!!!!!!!!!!!!!!! :o This is with FS calibration only? What doesn't work correctly about them? That only happens if you elect to calibrate in FSUIPC. If you want them to be the same, simply press the button labelled "Reset", then FSUIPC will leave them entirely alone. Surely you must understand that if you are asking FSUIPC to do something with the values, the OUT values are rarely if ever going to match the IN values -- it would have to do absolutely nothing at all to achieve that! You can easily make it do that by not using it -- please press "Reset", or close FS and delete the Joystick Calibration section in the FSUIPC.INI file (you'll find that in the FS Modules folder). Well, what yould you want there? I don't understand what you are expecting to see. How do you think it should work, and why? (Suggestions need to be made to Microsoft though, not so much me). Ah, I think the way the TQ6 works, you MUST have reverse set -- best to do that in the FS assignments. This is true whether or not you use FSUIPC -- you really do need to get things more or less right in FS first. Also check that FS's sensitivities are set at maximum if you calibrate in FSUIPC, otherwise you lose some scalable range. FS2004 in particular seems to have a temdency to whack that setting down to minimum! On the TQ6 I think you'll find that flaps and spoilers both need Reverse. But it would have been better to explain what you were seeing that to just insert loads of exclamation marks, don't you think? They don't exactly explain much. :wink: Hmmmthat's odd. Please list the values you see (IN/OUT) and the values you've calibrated for Min and Max. What happens if you don't calibrate in FSUIPC? I don't know how GoFlight did that then -- are you using their driver? Maybe that sorts it all out. Maybe all your problems are because you actually have two programs trying to sort out the same axes? I don't have any GoFlight drivers or DLLs installed. Check your GoFlight documentation, or the website, or ask GoFlight support. Well, FSUIPC isn't designed to work that way at all. You should be setting a stable minimum and a stable maximum, and that's it, for flaps anyway. It certainly is a miracle as FSUIPC has no knowledge of any physical notches on your device, and there's nothing specifically programmed in FSUIPC for any particular make of axis. Well, certainly try it with the axis properly reversed in FS, and make sure the sensitivity is at maximum. Then try it without calibrating in FSUIPC at all. Then try calibrating properly in FSUIPC, with stable minimum and maximum values. After that I'm agraid it's got to be GoFlight support. I really have no idea how they expect their flaps lever to work. Their products are certainly not designed to be dependent upon a user registered FSUIPC installation. As I said, I do have them working here okay (with the 9 detentes of the 737 and no GF drivers at all), but the large central zone (yes, with -7) is annoying. Regards, Pete

It certainly sounds like something related to the 800/900 upgrade is writing to the FSUIPC area controlling the display. There's absolutely nothing I can do without information. I've been asking for logs. if it is easy to reproduce, then go into FSUIPC options, turn on IPC write logging, then reproduce the problem. Close FS, ZIP up the FSUIPC.LOG (from the FS Modules folder and send it to me at petedowson@btconnect.com. It seems several folks can reproduce this problem but no one has yet provided any information. Once i can identify what is doing it, i can tackle the relevant author. What "dialog box". Do you mean the AdvDisplay window? That sort of problem is related to how it is docked. Check the PANEL.CFG, or try locking it instead. I don't have anything to do ewith any green band. that's FS. close it by right clicking it and closing. Some parts of the PMDG install are DLLs, not gauges, and are running all the time. Try removing the PMDGoptions.DLL. I don't know FS2Crew -- is that using the text display facility too? They may be clashing. Regards, Pete

It still hasn't arrived. From what you say it certainly sounds like something is writing to the display control area in FSDUIPC. The log would tell me thast. Please check you sent it to the right email address, the one I gave you. I also sent you an email yesterday, saying the same thing. Still no reply yet. Regards, Pete

Needn't worry about the video stuff, you can put the original FS9.CFG back now. It's best to run FS in Windowed mode until we resolve this in any case -- you never know, there may actually be an error message box awaiting your attention on the Windows screen. Try it and see. So, what add-ins have you got installed? Let's look at the Modules folder. BTW I'll be offline now till tomorrow, later on (maybe evening UK time). Seeing the eye surgeon first thing, and he uses those drops which dilate the eyes. I won't be able to use the PC most of the day. Regards, Pete

Hmmm. The log shows nothing is trying to access or use FS by then. Are you loading this ATR aircraft from the initial menu (the hang is occurring when it is loading the UI generated flight.flt). Try one of the default aircraft. Try deleting (or rather, temporarily removing) your FS9.CFG file (it's in the Documents and Settings\\Application Data\Microsoft\FS9 folder). FS will build another and start with default flight settings. There are some other things which seem to hang when FS is present too -- the first FS9 version of FSNav, for example. That was fixed fairly quickly. It doesn't even use FSUIPC, but does some checks which don't work when FSUIPC is present. If loading a default aircraft doesn't help, and you are sure it isn't FSNav, check your Modules folder, see what other add-ins there are there. Let me know. Regards, Pete

You aren't trying to use FSUIPC to calibrate the flaps lever into any plastic notches on the device, are you? FSUIPC can't do that. It just takes the complete range of the flaps lever and divides it across the appropriate number of flap detentes for the current aircraft. Just make sure that you can get to the minimum (OUT = -16383) when the lever is full forward (flaps up), and the maximum -- eg 16369 on a 9-detente aircraft, like the 737). I don't know what you are complaining about with all those !!!!!!!!!!!!!!!!!!!!! -- what's that about? The range of control values FSD needs is max -16383 flaps up to +16383 flaps down, but FSUIPC converts the continuous range into increments, to avoid stupid positions mid-detente, or situations where FS is wavering between two of them because of slight jitter. With the 737, for example, the increment between detents, as shown in FSUIPC's options (the position BELOW the flaps calibration) is 2047. This is actually only half the increment now needed, as it derives from the internal programmable interface value of the flaps control. Using 4094 gives: Flaps 0 = -16383 Flaps 1 = -12289 Flaps 2 = -8195 Flaps 5 = -4101 Flaps 10 = -7 Flaps 15 = 4087 Flaps 25 = 8181 Flaps 30 = 12275 Flaps 40 = 16369 These values work well with the 737. Likewise, you will get different values and different numbers of detentes for each aircraft. Well, as you can surely see, around half of the values will be negative. Why is this surprising? These are the values required by FS for that axis. The only thing I find odd and rather annoying with the TQ6 is that it has a very non-linear action -- the values seem to change too fast at either ends, and the centre area (where you get your -7, as do I) is very large. I assume this is more to do with the pots being used. That sounds good and exactly what should be happening. Again, why all those !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ????????????????????? That sounds good too. Again, the input FS wants on that axis is -16383 to +16383. Why is all this so amazing for you, so much so that you overuse exclamation marks to the extreme? I'm not sure how GoFlight intended the flaps lever to be used with the optional notches fitted -- I couldn't work out how to put them on in any case. To fit the calibration on a notch by notch basis would be quite a big job for FSUIPC. I did manage to do it in my PFC driver, but that has a specific known axis input to deal with. Regards, Pete

What version of FSUIPC? There was a bug affecting spoilers in version 3.40. You need 3.411, the current version. See the release notes at the top of the Forum. Regards, Pete

Test them in the air. FS seems to want to auto-deploy them if you use them on the ground. Why not try calibrating them in FSUIPC? As for linearity, it sounds like you have two different types of pot. Regards, Pete

Erno, I think that's wrong. As the A/P is actually managing to keep a correct attitude for whatever it is being told to do, the aircraft is stable at that pitch with that trim -- assuming your elevator controls are doing nothing, i.e. centred or left wherever you put them. When you then disengage the A/P the aircraft should, by definition, remain stable at that attitude. That certainly is the case here, for all default aircraft. In fact one "cheating" way of getting an aircraft into perfect trim in FS has always been to engage the A/P, let it trim, then disengage it. As far as i know that hasn't changed for many many versions. Of course it is not realistic for it to use trim in this way -- a true autopilot pitch control would operate the elevator AND then trim out the forces, just like the pilot would. But this would be no good at all for FS, because it would, indeed have the result you say -- with the elevator non-centred for a particular pitch, when the A/P is disconnected, the user's auto-centred elevator axis would immediately cause the aircraft to be out of trim. In other words, Microsoft have done it the way they've done it specifically to avoid the problem you say you've got! No, that would actually be rather catastrophic, except in very sophisticated cockpits where some sort of motor control can move your elevator axis for you. As I said, the way it is is not realistic, but is done to ensure you do NOT get the very problem you seem to think you get! Think about it. If in a climb it pulled its elevator stick back and trimmed out, as it should, and you then disengage it and let your *centred* elevator suddenly take control, you'd be diving before you know it! I really do not know how you are achieving that -- I cannot make it do it here, and when you think it though you must surely see that what you are saying isn't logical. As long as the A/P always uses trim only, the centred (or original, if not centred) position of your joystick should be correct when you release the A/P Regards, Pete

Erno, I think that's wrong. As the A/P is actually managing to keep a correct attitude for whatever it is being told to do, the aircraft is stable at that pitch with that trim -- assuming your elevator controls are doing nothing, i.e. centred or left wherever you put them. When you then disengage the A/P the aircraft should, by definition, remain stable at that attitude. That certainly is the case here, for all default aircraft. In fact one "cheating" way of getting an aircraft into perfect trim in FS has always been to engage the A/P, let it trim, then disengage it. As far as i know that hasn't changed for many many versions. Of course it is not realistic for it to use trim in this way -- a true autopilot pitch control would operate the elevator AND then trim out the forces, just like the pilot would. But this would be no good at all for FS, because it would, indeed have the result you say -- with the elevator non-centred for a particular pitch, when the A/P is disconnected, the user's auto-centred elevator axis would immediately cause the aircraft to be out of trim. In other words, Microsoft have done it the way they've done it specifically to avoid the problem you say you've got! No, that would actually be rather catastrophic, except in very sophisticated cockpits where some sort of motor control can move your elevator axis for you. As I said, the way it is is not realistic, but is done to ensure you do NOT get the very problem you seem to think you get! Think about it. If in a climb it pulled its elevator stick back and trimmed out, as it should, and you then disengage it and let your *centred* elevator suddenly take control, you'd be diving before you know it! I really do not know how you are achieving that -- I cannot make it do it here, and when you think it though you must surely see that what you are saying isn't logical. As long as the A/P always uses trim only, the centred (or original, if not centred) position of your joystick should be correct when you release the A/P. Regards, Pete