Luke Kolin

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

Because we're not masochists, or because sometimes we have a conceptual misunderstanding that prevents us from solving the problem, or perhaps it's far more efficient to ask than to suffer and then create a suboptimal solution. In my work I see a lot of people attempt to tough things out, and what they often end up with is something that barely works but it works nonetheless. It's not much better than copy and paste, since they don't know why it all works and is like "Cargo Cult" engineering. Cheers! Luke

What are these "guidelines" that you speak of? :) It might make things easier for misbehaving software, yes. But when it comes to filenames, there are no "guidelines". Either the filename is valid, or it is not - and if it is valid it is expected that it is supported. (Please note that I have not read the above thread in years, and am not commenting on anything beyond your post.) Cheers! Luke