Pete Dowson

Hmmm. Can't detect any connection at all here. Can you reproduce that with FSInterrogate? Please enable FSUIPC4's IPC read and write logging, and also Monitor those offsets (to the Log) and run such a test. Show me the results -- or if the log is large, Zip it and send it to petedowson@btconnect.com. Make sure, please, that you use the latest version (4.023 here at present, or 4.026 later tonight), and a default aircraft. Regards Pete

A member of the Microsoft FS Team has posted a message on the FSX forum about this. See viewtopic.php?p=353243. However, please also note that Firewalls should no longer present any sort of problem for local SimConnect clients such as FSUIPC4, provided that you either apply the FSX Acceleration add-on, or apply the free SP2 update when it becomes available, and use a revised version of any add-ons which are designed to take advantage of the new SimConnect features. Version 4.20 of FSUIPC4 is available now and, whilst still running okay on FSX original and FSX+SP1, this is ready to take advantage of the improvements in SimConnect in Acceleration / SP2. Regards Pete

Same PSS airbus, or a different aircraft? I'm in the midst of preparing a proper revised interim release, 4.026, which will include that fix. I'll put it up into the FSX downloads announcement later tonight -- I'm just out for a couple of hours. Please check there either later (certainly after 00:00Z, or more reliably in the morning). Thanks. Regards Pete

Good. Seems that the mailslot broadcasts just aren't getting through then. That's odd. Ah, so they were different? Is it possible that after changing that and re-testing you still had AdvertiseService=No (or 0) in the [WideServer] section of the FSUIPC4.INI file? Regards Pete

Ahin that case it isn't related to the initialisation issues we are investigating. There is a small chance that it could be a Simconnect problem, but I'm afraid the address is actually in a general library routine so it could be due to anything. The only answer is to tell MS I'm afraid. With it not being reproducible its going to be difficult for anyone to pin down in any case, so we just have to hope that they do get sufficient information over a period. In that case FSUIPC4 isn't actually doing anything except being the recipient of messages from Simconnect, with which FSUIPC simply updates its oinformation in case any application needs it. If the crash is down to an add-on, then the Traffic changes are more likely. There have been many subtle changes in the AI traffic system and no one is really very sure how compatible it is with files made for previous versions of FS. However, if you have only had it happen once so far there's not a lot of point, at present, in trying to eliminate anything by uninstalling. Regards Pete

Well, I would expect WideFS to make a small dent due to its parallel use of the Network -- usually that would be hidden by limiting the frame rate to suit the client PCs, to get a nice even update rate all round. Until FSX can match the sort of rates you are likely to want to limit it to (20 fps or more, minimum) then I'm afraid that's going to be a fact of life. But I am very disappointed in the performance of the user release of FSX compared to the Betas, on which I could barely measure any impact of FSUIPC4. I am in conversation about this with the guys in MS working on SimConnect. Incidentally, I was pleasantly surprised that, in fact, I got much more of a boost from updating my nVidia video drivers to 91.47 (October release) that the hit from FSUIPC4. Also, there are many tweaks which all told can substantially increase your frame rate and make it very flyable. Check places like http://www.fox-fam.com/wordpress/?page_id=41 and http://www.fsstation.com/articles/flighweaks.html. Yes, that's a bug in the weather setting facilities, and was bugged before release but the MS team wasn't able to fix it in time. It isn't noticeable if you can get the frame rates high enough. Don't you also get the sky flashing as weather is updated? That happens here even using MS's downloaded weather with auto-updates, and it happens quite frequently then as the previous settings supposedly smoothly "morph" into the new ones. Don't you also get bad stutters when autogen pops up? For smoothest flying you need the autogen turned well down (though some of the tweaks above do save having to turn it off completely). I'm not sure, but with WideFS running you may be better re-enabling HT. Also, FSX does make a bit of use of dual processing -- it is multithreaded -- just not enough in most folks opinion. Try it and see. Ahmy slowest FSX macine is running an ATI XT800. I've changed the ones I really fly on to nVidia 7900 or 7950 cards. Even a 7800 card would be faster, unless you stay with ATI but move to their current generation (1900? Not sure of ATI numbers I'm afraid). And the 256mb you have on that card is about the minimum which FSX seems to need. It is looking like video memory is one of the main bottlenecks now. Looks for 512mb. Anyway, on the software front, we are all hoping that there will be an update from MS, but we have no confirmation of this and there's nothing known about timescales. I just hope it won't take a year like the FS9.1 bug fix took! Regards Pete

No. None of the versions of FS so far have allowed us to do thatwell not with any degree of certainty. Pausing doesn't really have any useful effect in any case. FSX does have a facility to set the speed along with poition and orientation (and FSUIPC4 uses it to provide it as a new facility, even assuming the current position and orientation if that's what is needed), but this effectively acts like starting a flight -- you'd get a loading progress bar, for instance, so it can't be used within a flight, only as a situation starter -- good for Instructor Stations though. In FS2004 and FS2002 you cannot influence the speed using the old FS98-compatible offsets. They are only read-outs. Writing goes nowhere. You may have more luck writing to the velocities and accelerations in the offset ranges 3060-30B8 and 3178-31D0. Those go direct into the Sim Engine. Some of those have been used successfully for things like aircraft carrier catapulting and hokk braking. However, even those effects are likely to be temporary, as the sim engine regains control in its computation loops. You may have to repetitively write values. By all means experiment, but I'm afraid I don't hold out much hope. If your application is for setting up training situations then take a look at the FSX offset status document (in the FSX downloads above), at offset 0558. Regards Pete

Well, of course, seeing that the whole purpose of FSUIPC is to provide compatibility across different FS versions, the offsets list in the existing SDK is still valid. However, in addition to that there are new offsets with more information available, and some which aren't currently working. There's a document in the FSX SDK which lists the entire status of the offsets for FSX, and that is what you need. As with most of my stuff for FSX this is available for download in the FSX downloads announcement above. Please do peruse the announcements here from time to time. That's where all these things appear or get announced. ;-) Regards Pete

Yes, that looks it. Have you tried switching on the graduated visibility facilities in FSUIPC yet? Pete

The address isn't one that I've seen occur at all in any crash yet. But there appear to be a few bugs in SimConnect which we are trying to nail. Can you tell me more about the circumstances. i.e: 1) when it occurs 2) what else is installed over and above the base FSX 3) whether you've registered FSUIPC 4) show me the FSUIPC4.LOG please There are some other things tthat may help but they start to get complicated, so let's see those first please. Regards Pete

Ah, okay. Good, then, for nowif it happens again though, please, latest version, Logs. Regards Pete

Could you use 4.02, (or, better 4.023 available here) please, and let me know? I cannot really investigate problems with old versions. The TAS is read directly from SimConnect and is always okay here --- can you tell me what is wrong with it when to see it "not working"? Is it non-zero and static, or zero, or changing but a wrong value? Note that you cannot necessarily go by the default FSX gauges. I notice that the "TAS" in the ND of the default 738 is actually the IAS -- it is identical to the speed indication on the PFD! If you do get an incorrect indication, please enable IPC Read logging (in FSUIPC4's Logging page) and repeat the test so I can see just what that gauge is reading. If the log is large please ZIP it up and send it to petedowson@btconnect.com. Thanks, Pete

Good! Thanks for letting me know. Regards Pete

Thanks. I see what is happening. The Airbus is, indeed, using FSUIPC to disable the aileron and elevator axes, and then it reads the axis values I provide, and sends them to FS, again via FSUIPC -- with, presumably, possible modification in the middle according to the fly-by-wire needs. Because, in the Unregistered version of FSUIPC4, the axes are not being intercepted, it can't disable them. This is why I was confused -- since it couldn't disable them, they should workbut, no! Because FSUIPC isn't intercepting the axes, the values it provides to the Airbus are zero -- they simply never get set. So the Airbus code sends a constant stream of zeros to the aileron and elevator. This results in what you are seeing -- mostly no movement but with an occasional blip when on of the Joystick scan values gets through. The only answer is to enable the axis intercepts, which, in an unregistered version of FSUIPC4 needs a change. I'll send you an interim version which supports an "AxisIntercepts=Yes" parameter, which you will need to add. Regards, Pete

Ah, good. I couldn't think what else it could be but a firewall. Thanks for letting me know! Pete

Okay .... it sounds like the PSS depends upon FSUIPC's interception of the axis controls in order to operate the fly-by-wire. I have options in FSUIPC that allow it to disconnect the main flight controls from FS and interpret them itself. The default unregistered behaviour in FSUIPC4 since 4.02 is to leave all the axes alone. So any attempt at fly-by-wire in the PSS aircraft, using the FSUIPC facilities, won't work. This step in FSUIPC is, I hope, temporary, and is there simply to avoid me getting inundated with non-registered users complaining that their joystick response times were ridiculously long, due to the Simconnect security problems. What I find puzzling still, though, is that you say that you can actually fly the Airbus without FSUIPC and without fly-by-wire? Does that mean you can turn the fly-by-wire action off? If so, then you should be able to do the same with FSUIPC installed, shouldn't you? I'll add another INI file parameter, "AxisIntercepts" for unregistered users (only -- registered users already have the reverse control, "NoAxisIntercepts" so they can turn them off). Then you can add "AxisIntercepts=Yes" to the [General] section of the FSUIPC4.INI file in order to regain fly-by-wire. Hopefully there will one day be a Simconnect update and I can discard all these horrible options and make it work out of the box! Regards Pete

That's the thin cloud layer which FS9 puts on the top of the surface visibility when it is below something like 10 miles or so (sorry, not sure of the value). It is intended to look like a fog bank, but it covers only an area entending from the aircraft position to the "cloud visibility distance" set in your weather sliders (Options-Settings-Display-Weather). Microsoft did this is response to all the complaints than in previous versions you could climb out of fog, then look down and see the ground sharp and clear. Really? It's always been in FS9. No, though you can change the size of the layer as I just said. The graduated visibility options aren't advanced. You can just switch them on. Take a look. Regards Pete

Shows the same -- just nothing reaching it from Wideclient. It does show you are using FSX though, which may have been useful information in the first place? ;-) I notice the Server name is spelled HOME-SERVER is the Server but home-Server in the client. Not sure if that makes any difference 9it does get the IP address -- is that correct), but I have been told of one case, in Windows Vista, where the case of the letters in the names was relevant. Can I see the Wideclient.INI file please? Regards Pete

You've only shown the client log. That's only half the story. Does the WideServer Log show anything useful? The client seems to be just hitting a brick wall. Maybe a firewall problem in the Server? Possibly something you've updated, or automatic windows updates? There's no errors logged, but I've noticed that with firewall problems. Rather than return anything , which I assume might lead an attacker to think there's something there, you just getnothing. No response, nothing. But look at the server log. then check your firewall. Regards, Pete

In that case the main change for you in FSUIPC, in 4.02, is that it doesn't touch the axes -- like the other controls it monitors them for logging, but it doesn't intercept them. Before 4.02 they were being stopped in FSUIPC and then re-issued, after possibly being calibrated or re-shaped. All that is now not invoked for unregistered users. It uses FSUIPC? do you know what for? I'll be needing information from PSS then. You say it works better WITHOUT FSUIPC, so what is it using it for? Oh, right. But with FSUIPC you can move ailerons etc in other aircraft? The very first release, 4.00, was only available for a few hours. The only two official user releases have been 4.01 and 4.02. The 4.023 you are using is an interim version. I need the Logs in any case, please, as described. And some information really about what PSS is doing with those controls. It is presumably part of their "fly-by-wire" system, but I need to know what so I can see what'sc changed. Could you also try with the official 4.02 release please in case it is only a side-effect of something in the streamlining I did, for better frame rates? Oh, one more thing -- could you enable IPC Write logging as well, when you try the Airbus. I have an idea what is might be, but i need to see where they are writing. I've also a strong feeling that, if my idea is correct, you'd actually have no such trouble if FSUIPC4 were registeredif you can send me the logs this evening so I can check, I may be able to email you a test version later tonight. Regards Pete

Any log for me to look at? I know of no issues with any axes in this version. The only possible problems I know of with SAimconnect at present are: 1) FSUIPC cannot run at all -- no Add-Ons menu, nothing. In this case there would obviously be no effect of having it there. 2) Intercepted controls, like axes is intercpeted by a Registered install of FSUIPC for joystick calibrations, can, on a very few systems (so far) appear to be delayed, with a delay increasing from a few seconds up to 30, as has been reported. I've not managed to reproduce this on any system so far, but it has been reported to MS. You don't say whether either of these things are happening, nor even if your FSUIPC is registered. Can you give some more information, please? If you have registered it, have you been calibrating your controls in FSUIPC or not? The main change is that in an unregistered FSUIPC none of the axes are now intercepted by FSUIPC, so that it has no influence at all. Only if you register FSUIPC do you get an interception, but then you can still add a parameter to the INI file to stop it if your system suffers delays because of the Simconnect problems. In other words, the change (which actually occurred in 4.02, the current official user release) is to avoid problems with axes, not to create them! ;-) The current official version is 4.02, but that will be replaced by 4.03 when I am sure there are no known problems with 4.023 etcHowever, to make any progress I need information when folks do get problems. So, could you please tell me: 1. Is there an Add-Ons menu containing the FSUIPC entry? 2. Have you registered your copy of FSUIPC4? If yes to those: 3. Have you been calibrating your joysticks using FSUIPC4? 4. Can I see your FSUIPC4.INI file please? 5. Can you, briefly, enable Axis logging (in the Logging tab of FSUIPC options), and use your axes a little, first with a default aircraft, and then with the PSS aircraft, seeing it not respond whilst the default one does? If any of the files are too long to show here, ZIP then up and send to petedowson@btconnect.com. Also, could you tell me, is this PSS aircraft actually one converted to work correctly in FSX, or just one transposed from FS9? I may need help from PSS to get to the bottom of this in any case, so have you also posted on their site -- you can point out that you have me looking too. Regards Pete

That is really weird. Well, I'm glad you have a work-around, but I wonder what on Earth it could be? I don't even know how to detect which mode FS is in! Unless they come up with a Window you have to respond to, and that is hidden in full screen modecould that be it? I get one when I try the driver, but then I've got no Elite equipment, so it is bound not to like it. Regards Pete

First, I don't understand why you included the picture. What are you trying to show with that? Second, all the "Offset" controls are in among the 'O's" in the dropdown controls list, which shows all of the FS controls and all of the FSUIPC added controls. They are sorted in alphabetic order. There are hundreds of controls -- just hit the drop down button then enter "o" in the box to get to the O's quickly, and then scroll to find the right one. Drop-down lists are a standard type of Windows control. You've surely had cause to use one before? Otherwise get back and I'll try to find the appropriate Windows help. Regards Pete

Ah, I've checked. I think they may be getting cleared if it doesn't get a connection. I'll fix that if so. Possibly, as you are using a USB device, it was asleep or not connected one time. Thanks, Pete

Erthere are TWO values for the middle "Set" button. Don't you see them, one under the other? They define the RANGE for the Arm position. You cannot expect to find an exact position which always gives an exact value, and even if you could find it, values vary very slightly all on their own. This is why I carefully prepared numbered steps in the document for you to follow. Please just follow them exactly. This is the relevant one: Regards Pete