9 hours ago, jarmstro said:

For Gods sake!!! So Pyreegue have another update with cryptic instructions. I just don't understand. So you have to edit the file so it points to the file in the community folder. But with all the other profiles I've downloaded you have to point the file to the GSX MSF file? And in the Pyreegue download there's a folder which looks like it should overwrite files in the community folder but there are no mention of this folder in the instructions.

I would be grateful if some one could just let me know, in the simplest language possible, where to put profiles downloaded from flightsim.to and whether any editing is necessary and if so what. My community folder path is G:\MSFS\Community and my GSX addons path is on my C drive and is hidden but findable eventually. Thanks 

(If I could get ONE AIRPORT to work properly my blood pressure would return to safe levels.)

Drag and drop, copy and paste a file path. I don't mean to be rude but this is not rocket science and takes less than a minute to do. 

4 hours ago, pyreegue said:

Drag and drop, copy and paste a file path. I don't mean to be rude but this is not rocket science and takes less than a minute to do. 

I was told that editing the file path was unnecessary? This is the only profile I have downloaded where there are instructions to edit the path?

Edited August 31, 20223 yr by jarmstro

According to FSDT forum (and the manual), you do NOT need to modify the .ini files from flightsim.to, as long as the .bgl name used for the modification (e.g. the AFCAD file) is 100% identical to the one you have on your rig. 

6 hours ago, pyreegue said:

Drag and drop, copy and paste a file path. I don't mean to be rude but this is not rocket science and takes less than a minute to do. 

Editing the file path is not necessary anymore for GSX. All it needs is the correct filename of the .bgl file; you don't even need to set a path at all, just the filename.bgl is enough.

3 hours ago, Fiorentoni said:

Editing the file path is not necessary anymore for GSX. All it needs is the correct filename of the .bgl file; you don't even need to set a path at all, just the filename.bgl is enough.

It didn’t work for some without editing the file path. I will ask Umberto how this can be made into a drag and drop installation or even auto-detection from inside the scenery package so that it can be shipped already with a config.

34 minutes ago, pyreegue said:

It didn’t work for some without editing the file path. I will ask Umberto how this can be made into a drag and drop installation or even auto-detection from inside the scenery package so that it can be shipped already with a config.

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.

 

Edited August 31, 20223 yr by virtuali

7 minutes ago, virtuali said:

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.

 

 Will do that from now on, cheers 

20 hours ago, DiscoSweat said:

Really hope there's a robust support and patching plan in place because this addon has been a disaster for me.

Have spent the last 5 hours troubleshooting and still haven't seen a single ground service. Torn between waiting for an update and just doing a chargeback. Anyone with more experience with this dev able to say with confidence that the issues will be fixed?

Probably better to ask FSDT for a refund first. If they refuse, then you can do a chargeback. But they do (grudgingly) give refunds if you ask a few times. 

The dev is unlikely to have things fixed for a while, because he claims that the issues are not in his software, but rather in the underlying MSFS platform, or with third party airports, or with users, or Cloudflare, or <pick your thing that's not FSDT>.

Taking the dev at his word, if the issues are caused either by MSFS or third parties or user error, it's not really likely that he can fix any of those things. Maybe GSX shouldn't have been sold if the underlying platform didn't support it. 

I have also uninstalled GSX cause it simply doesn't work the way it's supposed to.

I'm not bothering with a chargeback since I do want to support smaller devs, and I can afford the $30 as a donation - but I'm not going to buy any more FSDT software ever again. . 

20 hours ago, DiscoSweat said:

Really hope there's a robust support and patching plan in place because this addon has been a disaster for me.

Have spent the last 5 hours troubleshooting and still haven't seen a single ground service. Torn between waiting for an update and just doing a chargeback. Anyone with more experience with this dev able to say with confidence that the issues will be fixed?

What's the problem? If you don't see no ground services at all I wouldn't wait for a "fix", because obviously there's something gone wrong during installing or you misunderstood something in the manual. How about contacting support over at the FSDT forums? Or describe your problem and we can help you here in this very thread.
A chargeback needs per law one or more tries by the developer to help you before it can go through, so you'll have to go down that route anyway.

1 hour ago, Fiorentoni said:

A chargeback needs per law one or more tries by the developer to help you before it can go through,

I’m sorry, what “law” are you referring to here? Can you post a reference to this law that requires the developer help?

Is this a Swiss or EU law? That won’t apply to a US credit card company - US law will apply.

In the USA, at least, chargeback is heavily weighted in favour of the customer. There’s no law that says “we won’t process a chargeback till the developer has helped”. Heck , American Express is well known as a great consumer card for this very reason - they practically always side with the consumer and do not hassle the card holder. 
 

Misrepresentation is valid grounds for chargeback, and given the huge amount of evidence that this program doesn’t quite do what it’s supposed to do, I very much doubt that a credit card company is going to refuse a chargeback. And if you think Visa is going to open an investigation over $30… well I don’t know what to tell you. 

“Under Federal laws your customers have the right to dispute charges based on billing errors or under "claims and defenses" provisions. Billing errors include unauthorized charges, undelivered goods or services, misrepresentation of goods or services, the wrong quantity of goods or failure to provide goods or services within the expected timeframe.”

here’s the source  https://legalbeagle.com/13319095-chargeback-laws.html

finally, do you work for FSDT or are you somehow related (professionally or personally) to the developers? You’ve been vigorously defending GSX and FSDT from launch day so it’s just odd that a regular user would be so deeply invested in defending a random flight sim program.

if you are just a regular user, I apologize in advance; but if you do have some affiliation to FSDT, it would be nice to know.

 

3 hours ago, Fiorentoni said:

A chargeback needs per law one or more tries by the developer to help you before it can go through, so you'll have to go down that route anyway.

Absolutely not, quit spreading misinformation please.

Thanks!

Edited September 1, 20223 yr by blueshark747

Folks, FSDT offers a demo for ALL their products since Day 1.
Try it. You like it? Purchase it.
You don't like it? No problem, remove it from your computer.

I have no affiliation to FSDT and never met Umberto in real life.
But I know  and appreciate his products since the LAGO time, twenty years ago.
He really, really does not deserve this onslaught of criticism and aggressive attacks, and the lack of respect for his work from some folks here is sincerely unacceptable.
When he patiently explains why this or that feature does not work because of the limitations of MSFS he is telling the truth, he is not trying to cheat you.
So please give him a break now and move on.

10 hours ago, FlyingGoose said:

Misrepresentation is valid grounds for chargeback,

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".

Edited September 1, 20223 yr by virtuali

11 minutes ago, virtuali said:

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.

Oh that is very good news! Does this new Facility API work already in SU10 beta or still there are some issues with is? That bgl stuff are indeed confusing 😅

4 hours ago, omarsmak30 said:

Oh that is very good news! Does this new Facility API work already in SU10 beta or still there are some issues with is? That bgl stuff are indeed confusing 😅

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.

Edited September 1, 20223 yr by virtuali