Pete Dowson

The "latest" being the ones listed above as Supported? Version numbers are always more exact. Some folks say "latest" but actually mean the last ones they saw or downloaded, maybe months before. I have read a couple of similar stories on the PM support site. They mostly sound like some sort of graphics processing hiccough from what I've read. Ah, so you do really have "the latest". Yes, as per documentation, it is not used on the Server any more, as it automatically supports both IPX/SPX and TCP/IP clients. Seems that Katy is a little out of date -- I think this may be due to the fact that she has been moving house and probably hasn't had time to keep up to date. Please, whenever you update any of my programs, peruse the History section. For WideFS, this is right at the end of the WideFS.doc after the heading History of Recent Changes You will find, in the section "Version 6.41 includes ...", this paragraph: These changes are also listed in the "RECENT RELEASE CHANGES" announcement near the top of this Forum, which you could read instead if you wish. I think that Timeout=0 has always been recommended for PM use. It is actually a better value for most aspplications now that most folks are using Windows 2000 or XP, which multitask better than Win98/Me. In the next version of WideFS (due next week), also pre-released as 6.414 on the PM support forum, the Timeout parameter is actually deleted and instead an "ApplicationDelay" is added, which does default to 0. If there are no errors showing in the WideServer and WideClient LOG files, then there is nothing wrong in the WideFS operation. It sounds like either something slow in the Client -- though I would expect something like video processing delays to cause jerks rather than consistent slow downs -- or some sort of extensive buffering going on between Server and Client, in which case the switch might be suspect. Does it operate any buffering? Seems unlikely. Otherwise, I assume some setting in the Client's network settings? Have you tried using IPX/SPX? Regards, Pete

I'm not sure why it would want FS2002 to be on it, but possibly that's so it can install some DLLs or other parts into the FS installation. Probably you would need to install it on the FS PC then copy the SB folder onto the client PC to be run from there. I am sure there must be some good help on this at wherever SB is supported. I don't actually fly on-line myself, but I do know that many folks run SB on a client PC. Regards, Pete

What does the FSUIPC LOG (in the FS modules folder) show? Are you using a user-registered copy of FSUIPC? Possibly you are not getting a proper connection because the example program is not getting access. Please try using FSInterrogate and examining its results. Look up the offset and size and units of those in the Programmer's Guide, and read them following the methods shown and documented. But don't expect to be able to read much at all with an unregistered copy of FSUIPC. Until an unregistered FSUIPC sees a correct Access key it will only supply its version number and the FS version number. Regards, Pete

But you said earlier: The "client computer with WideFS" should mean a PC with WideClient ruunning! What does it mean to you? It is WideClient which looks like FS to the application, like Squawkbox. Run WideClient, see it connect to FS, run Squawkbox. Pete

No, sorry. I'd like to be able to intercept and interact with FS ATC, but have not found a way. I am hoping things will be better in the next version of FS. Would an on-line flyer use FS's ATC? Seems strange. And I'm not really sure what to make of "window state". Why would someone fly with FS minimised? and if it was detectable and he wanted to avoid that, why not swap programs with ALT+TAB or similar? Regards, Pete

Ghastly silence? :shock: Is this compared to the aircraft engine sounds just before you closed, or do you mean all your fans stop turning, your hard drives stop spinning, etc? If the CD is firing up it sounds like it may be related to the CD protection mechanism in FS. It's pretty nasty in my opinion, and I know it doesn't work properly on all machines/CD drives. Possibly some other process in your PC is interacting badly with it? Especially with XP SP2, which adds quite a lot of new security stuff into your system. Maybe you had an anti-virus add-on and WinXP is adding its own actions to this. Sorry, I'm really running out of possibilities here -- but from what you say now I'd guess it is more likely to be related to something outside FS than any add-in DLL and so on. Hmmm, I can't really say I know of any sound a modem makes before dialling, but maybe the phone lines do something like that where you live. Aha! I think that proves itThat strange ".tmp" process is actually part of the protection mechanism which is implanted into FS2004 to (a) check the CDRom, and (b) prevent debuggers getting inside FS's code. The latter action is why it is running all the time. It certainly seems something else in your PC is interacting badly with the FS protection. Maybe if you used the "no CD" hack, replacing the FS9.EXE file, you'd have no problems, thought really I should not suggest such a thing as it is strictly speaking a violation of Microsoft's copyright. I actually have to use it because I need to debug modules inside FS -- without it there'd be no FSUIPC or WideFS for FS2004. Regards, Pete

No. But I think you can just play waves from your program and they'll mix with FS sounds if it has focus. At least, there are several programs which achieve this with no special facilities. Regards, Pete

All I know is that you write strings with the variant "FSUIPC_WriteS". The 2-byte value at 32FA will be written from a normal FSUIPC_Write, that is just the reverse of the Reads you've already sorted out. I think the complication with strings in VB is something to do with the fact that they are passed by value not by pointer and the declaration of the Write procedure had to be changed to deal with this. Another possible complication is that your program is using Unicode or Wide Characters (16-bit character codes) instead of the standard 8-bit (single byte) ASCII which is used by FS and most standard Windows APIs. I hope someone knowing VB will jump in and help, but it might be a good idea if you showed an extract of your code and explain what you see happening at present. Don't forget to use FSUIPC's Write logging (Logging options page, IPC writes) to see what FSUIPC makes of it, as I suggested. Regards, Pete

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