New Atc Client For Mac
Hello everybody, I have been working on a new ATC software program for FlightGear since October, and would now like to announce its beta-testing phase. After sharing it with a couple and collecting a few opinions in December, I think it is ready for controllers to try out if they are ready to face a few bugs for the cause of free software development. If you are a regular ATC or have good aviation background and wish to test it, you are welcome to contact me for more details. A short description of its philosophy and features are described on the new wiki page I have just created at.
See you all and fly safe. CaptB wrote in:What data do you refer to here: General/data retrieved from the latest X-Plane file set? I am talking about this data: (I'll add a link from the wiki page) You almost got me doubt it was legal but I did remember right: this data is GPL and already used by FlightGear itself, which made me think we would not have too much differences between pilot scenery and ATC-pie radars. A quick search on the forum also gives you this: Perhaps scenery people in the FG community have been building on top of it and adding differences that may cause trouble, but that will need to be reported. I have noted several differences and outdates with real life experience and charts (frequencies, TWYs, RWY names.) but every one I found was also present in the standard FG sim set up (pilot view).
New Atc Client For Mac Pro
The data is from 2010, and any new update can easily replace the old one, unless they change the spec, then I'll have to change the code. But honestly, I was verrrrry happy when I figured I could be able to draw every airport in the world for every ATC to control his favourite place.
With comparatively little effort. Also, in the case of missing taxiways or such, X-plane is apparently an active community, so any airport file can be contributed to. But I don't know the process. Many people will, and that's better discussed in the scenery-related forums I assume. Posts: 394 Joined: Tue Sep 24, 2013 9:12 am. The X-Plane database is not accurate, I control Denmark on VATSIM and I am very familiar with the published Danish AIP and I can tell you that X-Plane pilots that use this database are unable to fly many significant waypoints, especially in Copenhagen Area ( the CTA ) where there are many waypoints spicific for SIDs/STARs missing. OpenRadar allows for introducing missing waypoints and navaids and I have been introducing those gradually to be able to control realistically on mpserver if the pilot requests it.
Will ATC-Pie also allow adding custom nav data? However, to be fair: Note that not even OpenRadar was the first ATC solution available for FlightGear - so far, it just happens to be the most-developed solution that is fairly well integrated in the FlightGear eco-system, while also having top-notch support and a very responsive developer who also happens to be a regular forum user. So it will admittedly be hard for a competing project to get up to scratch with the degree of functionality offered by OpenRadar - and we've seen other ATC related efforts getting stalled because of these reasons. Then again, there are also certain issues - such as requiring a Java JRE, which raises the bar to entry/usage. Equally, python is also adding a few dependencies.
Competition and conflicting developments are happening regularly in the FlightGear community (just see the recent GUI debate we've had) - but competition can be a healthy thing - even though it would obviously make sense for people working on overlapping projects to get in touch early, and try to find a way to collaborate at least to a certain degree - e.g. By mutually supporting file formats/protocols etc. In summary, we've seen quite a few people who were originally opposed to OR and its Java overhead/nature - these day, OR is obviously an excellent choice for people wanting ATC+FlightGear. Equally, the scripted weather system that Thorsten came up with using Nasal has meanwhile become superior to anything we've had to date. So competition and having alternative isn't generally a bad thing - had Thorsten been required to implement the whole thing C, we probably wouldn't have LW/AW these days. Lydiot wrote: So I'd love to see why I'd pick this over OR.
There will never be anything from me listing reasons to choose over another program. I'll just be delighted if you try it.
Incidently, it is the best way for you to answer your own question as well. I did list some features on the wiki page, but that will not give you the feel of it. A couple of people have tried and sent me their feedback, and may post it here.
Obviously no point in bug reports in this thread, but discussion on the philosophy, look&feel, etc. May get you some idea, and me some material for improvement. About the rest, I have indeed been working with O-R's current developer Wolfram, in the past to improve it in different ways (which I wish to keep doing), and since I have started this project, always to ensure cross-program inter-operation. For instance, one thing I have started working on is strip exchange and ATC coordination, a substantial part of the ATC task which thanks to O-R people have been enjoying for about a year. No doubt the best example of where cooperation is needed (and in this case happening) between developers.
Given how little populated our network still is, it would honestly make no sense to start dividing it. Posts: 394 Joined: Tue Sep 24, 2013 9:12 am. Sanhozay wrote in:Is it your intention to use the same XML file format for SID and STAR annotations?
Email Clients For Mac
People including myself have been working on those route files, sometimes spending hours, and I don't expect anyone to write that kind of stuff all over again (see wish list). So of course I'll work in such way that they remain usable, either straight from the files or sourcing from them and into some other format. But, I am still thinking about how best to address routes, and would love to come up with an original solution.
One thing I want to explore first is if I can retrieve route data somewhere just like I get airport layouts and navigation points without effort. There are other standards for routes, and a guy contacted me offering conversion scripts, so now the question is: what is the most lazy-user-friendly way to integrate the most routes, including those who have no route files ready. Ideas are welcome via private email, and I can open up a discussion page on the development wiki.
Unless you really want to have it here but topics might get messed up if all are thrown in this thread. Cheers, Micky. Posts: 394 Joined: Tue Sep 24, 2013 9:12 am. Routes/airways can be found in awy.dat , that can be downloaded from the. Side note: A few years ago I found that I could open the apt.dat, nav.dat and awy.dat files in QGIS and tried to make some kind of maps. Unlike in USA the maps here in Sweden are not free, and in addition a bought map is current, while the apt.dat and nav.dat files could not be expected to be current.
Making my own maps did not turn out that well due to the effort that would have been needed to make them look good enough, and in addition roughly half of Sweden was flat due to the SRTM data stopping at 60 deg N, so the main part of my flying have been in USA. Ideas are welcome via private email, and I can open up a discussion page on the development wiki. Unless you really want to have it here but topics might get messed up if all are thrown in this thread. I'd probably look at existing VATSIM/IVAO data (freely available) and write import/conversion routines for those formats to gather a sufficiently large set of routes (or even just ATC sectors). Equally, such data could be imported into some kind of database (think postgis) and be provided via a central web service for all ATC-pie/OpenRadar clients.