No disrespect, but the complexity and length of Umberto's post, reflects the (some feel unnecessary) complexity involved with the use of AM / Couatl.

 

I'm honestly surprised you said this.  Being that 99.9% of scenery users have no idea as to the complexity of software modeling and design it takes to make a scenery such as FSDT (including myself), as well as creating such pieces of software to get around the limitations of FSX - I'm quite shocked as to your reply or what you expect a developer to say to this.

 

People complain that they need support for various issues on a product they purchased and then complain when the support answer they get was too lengthy.... who knew.

 

I agree, Umberto, you aren't going to make everyone happy and at some point you have to cut your losses.  It's a lose-lose position when people will never understand (nor care) to understand the importance the various pieces are to the puzzle; and simply write off the entire package because they begin to make assumptions as to what is needed and what is not - when in fact they have absolutely no idea.  Thank you for coming over to the "other side" in an attempt to help customers, though.

Sadly, this debate ALWAYS ends the same way:-(

 

Sorry Umberto, but there are other scenery devs that make surpurb addons WITHOUT using such software.

Hi Umberto:

 

I'm not about to join the fray here - only to ask that you do not allow the forum tone to affect your creative, artistic and programming skills - nor your professional demeanour when managing consumer issues. These will always be present, regardless of application complexity.

 

Many thank you for your courageous responses, but - in your own words - "It seems there's no way out of this." 

 

All the Best,

 

Paul J

+++1

 

Best regards,

Jim

Perhaps when Steve's shader fix is available, FSDT can abandon their own DX10 processes and have enough "headroom?" in FSX default files to eliminate the Coatl application.

I don't own any Fligthbeam or FSDT software. However, as a potential customer following this thread, the developer has posted 3 lengthy responses but has not addressed the main complaint. I understand that couatl needs to run for the scenery to work, but why does the addon manager software need to be running its update and DRM processes within FSX while you are flying? Why can't this be done manually when FSX is shut down like most other addon software?

 

The other thing that concerns me is that I have read that the couatl/addon manager puts up pop-up messages about updates, etc. while you are flying. Is this true?  I don't want any addon software doing this, especially while I am on a difficult IFR approach.

 

Ted

 

 

There's no need to do that. ALL our products are 100% UAC compliant.

 

Thank you for your input Umberto, however my suggestion to "Run As Administrator" seems to have solved the issues I was having with your product.  Maybe it'll work for others, maybe not.

 

I just successfully ran a "Live Update" without a hitch and verified all my airports under Virtuali are working.  So something is working now that was not working before, the only change was "Run As Administrator" setting for Couatl.exe and for Couatl_Updater.exe.

 

I'm happy I got it working, because like most of us have said, the content provided is excellent.  I hope this will work for others.

 

Rob.

I don't own any Fligthbeam or FSDT software. However, as a potential customer following this thread, the developer has posted 3 lengthy responses but has not addressed the main complaint. I understand that couatl needs to run for the scenery to work, but why does the addon manager software need to be running its update and DRM processes within FSX while you are flying? Why can't this be done manually when FSX is shut down like most other addon software?

 

The other thing that concerns me is that I have read that the couatl/addon manager puts up pop-up messages about updates, etc. while you are flying. Is this true?  I don't want any addon software doing this, especially while I am on a difficult IFR approach.

 

Ted

 

 

The only update notices I have ever seen appeared when first launching a flight (clicking the "Fly now" button, I think it's called)...never in the midst of a flight. I've never had an approach interrupted by a pop-up of any kind.

 

I own and have installed 2 Flightbeam airports, 12 FSDT airports and GSX.

Glad to hear that. Thanks Wayne.

Sadly, this debate ALWAYS ends the same way:-(

 

Sorry Umberto, but there are other scenery devs that make surpurb addons WITHOUT using such software.

 

Hi Phil, 

 

This is of course, a double edged sword. Scenery and addon developers are mostly all in touch by email. I can assure you, that most other devs are currently having nightmares with their products on torrent sites, being wildly distributed with no regards to the hard work the dev has put in. It has shut down many smaller devs.

 

While it's relatively a lose-lose situation either way, by not allowing piracy, it *does* allow developers to create content much faster and better quality. 

 

Of course, there are always ways to make it less intrusive. This is something that can always be improved. (and has been). 

 

Cheers,

As much as I love FSDT's products I definitely hate when couatl gives me problems. I reformatted my computer in anticipation for the PMDG 777 a couple of weeks ago and for some reason when I went to deactivate/activate all my products I kept getting esellerate errors. I posted on the forum and I was told it was my computer and I should disable a whole bunch of things even though other people I know where having the same exact issue.

I had the same problem,and support always blames the user, so I just ate the dollars and kicked their FSDTKDFW to the curb.

As much as I love FSDT's products I definitely hate when couatl gives me problems. I reformatted my computer in anticipation for the PMDG 777 a couple of weeks ago and for some reason when I went to deactivate/activate all my products I kept getting esellerate errors. I posted on the forum and I was told it was my computer and I should disable a whole bunch of things even though other people I know where having the same exact issue.

I had the same problem,and support always blames the user, so I just ate the dollars and kicked their FSDTKDFW to the curb.

if anyone who is having issues with Couatl and also has Trillian instant messenger, make sure ingame chat is turned off within trillian preferences, it doesn't work with couatl. Don't know if anyone here has trillian, just figured I'd throw it out there just incase.

 

Other than that, I've had no issues whatsoever with Couatl or AM They work flawless for me.

I'm honestly surprised you said this.  Being that 99.9% of scenery users have no idea as to the complexity of software modeling and design it takes to make a scenery such as FSDT (including myself), as well as creating such pieces of software to get around the limitations of FSX - I'm quite shocked as to your reply or what you expect a developer to say to this.

I personally can't seen any issue with responing to a lengthy post by saying that the length of the post is indicative that a process has, itself, become too complex. (In this case the AM and Couatl implementations for FSDT scenery).

 

How on Earth can such a flatline response "shock" you? It's a big bad, world out there.....

 

And to Umberto - the same message really. I am sorry that my saying that your post was lengthy and that that was indicative perhaps that the AM/Couatl implementations were too complex "hurt" you.... but again, I really cannot understand how such a comment could hurt anyone.

 

I made it very clear in my post that I appreciated the talent and specialism involved in scenery design... go read it.. I said that very clearly.

 

But I end on a completely objective point; how come other scenery developers manage to vend products without the need for a 'software' deck to sit, integrated into FSX? ...... I don't see any posts anywhere highlighting any weaknesses in sceneries from vendors that do not use AM or Couatl.

 

Choosing to integrate a complex system into FSX in order for your sceneries to work was a design choice surely?... I wholly appreciate that it was probably done in order to offer innovative and additional features..... but the feedback on offer here is that the negatives of Couatl outweigh the positives. That is not everyone's view, but that is the view of the majority of people who have posted in this thread.

 

Thanks.

Perhaps when Steve's shader fix is available, FSDT can abandon their own DX10 processes and have enough "headroom?" in FSX default files to eliminate the Coatl application.

 

Being DX10 compatible, is just *one* of the reason why we use the Addon Manager/Couatl, but there are many others, like everything related to interactivity in sceneries, like reacting to conditions like weather, visibility, temperature, and display objects in different states or different objects altogether.

 

The issue is, we do so many things in sceneries using Couatl Python scripts, that sometimes I even forgot some...the intelligent runway light systems such as RWSL

 

http://rwsl.ll.mit.edu/index.html

 

The advanced PAPI/FAROS system, the THL lights, they all work as supposed to do, and interact both with the user airplane AND the AI, the lights will turn on/off to alert of a potential runway incursion, just like the real life system . None of this is possible with "just" the traditional .BGL format, we need to use Simconnect (heavily), we need to control the AIs, we need to control our own object creations.  All of this, of course, is courtesy of Couatl.

 

We also used a memory-saving technique in JFK and CYVR, that patches the scenery in real time when the season switches, to have seasonal texture changes, without having to load a more complex object that contains all seasons. Again, done with Couatl, with a Python script.

 

We have a complete astronomical ephemeris calculator running, to calc the actual sun position at every date/time/place on the Earth, in order to display objects with dynamic shadows that change over the day, without ANY fps impact (compared to FSX default shadows), because all the transitions are pre-rendered, and both the calculation AND the actual object switching is made by, you guessed it, by a Python script running under Couatl.

 

A silly (nice) feature: an user told me that during summer 2011, the roof of the main terminal at PHOG was repainted from red to green. So (why not?) we have a feature that, if you set the date before August 2011, the terminal will have a red roof, otherwise it will be green. Again, not wasting any memory to keep two object loaded, so both the object switching and the check for the date is made, I think you guessed it already, with a Pyhton script running under Couatl.

 

There's a real-time clock on the old Control Tower at PHNL, which shows the current time and temperature, taken from the sim. Done by, you named it, a Pyhton script running under Couatl.

 

Those are just example on why a "simple" product like a scenery, might need scripting to offer interaction, either for small things like clocks, but also for serious AVIATION-related features with an high simulation value, such as the RWSL/THL/FAROS systems, as used at real world KDFW, KLAX.

 

But even if it was JUST DX10, one thing is just being "compatible" with it, like not having visible bugs or being able to use the scenery at night even if it use FS8 ground polygons, which is something that might be fixed with the DX10 "fixes", an entirely different thing is getting advantage of it, by modeling ground polygons that can use shaders, which is not possible with plain .BGL, so we need to control the object creation and visibility parameters in real-time, to overcome visual problems that would appear if the ground was "just" compiled with the FSX SDK, which is the prerequisite to allow use of shaders to begin with.

 

Even if the DX10 fixes would allow a scenery made with FS8 ground polygons will display properly under DX10, it will still look like an FS8/9 scenery, things like variable bump maps, shader-based (=faster) detail textures and specular reflection, would not possible if the scenery has not be designed for that, and we need the our modules to allow that.

Some of those features are amazingly innovative.

 

"astronomical ephemeris calculator running, to calc the actual sun position at every date/time/place on the Earth, in order to display objects with dynamic shadows that change over the day".

 

No-one can argue that that is not extremely innovative.  However my own view is that I do not need that level of complexity in my sceneries, if it required them to use an engine like Couatl (python).   I would personally rather have the elements of FSDT sceneries that are stunning in their own right, and that do not require Couatl.   Eg...   FlyTampa and Orbx sceneries do not use anything comparable to an engine like Couatl, and they are beautiful enough for me.

 

FSDT sceneries are too, but the features that you've listed that require Couatl, are not important to me, and I would rather not have those features and not have Couatl.

 

Some will agree with me there, others will of course strongly disagree.

 

I hope this works out positively.    I hope a solution is found to what is a very frustrating and complex problem for all concerned.  With that, I'll leave this debate alone now.  It probably has run it's course.

I personally can't seen any issue with responing to a lengthy post by saying that the length of the post is indicative that a process has, itself, become too complex. (In this case the AM and Couatl implementations for FSDT scenery).

 

Because they don't necessarily have any correlation.  Likewise, many simple issues can be also be described in complex detail.

 

If only life's complex philosophies could be solved with a single sentence!

 

I agree - this is going nowhere fast.  Thanks for your participation, Mir and Umberto.