GregG

Aye, actually I wrote some really nice functionality to check the DLL version and offer to update to the user some months ago, but I never actually included FSUIPC.dll because I hadn't asked you about it. I finally got around to it. :) So I'm going to include just the FSUIPC.dll and will include information about where to get further information (the Schiratti site and this forum) in my documentation, if that sounds alright. I'll also make sure to point out where to register. :) And aye, I do have a freeware key for Livewire Assistant. Thank you very much. So far the functionality based on FSUIPC is working well. Cheers, Greg

Hello again, Pete. What is your policy regarding including the FSUIPC.dll in a freeware installation package? Can I do this? If so, what files do you require to be included at the same time? I checked through the docs and performed a cursory search of the forums and didn't see an answer to this. I apologize if it's been covered frequently before. Thanks again, Greg

Thanks for the update, Pete. Hopefully, someone will find it useful. :) I don't think I'm going to find a writable solution with a reasonable amount of effort, and my project is still in its infancy, so I'll probably leave it alone with the huge amount of work I have left to do. It just seemed that it would be a nice little draw, but it really was outside the purview of the project to begin with. I suspect that if there were an easy solution, there'd already be less feature-rich freeware alternatives to Active Camera. On the good side I gained some experience with FSInterrogate, which is good, as there are already several MSFS variables that I'm going to need that are not yet documented for FSUIPC. You'll be hearing from me again, I'm sure, hopefully bearing new discoveries and not just asking questions. ;) Thanks again, Greg

It's definately the view direction and not the nose direction. And it seems to work just fine from both the ground and the air, it just uses two different orientations. Under certain circumstances 0 is direction the aircraft nose is pointing. At other times 0 is north. As long as one can detect which mode is in use, the value can be understood. Further testing will need to be done to figure that part out. I thought it was air vs. ground but that does not appear to be the case although it might be related. If you are in gradual transition mode, the value moves exactly with the view rotation. So it will move quickly and then slow down until it's unchanging and then start moving back, just like gradual transition. If gradual transition is off then it moves in chunks, just like the view. If you use view selectors it changes in large chunks. Again, just like the view. Essentially, the value appears to be exactly the view direction regardless of other settings. Of course, even if this value is useful for reading, which its seems to me that it is, that doesn't help with my wish to write to it. I agree that the Active Camera folks have solved this and I was just hoping to solve it independantly. I feel that simple mouse panning is something that should have been in MSFS to begin with, as it is with most flight sims, and just wanted to produce a freeware option for this minuscule subset of Active Camera's impressive functionality. I have no interest in producing a similar product, but I doubt I can convince them of that. Thanks, Greg Edit: On further testing it appears there is only one "mode". I was just misinterpreting some results. 0 is north and is not related to the nose direction. I was confused due to the fact that I was getting 0 at 340 (as the Seattle Tacoma starting runway is on that bearing). Then, once I realized that this was due to indicated north not being the same as the internal (true) north, I didn't "rethink" the situation. Edit2: To test this I did as you suggested, I put it into slew and pressed the space bar. The offset in question went to 0 in cockpit mode. 0 in VC mode if I press space again (to reset the head position), and 0 in spot mode if I press Shift+Num2 (to reset the view to looking in line with the nose). Then, in spot mode, I used my hat to rotate (the view not the airplane) one notch to the right. The offset changed to 2700. A second notch goes to 5400 and so on. This works in VC mode as well. From looking straight ahead with the aircraft pointing due north, moving one notch to the right brings the value to 1350, two notches to 2700, etc. Apparently with my settings one hat notch in VC mode turns the view one half as much as one hat notch in Spot mode.So this does indeed seem to be a perfect representation of the view direction on the horizontal plane.

Indeed, I wasn't very specific. Let me remedy that. :) It is 0 at north and continues around to 65535. 16384 would be east, etc. More testing needs to be done but it seems that when on the ground (just after loading a flight, at least) this value orients on the aircraft. However, once up in the air it orients on north. It's definately not indicated north though. I assume there's an FS9 internal north and it uses that, but I'm not too knowledgeable about that. It seems to be, in Seattle, about 20 degrees off of indicated north. (0=340deg/32768=160deg) So ~0 = straight ahead/north, 16384 is right/east, 49152 is left/west, etc. Or you can read it as a smallint and it is 0 = straight ahead/north 16384 is right/east and -16384 is left/west. As for which view it pertains to, it seems to be valid for cockpit, VC and spot views. Of course, in true cockpit view, the value stays near 0 (56 on my test). I did not yet test tower view as I never use it. I haven't determined if there is another value for the vertical plane, but it should be easy for me to find if you'd like. Just during those tests I noticed that 030A and 05D0 are related. Writing to offset 3126 doesn't work for me, unfortunately, as I need minute control (< 1 degree). For my needs I'm looking to control this in VC and spot views. Thanks again, Greg

Hello Pete, The new flight start determination offset you added to 3.12 is working marvelously, I'm pleased to say. Thanks, again. My sim run-up feature works just as planned. I have a new question. I've been using FSInterrogate to try and find an offset to allow me to adjust the view direction. I located 05D2 which seems to be a word value with 0 = North and originally appeared to be just what I was looking for. However, it seems to only work as read only, as values written to this offset are just written over again by FS9. (At least with writting using FSInterrogate, I have not tried to write with FSUIPC but I assume the results will be the same.) Is it possible there is a variable that I need to flag to force the change or have I just stumbled on a read-only offset that is useless for my purposes? The feature that would use this is extremely low priority, so I'm not going to dwell on it too much, but I wanted to make sure I wasn't missing anything obvious. That FSInterrogate is really handy now that I figured out how to make use of it. :) Thanks, Greg

If it's not too much trouble, then that would be quite helpful so I can more comfortably move forward. Would I have permission to let a few of my beta-testers use it as well? I would only send it to them directly and would not make it available otherwise. If not, no worries, it's still a help. Either way, thank you again, Greg

That sounds good, too. :) This feature should get a thorough checkout once the next version of FSUIPC is released as I know at least several of my beta-testers plan to use the feature dependent on this addition. Since the implementation of this feature is quite simple, I'll go ahead and add the code for it now, so it's ready when 3.12 is released. Actually, that's a point. Are new features like this added "right away" and released with the next version or do they tend to be one or two releases down the road (I'm not sure about your development/testing practices)?

Only if you too are curious. Since you've found an alternate solution, there's certainly no need, but purely out of curiousity it might be interesting. It would be really easy if you feel secure running the little alarm program I provided. If you are concerned about it, you could build it from the project yourself. It should start to go off when FS2004 starts but should then stop once a flight starts loading. It should then only go off for a moment when loading a new flight or when changing views. At least that is how it functioned on my system and two of my beta-testers systems. Again, there's really no pressing reason to bother, though. Exceptional news! Thank you Pete. I'll be greatly looking forward to your next release.Best wishes, Greg

Dear Pete, Thank you for your further testing on this. Unfortunately, I have been unable to do anything over the past four days due to some severe problems with my server. I'm very glad to hear you've made progress on this although I'm sorry my ideas haven't panned out for you so far. Just out of curiousity, you are saying the unnamed window, for you, does not disappear during the loading of the flight? If so, then obviously you are right. I was hoping more of my beta testers would check on it for me, but, unfortunately, only two did as far as I know. That's not quite enough folks to consider it a valid sampling. :) I'm looking forward to the implementation of your new discovery and am glad that at least my interest in this feature has helped you solve it for yourself. :) Thanks again, Greg

As I think back, I believe this indeed is what happened (it would maintain a single value when the 3d screen was not displayed.) I'll double check the specifics of this, however, the unnamed window method will probably be more useful, or, perhaps, a combination of the two. Thanks, Pete. Hopefully, my research into this will be of use to you as well.I'll report back when I have some new findings. Thanks again, Greg

Just an update. I've had pretty encouraging reports on this from my beta-testers. However, an unnamed window does appear momentarily when changing from internal to external views. I'm going to see if it has the same characteristics as the pre-flight-init window in the hopes it's a different window that can be differentiated programmatically by window characteristics/styles. If it's the same window, then it will make this a less effective method of detection, unfortunately, but not useless. Edit: Unfortunately, it's the same window. It has the same characteristics, and, more importantly, has the same window handle. But, this isn't a complete waste. As a matter of fact I've implemented it in my original program and it seems to work pretty well. But it's not a panacea for the whole situation. I'll try to keep thinking about this and see if I can find something. I still haven't re-investigated polling the FPS offset. If you find anything or have any further suggestions, Pete, please let me know. Edit2: I've double-checked using the FPS offset for this. It reports a > 0 value consistently (polling once per second) even if a flight is being loaded. Any other suggestions would be welcome. I'm happy to do the testing.

Just to followup on the unnamed window idea. It seems to work on some initial testing for FS9. If you want to test it here's some simple code: HWND CFSUIPCInterface::DetectUnnamedWindow(void) { HWND hwndUnnamedWindow = NULL, hwndFS9TopLevelWindow = FindWindow("FS98MAIN", "Microsoft Flight Simulator 2004 - A Century of Flight"); if (hwndFS9TopLevelWindow) { hwndUnnamedWindow = FindWindowEx(hwndFS9TopLevelWindow, NULL, "FS98CHILD", ""); } return (hwndUnnamedWindow); } The only caveat I've found so far is that the unnamed window doesn't disappear if you have FS9 minimized. Otherwise, this will obviously need some testing and see if that unnamed window appears under other circumstances, such as during a long flight. Therefore, I wrote up a little utility that watches for the window and beeps once per second when it finds it. The executable: http://www.bitspring.com/misc/FS9FlightInitAlarm.zip The VS.NET 2003 project: http://www.bitspring.com/misc/FS9Flightroject.zip If you would, let me know if you find this works for you as well, Pete. I can probably get some of my beta testers to try it as well. Oh, and don't judge me on the code. I just build a basic Win32 project and added in the bits I needed. There's nothing elegant about it. :) Edit: One of my beta-testers reported (and I've verified) that the unnamed window is present when first loading FS9 up until one creates or loads a flight and that flight starts loading. So it's presence alone is not in any way telling. However, the disappearance of the unnamed window seems to indicate that the flight is beginning loading. This may be enough for my needs, and hopefully useful to others, if this holds true after further testing.

Actually, no. I started development on this a while before I decided to widen its scope and then started using FSUIPC. For launching the customized flights, plans and aircraft, I simply use the FS9 command-line parameter /FLT:. If a FS9 process is already running, it launches the flight in the existing process, if not, it launches a new process and loads the flight. I will do so, Pete. I'm pretty determined to find an answer to this, and if I do so, you'll be the first to know. :) I did some very cursory looks at using the FPS to detect this, and after some initial setbacks I did not try further. Therefore, it's not been sufficiently tested to indicate it's usefulness. I'm going to investigate this unnamed FS9 window first, as it seems to hold the some promise. I just have to reacquiant myself with enumerating windows within a process before I can test anything. Thanks, Greg

Thanks for the response, Pete. Let me outline what I'm currently implementing. I actually need to detect what I'm asking for other reasons, but this one is the most complex implementation that requires it and is the one I'm currently working on. The application in question is very multi-purpose. Amongst many other things, this program launches flights after making customizations. The feature giving me trouble is called sim run-up and what it does is load the flight X minutes early and then time accelerates up to 4x until the original flight time is met and it sets time accel back to 1x and pauses. I have all the code in to do this, and can, indeed get it to work some of the time, but without a reliable way of detecting the flight init process, it can't seem to make it fully reliable. I could, for this feature, simply have the user push a button to start the process once the flight is loaded, but that's not a good solution for various reasons, including that I need this level of detection for other planned features. I've tried basing the detection on shifts in the in-flight time, but this is not reliable (after putting 12 hours of trial and error into it). Shifts in position are even less reliable for the reason I give in and earlier post in this thread. I'm utterly frustrated at this point. But I haven't given up. I really can't give up since I feel that this form of detection is crucial to my project. I'll be happy to give any other information you need. Thank you, Greg Edit: I'm investigating another option. According to Spy++, there seems to be an unnamed window open in the FS9 process when it's loading a flight. I'm going to look into this for a very undocumented way of detecting what I need. :) But if I could do it through FSUIPC somehow, it would be preferable, as this might be a red herring.

Raymond, thank you for your suggestion. Knowing the expected position is not a problem as my program launches the flight. However, I can think of some scenarios where that might not work. For example, my VA usually uses the exact same starting gate for all flights from the same hub. If someone loaded flight A and then flight B there would be no position shift to detect since the variables aren't cleared (as far as I can tell) between loadings. Someone I contacted about this off the forums (whose name I omit simply because I dont like giving peoples names in public forums without their permission) had an interesting suggestion to use the FSUIPC "run program" feature which will launch a program when the flight is finished initializing. I could implement something based on this, and probably will, but I wonder that if FSUIPC knows when the init is complete in order to have that functionality, couldn't it feasibly maintain a variable that could be queried by programs? I'd be interested to hear from Pete on this when he's caught up from being away. This is far more important to detect reliably than the 2 other scenarios I mention, to me. This gentleman also generously suggested a possible solution to detecting what window the user is looking at, by enumerating the process windows which is doable. As for the third scenario, detecting "End Flight" I don't think I really have a solution to that yet. I suppose I could watch that window for the appropriate message for the button being pushed, but I'd much rather know if there's a more direct route to detecting this. Thank you, Greg

I'm sure this is just a frequently asked question but I couldn't find anything specific in the SDK about it, I tried many offsets that seemed related according to the docs, but found none that worked, and performed several searches in these forums. I suspect I'm just missing something obvious. What is the best offset to poll to detect whether a flight is fully loaded? (By fully loaded I mean the point where it's now safe to start reading and writing in-flight variables.) Furthermore, can this method be used to detect if the player is viewing a screen that is not part of the flight experience (such as display settings, etc.)? I also need to make sure that I know if the player does an "End Flight". Most of the offsets I tried still showed the leftover settings from the previous flight after an end flight. The general note regarding offset 0x4D2 sounded relevant, but I still don't think it's what I'm looking for, as FSUIPC is initializing just fine. Currently, I need to do this for FS2004, although ideally I'd like to be able to detect the same thing for FS2002. My application is a fully external .exe. I'd appreciate any help regarding this issue. Thank you, Greg

Hi Pete, thanks for the quick response. According to my sent mail in my email client, I sent it to 'petedowson@btconnect.com' with subject 'FSUIPC and Livewire Assistant Freeware'. That email address seems to be right so I'll resend it right now. If you don't get it, I'd appreciate it if you let me know and I'll try and figure out where things are going wrong. Thanks so much, Greg Edit: Contact has now been established :wink:

Hello Pete, I was wondering if you received my email request for a freeware access key, as I haven't received a response. I sent the original request two weeks ago. It was in reference to my product, Livewire Assistant. If you did not receive the email, and I should resend, or should you need any further information, please let me know. If you just haven't gotten to it, there is no hurry, I just wanted to check. Thank you, Greg