Pete Dowson

I'd be interested to know more about this, if you do find out. However, in FSUIPC's case it is the application which creates the memory file and tells FSUIPC about it so it can open an access to it to retrieve the request data and dump back the results. The application keeps it, FSUIPC doesn't know about it except whilst processing the requests. That way each application has its own area, nice and tidy. Since it is that way round, I don't see how the higher-privilege process (FSX) can mark the area as safe for lower-privileged access when it is a lower-privileged process which created it and owns it. I suspect the same would apply to SimConnect, as each application instance would, again, need its own space, presumably created when it calls and opens SimConnect.DLL. Regards Pete

No, it does not. It only deletes ONE, the nearest on in the "line of fire", so to speak. Please read the documentation. It's only function was to remove a blockage in front of you on taxiway or runway. It is certainly possible for someone to write such a utility, but not I. Sorry. I think you are wrong here (though please do go check). I think the number of cycles provided to traffic diminishes considerably with distance. The real cycle-guzzling stuff is the stuff within visible distance. I'm pretty sure that it doesn't even draw them after about 10 nm or so, and the update frequency for distant ones is low. So, if someone bothered to write such a utility you'd find it made very little difference at all -- in fact it might make it worse as the utility itself would be guzzling cycles reading data and sorting it to decide what to zap. Best to instead only ever use AI which is designed for efficiency. For FSX the MyTrafficX program with the DX10-only traffic seems to give excellent performance everywhere with lots of traffic. It's the autogen which kills my system's performance. Regards Pete

Really? Having UAC on makes vista almost unusable for me. It's just a P.I.T.A. Vista is much nicer without it. What are you afraid of? Are there other users accessing your system with your user log-on credentials? UAC only protects you from you, and that makes it very restrictive and for me completely unnecessary. Pretty much all current SimConnect programs are designed to work with FSX RTM and SP1 as well as SP2/Acceleration, so they don't take advantage of the improved efficiency of the shared memory/pipe system available in SP2/Acceleration. The latter may well fall foul the the same protections. Regards Pete

Sorry, old versions are not supported. Please refer to the Announcements above. 3.65 is very old. Use the latest version then re-ask your question, but first of all please try using the facilities provided for you to check things yourself. Look in the FSUIPC Options and you will see a "Logging" tab. Go there and check IPC read logging. See if your requests are being logged correctly. Logging is provided to help developers. Pete

It's called "hacking" these days. I've been a programmer since 1963 and always worked at machine level upwards, so the nuts and bolts underneath were more easy for someone like me, together with my own tools and some anyone can purchase (e.g. including Microsoft's own excellent debuggers). However, it still takes many 1,000's of hours for each new version, and it has been getting more and more difficult as they use more and more convoluted code ("object-oriented", so called. Ugh). Additional multi-threading and multiple core usage make things tougher. I'm nearly 65 now so I'm glad SimConnect is 'taking over'. One day it'll do the whole job. :-) Pete

As far as I know, provided you are using the latest version of FSUIPC (eg, for FS9, FSUIPC 3.81) where some of the defaults were changed, there's nothing special to do for either of those add-ons. If you have been using FSUIPC before, you may want to delete your FSUIPC.INI file and go through setting your options (if desired) again, just to make sure the revised defaults apply. Get them working in FS without calibrating or assigning in FSUIPC first. This avoids confusion as to what is going on. Regards Pete

FSUIPC3 didn't exist at that time -- FS2004 hadn't been released and the previous version of FSUIPC, 2.xx, was free, yes. It was, even then, a full-time job -- I supported myself from savings and some dividend income for the five years since FSUIPC 1.00, but that finance was drying up and it became a choice -- either make a charge or try to find a job, in which case FS2004 would never have been supported. Colleagues and FS contacts persuaded me, eventually, to do the former. I did try a voluntary charge initially, but that was hopeless. It's still full-time, even though for FSX Microsoft have at last managed, with some help I should add, incorporate an interface ("SimConnect") into this latest version. For FSUIPC, since version 2 times, a lot of work has been put into the user facilities to make it worth the purchase price, but there's never been any charge for the application interface except for commercial users, just as in the case of Adam Szofran's FS6IPC for FS98. Whilst a lot of folks cried "foul" on the charge, I think few of them realised this. There were no user facilities at all in FS6IPC to justify a charge in any case. Note that there are two currently maintained and separately purchasable versions -- FSUIPC3 for FS9 and before, FSUIPC4 for FSX and later. Because of "SimConnect" FSUIPC4 was a complete re-write with only small sections of code transported from 3.xx. Hopefully, though, and because of SimConnect, it should remain compatible, or easily adaptable, to future FS versions -- assuming MS keeps up its end and maintains SimConnect in a compatible manner. Regards Pete

By following step 2 of the two steps I asked you to take! I was trying to explain why the steps were there, so you'd understand. I seem to confuse you by explaining so maybe I shouldn't in future, if you prefer? Here is the step which will accomplish what I said: 2. Also disable wind smoothing until you have loaded the test flight and it is underway for a few seconds, then go to the Winds tab and switch it on. Oooh, ouch! What's this about? Don't add any new winds!!! Where are you reading such things? Just repeat the tests with the extra two steps EXACTLY as I asked!!! Please just follow the step as written, don't take parts of it out and make up other things with it. See it says: 1. On loading FSX, before loading the test flight, ... With me, still? go to FSUIPC Logging tab ... This means the FSUIPC options Tab marked "Logging". I'm sure you must be able to find that. You have before and add these offsets to the Monitor (right-hand side): ...This refers to the Monitor which fills the right-hand side of the Logging tab page. You will see columns for Offset and Type. Just fill two lines in, those two columns, offset and type (the latter is a drop-down choice, but you'll see that -- you must have seen drop-downs before) as follows: 0E90 as type U16 0E92 as type U16 ... Okay so far? and check "normal log" below. Don't touch the left hand side. ... all that means is find the checkbox below labelled "normal log" and make sure it is checked. Then press Okay. Don't press anything else. Phew! :-( Don't rush on my behalf. There's only you with this problem, so there's no pressure for me, and I'm not well at present so I'm only working part time as yet (got a tummy bug at the end of my holiday). Oh, if and when you do send more logs, please could you include the test FLT + WX files, and your FSUIPC4.INI file. If I can see the difference it the logs I might try to repro it again. Regards Pete

The 4.284 log looks like it might be useful if I had something to compare it with, but something went odd with the 4.26 one -- there's no FSUIPC wind smoothing or simulated turbulence operating at all! Are you sure you had the exact same FSUIPC.INI file in both tests? I don't understand why there's no sign at all of ANY smoothing in your 4.26 example! The 4.284 problem seems, in the log, to be some king of initialisation problem. See this part of the log: The ambient wind from 91T must come from some initially loaded flight (Cessna EFHK cold cockpit.FLT), which didn't get overwritten as the "weather at aircraft" from the turbulence test flt until much later -- which has just the one layer of wind with direction 359M. It appears to FSUIPC as if the wind has just been incorrectly shifted from 91 to 359, one of the dreaded FS wind shifts, so it tries to smooth it, by keeping to the 91 and changing it gradually. By the end of your log, 60 seconds later, is has reached 26.8, but FS is still trying to set 359 throughout. I'm not sure that this isn't a cause of the problems you are seeing (with the odd 359 value creeping through), rather than the turbulence. I'll need to look and see whether my mechanism for restarting the smoothing target after a flight re-load has changed between 4.26 and 4.28. All the turbulence logging looks okay, and to specification. Those are the lines showing like this: With 4 of these between smoothing changes, each of those entries will represent a shift of 1/4 of the difference between the current value and a randomly selected target in that range. These are deliberately paced over 30-40 mSecs per change. The problem in 4.25 was that the changes to the andom target were instantaneous -- that DID upset the PMDG model. This new method was proven by PMDG testers to be good. Just a brief look at the otherwise uninformative 4.26 log, the first sign of Ambient wind at the aircraft is this: even though the same two FLT files were loading. I don't understand how a simple change of FSUIPC version could do that, so I'm going to assume it is just a random timing thing. Maybe next time it would be reversed. [LATER] Big Ouch! I've just checked the history of my changes leading up to 4.26 release -- the smoothing logging facility was disabled by then, and reintroduced a little later. Duh! I've found the closest version to 4.26 which has the logging enabled, so I'll email that to you. Could you repeat BOTH tests (4.284 and 4.262) please but with two important differences, one to eliminate the FLT loading difference at the start and the other so I can see the Ambient winds being seen by PMDG's code: 1. On loading FSX, before loading the test flight, go to FSUIPC Logging tab and add these offsets to the Monitor (right-hand side): 0E90 as type U16 0E92 as type U16 and check "normal log" below. Don't touch the left hand side. 2. Also disable wind smoothing until you have loaded the test flight and it is underway for a few seconds, then go to the Winds tab and switch it on. Okay? Sorry for all this trouble, but it still appears no one else has quite what you are getting (although they say so, so far the rest has resolved to ASX SP2/SP3 difference in options), and I'm intrigued that you could get such different results with what appears to me as identical code. Regards Pete

If you mean the one you sent on the 3rd, no, I'm afraid not. I already emailed you a reply, as follows: Regards Pete

Hmm. Thanks for the explanation. I'm wondering why there's no connection to FSUIPC from different privilege levels. All I can assume is that either the normal search for a Window with a specific Class Name deliberately hides those Windows with a hight privilege level, so the applications don't even try to connect because they don't see FS running at all, or Windows deliberately won't allow a memory-mapped file to be shared by two programs of a different level. The latter sounds the most likely, presumably to make it all more secure. Did you try switching off UAC (User account control) at all? That seems to remove some of these sorts of checks. Any way, I'll remember to make a note in the documentation somewhere. I wonder if this also affects SimConnect-interfacing programs using the SP2/Acceleration Named Pipes connection, as that, too, involves shared memory. Of course it would affect those written only to use the RTM or SP1 version of SimConnect as that uses TCP/IP protocols, even locally. Regards Pete

Ah, you are one of those who likes to print them, are you? Can't be many as this is the first such request I've received! ;-) At present, no, documentation changes aren't flagged. But all of the changes which would be described somewhere or other in the manual are listed in the "History" document, so for facilities, options and so on (as opposed to mere explanations), that should dojust the latest part which always comes first. I'll think about adding a changes indication, maybe by sidelining. But not for trivial changes I think. Regards Pete

I'm afraid I need information to even start to advise. FSX, FS9, FS8? FSUIPC version? How FSUIPC is being used, if at all? (FSUIPC or FSUIPC4 INI file?). The axis assignment, and calibration facilities, in FSUIPC only work if FSUIPC is registered, so most likely you have assigned the axis in FSUIPC and forgotten to de-assign it in FS, or vice versa. If you don't know what you've done and want to start again, simply delete the FSUIPC INI file, which is where all your FSUIPC settings are saved. Pete

No. The main performance drag to watch out for is the processor sharing -- process switching. And that applies whether or not your programs use FSUIPC. If you are using a processor with multiple cores then that shouldn't be of any concern either. Sorry, I don't know the program "PEIX". But to use any other application on a second screen with FS running, the latter has to be in Windowed mode, which isn't always a good idea. If you click the mouse outside of FS, then FS loses the focus and the sound will stop. No, although if you are thinking of FSX rather than FS9 then it would be a good idea to go for a 4 core processor. But if you have an older, lesser, PC, why not network them and move as much as possible off? It may not be such a good idea with the motion driver (as it would increase the latency by 10-20 milleseconds), but anything else which can interface remotely would be better off the FS PC in the long run. Regards Pete

The process Ian describes is the "official" way of doing it through FSUIPC, because that enables it to provide arbitrations between the two axes fighting to control the same control surface -- it simply chooses the one with maximum deflection. These days, since I added "axis assignments" to FSUIPC, there is an easier alternative which also works well, provided that you have stable (non-jittery) axes. With many of the more recent USB based joysticks and yokes this may be the case. For this you'd simply allocate your yoke axes in FSUIPC's Axis Calibrations tab. FSUIPC doesn't care how many axes you assign to the same control surface, it simply takes the last one to change by more than the "delta" value to can set there -- if you have no jitter you can leave the delta to default, but it could be increased a bit to deal with minor jitter. You don't want to have to increase it too much as this will cause a loss in resolution on your control. If you assign axes in FSUIPC you need to make sure they are not also assigned in FS. Regards Pete Pete

A quick way of seeing exactly what is going on with any offset is to use FSInterrogate, the very tool provided for this. There you would clearly see in the Hexadecimal representation the "decimal" version number clearly. Of course another tool to be used when developing programs is the IPC read/write logging built into FSUIPC, or even the monitoring facilities for specific locations. I am continually amazed at how many folks struggle on to develop their program without using the tools provided. Regards Pete

Rightthose memory problems can sure be annoying, affecting different things at different times. Thanks for letting us know! Pete

Thanks for the information, but why are you doing that? It should never be necessary to run a Vista-aware program such as FSX in elevated administrator mode! I don't understand why you are doing it? Regards Pete

Sounds like a key problem. Repeat the problem, close FS, then Zip up the FSUIPC.LOG and FSUIPC.KEY files (from the FS Modules folder) and send them to me at petedowson@btconnect.com. Regards Pete

But I think you mis-read. It is NOT the same issue. The reference you quoted was regarding an apparent difference in turbulence emulation between FSUIPC 4.26 and 4.28, even though the code is (and has been proven to be) identical. You are not saying that at all, you are talking about a difference between ASX SP2 and SP3. Now I suspect that, in the end, I'll manage to prove that the 4.26/4.28 apparent different is also due to changes elsewhere, but without actually standing behind the person reporting it I can't do that -- I need comparative logs to show the actual numerical data. That's what I asked him for. I don't want that for ASX SP2/SP3 differences. That would be more a matter for HiFi Simulation. Regards Pete

As Jim says, you'd have to go through SimMarket, but considering FSUIPC didn't start selling till August 2003 it is probably outside the time frame you are remembering. Regards Pete

No. That's a completely new one. So it doesn't lock up just going there, or selecting the keypress to be assigned? Sorry, but I'm not clear on what you really mean by "start to enter in any field" -- you first have to clcik a button to enter they keypress you are wanting to program. If some other add-on was capturing keypresses you still expect mouse operations to work even if you could enter nothing in the fields. However, it might be worthwhile doing a process of elimination on any other add-ons you have installed. The way the keypress assignment dialogue works hasn't changed in the nine years since it was added, and there's never been any problem with it before, but it sounds similar to the problem some folks appear to have with the Registration dialogue in FSUIPC3, one of the few other places where you enter keyboard data. That occasional problem has been going on, in a very small number of cases, for many years, and we've never got to the bottom of it -- there's some add-on (maybe nothing even to do with FS) which must surely be interacting with it somehow. Is the button dialogue similarly afflicted? Any other symptoms? Regards Pete

Thanks -- apart from flying to Ljubljana and back from Belgrade, there's no personal flying time this trip -- it's all for my other hobby, steam railways! ;-) I hope you sort out your axis connection problems. There are many other Saitek users here so I'm sure you'll get some help whilst I'm away -- but post your questions in a new thread and make the subject title attractive to those who might know the answers, like "Problems with Saitek yoke and quadrant". Regards Pete

No idea, sorry. Is the actual elevator affected. or only the offset? Regards Pete

Well, sorry, I don't recall offhand which of the supported FS controls Microsoft bother to list in assignments or not. But that is the first place to look for such standard things. But what about FSUIPC. Didn't you even find any in FSUIPC's assignment drop downs either? Or haven't you looked yet? I think there are plenty to choose from, depending on whether you want to update the standby then do the swap (in realistic fashion) or not. Pete