Pete Dowson

No. Don't fiddle with any WideFS parameters, they've all been optimised over a long time. I only still have the parameters for testing purposes. Are there two or more possible routes betweenn any of your machines? Is it daisy-chained, like a firewire link, or a star network with a hub or switch? If its a hub I'd strongly recommend changing to a switch. Have you looked at any of the WideFS logs to see if there are errors reported? UDP is not guaranteed nor checked. It's super for distributing data which is changing all the time, such as keeping gauges running (eg on Project Magenta's PFD or ND), as if some frames are missing now and then it doesn't matter so much because the next will be along soon. Even so, having said that, I have it working fine on my 8 PC Network but *only* after changing from a firewire daisy chain (400 mbps) to a standard 100 mbps switched star network. If it is too much pain using UDP and finding what the problem is, stick to TCP or even try SPX. Both of those are fully checked and "guaranteed". It is for these reasons I always avoided moving to UDP, even though FS multiplayer does use it. I only added it when I found out how easy it was to implement, so thought it worth a try! ;-) Regards, Pete

It is actually beginning to sound more to do with FSMetar's weather update methods. Your PC certainly sounds okay. Can you find a Forum where other FSMetar users gather? Maybe you can compare notes. I'm afraid I just don't know the program. Sorry. Regards, Pete

Not sure. Have you tried reading the FSUIPC manual and followng the suggestions there, especially calibration? Does you TQ6 work in FS in any case? If you have no response in FS, then there's really no point in asking FSUIPC to do anything. Please start from basics. After that, if you'd like to formulate some more specific questions, i.e. ones that can actually be answered, I'd be glad to help. But I think you need to do a little more first, please. Pete

Can you please post this on the PM support webboard. It is something which I am sure can be better answered there. All the FSUIPC "PM control" facilities are doing are toggling bits in PM-owned offsets. What happens then is totally in PM's hands. As for KeySends, that really isn't a route I'd take with any PM modules -- they are far better controlled through their offsets, and that is, in fact, how they communicate with each other in the first place. However, you say: What, here, do you mean by "lower toolbar"? I'm really not sure why you can't produce a 'C' keypress aimed at PM, but if you show me the settings I may be able to help. However, I do think it's the poorer method, by far. The most likely difficulty you have with PM ND modes is due to developments in PM -- there have been a lot of changes and unfortunately I think some of the bits originally allocated for functions no longer operate in the same way. I have not been able to keep up with all the changes that occur in PM. You may find that you need to send a value to the general "PM GC Controls" offset instead. There's an FSUIPC control for that too. If you look in the FSUIPC Advanced User's guide you will see a list of parameter values, including Boeing "classic" mode 'MAP CTR' (your 'rose') and the new ND mode 'CTR pushbutton'. I think which works will depend on how you've configured your ND in the PFD .INI file (or via the options on screen) as PM does support so many different ways of doing things now. Possibly, the only reason you've had any problems is because you'vce abandoned the 'classic' mode settings and gone to the 'new' modes. Sorry I can't help much more. I tend to get equally confused as PM changes and i cannot see what does what. But folks will have sussed it out, and they will be on the PM support web site/newsgroup, which is where I think you should be? Okay? Regards, Pete

Hmm -- stutters with no clouds? In that case I should think the problem is one of your PC. Are you running FSMetar on the same PC as FS? I assume it is getting weather from the Internet? What sort of Internet connection are you using? When I used to have a slow internet connection and a slower PC I used to dowload the whole weather (using FSMeteo) before I started flying, and then let it use that with no updating off the internet. These days I run ActiveSky on a separate PC via WideFS. Maybe it is just that your PC cannot cope? What is it? Regards, Pete

No, I never managed to find any way to hook that. I would have liked to extract the text itself to help automate responses. No, see above -- you are wanting to do what I wanted to do, but I couldn't find my way through the mass of C++ OOP class structures and Direc3D links. Yes, but they were before I added the new Window facility. All RC's menus come through offset 3380 -- programs like AdvDisplay (in FS) and ShowText (on any WideFS client) pick them up from there. You can do the same. It's just text. Regards, Pete

Ah, okay. Sorry. I got the impression you were, hence the question about it. Right! Well donesorry if I got the wrong impression! Regards, Pete

Yeah, I'm using new versions of the development tools. ;-) No you can't change it and you don't need to. Your name and email address are only used to generate your unique Key, tieing it irrevocably to you. The email address isn't used as such -- it would likely be a Street address for folks ordering by snailmail. The only ambiguity would be if someone with the same name as you got to have the same email as your old one. Regards, Pete

Yes, it can be quite a problem in FS2004 when the weather is updated, unless quite complicated precautions are taken. The authors of programs like ActiveSky and FSMeteo have gone to great pains to organise the weather updates so this either doesn't happen at all, or is rarely noticeable. It involves populating only weather stations far enough away from the aircraft (after the initial weather has been set), and also supplying the weather in batches with subsequent activation (thus only risking one stutter at most) rather than executing all the weather changes as submitted, which creates a whole series of stutters, especially when they affect clouds in view. Who's Pete Dawson? ;-) FSMetar was, I think, written for FS2002. Has it been updated to deal with FS2004 and its more complex localised weather? The only thing I can suggest on top of what has already been suggested is to reduce cloud density quite a bit, restrict them to one layer (if the option is there), and try to replace your cloud textures with the lower resolution ones available. Regards, Pete

Have you tried copying your FSUIPC files from the FS2004 modules folder to the CFS2 modules folder? I'm not sure I ever supported anything so horrible as a weapons system, mind. Pete

Kind of lost me there even though I follow the rest of what you said. Sorry, what was the problem? I'll try to spell it out. Radar Contact does NOT read keypresses. It asks FSUIPC to do it via the FSUIPC Hot Keys facilities (see offset 3210). This allows it to capture keys on the FS PC no matter which PC it is running on. The keys it so traps are configurable in its own dialogues -- there's one where you can say what key does what. Isn't that clear? You do. You can view them in RC's table and change them as you want. Of course. I told you two ways! The hard way and the easy! I even gave you the offsets to look up. Didn't you bother? :-( Well, sorry, but I don't think you could have read much of what I wrote! :-( There are TWO separate things going on here: 1. Radar Contact reads keys on the FS PC (no matter where it runs). 2. There's an FSUIPC control which will press keys on the FS PC, and you can use that contorl via Offset 3110. The first was simply clarification for you about what Radar Contact does (you weren't sure), and the second is telling you that you can make FSUIPC press keys via offset 3110. Okay? I seem to be repeating myself a lot. :-( Please just go and read about the things I mentioned. I'm not going to repeat all the documentation here. Go look up some of the offsets -- you've obviously missed a lot. And look at the list of FSUIPC controls in the Advanced Users guide. Regards, Pete

Radar Contact uses FSUIPC's Hot Key facilities to capture keypresses. It does default to using the numerics on the main keyboard, but I always reconfigure it to use Control+Shift+n combinations to avoid clashes with normal FS use -- in particular, the use of the 1-4 keys to select Engines, Exits and to control pushback direction. There are two ways to program KeyPresses into FS from an application. The original one is quite difficult but is of long-standing, and is described in offsets 3200-320B. It actually involves control of the Windows keyboard messages which FSUIPC will send for you. A much easier way was added in Version 3.60 (i.e. in April). A set of three FSUIPC controls were added to Press, Release or Press and Release keys with given shift key combinations. These are numbered 1071, 1072 and 1070 respectively, and they are listed with all the other added FSUIPC controls in the Advanced User's document. Any of the added FSUIPC controls can be actioned through offset 3110, just like FS controls, with the exception of the Offset controls -- there's no need for those as you can access offsets in any case. ;-) Regards, Pete

If VB doesn't support all the standard fields, surely it does "Comments"? It should be easy and need enough to add "FSUIPC Key=xxxxxxxxxxxx" to the end of whatever other comments you want to include. The key must be the LAST 12 characters, that's all. Is this is why you've not tried writing the Key to offset 8001? I'm afraid i can't really help with VB. Others will, I'm sure, but I think you will get on faster if you get more specific. Show some code for the other VB folks to correct for you. Regards, Pete

Please see the Access Registration document in the FSUIPC SDK. There are two automatic methods -- three if you count the two ways of including it in the Version Info. Pete

It sounds like you may have more than one action asigned somewhere. Have you checked that there are no overlaps with FS assignments? For more information for me, use the default aircraft, fly till you are close to doing the action which concerns you, THEN go to FSUIPC logging, turn on Axis and Event logging, and continue. After the problem occurs. go back to the logging and turn those options off. Close FS, and send me the Log plus your FSUIPC INI file. petedowson@btconnect.com. Regards, Pete

But that wasn't needed -- the client log showed it was finding that in any case, That's the same really - error 10060. It isn't an error WideFS detects, it is Windows which is telling me that -- I am only relaying exactly what Windows is saying when it fails. Yes, of course. The client disconnected because Windows disconnected it with that error 10060. I only suggested it was the firewall because previous times the error 10060 has been reported it turned out to be firewall. But with your latest log it does look like something happened before Windows reported the failure. If it isn't firewall problems it has to be something in the Network settings I think. Maybe one end is set differently to the other. I don't understand what may have been changed though, if you say you had it working a week ago. There's absolutely nothing changed in WideFS at the networking level. All the recent changes have been related to the Client and Server discovering each other and agreeing on a protocol without a lot of user messing or parameters. But your system is sorting all that out straight away. In the WideFS documentation there's a load of little things to check. I can only suggest going through all your Network settings and make sure that they look okay AND agree at either end. Regards, Pete

You must have updated WideFS as well, as 6.70 came out at the same time as FSUIPC 3.70. So it isn't the change to FSUIPC as you've been saying. In fact the Logs agree: The rest is only the same repeating as it keeps trying. Usually I've found that the "connection timed out" error is due to a firewall problem. The client hasn't permission to talk to the server. You don't show what you've set in your INI files, but if you've not specified a protocol in the Client and haven't expressed a "ProtocolPreferred" in the server, then the client will default to TCP. I notice you have SPX installed on the server. Were you using that before? If so, try setting "ProtocolPreferred=SPX" in the Server. I assume the Client PC also has SPX installed? For TCP or UDP you'd need to shutdown your firewall or tell it that the WideFS components are okay. Regards, Pete

Phew, how old was your previous version of FSUIPC? You missed all the super updates expecially for RC users -- by popular demand? Please do take the time to read the documentation. If you are not using Advdisplay (as per the RC documents), why not use the nice new FSUIPC window facilities? See bottom left in the first FSUIPC options screen. Please also take the time to help yourself by simply perusing the FSUIPC user documentation, especially after performing updates. Seems I waste my time trying to meet user's needs. :-( Pete

And what version number do you think that is? Please please ALWAYS quite version numbers. "Most recent" means the most recent one you happened to see, it doesn't mean anything to me. What has "installing the most recent FSUIPC" got to do with this part? What version of WideFS are you using, and what do the Logs say? What would such a utility do? I'm sorry, but the information about what is going on will be in your system. Check the FSUIPC Log, the WideServer and WideClient logs. If you've not changed WideFS at all (why not?) then perhaps you have a bad registration. I can tell from the FSUIPC Log, but it must be a complete log, from start to end with FS closed first. Keep the session short. And EXACTLY what did you do? Changed only the FSUIPC.DLL from version 3.??? to 3.??? (fill in the ?s please). You deleted nor changed any other files, at all? No renaming, no editing, no deleting, nothing? Regards, Pete

I'm not sure what you mean there, but I cannot and will not support old versions. If you ever want my help at all you first need to update to the latest version, not stick with an old one just because that's what you got from somebody else. That makes no sense. You evidently need to sort it out with them, then. Have you tried re-installing? Something may not be right with the installation. Regards, Pete

:-( I would really much prefer you to use 3.70. just remove the + signs in the comments on those three lines for now, please. Put "plus" if you like. Pete

Okay, it was easy after all. I suddenly had the bright idea of correcting those three lines in my regurgitated [Keys] section, and running FS again. It worked okay! That was the big clue! The only difference was those comments at the end of the line, after the ";". The problem is actually caused by the "+" sign in the comments, which occurs on those three lines only! Phew! The FSUIPC change which was responsible is this one (quoting from the History document): Evidently, when I added that facility (it was in version 3.60, back in April) I obviously took a rather lazy approach and didn't check things so well. I'll fix this and the correction will be in the next version -- maybe only an interim release in the Announcements above, for now. Meanwhile, please just remove the + signs in the in-line comments and you'll find it all works fine. Regards, Pete

Okay. There's definitely a bug and I'm trying to find it now. it is very odd. The log was okay, nothing I could see wrong there. The best test to see what was happening was to load your [Keys] settings into FS, add one more Key assignment IN THE DIALOG (to force a change so that it would re-write the section), then check what FSUIPC intrerpreted from your input [Keys] section. Obviously you've never used the dialogue to edit any of these, so you wouldn't have seen the results, here: There's only four differences, and one was my change. I've marked the differences clearly with rows of ##### and ???? (the last change was simply my additon to force a write). Note that all recent versions of FSUIPC retain the line numbers, and line comments. You lose the comments added to the ends of lines though. Anyway, your three problems are cause by rubbish in my tables for those three keys, which get regurgitated as: 32=66,11,128244,128244 36=75,11,640244,640196 70=67,26,25700,25600 which is very weird. I am investigating this, but I have other commitments too so I can't promise a quick result. But I'll do my best. Regards, Pete

Yes, received on 29th July at 22:34 BST and replied at 23:21 on the same day, a mere 47 minutes later! Here is what it contained: Seems you email system thinks I'm a spammer, or maybe your ISP? Regards, Pete

No attachment. But why not just include the [Keys ...] sections only here? (ARE you using aircraft-specific assignments at all? If not there will only be the one [Keys] section. Indeed. And yu say there are NO other changes excepting the 3.53/3.70 swap? Because it really sounds like something else is pinching those particular key presses. There are two ways of getting more information on this. 1) Try assigning those three non-working controls to ordinary keys, like A, B, C, temporarily. See if they work. If so it's the keys you are using originally being trapped someplace. If not, try assigning other controls to A, B, C, see if others work. If so then something somehow is getting in the way of those controls. 2) In the Logging section of the FSUIPC options you will find, on the left, places to sleect logging for "Button and Key operations", and 2Events". Select both of those, then try out your keys -- those that work, those that don't. Write down the order you do things so I can work out from the log what is going on. Regards, Pete