Pete Dowson

That's odd, because FSUIPC doesn't really do anything that early. What version is it? Let me see the Log file. Mostly problems like that are down to something corrupt in the installation of FS, but you say it is a fresh install. Try deleting the FS9.CFG file just in case, though, so that it creates a new one and loads a default flight. Regards, Pete

Hmmmthat's not possible. Version 3.22 dates from only a few weeks ago, not 2 years. This clearly shows that the program whih is not registered is Squawkbox, and it will be because you are using an unregistered copy of FSUIPC, and haven't entered the program registration Key for Squawkbox. Please see the Freeware Keys sticky thread above. Regards, Pete

That wouldn't normally be any symptom of FSUIPC registration, but let me see the FSUIPC Log, and your FSUIPC.KEY file -- Only the [Programs] section please. Pete

The program name for EXE filesis just the name before the .EXE part, but for Gauges and DLLs it is the whole name -- i.e. in this case you would enter "A330.gau" (without the quotes). This is why the emboldened title part in my Freeware Keys list includes the .gau and .dll parts but never the .exe parts. Regards, Pete

Sorry, I'm not sure where I come into this. Is this with a specific aircraft, using FS controls via Options-Controls-Assignments, or are you using something to do with my programs? The battery and alternator switches in FS are independent, but can be ganged to the off-position in some panels I think. Please try to be more specific when you ask such questions. I have great difficulty guessing what you are trying to do and how you are trying to do it. :( Regards, Pete

Once the Key has been entered once it is remembered in the KEY file. there's no need to reenter it each time you run FS or load an aircraft. If you load an aircraft with an unregistered gauge, then register it, you should be okay if you then reload that aircraft -- but possibly, because of the way FS works, to restart the Gauge you may need to load a different aircraft in between to force FS to restart the gauge. Regards, Pete

First, bear in mind that the GF displays aren't driven by FSUIPC. For the rotaries, if you go to the Buttons page of FSUIPC's options and turn the knobs you should see FSUIPC display some joystick, button number. Each rotary has 4 such numbers, fast and slow, clockwise and counter-clockwise. For each one you can assign Keystrokes or FS Controls. I think for PMDG you have to use Keystrokes. The ones you need will be listed by PMDG someplace. Sorry, I can't help you there -- I don't use any panels at all. If when you are turning the knobs FSUIPC doesn't see them, you need to install the latest GF Config program and driver from the GoFlight website. Regards, Pete

This question was asked privately, but I am posting it and the answer here as I think it will interest others: I cannot guarantee that other folk's gauges and DLLs work -- that is their responsibility. All purchasing FSUIPC does is (a) give you access to many useful facilities and (b) saves you having to register any add-ons for FSUIPC access, other than FSUIPC itself and WideFS if you use that. As for the freeware F16.GAU key provided, it is correct and does work for some folks, as you will find from other messages here, but I believe it has a programming error in it which makes this problematic at times, depending what other things are loaded first. Unfortunately, I am still awaiting a Log file from someone who reported this, and haven't seen it yet. If it is indeed the error I think it is, I will provide a work-around for it in FSUIPC 3.30, which may be out within a week or two. If you want to wait for 3.30 and try it then, and you aren't interested in other FSUIPC facilities, then by all means do so. Regards, Pete

Sorry, but I still don't understand. These "IPX/SPX properties" -- are these in Windows or somewhere? You don't have to change any addressing in Windows, only tell Wideclient whatever details it needs so it can address your Server. For Win98SE or before you shouldn't need to do anything with addresses at all for IPX/SPX -- Win98 finds the server automatically. For Win2000 or XP you do. Not sure about WinMe. the nextwork address is usually zero unless you have more than one network, I think. Why are you using IPX/SPX? Since version 5.50 I've specialised in making TCP/IP work better. I think there are less problems with TCP/IP simply because Microsoft have paid a lot more attention to it. Regards, Pete

The answer to the last question is Yes. The idea is that you could use phase-shifted rotaries that turn on A, then B in one direction... B, then A in the other direction... but are off in the detent. Ah, yes, it is clearer now. Thanks! I will add this clarification about the rotary detent condition to the doc. Best regards, Pete

Sorry, I don't understand a word of that. Can you clarify, and ask a specific question please, with specific data if you have any? Pete

No, the list is the drop-down list of controls for assigning to buttons in FSUIPC's "Buttons" tab, or keys in FSUIPC's "Keys" tab. Please refer to the FSUIPC user guide. Documentation is there to help, honestly! Pete

Why send this twice in two separate threads? Pete

Not really, if you've been through all the hints and suggestions in the documentation. Sorry. Worse, 5.40 is dead and unsupported -- I no longer have any code that old to check into. But if you've tried everything and it is still the same, there is something badly wrong with your Network somewhere. Maybe someone who knows about Networks can help you sort it out. I've alweays found it to be a matter of trial and error -- swap the Network Cards, re-install the drivers. Try TCP/IP as well. Regards, Pete

Actually, nor do I. Sorry, I'l have to study it. I'm sure it was all clear to me when I put it in, but it was derived from a contribution from someone else. It dates back so long now I've forgotten all the logic. You are probably correct in any case. I shall delete that paragraph just in case and only reinsert it if I can think it through and it works! :wink: No at present, no. Sorry. I could probably add another bit to offset 310A to disconnect the trim -- maybe two bits, one to disconnect it totally and the other to disconnect it when the A/P is active. Then it could be controlled by the Offset Byte ToggleSetBits control, or I could add an option in the A/P operated case. You'd think that FS would do this anyway, as it effectively does for the main controls. Strange. I'll see if it can be added quickly enough to go into the impending 3.30 version, otherwise I'm afraid it'll be a few weeks. Regards, Pete

I thought of another way you can do this for yourself, right now. Just program a key or button to operate the FSUIPC offsets. Scroll down the control list and find "Offset Byte Set". Then set the offset to "x888" and the parameter to a value to select the engines you want: 1 = engine 1 2 = engine 2 4 = engine 3 8 = engine 4 and any combination, e.g. 15 = all 4 engines. This is all the HotKey facility to select all engines does. Information about FSUIPC offsets for use in the Offset controls is provided in the FSUIPC SDK. Regards, Pete

It wasn't really about offsets as such, but whether FSUIPC could offer controls for the PMDG aircraft via their SDK. This remains unsolved at present as they still have not determined their commercial strategy for licensing this access. I think they want to be able to offer the individual hobbyists and cockpit builders the facilities we want, but want to make sure that commercial cockpit equipment suppliers pay their fair share of the development costs for the high-grade autopilot code they could then utilise to help sell sophisticated gear. If all you want is access to offsets I think you can find some hacked ones around, but I'm afraid I cannot help directly at present as I have good relationship with PMDG and want to keep it that way. Sorry it isn't better news yetI have proposed to PMDG some ways where FSUIPC could be authorised to list additional controls and map special offsets for proper cockpit programming, but I have to await their decisions on how to proceed. Regards, Pete

Not sleeping well at present. Miss my better half who's in a hospital in Brum -- had a hip operation on Friday. Sunny here too! Makes a change. I've checked out what is happening in the main Flight menu (ESCape-End Flight). It is different from all the others in that when FS is there it is still sending me frame calls, so I am assuming you are out of it, back to flying. But then I find you aren't -- the 2^2 flag in 3365 is actually continually changing between being set and clear -- I can see it happening in FSInterrogate. This is the same in FS2002 and FS2004. I've fixed it by delaying the clearing of the flag by 1 second after it is set. This ensures it remains set whilst in that dialogue and clears it one second after it terminates. This will be in version 3.30, hopefully released at the end of the week if I manage to finish the documentation changes! Regards, Pete

I think this is why I was so pleased to find the indications which drive 3364 in FS2004. I couldn't find the equivalent in FS2002. The 3365 values manage to copy with menus and dialogues brought up in normal flight modes. I don't currently know how to do it at all for the initial screen. It's an odd mode which doesn't fit. I'll take a look, but I may only be able to help you in FS2004. I'll get back to you on this. Regards, Pete

Good news then. Thanks! Pete

Rain? Yes. Mostly up and down to Birmingham these last two days, visiting my wife who's having a hip replacement there. I am lucky to have my youngest daughter home for the long weekend to give me a lift and generally look after me. I'm afraid the eyesight won't be right until the other eye is operated on, maybe in three weeks if I'm lucky. As it is I'm just slowed down a lot and tire easily. If you mean this, as listed in the History document: then, as recorded there, that was in Version 3.07 back in September 2003. Have you not updated since before then? Sounds like you are using one of those so-called advanced cockpits that continually sends controls to FS and thereby interferes with such sequences. It's the same problem which causes control acceleration in some cases. FS works on simple Keyboard messages -- don't hold down a key, just press E, release it and press the engine number. Trying to press more than one key together is the hit and miss part, and it isn't needed in these cases. The E 1 2 3 4 system works in the same way as the pushback (Shift+P then, later, a 1 or 2 for direction of turn). Registry? FSUIPC doesn't deal in registry settings. I've had no other reports of problems selecting one engine. The problems come with multiple selections, and then really only with the 3-engined aircraft. I can note your request for some future release (too late for 3.30), but please check out exactly what you are doing, becase it sounds a bit wrong in any case. I don't like adding features which aren't really needed. Let me know more details after experimenting with all the 'correct' methods. As it is, of course, you can assign a Button in FS to produce a keystroke. To produce two (E the 1 or E then 2) you'fd need to edit the INI file (see Advanced Users Guide), but that may be worth trying too. Regards, Pete

Thanks! They are perfect, so this proves that the problem you had in WideFS is avoided by the RestartTime=0 setting. This means I can go ahead with the 'proper' fix. If you've still got some stutters I'm afraid you need to look elsewhere. There's not a single glitch shown in the WideFS logs, though, please, next time, be sure to close everythnig down -- the performance figures I get from the closing lines in each log often tell interesting stories! :wink: Regards, Pete

I've got no records, no documentation, nothing, for 5.20. That is from 2002 and I only keep stuff for one year. 5.20 was the last one with minimal support for TCP//IP. The version after that, 5.40, was the first truly optimised for TCP/IP operations. I really cannot derive anything from such a comparison, sorry. If you are happy with that mixed setup. continue with it, but I would have thought it better to find out what was wrong with your system. Since 5.40 the Network code has been almost 100% stable and unchanging, right through to now, with 6.23 about to be released. The changes over these past 18 months have either been purely for FS2004 additions, or for button polling, improved logging, and little parameter tweaks. Ouch. Something is really screwy on your system somewhere then, as it does nothing -- it has nothing to do -- till you run an application. Old versions didn't use to connect when no applications are running, so there's not a comparison in that way. Anyway, as I always say, I cannot even make a guess with no information. Regards, Pete

I suppose PM's not talking much before then. Regards, Pete

From your private message: The logs don't actually show a lot wrong -- something serious, though, certainly. Your CDU PC was evidently ready and waiting to connect for a long time (2268 seconds) before FS was loaded and ready on the Server. Really after that there was only one error detected at that end: 2580260 Note: Send() request depth is over 100! which occurred 293 seconds later. This problem indicates some blockage at the Server end, possible you were in a menu or doing something else in FS other than flying? Or, more likely, this is coincident with the problems shown in the Server Log (below). However, because everything evidently starts at wildly different times it is difficult to tie together. And you didn't close the CDU client before Zipping up the Log, so I can't see the performance analysis at the end. In the Client INI file there's nothing wrong, though you could probably run PM's CDU okay with Timeout=0 set. It would give it a little more time, especially as there's nothing else running on that PC. In the Server end, these errors are bad. You shouldn't get many if any of these: 702687 Retried 314 times: sends blocked for over 5 secs! (0 of 337 sent), Error=10035 (skt=8880) 707703 Retried 620 times: sends blocked for over 5 secs! (0 of 348 sent), Error=10035 (skt=8880) 708844 Send ok but needed 693 attempts! (370 of 370 sent) (skt=8880) 712234 Send ok but needed 75 attempts! (353 of 353 sent) (skt=8880) 716375 Send ok but needed 86 attempts! (333 of 333 sent) (skt=8880) 719734 Send ok but needed 65 attempts! (367 of 367 sent) (skt=8880) 723609 Send ok but needed 59 attempts! (329 of 329 sent) (skt=8880) 726875 Send ok but needed 55 attempts! (336 of 336 sent) (skt=8880) 730703 Send ok but needed 38 attempts! (330 of 330 sent) (skt=8880) 739891 Send ok but needed 6 attempts! (311 of 311 sent) (skt=8880) 743500 Send ok but needed 15 attempts! (308 of 308 sent) (skt=8880) 746406 Send ok but needed 27 attempts! (346 of 346 sent) (skt=8880) 750266 Send ok but needed 59 attempts! (339 of 339 sent) (skt=8880) 753656 Send ok but needed 68 attempts! (337 of 337 sent) (skt=8880) 758000 Send ok but needed 85 attempts! (349 of 349 sent) (skt=8880) 761328 Send ok but needed 57 attempts! (333 of 333 sent) (skt=8880) 765328 Send ok but needed 71 attempts! (333 of 333 sent) (skt=8880) 768391 Send ok but needed 35 attempts! (332 of 332 sent) (skt=8880) 772062 Send ok but needed 32 attempts! (337 of 337 sent) (skt=8880) 774922 Send ok but needed 26 attempts! (343 of 343 sent) (skt=8880) 778500 Send ok but needed 44 attempts! (338 of 338 sent) (skt=8880) 781375 Send ok but needed 42 attempts! (329 of 329 sent) (skt=8880) 785062 Send ok but needed 48 attempts! (342 of 342 sent) (skt=8880) 787984 Send ok but needed 27 attempts! (344 of 344 sent) (skt=8880) 791828 Send ok but needed 45 attempts! (337 of 337 sent) (skt=8880) 794859 Send ok but needed 30 attempts! (327 of 327 sent) (skt=8880) 798453 Send ok but needed 10 attempts! (283 of 283 sent) (skt=8880) 818766 Send ok but needed 28 attempts! (308 of 308 sent) (skt=8880) 822234 Send ok but needed 30 attempts! (302 of 302 sent) (skt=8880) 826641 Send ok but needed 43 attempts! (320 of 320 sent) (skt=8880) All the above occurred in a period of just 2 minutes! Interestingly larger gap here, no problems for 3 minutes 37 secs! 1041547 Send ok but needed 18 attempts! (309 of 309 sent) (skt=8880) 1045156 Send ok but needed 19 attempts! (307 of 307 sent) (skt=8880) 1049328 Send ok but needed 30 attempts! (291 of 291 sent) (skt=8880) 1064891 Send ok but needed 7 attempts! (171 of 171 sent) (skt=8880) 1068953 Send ok but needed 31 attempts! (276 of 276 sent) (skt=8880) 1073516 Send ok but needed 21 attempts! (276 of 276 sent) (skt=8880) 1077531 Send ok but needed 23 attempts! (250 of 250 sent) (skt=8880) 1082453 Send ok but needed 51 attempts! (289 of 289 sent) (skt=8880) 1086719 Send ok but needed 49 attempts! (285 of 285 sent) (skt=8880) 1091703 Send ok but needed 62 attempts! (294 of 294 sent) (skt=8880) 1096094 Send ok but needed 61 attempts! (312 of 312 sent) (skt=8880) 1101266 Send ok but needed 69 attempts! (303 of 303 sent) (skt=8880) 1105766 Send ok but needed 71 attempts! (316 of 316 sent) (skt=8880) 1110875 Send ok but needed 72 attempts! (270 of 270 sent) (skt=8880) 1140781 Send ok but needed 35 attempts! (260 of 260 sent) (skt=8880) 1149016 Retried 321 times: sends blocked for over 5 secs! (0 of 321 sent), Error=10035 (skt=8880) 1149297 Send ok but needed 339 attempts! (319 of 319 sent) (skt=8880) 1154766 Send ok but needed 79 attempts! (307 of 307 sent) (skt=8880) 1159094 Send ok but needed 79 attempts! (293 of 293 sent) (skt=8880) 1164812 Send ok but needed 82 attempts! (278 of 278 sent) (skt=8880) 1201187 Send ok but needed 94 attempts! (287 of 287 sent) (skt=8880) The only error being reported here is that Windows is saying it cannot send the frame because it would be "blocked" (i.e. cause FS to stop awaiting the frame to be transmitted). I cannot allow that, so I count the problem and retry later -- as you can see, eventually it is transmitting but it is taking many retries each time. The only times I have seen this sort of error is when there is something actually wrong, but what that would be, I'm sorry I don't know. In your message you explain that the PM CDU is getting intpo a slow update situation. I think the sorts of things you are talking about happening on the CDU are not actually done through WideFS, they are file system accesses using Windows sharing. It looks like, whatever the CDU is doing, it is somehow conspiring either with or against WideFS to block that route. Sorry. I think maybe someone like Katy Pluta is needed here, to try to resolve why the Network is having these difficulties. I don't know enough about networks to have any other suggestions -- though please set Timeout=0 as suggested above, in case that helps a wee bit. One thing, though. In your WideServer.INI file you have: AutoUpdateTime=15 RestartTime=10 The default for the Auto Update, of 13, was arrived at after lots of experiments and I think you should stick to that unless you have good reason to change it. I would certainly never use a larger value than the default. For reasons recently discovered, please for now set the RestartTime to 0, or maybe 30. In the next version of WideFS you can leave it to default. I can't see any sign in the logs that this had any affect on things though. Regards, Pete