Talk:Traffic alert and collision avoidance system

instruments vs. displays - tcas vs. wxradar

You are right, and that's the most valid and most informed objection that I have seen so far. However, keep in mind that the wxradar article is just an empty placeholder at the moment. So, the MVC separation that you are referring to here, isn't done currently for the wiki article.

In fact, the "display" part of the TCAS is specifically referred to in the main TCAS article: http://wiki.flightgear.org/Traffic_alert_and_collision_avoidance_system#TCAS_display

So, I am fully aware of the difference between instruments and displays - we just don't have a separate wxradar article at the moment... --Hooray 14:15, 9 October 2012 (EDT)

I have invested lots of time to create the TCAS module. The wxradar extension to display traffic was a tiny part of the work. I wrote the wiki article since I hoped people would use the instrument. It doesn't really help if you keep sticking warning notices everywhere "Most of the stuff here is deprecated", basically voiding all the work and telling people not to use it - just because _you_ think that Nasal and Canvas is the one and only way ahead. Neither is it something motivating me to invest any more time into FG. When there is any other ready-to-use module available, which aircraft developers can immediately use to display TCAS traffic, then this page can well be extended. Until then, while there is no alternative available, I don't seen any reason to why people should be told to stop using it. So, I do *not* want the page to be changed with any such suggestions.

-ThorstenB 14:39, 9 October 2012 (EDT)

I don't know if you are aware of it or not, but we have actually started working on a dedicated map.nas module a couple of weeks ago, some of this has been recently committed to fgdata, other work isn't yet included, and more is yet to be done. In other words, yes, there are additional layers and implementations in progress - including a more generic tcas module (view/display). The point was not to stop people from using existing stuff or keep them from improving it (please see the exact wording of the template, which is obviously open to improvements). Rather, the whole point is to make other contributors aware of related efforts that are actively being developed currently, so that we can hopefully work out a way to improve collaboration and avoid redundant/wasted work. This is exactly to prevent people from working on features in isolation, only to learn later on that there are competing or possibly even conflicting approaches being implemented that may need to be discarded sooner or later. I fully realize and do agree that this in particular is not particlarly motivating, especially once we are talking about "throwing away" code. However, that doesn't just involve work like your TCAS/WXRADAR instrument/display, it also involves other existing features, such as ATC-FS, the Map dialog or the NavDisplay and lots of other stuff that other contributors and/or core developers have worked on. You make this sound like I am the main driving force behind all of this, which is far from the truth - in fact, I don't believe that the Canvas is the perfect solution for all our needs, and it wasn't my idea at all. However, there have been talks on the devel list, and a number of people have discussed the options available, and there is a consensus to re-implement certain existing features to unify the 2D rendering backend, so that better modularization and code re-use can be implemented. Now, regarding the wxradar display in particular, it has not been able to display LW clouds for a long time for example, re-implementing this feature (even for the LW/AW system) using the Canvas/Nasal was fairly trivial actually. So, yes - I'm a little surprised that people who are not actively maintaining a particular module are opposed to seeing it augmented or re-implemented using a new system, even though I am not particularly referring to the wxradar display here. Defending our own contributions is obviously fine and encouraged, but we shouldn't be thinking in terms of code (LoC), but rather in terms of features. --Hooray 15:04, 9 October 2012 (EDT)