Pete Dowson

You don't actually need static IP addresses to use WideFS. All you need is to tell WideClient (via the INI file) the name of the Server PC. You gave each of your PCs a name when you installed Windows -- the names are also shown in the Windows Explorer, and in WideServer's own LOG file after you've run FS with WideServer installed. By using a server name rather than an IP address you are leaving it up to Windows to translate it for you. That's fine for WideFS. The advantage of having static IP addresses is not really related at all to WideFS. It is to make FS itself, and some or all applications, run "smoother". With dynamic IP addresses, things take just a little longer whilst addresses are resolved. Additionally, the occasional enquiries, by Windows, sent to the "dynamic name server" (DNS) to convert IP addresses or vice versa, can cause noticeable stutters, especially in FS itself. These tend to manifest themselves as several stuffers over a period of perhaps a second or so, at regular intervals. This was actually a much bigger problem on Windows 98 than it is now on Windows XP, so it may not bother you at all. The complications which can arise with Internet access and fixed IP addresses are something to do with routers/modems and the way they are configured. I don't know how you access the Internet, but my ADSL modem needed some changes to operate in fixed IP address mode. I just followed all the instructions in its documentation. I can't say I understood them all, I'm afraid. Regards, Pete

But that isn't because of the fix in 6.441. The two client logs show everything good: PM: and MARCUS-OFFICE: So the only change which could have done this is your setting ApplicationDelay=6. Really, this is odd, as it should not be necessary to slow the programs down like this, at least not on Windows XP which is quite good at multi-tasking. It is as if you are using Win98 on that client. It may simply be this Application delay. It makes every access by each of the programs take AT LEAST 6 milliseconds. Maybe you can try reducing it. Experiment with it both lower and higher. The other thing you can try is increasing the new parameter "SendScanTime". This defaults to 10, limiting block send rates to 100 per second at most. You could try that a lot higher, say 50 (limiting to 20/sec). If that does no harm, leave it like that and reduce the ApplicationDelay again. Some balance of the two might help. Sorry, I cannot be more specific. The changes between 6.41 and 6.44 were tested over a reasonable period, including many interim test releases on the PM forum/Newsgroup, and things looked like they were just about optimum. There's something rather different happening somewhere on your system, but why and where I really have no idea. The "multiple connection" thing isn't important -- that is merely a result of something else. Always look at the logs and "feel" the performance. Summaries at the end like the two you have now are good -- a reasonable average frame rate and a low max Send Queue is what you want to see, and if you can smooth the stutters so much the better -- as I say, try adjustments in those two parameters, ApplicationDelay (as low as possible, preferably 0), and SendScanTime (10-100 is a reasonable maximum range to try within). Regards, Pete

This is why I suggested your user key may be invalid. It is the only reason I know of. Your program won't work on an unregistered FSUIPC at all in any case as it has no valid access key, but it (and many other client programs) will fall less predictably with a bad user key. I note you've not yet sent your KEY file to me for checking. Why not? ZIP the KEY file and send it to me at petedowson@btconnect.com. Regards, Pete

You are getting really bad blockages: Over 200 !!!! The fact that they take so long to start sounds rather like something has a memory leak somewhere, and clogging up things completely. You don't say yet whether you tried the ApplicationDelay=6, nor have I seend any logs from 6.41 for comparison -- possibly you were getting enormous Send Queues in 6.41 as well. This has probably only just come to your notrice effectively because, with the bug in WideClient, it was no longer recovering. Otherwise they'd eventually cause bad stuttering and maybe poor response. The bug was only that, once you get your huge send queue, it never recovers. The fix won't solve the problem which you have, which I would guess was also happening on 6.41. Something is certainly very wrong somewhere in your system. The log from your "MARCUS-OFFICE" PC was good and how it should be: Something is wrong on the other Client, for sure. But whether it is a program or hardware or driver I'm afraid I have no idea. That's where I would start a process of elimination. Regards, Pete

Hmmthat's a question for Enrico. Seems a bit strange not to be able to do that. Anyway, on your original problem, the one with the continuous "Send Queue over 100" failures, I found a bug in WideClient which, if such an error occurs once, it can then keep recurring forever -- the timing of the reconnection was interfering with the timing of the send queue being cleared (these things are tricky, being in different threads now). In other words, although you shouldn't have got a send queue as large as 100 in the first place, once you did get one so long, the bug in WideClient activated and made it much worse by not recovering. I attach a revised WideClient.exe (version 6.441) to be used instead of 6.44 -- the only change is this fix. I'll post this in the PM Newsgroup/Forum too. Regards, Pete WideClient6441.zip

Not if you only change the FS settings for the Slew mode axes. They are separate -- separate controls in fact. FS does not make a distinction between slew mode and flight mode, it simply only processes the flight mode controls. Regards, Pete

No, almost none of that at all! Where do you get any of that from? Just set the ClassInstance to 2, then find a way to get all your application programs which want to use FS on that PC to use classname "FS98MAIN02" instead of "FS98MAIN". The last part is the difficult part, as it may be a programming change. That is why I said you have to ask the program authors. If they don't change the program they will be trying to access the read FS, not WideClient! Pete

Where's the end of the log? It is important for you to close FS before getting the Log, please. Where did you get your FSUIPC user key from? It doesn't seem correct as far as I can tell. I can check it properly for you if you like -- ZIP it and send it to petedowson@btconnect.com. There is a FlyTHY Flight recorder program with an accredited Key, but it has the Product name "FlyTHY Flight Recorder v1.0", as requested in August 2003. The same Key cannot work with this changed. Regards, Pete

The ****** cheek of Microsoft! Other folks always blame FSUIPC first, but not MS before! Grrr! :evil: :evil: :evil: There is no problem with FSUIPC which is at all related to Geographical location. There cannot be, as it isn't doing anything which is anything to do with scenery or location. You are most likely suffering from a scenery or texture bug. If you are not using add-on scenery the most likely is the well-known seasonal textures bugs, some of which seem to still be present despite MS saying they fixed them in the FS9.1 update. Try changing to mid-Summer, see if it still happens. If so, and you are using add-on scenery, try switching off each such add-on scenery in turn. If you are not, or this doesn't help, you may have to experiment with different video settings and/or drivers. BTW I cannot support old versions of FSUIPC. The current one is 3.44. Please check the announcements at the top of the forum. Regards, Pete

Sorry, you've lost me completely. Are you saying you cannot make your buttons produce button presses which are recognisable in FSUIPC? If you can only write to FSUIPC offsets, you can still do it. You can send any controls to FSUIPC by offsets at 3110. For a KeySend you'd send the FSUIPC KeySend control ID number to 3110 after setting the KeySend parameter number to 3114. The control numbers are listed in the FSUIPC Advanced User's document. Otherwise, I'm afraid you will need to go to FSBus support, or their Forum if there is one. Regards, Pete

Ah, in that case it sounds as if the rotary is NOT an axis at all, as the rotary throttles are on, say, the Microsoft and Saitek Game Pads. Maybe it produces button presses. Try going to FSUIPC's "Buttons" option page, then operate the rotary -- see if you get a button number identified. Regards, Pete

They won't both be identified as separate. They have the same name and joined one after the other -- Wideclient avoids repeating messages else some client apps would fill the log by contant re-Opening attempts. Well, that is not that high that you should worry unduly. But this is a puzzle ... .. because changing that limit from 100 to 200 would have absolutely no effect on reducing it from over 100 to only 24. It cannot, it is only a limit on the count. Something else has changed. Yes, I agree. I have 3 x GCs, because I also have the FO's PFD/ND. But why don't you use the single copy GC with PFD/ND and EICAS, stretching the window over both monitors? Regards Pete

Okay, but performance is still being affected if the Queue is getting to 100. When you close the Client, the log will show the maximum size reached. On my 6 PC system the biggest I normally get is 10, but usually around 2, which is good. I even have 3 x GC on one of them (but nothing else on that one). Check the logs anyway. I'd like them compared between 6.41 and 6.44 to understand the differences, apart from this "reconnect" facility on high send queue sizes. Okay. When you have everything running okay you can try changing that -- I have good performance now with unlimited frame rates in FS, but this is with IPX/SPX and it has only been possible because of all the recent WideFS improvements. Okay. If the logs from 6.41 and 6.44 are signifcantly different, then this would be the most likely change which has caused it. Regards Pete

In that case simply program your button to send a KeySend parameter (1-255) -- see the drop down control lists in FSUIPC's Buttons page -- then edit the appropriate WideClient.INI file to specify which KeySend sends what keycodes. If you load the program using WideClient's "Run" or "RunReady" parameters, you can specifically direct the keycode directly to the correct program too. Please see the latest (6.44) WideFS documentation. I even list the Keycodes themselves there now! Regards, Pete

But WHERE is this software running? Which keyboard are you pressing these letters on? Normally, on the FS PC, pressing letters will do something in FS -- for example, A selects the ADF digits and W switches screen cockpit display modes. Pete

But the one Client log you sent shows: Did you forget pmSounds and AS2004? I think the latter is pretty heavy at times with its network access, and of course it is also using the Internet -- is that via the Network too? The problem with stutters is likely due to (a) multiple PM GCs competing for WideFS access. You need "UseTimer=On" in the least important of the two. and (b) on the PC with one GC the stutters are more likely due to AS2004 activities. The reconnection problem is due to this: You can stop it reconnecting on such errors (see documentation -- in particular please review the changes listed in the History section, at the end). However, that doesn't really solve the root problem -- the inability of the client to send messages to the Server is going to clobber things one way or another in any case. Please check your logs with 6.41. there may be similar things happening. Unfortunately, neither Client nor Server logs were closed, so I see no performance information. Please close FS and clients first before showing logs. So, what frame rate limit are you setting in FS2004? That could be crucial. It evidently isn't coping at present. And do try setting ApplicationDelay=6 in the Client INI files. It most certainly shouldn't be needed for any of those applications, but you need to slow their demands down to alleviate the loads. Regards, Pete

No -- it sounds like your program is checking the version number and doesn't like 3.44. Either that or you are user-registered and using an illegal user key. What does the log show? Pete

I don't really understand any of that, UNLESS, that is, your "Yaw" mode is a mistaken name for "Slew" mode? If so, then, yes, you are correct. FSUIPC does not touch slew mode at all. I have always found slew mode almost uncontrolable with axes. You are far better off leaving the axes parked and using the keyboard in slew mode. Again, assuming you are meaning slew mode, then you can only do this with FS's own calibration. Just reduce the sensitivity for the slew axes and increase the null zone. Alternately, set the sensitivity to zero and program some buttons for slew keypresses or controls. (Using recent FSUIPC additions for offset conditionals, you could actually make those buttons dual purpose, only performing this slew function if slew more is operative). Regards, Pete

Another copy of FS installed, plus WidevieW (by Lucian Napolitano) to connect them. WideFS cannot support FS windows in another PC. WideFS extends the FSUIPC interface, used by programs which interface to FS through FSUIPC, to networked PCs. If does not provide a duplicate FS for gauges and windows to interface to. If Wideclient isn't connecting to a running WideServer in FS, then you have not told WideClient, via the INI file, the Server Name or Server Node, as described in the documentation. Regards, Pete

FSUIPC does not "recognise" joystick axes as such, it only sees controls assigned in FS. Does FS see the rotary and act upon it? If not, then nor will FSUIPC. Regards, Pete

Send a letter to what, where and why? Sorry, I don't really understand the question. Pete

Not necessarily. The main change, for generally better WideFS performance, was defaulting the old "Timeout" parameter in the WideClient.ini file to 0 in the new "ApplicationDelay" parameter. To get that back the way it was in 6.41 you need to set that new parameter to 6. However, this should not be necessary -- certainly not on WinXP clients, unless it is with some badly behaved client programs. Please, anyone with this problem, new with 6.44, please tell me just two things: 1. The windows operating system in the Client PC, and 2. The application programs being run in that PC. If this parameter does look like the reason, perhaps I will have ot devise a way for it to automatically adjust upwads when unwanted reconnections occur. Please also check the WideClient logs. Can you tell me roughly how frequently the reconnections occur (the numbers on the left are in milliseconds -- just divide by 1000 for seconds). Thanks, Pete

No. The best thing to do when applying updates is to read the READ ME text which comes with them. Microsoft very clearly pointed out that you needed to update FSUIPC when applying the 9.1 update. The current supported version of FSUIPC is 3.44. Regards, Pete

Please only use the latest supported version of FSUIPC -- current is 3.44. Also, the Microsoft ReadMe for the 9.1 update very clearly pointed out you needed to update FSUIPC. Regards, Pete

No, nothing. FSUIPC is not aware of what screen mode is used in FS, and doesn't care at all because absolutely nothing it does is remotely concerned with screen modes. Sorry. It is starting to sound like a problem with your screen drivers. Regards, Pete