Pete Dowson

There are examples of programming in VB in the SDK. There are also a couple of "sticky" threads above dealing with Basic, and many individual older threads with questions answered. But no "scripts" as far as I know -- you need to program. Regards Pete

You have the Simconnect.ini file incorrect then. Just open a "New" file in Notepad, and cut and paste this: [simConnect] level=Verbose console=No file=C:\SimConnect%01u.Log file_max_index=9 then save it as "simconnect.ini" in your "My Documents\Flight Simulator X Files" folder -- where all your Flights and Plans are saved. This is why I would like to see the Simconnect log. Right. There are problems with some FS9 aircraft in FSX, but whether they can cause your symptoms I don't know. Regards Pete

AhI take it you are new to FS altogether? This was of course no different in any previous version of FS, except that the menu entry was "Modules" instead of "Add-ons". Incidentally, 'hide menu' is an option both in full screen and windowed mode -- the mode makes no difference, that only affects whether there's a Title Bar or not. The other menu bar difference with FSX compared to previous versions is that you get rid of it, once shown, by holding the ALT key down for a couple of seconds. I need to see the FSUIPC4.LOG and WideServer.LOG from the FSX Modules folder, and the WideClient.log from the folder in which you placed WideClient on the client PC. If there's no connection at all it sounds like a firewall problem. Maybe that's all the Logs will show. Regards Pete

Okay. That's good -- thanks for letting me know. Pete

Your mailbox is full and won't accept my direct email!!! Your message here had to be deleted as it contains your personal Key details, private to you, I have deleted it directly. You are in direct violation of the purchase agreement, not to disclose your private key The answer to your question is that FSUIPC4 is for FSX and FSUIPC3 is for FS9 and before. They are NOT the same product and do not use the same keys. Please do read some of the Announcements and documentation which have been around for many months! Pete Dowson

If the Add-Ons menu is not there then FSUIPC4 may not even be running -- WideServer is part of FSUIPC4 so that cannot run until and unless FSUIPC4 is running correctly! It sounds like a SimConnect problem. For more information, so I can advise you correctly, please show me the Install Log and the FSUIPC4 log files from the FSX Modules folder. Regards Pete

One thing that occurs to me which makes it more important to try 4.156 before "retreating" to FS9, and that is that the problem could, just possibly, be related to the business of axis interception, and loops which Simconnect could be made to perform depending on how you use FSUIPC's joystick calibration and axis assignment facilities. This area has been specifically improved in 4.156. If you don't use either of these then I don't think it will make much difference, but it is still worth trying. Please let me know. Regards Pete

No, sorry, I saw that, and ignored it, because Emile did NOT actually say that. Please go back and re-read. He had a crash then went and looked. He never said "only". You can go look at the event log and find every single time you loaded FSX, with FSUIPC -- 4.152 or later -- installed, you will get those errors. It is actually impossible not to unless you have the appropriate SimConnect Betas installed. Please do read my explanations of why this is so. Regards Pete

Well, the log certainly shows that something you are running is clogging up SimConnect, well and good: There's really nothing I can do with that -- either your aircraft add-on isn't working very well, or there's a problem in SimConnect, or it is just that your PC cannot cope with what you are asking it to do. To check on the first two I'd need to see a SimConnect log. For this please see the "FSX Help" Announcement above -- when you have a log, ZIP it up (it will be very large) and send it to me at petedowson@btconnect.com. I should be able to tell if it is a SimConnect or add-on problem. Not that would be any different with this, no. Actually there's a later version -- 4.156 -- from the FSX downloads above. Try that, by all means. If it helps at all it will be because of something the add-on aircraft is doing. I'd like to understand thatr, so a Simcopnnect log would still be useful, please. Why? Is it so essential you use this add-on aircraft, if it is only that causing the problem? Is it one designed to work in FSX by the way? If not it might be an incompatibility problem in the first place. Regards Pete

Okay, please let me know how you get on. Really, it is a bad sign if the time-out is occurring, and extending it as a work-around, whilst getting you past the problem, is not an ideal long-term solution. Hopefully updates to FSX will alleviate this sort of thing, but in the end it is a processor limitation. Regards Pete

Unfortunately there appears to be no provision for preventing these log entries, nor is there a facility I can use in Windows XP or Vista which allows me to check for a valid SimConnect version without actually "trying" its context, which produces three Error entries each time. Basically, therefore, there will always be a multiple of three "Error" entries whenever FSX is loaded with FSUIPC4 present and the latest version of SimConnect which that FSUIPC4 version supports is not installed. To understand this, look at the current set of SimConnect releases understood by FSUIPC 4.156 (this will vary depending on FSUIPC4 version): 1: Acceleration update (add-on), Beta1 2. Acceleration update (add-on) Alpha 3. FSX update SP1 4. Original release It tests for these in that order. Since only Beta testers will have the first one or two, currently there will be 6 "Error" entries, 3 for each of those two. If the user has not installed SP1 there will be 9. When the Beta period is finished and Acceleration is released, a new version of FSUIPC4 will be provided which will have only these listed: 1. Acceleration update (add-on) 2. FSX update SP1 3. Original release Then those who purchase and install Acceleration will get no error entries, those with SP1 as the latest will get 3 entries, and those with only the original installation will get 6. When the next update for FSX (SP2 or DX10?) is available the list for the matching FSUIPC4 will have that as number 1. I'll leave the Error counting to youyou can see how it goes by now. And so it goes onthe big advantage is that FSUIPC4 will continue always to work with older versions of FSX whilst still being able to take advantage wherever possible of the latest changes. This is the purpose of the SidebySide installation system. The only disadvantage, it appears, is the appearance of these Error log entries and the annoying confusion it creates for those users like you who look for them. Maybe I need to document this someplace, though getting folks to read documentation is difficult anyway! ;-) Regards Pete

Both 05EB and 05ED are documented as 1 byte offsets, yet you are writing 2 bytes for 05ED. The second byte will cause something to happen at offset 05EE, which controls the pitch. You said that the roll and yaw were affected, which seems odd. Are you sure it isn't a high speed pitch change? Try using 1 byte writes of 05EB and 05ED then get back to me. Regards Pete

It should certainly all work well in FS9. I have an Aerosoft GA28R cockpit with a driver which uses those offsets to provide slewing facilities using the yoke, and that works fine. Do you perhaps have any axes assigned to slewing which may be off-centre when slew mode is engaged? Just check that setting slew mode from the keyboard ("Y") doesn't do the same. Else, I await the Log to see what is happening. Regards Pete

Is this with FSX or FS9? If it is in FSX it may well be my error, as these have not been fully tested yet, I'm afraid (there's been so much to test/develop still!) Could you please enable IPC write logging, and also set the FSUIPC monitor to monitor 05E4 (type S16), 05E6 (S16), 05EB (S8) and 05ED (S8) to the normal log, then reproduce the problem and show me the LOG file? Also, as soon as you confirm FSX (or not) I will try to check it here. Regards Pete

Amazing! Well done! :-) Pete

This sounds like the data being sent to FSUIPC4 from SimConnect is being prevented from arriving in the time allowed. By default, if FSUIPC doesn't receive data about the user aircraft at least once per second (except when in Menus and the like), it assumes Simconnect has disconnected, and so reconnects. It does delete its menu entry and re-set it, but if the earlier connection is broken obviously the deletion of the original entry won't work. Please check the FSUIPC4.LOG file, which you will find in the FSX Modules folder. It will show exactly what is going on. It may be that the aircraft you are loading is putting a really heavy load in FSX, possibly also Simconnect, and generating periods exceeding a second where nothing much else gets done. Does this seem feasible from what you see? Are you getting good frame rates with this add-on aircraft, or does it vary a lot? It may simply be overwhelming your processor. Are you using FSX + SP1? If you haven't yet applied the SP1 update for FSX, you should do so. It is rather more efficient. The next update for FSX should be even better still, especially for Simconnect clients such as FSUIPC4 (when I can get a matching update out to take advantage of it). Meanwhile, you could try making FSUIPC4 more tolerant of bad performance by changing this parameter in the FSUIPC4.INI file: SimConnectStallTime=1 This sets the 1 second time out. Try 5, say. If that fixes it, try 3, then 2. You want it as small as possible really. Regards Pete

Of course. The side-by-side "assembly not available" errors will occur every time you load FSX with FSUIPC4 installed. They merely refer to the versions of SimConnect which FSUIPC can handle but which you don't have installed. Please check the times of those entries. Please yourself, but I think you'll find that it is completely and utterly irrelevant to your problem. As I already explained, if you'd care to refer back, FSUIPC looks for a number of different releases of SimConnect, and uses the one it prefers from those it knows. In the course of checking their presense, Windows in its wisdom, logs these errors. They mean exactly what they say, that FSUIPC has tried to connect to a specific version of the DLL and failed (because it isn't present) -- that error is actually returned as a result of the calls FSUIPC makes and this tells it that that version isn't present, so it proceeds to the next one. It is absolutely nothing to do with any SDK -- the SDK isn't even provided to FSX users of the non-Deluxe version. FSUIPC 4.156 supports 4 different versions of the SimConnect.DLL. This will vary from release to release as Beta versions are superseded, but on the whole it will simply grow. The "Acceleration" expansion pack option will add another, as will the DX10/SP2 update later. Since it worries you so much I will have a further look to see if the error can be prevented from going into the Log, but even if there is a way of doing it, it won't change anything else about what FSUIPC4 has to do in this area. You please yourself what to believe. You are misinterpreting what you are reading, or simply not reading what I am writing, so there's no point in me trying to say much else really, is there? Pete

Sorry, I've no idea. Does BlueTooth look like a normal serial port to applications? If so GPSout may be able to send to it if you have the port name (COMx perhaps?). What might be more difficult is telling the other end how to receive it! Regards Pete

Your yoke must be on the PC running FSX. There is no advantage to having it on a Networked PC -- in fact there is a disadvantage in that the latency (delay) in the action in the aircraft of manipulating the main flight controls will not be acceptable, except possibly in the more normally sluggishly-responding aircraft. Buttons, switches and so on are supported via a network through WideFS, but I don't support analogue axes that way for the above reasons. Regards Pete

The log explains the Button on line 13: 2119891 [buttons] 13=R1,32,C65734,0 2119891 FS Control Sent: Ctrl=65734, Param=0 2119891 *** EVENT: Cntrl= 65734 (0x000100c6), Param= 0 (0x00000000) PAN_UP It was button "32" on joystick #1 (that's the second one down in Joyview). FSUIPC follows FS2000's (and before) convention for numbering Hat positions from 32 (Forward, or North) clockwise through 45 degree steps to 39 for Forward Left, or North West. You had the North/Forward position of the Hat programmed to send C65734 (PAN_UP) and to repeat whilst held. The problem appears to be that this hat position is permanently held. That is wrong. When released a Hat should return a "released" or "null" value (actually 65535, as would be shown in Joyview, for instance). I think this would explain the problem in CH's "mapped" mode too -- I suspect it does the Repetition of the Hat Forward indication itself in that mode, so providing a constant repetitive "button pressed then released" indication, effectively hanging FSUIPC's test loop. Basically, you have a faulty Hat which appears to be stuck in the "pressed forward" state. Maybe there's some gunk in it causing a short, or it's spring or whatever is bent? Worth checking to see if it is easy to repair. Use that "Joyview" program to see what it is doing. Normal values are: Btn Direction Value 32 FWD 0 33 FR 4500 34 R 9000 35 BR 13500 36 BCK 18000 37 BL 22500 38 L 27000 39 FL 31500 OFF 65535 The fact that FWD is a value of 0 does strongly suggest a short circuit, so it may actually be in the wiring someplace rather than the hat itself. Regards Pete

Same here. Nevertheless, when I open them, and check the "joyGetDevCaps()" entry, several of them show values, including a "product name" -- for example "Microsoft PC-joystick driver". Not sure why "None" is shown in the main folder-type section -- probably something different in XP. The program is really a Win95/98 one. Open each in turn, see what you can find. You need to open them and select "joyGetPosEx()" to see values being read, including buttons. If a button or hat (whether real or not) is constantly triggering (i.e. going on and off) it will certainly keep FSUIPC's scanning in a tight loop, as it is designed to react to the last such change -- when there's always another change it will re-display it, even if it is the same as before. See what you can find. I could probably code around a continually repeating button/hat input, to avoid hanging FS, but I can't think how I would be able to get to other buttons for programming then if that keeps taking precedence. It would need some thought -- it certainly should not be happening (and in fact I've not had such a case in the 8 years of FSUIPC's button scanning). It must be a fault someplace, assuming it isn't a rogue driver. Regards Pete

FS only provides a normal analogue throttle, not a fly-by-wire discrete mode selector. Anything simulated like that by the add-on with have controls determined by that add-on -- maybe there are keystrokes, or maybe it determines them by using little ranges of values in the "real" analogue throttle inputs. I don't know. You'll have to check its documentation. Either way you should be able to handle it. Regards Pete

Oh, one thing which may help identify the problem is the attached small program, "Joyview", originally from Thrustmaster I think. This uses the same scanning system as FSUIPC and may give you more information, such as the driver name and so on, if it doesn't cause it to hang too. Regards Pete joyview.zip

This sounds very much as if you have a driver installed for a device which isn't present, and the button scanning is causing that to hang. In FSUIPC4 the buttons tab scans using an older Windows API whilst the axis assignments uses DirectInput. (In FSUIPC3 both use the older API). Check in Windows Game Controllers, see if there's an old unwanted driver still installed. Regards Pete

So you can program a button to use the FSUIPC added control "Offset Byte Togglebits" with Offset x7b91 and parameter 1. Alternatively, if you are programming a switch instead, use "Offset Byte Setbits" to set Stby and "Offset Byte Clrbits" to set Normal, both with offset x7b91 and parameter 1, again. I think this is easy enough without needing a specially named control as well, don't you? Regards Pete