Pete Dowson

No idea. I'm amazed that they can be set to operate digitally at all. But doesn't the other posting, above, by GeorgeTyrell help? I'd send them back and get them fixed if I were you. I'm sorry, but I don't have any Saitek gear and cannot substitute for their support. Judging by the recent threads on their new gear it looks like everyone's having problems with them, and that they were released rather before they were ready. I'm sure Saitek had an excellent reputation before this, and it is rather sad to see all this happen. But there's not an awful lot I can do about it. Sorry. Regards Pete

Ooh, ouch! Maybe I should put in a check against that. However, I do find it rather strange that Windows would look there for a Side-by-Side manifested DLL. I shall have to ask my contacts in Microsoft about it. The only difference I can think of is that 4.16 was not aware of the Acc/SP2 update whilst later interim versions were. Can you tell me what the version of the SimConnect.DLL was that you put in the Modules folder? Regards Pete

Hmmm. I don't think FSCopilot is interfering with anything -- didn't we try a test with that not even loading? Two tests in fact! Maybe an FSX reinstall would do it, but I'm not so confident. SimConnect is a side-by-side library and even if you do a complete uninstall first (which you should), parts of SimConnect are not removed. That FSX Help announcement does tell you how to fix this for the base version, but I think there are problems doing that in VGista -- you need extra privileges. It might be worth doing those little edits in the DLL.XML file, just to see what happens. Here's the beginning of a SimConnect log I just got with FSUIPC4 and FSCopilot listed in the DLL.XML file, but no FSCopilot installed in Modules: 0.00000 SimConnect version 10.0.61259.0 0.04623 Server: Scope=local, Protocol=Pipe, Name=\\.\pipe\Microsoft Flight Simulator\SimConnect, MaxClients=64 0.13076 Server: Scope=local, Protocol=IPv4, Address=127.0.0.1, Port=2276, MaxClients=64 0.13313 File not found: Path="Modules\FSCopilot.dll" 0.55982 DLL Loaded: Path="SDK\Environment Kit\Traffic Toolbox SDK\traffictoolbox.dll" Version="10.0.61637.0" 1.54959 Panels data export found and set to 20B319D8 4.44048 DLL Loaded: Path="Modules\FSUIPC4.dll" Version="4.2.0.1" > 15.82679 [ 0, 1]Open: Version=0x00000004 Name="FSUIPC4" This is actually from an installation with Acceleration already installed, so the version numbers and so on aren't like yours. But that message "File not found" has always been reported by Simconnect when it is told to load a module and it cannot find it. That's the crunch. In your log it didn't say it couldn't find FSUIPC4 even. Why not? Will it say that about FSCopilot if you move it or spell it wrong? Regards Pete

Sorry, but in my haste to reply before I went out, I pressed "Edit" and edited your message instead of "quote" to reply to it with quotes. However, I did read it, and here is my reply. I'm sorry it isn't good news! :-( First I have to assume that by "no fsuipc" you did mean that you looked in the Modules folder and made sure there were no new FSUIPC4 files produced (like the Log and INI files)? [if not tell me soon, please]. If so, then I'm absolutely and completely out of ideas. The Install log is perfect, but even if it was screwed up the rest is not explainable. In both of those XML files FSUIPC4 is clearly in the DLL.XML, in the place occupied previously by FSCopilot, and with everything absolutely the same excepting only the name of the DLL. It is inconceivable to me that SimConnect can read that file, find and load FSCopilot okay, yet not only completely ignore the FSUIPC4 entry but not even report that it is wrong in some way! It simply makes no sense whatsoever. Even if the FSUIPC4.DLL file wasn't there it would report that in its Log. If it was there but it didn't like it, it would report that too. There is no case I know where it would simply do something like this, say "I don't think I'll take any notice of these parameters, so there!". To test this, as an example, just edit the DLL.XML and change the spelling of "FSCopilot" to say "FSPilot". Run FSX, check the SimConnect log (you are still logging SimConnect? If not, do so for this). It should report that it cannot find " FSPilot". If it still actually loads FSCopilot then obviously we have been looking at the wrong DLL.XML file all along! If it does, correctly, report that it cannot find "FSPilot", try a test with a misspelling of the FSUIPC4 entry. Change "FSUIPC4.dll" to "FSUIPC.dll". See what the log says. Apart from such apparently daft tricks I just cannot think of any way of proceeding. You have a unique condition which, on all the evidence so far, is simply impossible. There must be something we're missing, but I honestly cannot see it. It isn't as if I can add more diagnostics in order to find out -- I can't add anything useful to a program that is simply being blatantly ignored. Sorry. Regards Pete

Sounds like you have more than one axis assigned to the same throttle(s). Check all your assignments. Possibly you are trying to assign them via FSUIPC Axis Assignments but haven't unassigned them or disabled the joystick in FS? Or possibly you not only have separate engine throttles but also one generic throttle assigned controlling all engines. Regards Pete

But it most certainly shouldn't work that way. The display is activated when you write to 32FA. Nothing happens when you write to 3380. Maybe you are repeating it? First, the call "FSUIPC_Write(&H3380&, 128, VarPtr(test), dwResult)" is wrong because the string is not 128 bytes long. You must give the actual length, including the terminating zero byte. Second, though I don't know VB, the usual sort of reason for this problem was that VB didn't use ASCIIZ strings, but either Wide or Unicode strings, so that string wouldn't be correct. Additionally, an ASCIIZ string should be zero terminated, whereas aren't VB strings preceded by a length byte? If that is some odd control character, that would wreck the string as well. Please use the Logging facilities in FSUIPC to see exactly what is being written. That is why I provided logging, to help folks debug their code, yet no one seems to bother to take advantage of this! :-( Regards Pete

Multiplayer aircraft are injected into FS9 through an interface I know little about, and which is of course completely separate from FSUIPC. I have no idea where FSNav gets its data, but it certainly isn't from FSUIPC either. As for TCAS, some such gauges get the data from FSUIPC, some don't. However, it sounds rather as if the multiplayer data is being received by FS, but for some reason it just isn't generating the visuals. If FS didn't have the data, how would FSNav get it? (Or does it have a facility to get it direct from SB?) WideFS only provides an FSUIPC interface, so plays no part in this. The interface involved is the direct TCP/IP one provided by FS for MP. I'm afraid I really can't help at all with that. If FS isn't receiving the data at all -- and FSNav and TCAS are getting theirs some other way -- then you need to check the setup of MP in FS. The TCP/IP and port settings and so on, I assume. Sorry, I've never used it myself. Regards Pete

No, it's a Global parameter, just like PollInterval. That's why I said "main" [buttons] section. You can adjust it, of course, via the PollInterval. Try values from 5 to 50, but be wary of impinging on FS performance with low values. Regards Pete

Please try the interim updates I've put up on the Server. Use these links: FSUIPC3: http://fsuipc.simflight.com/beta/FSUIPC3765.zip FSUIPC4: http://fsuipc.simflight.com/beta/FSUIPC4201.zip Add EliminateTransients=Yes to the main [buttons] section in the INI file to enable the option. It operates only with locally-connected joysticks (not EPIC or GoFlight devices). Note that enabling this option may mean you have to consciously press buttons for slightly longer. It depends on the PollInterval, another [buttons] parameter, which defaults to 25 (milliseconds). A "transient" button indication is one which only exists for one poll, so a real press would have to last up to 50 mSecs to be sure of being seen (more allowing for variations in the polling due to processor/FS activity). You may find you need to adjust the PollInterval too. Please let me know how you get on. Regards Pete

Correct. If you know it is either 4 or 1 you could simply use one line (and even program it in the FSUIPC options dialogue) to "togglebits" with a parameter 5. That'll change 4 to 1 and 1 to 4. (But also 2<->7, 3<->6 and 5<->0, giving 3 unassigned values with unknown consequences. The other (safer) way, in the INI, is to use the latching Flag facilities. Just use the flag for the same button, which is toggled each time you press the button. if flag is clear write 1 if flag is set write 4 The own-flag testing method effectively turns an ordinary press-button into a latching toggle, doing alternate actions on each press. Regards Pete

I only changed 5 seconds to 3 seconds, so the odds were changed from 7 to 1 against it going wrong to definitely shouldn't go wrong. So, yes, please try a few times to be sure. That sounds right, though when you say "stayed up for some time and eventually ...", does that appear too long now? It should only be 5 seconds AFTER the programs are closed properly. If a shorter time would be better I can do that easily, but I don't really want yet another adjustable parameter. Regards Pete

I'm a bit puzzled by this, because, whilst timing differences may just make it a little inconsistent, in general it should work most times irrespective of timing. I was using 5 seconds -- if the Computer name block was sent more than 5 seconds ago, when the first data is received from the Server, then it is sent again. The Client, when not receiving from the Server, normally repeats these every 20 seconds, so the chances of it occurring in the last 5 are small UNLESS it was this data to which the Server is responding, in which case all would be well. The client polls the Server every 2 seconds (default), with a simply polling block, so it is possible for a polling block to come between a Computer data block and the receipt of data from the Server, within the last 5 seconds. But that can happen only in one 2.5 second period every 20 seconds (a 7-1 odds against). See my puzzle? I will of course change my 5 second time to 1.5 x the polling interval (so, 3 seconds by default, which should guarantee things), but I am concerned now that there is something rather different going on with your system,nullifying the 7-1 odds against the buttons not being seen. So, the log please, espcially if it is still failing with the version I attach below (with the new timing). Version 6.756 also should certainly not restart any programs once shutdown is initiated. Let me know. Regards Pete WideClient6757.zip

Hmm. Strange. It works every time here. Must be a timing difference. Maybe the 5 seconds is too long. Could you set "Log=DebugAll" in the Wideclient.INI file (instead of the usual Log=Errors+), try again -- keep it as short as possible as the log will get big -- then Zip up the Log and send it to petedowson@btconnect.com? Thanks. Not sure what you mean by "iso closing" ("instead of closing" perhaps), but I think I know what is happening. The connection from WideServer isn't yet severed, so it looks like a new connection so I should start any 2RunReady" programs again. I need to check the flag that I'm closing down, in another place. Do you mean Wideclient window, not WideServer here? Else I'm confused! Oh, shame. Not WideClient. In the case of a Windows shut down, Windows will automatically send a WM_CLOSE message to all Windows. The problem will be that he is either not processing this when he thinks he is connected to FSUIPC, or has a separate thread for FSUIPC which he is not forcibly terminating when Windows says to close. It would probably be a deadlock if he is waiting for a response from a long-terminated FSUIPC or Wideclient. Regards Pete

Received the file this morning. Thanks. It gets weirder. That shows only FSCopilot.dll being seen by SimConnect, not FSUIPC4, and no failure to find or load FSUIPC4. So, it really MUST be something to do with that DLL.XML file after all. That tells it exactly what to load and where to look. The trouble is, the DLL.XML file you showed me is okay and does list FSUIPC4 correctly (as well as FSCopilot). So. One more experiment. Let's substitute FSUIPC4 for FSCopilot in your DLL.XML file. I attach two DLL.XML files -- one is your original, but with the FSUIPC4 entry swapped with the FSCopilot entry, and the other with the FSUIPC4 entry INSTEAD of the FSCopilot entry -- i.e. no FSCopilot. Save yours, then try with the first one. Do both FSUIPC4 and FSCopilot load, or neither? Then try with the second one. Does FSUIPC4 load, or still only FSCopilot? Finally, just so we know we are talking exactly on the same terms, could you re-run the FSUIPC4 Install.exe program, then Zip up and send me the Install FSUIPC4.log file from the FSX Modules folder. I'd like the actual file please. Thanks, Pete DLLXML1.zip DLLXML2.zip

Erhow? What would be the difference between a button "spike" and a normal button press? Do you mean to not take any notice of a change in button state unless it held the new state for some time? Ouch! That is bad! The driver, being close to the USB port, is more likely to be able to tell the difference between a transient "press" than a full "finger press", but it also rather depends upon whether the buttons are on (pressed) off (not-pressed), or just momentary (do their own on-off when pressed, even if held). The problem with trying to differentiate between momentary and held events in higher levels like FSUIPC is that the only way would be to have a faster polling rate. FSUIPC's default is 25 mSecs (40Hz). I would have thought it relatively easy for a normal finger press of a button to last less than that, don't you think? Of course, on top of this, the true achieved period in FSUIPC's button polling will vary somewhat, depending upon the processor loading and all the other things FS is doing. It would be near 50 mSecs, on average, with the PollInterval parameter left to default at 25. I would simply make the "press" only work if it were true for two successive polls. I suppose you could then experiment with a faster polling rate, get the best compromise between FS performance and "spike" elimination. Not sure how big it would be till I look, but it sounds simple enough if I use the PollInterval. I'd need a buffer for previous inputs and simply use the logical "AND". But since we hope it is temporary, would an INI-file only option be okay? It is less work if I don't have to mess with the Dialogues (and main documentation, for that matter). And wouldn't this have to be joystick-number specific, or wouldn't it matter if it applied to all? It would be less work for blanket coverage. I assume you are hoping for it in both FSUIPC3 and FSUIPC4? I would have to apply it only to local joysticks, not those connecting via WideFS, since the timings across the Network would make a mess. Although, if really necessary, I suppose the filtering could be done at the WideClient end. Regards Pete

Okay. Here's version 6.756 for testing. The problem with the buttons was quite simple to see once I had the clues. In order for WideServer to assign a distinct Button number to pass to FSUIPC it needs to know the NAME of the client PC sending the button data. The names are kept in a list in the INI file and used to ensure consistency across many clients (up to 32 with buttons). When TCP or IPX protocols are used, the connection is made before anything is sent in either direction. The computer name is sent to FS when it is connected,. Equally, when you let the clients connect automatically, since they don't know what protocol to use nor which Server until they get the broadcast from WideServer, when the client sends the Computer name, FS is certainly running and can receive it. The only combination which didn't work is UDP (which is connectionless) AND non-automatic connection. In this case the Client continually sends the Computer name and other stuff until it gets a responsethen it knows it is "connected". Unfortunately, however, the first part of what it sent in order to elicit the response is lost by then -- the server is responding to the last bit! I've fixed it by repeating the computer name block after receiving something if this is more than 5 seconds since it last sent it. It seems to work fine here, now. Please verify on your set-up. On the shutdown problem, I've changed it so that it does the closedown differently: 1. If there are Applications started by Wideclient and waiting to be closed, it sends them Close messages first, then tries to continue normally for 5 seconds before telling windows to close down. 2. If there are no applications it knows about, it does as now, immediate close down via Windows. I've not been able to test this yet -- maybe I won't be till Friday. So please let me know. Regards Pete WideClient6756.zip

Okay. So I take it then that you confirm that there is no FSUIPC4.LOG or INI files to be found. The mystery deepens, because that DLL.XML file is okay, it is as it should be. The only answer now is to obtain a SimConnect log file -- it will tell us if it is trying to load FSUIP4 and if not, hopefully why not. It is easy enough, so please don't back out now. See the Announcement near the top of this Forum entitled "FSX Help ...". Ignore the bit about repairing SimConnect for now, just do the Log bit. Run FSX, get the problem, close FSX, get the SimConnect log file, ZIP it up and send it to me at petedowson@btconnect.com. Regards Pete

Okay. Good clue. I try it with explicit Server/Protocol details here. I never understand why anyone ever uses explicit IP addresses in the first place. Isn't a name easier to read? My FS test Pc in the corner is called "CORNER". The one on its left is called "LEFT". I could never remember IP addresses anyway. And a lot of folks leave them dynamically assignable by their Router, so they couldn't realy on them anyway. It sounds like FSCommunicator is not quite so well designed in this area and is hanging in its FSUIPC interrogation thread or section and not checking/obeying the Close message it gets from Windows. The CloseReady is not so relevant to shutting the PC down. For PC shutdown all WideClient needs to do is call the Windows facility to ask it to close down the system. It is then Windows which sends closing messages to all of the processes. I'll take a look, but I'm not sure there's a lot I can do. Has anyone written to the FSCommunicator chap about it? I'm sure it is something he could easily fix. I may have another WideClient to try tomorrow. I'll look at the Close Down timing too, see if i can make WideClient hold out a bit longer. How many seconds does it need? Regards Pete

It isn't pestering. We are trying to get some information. Most all of what I need to know first will be in the FSUIPC4.LOG file, which you don't seem to want to even look for, let alone show me. I also suggested, as a test, trying to run FSX without FSCopilot (which would diable FSInn), to see if there was some interaction. With the early versions, and before FSX SP1 update, FSCopilot was sometimes causing SimConnect to not correctly run FSUIPC. Who said it was? What is the matter with you? Can you not just respond to questions, asked to try to elicit information, to help? I am trying my best with you! :-( Ah, so you DID run that test!! Why didn't you say that in the first place instead of getting all weird and emotional? That eliminates one possibility. So, now, can you actually positively confirm that there is no FSUIPC4.LOG and no FSUIPC4.INI file in the FSX/Modules folder? Why isn't there? You want to give up when we've only just started? After several exchanges we've established three important things already: (1) FSUIPC4 install is okay (2) there's no firewall or other such blockage, and (3) it isn't any interaction with FSCopilot. If there definitely is no sign of the LOG and INI files then you are correct, FSUIPC4 isn't getting loaded at all. There's only one file which will be responsible for that -- the DLL.XML file which is in the same folder as FSX.CFG. Find that and show it to me. It is a normal text file and can be opened in Notepad and Copied/Pasted into a message. If you really want to quit, by all means do so. but I really don't see why you are so wound up and emotional about this. I'm giving a good response rate aren't I? It's been less than 6 hours since you first raised the problem. How many support departments give such a response? Regards Pete

Say no more, then. Bit of a waste of a PC though. ;-) Pete

Ahin that case, I do really need to know whether there is or is not amn FSUIPC4LOG (and FSUIPC4.INI) file in the FSX Modules folder. If there is not, then FSUIPC4 is not even being loaded, which means that the DLL.XML file is wrong (that *must* be in the same folder as FSX.CFG). If the FSUIPC4 files are there, I still need to see the FSUIPC4.LOG file, please. Yes, but if that were the problem you would have no AddOns menu at all and FSInn could not run either. As another test you could try removing FSCopilot.dll from the FSX Modules folder, if it is there -- just temporarily, as a test. Pete

The three separate gear positons are read-outs. You can write to them, but FS will simply overwrite them with the next value. I don't know any way of making a partial failure. There is a facility in FSUIPC for preventing the gear being raised or lowered, that's all. See offset 32F8. Regards Pete

You managed to find the Install FSUIPC4 log file. There's also one forom FSUIPC4, just called the FSUIPC4 log. If it isn't there then you have never run FSX with FSUIPC4 installed. Sounds like FSUIPC4 isn't even being loaded -- you probably have a bad Simconnect.xml file. Check the folder which contains your FSX.CFG file. Pete

That's the Install log, and it shows it installed okay and that you have SP1 installed. But I repeat the other questions (suitably revised): Is this the first time you've tried to use FSUIPC4 in FSX? Can you find the FSX/Modules folder (I now know you can), and there find the FSUIPC4 log file? If so, please show it here (it is an ordinary text files and can be copied/pasted from Notepad). The FSUIPC4.log file will show me more about why you get no Add-Ons menu. After that we may need to go further -- getting a SimConnect log , possibly. But show me the FSUIPC4 log file first. Regards Pete

Chances for what? If it is a Microsoft Beta release of some old Win2000 version, then the chances that you can use it at all are pretty slim. Its Beta period will have expired. Are you short of a proper copy of Windows and this is the only reason you are resorting to a (free?) Linux? Regards Pete