Pete Dowson

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

I am off-line from now for a few days -- guests and relatives to attend to. The phenomenon of multiple connections is fully explained in the documentation. Please take a look. Sorry, but I don't ever have time to go browsing in assorted websites. If you want to show me something do so here, or ask where to send attachments. but please don't bother for at least 3-4 days. Your best bet at present is to check the documentation. It does encompass just about everything I know about Networks. After that you need Network expert help, or do as I do -- trial and error, replacing things, reinstalling things, and so on. One thing is reasonably certain, you have a problem on a client PC. Regards, Pete

Calibration in FSUIPC allows setting any throttle position, not simply idle and max. Please simply calibrate for the maximum range you need, in any cirumstance, then have some notches or marks for intermediate positions. You don't really need FSUIPC just for this in any case. Regards, Pete