Pete Dowson

AdvDisp folder? Wassat? Do you mean "ShowText"? Sorry, I'm completely lost. I have never made any programs playing sound since Esound.DLL, many years ago. Are you mixing something of mine up with something else? Regards Pete

Unfortunately it isn't that simple. They know it isn't working properly. The whole of the weather module needs a good sort out. It would not be a simple fix, but a major change and nothing they would dare risk as an "update". It would have to wait for FSXI -- and that's where a good level of complaints will help raise the priority. Direct all of your anger and frustration about this (but politely, of course), along with all the evidence you like, to tell_fs@microsoft.com. They do read them all. The more the better on this subject. I think I'm partly to blame for it being like it is. It isn't a new problem in FSX, it was the same in FS9. Exactly. But the fiddles I did in FSUIPC hid them too well and perhaps, as a result, not enough fuss was made by usersDuh! I am pressing hard for either SimConnect facilities to allow me to do the fiddles more, er, "properly", and "fix" it that way, or possibly for a little less-official help in hacking into the horribly complex code which is Weather.DLL in order to do the overrides. But no one is able to promise anything. Regards Pete

Didn't one come with it? You'd certainly need to get it recognised and calibrated in Windows' Game Controllers before using it in FS or FSUIPC. Regards Pete

Sorry for the delay in replying -- as mentioned in the Announcements above, my wife and I were off touring Argentina & Chile (by steam trains where possible) immediately after I returned to the UK from the AVSIM FanCon in Seattle. First is enough, you needn't say any more. There is an FSX installation SimConnect problem. Take these steps: 1. See if there is a file called FSUIPC4.LOG in the FSX modules folder. If so, then at least FSUIPC is being loaded. Show me the FSUIPC4.LOG file. 2. If there is no such file then SimConnect is not even loading FSUIPC4. The error could be in a number of places. Show me the Install log file from the FSX modules folder and we'll go from there. What version of FSUIPC4, by the way? Have you installed FSX SP1 update or the Acceleration pack? If not please do one or the other. Regards Pete

Sorry for the delay in replying -- as mentioned in the Announcements above, my wife and I were off touring Argentina & Chile (by steam trains where possible) immediately after I returned to the UK from the AVSIM FanCon in Seattle. The usual reason is that you have another copy of FS still running, but without any windows. That happens if you have some add-on (a gauge, aircraft, or DLL) which is not terminating all of its threads when FS is told to end. To fix it, use the task Manager (Ctrl-Alt-Del) to find the FS EXE process (e.g. FS9.EXE) and forcibly kill it. To stop it happening again you'd need to find the culprit, by a process of elimination. Regards Pete

Sorry for the delay in replying -- as mentioned in the Announcements above, my wife and I were off touring Argentina & Chile (by steam trains where possible) immediately after I returned to the UK from the AVSIM FanCon in Seattle. The control for that is "HEADING BUG SET", with the parameter giving the heading (in degrees, 0359). The problem you have there is to get the axis calibrated to give exactly 360 increments 0-359, somehow wrapping around at 360 to 0 (and back). I don't think that is feasible. I don't even know of any axes which could provide such a fine resolution, and even if there was it couldn't be easily controlled unless it was very large! Please describe how the axis would actually be used to set specific values, remembering there's no maximum and minimum or centre, it is continuous 0... 3590 ... The control is AP ALT VAR SET ENGLISH, which has the altitude in feet as a parameter (0-65500). The same problem applies here, with an axis. For a range of say 0 to 40000 in 100's you'd need 401 discrete values at intervals of 100. Exact mind, no approximations. Most hardware implementations of these setting knobs use not axes but rotary encoders, which just send an indication of "I've been turned right" or "I've been turned left", on each click. These are then programmed just like centre-biassed double throw switches: using the normal INC and DEC controls. Regards Pete

Sorry for the delay in replying -- as mentioned in the Announcements above, my wife and I were off touring Argentina & Chile (by steam trains where possible) immediately after I returned to the UK from the AVSIM FanCon in Seattle. Have you ever used EPIC and have an EPIC driver loaded with no EPIC device connected? If so try adding "PollEpicButtons=No" to the FSUIPC4 INI file's main [buttons] section. Otherwise it will be due to some constantly flickering button input or a rogue joystick driver. Try the attached JoyView to see what devices/actions it may find. You will have to open each of the 16 devices in turn to see if any are used. Joyview uses the same interface as FSUIPC4 does for buttons. Regards Pete joyview.zip

Sorry for the delay in replying -- as mentioned in the Announcements above, my wife and I were off touring Argentina & Chile (by steam trains where possible) immediately after I returned to the UK from the AVSIM FanCon in Seattle. Can you supply any more information at all, as there's not much to go on here? What function where? A PFC Cirrus 2 uses my PFCFSX.DLL (at least the ones I've seen do). Hasn't that got a version number? Have you tried the latest? What buttons are you talking about and where are you looking? Have you tried PFC support at all, BTW? Regards Pete

Sorry for the delay in replying -- as mentioned in the Announcements above, my wife and I were off touring Argentina & Chile (by steam trains where possible) immediately after I returned to the UK from the AVSIM FanCon in Seattle. If you are calling FSUIPC from a Gauge or DLL within FS, you should NOT be using the external interface with memory mapped files and SendMessageTimeOut, but the special internal interface which is far far more efficient. That uses SendMessage (no timeout), which from a separate thread is treated a bit like PostMessage but making your thread wait for the WndProc exit. So it should still be okay. Regards Pete

Sorry for the delay in replying -- as mentioned in the Announcements above, my wife and I were off touring Argentina & Chile (by steam trains where possible) immediately after I returned to the UK from the AVSIM FanCon in Seattle. Could you please explain a little more about how such offsets (which aren't normal FS functions) are used? Are you simply wanting to use the memory for communication between separate programs, modules, or PCs? And is this for a general product or a specific one-site implementation? Regards Pete

Sorry for the delay in replying -- as mentioned in the Announcements above, my wife and I were off touring Argentina & Chile (by steam trains where possible) immediately after I returned to the UK from the AVSIM FanCon in Seattle. This is normally done for you by FS itself. You shouldn't need to do it yourself. "Ticks" being ...? For FS9 and before that will intercept and disconnect the generic single axis and most of the controls used for the individual ones. I think that on FSX it may only work for axes processed by FSUIPC. Are you calibrating through FSUIPC? No idea. Log axes in FSUIPC and see what the joystick throttle is sending. Please also make sure you are using the latest FSUIPC version. There have been some changes in this area. Regards Pete

Sorry for the delay in replying -- as mentioned in the Announcements above, my wife and I were off touring Argentina & Chile (by steam trains where possible) immediately after I returned to the UK from the AVSIM FanCon in Seattle. Assign them the other way around in the "press" and "release" parts. Pete

Sorry for the delay in replying -- as mentioned in the Announcements above, my wife and I were off touring Argentina & Chile (by steam trains where possible) immediately after I returned to the UK from the AVSIM FanCon in Seattle. Well, that depends of what you mean by "sensitivity". Do you mean you tend to overcontrol, or that you need to move the axis too far? The latter gives more precision, more sensitivity for small changes. The word is rather ambiguous. I would recommend ALWAYS setting FS's "sensitivity" slider to max, i.e, far right. Otherwise you are simply lose most of the range and precision you paid for in getting a decent device. Then calibrate to get the full range used -- you should always be able to produce maximum deflection in both directions. The "S" slopes in FSUIPC enable you to achieve this whilst still having that precision you need near the centre. You should be able to find an ideal setting to suit your device. Then the aircraft sensitivity comes into play -- an Extra will be more sensitive to changes than a 747, for example. Another change which suits most folk is in the stick_sensitivity_mode -- see the FSUIPC user guide about that. "Shoot up in the middle of the axis"??? Pardon? There's nothing in FSUIPC which does that. Why on Earth would you want it to do that? Or am I misunderstand something? In general the only way to reduce sensitivity completely is to limit the entire range so you can't actuall reach the extremes (this is basically what FS's slider does if you drag it leftwards), That really is not good. The whole point of the S shape is to give ideal (i.e. slow) sensitivity where it is normally needed but allow the extremes to still be reached. Regards Pete

Sorry for the delay in replying -- as mentioned in the Announcements above, my wife and I were off touring Argentina & Chile (by steam trains where possible) immediately after I returned to the UK from the AVSIM FanCon in Seattle. No. It is (or rather was) a bug in SimConnect. It sounds like you've not yet installed FSX SP1, as that pretty well fixed it (using a work-around). If you have problems like this you really need to use the SimConnect logging facilities to see what is going on. SP2 / Acceleration fixes it good and proper, I believe. Regards Pete

Sorry for the delay in replying -- as mentioned in the Announcements above, my wife and I were off touring Argentina & Chile (by steam trains where possible) immediately after I returned to the UK from the AVSIM FanCon in Seattle. I doesn't matter what you current Email is. you need to register FSUIPC with the original details, exactly as first notified to you -- same name, email and key. If you don't remember any of this you can read them in your FSUIPC.KEY file. Regards Pete

No, the installer will work without that. It is FSX you have to "Run Asadministrator", but only when you want to Register. Regards Pete

Sorry for the delay in replying -- as mentioned in the Announcements above, my wife and I were off touring Argentina & Chile (by steam trains where possible) immediately after I returned to the UK from the AVSIM FanCon in Seattle. Yes. It is freeware and only needs the free access facilities in FSUIPC. Does this Lowrance device accept positional data, replacing its own GPS receiver data? I don't know many that do. Often the NMEA input feature is merely for routing and other information. I have three GPSs and none accept positional data, they all use their own aerial inputs with no override. Incidentally, with all of those sentences enabled (GLL, RMC, RMB, GGA, GSA and GSV) you are trying to send around 500 bytes at every interval, which at the usual default speed of 4800 bps will take well over a second, so you would need to set the interval to at least 2 seconds, or better delete some of that superfluous data (much of that is repetition). Regards Pete

Sorry for the delay in replying -- as mentioned in the Announcements above, my wife and I were off touring Argentina & Chile (by steam trains where possible) immediately after I returned to the UK from the AVSIM FanCon in Seattle. Sorry, the 5 seconds must be in your program somewhere. I cannot debug your program. Add some code to find where the time is going. I'm afraid I cannot really help with VB (.NET or otherwise), but if you present your code examples I am sure others here will be able to help. Regards Pete

Sorry for the delay in replying -- as mentioned in the Announcements above, my wife and I were off touring Argentina & Chile (by steam trains where possible) immediately after I returned to the UK from the AVSIM FanCon in Seattle. Each "FSUIPC_Process" call requires Windows to change from your process to FS, then back again when the response is ready. Therefore you only do one FSUIPC_Process call per update cycle, accumulating all of your different reads and writes before hand. No, sorry, that's actually pretty awful. To start with, what is setting "running" to FALSE to get the loop stopped? Second, why add millions of reads of the same value to the one process call? Third, there is no point at all in using the value you think you are reading with the FSUIPC_Read until the Process call has been done -- all the read and Write calls to is list the request. Nothing more. More to the point, all of your "FSUIPC_Read" calss (for all the values you want) should be grouped before one FSUIPC_Process call. It is the latter which actually does it. "Very" slow? 5 updates per second is too slow for your needs? Why exactly? The requests to FS for data are prioritorised. Some things are requested more often than others in order to even the loading and prevent performance degradation and jerking. However, that said, I'm pretty sure this one is one of those which was changed recently. What version of FSUIPC are you using? If not the latest, try updating. Note that new versions are often provided in the downloads Announcements above. Regards Pete

Sorry for the delay in replying -- as mentioned in the Announcements above, my wife and I were off touring Argentina & Chile (by steam trains where possible) immediately after I returned to the UK from the AVSIM FanCon in Seattle. You can have both SPX and TCP installed, you know. Why are you wanting FS to use SPX? The IPX/SPX protocols are less and less well supported by Microsoft. On one of those 1,000 times, did you happen to notice this part: In your case WideServer would not have run that program because the Node "looks" right (the 0.0. at the start). but maybe you could run it yourself and see what it says? I say this because from this, in the log: 190 Trying IPX/SPX on Port 8002, Node 0.0.1024.50958.40348 ... 6179 Error on client pre-Connection Select() [Error=10051] Network is unreachable it seems pretty conclusive that the 0.0.1024.50958.40348 node ID is incorrect. There's probably a router or another network card making that invisible outside the server PC. Ouch! 6.70 hasn't been supported for a long time now. Please always make sure you are using current versions. Pete

Sorry for the delay in replying -- as mentioned in the Announcements above, my wife and I were off touring Argentina & Chile (by steam trains where possible) immediately after I returned to the UK from the AVSIM FanCon in Seattle. Er07F2 contains the MCP-set V/S, to tell the A/P what vertical speed to attempt to attain. If you are only "reading" it what do you mean by "assigning another speed"? FS does not change it without notice, it only sets it to the aircraft default VS when you enable an altitude change (or the Altitude value is set to other than the current reading when in Alt Hold mode). When attaining the set altitude the V/S is reset to zero. Yes, 1800 is the default for the supplied aircraft. I'm pretty sure the default can be changed in the Aircraft.CFG files. What do you mean "no more"? The V/S can be set to anything withing the limits for the specific aircraft. For instance for the Boeing airlines it is something like +6000 to -6000. There are many add-ons using and setting this, and, in fact, the panel gauges do the same. Maybe you are setting it before setting the altitude hold and target altitude? You set those first, then adjust the V/S as you wish. Regards Pete

Sorry for the delay in replying -- as mentioned in the Announcements above, my wife and I were off touring Argentina & Chile (by steam trains where possible) immediately after I returned to the UK from the AVSIM FanCon in Seattle. FSUIPC is not usually needed to make gauges appear. Only a very few add-ons use FSUIPC for gauge functions. Well, more likely it means SimConnect is not installed properly, and that will affect a lot more things, not just FSUIPC. I need to see some information before I can even begin to help. The Install Log for FSUIPC, the FSUIPC4 Log itself, and (since you say you tried most things already), the SimConnect log you must have by now ...? (If not, see the FSX Help Announcement). Regards Pete

The installer doesn't need that. You only need to use that trick, on Vista not XP, when running FSX to register FSUIPC or WideFS. Regards Pete

Sorry for the delay in replying -- as mentioned in the Announcements above, my wife and I were off touring Argentina & Chile (by steam trains where possible) immediately after I returned to the UK from the AVSIM FanCon in Seattle. You have only the SP1 SimConnect present. That is insufficient. You need to follow the SimConnect repair suggestion given in the FSX Help Announcement above. Regards Pete

Sorry for the delay in replying -- as mentioned in the Announcements above, my wife and I were off touring Argentina & Chile (by steam trains where possible) immediately after I returned to the UK from the AVSIM FanCon in Seattle. The client log shows that the connection is not good: 1250 Trying TCP/IP host "CHRIS1" port 8002 ... 1250Okay, IP Address = 192.168.1.2 7156 Connection made okay! 24906 New Client Application: "FSC82" (Id=3372) 43265 Timed out response: connection assumed lost! 43312 Ready to try connection again 43328 Timed out response: connection assumed lost! The Server log confirms it. In fact every single attempt to send anything is being stopped. 22609 Connected to computer "CHRIS3" running WideClient version 6.750 (skt=9436) TCP 22719 Auto send stopped before sending all data (0 of 381 sent), Error=10038 (skt=9436) TCP etc So, I'd guess that something is blocking the data on the Client end. The Server is receiving data okay from the client -- else it wouldn't have its name and Client version number. So, the firewall or something is set incorrectly on XP. Yes, that phenomenon is described clearly in the WideFS documents and is due to the client trying to reconnect on a shorter timeout than the one the server is using when giving up unresponsive clients. It is an expected result, as described. Regards Pete