Jump to content


  • Content Count

  • Donations

  • Joined

  • Last visited

Everything posted by martinboehme

  1. The pitch-up tendency in a 172 is definitely very pronounced, so I don't think XP exaggerates it. I'm currently a few hours into my flight training on a 172, and the first time I deployed flaps, the pitch-up caught me off guard, even though my instructor had cautioned me about it. You learn to anticipate it and start putting forward pressure on the yoke and reaching for the trim wheel as soon as you put in another notch of flaps.
  2. I think that article is using "interpret" in its general English-language meaning and not in the specific computer science meaning. WASM definitely gets compiled to machine code. The article you linked to earlier shows machine code compiled from WASM (which in turn was compiled from C++ code) and compares it against machine code compiled directly from the same C++ code (Figure 7 in the article). But it's certainly true that WASM is slower than machine code compiled directly from C++. I think what's special is that Flight Simulator will have a wealth of addons available for it, and those addons are sold directly through an in-game marketplace. I think Microsoft / Asobo would be concerned about two things: How do they make sure an addon doesn't crash the sim, and how do they make sure an addon doesn't do malicious things? If the addon is allowed to run native code directly in the Flight Simulator process (as a DLL), both of these things are impossible to guarantee -- Microsoft / Asobo essentially need to trust the addon developer. In FSX and P3D, at least the former category (addons that crash the sim) are a common annoyance, and worse, it's often hard to pinpoint which addon is to blame. For the case of a professional training environment that you bring up, both of these points would presumably be moot. You would presumably be developing the addons yourself, and testing them carefully, or you would be sourcing them from trusted parties with whom you have a close working relationship. In this scenario, WASM adds overhead without any benefit. I think it's pretty clear though that this isn't the use case that Microsoft / Asobo are after. For the case of "study level" addons for enthusiasts from the likes of PMDG, I'm still optimistic that WASM will be viable technology once the required APIs are in place, but it's becoming clear that this will take time. This is what I'm getting from Robert Randazzo's post too -- assuming the post isn't marketing spin (which isn't usually his style), he's enthusiastic about the platform and the potential but cautions that things will take time.
  3. This reads as if there's a big difference between C++ and WASM - but in fact, WASM is specifically designed as a way of running C++ code. WASM isn't interpreted, it's compiled to machine code. In fact, the same is true when running JavaScript in a modern JavaScript VM, but you can typically generate much more efficient machine code for WASM than JavaScript. A big reason for this is JavaScript's dynamic typing and its type system in general. Yes, WASM is viable for projects of this size. I have worked on similar size projects in NaCl, a forerunner of WASM. WASM doesn't reach quite the same performance as compiling C++ directly to machine code, but it's close (factor of two or less). JavaScript is much slower. I'm not sure if Asobo have stated their reasons, but from my point of view, while Xbox may a reason, there are at least two other reasons to go with WASM: 1. It integrates well with JavaScript. 2. It provides a way to sandbox an addon's code. This means that a crashing addon doesn't bring down the whole sim, and it also makes it easy to identify what the culprit for a crash is. As noted above, it does allow C++. My understanding is that, currently, the main issue that developers are having with WASM in MSFS is not WASM per se but the APIs that are available to addons that use WASM, and this is what needs to be worked on. Edit: That's not to say that adding the required APIs will be an easy task. Robert Randazzo's post doesn't go into specifics, but what I'm reading between the lines is that Asobo was surprised at the scope of functionality they need to provide through APIs for PMDG and similar addons. (Added this edit because I reread my original post and realized it sounded as if I was saying there wasnt a problem with the current SDK.)
  4. Thank you for adding some real-world perspective on this! It's actually pretty easy to see why heavy doesn't have to mean sluggish. Heavier aircraft have larger control surfaces to account for their greater inertia. If the size of the control surfaces increases proportionally with aircraft mass, then maneuverability will, generally speaking, stay the same. There are certification requirements for maneuverability (e. g. minimum roll rate), and I have my doubts that the A320 as currently simulated in MSFS would meet them...
  5. I believe a community mod is being worked on as we speak. 😉
  6. This may be an unpopular opinion, and the word not allowed are going to pour hate on me, but I'll put it out there anyway: Real-World Flying is full of critical flaws and should never have been released in its current state. Right off the bat, control assignments are a joke. There's a single default control configuration. No custom key assignments. No sensitivity adjustment. And I wasn't able to get a single one of my existing controllers to work. What were the devs smoking? Did anyone actually ever try to use this sorry excuse for a sim? Next up: Weather. Incredibly, there's exactly one weather theme. One! Admittedly, it evolves dynamically and seems reasonably realistic, but there's zero ability to customize anything. No cloud layers, wind layers, visibility controls, nothing. You can't even set time of day. I mean, this is super basic stuff. Did none of the beta testers ever notice this was missing? Seriously? Then there's the aircraft. Normally, I'd qualify my opinions by saying that I'm not checked out in any of the types I'm about to comment on, but there are tons of issues here that no one can tell me are realistic. The A340 is woefully underpowered. No exaggeration, it only manages to climb thanks to the curvature of the earth. Stalls in the Tomahawk are a joke. Every single stall seems to devolve into a spin - there's no way that would ever get certificated. And don't get me started on the 737 MAX. The trim system is super buggy - it keeps winding in nose down trim on me until it becomes virtually uncontrollable. The most ridiculous bit though is the pricing. The basic game is free, but it only allows you to spectate - not a single aircraft is included. DLC pricing is outrageous. Even the most basic aircraft will set you back thousands of dollars. That much money surely buys you a lifelong right to fly your aircraft, right? Wrong! Every year, you're made to pay thousands of dollars in "annual" fees just for the privilege of continuing to fly an aircraft you already own! And it doesn't stop there. Every time you fill the tanks, say goodbye to another couple hundred bucks or more. It's the most blatant money grab I've seen in any game (no, I'm not willing to call this pile of junk a sim). Sorry, but I've had it. Until the devs reconsider their pricing and fix the many, many egregious flaws, I'm going back to MSFS.
  7. I think the reference to porting C++ code with WebAssembly pertains more to the kind of complex systems logic that you see from companies like PMDG. It makes sense to be able to port this code, rather than having to rewrite what likely amounts to hundreds of thousands of lines of code. The complexity in an FMC alone is staggering - no add on developer is going to want to throw away a code base that has years of development invested in it.
  8. None in particular. Just that consoles in particular have changed processor architectures in the past - and WebAssembly would make a possible future transition seamless for addons. However, better stability is probably the overriding reason for using WebAssembly.
  9. That makes a lot of sense I think. Historically, allowing addons to run as unchecked code in the FSX process has been a source of stability problems - and when there's a crash, it can be hard to say what caused it. Another reason could be future proofing. The code for FSX addons is tied to a particular processor architecture - Intel x86. WebAssembly runs on other processor architectures too, so it would allow an MSFS addon to run on a new architecture without having to recompile it.
  10. 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.
  11. >Winds are given in magnetic directionActually, winds aloft are given relative to true north -- the wind in the ATIS, OTOH, is magnetic.Martin
  12. 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
  13. 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
  14. >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
  15. >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?
  16. 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
  17. 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?
  18. 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
  19. 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
  20. 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"...
  21. 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
  22. 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
  23. 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
  24. Richard,this isn't about building a conventionally-powered aircraft that just happens to have flapping wings... this is about building an aircraft where, to quote the "How It Works" section on the website, "All of the thrust and nearly all of the lift is created by the mechanical flapping of the ornithopter's wings."Here's the link:http://www.ornithopter.ca/how_it_works_e.htmlCheers,Martin
  • Create New...