Pete Dowson

I wouldn't use keystrokes if I were you -- they are inefficient and less reliable, as they are assigned in FS (keyboard assignments) and have to go through a table lookup to convert them to the relevant FS controls. Why not simply assign the controls you want in the first place? No, you should make it send VIEW RIGHT instead. I'm sure I already said this earlier in the thread? I said "controls", remember? So, simply do NOT program the release to do a VIEW RESET. I already told you that too! If the release sends nothing to FS it won't change views again! It won't even know you released it! Didn't you bother to read my original reply at all?? :-( Groan. :-( Simply DO NOT USE KEYSTROKES!! Then the Num Lock is totally irrelevant! There's no control to go directly to spot view, only the controls to cycle through them. Sorry. Pete

My tests today were with weather set up with moderate turbulence via the Weather dialogues in FSX. I have previously run the PMDG 747X with ASX, but not with your latest update (SP3). It was okay (well, the same as with user-specified weather). Scanning through the reports earlier in this thread I really find only one thing in SP3 which one user found affected things, to quote: "are you using the new Wind stabilization (not smoothign) feature in ASX SP3? My first flight with ASX SP3, I had that enabled, and the PMDG 747x went all over the place when crossing a wind layer. The wind vector was twitching like crazy. I disable the wind satbilization feature, and have now completed 3 long flights with no problems." However, this whole thread is strewn with inconsistencies, so I would necessarily take any of it on faith. For instance one chap is absolutely sure it is only "cloud turbulence" in FSUIPC, not "wind turbulence" which cases a problem -- yet there is only one turbulence emulation provided, so that makes no sense. The difference between cloud and wind is which weather record the "turbulence" instruction comes from, that's all. Another inconsistency is folks absolutely sure that it was all okay in 4.26 and not in 4.28, yet I've compared the code and there is absolutely no difference -- the turbulence is identical in both. And this is borne out by examining the actual wind fluctuations. From the sounds of those particular reports it seemed as if the FSUIPC turbulence emulation was actually turned off (by having smoothing off too0 when they were using 4.26, as the type of turbulence they reported was exactly FSX's own, which cannot happen when smoothing is in operation (the whole reason for the emulation in the first place). I have spent a lot of time examining exactly what my own turbulence emulation code does, and it is now doing exactly what was intended and what was agreed with PMDG as realistic. I've had to make one change, and that is to remove a dependency on the FSX internal frame rates to regulate the wind fluctuations. I suspect that the instability on some systems may have been due to them "running away" a bit -- and that might also vary due to other things, even different versions of ASX or FSUIPC. I also found that, because my hooks in FSX have to operate on two routes (VisualFX to SIM1 and Weather to SIM1) there were on average about 8 occasions per second where two increments were applied at almost the same time. This could also have made too much of a "jerk" in the wind. The regulation I've included now seems to sort all that out and, as I say, the results look good. Let's see what sort of feedback I get from folks using 4.294 (or later). I'll also be installing ASX SP3 this week and will do some more tests with that. Best Regards Pete

Oh, right. Okay. Thanks. Pete

Do you mean this? I'm not at all familiar with the Delphi section, it is supplied as I received it. Is the are place for it in there? Best Regards Pete

Oh, are you new to C/C++? If so, might not Visual Basic be a better place to start? You will at least need to read up a bit more I think. If you are including Windef.h, how are you getting it undefined in the first place? Just delete your inclusion of Gauges.h. I wasn't suggesting you included the gauges header wholesale -- after all 99% is no use to you. i was only suggesting that if you didn't know what something like DWORD meant you could easily find out by just looking! These header files are TEXT files you know, you can read them, take bits out, make your own header, as you please. This is all part of what is known as "programming". ;-) In the end, if you didn't want to use DWORD you could use "unsigned int" as I suggested, or #define DWORD for yourself. You seem to be making a real meal out of a tiny snack! :-( Pete

I've released 4.294 in the FSX downloads announcement above. Please read the notes. I tested this with the PMDG 747X version 2.00.031 and found that, with moderate turbulence, flying with 20-40 knot winds at 13000 feet or so, the autopilot, though wavering about, never got more than 10-20 degrees off the intended course. I think this is excessive, and you can actually see it turning the wrong way (i.e. turning left slightly even though the heading bug is to the right). I have no idea why, but no other autopilot i've seen behaves like this so I'm afraid it is a question for PMDG. I updated to version 2.10.0040 of the PMDG 747X and this seems better, never getting more than 10 degrees off, and usually only 1-2 at most. At least, this is how it behaves once it is on course -- it seems to have a lot more difficulty actually getting TO the right course, often apparently turning the wrong way for a little while. I cannot explain the odd A/P behaviour, but I have examined the detailed logs of the turbulent wind details, and they are always exactly as indented, with small increments and the speed and direction changing smoothly up and down over the intended periods. To tone them down any I think would make them unrealistic, though you can experiment with the Turbulence parameters, as documented. In the end I'm afraid that, for the PMDG aircraft, if you still have problems, you have two choices -- either contact PMDG and supply them with the logged wind data and a description of what went wrong with the A/P, or simply set the FSUIPC4 options to prevent the turbulence emulation. The latter would merely make wind smoothing in FSUIPC act like it did in FS2004, so it isn't such a loss, relatively speaking. Regards Pete

thanks! Could yu move on to release 4.294 now, please? There are some other changes (not in the area you've been testing), and I'd like more exposure before I move on to 4.30 as a general release. Thanks! Pete

Two levers on a control are rarely identical, and in any case synchronisation in real aircraft is not by holding all the levers in-line -- watch a cockpit video sometime and you will see that 747 levers, for instance, are rarely exactly lined up. Each engine is slightly different, the stretch on each cable is slightly different. FSUIPC does offer a hot key facility to "sync" throttles if you desperately need it, but that simply takes the thottle 1 input and copy it to the others. I've no idea what you've done there, because there is no relation whatsoever between any of the axis controls and switches like that. I have read of a fault in early Saitek units where random button presses were being sent on occasion, but I thought they'd fixed that, and in any case I thought that was only on their yoke. Maybe it was on the quadrant too? There is a special FSUIPC parameter to seuppress transient button pressings which was added especially for their wonky units. No, sorry. If you cannot set up your controls to work in FS then really it is time to throw them away, or at least contact their support. Do they sell them for use in FS? If not maybe you should get some which are intended for use in FS. Forget FSUIPC until things work reasonably in FS. I cannot help with any of this stuff directly as I don't use any of it. All my controls are PFC (http://www.flypfc.com) and work through my own drivers. Regards Pete

"DWORD" is just a standard Windows API definition for "unsigned long" or "unsigned int" (in a 32-bit environment both a 32-bit values). You Borland compiler system should be supplied with a Windows header file for programming Windows programs, otherwise you will have a lot of problems. You could also download one of the Microsoft FS SDKs, such as that for Panel building -- the "gauges.h" file inside that contains a lot of useful definitions. Pete

What disagreements? I've never disagreed with anything you've said. You must be reading something else. I know nothing at all about any Baron aircraft, I only know what FS does and that's all I've ever talked about. But what FS control is that? Enable Event logging in FSUIPC and operate that control. The log will give its name. Pete

Yes, to uninstall. But all your settings are in the "INI" file and if you remove that, but leave FSUIPC there, all your joysticks are left completely alone by FSUIPC -- it never does anything unless you ask it to, so if you remove all your settings it does nothing. That's why I said you didn't need to "uninstall" it! Make sure all of the Sensitivity sliders are set Maximum (full right) and the null zone sliders set Minimum (full left). FS has a habit of setting some of these all wrong. Pete

Yes. If that doesn't suppress or at least divert the FDC messages, then it sounds like they are multiline too, which is a bit annoying if they don't need to be. what on Earth are they? Sorry, but this might have to be resolved with the FDC author -- you should also at least ask RC support why its menus aren't being refreshed. Are you sure you are on the most recent release? REgards Pete

That's odd, because Radar contact certainly refreshes its menu at intervals, every few seconds I think. What is FDC displaying? If they are single-line messages they shouldn't be directed to the multi-line FSUIPC window, but to the single line strip at the top of the screen. No. the way the interface is designed (right back since FS6IPC days), it cannot realy make such differentiation, at least not without an intolerable overhead. I know that FDC and RC can work quite happily together, so I'm sure there's a solution, but I'm sorry, I don't have FDC so I cannot tell you what it is. Are you sure you have the multi-line filter enabled in FSUIPC? That's normally been how RC's menus have been separated from other program's progress messages. Regards Pete

You never need to "uninstall" FSUIPC. If you made a mess of your settings, just delete the FSUIPC INI file. Everything you do in FSUIPC is stored in that one file. And FSUIPC has nothing whatsoever to do with the FS assignments -- if the FS dialogue isn't working you have something wrong with FS and may need to reinstall that, or contact Microsoft support. Regards Pete

That only happens when the values, from left to right, are not in ascending order. If you need to reverse the operation of the throttle (quite a common need) you have to select REV first, before setting the values. You couldn't have calibrated with the lever above the stop, because if you had every position below that calibrated position would result in zero 90) being sent to FS, and zero (0) means "idle". Possibly your lever is misbehaving to the extent that it sends slightly different values each time to come back to the same place. If so you'll just have to set a larger "idle" region. Calibrating in FSUIPC does not program buttons for reverse. That's a completely different matter -- you'll either need to use your Saitek software for that or program the button separately in FSUIPC to set reverse (usually using the THROTTLE DEC control with repeat enabled). Regards Pete

Thanks. Those errors logged by SimConnect were caused by my calibration "Filter" facility on axes you'd not yet moved (so it had no readings from them) -- probably your aileron and rudder trims. The filter action shouldn't have been operating until at least one value was received. It did no harm (except put worrying entries in Simconnect's log), but it won't happen in the next release;-) Thanks again, Pete

Sorry, it was supposed toi say Add: Debug=Please LogExtras=256 I just set up the weather in the FSX weather menu. You can set a nice thick cloud layer and set the turbulence level in it, or same with winds. FS is quite flexible in that regard. Surely you are not relying on turbilence added at random by FSUIPC? That sounds like 4.292 (the frame rates) but I've no idea what you could have their causing panels to flicker. Are you sure you downloaded 4.293? Maybe you made a mistake in the INI? Show me a Log please. The wind value logging I put in are operative all the time if the parameters I specified are added -- as long as Wind Smoothing is enabled of course (without that none of this is relevant). The logging is not specific to turbulence, it logs all of the wind settings all of the time. [LATER] It occurred to me that, just possibly, your flicker could have been caused by the Monitoring of those two wind values on-screen in real time. It uses one of FSX's messaging facilities, but I have sen flicker in full screen mode with some video drivers. If this is what is doing it just don't bother with that -- I just thought it would be informative for you. Alternatively switch to a maximised Windowed mode, where I've never seen any such flicker. So far, with all the turbulences types and modes I've tested all the figures look good, exactly as designed. I'll not get to testing the 747 update till tomorrow now. Regards Pete

Okay. You need 4.293: http://fsuipc.simflight.com/beta/FSUIPC4293.zip Edit the FSUIPC4.INI file. Remove all Logxxxx=Yes lines (same as unchecking any logging in the Logging tab). We don't want a load of unnecessary logging spoiling the tabulation of the wind data. Add Debug=Please LogExtras=256 This enables those "Wind values set" lines I showed. Some changes I made since I showed that: 1) The logging is actually done OUTSIDE the hooks into the WEATHER/SIM1 link I mentioned, so that it doesn't affect the timing. 2) When I did (1) I noticed that sometimes (about 8 times a second) the log entry was being instigated twice at virtually the same time. Upon checking I found this was because I also do the same intercept from VISUALFX.DLL to SIM1.DLL. I actually forgot I did that too -- if I miss those calls incorrect wind values creep in and mess up the smoothing (causing jitters). So, I added a little more code to eliminate any increment when no apparent time had passed. In fact I do more than that -- if the time since the last increment is less than 40 mSecs, I reduce the increment in proportion to the time difference/40. This should prevent it changing the winds too fast during periods of high (internal) frame rates -- I'm effectively limiting the changes to 25/sec. This means with the default divisor of 40 that it takes 1.6 secs to reach each target. I don't increase the increment for slow frame rates -- all that happens then is you get less wobbly turbulence. 3) I fixed the logging of the Vertical speed targets. The log extract I showed above had the wrong values in that column. I've downloaded the latest update to the PMDG 747 and will try it later, maybe tomorrow. But I suspect the reason I've not seen any problems is that my frame rates have always been around 20-25 on my test machine. If the problem is due to faster changes because of higher frame rates I think my limiter, now added, should fix it. Regards Pete

Are you sure you are deleting all the assignments in FS? Check all the controllers it lists in the drop down -- it only shows you one connected controller at a time, you have to change the selection to see the others. Pete

Slight delay whilst I figure out how to change the logging so it doesn't affect the timings. Drat! I'll have to update the version number again then. :-) I looked at the results I was getting and decided they were being affected too much by the sheer act of logging (in-line between WEATHER.DLL and SIM1.DLL calls), so I am working on a way for the logging to be to memory during those times, catching up after. I'll upload 4.293 when I have it working. It'll be this weekend, but maybe not today. Please don't use 4.292 in any case. it'll drag your frame rates down a bit -- I tried changing the way I was getting the Time for the logging, to make it more accurate, and it is way too inefficient. Regards Pete

If you are running FSX and Project Magenta you cannot be using FSUIPC 1, so the question does not arise. And there's no "uninstalling" to do in any case -- simply deleting the DLL does it. Please do look at the supplied documentation where it tells you all you need to know! Pete

The range is simply minimum to maximum, linearly as far as I know. The "AXIS_THROTTLE_SET" controls go from idle to max only (idle at -16384, max at +16384). Only the older FS98 controls (THROTTLEn_SET) provide a reverse range. For those the numerical throttle position for IDLE is always 0, max is 16384, and reverse is negative -- the max reverse depending on the AIRCRAFT.CFG parameter for reverse thrust percentage -- for example 25% would be -4096 (25% of -16384). FSUIPC calibrates to -4096 but auto-scales this according to the specific aircraft. Since FSUIPC is setting the idle and reverse and other special values for you, according to your min/centre/max calibrations, I don't see how it can be "trial and error", nor do you need to know the specific values nor why. Add-on Airbus aircraft are another matter entirely of course, as with an Airbus you don't control thrust directly but set it to specific modes. But then you are dependent upon the interpretation of the throttle input values by the specific implementation. Regards Pete

I'm glad things are going well. Let's hope they stay that way! Just one more favour, please. In the Simconnect log you provided, whilst I was concentrating on the crash problem, I hadn't examined much else. However, looking at it a little more leisurely I find these repeated at intervals: > 5.16200 [ 0, 2354]TransmitClientEvent:ObjectID=0, EventID=0, dwData=0, GroupID=1, Flags=16 < 5.16202 [0] >>>>> EXCEPTION=1, SendID=2354, Index=2 <<<<< > 5.16203 [ 0, 2355]TransmitClientEvent:ObjectID=0, EventID=0, dwData=0, GroupID=1, Flags=16 < 5.16205 [0] >>>>> EXCEPTION=1, SendID=2355, Index=2 <<<<< Now this is FSUIPC sending events with an invalid (zero) ID to SimConnect. This won't happen with the 4.291 version, but I'm concerned as to why they were being sent in any case, so I need to dig deeper. To that end I would like to see your FSUIPC4.INI file, please, the one which you used to make the crashes happen (and which you use now I assume). Please ZIP and send to petedowson@btconnect.com. Thanks! Pete

I might have time to fly my own sim! ;-) Pete

Are you trying to use FSUIPC? Don't start with FSUIPC, get it all working in FS first. Pete