virtuali

You don't have to wait for your forum registration to get support, because the forum is only ONE of the two possible FSDT support channels, email is always available. In any case, your problem is very likely caused by your antivirus, that has modified the executable mistakenly assuming it was a threat, so it has now corrupted it, wrongly trying to "heal it" from a non-existent threat. - Configure the antivirus to add the whole Addon Manager to the antivirus Exclusions - Run either the FSDT Live Update or the latest Offline installer. Please don't continue here, if you still have issues, use the FSDT support email while you wait for the forum registration to be processed.

It's a known issue in the sim, Asobo is aware of it, but it doesn't seem to have found the cause yet: https://devsupport.flightsimulator.com/questions/8061/exexml-fails-to-launch-my-simconnect-external-appl.html For me, it happens 100% of the time: NONE of the applications in the EXE.XML starts ( Fenix, Honeycomb drivers, GSX ), I suspect it's because I have a complete install of the MS Store version with SU 10 Beta using a license, and separate Steam version at SU9 using another license. This seems to confuse the startup, because I can't even start the Simconnect debug window, saying I'm "lacking a license" to run it.

Again ?? Really ? Haven't been explained clearly enough that what you think it's "simple database", it's basically a recreation of a very big site like flightsim.to ? What would be the point, again ? Just go there to get the free profiles, is that easy.

It's surely not something we can prevent, even if we wanted. Unless we decided to write a restrictive EULA which would explicitly forbid that but, since we haven't done anything like that, one must assume every user is free to share his own creations in the way he sees fit. I just can't see how we could legally claim copyrights over a file format ( the .INI file ) which is an open standard, containing data created by the author, who spent his own time customizing the airport. The important thing to note is: - We don't get any fees from these sales. - These authors are not getting any help from us, they are using the same tools available to everybody else. This means, being a free market, you are free to decide to not buy a profile, if the price asked is high for you, find a freeware one, or do it yourself.

Let's try a real life example: The most downloaded GSX profile on flightsim.to is for....(drum roll) FSDT LSZH, which already comes with one! So, what would be your "not rocket science" solution here ? Should we use the official one or the one on flightsim.to ? Wouldn't the user want to know the difference ? Maybe there's an explanation about the differences, maybe what the author did doens't agree with you ("in this profile I removed all docking systems because I love marshallers, especially the female ones" ) another author might do another profile for the SAME airport, the original author might add a readme saying "don't download this one, I made a better one on this link! " HOW, exactly, do you suggest we'd decide what to download "automatically" ? - A voting system inside the app ? - The ability to read notes and user comments inside ( "I gave you 1 star because everybody knows Zambia airlines doesn't park at E17!") ? - Something showing the most popular downloads ? - Something that shows screenshots ? Do you realize you are asking we should just CLONE Flightsim.to inside the installer ? What would be the point, exactly ? Just go there.

Before we could provide with those, those developers should MAKE those profiles to begin with! And, they would also need to grant their explicit permission to "download them automatically". Some developers would LIKE you visit THEIR site to download something, it's their work, and their right to distribute it in the way they see fit. We can't obviously clam any right on profiles made by 3rd parties for 3rd party sceneries!

Now you are saying something entirely different, that is "official developers profiles" Which developers you are referring to ? We provided GSX profiles for all our main sceneries that would be enhanced by GSX, like KCLT, KORD, LSZH, LSFB, KSDF and CYVR. If you have any of those, you haven't even *noticed* because they are coming with Live Updates. Other developers can just create their own GSX profiles and place them directly in the scenery package, no need to download anything, but how would you expect developers would already have GSX profiles ready, only 12 days after release ?

The instructions that come with many profile creators readme files are making it sound way more complex than really is, because of having missed this paragraph in the manual, Page 46: Once this is understood, it's just drag&drop in the %APPDATA%\Virtuali\GSX\MSFS folder, no edits required.

Of *course* you can file a Chargeback, and nobody will "challenge" it, because the cost to do do that would far exceed the value of the transaction. This doesn't have anything to do with citing "the law", that clearly said you only have a right to a refund, for copyrighted products (which have more exemptions to refund rights than normal products) provided is "misrepresented" or "unfit for purpose". What the low among of money which makes every discussion about "challenging" a chargeback completely moot, has anything to do with saying the product has "misrepresented", when clearly isn't ? If GSX costed 10.000$ a copy, you can be sure we'd challenged each and every refund requests based on those motivations and yes, we'll surely win the vast majority of those, because refund request coming from users finding *actual* bugs, not only are not coming in any meaningful numbers, but they are probably already been fixed.

That is in fact a bug, the airplane editor works, but it fails to reload a user config, it will surely fixed!

It's *almost* usable. In the current Beta it still missing some data: - Runway Starts, but Asobo confirmed they will be added soon. - Jetways and Jetway links. This is by far the most important data for us, so we keep reminding Asobo it should be there, because without it we would have to rely to very strange hacks to know where jetways are, like searching for all Simobjects in the sim and trying to *guess* which one are Jetways, because there isn't a separate Category for them, like there is for Ground Vehicles, Aircraft, Boats, Animals, etc.

And who's decides a product has been "Misreprented" ? That's what the "give support a chance to fix your problem, first" sentence means. Do you even know what makes 99% of the refund requests ? - CTDs, which we all know don't have anything to do with GSX, but were an unfortunate coincidence of release dates. This is by far the N.1 reason for refund requests. - Missing compatibility with Marketplace airports. This of course is clearly explained on our site, and we also have a *TRIAL* so, how one could possibly say this feature has been "Misrepresented" ? This of course will go away after SU10, and we are already at work integrating the new Facility API which will make GSX compatible with Marketplace airports AND will get rid of the Airport cache entirely, which is another source of bugs ( usually because failures to read the .BGLs, corrupted files, file priorities and loading order not clear ), all of this will be gone after we could read the airport data from the sim itself. - Generic "bugs" like the infamous "Passenger walk in air". Which are caused by two MSFS issue: a BUG resulting in a loss of LOD sync between jetways, which appears AS IF GSX "disconnected" the jetway when it hasn't, it's the jetway itself that lost sync between the LOD and the animation, and happens with any jetway from any developer, including the default ones, we reported this bug more than a year ago, and every other scenery developer out there can confirm this. The other issue being an SDK limitation, which makes for us impossible to know *where* the Jetway has docked, since they dock everywhere, on the back door, sometimes even on the service door with the head twisted! If we had a way to know where the jetway ended, we could have calculated the passenger path correctly but the way it is now, we can only HOPE the user has parked in a position were the jetway has docked properly. Both this issues will cause passengers "walking in the air", which most people see as a "GSX bug" when in fact the real issue is the jetway docking in the wrong place, with no way for GSX to know that. That's why we have parking customization that allows to change the Stop position precisely, that's why there's TEST function ( NumPad5 ) so users can TEST where the jetway WILL go from there, and adapt the position to overcome this problem. These are what make the overwhelmingly majority of the (fortunately very low, considering the sales) refund requests. None of them are the result of a product "Misrepresentation".

Then I must have misunderstood him, I have been biased because all the flack I got from him due to the SimBrief thing.

Attack "everyone" ? Have you even followed what kind of tones and attitude he's been using ? So you agree with him, that it would have been best to have GSX loading flight plans for the wrong airplane ? Or, you are just saying "You are right, but I don't like your manners", fair enough, your point is taken. Let's go back to the software... When I say something's not working because of a limitation of the sim, it's not something that is opened to discussion. It's a fact If anybody thinks my explanations of a problem caused by a limitation of the sim or the SDK or a bug is factually incorrect, it should be easy to disprove it. And I never "blame users", it's not their fault if this sim crashes or has bug. Sometimes, it would help if the manual is used.

So, are you saying you don't understand why GSX is not running, and you show a screenshot where GSX not even installed ? And all this drama, just because you didn't like the perfectly sensible choice of not blindly loading a SimBrief profile not meant for the airplane ? It's called DESIGN CHOICE, and you can provide with the opinions you want, but in the end, the final decision how to make a software is not yours. MY own decision is that, I think your suggestion of loading profiles for any airplanes, even if would result in drastically different passenger numbers (let alone Fuel quantities ), would all end up in most users assuming GSX is buggy, because it tried to load 400 passengers and 400K lbs of fuel in a 737 "just because SimBrief said so"

It might be caused by the \\?\ initial characters at start, which are a special notation to support extra-long path names, but I assure you the GSX code only checks the file name of the .BGL, it doesn't care about the path. So, the easiest solution to make an automatic install is: - remove everything from the path, leave just the .BGL file name - place the .INI *inside* your package, alongside its matching .BGL, no need to rebuild it or change the layout.json, the simulator will ignore it, but GSX will use it, no need to explain users where the %APPDATA% folder is! This last configuration is called "designer-provided" profile, and it used in read-only mode, which means if users start to edit your customization, their changes will not affect your file, but a new one will be created in *their* %APPDATA%. And if they screw up, they can just delete the .INI in %APPDATA%, but the designer-provide one won't be affected, so they won't have to start from scratch.

Well, GSX can be used like that. You don't even have to start it, because GSX Pro is in fact made of two separate products, which are installed together by our installer: - "GSX World", which is quite similar to other offerings from LVFR or Simultech, but it combines Ground vehicle replacement + Jetways replacement in a single product, and instead of being limited by region and with a single Jetway model all over the world, if can offer specific by-airport ground operators and by-airport jetways. It doesn't require any software to run, and it's really all automatic, you use it from the default ground services menus, and you can even use the free Pushback Toolbar add-on, with the GSX Pushback truck, because all the vehicles in this packages has been designed to be stand-in replacements for the default ones. - "GSX Pro", which is the "full" GSX, with all the customization and the other advanced features which require starting the Couatl engine to run. Which you can foreseeably do even just before you need it, since we designed it to be Started, Restarted and Quitted multiple times, at any time. If you want an extremely easy to use experience, without worrying about customization, you might use it this way, just getting the new vehicles/jetways which looks better and more varied. Call them from the default Ground services ATC menu, and when you need to Depart, start the full GSX from its icon, select Departure, and just do the Pushback and Eventually the Follow me. The Pushback will work 90% of the time with just Left/Right preset, and the Follow Me doesn't require any customization, it will work on the airport provided its reasonably well designed.

We were expecting this, although not *that* fast, that's why we spent so much time on the editor and to provide lots of high quality objects like Jetways and VGDS, which are not easy to do. I can only guess what will happen when freeware authors will start to realize they are not limited to making "just" a GSX profile, but they can also use the vast amount of jetway models and operators ( there are more variations than we used, for example they are also multi-colored ) and the VGDS to create entirely new sceneries using the standard DevMode editor, which allows to place any object anywhere and combined with the GSX own customization like unlimited pre-planned pushback routes for each gate, walking passengers paths, will allow to freeware of a very high quality.

This is an interesting suggestion, which I don't think it will be very difficult to add. It will of course made the program more complex to use.

And that's precisely why I don't just write single blanket sentences, which can then be quoted as the definitive answer. I always argument my point and, my point was: somiller thinks GSX should just ignore the airplane type, and load a Simbrief flight plan made for another aircraft in any case, even if it could then cause in a massively inaccurate variations in the number. I explained why doing this would be worse than what *he* experienced, a way lower difference in the passenger count, caused only because the icao type designator was wrong in the airacft.cfg file, which caused GSX reverting to its default method of estimating the passenger number based on payload, which is not as inaccurate as it would be, if we just took any flight plan, without checking. This is called "argumenting" and my opinion is the suggested solution of ignoring the airplane type would lead to way more wrong perceptions as "GSX has a bug" than how it currently works.

Try saying you like the Xbox livery, and the sky will fall...

There's no need to repeat here what YOU think it's "superfluous", when it clearly isn't, and the reasons why have been explained to you on our forum not just by me, but other users as well *before* I had to say anything. No, GSX doesn't "silently error", what you continue to call error is a precise design decision that has ben clearly explained in the manual when the preconditions to accept a flight plan from Simbrief are explained, which are all obvious and logical for everybody, just you don't accept them. The icao type restriction is there for the obvious reason we just can't blindly take in a flight plan made for a 747 into a 737, because *everybody* would think it's just wrong and silly for GSX create 400 passengers and have them magically fit into a 737, that's why it's correct to check for the airplane type and don't ignore it as you suggested. You found "hardly realistic" that GSX had to estimate a 214 passengers when an real 737-800 could only carry 189, yet you suggested a solution that would have created much larger errors, because the numbers could be coming from a flight plan made for a completely different airplane. With GSX calling for like 5 Buses worth of passengers, because of your suggestion to ignore the airplane type. And all of this why ? Only because by chance, PMDG made a *small* mistake of setting their icao type designator incorrectly, something that could have been fixed in a minute, and they already said it was a oversight and will be fixed soon. Because if this didn't happen and the icao type in the aircraft.cfg was correct to begin with, you would have just said "wow, GSX took the pax number from Simbrief automatically", because this is what normally happen. If *BREDOK* made a mistake in their icao_type_designator, making GSX "silently error" nobody would even cared...

The PMDG planes don't work without having an internal GSX configuration first, which we released on the same DAY it came out. If you you tried it without *any* configuration, it will likely work very badly, it at all. If you tried to create a configuration yourself, without starting from the basic internal config first, it will also not work correctly, PMDG are a special case which requires special coding,. Of course, if you posted about this either on our forum or on the support email, I would have told you to WAIT for the official PMDG 738 support, and use the other variants in the mean time ( if only to convince you GSX *works* ), and of course now that the config has been released, everybody using the PMDG 738 can confirm it works, you saw some posts here as well.

Using the GSX GPU on the PMDG is not very useful, since it cannot power the airplane, while the PMDG one can. I hope nobody bought GSX for the GPU, it's there for completes and because maybe one day the SDK will allow to write over some variables the electrical system which *were* writable in FSX and P3D, but aren't anymore in MSFS.

Page 54, the "Embedded Stairs" option.