Nothing in GSX is related to default FSX controls.

 

None of our installers touch, reads, writes, or interact in ANY way with the FSX default controls.

 

We have our *own* separate .INI file to store our own keys, the %APPDATA%\Virtuali\Keymapping.INI file, and we ASK to FSX, using official standard Simconnect approved methods, those keys.

 

Nothing of this operation is ever stored anywhere by FSX, THAT'S why we need our own Keymapping.ini file, for the precise reason that, asking to use a key via Simconnect will NOT act on the default FSX Controls file!

 

When a Simconnect client quits, every key that it asked to FSX is reclaimed back, without leaving any trace on the default controls.xml file.

 

There's NOTHING in any of our installer, not GSX, Addon Manager, Couatl or any of the scenery that will ever had ANY, even remote, interaction with the FSX default controls file, which is located in %APPDATA%\Microsoft\FSX\control.xml and NONE of our products and/or installers has any relationship with it.

1.  What method is being used by FSX.EXE and/or the Prepar3D.EXE to make the call to launch the executable it finds in the EXE.XML (where Couatl.exe is referenced)?  Do you know?  Does Umberto know?  I've used a dependency walker and that doesn't show anything about what method is called, nor does the SDK give specifics.  There are several ways to start a process (another executable) from within C#/C++ compiled product (aka FSX/P3D) ... these are "some" (not all) of the ways:

 

CreateProcess

CreateProcessAsUser

System

ShellExecute

 

Each one of these methods has a different security context which is managed by the OS .. they are not all the same.

 

I presume the Executable being launched has an embedded manifest to require Administrator rights and therefore it wouldn't matter which call is being used (as long as the OS has UAC)?

 

EDIT:

To be fair to Rob, It does seem that Create Process will raise an error if the manifest has "requireAdministrator" flagged.

After a 3 month break from FS, it's interesting that this thread is still active and still contentious.

 

As Rob Ainscough politely suggested, you'd think that this in itself would cause this developer to review the way their products are 'managed' within FS  (I am deliberately using the loosest terms possible, to avoid contention :wink:).

 

However it is (in my opinion) very clear that the developer has a fixed mindset and will never truly consider whether Couatl is an unpopular 'management tool' of their products.    - and that it may be fortuitious to look at a road map without it.

 

Time after time we see very 'analytical' responses to concerns, reports and feedback.   They are analytical but never really get to the heart of the issue;  

 

Couatl is invasive and many people don't want an invasive application, such as Couatl, interacting with their flight sim set up.

 

There comes a point when one has to realise that you just have to vote with your choices.

 

I detest everything about Couatl, and articulated my reasons for this on Page 1 of this thread.    Now, at Page 16, we are no further forward.

 

So I made the decision not to purchase or use any products that use Couatl.

 

At the end of the day sometimes we just have to accept that some people just are not open to feedback, and make our own choices with that in mind.

I have had gsx installed for quite a while. Suddenly it stopped working, and I got an error from the couatl engine. The only thing that changed about my pc that day was that I have bought the Razor Kraken 7.1 headset and installed it.

 

Virtuali didnt belive that it was my headset, and listed the known programs that interfer with couatl. I didnt use any of them, which I also stated in my first post at their forum.

I was asked to terminate one and one task in the process tree to figure out which one it was causing trouble. After a good while of doing this it was indeed an exe file connected with my kraken headset that caused coatl to stop working.

 

Lessons learned:

- Its not the fault of coatl.

- I cant use my headset which was quite costly (it's not couatls fault)

- I didnt feel like I was being listened to

 

I'm still using their product, but I am concidering not buying any more of them. I'm quite picky about service, and I'm very wary about being patronized.

I presume the Executable being launched has an embedded manifest to require Administrator rights and therefore it wouldn't matter which call is being used (as long as the OS has UAC)?

With "the Executable", when all the discussion about permissions started, the OP referred to the Couatl_updater.exe, and he suggested that we had no idea of the security context the updater was running under, so it wasn't a good idea launching the updater from within FSX.

 

This wasn't the case, because that executable HAS in its manifest a request to run As Administrator which means, as I've said, it will be either run As Admin IF authorized by the user, or it won't run at all so, the only security context it runs under is very well under control.

Virtuali didnt belive that it was my headset, and listed the known programs that interfere with couatl.

This was the original thread on our forum:

 

http://www.fsdreamteam.com/forum/index.php/topic,9720.msg76833.html#msg76833

 

"I don't think it's the Razer software, I have a Razer mouse too, and never had any problems with its software, although I have to say I probably haven't updated it in a while."

 

I think was quite clear this was just an assumption, based on the fact that I have software made by Razer on my system, so it was just a guess, not a something certain. The only thing sure, is that it was an external process, and of course it was.

 

After you posted again, I've suggested to do this:

 

"Open the Task Manager when FSX is not running, and look at all your running processes, and close them all, one by one, starting FSX each time you close a new one, until you'll eventually find which is the offending one. Once the problematic software has been identified, you can try look into some of its options, to eventually find if it's just a specific option that might be turned off that is causing this"

 

 

This was your reply:

 

"Ok I went through the processess, and I found that when ending the process "krakensysaudiolauncher.exe" my coatl engine errors went away."

 

You did what I've suggested, AND IT WORKED! Nobody else reported that problem until then, which means I could only gave you a list of the KNOWN causes, up to that day. But of course, as anyone can see, I gave you a CORRECT suggestion to find a new, unknown, cause and, of course, it worked.

 

Then you asked this:

 

"I'd also like to know how to permanently shut this exe file down so I dont have to manually end the process tree every time."

 

And I replied with:

 

"use the MSCONFIG tool that comes with Windows, in the "Start-up" section there's a list of all the executables that Windows launches automatically, just uncheck that one and reboot."

 

You replied with:

 

"Thanks :biggrin: "

 

Now, how that discussion could ever translate into "I'm quite picky about service, and I'm very wary about being patronized", it's really beyond me...

 

 

Lessons learned:

- Its not the fault of coatl.

Of course it wasn't. It was caused by another program which for some reason uses a very invasive global hook on all executables.

 

- I cant use my headset which was quite costly (it's not couatls fault)

A fair behavior would have been, going to Razer support forum and asking: "why your executable causes problems to another software that runs normally if I shut down your executable" ?

 

Since they made it, it's possible they could explain this and, perhaps, like in case of Radeon Pro or the ATI Tray Tools, is NOT required to renounce using those products altogether, but it's enough finding which specific OPTION causes this so no, it's likely you won't have to stop using your headset.

 

 

I didnt feel like I was being listened to

Quite the opposite: you have been given the precise, exact suggestion that enabled you to find the problem and solve it, which was to check all your running processes and proceed by exclusion until you eventually find the culprit. Which is the only possible way of finding a new problematic software that will be added to the list of the KNOWN causes.

 

And of course, since you were the FIRST one to report it, the problem is not "unknown" anymore so, another user that reported this issue after your first report:

 

http://www.fsdreamteam.com/forum/index.php/topic,9809.0.html

 

Got the "The krakensysaudiolauncher.exe from the Razer Kraken headset drivers" answer, which is now a known cause of that problem.

 

If you would eventually find if there's an OPTION in the krakensysaudiolauncher.exe file that could be changed, so you can still use it, it would be useful if you could report it on our forum, as this user did:

 

http://www.fsdreamteam.com/forum/index.php/topic,8941.msg71935.html#msg71935

 

Thanks to his reports, we can simply tell "do not use API monitoring settings inside RadeonPro", instead of just saying "Don't use RadeonPro"

Time after time we see very 'analytical' responses to concerns, reports and feedback.   They are analytical but never really get to the heart of the issue;  

 

Couatl is invasive and many people don't want an invasive application, such as Couatl, interacting with their flight sim set up.

 

My replies, explaining what Couatl does were in fact analytical, and WERE getting into the hearth of the problem. The issue is, you don't want to accept them, and already made up your mind about it. Couatl is not invasive, and I'll clearly explain why.

 

One definition of "Invasive", is a software that cause problems to OTHER software you use, which doesn't have anything to do with it.

 

For example, when you run things like the Radeon Pro utility with the "API Monitoring" enabled, they ARE being invasive, because they are causing problems TO Couatl. It's not that if you run Couatl that the Radeon Pro tool will stop working, it's the *opposite* way around, Couatl is the victim, not the cause.

 

Same for the antivirus, is not that if you run Couatl, your antivirus will start to malfunction. It's the other way around, the antivirus is the "invasive" program that is causing problems TO Couatl.

 

This, in relationship to other programs that are not related to FSX. With regards to FSX itself, again, Couatl cannot be called "invasive" either because, as already explained, is NOT running as an FSX module, a module is a .DLL, and such modules should be very carefully programmed because, if they crash, they WILL bring down FSX with them!

 

Instead, it's not possible that Couatl, being an external .EXE, could ever crash FSX. The only thing that Couatl can do, in the worse case, is to crash ITSELF, but this won't cause any problem to FSX. When Couatl will crash for any reason, it won't affect ANYTHING in FSX, except the things related to it so, for example, if Couatl would crash, GSX would stop, but of course the rest of the sim is still entirely safe.

 

So no, Couatl is NOT "invasive", when this term is used referring to programs that cause problems to other programs.

 

Another reason why people call a product "invasive", is when it starts with your system, with no obvious way to turn it off. And of course, Couatl doesn't do any of this, since it starts with FSX and quits with it. Nothing of it runs in the background in your system after FSX quits. And you can easily turn it off at any time, by killing the Couatl.exe process with the Task Manager or prevent its startup by setting the <disabled>True</disabled> line in your EXE.XML. So no, Couatl is not "invasive", even under this definition.

 

Another possible reason why a program could be labeled "invasive", is that is taking away resources and/or memory from your other applications. Again, the reality is exactly the opposite: Couatl SAVES MEMORY that is scarce in FSX, because it runs in its own separate address space, and its plugins could be as complex as we wanted, without stealing any memory from FSX. That's not the case for every other .DLL and .GAU file that you have installed in FSX, they *all* take away memory from it.

 

Last reason why sometimes a program is called "invasive", is that it connects to the internet without the user knowledge. And of course, Couatl doesn't do any of that. It connects to the internet, but it does it WITH the user consent, clearly indicating there might be an Update to download, giving the option to READ what the update is about, and decide to apply the update or Ignore it. And, as already explained in this thread, several times, the whole Live Update feature can be disabled altogether.

 

So, by every definition of "invasive", Couatl can't surely be classified as such.

 

 

I detest everything about Couatl, and articulated my reasons for this on Page 1 of this thread.

You posted in the first page of the thread, before I had a chance to explain several things and by your own admission, you didn't really know what Couatl *really* does.

 

Now, at Page 16, we are no further forward.

That's because you already made up your mind about the "unnecessary complexity" added to what we do, and decided it's not worth the effort, but you just can't expect the thread should go in your own way, regardless.

 

At the end of the day sometimes we just have to accept that some people just are not open to feedback, and make our own choices with that in mind.

I thought to have show a LOT of openness to feedback here, and I've already promised that we'll do our best to fight antivirus problems and such incompatibility with some (invasive) external executables, but that's it, you just can't expect we would get rid of it entirely. Also, expecting this, doesn't make any sense: are you really interested having that program improved, which is what "feedback" is all about ?

 

Couatl is not going anywhere, and it made our best selling product by far, which is GSX of course, and it made possible (why I'm still repeating this ?) many things that we don't have any plan to lose, and it will do more and more things in the future, especially with P3D, with more chances to control the graphic engine, which means the gap between the "use Couatl" and "don't use Couatl" will be even larger than it is now.

.

This was the original thread on our forum:

 

http://www.fsdreamteam.com/forum/index.php/topic,9720.msg76833.html#msg76833

 

"I don't think it's the Razer software, I have a Razer mouse too, and never had any problems with its software, although I have to say I probably haven't updated it in a while."

 

I think was quite clear this was just an assumption, based on the fact that I have software made by Razer on my system, so it was just a guess, not a something certain. The only thing sure, is that it was an external process, and of course it was.

 

After you posted again, I've suggested to do this:

 

"Open the Task Manager when FSX is not running, and look at all your running processes, and close them all, one by one, starting FSX each time you close a new one, until you'll eventually find which is the offending one. Once the problematic software has been identified, you can try look into some of its options, to eventually find if it's just a specific option that might be turned off that is causing this"

 

 

This was your reply:

 

"Ok I went through the processess, and I found that when ending the process "krakensysaudiolauncher.exe" my coatl engine errors went away."

 

You did what I've suggested, AND IT WORKED! Nobody else reported that problem until then, which means I could only gave you a list of the KNOWN causes, up to that day. But of course, as anyone can see, I gave you a CORRECT suggestion to find a new, unknown, cause and, of course, it worked.

 

Then you asked this:

 

"I'd also like to know how to permanently shut this exe file down so I dont have to manually end the process tree every time."

 

And I replied with:

 

"use the MSCONFIG tool that comes with Windows, in the "Start-up" section there's a list of all the executables that Windows launches automatically, just uncheck that one and reboot."

 

You replied with:

 

"Thanks :biggrin: "

 

Now, how that discussion could ever translate into "I'm quite picky about service, and I'm very wary about being patronized", it's really beyond me...

 

 

 

Of course it wasn't. It was caused by another program which for some reason uses a very invasive global hook on all executables.

 

 

A fair behavior would have been, going to Razer support forum and asking: "why your executable causes problems to another software that runs normally if I shut down your executable" ?

 

Since they made it, it's possible they could explain this and, perhaps, like in case of Radeon Pro or the ATI Tray Tools, is NOT required to renounce using those products altogether, but it's enough finding which specific OPTION causes this so no, it's likely you won't have to stop using your headset.

 

 

 

Quite the opposite: you have been given the precise, exact suggestion that enabled you to find the problem and solve it, which was to check all your running processes and proceed by exclusion until you eventually find the culprit. Which is the only possible way of finding a new problematic software that will be added to the list of the KNOWN causes.

 

And of course, since you were the FIRST one to report it, the problem is not "unknown" anymore so, another user that reported this issue after your first report:

 

http://www.fsdreamteam.com/forum/index.php/topic,9809.0.html

 

Got the "The krakensysaudiolauncher.exe from the Razer Kraken headset drivers" answer, which is now a known cause of that problem.

 

If you would eventually find if there's an OPTION in the krakensysaudiolauncher.exe file that could be changed, so you can still use it, it would be useful if you could report it on our forum, as this user did:

 

http://www.fsdreamteam.com/forum/index.php/topic,8941.msg71935.html#msg71935

 

Thanks to his reports, we can simply tell "do not use API monitoring settings inside RadeonPro", instead of just saying "Don't use RadeonPro"

 

The problem isnt fixed aka your software is inhibiting other parts of my system.

You expect me to fix it, or to be a middle man between you and Razor.

If you are just a one-man business I can understand the tone of your reply. To me it sounds like you are putting me, the customer, in a bad light. I cant understand how this is good for business?

 

This sums up your attitude:

"since the problem is *surely* caused by another program, you only need to find which one is."

 

From my perspective it is a problem that your program has problems with other programs which you leave me to find out a) which one it is and B) how to live without it.

 

And albeit it is true that the patronizing tendency wasnt very strong in that thread, I was wary of it, and I noticed other people complaining about being met in a patronicing way before I made my thread. I tried to be as pleasant as I could to avoid being met this way.

 

I wasnt going to say anything more about it untill I saw this thread and felt like sharing my experience and my after thoughts.

The problem isnt fixed aka your software is inhibiting other parts of my system.

It's the Razer software which is inhibiting another software you use (Couatl), it's important not to lose sight who's affecting what. It's Couatl that will stop working because of that program, NOT that one stop working because of Couatl.

 

I understand that, from your point of view, it still means "I can't use them together", but this means there might be things you can try (for example, checking the options) on THAT other program, just like the issues with Radeon Pro, which can be fixed by turning off a specific option, without losing the use of that utility.

 

"You expect me to fix it, or to be a middle man between you and Razer."

 

You are BOTH user or the Razer software and our software. You surely have reported the issue to us, and we came out with a solution, but have you reported it to Razer too ?

 

"If you are just a one-man business I can understand the tone of your reply. I end up sounding how wrong I am"

 

From the point of view of user support, yes, I'm alone, but I haven't developed Couatl myself, not the whole of GSX (which is a team effort), and be sure that everything found is being reported to Couatl developers.

 

This sums up your attitude:

"since the problem is *surely* caused by another program, you only need to find which one is."

That's the only correct answer I could gave, since your case wasn't included in the KNOWN causes of the problem.

 

There are literally tens of thousands PC software out there, you just can't expect we could test them all, since you *have* that software installed, is clearly easier for you to scroll through 10-20 entries in the Task Manager, than for us to test thousands of 3rd party software, especially in this case: a software that can be tested only by using it with the related hardware.

 

From my perspective it is a problem that your program has problems with other programs which you leave me to find out a) which one it is and B) how to live without it.

The same could be said if you were addressing Razer support team. Have you contact them ? If yes, which was their answer ? If not, why ?

 

I wasn't going to say anything more about it until I saw this thread and felt like sharing my experience and my after thoughts.

The issue is, you described your experience in a way that, if I hadn't posted how *really* the discussion went on and how it ended, someone reading just your report could really believe that there's some patronizing going on in our forum, which obviously wasn't the case.

 

It's really frustrating when you close a case (you ended it with a Thanks + Smiley, for God's sake!) believing you did everything right and the user seemed to be satisfied, and it turns out he had a completely different perception, or at least decided to share it that way.

 

I can only attribute this to the long standing issue that written words usually sound more harsh/definitive, and the communication on forums usually end up in greater chances of flame wars, because of the lack of the enhanced communication due to body language, tone, expression, etc.

The problem isnt fixed aka your software is inhibiting other parts of my system.

 

You expect me to fix it, or to be a middle man between you and Razor.

 

If you are just a one-man business I can understand the tone of your reply. To me it sounds like you are putting me, the customer, in a bad light. I cant understand how this is good for business?

 

 

This sums up your attitude:

 

"since the problem is *surely* caused by another program, you only need to find which one is."

 

From my perspective it is a problem that your program has problems with other programs which you leave me to find out a) which one it is and B) how to live without it.

 

And albeit it is true that the patronizing tendency wasnt very strong in that thread, I was wary of it, and I noticed other people complaining about being met in a patronicing way before I made my thread. I tried to be as pleasant as I could to avoid being met this way.

 

I wasnt going to say anything more about it untill I saw this thread and felt like sharing my experience and my after thoughts

 

I can't see how it's at all fair to expect any software developer to take responsibility for another piece of software hooking into his code and rendering things unstable.  For example, as an analog, there have been a few beta versions of FSUIPC along the way, a program that hooks into FSX to do all manner of amazing things, that have crashed FSX or other add-ons--it was never Microsoft's problem to fix that, it was Pete Dowson's issue because he wrote the code that hooked into an otherwise-stable FSX and caused a problem.

 

When you put the invasive Razer software on your PC, you have to take some responsibility for things as well--you are not the "middle man," you are the guy ultimately responsible for loading an invasive, incompatible piece of software on the machine.  If that Razer software also causes problems with iTunes, you're not going to find Apple taking responsibility for fixing the problem Razer caused, either.  I've had to uninstall a number of software packages over the years because they behaved as if they were the only or the most important program on the machine, everything else be damned.  It sounds like the Razer software is behaving similarly.

 

Regards

Hmm thanks for your reply, Umberto. In the end there you have a reconciling tone which I appreciate.

 

No I havent contacted Razor yet. On that topic: Have you? I would expect you to be just as interested in finding out why there is a conflict between your IP's. It must feel unfair to you that I expect you to do this, and not ask me to do it. Maybe I expect too much for the money I paid. However, your suggestion would have me running back and forth between your companies which your replies.

 

 

And you are quite right. I ended up saying thanks with a smiley when I infact was expecting more service from you. It was not very clear, and I can see how that would make you think "case close". I was in fact expecting you to update me with how you solved this issue. I can probably attribute my ending post with culture and having a silent expectancy of you continuing to investigate and fixing it. Since then nothing more has happened.

 

You ask me to contact razor. I see now that I probably will have to do that to get any where with this. But that's the problem: It's just MY problem. It isnt YOUR problem.

I find that annoying in any company.

Once again it is too bad that a developer has to publicly put up with some of this nonsense over and over again. 

I hope some who are on the other side of what I'm about to say consider this in the spirit it's offered... 

 

Time and time again, developers are encouraged to think outside the FSX box...  And then are criticized for doing so, when their efforts aren't flawless.

 

If what couatl brings to the table isn't worth what you, as the customer and end user believe the tradeoffs to be, then by all means vote with your $$.  I get that, agree with it and support it.  What I have a hard time understanding and supporting in this case is the "you're not listening" claim.  Listening is two way, and expecting a developer to change the core of how their software operates  - their key competitive advantage - based on criticisms that have been directly addressed and explained does not seem very two way.

 

I appreciate the time that Umberto has taken to respond to these criticisms with logic and clear explanations and I appreciate the opportunity that gives all of us to decide for ourselves whether the explanations have merit or not.  That he has taken the time and effort to respond in such detail speaks volumes to me, as does his knowledge, his logic and my own experience.

 

As for the longevity of this thread, consider that the title itself is a magnet.

 

Scott

Interesting...

 

I only have GEX from them and it works great. I've never had a problem with the in-FSX Couatl updates or with the addon manager from the site.

Airports and GEX all run flawlessly on my system along with 1st class support they get my vote anytime