Pete Dowson

You make macros for a particular aircraft or gauge, not for any specific hardware. Only when you have your library of macros do you assign as you wish to buttons, switches and keypresses. Are you using an up-to-date version of FSUIPC4 (4.742 or 4.743)? Because there were problems with the PMDG 737NGX fixed after 4.70 was released. So, it seems that the CDU gauge is not susceptible to this way of doing things. It is nothing whatsoever to do with hardware, only whether the gauge is written in a certain way. I thought the PMDG 737NGX was mainly driven by lots off added control numbers. Have you browsed all the extensive NGX contributions in the User Contributions subforum? There's a lot of stuff there. Also the LINDA package may well be suitable. LATER: having said that, I just scanned those entries concerned with the NGX and don't currently see any ready-made solutions. I think, also, that most CDU implementations only implement controls for the functions and LSK buttons -- you'd need, probably, to leave all of the text buttons to VRI's software, sending text keys, or program them to send the same keypresses. Maybe all of the CDU on the 737NGX is driven solely by keypresses? The content of the .mcro file is more important, though it wouldn't mean that much to me without the aircraft and at the exact same level of update as yours. Additionally, note that with VRI devices you generally have to assign the same thing to both "Press" and "Release" or else you'll need to press each button twice. Regards Pete

No, it isn't FSUIPC which has the problem. You cannot simply move FS from one PC to another, to HAVE to install it. Yes, once you've installed it you can get it up to the same state as on the other PC by copying everything over, on top, but you should have installed it and any updates first. I'm still none the wiser as to what you are doing. You appear to have TWO installations of FS -- one on drive C: and the other on drive E:. That's on this one PC, not on two PCs. You appear to be letting FSUIPC install on one drive but then running FS from the other. You can't really expect that to work at all, surely? Regards Pete

Correct. (Not sure what else they could possibly do! ;-) ) . Regards Pete

Replace. There can only be one copy called "FSUIPC4.DLL", and when Windows "keeps" a copy it renames it (with "- copy" for example). Only FSUIPC4.DLL will be loaded. I'm afraid I don't know if your "cockpit sounds" add-on uses FSUIPC -- it should say if it does. Regards Pete

That sounds like it may be related to the business I said was recently reported, about the start-up ground altitude. Maybe, once you really have things working okay, you could kindly tell me exactly how you did it and I can add a write-up to the documentation, to help others? In fact if I knew there was a good way of making it all work correctly I'd have another stab at getting all of the options on the (optional) visibility tab working correctly -- including, in particular, the graduation option which was always very popular in FS9 and before. They are being converted into FSX SimConnect "METAR" strings and sent to SimConnect. FSUIPC is only the intermediary here. You could, if you wished, experiment more directly by creating your own METAR string, in FSX's rather extended format, and send them via FSUIPC's offset B000-B7FF. The format is defined in the SimConnect SDK, part of the FSX SDK installed from the FSX Deluxe edition and updatable from the web. You could also use weather logging in FSUIPC or SimConnect logging to see the strings being sent and received (different formats in detail though!0. Regards Pete

Almost all FS keystrokes instigate FS controls -- there are exceptions when the control is local to a gauge and doesn't need sending through the system. The quickest way yo find out what they are called (and some of the names certainly aren't obvious) is to enable Event logging in FSUIPC's options, operate the control, then look in the Log file -- found in the FSX modules folder. Doing that with this switch shows it is "TOGGLE GPS DRIVES NAV1", number 66375. If you (temporarily maybe) run FSX in windowed mode you can enable FSUIPC4's console log and see events logged in real time. Regards Pete

Why have you purchased FSUIPC4 then? You only need to do that if you want to use its facilities, and since you seem uninterested in those I think you've wasted your money. As for "knowing how", have you not heard of documentation? That's why there's a user guide! ;-) Also, you don't "purchase FSUIPC 4.70" but "FSUIPC4". The current version is 4.742 and there's a 4.743 update available in the Download Links subforum. And with regards to your problem, I repeat, if you are not using FSUIPC for anything, it will not doing anything. You need to look elsewhere. Yes, but if you are not using FSUIPC for anything it will make no difference. Another default INI file which also does nothing will be created. Regards Pete

There are settings for exactly that in FSUIPC, on the four throttles calibration page. The re-mapping is automatic according to the aircraft loaded and will also cope with 3-engined aircraft. Pete

Sorry, no. I always thought the visibility control provided in FSX was faulty, which is why the visibility options tab in FSUIPC4 is optional and only appears is an INI file parameter is changed (with such warnings). I don't remember now what exactly all the problems were (it was 5 years ago), only that I did find it unreliable. Microsoft were certainly aware of it but said they couldn't fix it before FSXI. Was this using a global weather mode, or setting weather at a single station? If the latter it could simply be the normal interpolation i suppose, When setting station weather you need to set it at all surrounding stations, or use Global (not 'global mode but the 'GLOB' id) to populate them first. Recently I have had this reported to me -- maybe it will help? Regards Pete

I received your packet of files, thanks. But there is something very odd. The Install log and the KEY file are dated today, and relate to the 3.991 installer and an installed 3.998f in folder C:\Program Files (x86)\Microsoft Games\Flight Simulator 9\Modules Additionally the KEY file shows no sign of a registered WideFS, only an FSUIPC correctly registered. But the FSUIPC.INI and FSUIPC.LOG files are from 24th September, over a month ago, and relate to a very old version, 3.98a, in E:\Program Files (x86)\Microsoft Games\Flight Simulator 9\Modules The log shows neither FSUIPC nor WideFS registered. You also included another log, this one dated 20th November 2009, using version 3.48, and again no registrations at all. It seems to me you have two separate installs of FS and are installing in one, but running the other, and getting totally confused when obtaining the files. Please try to sort yourself out. I'm sure things will work fine once you have the right installation updated and in use. Regards Pete

The FS version has changed -- it is now 3.998f, not 3.991. When you enter the registration in the Installer, what response do you get there? You never said. And you never showed me the~ Installer log. I think you must be getting the key wrong when entering the FSUIPC details -- I've checked your name and email against your original registration and they are the same for both WideFs and FSUIPC, so it must be related to the key only, and I don't have that. There's really no other explanation. But don't post it here. ZIP up your FSUIPC.LOG, FSUIPC Install log and your FSUIPC.KEY file, all from the FS modules folder and send them to me, please. petedowson@btconnect.com. Pete

Ah, good! Not too difficult then! Good flying! Pete

Yes, if you are happy for FSUIPC to assign letters for you -- it will assign A, B, c ... etc in that order. Some folks prefer to have letters which remind them of the type of device, like Y for Yoke, T for throttle, R for rudder. In the latter case you don't change the Auto setting but simply reproduce all of the lines in [JoyNames] identifying devices 0, 1, 2 etc and, in the copies, replace the 0, 1, 2 etc on the left of the = by the letters you want. Leave the original lines intact, though -- they are needed to tie the device letter to the device number. Regards Pete

Have you enabled WideServer in FSUIPC? If it is enabled then it automatically updates the FSX title bar. There's no message line -- the title bar is only displayed if you run FSX in Windowed mode, of course. There's no data transfer that was being 'killed'. The server knows nothing about the client. The error you got before, most certainly means that WideClient PC cannot connect to the Server port in FSX. Searching with Google, this is the most complete answer I can find: WSAETIMEDOUT - Error 10060 Product: Version: Platform: All All All Question/Problem: Connection timed out. Answer/Solution: A connect or send request failed because the connected party did not properly respond after a period of time. (The timeout period is dependent on the communication protocol.) Check the obvious first: check that the destination address is a valid IP address. If you used a hostname, did it resolve to the correct address? If the hostname resolution uses a local host table, it is possible you resolved to an obsolete address. Can you ping that hostname? Do you have a router configured? Is the router up and running? (You can check by pinging it, and then ping an address on the other side of it.) Try a traceroute to the destination address to check that all the routers are functioning. Check your subnet mask. If you don't have the proper subnet mask, your network system may treat a local address as a remote address (so it forwards addresses on the local subnet to the router, rather than broadcasting an ARP request locally), or vice versa. I'm sorry that I cannot help more than looking things up. I am not a network expert, and WideFS simply uses basic methods copied from Microsoft examples. Whenever I've had network problems I've had to resolve them by trial and error. Incidentally, Windows Explorer, which you say allows you to access each PCs disks from the other, uses UDP protocol, not TCP. UDP has much less error checking, so you could see if that works. If may be getting so many errors it times out retrying. If so I'd suggest you need a better connection -- certainly not wireless, for instance. I understand that, but FSUIPC does not easily access shift keys like CTRL on their own. It might work if you set it to send Ctrl+A then edited the INI file and changed the A keycode (65) by null (0). This solutin is suggested somewhere in the documentation I think, but not prominently as it isn't always a workable solution. Regards Pete

Okay. some confusion though. You said in your accompanying email but the Simconnect log contains the same two Exceptions as logged in the FSUIPC log relating to the run without "AxesWrongRange=Yes" parameter. So, I suspect you got a little mixed up between these and their relationship to the SimConnect log? The log for the AxesWrongRange=Yes does not show the exceptions, so I think that is the problem. Please, until there's a fix from VRS, use that parameter. It was actually added for VRS. I think that, wothout it, VRS is handling the throttles with incorrect values. It is coded using some offsets in FSUIPC that used to be incorrect but which was corrected when this was discovered, between version 4.70 and 4.742. The fix, in 4.743, for VRS was to add the wrong range parameter to make FSUIPC revert to incorrect values for those offsets. Regards Pete

No, that's okay. I understand now. Pete

Sorry, I don't understand. What is this "virtual comport"? What is it for? how does it relate to WideClient? Are you talking about using the GSPout facility? What is that "Port3" parameter? Wideclient won't recognise that. And Run parameters belong in the [user] section -- that won't work there either. You don't seem to have any [GPSout] section defined, so I've no idea what it is you are attempting. The WideClient log is fine. Nothing wrong there. Using GPSout on the Server? Have you enabled it there and specified WideFS? Without correct parameters in the WideClient INI file nothing will happen. Pete

There's never been any "FSUIPC9" -- we are only up to FSUIPC4 which is for FSX, ESP and Prepar3D. FSUIPC3 is for all older versions of FS. There is no way anything is FSUIPC itself can do what you describe. If it only occurs with FSUIPC then it is either due to settings you've made incorrectly or unwisely (in which case just delete the INI file to remove all of your settings), or due to some third party application which is using FSUIPC. I cannot offer any other advice since you provide no useful information -- not even the version of FS itself or FSUIPC. Regards Pete

Sounds like you've calibrated it the wrong way around. Either that or you are loading a flight which is the mixture position saved as full lean -- it won't necessarily see the quadrant lever unless you move it as neither FSUIPC not FS take notice of static positions, they only use inputs from devices when they change. So you must always save flights with the controls set the way you want them on reload. Pete

What on Earth was wrong with using your own registration, if they were legal? Why not retrieve those instead of illegally using someone else's? Pete

Yes, it is used. It can only be positive (it is declared unsigned as you can see). It it the factional part of the wind speed value, as stated. You wouldn't use it when setting, it would only be seen on certain types of weather reasouts relating to ambient speeds. Cloud base variation, but not actually used by FSX which does its own thing. It works in FS9,. Sorry, on idea about any of that. you'd need to experiment. I suspect it is ignored in FSX. Again, no idea. I don't think it is used in FSX. Unfortunately many of these are questions for the FS team, which no longer exists. FS has only ever allowed weather to be set at weather stations. It interpolates between. FSX does have facilities for programs to create temporary weather stations -- optionally used by Active Sky, for instance, for variable ocean weather -- but this facility is not supported in FSUIPC, you'd need to use SimConnect. Regards Pete

Of course, just test the on ground flag via an event, and stop the sound if it is playing. Add this to the code: ref = 0 near the top , where the other variables are set, and this at the end: function onground(off, val) if val ~= 0 and sndflg ~= 0 then sound.stop(ref) sndflg=0 end end event.offset(0x0366, "UW", "onground") Regards Pete

It looks like some sort of firewall block, because Windows is providing the IP Address (which I assume is correct?) but it doesn't appear then to let anything also get transmitted to the Server? Additionally you are using a very old and completely unsupportable version of FSUIPC: The earliest supported version is 4.70 and the current version is 4.742, with a 4.743 update available in Download Links subforum. Sorry, I've no idea what a "STRG" key even is. FSUIPC supports Ctrl, Shift, Tab, Win, App and Menu as shift functions, and in any combination, but they must be accompanied by one graphic or normal key. (i.e. a non-shift key). You can sometimes get away by putting any old key is then editing the INI file to change it to a "null" instead (keycode 00. Regards Pete

Yes, and I think it is documented too. It is because the keys do not send a "press" and a "release". The same problem applies to all of the VRI devices. You need to assign both the press and release actions in FSUIPC -- both to the same action if that is what you want. Regards Pete

Ah, thanks. Yes I'd missed those! Will fix on next update. Regards Pete