Pete Dowson

Sorry, FSUIPC doesn't download anything. It doesn't even connect to the Internet. FSUIPC is an interface program for other applications to talk to Flight Sim. Is "NavData 2002" a flight planner, or are you just referring to a set of data for something else? When you say "the flight planner has not been downloaded to my flight computer", what do you mean? Are you using one computer or two? FSUIPC has nothing to do with flight plans or multiple computers. If you are using a Flight Planner on another PC you need to get it to write its FS .PLN files to the FS Flights folder, presumsbly over a Network connection of some sort. They need to be saved to the folder where you store your saved flights. Perhaps the documentation for the planner will help, or the author? Regards, Pete

There's also "PAN RESET" and "PAN RESET COCKPIT" controls. I don't know if they work or what they do though. Regards, Pete

Okay. Glad you sorted it. Thanks for letting us know! Regards, Pete

Just program the button release for each of those to provide the forward view. Maybe. I think FS2004 (maybe FS2002) treats Hats specially -- in earlier versions they split it into up to 8 buttons like FSUIPC. Regards, Pete

Installing and registering what? You need to be a little more specific, really. Anyway, nothing of mine changes any FS menu entries. There are facilities in FSUIPC for applications programs to disable entire menus, like Aircraft, World and such. Those programs are the ones used in competions and they do that to prevent cheating. But even those changes are timed out -- if the application stops running and doesn't refresh its requests every few seconds the menus revert. Regards, Pete

Ah, we probably passed each other that day! :) There are apparently two ways to do this -- there are already several other threads here about it, in fact. But your best bet is to read the stuff Bob Church has written. Try the CH Hangar: http://www.ch-hangar.com Regards, Pete

If you have a program that can so easily crash or hang WideClient, I'd like to try it here, please, as I need to find out why. It is EASY to crash FS with an application, because you are allowed to write to so many places in FS which FS can get grumpy about. but WideClient should just pass things on. So, if you can supply something which will do it on my system, perhaps you could put it together with instructions. ZIP it all up and send it to me at petedowson@btconnect.com, please. I am trying to wrap things up (new WideFS and FSUIPC) for late next week, or at most the week after, if possible. Please note that one of the changes in 6.414 was to do away with the "Timeout" parameter (which defaulted to 12). It is "renamed" the ApplicationDelay, to more accurately reflect what it actually does, and the new default is 0. This was after testing many client programs and finding they all run perfectly well with no delay in WideClient before returning control to the calling application after every Process request. The only reason there was a delay in the first place was that some programs seemed to sit in such a tight loop calling FSUIPC_Process that once they were running nothing else got a look in, making the whole PC difficult to deal with. To make the same effect as the original default Timeout=12 you need to set ApplicationDelay=6 (the original was halved way back in Version 5). Aha! I see. Oh, in that case it isn't really relevant. The error is likely because there are multiple threads in WideClient (more in 6.414 than in 6.41 in fact), and the crude process killing method probably kills them in an order which upsets the thread sharing parts of WinSock. Try the ApplicationDelay change. If that makes it work in 6.414, try 6.41 again but set Timeout=0. This should make them similar as far as your program is concerned. Let me know please. Yes, very much so. Thanks. If possible, I would still like to try things here, even if the delay change does help. I would like to avoid any possibility of WideClient appearing hung -- I'd need to take steps if this is caused by very tight loops at the application/process interface. Regards, Pete

If you are a Virtual Cockpit user, I can understand that. I prefer Hats to provide simple views rather than pans, so I know where I am (I'm not using any FS panel, or at most a 2D one). I know you can make views work with "VIEW LEFT" etc etc. With a decent Hat you get all 8 main cardinal directions to view. Regards, Pete

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