Pete Dowson

Hmmmstrange. I wonder how that happened. Certainly it isn't anything in my installer changing your entire file system. Anyway, I am making some changes to try to IMPOSE the attributes I want on the files my installer installs. Those changes will be in the next update, whenever, so please be sure to let me know how they work on your setup. Thanks, Pete

Strange. I think the "graying out" actually means that the attributes are being imposed by virtue of attributes for the folders above being inherited. If so, it could all be some strange result of how FSX itself is installed on your system. Have you checked the attributes of other FSX folders to see? Regards Pete

Yes, it sounds like you are getting something wrong. The name, email and Key must match EXACTLY to that which you'll find on the receipt. Use cut-and-paste if you are not sure. Please also make sure you are NOT using version 4.00 of FSUIPC4, though that is unlikely as it was only available for a few hours. If you still get a problem, write to me at petedowson@btconnect.com. Tell me exactly what you are entering and show me the receipt. I can cross-check it here. But I can tell you that all such incidents for the last three years and more have been simply down to the fact that folks were entering their name differently. Regards Pete

Does their driver use FSUIPC? What is the name of their program? Is your FSUIPC user registered? If you'd like me to check, try again, then close FS2004 and show me the FSUIPC.LOG file (you'll find it in the FS Modules folder). Regards Pete

Very strange. The folder is created by FSUIPC's installer with default properties. I'll check to see if I can deliberately "unhide" the folder in case it is getting the property from its parent, though that seems unlikely too. Yes, that's correct. Access denied? Even stranger. Why were you trying to reinstall the same version again, by the way? And howw long (how many seconds) after closing FSX did you try this. I have noticed that FSX closed its Wndow and seems to disappear quite quickly, but, presumably because of the sheer amount of clearing upit has to do, the process itself doesn't finish for anything up to 20 or so seconds later. If that was the case, and for some reason you tried to re-install FSUIPC4 then the "Access Denied" error may have simply been because the module was effectively still loaded in tthe closing down FSX process. I don't know how Windows is doing this, because even if the file does get marked "read only" the installer deliberately unmarks it before trying to replace it. I have a fgeeling that this may be an indirect result of trying to re-install it whilst it was still running. Why are you repeatedly trying to install the same version? This is not a general problem, it is somehow very specific to your system. Can you please tell me what version of Windows it is? Are any of the folders in FSX already marked hiddeb or read-only? I am grateful for the report, but I am still puzzled as to why you are installing FSUIPC 4.026 three or more times when the first time worked okay? It may simply be this which is somehow causing the problem, though it wouldn't explain the hidden files in the first attempt. Anyway, I'm making changes so that the attributes like Hidden and Read Only are removed by the installer before it tries anything. Regards Pete

Everything interfacing to FSUIPC is related to FSX. FSUIPC is forging that relationship -- that is what it is for! ;-) SimConnect can also be used directly by other programs, so that is forging relationships as well. Pete

It doesn't sound like the same, but certainly it is worth reporting this to tell_fs@microsoft.com please. There are no important changes I'm making to FSUIPC which are not SimConnect problem avoidance related -- work-arounds where we've found them. Nothing I know of or can do would change FS's abilities to redraw itself on changes of process or mode. I haven't had exactly the same problem that you describe but certainly I've had FSX disappearing to the task bar without warning and just never restoring. And I've had completely black screns, with everything otherwise appearing to be running, when switching from windowed to full screen mode or vice versa. Most of these sorts of problems I know about do seem to be associated with full screen mode, and I think for stability it is currently best to run instead in maximised Widowed mode if possible. (Oddly, I remember problems like this in the early days of FS2004). I can only hope that MS will be able to address these things sooner rather than later. One of the whole points of making FSUIPC almost exclusively a SimConnect-using client is that it means there's no complex invasive code in it, so nothing to go wrong -- at least on my side of the interface. Except for the button, key and joystick scanning (which are still independent and use standard Windows facilities) everything it does is via SimConnect. And 99% of the time it is doing nothing but waiting for information to arrive from simconnect as, unlike previous methods I had to use, the simconnect data access is passive -- FSUIPC files a request for information with SimConnect during initialisation, and then it merely sits back and waits for it to arrive. Admittedly, whilst flying, that's a lot of data which is changing fairly frequently, but on the whole is it no more often than in FS2004 and it is tied to the frame rate. Regards Pete

Actually, I think you are adding to the wrong thread -- but I can see why. The right one is http://forums.simflight.com/viewtopic.php?t=57105. It sounds like another possible symprom of the bug reported and hopefully now "worked-around" (at least in my code, update to be released here later tonight) -- it needs changes I expect to all SimConnect client programs until MS can fix it. Actually only removing it from the Modules folder, or renaming it would be enough. And if you told Windows to trust all software from me (via the option in the dropdown) the "trusted status" is nothing to do with FSX but is recorded someplace else, in a repository you can access via IE's Options. Aha more usual symptom. Please make sure all this interesting information gets to MS, tell_fs@microsoft.com. I've tried to promote this as the most urgent SimConnect problem to resolve, even before firewalls, weather and performance! Regards, Pete

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