Jump to content


  • Content Count

  • Donations

  • Joined

  • Last visited

Community Reputation

1 Neutral

About martinboehme

  • Rank
  1. I'd like to use ChasePlane when flying with a 2D cockpit, but it doesn't work correctly for me. (Obviously, it doesn't make sense to use ChasePlane inside the 2D cockpit, but I'd like to use it for outside views.) When I switch from the 2D cockpit to an outside view (using the ChasePlane interface) and then back again (using the menu entry Views / View Mode / Cockpit / Cockpit), I find that the viewpoint of the 2D cockpit is offset from the correct position by about 10 or 20 meters. Once this happens, I haven't found a way to reset the 2D cockpit viewpoint to the correct position. Here are some screenshots that demonstrate this issue (with the Majestic Q400): First, the initial view from the 2D cockpit with the correct viewpoint: Next, the view after switching to an outside view using ChasePlane and then back again: Note how the viewpoint is displaced forward and to the left. (The position of the aircraft has not changed.) Finally, here's what I get at this point when I look back and to the right in the 2D cockpit (Shift Numpad 3): Note how the view is obviously displaced outside the virtual cockpit (which the Q400 displays when a view direction other than forwards is selected in the 2D cockpit). I've observed a similar effect with the FSLabs A320, though with this aircraft, the viewpoint is displaced upwards. I realize that as a 2D cockpit user, I'm probably in a small minority, but I would be grateful if this could be made to work, as I really like the control that ChasePlane gives me over outside views.
  2. >Winds are given in magnetic directionActually, winds aloft are given relative to true north -- the wind in the ATIS, OTOH, is magnetic.Martin
  3. Another point that doesn't seem to have been been mentioned yet: On takeoff, you need enough runway to be able to accelerate to V1, then abort the takeoff and decelerate back down to a stop. This increases the runway length required for a legal takeoff to more than the amount of pavement usually consumed until the wheels leave the ground.Cheers,Martin
  4. Hi Nick,some destinations I can recommend in terms of there being good freeware scenery available:KBOS (Boston)VHHX (Hong Kong Kai Tak)VHHH (Hong Kong Chep Lap Kok)Cheers,Martin
  5. >P.S to WarpD: I'm not trying to offer this DME for pilots,>it's just helping me for my autopilot system calculations. Not>so big deal :)Hm, can jump in here and take this off on a tangent...? ;-)I'm guessing what you want to do is adjust the sensitivity of the autopilot's corrections depending on your distance to the runway... so that as you get closer, your corrections become smaller and smaller...?This is something I've thought about as well (one of those "projects I'd like to do when I find the time" is a custom autopilot), and I've wondered how autopilots do it in the real world. Computing a "fake" DME is something that obviously can't be done in real autopilots -- so how do they deal with this? This is something I'd love to know... if anyone has this knowledge, please share it!I'm guessing that real autopilots do one of two things, depending on their level of sophistication:1. Just ignore the fact that LOC and GS get more sensitive the closer in you are. Adjust the gains in the autopilot controller until it works "reasonably well" between say ten miles out and 2/3 of a mile out (i.e. CAT I decision height).2. Use radar altitude as a surrogate for "distance to the threshold" -- this is probably a good enough substitute for adjusting the autopilot gains, and it's going to get more and more accurate the closer you get (CAT II/III even has certain guarantees).Has anyone got any real-world knowledge on this?Cheers,Martin
  6. >Presumably the code section is smaller and in blue because>you used the {code} script tag to preserve the formatting:Yep, that's just what I did...>For some reason though, it doesn't seem to switch back to>"normal text" even after the {/code} closing tag!So I guess it's just a known bug and I wasn't doing anything wrong?
  7. Sure... as a simple example: HMENU hmenu;UINT id;HWND hwndFS;// Let x and y be the position on screen where we want the popup menu// to appearint x=50, y=50;// Create the menuhmenu=CreatePopupMenu();AppendMenu(hmenu, MF_STRING, 1, "One");AppendMenu(hmenu, MF_STRING, 2, "Two");// Find window handle of the MSFS windowhwndFS=FindWindowEx(NULL, NULL, L"FS98MAIN", NULL);// Show the menu. The ID of the selected item will be returned in idid=TrackPopupMenu(hmenu, TPM_LEFTALIGN | TPM_TOPALIGN | TPM_NONOTIFY | TPM_RETURNCMD | TPM_LEFTBUTTON, x, y, 0, hwndFS, NULL);// Destroy the menuDestroyMenu(hmenu); This would then return either 1 or 2 in id (or 0 if the user cancelled the menu), and we can then perform the appropriate action.I just cobbled this up (my code constructs menus dynamically, so there isn't anything I could lift directly)... so the code isn't tested, but it should work, possibly with a few quickly corrected compiler errors.Cheers,Martin
  8. Thanks for letting me know! By the way, my browser shows the text below the code snippets in blue and in a smaller font -- do you know how I can avoid this happening?
  9. Update: My previous post was a bit premature... Turns out the technique is not very robust. For example, if the user switches to a different view, the frame counter will stop counting... menu selections etc. can also cause the technique to go wrong.However, I've since discovered a different technique that doesn't seem to suffer from these problems. The idea is to change a single pixel on the screen, then on the next PANEL_SERVICE_PRE_DRAW call, check to see if that pixel has been overwritten by Flight Simulator. If so, the front buffer is currently being displayed on the screen, and we can open the menu: case PANEL_SERVICE_PRE_DRAW: if(wantToShowMenu) { if(!haveSetPixel) { // Change a pixel on the screen hwndFS=FindWindowEx(NULL, NULL, L"FS98MAIN", NULL); hdc=GetWindowDC(hwndFS); colorref=GetPixel(hdc, 0, 0); colorref=colorref ^ 0xffffff; SetPixel(hdc, 0, 0, colorref); ReleaseDC(hwndFS, hdc); // Remember the color that we drew colorrefDrawn=colorref; // Remember that we've set the pixel haveSetPixel=true; } else { // Check if the color of the pixel now is different than // when we set it... hwndFS=FindWindowEx(NULL, NULL, L"FS98MAIN", NULL); hdc=GetWindowDC(hwndFS); colorref=GetPixel(hdc, 0, 0); ReleaseDC(hwndFS, hdc); if(colorrefDrawn!=colorref) { wantToShowMenu=false; ShowTheMenu(); } } } break; I'm hoping this code should be more stable -- I can't currently think of anything that could go wrong here, but who knows what further testing will uncover...MartinEdit: Switched off emoticon option
  10. Hello everyone,just wanted to share a discovery I've made. I'm currently working on a C gauge where I want to display a context menu when the user right-clicks on the gauge. The API call to display this kind of menu is TrackPopupMenu(), and in windowed mode, this works just fine. In full screen mode, however, the menu only appears half of the time; the other half of the time, the menu seems to be "active" but is not displayed.After some searching on the Internet, I found that the reason for this is that Flight Simulator is constantly switching between two graphics buffers when it does its rendering, whereas GDI always draws to the same buffer. So if I get lucky, the GDI buffer is active when I open the menu, and it gets displayed; if I'm unlucky, the other buffer is active, and I don't get to see the menu.There are a couple of API calls in DirectX to make the GDI buffer active before trying to display a dialog or menu -- FlipToGDISurface in DirectDraw and SetDialogBoxMode in Direct3D. However, to be able to call these routines, I would need to have access to FS's Direct3D interface, which I don't.However, I've come up with a hack that does pretty much the same thing. Figuring that FS switches buffers every frame, I decided that I would just count the number of frames from the point when FS initializes its rendering surfaces. I should then display the menu only on even frames, when the right graphics buffer is active. To paraphrase the code: case PANEL_SERVICE_PRE_INSTALL: frameCounter=0; break;case PANEL_SERVICE_PRE_DRAW: if(wantToShowMenu && (frameCounter%2)==0) { wantToShowMenu=false; ShowTheMenu(); } frameCounter++; break; And then I set wantToShowMenu to true in the mouse handler when the user clicks the button. PANEL_SERVICE_PRE_INSTALL seems to be the right place to reset the frame counter because it gets called when switching between full screen and windowed mode and when the window gets resized.Admittedly, this is a monstrous hack, but it seems to work, and I can't think of any other way to do the same thing. I haven't tested to see if it's graphics-driver dependent, but I'm hoping that it's not.I believe a similar technique could maybe be used to draw overlaid windows in FS, similar to what FSNavigator and FSInn do, though I haven't tested this. The idea would be to respond to a WM_PAINT by validating the client area (without doing any actual painting) and setting a flag that would cause the actual painting to be done in PANEL_SERVICE_PRE_DRAW.Hope this helps some of you who may be grappling with a similar problem...Cheers,Martin
  11. You're right -- FMCs _are_ complex...If you want to get an idea of how these things can be implemented, take a look at Alex Wemmer's vasFMC, which is a pretty comprehensive open source implementation of an Airbus FMC (and it has a Boeing-style nav display, too). Version 2, which will include a lot of new features, is currently in alpha:http://forum.vas-project.org/viewforum.php?id=2vasFMC is a standalone program, but a gauge implementation is planned for the upcoming version 2.As for documentation, the FMC manual or FCOM is probably a good place to go for all the "little details"...
  12. Bjoern,PID cotrollers are pretty much the standard method for building autopilots... so they should definitely be up to the job.Not that I have any practical experience with autopilots (I've been thinking of getting my hands wet for a while, though), but it sounds as if your gains need some tuning. Specifically, if the controller doesn't correct quickly enough when the target speed is reached, it sounds as if the gain for your "I" component is set too high relative to the "P" component. Also, to simplify things, you could try starting out with just a PI controller, then when you've got that working, add in the "D" component if needed for some fine-tuning.Martin
  13. Hi Bjoern,I'd say the problem is that your controller is trying to control the aircraft indirectly through another controller (Microsoft's autopilot). So a) you're introducing extra latency into the system (in effect, you're "twice removed" from the variable you want to control) and :( you're pretty much at the mercy of how well that second controller (in this case, Microsoft's autopilot) is doing its job...So I would suggest that instead of letting your controller act on the vertical speed setting of the autopilot, you let it act directly on the elevator... that should make the behaviour of your controller more predictable.HTH,Martin
  14. 10 degrees is the number I remember, too. Just to clarify, that's TAT, not SAT... because TAT is what determines the skin surface temperature. In contrast, the -40 degree number below which anti-ice is not required is SAT, IIRC...Cheers,Martin Boehme
  • Create New...