Pete Dowson

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

I don't know. It is one possibility. I need more information. Is this the first time you've installed FSUIPC4? Can you find the FSX/Modules folder, and there find the Install FSUIPC4 log file and the FSUIPC4 log file? If so, please show them here (they are both ordinary text files and can be copied/pasted from Notepad). Regards Pete

Hi Thomas! Ah, but you have Acceleration installed! Thanks for the confirmation, nonetheless! Best Regards Pete

Okay. Thanks. I'll take a look. If you don't hear back from me by the end of the month, please write again. I should be able to get to it on or soon after the weekend. Regards Pete

Yes. You send the message as a normal ASCIIZ string to offset 3380, then write a control word to 32FA which specifies stuff like time of display and whether it scrolls or not. Please see the FSUIPC SDK. Regards Pete

Sorry, no. I really don't know much about it, and would naturally have a problem unless I bought one myself. The main problem with these innovations is that there are many of them -- Saitek has one, there are keyboards with displays (from Logitech and others), as well as the CH devices -- and they all need different drivers, different programming and so on. It really isn't something I could start dabbling in. The drivers from the specific manufacturers really do need to cope. I'm sure it will improve with time. Tell them what you think! Regards Pete

I can't reproduce the problem here no matter what I do. I checked the code also, and the button scanning actions in WideClient are not at all related to its connection to the Server. So it remains a mystery at present. Just in case it is related to a configuration setting, could you just run a simple test please. Rename the WideClient.INI file the problem client is using, so it doesn't get used, and allow WideClient to run purely on default settings. [i'm hoping here that you are using XP throughout and have WideFS automatically connecting. If not, let me know in case that is related, and just edit the default INI to insert your ServerName and Protocol parameters]. Let me know the result, and please show me or append the WideClient.INI file you normally use. Regards Pete