Pete Dowson

Yes. the easiest way really is not to program the "release" action, forcing you to press forward view when you want to return. Well, I don't know what it would be any different. The FS controls are FS controls no matter whether they are programmed in FS or FSUIPC. Maybe the PAN RATE value on applies to the PAN VIEW axis command? Yes, of course. The flexibility provided by FSUIPC is the reason for this. ALL applicable parameter lines are applies, not just the first one reached. This is how sequences of controls or keystrokes are programmed on one button action. You can't have complete flexibility without such consequences -- you have to be specific with conditions.

Great! Glad it was so easy to resolve. But I must say that it does not speak highly of that particular router -- not that you can overload it, but that it fails in such a way when you do. It should be able to fend off traffic it cannot cope with rather than apparently give up and do nothing! Regards, Pete

You either have some add-on for Windows which is wrecking the standard dialogue display units, or the system module COMCTL32.DLL you have installed is not the correct version for the version of Windows you are using. Of course, it could be the video drivers, but if they do that something is really wrong with them. If you are using full screen mode, try windowed mode (ALT + ENTER) -- if that 'fixes' it then it is probably a video driver problem. FSUIPC, like many other programs, uses standard "dialogue" units when defining the sizes of the dialogue windows and so on. The facilities used are designed to be "universal", to scale to any screen settings, resolutions, and so on. These aren't things programmed in my code, but defined in statements to Windows, data definitions called "resources" attached to the real program. In "property sheets" like the FSUIPC options (all tabbed dialogues like this are known as "property sheets"), the individual pages are normal standard dialogues and use normal standard Windows facilities. The window around them, along with the tabs above and button below are a later addition provided by this COMCTL32.DLL. I think there are some video driver packages which overwrite the standard system version of this with their own, but they don't always match. If this is what has happened, then it is possible that simply updating the video drivers may fix it. Otherwise, try reinstalling COMCTL32.DLL if you can, using the Windows System Information tools, or booting in Safe Mode. If that doesn't help I really don't know any way other than re-installing Windows -- though help from a windows expert such as Katy Pluta (in the FS2004 Forum) would be a good idea. Regards, Pete

There's no "structure" involved, but the code obviously would depend upon what language you are using. I can help with C. Others with VB. Use the FSUIPC Looging options for IPC writes to see what FSUIPC actually makes of what you are doing. Regards, Pete

That sounds very weird. What sort of sound do computers trying to connect to the internet make? That's a puzzle for me on its own. Certainly nothing of mine has anything to do with the Internet, and the fact you have reports saying IE is hanging sounds suspiciously like there's something wrong with the Windows installation. Well, I don't know anything out of that lot which will cause close down problems, though there were reports on the FS2004 Forum about FS not closing down (but not actually crashing either) with some version of some add-on. Sorry, I can't remember which one it was -- scan that forum. As far as I know there is nothing in FSUIPC that has anything to do with close down problems -- though one of the things which actually use FSUIPC may indeed have such a problem. All I can suggest is a process of elimination between all of your add-ins. Start by eliminating the add-in Modules (DLLs) in the FS Modules folders and only run default aircraft. If that's okay, add the removed DLL's one at a time, still only flying default aircraft. If it recurs you have found the culprit. If not, then try using each add-on aircraft, one per FS load, till you find it. Before all this you could take a look at the FSUIPC.LOG file (it is a plain text file and resides in the FS Modules folder). See if that indicates any errors -- show it to me if you don't understand it. Regards, Pete

Are you trying it on an aircraft with variable pitch prop? Check the FS panel throttle quadrant -- the prop control is the blue handle. Is that moving when you use the prop axis? If not, then it is most likely that FS has set the sensitivity to the minimum. It seems FS2004 is prone to that -- check Options Controls Sensitivities. Regards, Pete

FSUIPC doesn't do assignments. Use FS -- Options-Controls-Assignments. Regards, Pete

Well, assuming you set the parameters correctly, WideClient is now doing EXACTLY the same as FSUIPC. In fact that's how I modified it so quickly -- I copied the FSUIPC code for that action. Set Log=Debug in the WideClient.ini, try again, then ZIP up the WideClient.LOG file and send it to me -- you can reply to my earlier email for that. Include your WideClient.INI file please. What operating system are you using on the Client? The SendInput facility isn't available on them all. What O/S is on the Server? Regards, Pete

Please try again with FSUIPC 3.411, get the problem, close FS. Then ZIP up both the FSUIPC.LOG and FSUIPC.KEY files from the FS modules folder, and send them to me at petedowson@btconnect.com. So far there have been about 16 reported cases of similar problems, not specifically with PSS, but with all sorts of programs. Every single time I have asked for a LOG and KEY file, and of all those reports only one person ever did supply these. His problem was that he was using a counterfeit Key for FSUIPC. The others were never heard from again on this matter. The Key checking was tightened up a bit, and that is the only change that could make such a difference. I have been worried that this might affect some legitimate, correct, Keys, but so far that certainly has not been true. Please do send the files, as I am anxious to find out whether it is indeed possible to trigger the problems with a good key. Regards, Pete

WideFS didn't use SendInputuntil WideClient 6.417 that is. Didn't you get my email yet with a version 6.417 of WideClient to test? It includes a "SendInput" option. Regards, Pete

No, that's not right. It's starting to look like a faulty router, if you ask me. But that would be difficult to prove without having another to try. Of course, it could be buggy firmware in the router, so another one of the same make wouldn't prove it either. Have you checked to see if there are any updates? The only time I've ever had to re-boot (reset really -- power off, count to 10, power on) any of my Network thingies (ADSL modem/router, two wureless access points, one 8 way and two 4 way switches) was after a load of power surges/cuts during a bad storm. Even then it was only one access point and one switch needing power cycling to get them out of a coma! Anyway, I see from your log (I won't repeat bits of it here, it all looks bad) that the whole Network gets blocked, not just the one with ActiveSky on. This just shouldn't happen with decent hardware and connections. The suspicions must lie with the router and/or the wireless card in the FS PC. They are the only two parts which are common for all clients. Sorry, but I think I've reached about the limit of my knowledge here. Whilst it may well be something about the set-up in your Windows machines (FS PC?), I'm really inclined to think it may be hardware/firmware. But see if you can get more expert opinion. Some way of eliminating things would be useful. I suppose you could swap over the Wireless card/adapter from one of the Clients to the FS PC? If the Router has another Ethernet socket, perhaps you could try a hard-wired connection to the FS PC -- you'd need a cheap PCI Network Card for that. It might be worth hardwiring at least the FS PC anyway. That's the "hub" of all the activity after all. Regards, Pete

This was reported earlier and will be fixed in the next release. Meanwhile, just uncheck the "Filter" checkbox -- it was the addition of the filtering which messed the mapping up. Apologies. The next version should be available within two weeks. Regards, Pete

Er"PC that has the router on"? You mean this PC is hard-wired whilst the others are wireless? That probably isn't that relevant, except that with AS2004 getting its Internet weather through that, the hard-wiring should give you better capacity -- I assume your Nework card in that PC is 100 mbps capable, at least? Unfortunately, the Client log is only half the story. Where's the Server log? I need that to see what the Server thinks is going on. Just looking at this end for now, although all the programs are loaded up straight away it was a good 1hr 18 minutes before the first errors appeared. What might have been different then? AS2004 would be pretty busy dowloading weather and sending it to FS soon after FS was started. Four completely different errors reported by Windows, one after the otherone of which seems quite astounding. "no route to host" means that the router or whatever lost track of what was connected to it completely. After all that kerfuffle, things settled down again: until exactly the same problems occurred. This time the good part lasted 27 minutes. It seems rather odd how things can be perfect for long periods then go haywire. What is likely to be happening in those times when it does? Anything you notice? Really, there's nothing you can do in WideFS which will fix errors like this reported by Windows. You could try using the IPX/SPX protocol, which is a little more efficient and may avoid clashes with AS2004's internet access for weather. To see if those Internet accesses are causing a problem you could try running AS2004 in an off-line mode, without auto-updates. I think it can be set that way. This is just to try to identify the problem, mind. I'm not suggesting keeping it like that. You didn't say whether all these devices run at 54 mbps. Trying to squeeze AS2004 operations AND RCV31 operations through the router may "overload it", but it isn't a very good design if it isn't coping. Apert from some process of elimination, trying things one way and another, I can't really see how I can help further. I'll look at the Server LOG to see if that throws any other light on it. But you might be better seeking Network configuring help from an expert like Katy Pluta, over in the FS2004 Forum (on the PM support site). Are the other two clients also Wireless? Don't they have problems at the same or different times? Regards, Pete

What does "dropping out" actually mean? It is not exactly a tehnical term :wink: . Are there error messages on screen, do the WideClient and WideServer LOG files show anything? No, not really. There are no "tweaks" to stop a Network "dropping out". But let me see the Server and Client log files. If they are large, ZIP them up and send them to me at petedowson@btconnect.com. The router shouldn't have anything to do with it unless you are connecting to your clients via the Internet! :) . Is it acting as a Hub or a Switch, or do you have a separate Hub/Switch? What speed is the Network operating at? The router number (WAG54G) implies its a 54 Mbit G-level WiFi. Are all the individual receivers matching this? Certainly 54mbit should be enough, even for ActiveSky. And even if it is bottlenecking it should be transient, yet the term "dropping out" seems to imply a complete stop. I have USRobotics Wifi in 54mbit G-mode, but with all USR units it supports "turbo" mode which goes at 100mbit (same as my wired Network) -- or even more, apparently, if I apply firmware updates (to 125 mBit). However, the speed does drop quite a bit with distance and obstacles. Thick walls, metal cabinets etc. I wouldn't have thought your Clients were too far from your FS PC and the Access Point, though. Or are they all a long way from the Access Point, with obstacles? Regards, Pete

Sorry, I don't quite understand. are you saying it works from a Button programmed in FSUIPC to send a KeyPress to FS? Or do you just mean that the keypress works when used on the PC which is running TeamSpeak? If the former is true, then it sounds like TeamSpeak may be intercepting Windows messages specifically aimed at FS. Can this be so? Do you tell it somewhere that FS is the program you want it to work with? On a WideClient PC the substitute for FS is Wideclient itself. Perhaps if you programmed your Button to send KeySend1 on pressing and KeySend2 on release, then, in WideClient.ini added something like: KeySend1=74,16,FS98MAIN KeySend2=74,24,FS98MAIN This will press "K" and release "K" respectively, and send these to WideClient, which is using the same Class name (FS98MAIN) as FS does. Try that as it stands. If that doesn't work, try adding "PostKeys=Yes" to the WideClient.ini, too. This makes WideClient post the messages instead of "replaying" them as if from a recorder. If neither work, yet the programmed button works on the FS PC, then there must be something different in the "SendInput" system I use in FSUIPC. Wideclient doesn't use SendInput at present, but I can look at adding it -- let me know what you find please. Regards, Pete

Oh dear .... I never mentioned any "section numbers"! Please read things properly. First check that the document you are looking at is called "FSUIPC User Guide", is dated 4th November, and has Version 3.411 clearly there in big bold type. Find the Joysticks section. Scroll down until you get to the bit telling you, step-by-step. how to calibrate in FSUIPC. There's a bold sub heading "BACK TO FSUIPC" and a picture of a page in the Joysticks options tab. Below that a way the detailed calibration instructions begin by saying: and there then follows a series of numbered steps, from 1 to 9, followed by a paragraph starting with "That's it," Alternatively, just SEARCH for the world "filter". Step 8 will be the third such mention found. Really, I shouldn't have to tell folks how to find things like this. If you are using FSUIPC to calibrate you should have gone through those steps in any case. Continually coming back here and saying it isn't there at all is most tiresome and very disappointing. :( Pete

Oh dear. :( :( :cry: Try looking a little down the page(s). Item 8 in the step-by-step list discusses the filter, item 9 the Rev. If when the Prop pitch and Throttle are both on max you don't achieve the correct RPM, there's something wrong with the model. There's nothing FSUIPc can do. You need someone who knows how to make good aircraft models, which isn't me I'm afraid. Regards, Pete

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