5H1N0B1 wrote in Sat Feb 01, 2014 7:06 pm:So I still have the VOR displayed. How, with an arrray[] can I feed this Canvas to display (with same picture for begining) the plot spotted by the radar ?
For info this array will be an array of "Target" object.
Once the previously outlined steps are working, I would consider customizing the searchCmd in your lcontroller file.
At the moment, TFC.lcontoller works like this
https://gitorious.org/fg/fgdata/source/ ... roller#L90- get a list of AI and MP traffic (two vectors)
- foreach list of AI and MP traffic
- determine if each aircraft is within the range specified via in_range: https://gitorious.org/fg/fgdata/source/ ... roller#L50
- **** PLACEHOLDER ***
- if it is in range, the aircraft will be appended to the result vector
- the result vector will be returned, and later on used to call the draw/update routines in the *.symbol file (e.g. TRAFFIC.symbol)
The line where I added PLACEHOLDER is where you could insert your own logic, i.e. the radar-specific stuff from xiii's code - such as checking distance, azimuth, altitude - radar profile/signature, terrain etc - and only append the aircraft if the whole check evaluates to true.
You will find that the whole lcontroller file uses a wrapper called "TrafficModel" - you can either extend this to use your "Target" class directly, or change your Target class accordingly.
The main thing is that your class should be derived from a geo.Coord object, so that it has the lat/lon/alt methods available and can be directly processed by MapStructure without requiring further changes.
You will see that the TrafficModel class is used in a few places - so this would need some changes if you use some different approach, but it's still simple.
The external interface is all about having lat/lon/alt (positions) and the .equals() method
Overall, TrafficModel is just a dumb helper class that is a wrapper for geo.Coord() objects, so there's no reason why you shouldn't be able to extend your own Target class accordingly, you can use the TrafficModel as a template. I would just suggest to maintain the MVC separation at all times.
Analogous to the in_range() helper, you could add other functions for your own filtering needs (altitude, terrain-obstruction etc) - it's better to use separate functions for each, than inflating a single function unnecessarily. As you can see, the in_range() function is unaware of TrafficModel specifics -it deals directly with lat/lon pairs..
So it's simple to reuse as is.
TrafficModel itself is typically directly used via the constructor call: .new()
There's now a separate article detaliing all the steps outlined above, to provide a dedicated place for people interested in this - or even in getting involved, but also to document the whole effort:
http://wiki.flightgear.org/Canvas_RadarI have also extended the "demo" in the MapStructure article, so that it now contains a button to reload the dialog from disk, for more rapid prototyping - without having to exit/restart FG.