virtuali

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>

Almost all Javascript engines today use Just-in-Time compilation, meaning the source code is first parsed, then compiled, and then optimized, the JS engine in Chrome has two compilers, one to compile and another to optimize the code created by the first one. Not sure about the MSFS implementation, but I know they used Webkit, which is the engine mainly developed by Apple, and used by Safari, it's know to be very fast as well. Note that, the binary code from Javascript is still not real x86/x64 ML, but it's a bytecode that is somewhat "similar", and it's executed by the Javascript VM. In this aspect, Javascript is closer to C#, but with the difference that C# compilation is completely Ahead of Time (AOT), while Javascript is JIT. But the end result, is fairly close: a pseudo-asm, which is not real CPU code, but it's optimized to be executed quite fast on a VM. The main issue with Javascript, or any other JIT language, is that at any time the compiler might decide to re-optimized stuff and compile again, usually because it realized some assumptions were wrong. Another issue is the in-famous garbage collection. Sure, this will completely shield you, the developer, from having to deal with pointers and memory allocation ( more precisely, memory de-allocation, since it's easy to allocate memory, and it's equally easy to forget to free it ), but that also means garbage collection might happen at any time, and you have no control over it. That's common for Java/JS/C# or any other similar language that has a VM that takes care of memory handling for you. WASM, instead, at least how it has been used by Asobo, it's not only completely AOT ( hence the annoying long compilation step of all WASM airplanes the first time they run, or if there's a sim update ), but it's also fully Intel. If I decompile a WASM .DLL that has been compiled by the sim at startup using my favorite decompiler ( IDA Freeware ), it's recognized as a real x64 .DLL, it shows actual Intel ASM op-codes and it has imported all Simconnect functions like a real C++ module. Asobo clarified this when some users wanted to know more about technical details, for example if WASM ended up being a "real" machine code, rather than just another bytecode-based VM, like Java/JS/C#, so they explained their implementation is based on Innative: https://github.com/innative-sdk/innative This creates real .DLL that can be linked with standard C/C++ object modules, and possibly interact with the OS. Now, this last feature is not possible with MSFS WASM: they chose to create a sandboxed plugin instead, so no OS interaction and no linking with 3rd party libraries, but as far as execution speed, it's functionally equivalent to real ML, because it *is* real ML. Now, it's possible MSFS WASM might not be 100% as fast as a standard .EXE, but I'd say the difference is mostly marginal, and related to different optimization capabilities of the different compilers used, nothing you check without running lots of diverse benchmarks. Also, there's no garbage collection in WASM, so it's the same as unmanaged C++ in this case.

That's good question, for which I don't have a precise answer. Usually, when something is compiled by-user, locally, security has something to do with it. Not from a DRM point of view ( as far as I can see, WASM binaries are not encrypted ), but with security at large. The first thing that comes to my mind is, how do you spread a virus, if the WASM system is unable to just run pre-compiled binaries, but must always re-compile from the intermediate code ? Clearly, when you are controlling the compiler ( Flight simulator includes the compiler so, in a way, it IS the compiler ), you can fairly easily prevent to compile dangerous code, since the only thing you allow to compile, are the API you provided with that specific WASM implementation. But please don't quote me on that, it's just an assumption I'm making.

That's the key sentence. Integration with external websites is surely possible using, for example, Javascript. And it's surely not possible using a "pure WASM" approach, like PMDG so, in a way, they are both correct. The main reasons why a developer would decide to use a "pure WASM" approach ( meaning no external .EXEs required ) are: - Being accepted on the Marketplace. MS doesn't approve anything that requires an .EXE module. - Eventual Xbox compatibility. While there are still issues with WASM on Xbox, which were discovered by PMDG with the DC-6, and seem to be mainly caused by the inability to test on Xbox in real world conditions, I'm sure this will eventually fixed someday, which means Xbox users will likely be able to buy the 737 too. - Raw speed. Sure, Javascript has improved a lot in recent years, but C++ still has the edge, and the reason why it takes so much time to start a WASM airplane, is because when the code it's being run for the first time ( or the sim is updated ), all WASM code is compiled to native, so it's basically equivalent to a real x86/x64 .EXE/DLL, and that's still way faster than Javascript will ever be. - Ease of portability for existing code. If you have tons of existing C++ code ( and "existing" doesn't automatically mean "bad" ), porting it to WASM is reasonably easy (provided you haven't used exceptions too much...), but converting to Javascript can be extremely complex, not so different than a complete rewrite. And you'll end up with a code that will never run as fast as the previous one, and perhaps you discover that only *after* doing all that work. What if it's too slow ? Work for months to port to JS, and then go back to C++ ? That would be a commercial suicide that could cause any company to go bankrupt. Right now, the pure WASM approach seem to work, considering how good performance are with the 737. Perhaps they might consider doing *something* with Javascript, to achieve some integration with sites like Navigraph or Simbrief, but the issue is, the way the SDK is made, it doesn't exactly makes it "easy" to integrate those different sub-systems, which sometimes just don't talk with each other, or even if they do, they do it in a clunky/inefficient way. For example, lots of interesting things can be done from Javascript + Coherent but...Coherent can't be called from Simconnect, and Simconnect is basically the only way a WASM module can communicate with the sim or the outside world in general, since it's heavily sandboxed. There are workarounds, but they are inefficient/slow/bad to maintain. In addition to that, the most important NEW part of the whole sim, that is the HTML/JS subsystem, is still completely undocumented. While this might not be so much of a problem for a freeware product, it's really a no-go for any serious commercial developer. How you are supposed to *support* users and reacts to bugs and/or sim updates, if you based your product entirely on undocumented features ? Being undocumented, Asobo/MS are not bound by any backward compatibility, even between updates. They could redesign major parts of the HTML/JS framework, and if that would break dozen of products...that's too bad, but developers who decided to risk using the wholly undocumented sub-systems can't complain much, they should just try to fix their stuff. Again, this might not be an issue for freeware, but until that important part of the documentation shows up, I'd be wary of risking an high profile payware JUST to offer a couple of auxiliary features more, which are not really the core of the product. So, I must say PMDG explanation about the lack of these features makes sense, and they are telling the truth, it's just a consequence of the design choices of the product, which are sensible, all considering ( here I'm biased, because I'm a C++ addict, and I consider JS to be as a script-kiddies evil, it's so easy to use that it's not even fun anymore.. ). If another developer made a plane using a different approach, possibly using external software ( I believe the Fenix A320 will require an external .EXE ) or Javascript, that makes sense as well, and doesn't make the PMDG explanation any less valid, every design choice has different benefits for both developers and users as well. Pure WASM is fast, it's a clean approach and it will get you to the Xbox/MS Marketplace, and it's fairly transparent for users, with the only exception of that initial slow startup. External .EXE give you both the absolute best speed (pure C++ code is a bit faster than WASM C++) and absolute best flexibility (you can do anything a Windows PC can do), and they are kind of safe too (if they crash, they won't crash the sim), but they might be annoying for users and/or being clunkier to use, and are susceptible to be attacked by bugged antivirus, sometimes even Notepad.exe gets blocked, go figure... HTML/JS is the new wave, it's probably best if you are starting a new airplane from scratch, and you can find developers more easily, but you might discover some things might be slow and would require a WASM module anyway ( like the advanced autopilot in the FBW ). And, JS it's completely undocumented, not integrated with Simconnect, and a sim update can possibly break the whole product at any time. Full disclosure: GSX will use ALL OF THEM. We have a tiny, lightweight, WASM module to do just a couple of calls we need, mostly to allow other products to integrate with us ( publishing L: variables to the outside world ), an external .EXE that runs the whole GSX code, so it can do lots of things ( including Simbrief integration, yes...) without being limited by anything in the SDK, and we are ALSO using HTML/JS for the UI and menus. But I sometimes envy airplane developers that can achieve almost everything they need to do, and they even have multiple choices available.

Well, that checks out. Some SDK QA is needed.

Maybe there's some kind of hidden meaning, like: - If you are a real coder, you will probably be able to get figure it out how to get rid of that nag screen by yourself. Since real coders never run the sim in full screen, because they always have multiple applications/debuggers/compilers/editors opened, we played this trick on you, by showing a dialog that can't be suppressed until you go back to windowed mode, which would be the only mode you'll ever use anyway. In addition to that, since we purposely added a link that doesn't work ( not sure about the QR, but the hyperlink doesn't open anything, perhaps I also failed the test... ), since the job position is in QA SDK, your first task should be reporting the bug to us. - If you are not a real coder, just don't bother with Dev Mode, turn if off, and just play the game in full screen, like you are supposed to.

This has become like an internet meme now. EACH time, on every forum, of every game, when fps are discussed, it doesn't take long before somebody will post the "movies are shot at 24 fps" mantra. You just can't compare movies with real-time PC graphic, they are many key differences which, in the end, all means those 24 fps will not fell the same in a movie or a PC game, let's see: - The famous "cinematic look" is achieved with a very specific combination of frame rate AND shutter speed. The most common setting, by far, is what is called a 180 degree shutter angle, that is the shutter opened for half time, that is 1/48 of a second. Film industry found this resulted in a good compromise between a too blurred image ( shutter completely opened for the whole 1/24th of a second ), or a *stuttery* image, with smaller angles, meaning a faster shutter speed, like a 1/100th or a 1/250th of a second. Sometimes the DP wanted to achieve this effect, but that's not very common. This without even considering that, if you are seeing a movie on analog film on a real projector, the projection system will insert black frames at 1/48s intervals to balance the black frame caused every 1/24s caused by the film advancing system, so you'd get nicely spaced black frame every 1/48s, which are less noticeable AND they match the shutter speed the file was shot with, so you are not "losing" any information. If you seeing the movie on DVD, the player will convert it to 60fps inserting frames, unless you use a Blu-ray player, configured to output 24p with a TV that supports it. So, shutter speed is the first difference. Shutter speed in PC-generate graphic is "infinitely" short, that is each image is "discrete", so it will never feel as smooth as a move shot at 24 with a shutter speed of 1/48, the most common case by far. Some interesting explanation here on Red's site: https://www.red.com/red-101/shutter-angle-tutorial#:~:text=By far the most common,a second at 24 fps. "But my game has ***motion blur***" effect". Well, yes, motion blur might help to simulate a movie, but it's an effect that cannot compare to reality. In a movie, each frame includes a all the information of that 1/48 slice of reality, with each object containing a variable amount of blur ( or even none, if it was steady ) which was the result of the object own motion combined with the eventual camera motion. Motion blur in games is the result of an estimate mostly based on the previous frames and it's mostly related to the camera motion. It looks fake, because it is. - Absolute fps steadiness. Frames in a movie shot at 24 fps are all spaced apart by exactly 41.6 ms. Nothing can change that, no background processes, no threads, no OS workload, no bus arbitration, nothing can change the absolute steadiness of each and every frame spaced 41.6 ms from each other. Even a game capped a 24 or 30 fps WILL have some micro-stutters sometimes, and this assuming the best possible conditions of a monitor that sync down to that frequency. G-Sync/Freesync/VRS etc are all good, because you can at least fix the screen tearing resulted by trying to draw an image when the previous one was still drawing, but something that runs at 32 fps for a while, then goes to 38, then goes back to 29, and it's doing continuously, might be tearing-free, but it won't feel as smooth at something that is completely locked at 24 fps for hours, with that natural motion blur. - Passive vs interactive. When you see a movie, you are NOT interacting with anything. In a PC game, you are controlling something and interact with something else, and the game must first process your input. There's USB lag ( or worse with wireless ), there's PC monitor lag and this is added to the time it took for the game (after it read your input) to decide what to do in response to what you asked to do. If the game runs at 24 fps, it's more likely to be in unfortunate situations like you pressing a button just before a new frame rate was created, you might have to wait at least another 41.6 ms to see the effect of what you did. If the game ran at 60 fps, the wait time would have been only 16.67ms, meaning you will "feel" closer to the action. So, even if you think you are not "seeing" much difference between 30 and 60 fps, the game will FEEL better. This won't be an issue when watching a movie, but it is when interacting with something. But if you don't believe the technical data, why you don't just trust your own eyes ? Now, not *everybody* is sensitive to frame rate in the same way. There's a somewhat "general" agreement in the scientific community that, for most people, having more than 60 fps is probably overkill, but every person is different. I'm a bit fixated with fps, to the point I just don't care so much lowering quality, to get more fps. Those of you which are into Home Cinema might remember the issue with the in-famous "Rainbow Effect" with DLP Projectors. People were making a big fuss about it, so the first time I went to see one in action, I was shocked by two things: how much better the quality/contrast was against the usual LCD projectors, and how IMPOSSIBLE for me was to watch a movie on a DLP, because I was just too distracted by the rainbow effect. I couldn't simply watch the movie anymore, because each time I blinked, I saw that streak of colors. Regardless how clearly better DLP was in general, I just couldn't think getting one, so I ended up buying a regular LCD proj, which didn't had the same beautiful colors and deep blacks, but at least I could watch the movie, instead of the rainbow. But that's not the main thing. My father is also very much into Home Cinema, and when we went to shops/exhibits together, to check all the new stuff that came out, he was NEVER, ever, able to see the rainbow! Regardless how hard he tried, he never saw the DLP Rainbow effect, and lucky him, so he could buy a nice DLP. I think it's *possible* those people that can't see the DLP rainbow effect might be the same ones that won't see much difference between 24, 30 or 60 fps. For me, 30 vs 60 fps is like NIGHT AND DAY, but I can understand how not everybody might feel the same. Also, we can see in a game like Flight Simulator, where the action is somewhat more relaxed than, let's say, a competitive driving game, having a good locked 30 fps is more than enough, which is surely true, but that's quite difference than saying there's "no difference", and surely not "because movies are shot at 24 fps"...

No, they won't affect fps, but their models and textures will use VRAM from your video card. How much, depends how large their models are, how many *different* textures they use, how many frame of animations they have and, most importantly, how well they are optimized with multiple LODs. In general, the MSFS graphic engine can take A LOT of beating, but the one and most important thing that helps with performances, are objects using multiple LOD levels as extensively as possible.

That's basically what I've being doing for the past months, I'm only using some of my self-allowed "Air-time" ( or Out-of-cell time ), because it's Saturday..

Now, before urban legends will be spread, it's best to clarify Aerosoft already used the same people in a previous scenery and, of the about 50-60 passengers models that will be included in total with GSX, exactly 18 of them will be the SAME as the "Aerosoft" models. That's because they are not obviously Aerosoft models, they can be purchased by anyone on Turbosquid, with a fairly low price all considering: https://www.turbosquid.com/3d-models/3d-rigged-photorealistic-rendering-model-1413846 This is one pack of 6, there are 3 packs available from the same developer, for a total of 18 different characters, and those are exactly the ones Aerosoft used in their sceneries, so I'll anticipate by saying you will see these 18 guys in GSX as well, because of course we bought them too, almost a year ago... And that's why we haven't shown a video with the new GSX passengers *yet*, because we haven't finished adding the remaining ones, so in the end those 18 guys will blend with the other 50 or so we are still working on, but if we released a video today, I can only imagine the "GSX took the models from EBBR..." uninformed comments, same as when we had the in-famous "OMSI granny", which was in fact licensed by OMSI ( and by us as well ) from a company in Italy named AXYZ, makers of a very good people animation software named "Anima". In fact, I even toyed with the idea of purposely including again the OMSI granny, this time proudly walking outside the airplane with a boxed copy of "OMSI Bus Simulator" in her hands, as an inside joke. But in general, we improved the animations a lot, compared to P3D. That's because passengers in P3D were made using FSX compatibility, so they had a very limited skeleton with only 22 bones (the most FSX could do), which is not enough to do a smooth human animation, but for MSFS we are doing everything native, with 60-70 bones per character. Also, we improved our walking animation software to add some variations, meaning the walking cycles have multiple variations randomly selected, so every guy moves differently, with a different stride, and it alternates between different walking cycles, sometimes they look straight, sometimes they look around, their hands/fingers move (not possible before with just 22 bones), sometimes they answer the phone, and each time it's different, because the animation is procedural, because we need to adapt them to every possible airport. We also improved the overall forming of the crowd, so now the passenger will walk in different lanes depending on their speed, from right to left, slower to faster, which will reduce the chance of collisions between themselves. Overall, all these changes results in the whole crowd looking way more realistic, more like a real crowd.

Just a quick reminder: GSX for MSFS will expand the passenger waypoint editing feature we introduced recently with P3D for Walk-in gates, to extend it in the 3rd dimension, so you'll be able to create any kind of passenger walking "lanes" on any airport, even climbing up/down different floors, and of course it will be saved in the usual GSX profile which can be shared or supplied by airport developers as well. This way, airport developers can focus on doing the detailed interiors only, instead of wasting time with passenger animations ( or, at least, they could just do some animations specific to the place, like people seated on the airport chairs ), because GSX will provide with the "walkers", which have the advantage of being more varied, since they are procedurally generated, so each time you go there, you won't see exactly the same people Airport developers could just provide with a GSX profile with all those waypoints programmed, as they already do with other GSX customizations, and they can save all the time required to create walking people inside terminals. If they need to make changes to the airport, maybe a new terminal or an reworked one, changing just the GSX passenger waypoints will be way easier than having to do them again in 3ds or Blender to match the upgraded airport layout. We plan to supply at least 50 different human models, each one optimized with many LOD levels so they will be fairly fps-friendly, even when there are many of them on screen, and they could also easily turned on/off without restarting the sim, and since they are created by Simconnect, they are not part of the scenery, and it's ensure they are completely destroyed and their resources are free when they are removed, something you can't be sure of if you include the objects inside the airport .BGL files, which is the normal method everybody could use until now to make humans inside airports.