virtuali

Making airports for P3D not inherently "slower", but it less convenient, the tools are more obscure, there isn't an integrated editor you could use to see how the scenery looks like in the sim *while your are editing it*, you must use lots of different programs at the same time, some which are part of the SDK, some are not ( ADE, for example ) and the overall lack of integration between all the different programs makes the whole process more convoluted and less user-friendly. This is not so much of a problem for professional developers, they can get around those issues easily, and in many case have developed their own tools as well so, once you are setup and understood the whole process, the MODELING is not very different from MSFS, especially if we are referring to "proper" P3D scenery, that is made in full PBR, but there aren't that many P3D sceneries made like this. If a scenery gets ported from P3D to MSFS quickly, it doesn't automatically mean the resulting MSFS product is bad but, instead, the P3D version was good. PBR is PBR and, the same object in MSFS usually looks automatically better than it did in P3D, just because the lighting engine is so much better. The MSFS integrated editor lowers the barrier of entry for new developers, it's easier to start and obtaining results, and since the surrounding scenery is so much better than P3D, there's no need to add too much stuff around the airport borders and, the worldwide photoreal coverage makes doing smaller airports in the middle of nowhere way more interesting, since even that "nowhere", in fact looks good. That's why you see so much freeware, but also lots of commercial products from new developers you never heard before. This is all nice and good, and it seemed to result in lower prices, fueled by the Marketplace sales. And in fact, sales on the Marketplace ARE generally higher, but they are not as high as they were in 2020, and that's mainly because of the very well known issues of the Marketplace: - Sceneries are encrypted and their developers don't have any control *which* files will be encrypted. It's decided depending on the content type but, for example, if we could choose, I wouldn't encrypt the airport data (parking spots, taxiways, etc. ), because it would result in a crippled airport, one that couldn't be read by flight planning utilities, or other utilities that needs to read the airport data. This could be fixed if the SDK added the famous navdata/airport data API, which has been promised a long time ago, but hasn't arrived yet so, as of today, a scenery bought on the Marketplace IS functionally inferior to the same scenery bought from anywhere else. - Release and updates on the MS Marketplace are slower. More precisely, they are unpredictable. We had to wait several weeks (6 weeks in some cases) to have an update released on the MS Marketplace, while in one case it was released in just 2 days. This is bad especially immediately after release, when any product needs more patches, and they must be released quickly. This lead to some developers deciding to wait to release on the Marketplace, so they could submit a more mature version to Microsoft, one that wouldn't require much maintenance, but this has the side effect that, by the time it appears on the Marketplace, the pirated version might already be everywhere. - There's no way for developers to test on Xbox. We suggested many different ideas how this could be done without exposing anything of the Xbox security model, and leveraging some features the Xbox system *already has* for testing on RETAIL machines, but none of these suggestions were ever being replied to, other than a generic "we have no plans to allow local testing on Xbox". Of of the main point of being on the Marketplace, was accessing the Xbox user base, and this was supposed to help lowering prices due to higher sales, but it's not happening right now, because Xbox users have been burned too many times by crashes due to the limited amount of memory on the Xbox, which is mainly due to the inability to test on Xbox. Everything you buy on Xbox is untested, and it's based on the assurance we got from Asobo that "If something works on PC, it will work on Xbox", which is clearly not the case. The entire WASM subsystem was completely dysfunctional on Xbox, and it took an actual release ( PMDG DC6 ) that ended in user's hands, to realize the retail systems didn't work like the debug systems everybody at Microsoft uses to test. Since Xbox users are FAR less tolerant of bugs and crashes, as of today, the only use for Xbox compatibility is to allow PC users that ALSO have an Xbox to have an alternate way to use what they already bought and, since their main system is the PC, they won't care if the add-on crashes on Xbox. But it doesn't seem to achieve the real goal of reaching an entirely new mass of customers, which was the basic premise many developers bet on in 2020, resulting in initially lower prices. The main issue with Xbox is, the Xbox "OS" always runs in the background in its own memory space, so the games don't have *all* memory available for themselves to begin with, and to ensure the Xbox *itself* won't crash, the background OS constantly monitor the game which runs, and if it sees it's approaching memory exhaustion, it will axe it, causing the CTD. On PC, Windows tries its best to not be out of memory so, as long you have enough space on the Swap drive, even if you have just 8GB of RAM, it will start swapping, going slower and slower, but it will still run. But how do you test something as complex as MSFS with so many add-ons ? You can't expect even the MS test team to do that but, even assuming they could, is that even fixable ? Suppose you have add-on A, working perfectly fine with the basic game installed, but on the *borderline* of exhausting memory, because the sim *itself* is already taking quite a bit of it. Then you add add-on B, which would also worked perfectly fine by itself, but it might start to CTD after a while if used together with A. Now, add add-on C, and the sim might not even load the flight, because all 3 consumed the available memory immediately, so the sim got the axe from the underlying OS. It's extremely hard to make products that will use as little as memory as possible. For start, you must be deadly serious with LODs, and that adds quite a bit of time to development. Yes, it's way better than it ever used to be in FSX and P3D, because there are way better tools in MSFS to check and create LODs but, this means it's not SO easy then to port an existing P3D product, since in P3D LODs were seldom used, because of the primitive tools and ancient methods of tagging them, and on FSX nobody used them, because they use extra RAM and VRAM, which are precious commodity in FSX, and on P3D still not rock solid DX12 support, you want to use as little as possible. And, just add-on LODs wont's always be helpful in many cases. Asobo suggest using different texture sets for objects seen from a distance, but this only work to a point, because if you have an object close to you using the higher res textures and there's another version of it farther away, BOTH textures will have to be loaded and, since they are different and not MIPs of the original one, they will even take more memory, resulting in the optimization being counterproductive. All of this requires lots of time, and not many developers use it and, since the MSFS engine can take a lot of beating before the fps really goes down, so most scenery developers just ignore LODs, because "it always runs at 30 fps locked". On PC, with a good video card. On Xbox, which nobody can test on, it will likely crash. Prices are raising now because: - Xbox sales are not as strong as they initially were, because the lack of QA on the Xbox compared to the PC version, due to the impossibility to test the product by the one that knows it better, the developers of course. - The Marketplace limitations that affects PC users as well. Add-ons requiring .EXE modules are not accepted, even if they are sold as PC-only. You can't buy Fenix on the Marketplace, and you won't be able to buy the full GSX there as well (we'll have a reduced version, just for the Marketplace), and this doesn't help with reducing prices either. Also, there's no way for developers to reliably check if you "own" a product on the Marketplace so, there's no way to offer things like upgrade prices, and there's no way to choose what to encrypt, resulting in actual limitations on the products capabilities. - The realization that "just" making a scenery is not enough, you need to do be serious at optimization as well, and that can only mean increasing development costs. And the more time you take to add detail, the longer it takes to optimize it. Also, how many LARGE airports have been made *entirely* from scratch for MSFS ? I'm not even sure if they are even feasible, also considering another issue: a proper airport made in the proper way needs lots of time to be done, even more than one year. And by the time you are halfway done, Microsoft might decide to offer the same airport "for free" in a World update, without much of an advance warning. The result is, nobody is really taking on huge international hubs, which ARE the things (airport-wise) that sell the most. Everybody seems to offer mid-size airports, which by definition sell less than big hubs, but since they DO require significant work anyway, the prices can't be very low. Basically, there's a disconnection between what most users would like to pay and what is feasible and the projected sales. You would like to pay 5$ for a regional airport, but such airport won't interest anybody except those living in *that* region so, selling at 5$ would result everybody in *that* region buying it, but those users won't be enough to cover development cost, if sold at that price. And if it sold for 15$, users would say it's too much for a regional airport. On the other hand, something like KLAX or KJFK would surely interest lots of users worldwide but, the included versions are considered to be "good enough", and to make a proper version that would looks *dramatically* better than the default handcrafted one, it would require an incredible effort, and nobody has the required capitals to work 2 years on such an huge product, because right now they are all busy doing smaller airports, which have a shorter sales life span, so you need to start the next small airport, and the next one, and the next one.

Like Afghanistan is called the "Graveyard of empires", due to many large countries failing to impose a rule ( British Empire, Soviet Union, the US ), the A350 (and A380 as well) is the "Graveyard of developers", because its systems are the next level of complexity compared to the A32x, its AOM is scarily long at thousands of pages and not as easy to get, and it will be extremely easy to underestimate how much time it will really take, considering there isn't a "Prosim A350" Fenix could start from, it will likely have to be made from scratch, and you'll bankrupt in the meantime. It's THE Graveyard, after all. That's assuming making a product with the same fidelity as the Fenix A320. An average A350 is more feasible, but I'm afraid it won't have what makes the A350 exciting: the next-gen avionics and UI.

That doesn't obviously have anything to do with with GSX being supposedly "bugged" or "corrupting the .BGL", it's just the ground elevation in P3D V5 is different so, a scenery which was made for previous versions might have issues. And, because it's GSX (or more precisely, the KMEM script run by it) that handles lots of custom things in the scenery, including collisions with objects and/or ground, that's why you see a difference with or without GSX, that's what I meant when I said the issue is not as easy to fix as other scenery, because of the *unique* way KMEM was made.

Sorry, but there's no such thing, since GSX never tries to write to any .bgl files. And, nobody reported it before. If you still think it's a bug, open a proper thread on our forum, and we'll surely look into that.

Just like in the P3D version, when you select a gate to use in GSX, all default ground vehicles will be removed automatically from it. Note that, most of them would be GSX vehicles anyway, since we are also replacing many default ground vehicles models with GSX ones. Basically, many GSX objects can act in two ways: "Dumb mode", which is exactly like a default Ground Vehicle, but with a custom model and a custom operator appropriate for the airport. This will be used by AI planes, but you can use them as well, if you really want ( you probably won't, having the full GSX ) "Smart mode", the same vehicle acts under GSX control, so it does more and behaves better. For example, when the Catering vehicle is used in Dumb mode, it will perform the same kind of service like the default one, but with a custom model/logo, and it will wander through the airport as Ambient traffic. But the same vehicle, under GSX control, will work as it's supposed to, with the character pushing the carts, with a more precise positioning over the service doors, etc. Of course, there are vehicles that are unique to GSX, like Deicing Trucks, FollowMe cars, Cargo Loaders, Cargo staircases, etc., so these won't appear as default Ground services and won't be used by AI, or there are vehicles that are so much better in GSX, like the Baggage loader, that we assumed nobody would ever wanted to use the default one anymore, so we don't even bother to replace them as default models.

As I've repeated it again in February, we'll look in this, but at this time we are working 24/7 on releasing GSX for MSFS. But that's besides the point, the point is: - The product in question, KMEM, came out in 2016 for FSX and P3D V3, which were the ONLY two main simulators available on that date, P3D V4 came out the following year. Nowhere we ever said it would always updated "forever", for each new sim that would eventually came out after that. - KMEM is still fully compatible with P3D 4, but it's still not a native product and it's not advertised as such. We honestly put only native products in the P3D 4/5 section of our site, with "native" meaning compiled with the P3D 4/5 SDK and made in full PBR, so they could never work in FSX. That's what a proper P3D product is, and we DO NOT misrepresent ours, except the ones that truly are. KMEM is in the FSX section of our site. - When P3D V5 came out, some sceneries required fixes, mostly due to the updated default scenery. We updated some sceneries which were reasonably quick to do, even older than KMEM, like KFLL, or PHNL. - The way KMEM is made, the possible fix is a quite a bit more complex. But again, we never sold KMEM with the promise it would be "updated for life", and just can't demand a fix in the shortest amount of time. The scenery works perfectly fine for the simulator you bought it for ( FSX or P3D V3 ) and an extra version too, that is P3D V4. - KMEM is sold in TRIAL version so no, nobody can say users that bought it *after* P3D V5 came out were somehow "tricked" into buying a bugged product. And it's NOT just that, in ADDITION to that, for those that don't check the Trial, we added the following disclaimer, in the FSX download page, just if it wasn't clear enough you ARE buying an FSX Product: http://fsdreamteam.com/products_fsx.html Basically, users that bought it for FSX or P3D 3/4, simply cannot demand a fix for P3D V5, because the product works with the simulator they bought it for. And for new users, those that bought it after P3D V5 came out, we made every effort possible to: - Clearly label the product as being an FSX product first and foremost, with some adaptations for P3D, but it's in the FSX Products section for a reason, because we are not hiding the fact it's not a P3D native product, and surely not a P3D V5 product. - Making a STRONG suggestion to check the Trial to those wanting to use it in P3D V5.

It will come out this season!

Of course it will, with 50+ completely new different characters, of much higher quality, with all new animations. The jump from 22 ( maximum allowed in FSX ) to 80-95 bones per skeleton makes all human animations way more realistic and, to make them less robotic, we added a new feature to our custom animation player which plays slightly different walking loops for each passenger, for example looking straight, left, right, picking up a phone, etc. This, of course, resulted in requiring more time for us to do each passenger ( we could release GSX months ago if we just kept the old animations, but which good airplane would be using back then, other than the default A320/FBW ? ), but in the end it was worth it, since the overall crowd now looks so much better, and at those Walk-in gates, there will be a guy watching over the passengers with a notebook in hand. Passengers will be likely the last preview we'll show, but there will be others between now and release. The new baggage loading animation has also being remade from scratch, fully motion-captured live, with more variations in luggage (12 compared to 2 in P3D), a different character, and a completely brand new belt loader vehicle, were even the various warning *stickers* are correctly placed according to its real world user manual, with a visible moving belt. In our previous preview video, the one with the Pushback, we only had one character, now we have four, two males and two females, with different voices depending not only on region, but also on gender. Did I mentioned SimBrief integration ? We are working on it right now and, as of today we have: - Safegate VGDS will show an ETD countdown from your currently loaded SimBrief plan, so the ground crew will know they have to hurry! - The Passenger Number will be automatically set from SimBrief, so there will be no need to enter it manually, and no need to wait for airplane developers to integrate it with their own passenger count in the airplane. - The Refueling will present another option, in addition to the usual 20%, 50% 70%, 100% etc. percentages, we now have an option to use Block Fuel planned on SimBrief.

Sure they did, many airport developers supplied a custom GSX profile, which is a fairly small .INI file that can be placed in the scenery folder together with the various .BGL files. The sim will ignore it, it will only used by GSX. Sharing GSX profiles has proven to be very popular: Cartayna files is one of the most downloaded product on Simmarket, and iniBuilds started their career by making GSX .INI profiles ( that's where their name comes from ), and there are many groups on Facebook, sometimes with thousands of members, dedicated to making and sharing GSX profiles. A GSX profile is not strictly required, because GSX still reads the scenery directly, and it has a fairly complete internal database (which can be user-overridden as well) to establish some rules about which operator goes where, with "operator" meaning Ground Handling, Catering and Jetways. Also, the GSX Pushback is able to figure out the most common situations and is able to place you on a reasonable point on the taxiline automatically, by reading the airport data directly, not requiring any intervention. However, if you ( or somebody that likes to do that and will share his work ), want to go really deep into customization, and a GSX profile will allow you to specify, for each gate, things like: - Custom multiple Pushback routes (as many "slots" you need, for each parking), with multiple bezier-based waypoints that can create a very precise and smooth curve. - The starting position of every service vehicle, and their operator too, overriding the generic rules, by airport, terminal or gate. - Create Walk-In gates, with custom paths Passengers can walk during Boarding/Deboarding. The major improvement compared to the existing P3D version, is that waypoints can now be edited in the 3rd dimension, allowing Passenger to climb/descend over the airport structures before reaching/leaving the airplane. - Create "Airport Walkers", this is a new feature, to create "looped" paths that will populate an airport automatically, not just while Boarding/Deboarding GSX. Think "Aerosoft EBBR", but you could add them yourself to any airport that has visible terminal interiors. - Set the airplane Stop position independently from the parking spot center/radius, so the main Exit will always end up in a predictable situation, resulting in Jetways working more reliably. - Set a specific Parking System. By default, with no customization, there will be a Marshaller, but we have a large selection of VGDS systems, from the simplest "semaphore" ones, to the more complex like Agnis, Agnis-Papa, Apis++, and multiple versions of SafeDock. All models have been remade from scratch since P3D, and the more advanced types have smart features, like showing the Boarding/Refueling/Catering progress and...(drum roll, another brand new feature ) SIMBRIEF Integration, showing info about your upcoming flight with the ground crew ETD countdown clock, just like the real ones. All models come with a variety of supports, ground, wall mounted in L or J shapes, and even multiple colors, so they can be adapted to any airport. So yes, when there's a GSX profile available, your airport + GSX will work so much better. We'll of course offer full customization for all our MSFS airports by default, and as usual, GSX will be free to be used there so, those smart users that bought an FSDT airport, are in for a real threat, because a *massive* improvement is coming, and it's completely free to use, for them.

Yes, Saitek X-52 is basically already fully mapped by default. I have an X52 Pro, and I think I only changed a couple of buttons, but it was already ready to use.

You want to edit the video title: "hardly bugged" really means is not really bugged. "Bugged hard" might be better.

Or moving away a developer from XP, which is usually way more effective.

Why you are posting this in the P3D forum, when your post about supposedly low fps at KLAX was with FSX ? Now, I haven't got the time to reply to you, because you posted last Friday and I need some time to check this but, what's clear, and should be already clear from this post, is the problem is NOT the scenery supposedly "not optimized". How you could possibly say the *scenery* is not "optimized", when you said yourself that, in your case, disabling GSX improved the fps ? More on later but, let's see how KLAX REALLY runs in P3D V5: This is with GSX ( of course ) and with the default 737: Now with the PMDG 737: I don't have OrbX or any other scenery installed, but the extremely good fps with the PMDG proves the scenery and GSX are NOT the problem. Now, you are using FSX, and FSX is a completely different story, and I believe the problem here is (again) not the scenery, but rather the GSX Jetways, which are far way more detailed than the ones the scenery originally came with. They are EXTREMELY optimized, with multiple LOD levels, but I must say we optimized those for P3D, which has a *far* more efficient graphic engine than FSX, and I can see the fps drop as well on the same system WITH FSX. The only option I can think of, is to provide FSX users with an optional download with the standard jetways instead of the GSX ones, which were made mostly taking into account P3D, but I can't say when we'll have time to do this, since we are working full time on finishing GSX for MSFS, that's another reason why I haven't replied to you on our forum, but I DID took the time to test the scenery in FSX, and yes, the frame rate drop happens there. But it's NOT the scenery being supposedly "unoptimized", it's just that it was made more towards P3D, in which it clearly perform very well, as the above screenshot proves.

It's a way to use the time it takes for MSFS to load...

That's likely because it does all these computations in the external .EXE which, by default, and without doing anything special on the developer side, is assigned its own separate threads (and its own spare CPU cores) by the OS, so it's not affecting the MSFS Main Thread so much. It's likely the code still has room for improvement, with far more optimization options than if it ran inside MSFS. Also, you can even have some control over it, by playing with the OS Affinity settings, depending on your system and how many other apps you run in the background. Asobo has promised multi-threading for WASM a while ago, but right now is not there yet so, until it will eventually arrive, likely in the way of each WASM module begin assigned its own thread, external .EXE have the performance edge, at least when computations and system simulation is concerned. Drawing gauge graphics, that's completely different, it's too dependent on the developer ability to be smart drawing stuff, regardless of the method.

True, I've seen it yesterday, and I daresay it's even better then the original. Movie spoiler

The OP didn't asked which one to buy, since he said he already has the PMDG 737. He asked if he should get the Maddog as well, but was worried about performances. I'd said if the PMDG run "beautifully" on his system, I'm sure he won't have any issues with the Maddog as well, their both perform good, and any fps differences are really minor.

Maybe because it also requires to push down 20 deg to gain speed, so it's supposed to be flown inverted to not suffer from negative Gs.

On the Marketplace as a free download. I already landed on the carrier, at the 3rd try, made 500k points, some guy on 1st place scored 1.2M points.

It's out now!

Except Discord is basically a reissue of IRC. Now, the same confusing mess it's back with a new name and interface and renewed hype, and those that weren't there in the 90s, assume it's something "new", when it isn't. It's a CHAT system, not a forum.

I'm not sure why you are asking this. I was just making an *example*, to explain the long approval time in the Marketplace doesn't have anything to do with the fact the developer has already published several products ( as in our case, FSDT ), or it's the first one.

Nope. We are in the Marketplace basically since MSFS came out, in August 2020, released many products since then, but our latest scenery, LFNC, took about 6 weeks to be approved. That is a very small airport, which is extremely quick to check out, and currently has no bugs reported.

True but, he was referring mainly to the Flight modeling. Don't know if Fenix has a custom flight model that runs externally too, or it's just for system modeling, but regarding the flight model, the only simulator that is designed to have its flight model driven by a custom simulation, which can be either internal or external, is P3D, which has several features to deal with that, such as the External Sim feature ( now deprecated in favor of the SimObject API, but still available ), the ability to create a completely new SimObject class driven by fully custom code without using an external module, so it's very high performing ( the SimObject API ), and the special "Syncronous Simconnect" calls, that can be used to be sure your code is synchronized with the simulation, which of course means you can slow down the whole sim if you are not careful. None of this is available in MSFS, which doesn't make exactly easy to replace the Flight model. There has been some discussion on the MSFS developers forum, here: https://devsupport.flightsimulator.com/questions/3955/wasm-flight-model-replacing-game-flight-model.html the topic is clearly important to many 3rd party developers and, the last reply from Asobo was: The whole thread started because it was noted the Volocopter uses a WASM module using Simconnect for its custom flight model so, later replies from Eric (developer at Asobo), was that, when saying "It might not be future-proof", he was referring to external .EXE replacing flight model through Simconnect, now WASM modules. So, right now, the custom flight model situation, according to Asobo, is as follows: - There's no officially supported method to replace the flight model. But this might change at any time in the future. - Some developers did that through Simconnect, but it's considered as a workaround and, not future-proof if done through external .EXE - Asobo themselves used a custom flight model in the Volocopter, by means of a WASM module, also using Simconnect. So, it's not entirely clear why the distinction between an external EXE using Simconnect to replace the flight model vs a WASM module. It is likely because they know WASM, running inside the sim, might have less overhead and less synchronization issues compared to an external .EXE, but that's just a guess.

Should have placed by <Joke> tags, if that wasn't already obvious ? P.S. Sorry, I forgot to close the tag, I must be bad coder after all... </Joke>