Luke Kolin

Sorry I have not gotten back to you sooner, Pete. It's been chaotic here. The FS9 implementation certainly works "correctly" in 3.908, and I think the FSX does. My memory is giving out. Cheers! Luke

I downloaded the guides and example LUA plugins and was able to get something basic cobbled together in around 30 minutes. You deserve a hearty "thank you" for making things so easy to delve into from this perspective. So thank you! Here's the data I logged. I had a 23ms sleep interval, and I'll give you the second I took off, as well as my landing. It's a VistaLiners 727 out of JFK 4L to LGA 31, my standard test flight. The landing is more interesting (but I figured I'd include the takeoff as well if anyone was interested). What's interesting is in both cases (I bounced my landing) the peak Gs don't seem to occur until about 50-75ms after FS detects we're on the ground. I'll try an FSX run, assuming I can do this with an unregistered FSUIPC4. (I only have FSUIPC3 registered). If you want/need any other data, feel free to let me know. Cheers! Luke msecs,timeL,ias,onGround,takenOff,G 45563,17:48:27,154,1,0,0.976 45578,17:48:27,154,1,0,0.976 45610,17:48:27,154,1,0,0.976 45641,17:48:27,154,1,0,0.974 45656,17:48:27,154,1,0,0.974 45688,17:48:27,154,1,0,0.974 45703,17:48:27,154,1,0,0.974 45735,17:48:27,154,1,0,0.973 45750,17:48:27,154,1,0,0.973 45781,17:48:27,154,0,0,0.854 45797,17:48:27,154,0,1,0.854 45828,17:48:27,154,0,1,0.741 45844,17:48:27,154,1,1,0.762 45875,17:48:27,154,1,1,1.091 45891,17:48:27,154,1,1,1.091 45922,17:48:27,155,1,1,1.411 45938,17:48:27,155,1,1,1.235 45969,17:48:27,155,1,1,1.008 45985,17:48:27,155,1,1,1.008 46016,17:48:27,155,0,1,0.922 46031,17:48:27,155,0,1,0.870 46063,17:48:27,155,0,1,0.858 46078,17:48:27,155,0,1,0.858 46110,17:48:27,155,0,1,0.877 46125,17:48:27,155,0,1,0.896 46156,17:48:27,155,0,1,0.915 46172,17:48:27,155,0,1,0.915 46203,17:48:27,155,0,1,0.931 46219,17:48:27,155,0,1,0.947 46250,17:48:27,155,0,1,0.963 46266,17:48:27,155,0,1,0.963 46297,17:48:27,156,0,1,0.979 46313,17:48:27,156,0,1,0.994 46344,17:48:27,156,0,1,1.006 46360,17:48:27,156,0,1,1.006 46391,17:48:27,156,0,1,1.019 46406,17:48:27,156,0,1,1.032 46438,17:48:27,156,1,1,1.045 46453,17:48:27,156,1,1,1.045 46485,17:48:27,156,1,1,1.123 46500,17:48:27,156,1,1,1.123 46531,17:48:27,156,1,1,1.125 46547,17:48:27,156,1,1,1.125 297766,17:52:38,125,0,1,1.046 297797,17:52:38,125,0,1,1.046 297813,17:52:38,125,0,1,1.046 297844,17:52:38,125,0,1,1.046 297860,17:52:38,125,0,1,1.046 297891,17:52:38,125,0,1,1.046 297906,17:52:38,125,0,1,1.045 297938,17:52:38,125,0,1,1.045 297953,17:52:38,125,0,1,1.045 297985,17:52:38,124,0,1,1.045 298000,17:52:38,124,0,1,1.045 298031,17:52:38,124,0,1,1.045 298047,17:52:38,124,0,1,1.045 298078,17:52:38,124,0,1,1.045 298094,17:52:38,124,0,1,1.043 298125,17:52:38,124,0,1,1.043 298141,17:52:38,124,0,1,1.043 298172,17:52:38,124,0,1,1.043 298188,17:52:38,124,0,1,1.043 298219,17:52:38,124,0,1,1.043 298235,17:52:38,124,0,1,1.043 298266,17:52:38,124,0,1,1.043 298281,17:52:38,124,0,1,1.042 298313,17:52:38,124,0,1,1.042 298328,17:52:38,124,0,1,1.042 298360,17:52:38,124,0,1,1.042 298375,17:52:38,124,0,1,1.040 298406,17:52:38,124,0,1,1.040 298422,17:52:38,124,0,1,1.040 298453,17:52:38,124,0,1,1.038 298469,17:52:38,124,0,1,1.038 298500,17:52:38,124,1,1,1.037 298516,17:52:38,124,1,1,1.037 298547,17:52:38,124,1,1,2.224 298563,17:52:38,124,1,1,2.224 298594,17:52:38,124,1,1,3.259 298610,17:52:38,124,1,1,2.266 298641,17:52:38,124,1,1,1.037 298656,17:52:38,124,1,1,1.037 298688,17:52:38,124,1,1,0.878 298703,17:52:38,124,1,1,0.878 298735,17:52:38,124,1,1,0.880 298750,17:52:38,124,1,1,0.880 298781,17:52:39,124,0,1,0.880 298797,17:52:39,124,0,1,0.878 298828,17:52:39,124,0,1,0.877 298844,17:52:39,124,0,1,0.877 298875,17:52:39,124,0,1,0.875 298891,17:52:39,124,0,1,0.875 298922,17:52:39,124,0,1,0.874 298938,17:52:39,124,0,1,0.874 298969,17:52:39,123,0,1,0.874 298985,17:52:39,123,0,1,0.872 299016,17:52:39,123,0,1,0.872 299031,17:52:39,123,0,1,0.872 299063,17:52:39,123,0,1,0.872 299078,17:52:39,123,0,1,0.874 299110,17:52:39,123,0,1,0.874 299125,17:52:39,123,0,1,0.874 299156,17:52:39,123,0,1,0.874 299172,17:52:39,123,0,1,0.875 299203,17:52:39,123,0,1,0.877 299219,17:52:39,123,0,1,0.877 299250,17:52:39,123,0,1,0.877 299266,17:52:39,123,1,1,0.877 299297,17:52:39,123,1,1,0.875 299313,17:52:39,123,1,1,1.586 299344,17:52:39,123,1,1,1.510 299360,17:52:39,123,1,1,1.189 299391,17:52:39,123,1,1,1.189 299406,17:52:39,123,1,1,0.973 299438,17:52:39,123,1,1,0.955 299453,17:52:39,123,1,1,0.955 299485,17:52:39,123,1,1,0.992 299500,17:52:39,123,1,1,1.003 299531,17:52:39,123,1,1,0.992 299547,17:52:39,123,1,1,0.986 299578,17:52:39,123,1,1,0.986 299594,17:52:39,123,1,1,0.992 299625,17:52:39,123,1,1,1.002 299641,17:52:39,123,1,1,1.008 299672,17:52:39,123,1,1,1.008 299688,17:52:39,123,1,1,1.010 299719,17:52:39,122,1,1,1.008 299735,17:52:39,122,1,1,1.008 299766,17:52:39,122,1,1,1.008

That might be true. I think we each have the same doubts, just on different sides of impact. :) I suspect I'm getting a normal, rather than impact-related, value. Ah, dragging me into Lua kicking and screaming! :) I've suspected that I need to learn how to do this for a bit. I'll dig into it later tonight. Apologies in advance if I come back with a few silly questions. Cheers! Luke

Thanks for adding this into 3.907 so quickly. I did a brief test this evening and it seems to work accurately. I'm wondering, however, if it might be better to get the value at the first frame *after* the aircraft is on the ground, rather than updating while in the air. The latter value (and FSUIPC's current behavior) seems to work well for vertical speed, but I seem to get a sub-one value for G forces, whereas one would expect this value to be >1 on touchdown. Does this make sense? I recognize that the latter behavior is also significantly more complicated to implement, and I apologize. Cheers! Luke

We've extensively used offset 0x030C to read vertical speed at touchdown; it provides a good clue as to the quality of the landing, but it's not used in the real world AFAIK. I was wondering if it would be possible to add another offset similar to 030C to read G-forces while airborne, then cease updating on touchdown. I believe the offset to fetch from would be 0x11BA, but only while airborne, much like the relationship between 030C and 02C8. Cheers! Luke

I am trying to get an absolute Angle of Attack value calculated, for use across a wide variety of aircraft. I was reading here: http://forums.simflight.com/viewtopic.php?f=54&t=4603&start=0&st=0&sk=t&sd=a&hilit=Angle+of+Attack And it appears (confirmed with my work with FSInterrogate) that after adjusting the value, I get a relative AoA with is a percentage of the maximum AoA value for the aircraft, contained in the AIR file. Is there any way to expose this value via an FSUIPC offset, or get at it programmatically? Cheers! Luke

Many thanks, Peter. I greatly appreciate your work and flexibility when adding new features to your software. Cheers! Luke

Cool! I wasn't aware of that - I don't believe it's listed in the 4/06 SDK. Is there a newer version? It's not something I need right away, but if you ever do have some free time it I believe would be a welcome addition for those of us with fuel planning software and WideFS. It's not really for me; we have several thousand users of my software and I would prefer to have something that works as simply as possible without setting up file sharing. To be honest, if there was a handy feature that I'd love to see, it's an FSUIPC/WideClient facility to allow software running on WideClient to read any arbitrary value from the aircraft.cfg. Cheers! Luke

I have a nifty fuel loading module for my software that depends on knowing the empty weight and max gross weight of the current aircraft. While one can read ZFW via an FSUIPC offset, MGW appears to be in the aircraft.cfg, which doesn't appear accessible if I'm running on WideClient. Is there any way to expose aircraft.cfg data to WideClient software, or MGW specifically via an offset? Cheers! Luke

It looks like the SimConnect version is now 10.0.61242. I assume that the minimum build for FSUIPC 4.10 remains 60905, since it works with both FSX and FSX SP1? Cheers! Luke

Murray, take a peek here: http://forums.simflight.com/viewtopic.php?t=59965 The second-last post might be the same problem you're encountering. Cheers! Luke

My gut tells me that the user you're running FSX/FSUIPC as doesn't have permissions to write to the file where FSUIPC saves its settings. Have you tried switching to Administrator before you run FSX and calibrate the axes? It's reassuring to know that a) there are systems that can run FSX well, and b) the mystery of higher than normal HST receipts has been explained. :) Cheers! Luke

Is there any way to easily extract ILS data using MakeRunways? I'm trying to build a database of ILS frequencies/courses out of the FS scenery, depending on version. Cheers! Luke

You do NOT need to re-purchase. Just enter in your e-mail address and registration code in the FSUIPC dialog from the Modules menu in FS9. Cheers! Luke

That sounds just fine by me. I'm drinking from a firehose here and I'm probably going to take a serious stab at things once you release your installer and I can get some ideas of what should be done and the manifests you are embedding in your file. Looking a little further, it looks like the ACTCTX calls are kernel32 functions, that appear to be XP and above. Again, I don't see a problem calling those but I'm going to wait and see what you do with your installer and take baby steps from there. I appreciate your willingness to help out here. Rest assured, I have no intentions of putting out a crappy product that will cause you support headaches. It reflects poorly on both of us, deservedly so for me, and not so for you. I want to ensure that you have confidence that my installers do the right thing, just like they have done for v2 and v3. Cheers! Luke

Thanks for the outline, Peter. I agree with your concerns that FSUIPC installation is not trivial when compared with previous versions. Based on a quick review of things, I agree that #3 and #6 are the most likely to have issues. For #6, I'm already digging through the AppData folders to get the FS9.CFG, so adding another entry for DLL.XML and manipulating it won't be too hard. I then have to loop through and modify ALL of these files, but that's probably good practice if I'm installing something like FSSOUND.DLL. For #3, since I haven't done more with the SimConnect API than install it on my PC, I need to examine this some more. If the functions needed to validate the SimConnect version are publicly exposed in the FS DLLs, then I believe our NSIS installers can call them just like we would any other part of the Win32 API. I already do so to detect FS running and multiple installer copies by checking for window handles and creating semaphores. If I've misread what's involved in step #3, I apologize in advance. I'm going to dig through some more. Again, I think a silent version of the installer (perhaps with an optional parameter to supply the location of FSX) would probably be OK, but my inclination as a developer is to determine what is going on under the covers and ensuring that I am doing it right and can validate that the install is successful. I certainly don't want to cause additional headaches for you Peter, but I am also interested in ensuring that FSUIPC4 operates under the existing FSUIPC install framework we have. Cheers! Luke

We'd rather not be spawning external programs from our installers, when they are perfectly capable of doing the same thing as the FSUIPC installer. All of our installers currently detect the currently installed version of FSUIPC, determine wether an upgrade is necessary and prompt the user accordingly, without the additional overhead of a seperate installer. I recognize and sympathize with your concerns and ensuring that installers behave responsibly. This is critical to ensuring that users have a positive FSUIPC experience, but I would very respectfully suggest that the solution is to provide complete documentation to third-party developers (just as you have to FSUIPC itself) and then ensuring (through cooperation and shaming) that we meet the same high standards as you. The end-user experience is critical to us as well, which is why we want to have control over the entire installation process instead of merely spawning an external process that can probably only give us a "TRUE/FALSE" result. We want to work with you because our goals are the same. I've offered before and repeat now my desires to publicly release NSIS sources to our installers' FSUIPC installation code, so that other can "do it right" as well. Realistically, the installer will never operate in a vaccuum. It won't take too long to reverse-engineer the changes it makes to a vanilla FSX installation (just like in the past), which is a situation where you cannot control what others do. Documenting and recognizing that other installers will want to install FSUIPC by themselves I think provides a better level of control for you, and better outcomes for everyone. Cheers! Luke

Probably good - our ACARS package deals with a number of different parameters and that seems to be the only one that doesn't work! Thanks again Pete. Cheers! Luke

One of our FSX beta testers was testing out our ACARS package with FSX, and indicates that it works great except for one little thing; Offset 030C (the touchdown rate offset) appears to read zero. I can't verify the report, but I figured I'd pass it along for whatever it's worth. Cheers! Luke

Does your installer have a "silent" mode? Cheers! Luke

For those of us who have bundled FSUIPC.DLL with our applications, do you plan to document what the installer is doing? We much prefer being able to have our installers seamlessly detect wether to do an FSUIPC upgrade and making it all happen automagically. I'd be happy to share any NSIS code I write with the community. Cheers! Luke

My initial guess is that the floating point ops you are doing barf when they attempt to get stored back into a Long. Try using a Double for your final result, and see what happens. Cheers! Luke

And that was exactly it. I discovered that Elevators and Ailerons were getting inputs from the CH Yoke and the CH Throttle. 15 seconds later, all was well. Thanks Peter! Cheers! Luke

I never thought of that, but on its face it makes perfect sense. I'll give it a whirl when I get home and let you know. Thanks! Cheers! Luke

As a disclaimer, I'm 99% certain that this is NOT a FSUIPC issue. However, since I'm diagnosing it via FSUIPC and there are some experts here on FS Control values, I figure I'd throw it out there. I have a 3-lever CH Yoke, and the aileron axis returns values between -16384 and 16384. The Yoke was caliberated just the other day, and from the XP Control Panel it appers to be OK and centered. When I rotate the yoke left and right the values change in the FSUIPC calibration screen, but when the yoke stops moving and is held at a particular position, FSUIPC reports that it's geting an IN value of 785. Essentially, if I turn the yoke left for full left bank, I see the IN values decrease below -16000, and then a 1/4 second later I see 785 IN. I do NOT see this behavior in Control Panel when I move the yoke around so I believe that the yoke is sending the correct values into FS9, but before FS9 passes them to FSUIPC for display, it does something funny. Does that seem reasonable? Anyone have any ideas as to why this would be happenning, or a possible solution. My first instinct is to nuke FS9.CFG, but before I do that I'd want to double check if there's any less invasive way to fix this. Cheers! Luke