Pete Dowson

ERhow? There's something screwy with your router then. It should be able to identify the correct PC from the correct name. And local "intranet" IP addresses are never in the same subclass as Internet ones. BTW why set the ServerName to the IP Address when there's a ServerIPaddr parameter you can set? Regards Pete

So, it was working one day, and not the next, and you've not changed anything whatsoever? Is that right? Assuming you aren't using a WideFS key with an expiry date (and very few such have been issued, only by Project Magenta I think), that really doesn't sound feasible. Something must surely have changed. I'm afraid that without any information so I couldn't even hazard a guess. Basic inforamtion like version numbers of everything is missing, and I'd need to see INI files and Logs. It would also be nice to know, please, whether you are talking about FSX or FS2004, or FS2002 or ... After you supply more information, we'll have a guess. Okay? But please do think long and hard about that "not changing anything" part. Thanks, Pete

No, I didn't know that! (Sorry, I never use FS ATC as I think it is dreadful. I am a firm Radar Contact user). Not specifically. Do the NUM pad keys also get taken? Have you tried changing the NUM lock state? What do the arrow keys do in the ATC menu anyway? Otherwise you could presumably simply assign key presses in FSUIPC4 to do the job. The keys are simply associated with the controls Ailerons left, Ailerons right, and Elev up, Elev down. You could do that via FSUIPC's Keys tab. In fact, try assigning them to the arrow keys -- there's a possibility that FSUIPC will trap them before the ATC window does. Regards Pete

I don't know "My Traffic Communicator" either. I installed My Traffic X for proper AI traffic, in correct liveries, in FSX. I really don't know any of this other stuff you are mentioning. Maybe it's part of a later version? Either way it isn't realted to my programs, FSUIPC or WideFS. Regards Pete

Sorry, this is not in any way related to anything FSUIPC offers or does. I have no idea how to solve such problems if merely saving the flight, once you have positioned the windows, doesn't work. It should work (but of course you must save the flight), so it certainly sounds like a bug -- please report it to Microsoft via tell_fs@microsoft.com. Regards Pete

No. Sorry. Pete

Sorry, no. I have never heard of "ANFS.EXE", and I have MyTraffic X. What is "My Traffic X Live"? Is that a separate product? I think you need to ask My Traffic support. Regards Pete

If it's a firewall, I can't help with firewalls -- all the information I can possibly get is there, in the point blank message from Windows: "connection refused". Maybe your two PCs are on different workgrpups or something? There's no other information I can get. If Windows refuses to allow WideClient to connect to your Server, there's not much I can do -- you need to find out why and fix it. It'll be something to do with your Netwrok settings somewhere. Sorry. Katy Pluta over in the FS2004 Forum is the person I always ask about network problems. Maybe try there? But first, check your Windows firewall settings on the Server. Disable it or explicitly allow WideClient / WideServer to talk to each other. Or maybe there's a firewall setting in the Router which needs changing? Some routers provide their own firewall protections, I think. Regards Pete

WideServer has been setting up all three possible protocols if it can for many many versions now -- TCP. UDP and SPX. It doesn't matter if one isn't installed providing they are not all missing! Your previous version of WideFS must have been MANY years old if your log was not showing an attempt to set up SPX service! Windows is refusing to allow the client connect to the Server. That's all Windows is saying. I assume it is because it is blocked by a firewall or something. Sorry, I cannot tell from here. Maybe it's that weird IP address? Or did you do that? If so, why? There's no need for private Network addresses -- those are local to your Network. Regards Pete

Okay .. what about the other questions & suggestions? But the Goflight driver is also a SimConnect client, albeit an external one I assume. Does IT stop working at the same time as FSUIPC4? Does it have a menu entry in Add-Ons? Seems odd that so far at least there's only you with this problem. We need to find out why, what makes your setup so unique. Regards Pete

No, none at all. No one has even been able to supply a log yet. There are lots of issues with it never appearing, or appearing on some sessions but not others, but how many references did you find to it actually "disappearing"? FSUIPC4 (or any other SimConnect add-on for that matter) doesn't control the Menu entries at all. SimConnect supports a request for a Menu entry to be created. SimConnect itself adds the Add-ons menu, and then places the requested entry within that. I think there's a limit of 16 that it copes with. FSUIPC4 like any other add-on would only ask for the menu to be added once, during initialisation. How it then can disappear I really don't know. It sounds like some sort of menu maintenance bug in SimConnect. Ahso you are saying it is NOT a problem with the menu, the problem is that SimConnect itself, or possibly FSUIPC4, actually stop working? LEt me search back on your messages. ... Ah, is this in connection with the GFConfg program? That's the only other reference I can find to such a problem, here from Nov 4th: That thread seemed to get nowhere after I asked you to "report it to Microsoft via tell_fs@microsoft.com with as much information as possible." I don't think MS tech support can help with FSX bugs in that sort of detail. "tell_fs" is the best reporting mechanism. As far as reported here at least this is a problem unique to your setup. Did you compare notes with others also using GF, such as 'spotlope' who did say in the same thread: Is it still happening ONLY with the GF stuff running too? Does the GF software have an Add-Ons menu entry? Maybe, if it is happening so consistently, as you say, then we can get some really good information on it to pass to MS. Best to produce a SimConnect log so I can see what is happening, and I'll report it direct as well. To do this create a file containing these lines: [simConnect] level=Verbose console=No file=\Modules\SimConnect%01u.Log file_max_index=9 and save it as Simconnect.ini in your "My Documents\flight simulator X files" folder. Then, keeping things a short as possible, reproduce the problem. close FSX, Zip up both the Simconnect log and the FSUIPC4.LOG and send them to me at petedowson@btconnect.com. Note also that there has been a problem identified with Multipayer -- if an MP mode is entered, SimConnect stops sending data to FSUIPC4. The Add-Ons menu continues though, and other things work. I programmed a work-around for that, which involved closing and re-initialising the SimConnect interface if I saw no data updates for 2 seconds or more. That's in the current release (4.04). It may not help in your case as it still depends upon getting Events from Simconnect, which in the MP case certainly do still arrive. If you can please look in the FSX Modules folder next time your problem happens, but AFTER closing down FSX. Check the FSUIPC4.Log file. See if it terminates properly (i.e. says Log closed or whatever rather than simply trails off). If the Log closes okay, then FSUIPC4 was still running. If FSUIPC4 is still running, then that suggests another work-around for now (you still need to report the problem). Maybe I should have a normal timer watchdog too -- and close/reopen SimConnect if I see no events at all for several seconds. Regards Pete

I didn't suggest to read the SDK again, but to use the tools at your disposal to check what is happening, like using FSUIPC Logging, and using a Debugger for VB. I don't understand why so many VB programmers don't seem to understand about debugging. Doesn't the VB package come with any tools for this? How do they get programs working at all? One more thought. You said you defined xResult as Dim xResult as Integer Now I always assumed an Integer on a 32-bit system was 32-bits. What you are seeing might be explained if an Integer in your compiler is only 16 bits. Both numHdg and xResult would be too small for the intermediate result. Alternatively, it would also be explained if the compiler worked backwards and divided your value by 360 before multiplying by 65536. Try forcing the order by xResult = (numHdg * 65536) / 360 I tend to always use parentheses for such things in any case as I don't wholly trust compilers! ;-) Have you any books on VB to learn more about it? It seems to me the answer is in understanding the language you use more thoroughly, and then trying to debug it correctly. I've now really helped about as much as I can I'm afraid. Regards Pete

Actually, you don't buy "4.03" but just FSUIPC4. You are entitled, and in fact requested, please, to keep up to date. The current version is 4.04 and I will be releasing 4.05 tomorrow, or possibly Friday at the latest. Interfacing to "FSUIPC 4.03" is the same as to any version of FSUIPC since version 1 for FS2000. If this "SIOC code" interfaces to FSUIPC at all, then it should certainly interface to FSUIPC4. But I am sorry, I do not know SIOC or IOCARD at all. Isn't there a Forum dealing with these products where you can get help? OR perhaps they provide technical support? How would anyone else know except whoever supplied the code? Isn't there any writing with it to explain it? Don't you know where it came from, so you can ask? Again, I am very sorry, but I have to re-iterate: I do not know IOCARD or SIOC at all. In fact I have barely heard about them. I think you need to find their technical support site or a forum which discusses cockpit building, where perhaps you may find other users of this hardware? Regards Pete

And what results did you get? You need to talk about both inputs and outputs to a problem. You ARE using a default aircraft, aren't you? If you are trying to do with with sophisticate panels like those from PMDG, Level D and PSS you will probably never get it working as they tend to use their own autpilots, not the built-in FS one. I'm afraid JD is away all week. Perhaps he will see your questions next week. Have you tried using some of the facilities in FSUIPC to see what is going on? That should be your first step. Please use the Logging -- you can Log the IPC reads, and see what you are asking FSUIPC for and what it is providing. Then, of course, there must surely be some debugging facilities in VB? I can't understand how any one ever gets a VB program working otherwise. All the code, including that inside the FSUIPC routines you are calling, is in your hands. All you need to do is find out what is wrong. You can trace it step-by-step. Regards Pete

But you showed no log of that. What does it show then? Why are you changing anything at the Client end in any case? That doesn't know or care whether you have FSX or FS9 at the Server. I'm sorry, I really can't help without information to go on. There was certainly a bug in the GPSout facilities in FSUIPC4.03 but it is fixed in FSUIPC4.04. Regards Pete

There's a list in the text, in the part using the GF166 as the example, and of course in the ful specification 9Appendix 1), under the heading "Value Types". The text is meant to be read and the examples followed, the Appendix is the reference, the definition. Regards Pete

I don't really know, but I should think it is how often the PM software sees a data update. Since that depends upon two things -- -- how often the PM software manages to read it, and -- how often WideClient gets updates from WideServer it isn't easy to say what controls it. The frame rate from WideServer is normally dependent solely on the FS frame rate, and usually equals it, or quite close. Regards Pete

360 wasn't a good example to start with, was it? That's the same as 0 (and that's what would be written). What did you get displayed? I don't know VB at all, so maybe someone else will help you, but one thing that would puzzle me is the absense of any definition of what "xResult" is. Shouldn't that be defined someplace? Pete

What would the elevator trim actually look like, displayed? Most trim gauges are simple a marker moving up and down against a scale. How would you do that in a GoFlight device? Oh, I see. You want to show it as a number from 0 to 20? No and No. Pretty much every part is wrong. 0BC2 is wrong, you missed off the X. And it's a 16-bit signed number not unsigned, so it would be S16 not U16. Please check the examples in the documentation. I don't think any of the arithmetic part is correct -- I don't know where you are reading that. And you've omitted the D... parameter to tell it how to display the result. I really don't remember much at all about GFdisplay -- I've not had any GF displays here for 18 months and din't use them for a while before that. But I'm pretty sure the facilities i provided were nowhere near as sophisticated enough to perform three arithmetic operations at all. Let me look at my own documentation a mo' ... ... well, it says there, explicitly in black and white, in relation to the *n multiplier and /n divisor facilities that "Only one of each, at most, is allowed—you have to combine multipliers and combine divisors if you need more." And there's no sign of any facility to add a number to anything anywhere. Where did you read that? The only thing I can think of is that you split the values into two parts, using a Condition -- if the value is <0 then divide by -(16384/10) or -1638.4 (I'm afraid I don't recall whether decimal places are used -- if not you'll need to approximate slighly by using -1638). Similarly if the value is >=0 divide by 1638.4 (or 1638). Please check through the documentation like I've just had to. Each part is documented. Just put them together. You'll need one condition now, and two lines for the display. Regards Pete

I wouldn't spend too much time on that. It may simply depend upon how you edit the path when you are telling FSX where to install. I've not really experimented with that part. In any case, it is a valid enough path with or without the trailing '\' character, so it isn't a bug anywhere else, only in my installer. Regards Pete

So you really send the second command so close after the original arrives that there's no Sim Time between them? Just a sort of instant-reaction. Hmmm. never thought of that. I'll see if I can use that to help improve some of my masking/inhibiting facilities. Thanks! Pete

Thanks for the information. Seems that the methods McAfee uses are indeed a major problem for FSX. I hope you report your findings via tell_fs@microsoft.com so that they can take special note of this and see what is really going on. Good flying now! Regards Pete

Right. The broadcasted mailshots used by WideServer to "announce its presence" so that clients can connect to it cannot cross Workgroups it seems. I originally thought nothing crossed workgroups (all my PCs are always on the same one), but it seems folks can get around it by specifying the ServerName and Protocol in the Wideclient.INI file -- that stops WideClient just listening for a Server and makes it try to connect to the one specified. Regards Pete

Ah, not something FSUIPC can influence on all aircraft then. You mean this is for a specific panel implementation. In that case I would have thought you could do what you liked with the flap handle? Okay, but that is something you could do in any case, if you are reading 6D11 and applying it, why not simply read an FS control parameter and apply that? Really? Just about all those with SET as well as AXIS in the name take a parameter and can therefore be assigned to an axis. Have you looked in the Drop Down for FSUIPC's Axis Assignments (for FS controls). There are over 40 for direct FSUIPC-calibrated axes, but more in the FS assignments list. Surely an aircraft likely to use your flaps gauge will never be utilising all of those for other things? At present, asnd for this particular purpose, it seems to me that either of the two choices I can see would be better. i.e. (a) using another axis assignment as mentioned above, or (b) using the current axis assignment facilities in FSUIPC, programming your flaps axis detentes in the "ranges" part of the assignment, with the actions assigned being an Offset Byte Inc in one direction, or Dec in the other (or a Set in both with the value you want in 6D11 as parameter. The latter is akin to my original suggestion, but with calibrated notch positions thus saving the need to have a new facility to send continually changing values. I'll sit on all this while you give it more thought, okay? I still don't see the need for changesyet. Regards Pete

Hi Doug, That's the procedure set up by "register_key_event_handler". I use it myself for intercepting and logging events, but I didn't know there was any way to CHANGE or STOP the events it intercepted. How's that done, please? The parameters received by the handler are simply the event and its parameter (not a pointer to them for changing), and the return is void so you cannot indicate acceptance or rejection. Is is done somehow via the PVOID userdata parameter? Thanks, Pete