Legacy status proxy - Data-Feed-Kompatibilität für unmigrierte passive Clients

Der "Data Feed", der "passive" Clients (d.h. externe Tools, nicht Piloten-/ATC-Clients) mit Status-Informationen versorgt, wurde vor einigen Monaten auf ein neues JSON-basiertes Format umgestellt. In der Nacht zum 7. April 2021 wurde der alte Feed nun abgeschaltet, wodurch einige Clients nun nicht mehr funktionieren.

Um diese wieder zum Laufen zu bekommen müssten sie auf das neue Format migriert werden, was aber teilweise nicht so einfach möglich ist. Das folgende inoffizielle Tool kann verwendet werden, um vorübergehend eine Kompatibilität herzustellen:


Zum Ausführen des Proxies wird Java zwischen Version 8 und 11 benötigt. Falls keine passende Version installiert sein sollte könnt Ihr AdoptOpenJDK in Version 11 mit HotSpot-JVM verwenden.

Bitte lest Euch vor der Verwendung Disclaimer, known limitations und FAQ genau durch.

Einige Punkte möchte ich direkt hier nochmal betonen:

  • der Proxy ist nur als Übergangslösung gedacht - wer als Entwickler mithelfen kann, die betroffenen Tools ordentlich zu migrieren, sollte dort seine Hilfe anbieten
  • der Proxy sollte nur für "passive" Clients verwendet werden - Piloten- oder ATC-Clients benötigen ordentliche Updates um nicht gegen den CoC zu verstoßen
  • es wird nicht empfohlen den Proxy öffentlich zu betreiben, idealerweise sollte er auf jeden Rechner, auf dem eine Kompatibilität benötigt wird, jeweils nur lokal betrieben werden
  • die Positionen von Controllern wurden leider aus dem JSON-Datenformat entfernt, sodass sie auch bei Einsatz des Proxies fehlen - dadurch können unbekannte Stationen/Lufträume in Anwendungen wie QuteScoop nicht mehr angezeigt werden und verschwinden von der Karte
    • seit Version 0.90 fügt der Proxy ersatzweise aus der VAT-Spy-Datenbank ermittelte Koordinaten ein
    • seit Version 0.95 ermittelt der Proxy darüberhinaus fehlende Koordinaten anhand der Audio-for-VATSIM-Transceiver, sofern verfügbar

Ankündigung im englischen VATSIM-Hauptforum: https://forums.vatsim.net/topic/311...-to-passive-clients-not-migrated-to-json-yet/
 
Zuletzt bearbeitet:
Keine Ahnung, ob es dafür einen irgendwie zwingenden Grund gab. Fakt ist, dass aufgrunddessen viele Tools, die einem liebgewonnen bis notwendig geworden waren, nicht mehr funktionieren. Und so einen Proxy werde ich bei mir sicher nicht laufen lassen.
Für mich der Anlass, meinen IVAO-Account mal wieder zu aktivieren. Schade drum, aber wenn es so läuft, kann man nur jeweils die Nische suchen, in der man besser aufgehoben ist.
 
Die VATSIM-Infrastruktur musste und muss weiter an die aktuelle Technik angepasst werden. Das ist gut so und das will glaube ich auch keiner anders. Dass dann manchmal alte Zöpfe abgeschnitten werden, ist leider unausweichlich. Es sind halt noch viele Produkte im Umlauf, die seit Jahren/Jahrzehnten nicht mehr weiterentwickelt werden, sich aber immer noch großer Beliebtheit erfreuen. Vieles davon ist mitlerweile als Quellcode veröffentlicht, sodass man selber auch mithelfen kann, diese weiterzuentwickeln. Das ganze VATSIM-Universum lebt halt zu einem großen Teil von der Einbringung der Community. Du siehst das wohl ein wenig anders - deshalb viel Spaß im anderen Netzwerk.
 
Keine Ahnung, ob es dafür einen irgendwie zwingenden Grund gab. Fakt ist, dass aufgrunddessen viele Tools, die einem liebgewonnen bis notwendig geworden waren, nicht mehr funktionieren. Und so einen Proxy werde ich bei mir sicher nicht laufen lassen.
Für mich der Anlass, meinen IVAO-Account mal wieder zu aktivieren. Schade drum, aber wenn es so läuft, kann man nur jeweils die Nische suchen, in der man besser aufgehoben ist.
Hallo Rainer,

das wäre aber schade. VATSpy geht doch? Die aktuellste Version kann mit dem neuen JSON-Format umgehen. Und der Proxy ist kein Problem, läuft im Hintergrund und stört nicht.
 
Zunächst einmal: VIELEN DANK für dieses Tool!!

die Positionen von Controllern wurden leider aus dem JSON-Datenformat entfernt, sodass sie auch bei Einsatz des Proxies fehlen - dadurch können unbekannte Stationen/Lufträume in Anwendungen wie QuteScoop nicht mehr angezeigt werden und verschwinden von der Karte
Könntest Du die Stationen nicht aus der Datei firlist.dat auslesen, die immer unter C:\Users\<username>\AppData\Local\QuteScoop\QuteScoop\data zu finden ist?

Maastricht hat die Position des Name-Tag z.B. so definiert: EURM:Maastricht:NL:50.50:9.64:521
 
Hallo Rainer,

das wäre aber schade. VATSpy geht doch? Die aktuellste Version kann mit dem neuen JSON-Format umgehen. Und der Proxy ist kein Problem, läuft im Hintergrund und stört nicht.
Na, dann probier ich das nachher mal, gestern ging keines der Tools mehr bei mir, auch kein QuteScoop und VatMap auf dem iPad immer noch nicht (o.k., letzteres mag nun nicht so wichtig sein). Einen ATIS kann ich mir über Christoph Paulus‘ CPDLC-Tool auch nicht mehr ziehen.
Aber gut: Ich kann ja noch etwas zu basteln versuchen. Trotzdem: Die rüde Art, in der das durchgezogen wurde, finde ich schon irritierend. Und ja: Natürlich danke für das Tool, aber da muss man erstmal sehen, wie man die evtl. Sicherheitslücken da schließt (bin da nicht so der Fachmann).
EDIT: Ich kann bestätigen, dass VATSpy schon wieder funktioniert, also ich reg mich ja auch schon wieder ab 😉.
 
Zuletzt bearbeitet:
Hallo Rainer,

was genau meinst Du denn mit "Die rüde Art, in der das durchgezogen wurde, finde ich schon irritierend"?

Die Umstellung wurde vor Monaten angekündigt und wurde schon nach hinten verschoben. Der erste offizielle Abschalttermin war schon vor 2 oder 3 Monaten wenn ich mich da recht dran erinner.
 
@Rainer Jurczyk Parallel zu dieser Diskussion werden im folgenden Thread viele Alternativen vorgestellt. Vielleicht findest du dort eine passende für dich, die deinen Geschmack trifft bzw. deine Bedürfnisse erfüllen. Es wär ja schade wegen solch einer Kleinigkeit mit dem schönen Hobby aufzuhören :)

 
@Andreas Fuchs Erstmal willkommen zurück im Forum, schön Dich hier wieder zu sehen! :)

Für die Airspaces würde ich lieber die nun wohl offiziell bei VATSIM gepflegten und auch schon von anderen Tools angezogenen Daten von VAT-Spy verwenden, ich schau mir das gleich an. VATSIM verweist auch in seiner öffentlichen API direkt auf diese Daten, ich würde sie daher als die "verbindlich(st)e" und mutmaßlich vollständigste und aktuellste Quelle ansehen. Parsing/Datenverarbeitung ist dabei weniger das Problem als vielmehr die Frage wieviel Aufwand ins Drumherum des Proxies gesteckt wird (automatischer Download? automatische Updates?). Da der Proxy keine Dauerlösung sein sollte werde ich hier wahrscheinlich einfach voraussetzen, dass der Benutzer die nötigen Daten selbst herunterlädt. Theoretisch (die Lizenz gibt das her) könnte man die Daten auch mit dem Proxy zusammen ausliefern, dann müsste dieser aber min. zusammen mit den AIRAC-Zyklen jeweils aktualisiert werden - das bringt nicht wirklich Punkte.

Ohne es bisher selbst überprüft zu haben, aber die VAT-Spy-Daten sind laut Issue-Tracker (#267 und #261) für unsere VACC derzeit über alle RGs hinweg wohl veraltet oder fehlerhaft. Da wie gesagt auch andere Tools/Karten diese Datenquelle anziehen wäre es super, wenn die Nav-Departments ihre Sektoren dort updaten könnten. Vielleicht ist das sogar etwas das GNG in Zukunft automatisch exportieren könnte?
 
Hi Rainer,

wie von Kai erwähnt, wurde das nicht über Nacht gemacht. Ich persönlich finde es auch nicht optimal, dass VATSIM den klassischen Feed nicht weiter parallel anbietet, aber man hat sich so entschieden. VATSIM befindet sich seit etwa 2 Jahren ENDLICH in einer Phase der technischen Transformation, nachdem dies über 15+ Jahre fast komplett verschlafen wurde. Ein paar Opfer müssen wir also bringen, alte und liebgewonnene Programme müssen angepasst werden oder verlieren ihre Funktion. Zum Glück hat der Daniel hier diesen Proxy erstellt, der den neuen JSON-Feed auf dem jeweiligen PC in das klassische Format umwandelt und dann über eine interne IP-Adresse/Port im alten Format bereitstellt.

Du musst also nur den Proxy bei Dir installieren, starten, die Nutzungsbedingungen akzeptieren und dann in Qutescoop in den Einstellungen anstatt "VATSIM" die Option "user defined network" auswählen und die lokale Adresse eingeben, von der Qutescoop ab dann die Daten bezieht: http://localhost:8080/

Das war es schon.
 
Für die Airspaces würde ich lieber die nun wohl offiziell bei VATSIM gepflegten und auch schon von anderen Tools angezogenen Daten von VAT-Spy verwenden, ich schau mir das gleich an.
Wir updaten die Qutescoop Stammdaten regelmässig und nutzen die VATspy-Datenbank (Github) als Vorlage, ist also so gut wie immer up to date.

Für fast die ganze Welt sind die Luftraumdaten eigentlich gut bis sehr gut (=akkurat), nur in Deutschland hat leider niemand für EDGG die aktuellen Lufträume erstellt und bei Github hochgeladen. EDMM, EDWW, EDYY, EUC etc. sind alle korrekt im System drin.

Selbstverständlich ist es absolut Deine Entscheidung wieviel Aufwand Du in diese temporäre Lösung stecken willst - aus der Vergangenheit wissen wir, dass temporäre Lösungen oft lange angewandt wurden und werden. vpilot zum Beispiel! War nur als temporäre Lösung gedacht. Ok, Äpfel und Birnen vergleichen ist nicht fair!
 
RG Bremen - NAV
RG Bremen - Mentor
Die rüde Art, in der das durchgezogen wurde, finde ich schon irritierend.
Es gab monatelangen Vorlauf (nachdem man sich anfangs beschwert hat dass 3 wochen Vorlaufzeit zu kurz waren). Das ist in keinster Weise rüde und relativ Standard.
Das “wir müssen immer jedes Tool mitnehmen” ist mMn das, was die Entwicklung von VATSIM jahrelang behindert hat (136er Frequenzen zB). Es ist einfach an der Zeit, Tools die seit +- 9 Jahren (Qutescoop) keine grossartige (Weiter)Entwicklung mehr erhalten haben, endlich zu Grabe zu tragen.
 
Ok ok, vielleicht hab ich das ja auch nur verpennt, weil ich in letzter Zeit mangels derselben nicht dazu gekommen bin, das englische Forum mitzuverfolgen. Da wäre ein Warnhinweis hier schon sinnvoll gewesen (oder hab ich den vielleicht auch übersehen?).
Also wie gesagt, hab mich ja schon wieder abgeregt, jetzt bitte keine Grundsatzdiskussionen, davon gab es in der Vergangenheit eh schon zu viele. Dann ist es wie es ist und ich bin für meinen Teil auch schon dran, die verbleibenden Probleme in meinem System, so sie sich nicht noch von selbst durch Updates beheben, vielleicht auch ohne den Proxy zu umgehen.
 
Es ist einfach an der Zeit, Tools die seit +- 9 Jahren (Qutescoop) keine grossartige (Weiter)Entwicklung mehr erhalten haben, endlich zu Grabe zu tragen.
Voooooooooooorsicht, uffbasse! :D

Qutescoop hat in letzter Zeit doch einige Updates erhalten, um es am Leben zu halten, Totgesagte leben länger. Letztes Jahr wurde ziemlich viel Energie investiert um, a) die Lufträume zu aktualisieren (habe ich über Wochen hinweg fast komplett im Alleingang gemacht) und b) diverse Änderungen im Format auszugleichen. Hat doch geklappt! Jetzt muss halt jemand ran, der die Motivation und Fähigkeiten hat, auch diese Anpassung zu machen. Keiner verlangt, dass VATSIM sich nicht weiter entwickeln soll - es wäre allerdings keine Hexerei gewesen, den klassischen Feed weiter parallel zu betreiben, hätte keinem weh getan.

Qutescoop ist weiterhin ein cooles Guck-Programm, auch weil es die VATBOOK-Daten herunterladen und anzeigen kann. Wir reden nicht von ServInfo, welches wirklich schon in die Jahre gekommen und mangels Sourcecode nicht weiter entwickelt werden kann (der Entwickler ist vor einigen Jahren verstorben). Ausserdem gibt es ein direktes Pendant zu ServInfo, VATSpy.
 
Wir updaten die Qutescoop Stammdaten regelmässig und nutzen die VATspy-Datenbank (Github) als Vorlage, ist also so gut wie immer up to date.
Da man mehr Tools erreicht wäre es aus meiner Sicht vermutlich effizienter, die Daten zukünftig nur noch bei VATSpy zu pflegen und dann von dort automatisiert in das für QuteScoop nötige Format zu übertragen. Gibt es etwas das QuteScoop in seinen Sektordaten kennt, was VATSpy nicht unterstützt?
 
RG Bremen - NAV
RG Bremen - Mentor
Voooooooooooorsicht, uffbasse! :D

Qutescoop hat in letzter Zeit doch einige Updates erhalten, um es am Leben zu halten, Totgesagte leben länger. Letztes Jahr wurde ziemlich viel Energie investiert um, a) die Lufträume zu aktualisieren (habe ich über Wochen hinweg fast komplett im Alleingang gemacht) und b) diverse Änderungen im Format auszugleichen. Hat doch geklappt! Jetzt muss halt jemand ran, der die Motivation und Fähigkeiten hat, auch diese Anpassung zu machen. Keiner verlangt, dass VATSIM sich nicht weiter entwickeln soll - es wäre allerdings keine Hexerei gewesen, den klassischen Feed weiter parallel zu betreiben, hätte keinem weh getan.
Als derjenige der letztes Jahr den Fix für Qutescoop geschrieben hat als das Datenformat wechselte weiss ich davon natürlich, allerdings: Datenupdates sind keine Weiterentwicklung, und die Codebase ist in so einem desolaten Zustand dass es meiner Ansicht nach kaum Sinn macht, ohne einen Rewrite daran weiter zu arbeiten.
 
Das Problem mit den nicht verfügbaren ATIS über den Hoppie CPDLC-Service liegt evtl. darin begründet, dass er die VATSIM-Daten auch nicht mehr richtig herunterladen und bereitstellen kann (das ATIS kommt nicht live aus dem Netz, sondern aus dem VATSIM Data File). Auf seiner Homepage konnte ich keinen Hinweis dazu sehen. Falls das weiterhin nicht funktioniert, müsste man ihm mal schreiben, wobei ich mir nicht vorstellen kann, dass dies noch nicht geschehen ist.
 
Gibt es etwas das QuteScoop in seinen Sektordaten kennt, was VATSpy nicht unterstützt?
Eher anders herum: Qutescoop kann die Sektorbezeichnung (EDGG_K_CTR vs. EDGG_P_CTR) interpretieren, VATSpy nicht! Das einzige womit Qutescoop nicht dienen kann ist die Unterscheidung der Stationsart: z.B. CZQX_CTR vs. CZQX_FSS.

Wir können uns das gerne mal direkt per Discord anschauen, ich habe mich da ja ein wenig eingearbeitet. Daniel Blasig hat die Airport Daten von VATSpy ins QT-Format konvertiert.

PS: Ganz vergessen - vor etwa einem Jahr hatte ich aus den Sphären der VATSIM DEVs erfahren, dass sie eine solche zentrale Luftraum-Datenbank aufbauen wollen, die dann die ganzen Programme/Websites bedienen soll. Was daraus geworden ist, weiss ich nicht.
 
Zuletzt bearbeitet:
Als derjenige der letztes Jahr den Fix für Qutescoop geschrieben hat als das Datenformat wechselte weiss ich davon natürlich
Weiss ich doch noch. :) Danke Dir dafür

Re-write? Gerne. Aber: Wer nimmt diese Last auf sich? Dann doch lieber ein wenig Energie investieren, um es am Leben zu halten. Die Funktionen an sich sind ja okay, vielleicht noch die Möglichkeit, _FSS und _CTR Stationen zu unterscheiden. Aber sonst bin ich zufrieden und die mutmasslich meisten anderen Nutzer auch?
 
Bzgl. QuteScoop: Die Codebasis ist halt altes Hobby-C++. ;) Wenn ich mir (egal in welcher Sprache) Code von vor 15 Jahren ansehe den ich damals privat geschrieben habe muss ich heutzutage auch leicht aufstoßen, da hat sich mit der Zeit einfach zuviel geändert und (nicht nur bei mir persönlich) professionalisiert. Komplett unwartbar fand ich das was ich mir bisher angesehen habe zwar nicht aber die Codebasis sieht nicht viel besser aus als das was ich in C++ zusammenhacken würde. Wie man am Besten JSON-Support dort einziehen kann wirft schon einige Fragen auf; wer Interesse hat zu unterstützen: Jonas Eberle hat gerade kommentiert, dass bei einer Umstellung auf das alte Whazzup-Format keine Rücksicht genommen werden muss, es darf also ruhig ein Komplettumbau sein. Das Issue ist nun mit "help wanted" gelabelt.

Falls hier jemand Ahnung von (Visual?) C++ und Windows-Build-Automatisierung hat (da haben wir doch bestimmt jemanden hier?): QuteScoop hat aktuell auch ein Problem mit dem automatischen Bauen von Windows-Releases. Ich hatte auch schon kurz reingesehen, bin da mit meinem Latein aber am Ende (schon allein weil ich aktuell keine lokale Windows-Build-Umgebung hier habe).

Eher anders herum: Qutescoop kann die Sektorbezeichnung (EDGG_K_CTR vs. EDGG_P_CTR) interpretieren, VATSpy nicht!
In den Daten sehe ich allerdings durchaus Sektoren wie EDWW-A und EDWW-B (mit Bindestrich statt Unterlänge geschrieben und ohne Endung). Von der anderen Notation abgesehen sollte das eigentlich dasselbe sein?
 
Zuletzt bearbeitet:
Oben