Pete Dowson

Either paste the test from the Log into a message, or, for a larger file, ZIP it up. Always use ZIP in any case when sending files. Including obtaining a SimConnect log file (in the FSX Help Announcement)? Since it sounds like SimConnect is going wrong, that sounds to be the most useful. Also, since you've read all the Announcements, did you not find Version 4.156 of FSUIPC and try that? I've never heard of that before. What is left in the Add-Ons menu after it "disappears"? Sounds like some other add-on is interfering? As well as a log please tell me what else you have installed or running with FSX. Regards Pete

Please show me the WideClient.INI and LOG files, and the WideServer.LOG from the FS Modules folder. Regards Pete

Yes. This is why the official Microsoft website gives instructions to disable local Firewall and Antivirus checking, though I think that is only needed for certain such programs. Even so, the very action of these programs on such traffic does slow things down somewhat. Incidentally, I think this will be a lot better in the SP2 release. Sorry, I don't understand. When you say "returned to the desktop" do you mean FSX is crashing? What is "rejoining the flight via the task bar"? If you are using full screen mode and FS is minimising all on its own -- usually when changing views -- this was an FSX problem before SP1 but I've not heard of it happening since. Have you installed the SP1 update? Does it happen in Windowed mode too? It may well be a function of your video driver -- see if there's a later version. Well this will obviously be placing a little extra loading on the system, more perhaps depending also on your firewall settings. Does the FSUIPC4.LOG file show anything (you'll find that in the FSX Modules folder). Regards Pete

Yep, that looks perfect. Thanks! This version, or one very like it, will be released as a new User version in the coming week, probably Monday/Tues. It will be 4.16. Please update to that when it's posted. Regards Pete

Yes, the control is in the same sequence. I expect that is because, otherwise, the SELECT_ controls will actually seelct an ATC option from that window. Rightbut on the other hand I do try to maintain compatibility with FSUIPC. That's been part of its main purpose, after all. I've made one of the changes I suggested -- adding the radio select and swap controls to the list of those I intercept, so that at least they should be kept together. The ATC close thing will occur first then, in fact. I'll post it to you by email (after I've checked that I've not broken anything else) for you to test. Even if it works, I'd like to see the same logs please. Regards Pete

From the logs you sent me it looks very much like it is actually an FS2002 model. They may have updated the graphics and animations for FSX, but it seems all the gauges are very old indeed -- at least the radio ones. Received the Logs by email. Thanks. These controls: 452688 *** EVENT: Cntrl= 65585 (0x00010031), Param= 0 (0x00000000) NAV_RADIO 481106 *** EVENT: Cntrl= 65582 (0x0001002e), Param= 0 (0x00000000) COM_RADIO 481107 *** EVENT: Cntrl= 65581 (0x0001002d), Param= 0 (0x00000000) FREQUENCY_SWAP are all non-specific -- they work on the last radio selected, 1 or 2. these controls: 452751 *** EVENT: Cntrl= 65539 (0x00010003), Param= 0 (0x00000000) SELECT_2 and 357234 *** EVENT: Cntrl= 65538 (0x00010002), Param= 0 (0x00000000) SELECT_1 are supposed to select the appropriate radio first. The sorts of things this cockpit is doing here are rather archaic -- there have been proper NAV1/NAV2 and COM1/COM2 controls around since FS2004 was released and there were better ways of doing this even in FS2002. I'm now pretty certain this aircraft's radio stack is a very old design. The "SELECT_n" controls are processed by FSUIPC because these are the 1, 2, 3, 4 keys used for things like selecting engines, and Pushback direction, and FSUIPC tries to ensure they are associated with the last relevant control -- it allows, for instance, a view left or right whilst pushing back, before pressing the 1 or 2 for direction. FSUIPC certainly doesn't stop the SELECT_2 actions going through, but it is likely that, because I am intercepting them, the order of controls being sent by your panel is getting changed. Here's an example: 379478 *** EVENT: Cntrl= 65582 (0x0001002e), Param= 0 (0x00000000) COM_RADIO 379478 *** EVENT: Cntrl= 66514 (0x000103d2), Param= 0 (0x00000000) ATC_MENU_CLOSE 379478 *** EVENT: Cntrl= 65581 (0x0001002d), Param= 0 (0x00000000) FREQUENCY_SWAP 379478 *** EVENT: Cntrl= 66372 (0x00010344), Param= 0 (0x00000000) COM_STBY_RADIO_SWAP 379569 *** EVENT: Cntrl= 65539 (0x00010003), Param= 0 (0x00000000) SELECT_2 That last SELECT_2 was probably issued just after COM_RADIO. I don't understand why it is issuing both a FREQUENCY_SWAP and a COM_STBY_RADIO_SWAP -- probably only one of them actually works. I cannot do the same as I do for Engine, Exit and Pushback -- i.e. keep back the first command for a short time, waiting for the SELECT, as this would then occur AFTER the "SWAP" control, but I will experiment with either allowing the SELECT to go through even though I am saving a copy for later too (I am a bit worried about such double actions), or, more likely probably, intercepting and forwarding the SWAP controls as well. If it is only the SWAP control which is being affected here that should be okay. It is interesting that this hasn't come up before. It would happen on FSUIPC3 too, except that on that ALL controls are intercepted and processed, so the order isn't being changed. Regards Pete

You mentioned this is a Flight1 aircraft? I can't find it anywhere on their website -- I wanted to check whether it was indeed an FSUIPC user etc. The only Cardinal they have is the Dreamfleet one, which I think is an FS2002 aircraft updated for FS2004, not a specific FSX one by any means. Is that it? Where does AOPA come in -- I can't find any mentioning AOPA. I've searched several other websites and can't find any other Cardinal for sale. Is this the actual name it is listed under? I did find a freeware Cardinal on FlightSim.com, here: I'm downloading it now to check its radio stack. [LATER] No, that one is okay -- and it doesn't use FSUIPC in any case. Regards Pete

None at all. FSUIPC doesn't have anything to do with these values, and the "swap" action is normally all accomplished by FS itself, other programs don't come into it. So it sounds as if the Flight1 aircraft are using FSUIPC for something and have some errors in the offsets they are using. Are these aircraft transposed for FSX or newly written specifically for FSX? If the latter it surprises me that they are using FSUIPC at all. Can you do some logging for me so I can see what is going on? For now please remove the PFCFSX.DLL from the Modules folder (else the logging from its actions will swamp the rest). Also, please disable or temproarily remove any other add-ons which may be using FSUIPC, for the same reason. Then go into FSUIPC's Logging tab, enable logging for these options: IPC Write Button and key operations Events (non-axis) and also, on the Right-Hand side of the Logging tab, set these 4 locations for monitoring: 0350 as type U32, in hex 311E as type U32, in hex 034E as type U16, in hex 311A as type U32, in hex and check the "Normal Log" option below. Reproduce the problem (do an obvious Frequency change, different frequencies each time, for COM1, COM2, NAV1, NAV2), then close FSX, ZIP up the FSUIPC4 Log and INI file, and send to petedowson@btconnect.com. I am going on holiday next Thursday and plan to make one more FSUIPC release (4.16) before than, so if you could be quick about this, if there is anything I can do I will do it beforehand. Regards Pete

You not only have to download it (for FS9 you want FSUIPC version 3.75), you have to unzip it and place the DLL into FS's Modules folder! That's it. That's the total installation needed, and it is clearly documented that way in the User Guide. Surely that's not too much, is it? If you do that simple thing you will see "Modules" in the FS menu bar, with "FSUIPC" inside it. Pete

I don't know VBA, but can you do the programming needed in VBA? If VBA can call library routines, like those written for C programmers in the FSUIPC LIB file, then maybe you can do something by rewriting the latter as a DLL. Alternatively, check the FSUIPC Client DLL -- see viewtopic.php?f=54&t=53255 . Really, I suspect you'd first need to write a supporting package (perhaps a DLL) for your VBA scripts to call. I doubt there's anything ready-made at present. You need to do some 'real' programming before 'scripting'. Regards Pete

Networking will work across different workgroups, but the Broadcasting facility, which WideServer uses to let any clients know it is available, only operates within the same workgroup. So the easy automatic connection I programmed for WideFS needs everyone to be in the same workgroup. The alternative, as I mentioned, is to tell WideClient where the Server is, and what protocol it must use. This has to be used in any case on older versions of Windows, and it always had to be done in older versions of WideFS, before I found out about broadcasting. Glad you got it working now anyway. Regards Pete

There are no changes past or future which would change what EPICINFO5 does. EPICINFO is dependent upon FSUIPC, for sure, but all of the values it reads and writes are pretty standard things supported by FSUIPC for all client programs, and not liable to change. Regards Pete

Yes, that's quite simple -- you just need to have a button Flag toggle on and off when the VS button is pressed, and have the operation of the rotary conditional upon the flag. Yes, provided FSUIPC sees them both. Does it? Isn't the Phidgets stuff programmed directly, not as button inputs? To do the above you'd need to get everything seen in FSUIPC as button operations. Maybe you should tell me more about Phidgets? Perhaps it can be set to provide buttons inputs, or otherwise operate FSUIPC's virtual buttons offsets? Regards Pete

Luck. I just happpened to be here when it arrive. ;-) You might want to look at other separate gauge systems, then, like the "FreeFD" range. Look at http://www.flightsim.com/cgi/kds?$=mainglass2.htm I don't know if the authors ever got around to doing Airbus, though, and maybe that software isn't easily available now either. Regards Pete

No. Apart from the altimeter adjustment ("BARO" to change the QNH), and the "STD" button for setting standard pressure when flying Flight Levels, those settings are maintained and actioned within the gauges themselves. They are local to the panel, not part of FS's simulation engine and not equipped with programmable controls. This is an oversight on the part of the aircraft designer, or just a different market than that targetted. They aren't catering for fully equipped hardware cockpits. If you want full facilities like that you may want to check out Project Magenta. I can see why you are confused -- these (now long unsupported) offsets in FSUIPC relate entirely to a heads-up navigational training aid implemented in FS -- the rectangles, telegraph poles and so on were actually displayed in the sky in front of you, to show you where to fly to follow a VOR radial or ILS. Microsoft called it "EFIS", but it isn't in any way related to the glass cockpit controls you are talking about. Regards Pete

No, not that would invoke anything on a Network, let alone the Internet. Now, hang on. As I said earlier, SimConnect uses TCP/IP to talk to FSX. It does select a different random port every time you run FSX. But it is local TCP/IP traffic, on IP Address 127.0.0.1, which is the local PC. That is not Internet traffic -- it goes nowhere else at all but between SimConnect and FSX! FSUIPC4, like all other FSX add-ons using SimConnect, will cause a lot of activity on the specific TCP/IP ports SimConnect uses to talk to FSX. This is quite normal, it is not a significant overhead on performance (it is almost immeasurable, and will be improved even further in the forthcoming SP2 update for FSX). Is this all that concerns you? Did you not see that I said SimConnect uses TCP/IP, long ago? Regards Pete

I'm afraid CH users would need to answer that. I don't have any of their gear at all. Sorry. Best post a separate message with your question in the title. Before that, take a look at the sticky thread above this entitled "FSUIPC guide for CH users". Regards Pete

Okay. The answer appears to be that the Client is not receiving the Broadcasts from the Server, so it doesn't know how to contact it: The Server is actually doing the Broadcast: so the problem is in the Client PC. You said "Both PC's use Windows XP" originally, so this is ununsual -- older versions of Windows didn't support the broadcasting method. Possibly it is an out of data XP version? Or, possibly more likely, you don't have both PCs in the same Workgroup? You can check and change Workgroup names by right-clicking on "My Computer", selecting Properties then Computer Name. Alternatively, simply tell WideClient the name of the Server and the Protocol you want to use. Please refer to the WideFS User Guide (part of the documentation which came with WideFS, which you really should have looked at by now). It is all explained in the section entitled Configure your Network. It does even say "... if you find the connection is not happening, ...". Did you not read this? Regards Pete

Yes, of course. That is precisely what controls such as "Offset Byte Setbits" and "Offset Byte Clrbits" are for! I mentioned these already! That is a "word" so you'd use "Offset Word Setbits" and "Offset Word Clrbits". The bits which are set or cleared are specified by the parameter. You can change one or several bits -- the parameter is simply a mask, the sum of the bits to be changed. If you only have a bit number then that is the power of 2, for example: bit 0 = 1 bit 1 = 2 bit 2 = 4 ... bit 7 = 128 nit 8 = 256 ... bit 15 = 32768 Regards Pete

Have you tried using the fixed version I uploaded on the 15th August? I've been waiting for your confirmation that it is all okay now -- I found the bug and as far as I can see it should all work fine now. I used your original thread to notify you here. Oh dear! It sounds like you are not reading my replies to you, nor keeping an eye out for updates. Please do not, at least not until you re-visit that topic as I had expected you too and see that you should have been using the fixed, updated version now for the past week. Regards Pete

Try a process of elimination on things you have installed. but first check for a SimConnect.xml file -- if you are not using any Networked SimConnect applications you don't need one. Look in the same folder as the FSX.CFG file, i.e. (on WinXP) Documents and Settings\\Application Data\Microsoft\FSX. Don't forget, also, that FSX itself will be going onto the Internet to get weather, unless you have that option turned off by default. Regards Pete

It doesn't. The only part of FSUIPC4 which has any Network code in it is the WideServer part, which you have to Register and activate specifically. Simcnnect uses TCP/IP to talk to FSX. FSUIPC4 is a 100% Simconnect user, as a Client. Maybe you have a SimConnect.XML file which is telling SimConnect to open ports on the Internet? I don't know how you'd manage to do that, but it is absolutely nothing to do with FSUIPC. As it doesn't generate any in the first place this is not a valid question. Sorry. Maybe you have some add-on which uses FSUIPC and which does this? It probably doesn't start if FSUIPC isn't present. Check everything you've installed. Regards Pete

Do you know how the VATSIM program is setting its weather? via FSUIPC4 or directly via SimConnect? I use ActiveSky X for FSX and, as I say, I've never seen any haze or cloud flashing with that. Before that I was using Active Sky 6.5, which uses FSUIPC4, and, again, no haze flashing, but the way it changed the clouds did give a bit of cloud flashing now and then. Regards Pete

Sorry, but I see no attached files. If the files aren't too large you can simply paste their contents into your message. Otherwise, since you are having difficulties attaching things, ZIP them up and send them to me by Email attachment: petedowson@btconnect.com. Mention the thread in the accompanying message so I know what it is about. Regards Pete

Yes, but if you are not re-installing Windows too you might as well also backup your FSUIPC.KEY file. By replacing that afterwards you won't need to re-register either. (This doesn't apply if you are reinstalling or rolling back Windows too). There aren't any other files with any settings to do with FSUIPC. Regards Pete