virtuali

Just run the Offline installer on top of a normal installation. And don't do an update, otherwise you'll go back to the regular version.

Update: I've posted a Beta for 2.9.6 to try here: https://app.box.com/s/wfiu97shs0r91vmaj0jl It uses a completely new method of starting the Couatl engine: by using an auxiliary "booter" app (similar to what Fenix does), called couatl64_boot.exe, which is what MSFS will start automatically now. This will start the Couatl engine, monitors it and will restart it if required. Windows 8 Compatibility shouldn't matter anymore now. The feedback we need is: If it always starts with the sim If it's able to restart the Couatl engine during a flight in case it crashes If it doesn't reopen when choosing "Exit" from the right-click menu of the couatl icon in the traybar notification area. If it closes when exiting the sim.

I was never able to replicate this. Nothing really happens in GSX when you touch down, even if you pre-selected a gate in flight, so GSX would ideally need to create its own vehicles when you land, there's explicit code that delay their creation until after your speed goes under 60 kts I think, so well after touchdown, precisely to prevent even this case of vehicles being created on touchdown, because you pre-selected a gate. if you don't preselect a gate in flight, GSX vehicles are created when you decide to do so, that is when you select a gate after landing. On final approach, instead, it really depends which distance. At some stage, GSX must call the Navdata API to load data about the airport, that's the one and only thing it does before landing, and it can't be done too early, (30NM out, for example), because there's a range after which even MSFS itself doesn't know that data yet, which is a few miles around the airport. The query about jetways, for example, doesn't return anything until the jetways themselves are loaded, which usually happens about 4-5 NM outside the airport center. The center of the airport matters so, in very large airports, the DEFAULT "visibility" range in GSX, which is 3.0 NM out, might just be on the border of the final approach, because the distance is from the airport ref point. And yes, you CAN tweak this visibility range, but if you make it too big, either you might go outside the range where even the Navdata doesn't have that data anymore, or you might overlap into the range of another nearby airport so, for example, if you are landing on some runways at KFJK, your actual position might be closer to KLGA reference point, so GSX might think you are landing at KLGA. And yes, it's a chicken-egg problem: before loading the airport, we only know the position of its reference point, if we wanted to be more precise, so we could recognize you *are* landing at KJFK, we would need data about the runways, for that we need to load the whole airport data first, potentially causing even more "stuttering", because we would hypothetically have to load more than one airport at once, to decide which one is really the closest one. So yes, you can play with individual airport_visibility ranges, as discussed in the manual at Page 74, but the usual reason to do so, is to reduce them to prevent conflicts between airports which are too close, not really to increase it to make the "load event" as far as possible from the final approach, but it might work in some cases. And of course, if this is really the cause of the stuttering, it's caused by Simconnect itself, since that's what a call to the Navdata is. There IS a way to prove this theory and would be re-enabling the legacy "airport cache" method, where instead of calling into Simconnect, GSX would just open the scenery .BGL. No, it's not a permanent solution, because Navdata is really mandatory now to make jetways working and of course Marketplace airports wouldn't work without it. But it might be a good TEST to at least know that, on your system, the calls into the Navdata ( Simconnect ) might perform worse because is affected by other traffic over Simconnect (AI traffic injection, FSUIPC, etc.), if the stuttering doesn't happen with the legacy Airport cache method, at least you would know where to look for.

We should solve the restart issue with the new auto-restart method we are testing right now, the first feedback we got from testers seems to be positive. It's nothing secret: if you want to try it, we posted it on GSX Community channel on Discord, Just installing GSX won't have any performance cost. Of course there will be some performance cost if you are boarding lots of animated passengers and cargo on a dense airport but, clearly, it's not as if you need your full fps when you are on ground, particularly if you use the AutoFPS app, which will reduce other visual settings you don't need on ground, so you might not even be able to notice any fps impact. Which will go away as soon the most fps-consuming service (Boarding) ends. In addition to that, you can reduce the fps amount of the Boarding by acting on the Passengers Density slider in GSX, so it's not as if you don't have options.

It's not possible to say anything, unless you make a complete report, including: - What "EGLL" is. Default or 3rd party? If it's not default, clearly identify the scenery. - If it's not default, if you verified the GSX replacement jetway files are Disabled for that airport. - If you are using a custom GSX profile, say which one, and verify it has been loaded, and there aren't any other profiles for the same airport in the GSX profiles folder. - If you are using Simbrief. If yes, if you are sure your flight plan has been loaded. - The precise, exact, sequence of operation, including what you did from the Fenix and if you did something with GSX. In general, you shouldn't mix-up: either use only GSX or use the Fenix integration. - The precise, exact, settings in the GSX Page of the Fenix EFB. - If you set GSX settings as Fenix suggests (Autoservices = off, Detect Custom fuel = off, Refuel always progressive = on )

That's because: - for some users (including me!!), disabling the Windows 8 Compatibility setting, which we have done in the last update, has fixed random crashes that happened when selecting the gate in the previous version. - for some users, Windows 8 Compatibilty mode was better to prevent crashes in flight. So, if you have a crash in flight, enable the Windows 8 compatibility flag again. However, this is just a temporary fix, we are testing right now a very different way of starting it, with an automatic restarter utility, so the Compatibility flag shouldn't matter anymore.

That's likely. When Microsoft released the bestselling addons of the Marketplace (I wish they released it before???), apart for the sad consideration as a scenery developer as well that very few airports made it to the top 100, the things that most shocked us was the "Platinum/Gold" tiers, which so much stuff that, when it came out, was immediately labeled as borderline scam, no names, you all know who they are. The other thing that puzzled me, a lot, is how much more popular the military airplanes are compared to the "mainstream" idea that tubeliners are the only ones that matters, which is even more strange, considering military planes sold on the Marketplace must comply with the limitation of not showing (let alone have it working) any weapons. To think that, we had TWO airplane projects (two very popular Airbus, one still not done...), that we started, which we decided to SCRAP, after reading all the negative comments saying lightweight products more catered to the Xbox users shouldn't exists and would ruin the developer reputation in the long run, so we decided to focus on GSX, which took away all our available time (and it will continue to do so for the foreseeable future), because we were lead to believe that, either something is "study-level" or it shouldn't even exists.

There was just ONE email about a purchase mistake like that still hasn't been replied to, and it's because it arrived at 4:25AM so yes, technically it wasn't Sunday anymore but, you know, nobody works in the same time zone. Now, I can't be 100% sure it's was you, since you are using a different nickname here but, since your different nickname on the MSFS forum were you posted the same complain that we supposedly "don't answer", looks very similar to the one in your email, I'm quite confidently say that yes, it's probably you, since your post on the MSFS forum even contained the same misspelling error as this one... Of course, the email has now been answered, with instructions on how to exchange the FSX version you bought by mistake, for the MSFS version. Next time you complain in public about anybody "not replying", AT LEAST wait the customary 24 BUSINESS hours, and take into account time zones as well.

Yes, because even if I set a 30 fps target, if I don't lock it, AutoFPS doesn't keep it *exactly* to 30 but, instead, it's always a bit more, in the 36-45 range, which is perfectly fine for GSync/Freesync monitors (it's better, actually), but not with fixed refresh ones.

I wanted to suggest you doing that, so you could have definitive proof GSX didn't had anything to do with the crash, but I see you already done that. What really happened, and your test without GSX confirms it, the sim crashed for other reasons, and it **made** the Couatl engine crash because, when there's an abrupt crash like that, the Couatl engine, which it's a native, unmanaged, Win64 application so it's tasked to do its own memory clean up instead of relying on the .NET framework to do that, won't get a chance to do its normal cleanup on exit, because the "CLOSE" message from Simconnect it was waiting for never arrived and the connection with the sim was broken abruptly ( because MSFS crashed ), which caused the program to crash, with an Event in the Event Viewer. This can easily mislead thinking Couatl64_MSFS.exe was the cause, when in fact it was the victim of the unrelated crash in the sim.

Yes, because my monitor is not G-sync or Freesync, it's fixed 60hz, so I must lock either to 60 or to 30, otherwise I lose smoothness: 40 fps, in my case, looks worse than 30.

Then I would lose the ability to give priority to the airport and the ground services while on ground, where I might not need an high TLOD (unless the airport is close to Photogrammetry buildings, which really look bad at low TLODs). I think being able to use a different strategy if the frame rate is locked might be a useful feature.

I understand that. It seems that, while there's clearly a logic that decreases TLOD if you are below the target frame rate or increase it if you are above, there's nothing that *tries* to increase it if you are locked exactly on the target, because it thinks you have no headroom for doing that, when in fact you just locked the fps.

Alright, I never got that message, so it recognizes the new MSFS beta correctly. I think I understood what's happening, and I suspect there might be a problem with the "lock at 50% of monitor rate" option in MSFS when used together with the "TLOD Min on Ground/Landing" in AutoFPS. I'm not using Frame generation, and my monitor is 60hz, so the fps is locked and steady at 30 fps and I set 30 fps as target in AutoFPS. The MSI Afterburner overlay graph confirms a 30 fps with a flat line, and I could keep 30 fps even if I closed AutoFPS and set TLOD manually at 200. But since I have the LOD min at 25 so, and I'm on ground, TLOD is 25, it's working as expected. However, after takeoff, if the fps in the sim is locked at 50% of the monitor rate, AutoFPS doesn't even try to increase it: it just shows TLOD 25 in red and it stays that way. Cloud quality was set to Ultra and never reduced (Decrease Cloud quality is enabled), and I was flying in clear weather anyway. As soon as I changed the fps lock option to 100% of monitor rate, fps went up, and AutoFPS quickly raised TLOD up to 200 and kept it that way. If I set the frame rate lock to 50% monitor again when in flight, TLOD stays at 200 as it should. It seems that, when the fps is already locked at 30 fps in the sim, so you are already on target, if the TLOD Min on Ground/Landing option is used, it never tries to raise the TLOD after transitioning from ground to flight. Here's a video I made:

Doesn't seem to work for me. Red numbers for TLOD and Cloud quality means the app hasn't recognized the memory offsets, right?

Yes, 0.4.1 couldn't change the TLOD, it was fixed at 10 no matter what. It worked with the previous MSFS Beta though. I'm trying 0.4.2 test now.

Yes, I found it linked above, thanks.

The subject of the thread where I posted this. The new MSFS update.

Where is that? I just checked GitHub, and the latest version is still 0.4.1

Seems the AutoFPS app will need an update to support this.

You mean something like this? This FSDT KMEM, in P3D, released in 2016. That's P3D, 8 years ago... All technology that would be immediately ready to be used in MSFS, if only we could get a proper "Avatar Mode", like P3D.

Are you sure? https://www.amd.com/en/products/software/adrenalin/frtc.html#:~:text=Frame Rate Target Control (FRTC,create cooler and quieter gaming.

I don't doubt you can reproduce it, but nobody ever reported in this way, you are the first one saying this. Basically, everybody agreed his simulator is completely smooth, the only stutter things are the GSX vehicles, which means GSX is not affecting the sim just because it's there. It's normal that any package that adds a large number of files to the sim will add to the startup time, it's the same if you add an AI traffic pack with lots of models and liveries. You can reduce the startup time significantly by disabling all GSX Airport Services. The only effect of this, is operator selection for the **default** Ground Vehicles (the one used by AI) will be less accurate, being "by region" instead of "by airport", but it should reduce the startup time quite significantly.

I fully agree that movement of GSX vehicles is not as smooth as it was a while ago (I think before SU14), because it seemed that back then the Simconnect latency was better but, saying the sim became smoother after uninstalling GSX is really not possible, you must have changed something else in the meantime, because the mere fact GSX is installed, can't cause stuttering by itself, or something completely different is going on in your case. Everybody here is saying something different: his whole sim is completely smooth except GSX vehicles, if you really meant what you wrote (your sim became smoother only after you uninstalled GSX), that's a whole different matter which would require a completely different troubleshooting process, and it's not what most have reported this. Trying to guess, something that might happen is that you might have hit the max number of Simobjects, usually because too many AIs using Simconnect Injection, and when that happens, any Simconnect app will start to receive lots (sometimes thousands) of Simconnect Exceptions to notify the problem, and this not only increases the Simconnect traffic quite a bit, but it causes all app to work even more to handle the exceptions. But this is just one theory and a guess.

Sorry but, it doesn't make any difference, I was just making an example that normally is not that bad (or, at least, I never seen it so bad). Do you also see something like that? I'm asking because, I posted a video that was WAY better on our form, showing only a couple extremely minor micro-stuttering, not even remotely comparable to what was shown on that video to a user who said GSX is a "stutter fest" for him, and even after I posted, he said he had something similar so, clearly, nobody has the same tolerance to this and what looks to me as micro-stutters, somebody else calls it "stutter fest", and still it was much better than what has been shown. Please clarify: - Is your frame rate locked - Have you used process lasso correctly, including (if your CPU has them), assigning MSFS only to P-Cores? - Do you still have stuttering as bad as in that video that has been posted? This is good, and it means the issue is caused exactly by what I explained: GSX is affected by the Simconnect latency/irregularity and it's not CAUSING stuttering to the sim. Which is to be expected because, running entirely external to it, while it has the disadvantage it can be affected by Simconnect latency, it also has the advantage that it cannot slow down the sim. Again, if you don't have any other apps that use Simconnect and they use that info to SHOW something that moves, you won't even know they are affected to. I keep repeating this, because you continue to repeat "the only thing stuttering is GSX", as if you don't want to accept the above explanation. Of course: the Default Pushback system doesn't use Simconnect to move the airplane, it's an internal system that takes periodic Left/Right commands but otherwise moves the airplane on its own, so it's not affected the Simconnect eventual lack of regularity due to either variable fps or too much traffic on it because it doesn't communicate with the sim using Simconnect.