Pete Dowson

Hmm. Shame. That was the most likely option. ASX doesn't use WideFS. Nothing wrong with the logs or INI, so I'm at a loss really. Perhaps you could enable more logging at the WideClient end (Log=DebugAll in the [user] section) and try. Don't let it run too long as the Log will get huge. ZIP it and email it to petedowson@btconnect.com. I've not really changed anything in WideClient for years, especially for those using 6.75, so how suddenly these problems arise for old programs for several users at the same time is really mystifying. I can't see how it could be RCV4 either as I've used that on a WideClient for years too, along with many other programs on the same PC. Pete

I don't want the title of the Installer, I want the version number of FSUIPC.DLL, the program. I'll re-iterate the ways you can find this, as you seem totally unwilling to do as I asked before: 1. You can find the FSUIPC4.DLL in the FSX Modules folder. Right clicvk on it, select Proprties, then Version. 2. You can run FSX, go to the FSUIPC4 options (ALT D F) and read the version number on the About page. 3. You can find the FSUIPC4.Log file in the FSX Modules folder, and read the version number on the top line. I have explained all these things before, but you are ignoring them. Pete

Please do not SHOUT. That helps no one. Try to remain civil. you have great difficulty expressing yourself, it seems, but shouting makes just it worse. If the FSUIP4.DLL is not in the FSX|modules folder, then something or someone has deleted it. Perhaps you could be clearer. How are you actually seeing that it is "MISSING"? Are you looking for it in Windows Explorer? You should note that unless you set the option otherwise, Windows has the awful habit of hiding the filetypes of DLL and EXE from you. Maybe that is what is confusing you? Pete

It wouldn't have installed anything into FSX -- FSUIPC3 cannot be installed in FSX, it does nothing, and it would certainly not have replaced FSUIPC4 as the names are different. It seems that you are messing about and not knowing what you are doing. All this works fine for many hundreds of folks. I am trying my best to help you but getting information out of you is turning out to be extremely difficult. You getting irritated and irrational won't help. Just delete the whole INI file and start again. don't touch anything like "aircraft specific" as you obviously don't appreciate what it is for. Just keep it simple. For Pete's sake, you are only programming 5 damned buttons! It's so easy! Tell me what you don't understand and we'll go through it, step by step! What does "gone completely" mean? Please try to make some sense. Pete

Whilst 100% CPU usage isn't meaningful in itself (earlier versions of FS use to give the save value even when not doing much -- it was just that they soaked up idle time instead of Windows' own "idle time" process), the only times I've seen that on any of my systems is when there's been something wrong on the Network. Well, not the high CPU load directly, but the lack of the processor being released. No where in WideClient is there any "loop" which takes any measurable time. it is all "get message from Windows" -- "Process it" -- "return to windows". All the processing is relatively short. Whenever I've seen this problem the time being taken is always deep down, in Network modules or in Game Port / Game Device sections of Windows. Is the PC you have a problem with one on which you have ever had any joystick device, but no longer? Especially an old game port type? It may be a joystick driver polling the joystick for Wideclient's button scanning. Unless you tell it not to, WideClient scans all joysticks apparently installed on the PC so that you can program their buttons back in FSUIPC. When one is missing, especially a game port one, Windows seems to get stuck deep down in the driver waiting for a response. With the default scanning rate of 50 per second (20 mSecs) there may be little time for anything else. But WideClient has higher priority threads for Network and Client calls. Check Windows Game Controllers -- see if it has registered drivers for non-existent devices. If so, uninstall them. Also make sure you don't have GFDev.dll installed if you have no Goflight units on that PC. You can also stop WideClient scanning buttons by setting ButtonScanInterval=0 in the [Config] section of WideClient.INI. If it isn’t button scanning it is almost certainly a Network problem. Run it, get that 100% symptom, close FS and WideClient. Show me the WideClient.INI file, and both WideClient.log and WideServer.log files. Incidentally, version 6.759 is available in the downloads announcements above. You may want to change to that. Regards Pete

Radar Contact? RC doesn't install FSUIPC4 that I know of! What's all that? Please just either find the FSUIPC4.DLL in the FSX modules folder, right click, choose Properties-Version, and read the version there! There should be none of that "Installer for" business. What on Earth are you looking at? The Installer log? Why? If you want the version number from the Log you have to look at the FSUIPC4.Log! Well, you've set the same 5 buttons for "PMDG747-400 VIRGIN ATLANTIC AIRWAYS Penelope" and all other aircraft, except "PMDG - 747-400 GE CF6 Engines", where you've only set two of those plus a third button doing nothing ("K0" is "null2, or "no key"). If you want the same 5 buttons operating the same 5 KeyPresses for all aircraft, as you seem to have programmed really (except for that latter mess), why are you bothering to use the "aircraft specific" checkbox? I suspect you are only succeeding in confusing yourself. Just delete all of the above except for [buttons] 1=P1,18,K56,11 2=P1,17,K48,11 3=P1,16,K55,11 4=P1,14,K49,11 5=P1,1,K54,11 And please don't come back here until you at least know which version of FSUIPC we are dealing with. I told you three ways of finding out and you did none of them! ::-( Pete

But the "Auto" setting, will use a Pipe if specified in the "Local" entry. If you showed me the first part of your SimConnect log I could tell. The ID numbers assigned to each client program are in ranges. At the start of the log there are entries listing the Simconnect services being established, as here for instance: 0.01346 Server: Scope=global, Protocol=IPv4, Address=LEFT, Port=500, MaxClients=64 0.04459 Server: Scope=local, Protocol=Pipe, Name=\\.\pipe\Microsoft Flight Simulator\SimConnect, MaxClients=64 The "MaxClients" value reserves the IDs. So above clients 0-63 would be using the IPv4 protocol via Port 500, whilst those with IDs 64-127 would be using the local Pipe. Additionally I think the Pipe ID allocation runs from low (64 here) to high, whilst the others run from high (63 here) to low. So, you can tell from the ID assigned which protocol it is using. For example: > 8.25427 [64, 1]Open: Version=0x00000004 Name="FSUIPC4" here FSUIPC is ID 64, using the Pipe. Regards Pete

Are you one "Tommie Wood", from whom I have just received an email? Pete

The User guide (in the Registration section) does actually say you need to keep the same identity for both registrations (the name and email tie in irrevocably with the Keys). You needed really to tell SimMarket your required ID (email) when you ordered. You have two choices now (only one when I'm off on holidays). You can either get SimMarket to sort it for you -- raise a problem ticket, I think. They are quite quick. Or you can send all the details -- both FSUIPC and WideFS -- to me at petedowson@btconnect.com, saying which email you want to use, and i'll make a new Key for whichever needs changing. Regards Pete

So you are talking about buttons and keys assigned in FSX "Options-Controls-Assignments"? Or in the PMDG 747 menus? And what IS that version? Please never ever just say "most recent" or "latest". It is meaningless. I've had folks saying that and when looking at the logs they supplied it turned out they were using one many versions out of date -- a year old in one case! They thought it was the "most recent" because they hardly ever bother to look for updates! FSUIPC, like all of my program, has a VERSION NUMBER. It's a value like "4.272" (which happens to be the "most recent" one today). It is so easy for you to find out what version you are using. Look on the About tab in the options. Look at the first line in the Logs. Right click on the DLL itself and read the Version in Properties! Whoa! Where do you "reset buttons"? What do you mean by "reset"? Is this in FSX or FSUIPC? So are you, all this time, talking about button assignments in FSUIPC itself? This is what I have been trying to get clear. You've never actually been explicit! When you make assignments in FSUIPC4 they are saved to a file called "FSUIPC4.INI". You'll find it in your FSX Modules folder. Make your assignments and show that file to me. It's an ordinary text file. It sounds as if you are using the "aircraft specific" facilities by expecting the buttons assigned for one aircraft to be available for another. But first, let's make sure you are actually really using the "most recent" version. I don't want to waste my time trying to fix anything already fixed! Regards Pete

WideFS simply provides a copy of the FSUIPC interface on Networked PCs, so any FS application program which uses FSUIPC and runs externally to FS (not inside it) will work, with some provisos regardingaccess to things like NAVAID or Airport databases and other parts of FS. Certainly I know folks are using FDC on Networked PCs. I don't know VoiceBuddy - I don't think it uses FSUIPC in any case, but if all it does is translate voice commands to keystrokes, then those too can be relayed from a Networked PC (though there may be keyboard focus issues, depending what else you have running on that PC). I run ActiveSky 6.5, FS RealTime, AISmooth, Radar Contact, Jeppesen FliteMap, FS Flight Keeper, TSR Electronic Checklist and a few other programs linked to FS from Networked PCs, all via WideFS. I know of folks using Squawkbox that way too. Regards Pete

For the FSX PC you should have all three versions of SimConnect installed, as different SimConnect client programs will need different ones. For DLLs and Gauges using SimConnect, like FSUIPC4, the RTM version is usually needed (even if they then use a later one), as it is the one which loads them. The same would apply to any EXE's you have loading automatically (via the EXE.XML file). For Networked PCs you need whichever versions of SimConnect may be needed by the applications you run which use them. Having multiple versions installed does no harm. They install into the Windows "SideBySide" library system which allows different versions of the same library to be used by different programs, according to their expectations and needs. Pete

Could you perhaps be a little clearer about what you are talking about here? What is this "msconfig" you might want to edit? Where is it and what program does it relate to? You seem to be mixing up stuff to do with windows, FS, PMDG and FSUIPC all together and I just don't understand what you are doing or what you think is going wrong. If you are talking about anything to do with any of my programs I need to know which one (FSUIPC presumably?) and what version. Then I need to know what you are doing with it and what you think is wrong. If your message was a re-post as you say, why isn't it in that thread? Maybe I could follow you then? Pete

For the local connection, between programs running on the same PC as FSX, Named Pipes should be much more efficient as they are simply implemented via shared memory, much like FSUIPC's own interface with its clients. For a Networked connection it make little to no difference as pipes are transported using TCP/IP protocols in any case. It worries me a little that so much TCP/IP data exchange is by UDP which is basically unchecked and un-recovered on error, unlike TCP. In a perfect world UDP would be preferable as it is faster without the red tape. But ... By default SimConnect SP2 or accel uses Pipes locally when you set "Auto" in the XML file (or don't provide an XML file). Prior to SP2/Accel pipes weren't an option. Regards Pete

No, but in the few other cases it has been due to some other service, driver or process going wrong. Kensington mouse driver, Windows blinds, other such things. Something you have installed is interfering with it. Regards Pete

You are entering something wrong, then (all three parts, name, address, key, must be correct), or you have mistakenly bought a key for FSUIPC4 instead of FSUIPC3. Since you hide your name behind an alias I can't even check for you. If you feel sure you have it correct, please send all the details to me at petedowson@btconnect.com, and I'll check them here. Pete

Those errors are most certainly down to corruption occurring between the SimConnect DLL and FSX. No, because the version data reported in the errors is rubbish. The whole sequence is most definitely indicative of a completely corrupted set of data in the pipeline between SimConnect.DLL and FSX itslef. I have no idea how that can arise. It is using a Windows facility called "Named Pipes", which is merely a way of using shared memory between processes. This has got to be down either to a faulty memory module (possibly overheating memory?), or a bug in either Windows or SimConnect. There's real;ly no way anything in any application add-on can be responsible for these errors. You could try forcing Simconnect back to using TCP/IP, just as an experiment. It is slower, a lot less efficient, and may slow things down a bit. Of course it still uses memory buffers, but not the same one all the time -- it'll keep allocating and freeing them. To force SimConnect to use TCP/IP you need to put a SimConnect.XML file into the same folder as your FSX.CFG file. See below. You don't need the Blue bit if you aren't using SimConnect over a Network. If you already have this file, to run, say, ASX, from a Networked PC, just add / chage the RED bits: SimConnect SimConnect.xml False False IPv4 global LEFT 500 64 4096 True False IPv4 local True Pipe local Ah, I see that you do use SimConnect over a Network, so probably all of the above file is relevant -- check the corts and so on in the version you are using. All I'm doing is changing the usual local "Auto" protocol to "IPv4", and adding a complete new entry, in red above, to disable the local "Pipe" protocol. That is from the WideServer log -- FSUIPC never logs any such thing! And it's not related, but a glitch on your network. The odd one now and then probably doesn't matter, though on a truly healthy network you should never seen any such errors. Regards Pete

Not really. It has at least read and written some stuff with FSUIPC -- what changed since your previous attempt? It is extremely inefficient. I noticed that in the Logs I did here. It is writing its Key and Name, which should only amount to 37 bytes, but it is writing 268 instead -- the absolute maximum allowed. The other 231 are just irrelevant rubbish. Furthermore, it does this very frequently. It was the same in my log -- it is writing its key at the Gauge refresh rate. I suspect it is written badly, maybe even doing a complete new FSUIPC connection (Open/Close) on each call. This would be allocating and freeing about 32k of memory at about 4 times your FS frame rate. This doesn't seem to have any noticeable performance impact here on my test system (a 3.2Gb PC with 2 Gb memory), but I could imagine it making a big difference on some, especially if you have other things running too. However, your log just stops, dead, without too many of those silly repeated writes, so I guess it just crashed then. Sorry, it isn't anything I can help you with I'm afraid. There is no way I can debug other folks software. Perhaps you've found the reason why it is now freeware? You could see what happens if you remove that gauge I mentioned -- just find the line in its PANEL.CFG file and comment it out (; in front). If it isn't the last line the succeeding ones will need renumbering. Just make a backup copy first. That will stop it using FSUIPC, so you can take that out of the equation too. Of course if it then works it doesn't prove much except that there's a problem with that gauge. Regards Pete

Hi Martin. The NWI is used by ActiveSky 6.5 and that works pretty well on FSX (for those who've not upgraded to ASX). I've not tried it on ESP, but there's really no difference in that regard. No, no change, but FSUIPC4 and ESPIPC use SimConnect to set the weather, and have to convert it all to extended METAR strings. If FSX/ESP are crashing it could be a SimConnect problem on your installations. It is also possible, of course, that you have something which maybe not quite right in the NWI (or something I didn't think of) but which didn't have any adverse effect in FSUIPC3 but does in FSUIPC4. Your best bet is to use the Logging facilities provided in FSUIPC4. Please let's concentrate on FSX first, because it is far easier for me to get into it the way my development is set up. In fact, it would be best to log the exact same sequence in both FS2004 and FSX so that we can see where it goes wrong in context. Enable Weather logging and both IPC Read and Write logging in both. Turn off any weather options in both. Make sure you only have that one FSUIPC client to avoid extra large and confusing logging. It might also be a good idea, for FSX, to get a SimConnect log too (see the FSX Help announcement). Zip up all the logs, and the FSUIPC INI files and send them to me as email attachments. You know the address. BTW I'm going to be running very short of time soon. [LATER] I just ran ASV6.5 against FSX, using the latest FSUIPC4 (4.272), just to make sure I've not messed anything up, and it sets weather quite well, no problems. I also tested with WeatherSet2 (good for reading via the NWI, more difficult to use for writing). With the FSUIPC weather logging on and a program setting weather stations via the NWI you will get log entries like this one: 475484 NW_SET weather command received, ICAO=EBAW 475484 >NewSet: **** New Weather being set: ICAO=EBAW (Dyn=0) 475484 >NewSet: Pressure=1021.0, Drift=0.0 475484 >NewSet: Visibility[0]: range=1.2sm (1979m), from=-610ft, to=9880ft 475484 >NewSet: Temperature[0]: alt=36ft, Day=10 C, NightVar=0 C, DewPt=10 C 475484 >NewSet: Temperature[1]: alt=3000ft, Day=5 C, NightVar=0 C, DewPt=-1 C 475484 >NewSet: Temperature[2]: alt=5990ft, Day=-1 C, NightVar=0 C, DewPt=-7 C 475484 >NewSet: Temperature[3]: alt=9000ft, Day=-4 C, NightVar=0 C, DewPt=-10 C 475484 >NewSet: Temperature[4]: alt=12000ft, Day=-13 C, NightVar=0 C, DewPt=-19 C 475484 >NewSet: Temperature[5]: alt=18000ft, Day=-26 C, NightVar=0 C, DewPt=-32 C 475484 >NewSet: Temperature[6]: alt=24000ft, Day=-39 C, NightVar=0 C, DewPt=-45 C 475484 >NewSet: Temperature[7]: alt=30000ft, Day=-52 C, NightVar=0 C, DewPt=-62 C 475484 >NewSet: Temperature[8]: alt=34000ft, Day=-57 C, NightVar=0 C, DewPt=-67 C 475484 >NewSet: Temperature[9]: alt=39000ft, Day=-54 C, NightVar=0 C, DewPt=-69 C 475484 >NewSet: Temperature[10]: alt=50000ft, Day=-59 C, NightVar=0 C, DewPt=-74 C 475484 >NewSet: Temperature[11]: alt=82000ft, Day=-69 C, NightVar=0 C, DewPt=-89 C 475484 >NewSet: Surface wind: to alt=2040ft AMSL, dir=280T, vel=5.00, gust=0.0, turb=0, shear=0, var=0.0 475484 >NewSet: Wind layer 1: to alt=3000ft AMSL, dir=284T, vel=13.0, gust=0.0, turb=0, shear=0, var=0.0 475484 >NewSet: Wind layer 2: to alt=5990ft AMSL, dir=315T, vel=18.0, gust=0.0, turb=0, shear=0, var=0.0 475484 >NewSet: Wind layer 3: to alt=9000ft AMSL, dir=307T, vel=15.0, gust=0.0, turb=0, shear=0, var=0.0 475484 >NewSet: Wind layer 4: to alt=12000ft AMSL, dir=307T, vel=22.0, gust=0.0, turb=1, shear=0, var=0.0 475484 >NewSet: Wind layer 5: to alt=18000ft AMSL, dir=288T, vel=33.0, gust=0.0, turb=0, shear=0, var=0.0 475484 >NewSet: Wind layer 6: to alt=24000ft AMSL, dir=290T, vel=33.0, gust=0.0, turb=0, shear=0, var=0.0 475484 >NewSet: Wind layer 7: to alt=30000ft AMSL, dir=284T, vel=37.0, gust=0.0, turb=0, shear=0, var=0.0 475484 >NewSet: Wind layer 8: to alt=34000ft AMSL, dir=274T, vel=28.0, gust=0.0, turb=0, shear=0, var=0.0 475484 >NewSet: Wind layer 9: to alt=39000ft AMSL, dir=256T, vel=24.0, gust=0.0, turb=0, shear=0, var=0.0 475484 >NewSet: Wind layer 10: to alt=50000ft AMSL, dir=256T, vel=14.0, gust=0.0, turb=0, shear=0, var=0.0 475484 >NewSet: Wind layer 11: to alt=82000ft AMSL, dir=256T, vel=7.0, gust=0.0, turb=0, shear=0, var=0.0 475484 >NewSet: Cloud[0]: type=9, from 364ft to 4410ft (+/- 66ft), cover=8, turb=2, topshape=0 475484 >NewSet: Precip=1, base=-120ft, rate=2, icing=1 475484 >NewSet: Cloud[1]: type=1, from 38960ft to 39130ft (+/- 100ft), cover=2, turb=0, topshape=0 475484 >NewSet: Precip=0, base=0ft, rate=0, icing=1 475484 >NewSet: **** End of New Weather details for ICAO=EBAW 475484 Setting Weather: "EBAW 240007Z 28005KT&D609NG 28413KT&A609NG 31518KT&A902NG 30715KT&A1814NG 30722KT&A2731OG 28833KT&A3646NG 29033KT&A5474NG 28437KT&A7303NG 27428KT&A9132NG 25624KT&A10351NG 25614KT&A11875NG 25607KT&A15228NG 1979&B-201&D3201 8CU003&CU040FLMR000T 2CI389&CI002FNVN000T 10/10&A0 05/M01&A902 M01/M07&A1814 M04/M10&A2731 M13/M19&A3646 M26/M32&A5474 M39/M45&A7303 M52/M62&A9132 M57/M67&A10351 M54/M69&A11875 M59/M74&A15228 M69/M89&A24982 Q1021 " The lines up till the "Setting weather" line is the received NWI command for a single station, and the long METAR-type string at the end is how this gets sent to SimConnect. With SimConnect logging enabled you'll see the same string there. I'm sure you'll be able to understand this, but what I'd be interested in is the comparison between FS2004 and FSx. Theoretically there should be nothing you can do via the FSUIPC IPC NWI interface to cause an FS crash, because the data all has to be checked and converted into that METAR string first, so rubbish shouldn't really get through. If the crash is actually happening in my code then of course i want to know, and fix it. Regards Pete

nothing is using FSUIPC for anything then, at least not before it crashes/hangs. I'm afraid you need to look elsewhere, it isn't going to be related to FSUIPC at all. I'll download it and try it here, just out of interest, and confirm one way or the other for you, but it's certain that if you have IPC read and write logging enabled, as you have, and no such actions are logged, then nothing is actually reading or writing anything via FSUIPC -- it may have opened a "link", but that is completely self-contained at its end. FSUIPC won't know anything about that till it makes its first read or write request. [LATER] Okay, I downloaded, installed it, and it runs fine. No problems at all. It has just one gauge interfacing to FSUIPC -- "RT742_Tapes.GAU". Your log certainly shows it simply isn't getting that far. I suspect you have some kind of graphics conflict or a corrupted gauge someplace. Regards Pete

Oh, sorry. Missed that ... Pete

No. Haven't you even looked at the Menu? Pete

Well, you could enable FSUIPC's IPC logging (Logging options page, IPC read and IPC write logging). Make sure you don't have any other FSUIPC-using programs running else the log will be too confused. Run it till it fails, check the FSUIPC log (show it to me). Maybe there will be a clue in whatever it last accessed in FSUIPC. Mostly these sorts of problems are down to incompatible gauges, which is why I was suspicious about it being FS2002 specific. Incidentally, I've had a look through the AVSIM libraries for anything resembling this as a freeware item for FS2004 and I can't find it (else I might have tried it for you). Googling only turns it up as FS2002 payware. Regards Pete

Sorry, you need to learn a little more programming I think: Here you are writing 128 characters, starting at mensaje[0]. Yet that variable is nowhere near that big! You could easily crash your program doing things like that! Use sizeof(mensaje) to get the proper size instead! Also, in C/C++ declared strings automatically have a zero terminator appended. You do not need to add that \0 character! Here: You are providing the address of the string variable "+1" as the address of the 16-bit binary value to be written. The string "+1" will be some very large binary number! Strings are only used in FSUIPC where it says so! If you don't understand C then maybe you should look at some more elementary language which doesn't need so much work on your part? There are examples in the SDK for several languages. Maybe C is not suitable for you? It will actually be 49 seconds, because the string "1" is represented in 16 bits as 0x0031 (0x31 is the character 1, and the the 0 comes from the zero string terminator. 0x31 is 49 in decimal. You don't need to call FSUIPC_Process for everything you write. That is very very inefficient. Do all the reads and writes and one "Process" call at the end. Pete

Oh, right. Isn't that for FS2002? I seem to remember that being many years old now. Are you sure it works with FS2004? Is "VMAX" the company? Do they have any support? Regards Pete