Jump to content

Daniel Neugebauer

Members
  • Content Count

    34
  • Joined

  • Last visited

  • Days Won

    2

Daniel Neugebauer last won the day on May 15

Daniel Neugebauer had the most liked content!

Community Reputation

17 Good

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Release 0.90 of the legacy proxy is now available: Searching coordinates using VAT-Spy works completely offline and without having to install VAT-Spy (the database is included within the proxy application itself). Having controller coordinates means that QuteScoop is now able to display labels for center sectors again. The configuration dialog provides several options to fine-tune the search. Those options are explained in the user manual which was split from the readme file for better readability. The Station Locator feature was supposed to offer an option to also use the list of
  2. The upcoming changes to the network protocol actually really require a deprecation of all unmaintained clients. This was communicated back in March: I'd like to point out that the deprecation of legacy pilot & ATC clients has absolutely nothing to do with the data feed discussed in this thread: The data feed we are talking about here is just a regularly server-side generated dump of the current network state and can be accessed without any login or pilot client via a web URL, it does not allow you to actively connect and participate with the network, it is just used to display g
  3. Airport != Center/Radar/Area Control (aka FIR/UIR sectors) While there are many databases on the Internet providing airport coordinates there are very few that will give you meaningful FIR/UIR information, especially in regards to VATSIM. As I've written above, the VAT-Spy database seems to be the easiest available and also the best (quality-wise) choice if you make some adjustments to the callsign lookup as compared to the actual VAT-Spy program. And if you want you do not only get center coordinates but also sector outlines - way more information than what is available from just perform
  4. Just as an addendum if you use Qutescoop: I missed that it disables the "ATC bookings" option when you switch from VATSIM to "user defined network". If you are missing bookings please make sure to re-enable that option. The setup instructions on GitHub have already been amended.
  5. I noticed that a list of all online transceivers has been added to the public API by finding the documentation in the same place as for the JSON data feed: https://api.vatsim.dev/#operation/TransceiverData Using this data could help to solve the issue of station coordinates missing in the JSON v3 data feed. Unfortunately, I cannot find any policy like minimum fetch intervals regarding the transceivers list (such policies had been attached to the old data feed). Is that transceivers list supposed to be treated in the same way as the data feed?
  6. What about the transceiver "API"? I don't know if there are any policies attached to it (fetch intervals etc.) but I would assume that it can be used as part of a workaround to locate stations because the "API" has been made public. Other than that, VAT-Spy data seems to have an acceptable data quality (some sectors are outdated or not recorded properly, but most seem to make sense). I get good results by matching callsigns from long (more precise) to short (less precise) - which is not what VAT-Spy currently does but it seems to already be on Ross' todo list. I index all FIRs, then UIRs
  7. If using the proxy is an acceptable interim solution until you find a new developer to properly migrate your software, it is possible to run the proxy on a server as well (the proxy's GUI is optional, it works from CLI). After starting the proxy the URL in your existing PIREP software needs to be changed from http://status.vatsim.net/ to (by default) http://localhost:8080/ and of course you need to test if everything works. This should be a very quick change, maybe the previous developer can have a look at it. Please make absolutely sure that access to the proxy server is blocked by a pa
  8. That's fine for me, thanks! :) Is there any easy-to-follow place where changes to the data feed are publicly announced? I only stumbled upon those changes by looking at the raw JSON yesterday and wondering myself if I missed the flightplan's revision_id earlier. There was no mention on Tech Blog Q1 either. I don't follow these forums regularly so if there was some announcement maybe I just missed it. What about the not yet documented revision_id in particular? Are you able to already tell if it is going to stay permanently?
  9. Thanks, I really wasn't sure how to read your comment earlier. :) I agree that the proxy is (very obviously) not recommended but it may still currently be the best option for web developers who were unaware of that change until yesterday to quickly restore their service while working on a proper migration. It may also be the only option for users who cannot actively contribute to migration efforts of their favorite desktop applications while they wait for an update. For a developer, using JSON has some very clear advantages over the old format and is much better to extend. I am very
  10. Please clarify if that is just your personal opinion or an official statement from VATSIM staff prohibiting use of that solution.
  11. @Alexandra Robison That's why I waited with publishing the code on GitHub until the announced termination date and only announced it on a larger scale today after the termination had actually happened. The proxy is just a workaround and not a permanent solution. Such a proxy is inconvenient by nature. I don't believe any sane developer will rely on it for any longer than absolutely necessary and I made it very clear that the main goal should remain to migrate the original applications affected by the format change. Users (and maybe even webservice operators) however don't have a choice and may
  12. I just released version 0.80.2 which should now be compatible with ServInfo. There are two different options to configure ServInfo to use the proxy, see https://github.com/dneuge/legacy-status-proxy-vatsim/discussions/3
  13. I just tried it myself and in theory it should work (manipulate the VATSIM.loc file manually; do not configure the legacy proxy as a proxy server in ServInfo). However, ServInfo appears to get stuck while downloading the file? Edit: It seems that ServInfo requires the connection to be closed after each transfer. I will change the connection reuse policy on the proxy server accordingly. In addition to .ini/.loc file manipulation ServInfo will be able to connect by simply configuring the proxy URL as a custom network. Note that I am not sure how useful ServInfo will be without some kind of
  14. It seems like there are two workarounds to estimate a controller position: Known stations could be looked up from https://github.com/vatsimnetwork/vatspy-data-project. Unknown stations could be estimated by their transceivers - it appears that transceivers are now public as they are listed in the API docs: https://api.vatsim.dev/#operation/TransceiverData Since controllers usually provide service by voice most unknown stations should be locatable this way. I'm a bit unsure about the details of that file, though... It seems like it has not been mentioned in these forums before and the
×
×
  • Create New...