Pete Dowson

Ah, well done! What did you have to do to fix it in the end? Regards Pete

Well, it shouldn't, because the Zapper uses the same AI deletion routine as the Traffic Explorer add-on from MS, and the same sort of deletion is actually done automatically by FS9 if two AI get into conflict for too long. They also get deleted sometimes after being given a Go Around. Of course it is possible that there's a bug in this TCAS DLL which doesn't like the disappearance of an entry, but if there was you'd think it would be happening quite a lot. Regards Pete

It would have been easier to use the Flag facilities provided. This is because in order to get a key press whilst not having the keyboard focus the external program has to use the Windows "hot key" facility, which steals the key press away from FS -- so neither FS nor FSUIPC ever sees it. You cannot use the same keypresses. You say you tried to use a joystick button as a switch. If you have a spare button why not use that to operate the light, via the FS control for it (not a keypress). Why? With FSUIPC keypress assignments to can assign all sorts of key combinations which won't interfere with anything else. But you don't program them to send key presses, but FS controls. No, not if the external program is grabbing the keypresses using Windows hot key facilities. Nothing else can see such keys. Regards Pete

Why don't you try showing me the Install log, as I asked yesterday? If the installer created the FSX Modules folder it will be in there. I can't help you unless you try to rerad what I say and provide the information requested. Pete

The log only shows that the GlobalSign certificate didn't verify correctly on your system. It does give an error number (0x80092026) which may be useful if I have to refer it to GlobalSign or Microsoft, but meanwhile you are still not providing haslf of the information I asked for. i.e. what does the signature checking say if you check it via the DLL's properties, and what version of Vista are you using (version and language). Also, please check in Internet Explorer to see if you have the GlobalSign root listed there and whether I have been listed an "untrusted" rather than "trusted". Go to Tools - Internet Options - Publishers. In "Trusted Root Certificates" there should be "GlobalSign" and "GlobalSign Root CA". In Trusted Publishers you should be able to find me ("Peter L. Dowson", but maybe not yet, if you haven't clcicked on such. I certainly should NOT be listed in "Untrusted Publishers". There was a problem on one Russian installation which used a Cyrillic character set as part of the FS path name. However, yours appears to be okay ("C:\Program Files\Microsoft Games\Flight Simulator 9\MODULES" -- except, of course, that the Program Files location is the very worst place to let FS install itself into on Vista. Apart from FSUIPC you may get lots of problems from other add-ons as Vista protects all folders in "Program Files". If you've only just installed it it may be a good idea to uninstall it and reinstall to somewhere like "C:\FS9" -- I think you'll get far less hassle in the future, as you add more things. Regards Pete

Thank you. It isn't very often someone posts good messages here! ;-) Regards Pete

Can we try to get this part clarified first, please? Is this "interface box" is a piece of software? It sounds like a piece of hardware. Does this commercial company, "Aerosim", think it has a license to use FSUIPC for its commercial products? I've looked at Aerosim's website and I can find no mention of any "FS Interface Box", nor that they use FSUIPC. I have no record of any company by that name ever approaching me for a license. And then where is this "Aerosim FS Interface Box"? Either you haven't installed whatever it is which interfaces to FSUIPC on the client, or it doesn't use FSUIPC after all. I suspect the latter. Can you give me any more information? The Wideclient window isn't used for much, unless you use the button facility it provides (designed for touch-sensitive screens). Normally you minimise Wideclient or set it invisible. It is only the interface, across the Network, to FSUIPC. You need a program which talks to FSUIPC for it to do anything, of course. It sounds like you either haven't got anything using FSUIPC, or you simply have not run it! Regards Pete

If PMDG have messed something up I'm afraid it would have to be they who fix it, unless they can tell me precisely why it is now going wrong again, if due to my turbulence eemulation. I actually depended upon their expert 747 captain, who tests their models, to test the FSUIPC4 turbulence emulation for me and he gave it his approval. The only example shown to me so far has the maximum turbulence set ("severe" or 4), which does indeed make life difficult for the autopilot -- so much so pilots would normally fly manually and seek a way around it. But certainly with mild to moderate levels the previous PMDG 747X is flying fine here. And the cloud and wind turbulence is the same -- the only time it was ever different was well before 4.26, some 4.25 test release I think. That was a bug, and it was also before the turbulence was re-written to do Gaussian ramping rather than sudden changes. The problem reported here is EXACTLY what happened with the 747X with the sudden changing, even if they were mild, in the much earlier version of FSUIPC4. Realistic turbulence, as in FSUIPC4 now, has smooth changes to random extremes governed by the severity, with those extremes chosen to fit a "normal" or Gaussian distribution. That's what changed in 4.26 and it hasn't been different since then. Considering all this, it does seem to me that, somehow, these two fliers have been using an older version of FSUIPC4 even though they thought it was 4.28. I even downloaded 4.28 from the Schiratti site and tried that, and it was fine, exactly as expected. Regards Pete

Can you please explain what this "exact same problem" is? Show me the FSUIPC log file please. What version of FSUIPC are you trying? What version of Vista. I need information to help -- if it is a code signature prtoblem, which you appear to imply, did you right-click on the DLL and check it, as advised? If so, what were the results? If not, why not? I cannot help in a vacuum I'm afraid. The code signing is a standard Microsoft-upported third party one provided by Globalsign, and all Windows XP installations did automatically include this after SP1. It appears some non-English versions of Vista are missing the root certificates. That is the only problem I know about, and that is fixed by the "global Fix" supplied by Globalsign. Pete

But 13 means engines 3 and 4 are also on fire! Please enable IPC read and write Logging in FSUIPC and show me that in the Log. Sorry, I know nothing at all about XML and C variables. I observe that the fire is extinguished from outside the aircraft. Do you? Isn't that what matters? Have you even looked to see if the fire is put out? Why are you trusting in some XML variables only? Maybe those go wrong here too, I don't know. I have no panel in my cockpit -- I use a PMDG 737NG mofel with no Gauges whatsoever, as I have a hardware cockpit using Project Magenta. It works fine with that. I'll do a test for you here on my dev PC using the default 737. [LATER] Yes, it works on the default 737. When I write 1 to 3366, the Engine 1 fire starts, and 3366 reads back 1, not 13. I really don't know how you are getting 13. When I write 0, it reads back 0 immediately (but I think that is merely because FSUIPC is providing the current value it has, which is the one you wrote), and the fire visibly extinguishes in about 10-15 seconds. It does not extinguish immediately -- maybe you are not waiting long enough? I will change FSUIPC for this variable so that it doesn't copy the written value to the read-back value, as it does with most -- I have to make such exceptions here and there, but in general it is better (for toggling purposes) to readback the written value, so that is what my code does except for flagged exceptions. Testing that change now ... [LATER STILL] Okay. Some observations: (1) If you are using the FSInterrogate "Quick Data Window" facility to test reads and writes, please note that there is a bug in it where Hex values are decoded wrongly when writing. It may be that "0x01" is being written as 13, which is why you are seeing it. I have told Pelle about this and, when he has time, he will be fixing it. Meanwhile, either use the Interrogation facility and its single read/write options (which have separate entries for each data size and hex / decimal) or change the data type in the Quick Data window to "decimal", which seems to work okay. (2) The readback you get from FSUIPC is indeed only what you writer. Download 4.283 from here: http://fsuipc.simflight.com/beta/FSUIPC4283.zip and you will then see that after writing the 0 to extinguish the fire, it continues to read back 1 until the fire does actualy extinguish. (3) I believe, then, that you weill find that your XML / C variables behave in the same way. That the fire does extinguish, but it takes 10-15 seconds. Regards Pete

There's NEVER an "FSUIPC4 folder"! Installing FSUIPC4 is a matter of running the program called "Install FSUIPC4". Go to http://www.schiratti.com/dowson and download "FSUIPC4.ZIP". Open the ZIP and extract "Install FSUIPC.exe" to any handy folder on your system, then run it by double-clicking it there. That will install it. If it gets an error, tell me what it says and Save the Install log somewhere (there will be a menu item for that). Show me the Install log. Pete

Okay, I've checked all this, and it all operates as I thought it did -- basically, since version 4.15 (July last year) no axes are intercepted UNTIL some action on them is detected. This was done as a precaution because problems were occurring on the more sophisticated add-on aircraft which use the controls themselves. As I said, mostly this would go unnoticed, and the "action" is often seen during the FS start-up phase so would have no effect worth noting. However, when they are cross-assigned like this they may initially, for one or two readings only, operate directly in FS without being intercepted and so re-directed. Testing here I can see it happening with your sort of cross-assignment, but it only occurs the once and then it is all okay. I don't have to go into FSUIPC options or do anything other than waggle the axes. I think you will find the same -- I would guess what is happening when you call up a menu is that because FSX is suspending the axis scanning whilst in menus and re-instating it on exit (which I know it does), is this which generates thje initial reading sufficient to make FSUIPC4 do the interception. I hope this explains things for you? Regards Pete

The "KeySend" option is for sending Key presses TO the Client FROM the Server, instigated by key or button press there. You have it the wrong way around. To send key presses from a client to the Server is a different set of facilities altogether. Please look up the "SendKeyPresses" option and the superior "ButtonKeys", both described in the WideFS technical document. The ButtonKeys option is better as you don't need to ensure focus on the Wideclient window then -- instead of sending the keypresses it sends button numbers which you can then program as you like in FSUIPC's Buttons tab -- for key presses there (which can of course be completely different) or for FS controls. Regards Pete

sorry, I don't really understand how stopping a fire is achieved by reading anything. It's writing 0 to the appropriate bit which does it. I tested by actually doing it whilst watching the fire in the external 3D view. This is how I know it takes a few seconds for the fire to go out and the smoke to disperse. Maybe I'm misunderstanding something about what you are saying? Regards Pete

You are making an error. All three parts (name, email, Key) must be exact. Use cut and paste if you cannot get it right. Also double check you have a Key for FSUIPC4 and not FSUIPC3. Pete

Hmm. I don't understand any of that. Certainly, it is possible that the axes need MOVING so that a value i detected *before* FSUIPC starts mapping them -- so initially, the first movement of the axis, might not do as you expect. This is because FSUIPC doesn't intercept any axes unless it detects that they are used. Again, this was a safeguard added to avoid problems with complex aircraft. But normally all that sorts itself out automatically within the first few seconds of so of being "read to fly". You shouldn't need to do anything, unless your axes are so stable they give no signals until moved. I don't understand why opening and closing an options dialogue will do anything special. That's a puzzle. I'll have to look into that. Regards Pete

Hmmm.. Are they calibrated in FSUIPC? There were a lot of changes to avoid intercepting and *stopping* axes unless you actually calibrate, because othjerwise it was upsetting some complex aircraft like the Level D 767. Otherwise, maybe you've found a bug. I'd need to do some more checking to see. I doubt if many folks use these facilities, maybe you're the first with FSX. Pete

Not if those FS axes are diverted to other uses. You can either use them for Props or for other things, not both. Yes. Because they have to have a parameter (the axis value). non-axis controls are simple push-button types. No values associated with them. Axis controls have a value associated. That's the point. There are many many axis controls. How are you possibly running out of them? Both FSX and FS9 list 26 in their assignment capabilities -- if you assign to FS controls via FSUIPC there are lots more (all the others FS doesn't bother to list for you). Surely you cannot possibly be "running out"? If you want FSUIPC to "arbitrate" for the maximum deflection/value, yes, either in FS itself, or at least to FS controls in FSUIPC. Of course using FSUIPC axis assignments you can assign any axis to any control, as many times as you like, in any case. But then you don't get arbitration -- you need to be very sure any currently unused axis is "quiet" -- i.e. either parked in a dead zone or not liable to any jitter at all, as the last change is the one which is used. Sorry, this part makes no sense to me. Can you re-phrase? Of course -- it simply intercepts the original control and uses it for something else. This is done all the time anyway, as for instance if you "map" the one generic throttle to 4 others, or other such combinations. No, of course not. What on Earth would be the point of that? It is all very simple. FSUIPc has to intercept the controls in any case if you are calibrating in FSUIPc -- how else do you think it can do that, change the values used? It is therefore just as easy for it to forward them on as something else entirely. It is doing it all the time. Think it through. it is all quite simple and logical. The only base stipulation is that FSUIPC is calibrating, so processing, the axes. Don't forget that with FSUIPC assignments you can have the same axes used for different things according to the aircraft being used. I hardly think any one is going to have enough real "axes" to ever run out of the FS possibilities. Regards Pete

Just to prove this to myself (apart from examining code changes through my Source Control system) I've flown with your saved flight with both 4.28 and 4.26 now, and the results I get are identical. I also added winds with turbulence, and the effects are the same for both wind and cloud turbulence -- as, indeed, they must be as it is the same code. With the severe (maximum turbulence) you had set (number 4 as shown by WeatherSet), the 747 A/P does have difficulty keeping on track. this is to be expected. It does tend to reach its maximum bank before turning back towards the intended course. With light to moderate turbulence (wind or cloud, or both) it copes well. I think you'll find that in real life the pilot tends to take over manual control during severe turbulence, and requests a course or level change to get out of it, re-enabling the A/P when the effects lessen. Incidentally, I am just about to upload version 4.282 to the "FSX downloads" Announcement above. This has a few important changes, none to do with the weather, but if you are going to test 4.28 (again?) you might as well get that version instead so we know we are definitely talking about the same code. Regards Pete

Well, I've tried your saved flight (which had user-set weather with a cloud layer featuring very high turbulence (level 4). I deliberately re-installed the release 4.28 (I'm a bit later here with some other changes), and the wind changes are small and smooth, as programmed. The wind speed changes up and down a little, by 1-3 knots and the wind direction likewise. nothing drastic and certainly nothing not already tested and found to be okay / good by the PMDG 747 test pilot. The loss of control problems in the earlier turbulence effects, before 4.26, were as you describe and were due to sudden changes as opposed to smooth up and down changes which I added. I've also brought up my Source Control and examined al of the changes made between 4.26 and 4.28, and there is only one, small one, which has anything to do with weather, and that it the one to stop the vertical wind being changed all the time (nothing to do with turbulence or any of those facilities, just to do with thermals for gliding). Interestingly, and perhaps meaningfully, the symptoms you describe, with cloud turbulence (only) being a problem, are exactly those which were apparent in a much earlier release, 4.25 or before, before the finalisation of the wind smoothing and turbulence emulation in 4.26. If you are genuinely using 4.28, then this is a huge puzzle -- I don't suppose you have any Logs left from when you were having these problems, have you -- the version number would show at the top of the Log? Is it possible that you installed something which overwrote your 4.28 with some other, older, version? Please, to be really sure, can you download 4.28 again, from the Schiratti site, and re-install and check again, as I have just done? I'm beginning to think this is all one big mistake and I don't want to waste my time further. I cannot emphasise enough that the treatment of wind smoothing and turbulence is absolutely identical in 4.26 and 4.28. Regards Pete

Okay. Found it. It seems the ATC.DLL has its own language resources appended, and the name is in there. Naughtily of MS there's no indication that the versions of ATC.DLL are in any way different, but they are. I always thought they deliberately collected all language elements of the program into the Language DLL to make it easy to translate. Bah! Please download FSUIPC 3.811 from the "Other Downloads" announcement above. Regards Pete

That's all very well, but you'll be stuck on that version forever, despite any new facilities and fixes, unless we can sort out why 4.28 doesn't appear to work. And I am not going to support old versions, ever. Best to stick to the latest and temporarily turn off the cloud turbulence, as I said. Pete

I assume "ENGINE_FIRE" is 0x3366? You are testing for "engine_fire & 1" before you've actually read the value -- the _Read only queus the read, you need a Process to fire it off. It works fine here -- the fire extinguishes in a few seconds, not immediately. Please please please use the tools provided to check these things. There are IPC read and write logging facilities in FSUIPC's logging tab to help you work out what you have wrong, and there is a program called FSInterrogate which is very easy to use to verify operation of offsets. I shouldn't need to debug folks code for them, really. Regards Pete

Might be earlier. I got curious and looked into the Gernam language DLL. It seems that whilst the Window name is "Flugsicherung" the name I am reading from the Language DLL is "FS" -- it is the one in the Options menu, and it seems Microsoft abbreviated it rather drastically for the Menu! Weird! I am looking to see where I can find the REAL name, otherwise I shall have to build "Flugsucherung" in and hope that MS have not done such things with any other language. Regards Pete

Why not simply turn off cloud turbulence for the time being? Pete