danklaue

Really? I get less than 20 drop with the encrypted version. I guess it might also depend on how much else is going on in the sim.

Yes.

That's interesting to see! Just to provide a bit more insight into this, of course, you've already pointed out that the BAe146 is throwing a lot more at the entire system than the default Cessna. Here are some data points that illustrate this: While the C172 has a total pixel count for albedo, night, and normal/PBR textures of around 250 million pixels, compared to the BAe's 800 million pixels. While the C172 has less than 100 click spots, the BAe146 has almost 500 click spots. While the C172 has a total mesh size of around 18 MB, the BAe146 has meshes totalling about 173 MB. While the C172 has 6 Lua scripts, averaging about 40-50 lines each, the BAe146 has almost 80 logic modules, totalling roughly 80,000 lines of code. While the C172 has a sound bank that's around 7 MB in size, with around 28 discrete sound events, the BAe146 has 170 MB worth of sounds, with about 160 discrete sound events. Phew! This was an interesting exercise! I mean, I was also curious to look into, for instance, how many animations, keyframes, 3D lights, etc. were used in each plane, but some of these would be very difficult to tally up, and I've got updates to work on. 🙂 The file size may tell part of the story, but really, the amount of stuff we're throwing at our computers these days, expecting them to just crunch through those at even just 40 FPS! (I get 80 FPS inside, and around 120 outside with the BAe146, both on my iMac and my PC), I'd say we are getting a lot out of our machines these days. This whole project had as one of its main focuses, optimizing stuff, and these optimizations we try to pass along as options that are configurable by end-users, so that they can have some control over which aspects of the plane can be neglected in favour of some performance gains... for instance, almost every logic module, registered in the "Manifest.json" file (which is configurable in a text editor), has a "Skip_Frames" variable, where you can determine which module should be running at lower frame rates, so that unimportant or FPS-heavy modules can be set to use less resources. Editing a single module's "Skip_Frames" value may not make a huge difference, but it can add up, if you can do this for over 40 modules. Or, for instance, unloading parts from memory that are not in view, dynamically. When you are sitting in the pilot's seat, looking forward, the wings, engines, fans, stabilizer, etc. aren't drawn (or are replaced with lightweight meshes that only serve to cast shadows on the ground), but as soon as you turn your head or move around a bit, these parts are commanded to load up. It's almost Quantum mechanical! It's these initiatives, along with many other per-module optimization initiatives that contribute to this plane's FPS performance.

There's over a dozen videos uploaded to YouTube within the last few days, many of them several hours long. Just go to YouTube, punch in "Just Flight 146 X-Plane", and you'll find lots of material on this... along with those YouTubers' impressions, tips, assessment, likes/dislikes, etc. of the plane.

Yeah, us dev's aren't always the best at marketing, are we? We often partner with people who are good at that... and we tend to pay a huge premium for their services as well. But that's not always the best solution either... to just leave the marketing message in someone else's hands... in the past, we've been attacked by others (mostly competitors), who picked apart the marketing messaging of our product, blaming US for the marketing jargon, and using it to smear our reputation and attack our honesty or character. (Another dynamic that end-users maybe don't really have much of an insight into, and which adds to the need for grit in this industry). Yup. This tension is real. It can cause partners to part ways. As a company, striving to aim for solid foundations, tools, service, reliability, treating those you work with fairly, putting products out there that you can feel good about, walking alongside customers as the sim world changes, etc. is definitely NOT the best bang-for-buck formula... but hopefully, having long-time developers who continually try to prove that there are ways to resist succumbing to the lure of the quick buck contributes to building a happy, healthy, supportive, and understanding sim community. And I think that's valuable. I see great value in our hobby (well, it IS a livelihood for myself and those I work with... but it's a great place to make a living). In the forums, on the live streams, in chats, on Discord, you see people putting aside divisive political or world view opinions, and come together in an environment where they can learn about and discuss marvels of technology that most of us don't have ready access to, but have dreamt of experiencing since our childhood. Sure, we still get some toxicity and divisiveness, but overall, the sim, the VR world, the planes we get to learn about, what a great way to spend our time! And I AM grateful for all the people who actually purchase our products, making it possible for us to spend time we'd otherwise spend labouring away in some other industry, to help us contribute to building this environment.

I can sympathize with the sentiment here. It's frustrating. And from an end-user's perspective, this may really just seem like greed and an unwillingness to truly serve our clientele. But maybe there's another side of developers that end-users don't often get a glimpse into: the risk in some of the investments we make, and the tremendous losses we sometimes go through, if a product we've been working on for years doesn't end up working out. Tens of thousands of dollars, and months, sometimes years, have been sunk into projects that didn't make it to market. I've had several situations where I had an aircraft 70-90% done, only to see a competitor swoop in and publish their own version of exactly that plane. (With one project, this even happened TWICE! I thought I could still release a plane that was pretty far along, after someone else published that exact plane, weeks before I thought I'd publish mine... only to have a FURTHER competitor publish their version of that plane a short time later.) And especially stepping from smaller GA aircraft to the bigger planes, it's not just more complexity, longer development times, bigger up-front investments, and more stress that we also have to deal with, but also a psychological preparedness to absorb an onslaught of criticism, dissatisfaction, trolling, etc, as these larger projects don't just attract MORE people, they also attract a different crowd. So you may well think that that's all more than compensated for by the increased price of the product, that us dev's will get our investments back, no problem... but ESPECIALLY in this economic climate right now, a big plane, towards the end of a sim run, with MSFS2020 having just recently made this market more volatile, it is hard to be able to gauge whether you'll even survive as a company, and be able to retain your team members, if you make the wrong choice here. Smaller planes represent a more manageable up-front investment, and you can make a lower percentage of your success depend on each product. So I do appreciate that some people in this thread seem to understand that the choice to publish an aircraft that IRL originally didn't even have an FMS, with X-plane's default FMS integrated, and with a decision having been made to seek to satisfy the apparent desire expressed by our potential clients to equip the plane with a custom FMS, is (to put it mildly), somewhat mis-characterized by what Chock expressed above. Like every business, we tend to spend a lot of time considering carefully what sorts of directions we would like to go in our entrepreneurship; and ROI isn't the only criteria either. If our deliberations keep coming back to "Big plane customers are a tough crowd", or "The up-front investment is huge, and the return is risky", or "We could just stick to what we know, because we know it works"... then you'll see us make decisions accordingly. We generally enjoy what we do, but some people on the forums do tend to demand more grit from us, if we consider the notion of trying to cater to such an audience. We took a risk with this plane. Time will tell if it was a good bet or not... and by what dev's choose to consider worthwhile, it may help reflect on how forums and actual customers (and their attitudes) can shape the type of market you'll end up getting.

The experimental flight model is something we are actively involved in using, but it's not ready for prime-time. The whole idea is, that we as developers can work behind the scenes, making Laminar aware of stuff that "breaks" our planes when using the experimental flight model. The Just Flight fleet of aircraft just got released today, with updates to the 11.40 flight model... but NOT the experimental flight model. There are some things that might not work 100% in 11.40, which Laminar's new flight model in the next release SHOULD address... that gives us a chance to put our planes through their paces, before the new flight model hits the updater, and shortly thereafter, we can push an update (via SkunkCrafts auto updater) for all the flight models to be adapted to the latest release. The recommendation is always, to leave the experimental flight model turned off for most payware (unless otherwise specified).

Actually, I see that someone above already recommended my YouTube tutorials. It just so happens I'm in the process of revamping those tutorials, and I'm using the latest Blender and Xplane2Blender tools to do so. As time permits, I'm hoping to keep pace with the Xplane2Blender script development (which Laminar endorses and actively develops on GitHub), but since it's still in Alpha, I'll probably give it a break with the tutorials for a bit, until it's more stable and cleaned up. Here's a link to the playlist of currently available tutorials: https://www.youtube.com/watch?v=xy_yH-j2SKM&list=PLXQZyRq30oEt1sbT_v-KAFRhrqrVNfWlT They are fairly compact... within about half an hour, they pretty much showcase the basics of how to get a basic airplane with exterior artwork flying in X-Plane. But more tutorials to come.

We've tried that... it's quite cumbersome. The stuff that comes to us from 3DS has a format that has to be revisited a lot anyway... for instance, the keyframes in FSX/P3D can be 200-300 keyframes long, and at some point, we've grown accustomed to working with bones in a lot of circumstances. At this point, it's a toss-up whether it'd be more worth trying to work with the way it comes from 3DS (and all the problems associated with it) vs. just re-authoring animations based on existing templates and planes. I wish I had more time in general. The opportunities are many, and the growth is staggering. I'm excited, though... when I think back of the "dream" I had when I first published those tutorials, and see where we're at now, it's quite thrilling to see what's been happening.

Lately, sounds are largely re-authored from scratch as well (by Thranda). The 3D model goes through some adaptation, and has to be completely re-animated from scratch (not a minor task, especially not when considering complex cockpits with hundreds of switches, dials, buttons, handles, levers, covers, latches, and click spots, many of which are routed through custom plugin-based logic). Textures are re-done for X-Plane to take advantage of PBR. (Albedo textures can largely be re-used, although they go through touch-ups and often times a 4k-ification process). Flight model is from scratch, as X-plane's flight physics is DEScriptive, not PREScriptive (as in FSX/P3D.). You actually have to model the aircraft again in PlaneMaker, which is a geometric shape (that is hidden for the final release) that interacts with the atmosphere in X-Plane to produce physical effects that determine the flight dynamics. There is nothing (except for maybe initial engine HP values, fuel quantities, and weights) that can even be gleaned from the FSX/P3D files. Additionally, in the areas where X-Plane's flight dynamics model does not provide us with enough detail (such as, say, weird curves or kinks in the charts, as a function of altitude, where Laminar only gives us linear control between two target altitudes), we can "nudge" the base flight dynamics to cause the plane to fly more accurately, via plugin modules. That way, we have the best of both worlds... we can make use of X-Plane's "DEScriptive" Blade-element-theory-based flight physics, which makes it behave very realistically in most circumstances, with the added benefit of nudging it here or there, if necessary, to achieve the numbers that X-Plane's flight physics model is not yet high-res enough to be able to account for. Plugins are coded from scratch. Thranda has built an entire logic library in SASL's plugin infrastructure, which has contributed to accelerating the production of, and facilitated the maintenance of a large fleet of planes that all share common logic elements (and with that, a certain commonality in "feel" between aircraft). I like to think of it like a buffet. There's a menu, and every plane can select existing menu items from the buffet, and put it on its own personal plate. The plane goes out with the particular plateful of logic that corresponds to that plane, encapsulated within and encrypted for that particular plane. When a plane comes along that has more complex systems, it's like a guest that comes to the buffet line, and asks for a custom dish, which is then whipped up, or modified from an existing menu item. The more planes we have, the more our logic library grows, and the more approachable complex planes become, as we have the headroom to concentrate on more minutiae and depth. The real beauty is, that despite the fact that this logic is inaccessible to end-users, they can still configure most of the variables that make that plane's logic unique, via the "Manifest.json" file. So the planes are largely customizable by end-users, provided they know what to look for in the configuration file. So we're always striving to make the most of all of the advantages that come with partnering with companies that already have a recognizable brand and presence in FSX/P3D, and are able to add a layer of experience to those base products in X-Plane, always with the hope of convincing more and more people to give X-plane the chance we feel it deserves. And from the looks of it, we're only just beginning. Things are ramping up. We're tackling more complex planes. We're adding more features and more depth. We're updating planes to take advantage of the latest advances in X-plane (although keeping pace with Laminar is a bit tough). I do believe that customers get a MUCH better deal out of the X-Plane variant of these planes, not only because X-Plane is the better platform and the market leader in terms of simulation, but also because we are able to add so much nuance and depth to the experience in X-Plane. Besides, most of Carenado's offerings are still more affordable for X-Plane than their FSX counterparts.

The altimeter will support swapping between InHG and MB in the next update... but if you want that functionality now already, just download this zip file and drag the files it contains into the SAAB's "objects" folder, replacing the files that are in there. This'll allow you to use the calibration knob to switch between InHg and MB, and the "TEST" button on the left will reset the altimeter to standard atmospheric (29.92 InHG).

Many people love the fact that Carenado planes are textured with detailed, high-quality 4k textures. Whether or not performance drags down depends on so much more than just the size of the textures. It depends mainly on VRAM headroom left over in your video card after all scenery, cloud, and other graphic files are loaded. If you're skirting the limits of your video card's VRAM, yes, you'll get a performance hit... which you may be able to mitigate by setting your X-plane graphics settings to compress the textures (which also lowers the resolution of the individual texture files), so you can adjust the sim to suit your harware and your usage style. (For example, if you enjoy using high-resolution scenery meshes and Orthophoto tiles, you may need beefier hardware to additionally run a plane running 4k textures... but if you don't fly in heavy sceneries, you'll leave more headroom for airplane details.) Overall, X-Plane also benefits from several newer technologies that should give your system more mileage... but again, there's little you can do if you have old or underpowered hardware, and still want to fly highly detailed planes in highly detailed scenery. Something's gonna have to give.

It's integrated. If you have the RXP750, it'll show up in the 3D panel.

I think this information may be beneficial for the discussion and end-user understanding of where the sim is at and where it's headed. It relates to what was presented by Laminar at the 2018 FSExpo.

I'll copy-and-paste this from another forum where I posted my thoughts on... might be of interest in this discussion: