Pete Dowson

I think so. In FS -> from "user defined" to clear In FSUIPC -> turn off weather Hmmm .In my experience the FS weather always spontaneously changes to "user defined" when any external program tries to do anything with it. In fact it was one of the (unexpected) problems with some of the global weather filter options in FSUIPC. Regards, Pete

What problem? You've not mentioned one. Anyway, the answer is, no, FSUIPC does not use the internet. Pete

Right -- I suspect that the bits changed by the other PM ND control you used was programmed for the older mode and that's why it doesn't work with the new one. I don't think Enrico properly maintains the use of the toggle bits method those FSUIPC PM commands use, preferring things to go via the general parameter-driven interface. I think this comes about because of the complications with assorted modes and first/second officer differentiation. Regards, Pete

Right. In fact 2000 os probably long enough to cause some programs to time out the FSUIPC connection and report an error! But it does indicate that the cause of the problem is not some initial zero the program wasn't expecting. Really, I doubt if I'll be able to get anywhere -- the author needs to be involved. I can help him, of course. That is actually very strange and points to something other than WideFs entirely. It sounds like it is more to do with the installation of the software. I'm surprised it uses the registry so much. I try to avoid that as it makes things far too install dependent. No, not at all, sorry. No, thnkyou anyway. I am really far to busy. ;-) Regards, Pete

FS weather should always be "user defined" if it is being set by an external program. In fact just the act of setting it externally makes it user defined. Sorry, I don't understand what you have changed. Pete

I have no idea why it would want any in the first place! One other user of P8R wrote me that he tried to reinstall XP, WideFs and the P8R softs and that the problem was solved. The "Log=Yes" wasn't for fixing anything, only to see what the program was asking for just before it crashed! Really the author of the program should be investigating and fixing this. He seems to be shirking his duties! Pete

Well, yes, that should easily be possible but ... ... this really indicates that you have something wrong with your parameters in the WideClient INI file. No way pressing "C" should bring up the Windows taskbar. You are somehow causing a different keypress, or having it addressed to the wrong program, one minimised to the task bar. If you want me to check that you'll need to tell me what programs are running on that PC and show me your INI file. Regards, Pete

Sorry, no, I do not. It sounds like his program is assuming that all data it reads is going to be valid straightaway, but with WideFS it can be many milliseconds for some values to initialise. Before that they will read as zero. Now zero is NOT an invalid floating point value, but I guess he may be assuming that he has a non-zero value and is doing something naughty with it, like dividing it into something. I would have thought that this would give an overflow errors, and maybe it does -- but his message "invalid floating point error" may be a catch-all. (I wonder what a valid floating point error would be! ). There is a parameter in WideClient which you could conceivalby use to make the program wait longer for any fresh data it needs. This is defaulted to 500 msecs (half a second) which should be easily adequate, but perhaps it all depends upon how fast the connection is and how much other data he is requesting simultaneously. Please see the first Question and Answer in the WideFS document. Registry? Don't understand that. Or is he rferring to a list of data items he reads, in which case he might be asking you to find out which one it is by a process of elimination. You can use the extensive Logging facilities in WideClient to see what the last data his ND read was before it crashed. Use Log=Yes, as described in the documentation. Keep the session short with only the crashing program running. I can help you decode the log afterwards. Regards, Pete

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