virtuali

Not sure what you mean with "always want to install my two sceneries" but, if you have installation issue, you are supposed to contact support to solve them. Maybe you wanted to say the *updater* is trying to *update* a scenery you wanted to remove ? If that's the case, it's likely you haven't removed it correctly but, again, it's a question for support, which will tell you exactly which files you need to remove to stop the updater to update a scenery you don't use anymore. Please don't reply here, the Bargain's Hunter section is not the place to make support questions.

Almost right, but not quite. They will override the codes found in the scenery AFCAD, but their only use will be as "Tie Breakers" to give those operators a scoring boost, to the one they already had assigned, based on GSX normal rules. Which means, if after GSX founds that, according to its own operator assignment rules, there are two or more operators TIED with the maximum score (so they would normally appear in the GSX operator selection menu), the Arline Codes of the Parking, will boost the score of the ones that would have otherwise tied. And if, after adding the scoring boost, there are still two or more operators possible, there will be an operator choice menu, which would otherwise disappear if there was only one choice ( no point having a menu with just one choice ). All of this, affects only the USER airplane. Nothing you do in GSX will have any effect on AI.

Of course it's applied, but it won't show up with some "discount" indication, it will just be 21.75 instead of 29.00. Obviously, sales taxes or VAT will be added when due, but that would have been the same even before the sale ( it would have been 29.00 + VAT/tax ). To be extra sure, I checked today's sales, one by one, and there isn't a single user that has been charged more than 21.75 USD + Tax as soon after the sale started, about 10:00 AM CET.

The works exactly as in P3D. That's the part where the running code is really exactly the same as FSX/P3D Not exactly. They turn in the right direction but, they are turning with some delay, so it might give you the impression they are turning in the opposite direction, but only for a short time, they eventually catch up, because of some lag. While in FSX/P3D the steering was completely controlled by GSX, since GSX vehicles were only used for GSX and the user airplane, while GSX ground vehicles are used both by GSX proper and as replacement for default Ground vehicles, which means they are controlled by GSX (when GSX proper is used), for movement, but with the steering using an MSFS-native method, which is not exactly working well with the kind of waypoints calculated by GSX, while they are completely controlled by the sim when they work with AI, so in that case their steering wheels usually looks better, since both the waypoint handling and the steering are made by the sim itself, so the two strategies are more coherent with each other. We are obviously working to improve this, which will mean trying to match the MSFS steering with our own waypoint calculation. Difficult to explain why we couldn't use the GSX-own steering in MSFS as well, it's related mostly to the fact all airports are sloped, but also so we don't need to have two completely different set of vehicles, identical in every way other than the steering method, which would duplicate the number of objects installed. This doesn't have anything to do with GSX. In general, everything you see that is NOT your own airplane, is completely ignored by GSX pushback. If they are AI, you can be sure it's the default pushback system that is running, but with multiplayer planes, there might be additional complications caused by the *remote* user using GSX COMBINED with the very well known issue of multiplayer planes lagging or stuttering or skipping or jumping up/down or just floating in the air, which obviously happens regardless if GSX is installed and always happened before GSX came out.

Every menu "clunkiness" is caused entirely by the hoops we had to go through to use a proper Toolbar menu instead of a (really) clunky external superimposed overlay. Being a proper menu has lots of advantages and it's better in the long run, but it's affected by the fact all Toolbar menu code is automatically killed by the sim to save performances, so no Javascript code (other than airplane gauges ) runs when the menu is closed. Because of this, the menu can't be really closed, it's only hidden, so we can pop-up the menu at any time, since GSX often requires a new menu opening automatically after some time. And, it requires user understanding that, while the menu is closed, you can't call it from the Hotkey, but you need to open it from the Toolbar and in that state you'll miss all text messages and menus won't pop-up, while when it's only hidden ( white toolbar icon ), it works as expected. I see lots of tutorials online where the presenter keep using the mouse to open/close the menu every time, which makes it extremely "clunky", because when it passes from the closed to the open state, it's obviously slower since it has to reinitialize the whole menu, so it looks "unresponsive", but only because it's not used as it's supposed to be used: opening the menu with the mouse when you call it the first time, never close it with the mouse, except when you are done with ground services. The manual explains this but, since this was a big operating change from the initial release, and it's on the last pages, I think not many users are fully aware of it, otherwise I wouldn't see so many videos online of always using the mouse, which causes lots of unnecessary double clicks, missing notifications and worse responsiveness. This is actually a very good idea, not sure why nobody has expressed this way, but we'll surely look into it. However, even without it, there are many ways you can accelerate services that takes longer and are: - The Passenger Density slider has a direct effect on the Boarding/Deboarding time - The "Multiple Trips" for Passenger Bus and Fuel Trucks also can be used to shorten Boarding/Refueling times, because if it's Disabled, instead of use the real Fuel/Pax trucks capacity (adding to their trip time to the overall waiting time for the service), it will only send a single Truck with an "infinite" capacity, no matter how many passengers you have, or how much fuel you asked. - The "Time Acceleration" for Refueling slider can be used to make refueling going up to 10x faster than realtime, without having to use a real Time Acceleration in the sim, which might have other side-effect. Well, let's use actual numbers to be the judge of that. Surely, everybody buys models from Turbosquid, some guys that work for us even SELL models on it. Looking at my invoice for that particular set of 18 people, dates almost a year before Aerosoft EBBR came out, it's just that GSX took longer to be released, and one of the (many) reasons it didn't come in 2021 was BECAUSE it look a very long time to add a lot more models, and animated them. At this time, we have 53 different characters, meaning 18 out of 53 are the same ones bought by Aerosoft or Flytampa: would you say those developer were "cheap" by using the same 18 GSX models, had we released GSX a few months earlier with JUST those 18 guys ? Animations might look "basic" or "repetitive", but only because you keep seeing them at each flight, and you might seem them (especially without jetways) in the OPEN and, most importantly, because you see them for a longer time. When using these characters inside terminals to create ambience, you don't notice their animations are even more basic and far more repetitive. GSX animations are less basic and way less repetitive then both previous GSX version because: - We moved away from FSX-backward compatible human skeletons with 22 bones, to higher counts allowed in MSFS, averaging about 70 per characters, so the animations are visibly more natural - Our updated animation player has built-in randomness: in the FSX/P3D version we only had ONE walking cycle (with 22 bones) for each passenger, now we can have many variations, randomly selected, with most passengers having at least 3 different walking cycles, usually looking straight, or right or left, but also picking up phones, etc. Yes, of course this can only be improved, but you must understand it takes time, because even adding a couple more variations for each passenger, it means we'll need to multiply ( as of today ) by 53 different people. So yes, this will improve, but it will take a bit of time, the important thing was to have the basics working, since there's no limit how many variations we can have for each walking cycle, and no limit how many different characters we can have, it's just a matter of time modeling/animating them. GSX for FSX/P3D was a 10 years long project, and it has always been updated ever since. I don't even know why I need to explain this, when there's some history backing it up. We explained this so many times: GSX actually FULLY respect Asobo LOD guidelines, it's probably the only add-ons that does that, which not only added a lot to release time but, it's something that, while it makes for a more reliable product in fps and memory footprint, it's also something that users don't like, yet at the same time they yell at new products that are "fps killers", and when I look at why these products are so heavy on fps, most of the time it's because they either don't have LODs, or even if they have, they have been set in a way they are only enter in effect when they don't do any benefit. The SDK has a very precise tool that tells you exactly, based on a combination between the object complexity, it's size and it's distance from the camera, how you are supposed to switch LODs properly. With "properly", meaning "before the simulator will eventually axe your object itself", because that's what will do when memory becomes constrained. Now, while this is the theory, we don't exactly know how this strategy really works, and how it's different between Xbox and PC. This because when the "kill the badly LODed object" strategy was announced by Asobo, sometimes around SU5 ( the first Xbox version ), even if they said it would be several months before the strategy would enter in force, it still caused some stir on developers forum, because nobody basically took LODs seriously before, and since it takes lots of extra work to create them and tune them visually, adding LOD is something every developer hates, because it adds to development time. Users hates it, because it might be visually distracting, but it's mostly a necessary evil to prevent bigger issues of fps and, most importantly, too high memory usage. Again, this is the theory. The practice is, the simulator doesn't seem to scale this very well. While I'm fairly sure that with a video card with "only" 8GB, which today can be considered entry level, a proper LOD strategy is absolutely required by add-ons, because they just won't fit all together ( and GSX works best with BIG airports and airliners ), it doesn't seem the sim ever tries to use much of extra resources you have, because without manual tweaks, even on Ultra settings, I never managed to see more than 8-9 GB of VRAM used of my 3090. Since GSX objects are not used just when GSX is in action, but they are also used as visual replacement for default Ground Vehicles ( Airport Services and Living World vehicles ), we MUST use LOD properly, because when those vehicles are not called by GSX, we are not even in control HOW MANY of them we have, it's the simulator that will create them, based on the Ground Traffic density sliders, and the number of parking spots (both for AI and Ground vehicles) in the airport. That is, an add-on scenery that has more parking spots than a default scenery, will force the simulator to create more ground vehicles than usual, just because it has more parking spots. However, since the issue with the Pushback truck in GSX you noticed, affects ONLY the models with a Towbar, since these are not available (the sim doesn't support Pushback with a Towbar by default) as default Ground Vehicles, but appear only for the user airplane and only when calling GSX, I guess we CAN tweak their LOD to be less restrictive, since we are sure only one vehicle will be seen at any given time. Then there's the OTHER issue, which now has been documented in the SDK: there can't be any more than 1000 Simobjects in a scene. This counts includes everything that moves, basically, like AI planes, Ground vehicles ( GSX and default ), Living World vehicles, Passengers, Boats, Animals, and airport Jetways too. Because, the irony of the above limit, is that SU9 added a new way to create objects, which is way more convenient and more efficient and allows more reusability, and it's the breaking up of objects, allowing to attach objects to other "parent" objects. This is clearly more efficient because, while before SU9, a Pushback with a Towbar would have to be made as a single object including the Tow Truck, the Towbar and its Driver, now it's made by 3 separate objects, which can even controlled by variables, and since GSX came out no longer after SU9, we immediately jumped on this feature ( this delayed GSX as well ), because is so much better and flexible being able to independently model the Truck, the Towbars and the Drivers, and create many variations of vehicles by combining them in different ways. Same for the Baggage carts: the cart is a separate object, and each bag is a separate object too, which gets attached to the cart. This is incredibly better for flexibility, because we can easily add more variations and new kind of luggage ( in FSX we had just 2 bags, one blue one red ), because bags are separate from the cart, but it also means that each cart is 12 Simbojects, plus 1 for the guy loading, 1 for the loader itself, meaning with two loaders, we add 28 objects to the overall count. But of course, nobody really noticed this before, when AI Injectors started to appear, and of course highly detailed add-on airports too. A super-big airport like KORD adds to the overall Simboject number 186 objects JUST to create jetways. If we assume using it with a GSX profile, which adds a VGDS on each gate that has a jetway, you add another 186 objects at the very minimum, but that's just the best case scenario, when the wall mounted VGDS is used ( 1 object ). Because the ones with a wall support or a ground support, are made with 2 objects, again for the obvious benefit that allows to create an object variation by attaching two object together to create a new one. So, the hard limit on the number of Simobjects is seems to affect more products that were made in the most efficient way, since from a memory usage, having the same objects ( for example, drivers ), inserted several times in multiple vehicles, is way better than having all vehicles including all parts, since it lets the simulator more way to optimize their loading. We can only hope to trying to convince Microsoft/Asobo to lift this limit and/or make it dependent on hardware, at least on the PC version, otherwise it would be very difficult to achieve what everybody would want: that is more passengers and more variations. We probably made a mistake here, by being too honest, and having the Demo in the exact situation you would be on any random airport without any customization. Because, if we made an airport profile for the 3 Demo airports, you wouldn't have noticed any of that. What's really best, in the longer term, having users saying: 1) "I checked the Demo, and it worked perfectly fine, but it's a complete mess everywhere else, but I couldn't figured it out from the Demo" 2) "I checked the Demo, and there are glitches, but I heard it's way better if you download an airport profile" #1 Would work better in the short term, with better initial sales, but #2 will result in the program lasting longer, with users not buying immediately, eventually ending up buying it anyway, sooner or later. That's more sustainable, and better for everybody as well, because you KNOW we MUST keep improving it, something not as obvious with strategy #1. That's just to say, airport customization is important, because not only it fixes almost all these things, but it also protect GSX from being affected much by badly designed airports. No, not all users needs to customize an airport themselves, that's not really the point. What matters to you, as an user of profiles eventually made by somebody else, is what the GSX Editor CAN DO, even if you don't use it yourself, somebody will and, after only 4 months after its release, there are custom GSX profiles for literally every airport that makes sense using in GSX as free downloads. That's why we worked a lot adding lots of features to the airport customization editor: it's simply not possible to always sort out every possible situation automatically. You said vehicles and passenger sometime clash into each other. While vehicle clashing usually can be fixed by editing the vehicle starting positions, you just can't fix every possible situation, and surely not with passengers. Doing this, would mean checking every vehicle/passenger position at each frame, and that would take a very big impact on the simulator at large, since we would require to Spam Simconnect with many more commands per frame than what is reasonable to not start to disrupt OTHER add-ons also doing their thing. At some time, when somebody spams too much, the simulator cannot cope with all request, causing stuttering, lost commands, objects not being removed, or not even being created altogether. Without even mentioning that, even if in an ideal world, we could connect to the sim without any of the above issues, the very problem itself of vehicles not clashing into each other or people moving as a realistic crowd is VERY complex, even in games where the developers not only have FULL control over the whole game engine ( we don't ), but where developers have what can be considered an INFINTE BUDGET, compared to any MSFS developer. There are literally hundreds of videos joking about "GTA V glitches", now rapidly being surpassed by "Cyberpunk 2077 glitches", showing AI vehicles and AI people doing strange things, and these games have 100x the resources we have, in addition to be able to work on the actual game code, so they can use whatever method they like, a luxury we don't have, since we need to play within the rules of the Host simulator. That's why we really can't automatically "fix" those vehicle/people clashing into each other, without some help with airport customization, and even with it, it won't really be automatically solved in all situations, and the crowd simulation will never be perfect, because it would require a far higher level of control we just don't have. And no other game has to work together with other add-ons, it's really something unique to MSFS + add-ons.

Yes, that's my understanding too: Release/Debug it's an indication how the .WASM module has been compiled by the developer, but it's still non-native intermediate code, while the presence of a .DLL indicates the simulator has compiled into native x86 code locally. So yes, it's possible to have a .wasm code running either in Debug or Release, but also a .DLL compiled in either Debug or Release. Some users seems to have the A310 wasm listed as "Debug", I have it in "Release", but I don't have the .DLL The ideal situation should be having the .DLL in Release, this should grant the best possible performance.

Well, yes, the GSX update was supposed to be released yesterday, that's why the notes are dated Nov. 11st but, we released it today because, since MSFS servers had issues yesterday, I've decided to wait a bit, in order not to release *again* something during another MSFS server outage!

That's because you haven't installed today's update: https://www.fsdreamteam.com/couatl_liveupdate_notes.html However, even if you still have the previous version (which was compiled with an earlier SDK, that didn't optimize Release versions properly ), you can see in your screenshot the sim has compiled a .DLL for GSX .wasm module, but for some reason it hasn't for the A310. The same happens to me, tried with two separate MSFS installs, MS Store and Steam. The folder that is supposed to contain the compiled .DLL is empty, and the airplane loads quickly, even when removing the folder, so here is not compiling the .DLL too.

That's weird. In fact, I tried it now, and no .DLL is being compiled after clearing the Localstate folder, but DevMode's WASM Debug window indicates it's a RELEASE build however, no .DLL is there, meaning the sim is likely running the WASM intermediate code, instead of the native x86 .DLL. The airplane loaded quite quickly, not taking many minutes, like other planes with WASM after an update.

You can try this: - Enable DevMode, then start a flight, or enable it when you are already in flight. - From the DevMode menu, be sure "Enable Fast WASM compilation" is DISABLED - EXIT from the sim. - Remove this folder, if your MSFS is from MS Store: %LOCALAPPDATA%\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalState\packages\microsoft-aircraft-a310-300 or this one, if you are on Steam: %APPDATA%\Microsoft Flight Simulato\packages\microsoft-aircraft-a310-300 - Restart the sim, it will recompile the WASM code with Fast compilation Disabled. Now you can disable DevMode, if you don't use it.

It's not something developers enable, it's a setting on the user's systems, which can be enabled in DevMode, but even if you exit from DevMode, it stays the same so, even if you enabled it long ago for some reason, it's possible is still there. - When Fast WASM compilation is Enabled ( not default ), WASM modules are not fully optimized for speed, but newly installed modules or simulator updates won't cause that long startup time the first time you load the airplane after an update. However, the module itself will run slower. Not sure if this could possibly cause a big fps drop, that's really depending on what the module is doing, but surely it will run slower. - When Fast WASM compilation is Disabled ( default ), WASM modules will be compiled to run at full speed, which will take longer to load the first time you start the sim after an update, or after the airplane itself has been updated. But they will run at full speed, after compiled. Fast WASM compilation should only be enabled by developers, because it allow debugging, never by end users. To further clarify: the simulator is not running the .WASM file itself. That's more like an intermediate code, what is really being run, is a .DLL that is being recompiled from the .WASM file each time the file or the sim are updated. That .DLL is located in the "LocalState" sub folder of the MSFS profile, and it's not supplied with the airplane, it's compiled by the sim from the .WASM file, and it's native x86 code, that's why it might take a long time to compile it in a fully optimized way.

Keep in mind that, when the GSX icon is dark, the menu code is not executed, which means: - GSX won't respond to the Hotkey - No text messages from GSX will appear - Pop-up menus cannot appear. This the biggest problem because, while the first two are just minor annoyances, in some situations GSX will need to display a menu after some time it was last closed, for example after the refueling truck is in position, or when asking for a Pushback direction. In these cases, since the menu code is being stopped by MSFS when the toolbar icon is not active, so it won't respond to any calls from GSX to display a menu. That's why by default the X icon doesn't really close the menu, it just hides it, so it can be made appear again on request, and that's why the manual suggest to keep the icon Active for as long you need GSX, and close it from the toolbar when you are done with it. The hidden menu having an effect on the cursor is just a side effect we don't have any way to prevent. The whole menu system would be way easier to understand, would always reply to the hotkey, would always show text messages and it wouldn't require to keep it open but hidden, if only the SDK allowed to open a Toobar menu with a Simconnect call, something that's not possible right now, so we had to use this workaround to let it work as it should.

We don't include/change any of the Approaches in the airport, we just use the ones in the default Navdata and, it seems there's a bug in the default Navdata that, according to Asobo, has been fixed in the latest SU11 Beta: https://devsupport.flightsimulator.com/questions/11912/bug-missing-ils-approaches-at-cyvr.html

GSX never sets the airplane in Slew in MSFS, only in FSX or P3D, but we couldn't do that in MSFS, because whenever the airplane is set in Slew mode in MSFS, the Camera automatically switches to the "Slew Camera", which is quite annoying and would made working with the editors impossible. Instead of Slew, we disable the simulation in every situation we need to be sure the airplane doesn't move on its own, like when editing a parking, editing the airplane profile itself, or very briefly when using the "Warp me" function to instantly move to another parking, or when lowering/raising the plane when using a Towbarless truck, which doesn't really move the airplane, but only affects its pitch. You can detect when this happens by checking the standard "SIM DISABLED" SimVar, if it's 1, it means we temporarily disabled the simulation, because we either need to keep the airplane in place, or we need to move it, for example during a Warp. Sometimes we also "freeze" the airplane (not necessarily always together with "disabling" its simulation ), by setting the following SimVars to 1: IS LATITUDE LONGITUDE FREEZE ON IS ALTITUDE FREEZE ON IS ATTITUDE FREEZE ON Note that, you can't be sure it's GSX that set those to 1, because they are also set by the standard "Active Pause" function.

That's not what he said. He said you can run both at the same time, provided you keep your FSLTL settings reasonable.

That's normal. Whenever you use any form of Temporal Antialiasing ( TAA and DLSS are all temporal-based ), anything that moves fast will have these issues on fast moving displays with text.

They say when you are in a hurry, time seems to pass slower. I just timed how much time it takes from the moment you call Pushback from the GSX menu, to the moment it says "Release Parking Brakes", using a tow truck with a Towbar, and it took exact 1 minute and 40 seconds.

It takes the time it takes to play the bypass pin animations. While it's likely a real person might work faster and, there are reasons why such animations are usually slower than real life, and it's because those animations are not generated in real time ( the performance impact will be huge if we tried doing that ), they are pre-calculated so, in order to play smooth, additional "transitions" from various pieces of the animated timeline must be played as well, adding to the overall animation length. Without those, the animation would be faster, but there would be jumps between the various parts. As usual, there's always a reason why things are made in a certain way, and why things are not 100% identical to real life.

If the PMDG startup flight has its own Passengers Stairs and its own Baggage Loaders, GSX will first need to operate the PMDG FMC to send away those, and wait until they are gone, which takes about 40 seconds. You can speed up that by first sending them away once, then create a custom Setup with those vehicles gone, save it as "GSX" ( maybe do several versions, one with the GPU running, another with the APU, etc. ) and Load that setup, so you won't lose 35-40 seconds each time.

that won’t reduce the number if objects in the scene, since airport services are set by parking type, and we used the same configuration as defult, just with different model. Excluding GSX Airport Services it’s only used in case of 3rd party airports with their own custom Aiport Services in case you’d rather use those, but won’t help with the number of objects, if this is the issue.

that’s exactly what the restart button does

Quoting from the manual, Page 27: More clearly, there isn't a single airplane in MSFS right now requires that option, which could be useful only in very specific cases, like a turnaround simulation that will result in the airplane refueling itself after some time, so that option might help GSX to keep up with that event, by sending its fuel truck automatically when it detects a change in fuel levels. That's why it's Disabled by default, it's a rarely required. Or, it might be the NEXT option, same page of the manual: Obviously not, you only need to reset GSX, either using the "Reset Position", or "Restart Couatl" button, which basically do the same thing.

UPDATE - September 21st, 2022 GSX Pro NEW: Menu system changed; Auto-close function has been removed. GSX Pro NEW: It’s now possible to use a Hot key (Ctrl+Shift+F12 by default, can be configured) to call the menu if the Toolbar icon is Active. GSX Pro NEW: Updated manual to explain how the menu behavior changed and how to configure the Hotkey. Fixed the PMDG 737 refueling example. GSX Pro Fix: Menu options keys 0-9 no longer activate with Ctrl/Shift/Alt modifiers, causing services starting when changing cockpit views with the menu open. GSX Pro Fix: Passengers created in Air when Boarding at Gates with Jetways starting inside Terminals with solid Roofs. GSX Pro Fix: Error when Reloading SimBrief if the wrong username was used or there was no flight plan available online. GSX Pro Fix: Error happening when returning to the Main Menu if Passengers were still being generated. GSX Pro Fix: Service Doors not closing automatically at the end of Catering service. GSX Pro Fix: Refueling stuck when closing menu before service. GSX Pro Fix: Error when listing nearby airports if the airport cache wasn’t ready. GSX Pro NEW: Added new Handling operators: Iran Air, Iraqi Airways and Al-Burhan. GSX Pro NEW: Added new Jetway logos for some Japanese Banks. GSX Pro NEW: Parking Spots with an empty Parking Name in the airport .BGL are now displayed as “Ramp”. GSX (FSX/P3D): Fixed Marshaller/VGDS Fonts appearing at the wrong altitude. FSDT Installer NEW: When downloading unencrypted airport files for FSDT sceneries bought on the Marketplace, their GSX profile will be downloaded as well. FSDT Installer NEW: Fixed a problem with Danish locale, resulting in activation keys starting with “AA” not being recognized correctly. FSDT Installer NEW: Fixed an error that could happen when clearing the temporary internet files cache before downloading files.

If you wrote this number correctly, that is 90 Mbits/s, you should probably expect something around 1 hour to install, since it takes about 5 minutes overall to install and download all updates on a 1Gb/s connection: https://youtu.be/j_GYdmNFzVI Sometimes issues of slow downloads might be just an ISP routing problems, I had problems like this with some sites, and those were usually solved using a VPN, which bypassed my ISP own routing, which can be easily confirmed by checking that packets take a different route even if I choose a VPN node in my own country. This one is supposed to be quite good and doesn't have many limitations in free mode: https://protonvpn.com/

"detect custom fuel system" should be left Disabled as it is by default, because it's only required in very rare cases, when the airplane has a turnaround simulation that results in the plane start refueling itself after some time it was started, so it helps GSX keep up with the event and have its fuel truck being sent in that case. I don't think any 3rd party airplanes in MSFS has this feature, so it should be left Disabled, but it's there in case of need.