Stefan Schäfer informiert uns – und einige Leser bestätigen dies – dass FS Global Real Weather und Active Sky Next nicht miteinander kompatibel sind. Und zwar selbst dann, wenn Active Sky Next nicht läuft. Nachtrag: Der Fehler wurde behoben, bitte jedoch die neueste Version (4.925) von FSUIPC installieren (aktuell ist auf Pete Dowsons Seite noch die Version 4.923 verlinkt, aber das wird sicherlich bald geändert).
Scheint da wohl noch einige Probleme zu geben. Die Dash8 mag ASN nicht und bei der PMDG habe ich im Nebel Texture Probleme im VC.
Inwiefern mag “Die Dash8 ASN nicht”? Habe ASN gestern kurz mit der Dash (MJC) getestet und keine Probleme, soweit ich das beurteilen konnte.
Generel: Heißt, man muss ASN deinstalliert haben, damit FSGRW geht bzw. FSGRW funktioniert nicht mehr, sobald ASN auch nur installiert ist – verstehe ich das richtig?
Ich konnte keinen Vernünftige Flug machen. Ich habe jetzt 1.008 und mir hats im Anflug den AP ständig raus gehauen. Dann hatte ich VS von 1200ft mal hoch und runter. Die Dash flog sich, wie ein Besoffener Elefant im Porzellanladen läuft… Ich hab darauf hin den Flug abgebrochen, ein normaler ILS Anflug war einfach nicht möglich.
Ja, hab ich heute dann auch gemerkt…ich habe daraufhin ASN abgeschaltet.
Versteh ich jetzt nicht. Was heisst nicht kompatibel?
Ich habe ASN und FSGRW auf einem zweiten PC installiert und betreibe beides via WideFS bzw. simconnect. Sehe da kein Problem.
Da bahnt sich doch eine interessante Kontroverse an 🙂 Ein AddOn “torpediert” ein anderes! Da stellt sich doch sofort die Frage, wer nun daran Schuld trägt… Was verändert ASN an FSX, dass FSGRW nicht mehr funktioniert? Stellt sich diese “Ungereimtheit” nur dann ein, wenn alle diese Programme auf demselben Rechner installiert sind? In jedem Fall ist dies eine unangenehme Situation für die User, die durchaus zu Regress-Forderungen führen könnte. Lassen wir uns mal überraschen, was die Entwickler dazu zu sagen haben.
Ich gehe jetzt einfach mal prophetisch davon aus, dass es NICHT an FSGRW liegt, sondern an ASN, denn mit AS2012 gabs ja absolut keine Probleme. ASN wird da wohl irgendwas im FSX drehen, wovon FSGRW abhängig ist. Aber vielleicht ist es ja doch umgekehrt…!?
Da kommt mir doch spontan der ORBX’sche Eingriff in die Core-Dateien in den Sinn, der anderen Add-ons wie France-VFR den Garaus machen. Aber klar, alles nur Spekulation…einfach mal laut gedacht…
Wie Oski schon richtig anmerkt, warten wir mal auf die (hoffentlich kommenden) Statements der Entwickler.
Genau, so sehe ich das auch 🙂
FSGRW ist von diversen FSUIPC-Funktionalitäten abhängig; ASN installiert im Flugsimulator nun eine DLL (ASN Connect), die – auch, wenn ASN gar nicht läuft – FSUIPC-Funktionen blockiert und diese nun (nicht nur von FSGRW, sondern von allen Programmen, die diese FSUIPC-Funktionalitäten benötigten) nicht mehr verwendet werden können.
LG,
Bernd (Entwickler von FSGRW)
Nachtrag: ich möchte noch anmerken, dass ich den Entwicklern von ASN keineswegs Absicht unterstelle – problematisch finde ich allerdings, wenn ein Programm wie ASN so ein wichtiges und weit verbreitetes Add-On wie FSUIPC – das quasi Standard in der Flusiwelt ist – blockiert und es keine andere Lösung gibt, als die ASN-DLL zu deaktivieren bzw. ASN zu deinstallieren.
LG,
Bernd
Nachtragen kann man auch, dass natürlich nicht FSUIPC an sich geblockt ist, sondern nur spezifische Funktionen, die FSGRW benutzt. Evtl. auch andere (Wetter)Programme, aber dazu gibt es bisher noch keine Infos (oder diese Entwickler regeln das intern mit Hifi und FSUIPC anstatt über alle öffentlichen Kanäle)
Passieren sollte Hifi sowas natürlich nicht, die 3 Entwickler (Hifi, FSGRW und FSUIPC) sind (nun auch intern) in Kontakt und werden sicher bald eine Lösung finden.
Die generelle Funktionalität von FSUIPC ist nicht betroffen.
Naja, man kanns herunterspielen – oder sagen: Es ist ne Sauerei.
Wenn ein Programm nicht in seinem Programm bleibt und der Kunde darüber nicht informiert wurde – FSUIPC als Schnittstelle nutzen ist kein Problem, aber da was verändern…wenns unabsichtlich ist, ists sogar noch schlecht programmiert…
Man kann aber auch die Kirche im Dorf lassen und sagen, dass da halt ein Fehler passiert ist. Deshalb wurde der Kunde nicht informiert, weil es bis dato keiner wußte.
Pete Dowson war über die Entwicklung informiert und wer letztlich nun “schuld” an der ganzen Sache hat, bleibt eh noch offen.
Mit fast jeder FSUIPC Version kommen Bugs ins Spiel, die hinterher wieder ausgebügelt werden – mal fataler mal nicht. Und Hifi sich ist der Situation nun auch gewahr und wird entsprechend handeln. Die 3 werden das schon regeln.
Und was soll denn “wenn ein Programm nicht in seinem Programm bleibt” heißen? Welches FSX Programm bleibt denn heutzutage noch “in seinem Programm”? Du monierst, dass ASN nicht “in sich” bleibt, weil es auf eine “externe” Schnittstelle zugreift. Die Probleme gibt es grade, weil ASN auf die gleiche Scnittstelle zugreift, wie FSGRW. Schlußfolgerung? Bleibt FSGRW dann auch “in sich” oder nicht?
Die Anzahl der Addons die “in sich” bleiben, dürfte heutzutage gering sein: kein PMDG mehr, kein A2A mehr, kein EFB, kein Majestics usw usf.
Hier ist ein Fehler passiert, der, wie gesagt, nicht hätte passieren sollen. Wie er aber auch tagtäglich mit jedem neuen Programm, mit jedem Update, mit jeder Freeware passiert.
Man kann nun natürlich auf allen sozialen Plattformen und Medien öffentlich den großen Aufschrei platzieren, man hätte aber auch seine Kunden auf den üblichen Kanälen sachlich informieren können, dass an einer Lösung gearbeitet wird.
Mir persönlich behagt der erste Weg eher, und das hat jetzt nicht nur was mit den Wetterprogrammen zu tun, sondern solches Developergekeife tut einfach unserer Community nicht gut. Es reicht doch schon, wenn sich die Nutzer an die Gurgel gehen, wer nun das bessere Wetterspielzeug hat.
“Du monierst, dass ASN nicht “in sich” bleibt, weil es auf eine “externe” Schnittstelle zugreift. Die Probleme gibt es grade, weil ASN auf die gleiche Scnittstelle zugreift, wie FSGRW. Schlußfolgerung? Bleibt FSGRW dann auch “in sich” oder nicht?”
Falsch. Schnittstellen sollen genutzt werden – aber ASN verändert (!) etwas an einem anderen Programm bzw. der Schnittstelle (FSUIPC). Entscheidender Unterschied! 😉
Mit “im Programm bleiben meine ich, dass die Programmabläufe nicht irgendwo anders, sondern in diesem Programm ablaufen, und nur die Verbindung zum FSX/P3D/einem anderen Programm über ein anderes (in diesem Fall FSUIPC, die Schnittstelle) läuft.
Wenn ein Programm aber ein anderes Programm manipuliert/es verändert, sodass dieses nicht mehr funktioniert wie vorher/in diesem Fall andere Programme mit dieser Schnittstelle nicht mehr funktionieren, dann ist was falsch.
Es ist kein großer Aufschrei – aber man darf sich wohl dagegen wehren, dass etwas als “kleiner Fehler” heruntergespielt wird. Ich machte ASN nix böses, auch wenn diese Unterstellung vermutlich als nächstes kommt. Aber Jublerei und dann bei Fehler alles herunterspielen – das ist falsch. Darauf weise ich hin, mehr nicht, weniger nicht. Danke.
Und: Wer die übrigen Beiträge zum Thema ASN hier verfolgt hat weiß, du bist mit viel Eifer dabei und von ASN überzeugt. Das ist zunächst mal gut. Aber man muss doch, wenn Probleme auftreten, auch mal ehrlich sein. Und wenn man ehrlich ist: Die Schuldfrage ist relativ klar – das Programm, dass etwas an FSUIPC verändert 😉
Das Problem wird sicher gelöst, und dann wird das ganze vergessen und gut ist – aber hier vom Sinn her zu schreiben, dass sei keine große Sache – das gefällt mir einfach nicht.
In diesem Sinne, nix für Ungut.
Ja, ich bin mit Eifer dabei.
Das liegt einerseits an mangelnder Zurückhaltung 😉 andererseits geht mir halt bei manchen Kommentaren und Aktionen die Hutschnur hoch – wo wir wieder bei Punkt 1 wären 😉
Und Du sprichst erst von “Sauerei” und relativerst Dich nun selbst wieder, dass es doch nicht so schlimm sei. Warum also dann erst die “Sauerei”? 😉
Nur mal so als Beispiel – und meine Antwort zur “Sauerei” war, dass man doch auch mal die Kirche im Dorf lassen kann.
Ich versuche einfach zu anderen sich ereifernden und hämischen Kommentaren (betrifft jetzt auch nicht nur dieses Thema) einen gewissen Ausgleich zu finden.
@Günter: das stimmt so aber definitiv nicht. Wie schon erwähnt, ich unterstelle nicht, dass die Entwickler von ASN das bewusst gegen FSGRW (oder die andere Konkurrenz) gemacht haben, aber es ist ihnen definitiv bewusst gewesen (das wurde uns bereits bestätigt) und wird höchstwahrscheinlich auch nicht geändert werden. Ich weiß also nicht, woher Du hier Informationen beziehst.
Bzgl “Information der Kunden über übliche Kanäle” – unsere Facebook-Seite und die typischen Flugsimulationsseiten so wie hier SIND die üblichen Kanäle, wie wir unsere Kunden informieren, denn nicht jeder ist im Support-Forum registriert. Der Punkt ist meiner Meinung nach: HiFi Sim hätte diese Information der breiten Masse zugänglich machen müssen. Wir machen das nicht, um jemanden zu ärgern, sondern deshalb, weil wir wollen, dass unsere (potentiellen) Kunden Bescheid wissen, dass wenn sie ASN installiert und nicht laufen haben, Probleme im Bezug auf FSGRW auftreten. Nicht in Form von Fehlermeldungen (das wäre ja zumindest ein signifikantes Zeichen an den User), sondern in dem Windsprünge auftreten oder Höhenwinde fehlen.
Bzgl “FSGRW greift auf dieselbe Schnittstelle zu wie ASN” – das stimmt so einfach nicht. ActiveSky hat seine eigene DLL, die bestimmte FSUIPC-Funktionalitäten blockiert, auch wenn ActiveSky selbst gar nicht läuft. Wenn Du FSGRW (und soweit mir bekannt jedes andere Add-On, das mit dem FSX kommuniziert) abschaltest, dann wird nichts blockiert. Da gibt es aus meiner Sicht doch einen wesentlichen Unterschied.
LG,
Bernd
Wie gesagt, sage ich ja auch, dass das nicht hätte passieren dürfen.
Ob man dann aber zuerst öffentlich im Hififorum postet, dann – bevor Hifi antwortet/antworten kann (Zeitverscheibung) gleich auf Facebook postet und nun hinterher Pressemitteilungen versendet…?
Ich weiß auch, dass ich als Hifitester eh keine Glaubwürdigkeitsbonus habe, und mir persönlich ist trotzdem wurscht, welches Programm verwendet wird, da alle 3 großen gut sind und das eher von persönlichen Vorlieben abhängt.
Völlig unnötig ist nur diese Stichelei zwischen den Developern, die unserer Community nicht gut tut, da hier der Kindergarten nicht auch noch angeheizt werden müsste.
Wie gesagt, Pressemitteilungen und Facebook sind unsere primären Kommunikationswege mit der Community. Als die Informationen veröffentlicht wurden, war bereits bestätigt, dass es sich um dieses Problem handelt, insofern sehe ich hier kein Problem.
Was Sticheleien angeht, gebe ich Dir recht, wobei die Pressemitteilung doch sehr nüchtern gehalten ist.
LG,
Bernd
“Als die Informationen veröffentlicht wurden, war bereits bestätigt, dass es sich um dieses Problem handelt,”
Das Problem war erkannt, aber Hifi weder (intern) kontaktiert noch auf die Rückmeldung gewartet.
Ich will mich auch nicht weiter im Kreise drehen.
Und will Dir aber auch danken für eine sachliche Diskussion, die man hier führen kann.
Vielleicht reicht ja mein Raunzer, dass nächstes Mal erst an die Tür geklopft wird, bevor eingetreten wird 😉 Is ja schon was …
In meinen Augen schlecht Entwickelt. Ok wenn die Anwendung läuft macht es sinn bestimmte Sachen für andere zu blocken um keine Seiten Effekte zu bekommen (Wenn es wirklich nötig ist). Aber das es auch der Fall ist wenn das Tool aus ist ist fail.
Für mich ist das ganz einfach: Ein Produkt, das nach einem anderen (ähnlichen) Produkt auf dem Markt kommt, hat dieses und auch keine anderen zu stören oder in deren Funktionen zu be- oder gar zu verhindern. Punkt. Nur wenn es gar nicht (?) anders geht, sollte zumindest eine etsprechende Informationen veröffentlicht werden, im besten Fall mit der Eigeninitiative (!), das ändern zu wollen…
Die notwendige Austausch zwischen Entwicklern (im Vorfeld einer Veröffentlichung) zum Wohle des Produktes und deren Käufer darf als angemessen und nicht als unverhältnismäßig arbeitserschwerend vorgesetzt werden. Hierbei ist es “völlig Pumpe”, wer und was nach (!) wem oder was anbietet.
Auch ich unterstelle den Machern von ASN keine Absicht, aber ein gutes Licht wirft es auch nicht wirklich in deren Richtung. Hier gibt es sicher andere Lösungen – für eine friedliche Koexistenz. Hier ist ganz klar HiFiSim gefordert. Niemand sonst.
Bert
Völlige Zustimmung!
Ich erinnere nur daran, das FSGRW und ASN auch von Testern verwendet wurde und wir im Vorfeld(!) keine Fehler feststellen konnten!
@Günther: “Und Du sprichst erst von “Sauerei” und relativerst Dich nun selbst wieder, dass es doch nicht so schlimm sei. Warum also dann erst die “Sauerei”? 😉
Nur mal so als Beispiel – und meine Antwort zur “Sauerei” war, dass man doch auch mal die Kirche im Dorf lassen kann”
Ich schrieb:
“Naja, man kanns herunterspielen – oder sagen: Es ist ne Sauerei.”
Bitte das kann (!) beachten, bezieht sich auch auf die Aussage nach dem Gedankenstrich.
Sinn: So wie man es herunterspielen kann , kann man es auch als Sauerei bezeichnen.
Die Wahrheit liegt in der Mitte. Aber es ist müßig das zu diskutieren, wenn du meinen Standpunkt nicht nachvollziehen möchtest/kannst.
Ich hab mir mit dem ASN Downwload FSUIPC zerschossen – ich kann derzeit FSGRW nicht benutzen. Und eigentlich hatte ich nicht vor FSUIPC mit all den Einstellung neu zu installieren. Was anderes, als bei dieser Sache zu sagen “schlampig programmiert” (von ASN) geht meiner Ansicht nacht einfach nicht. Denn sowas darf wirklich nicht passieren, wenn man Geld für ein Programm verlangt. Das Freeware häufig zu Fehlern führt ist eine andere Sache.
Dann noch den schuldigen woanders zu suchen als bei ASN halte ich für äußerst zweifelhaft. FSUIPC und FSGRW haben ja funktioniert. Das deren Entwickler jetzt mit ASN über das Problem und die Lösung beraten ist kulantes Entgegenkommen und natürlich Eigeninteresse daran, dass ihre Programme wieder voll und ganz funktionieren.
Nun gut, da sind wir nun in den Details der Interpunktation und deren Zweideutigkeiten. 😉
Da Du mir aber nun erklärst, wie Du es meinst, kann ich es besser nachvollziehen, ok.
FSUIPC wurde bei Dir komplett “zerschossen”?? Heißt, da geht gar nichts mehr? Oder betrifft das nur die FSGRW Funktionalität, die eine ASN Deinstallation wieder herstellt?
ASN berührt weder den Modules Ordner noch FSUIPC, sondern nur die o.a. Funktionen, die FSGRW nutzt.
(Eine FSUIPC Neuinstallation ist übrigens nicht dramatisch – wenn nötig – da Du mit der FSUIPC4.ini alle Einstellungen sichern kannst.)
Joystick-Zuordnung war auch weg – kann Zufall sein, kann aber auch kein Zufall sein. ASN ist deinstalliert – FSGRW geht trotzdem nicht mehr.
Hört sich ja schonmal anders an als “zerschossen”…
Joysticks waren weg oder sind weg? Und den bekannten WIN8 Fehler kannst Du defintiv ausschließen?
FSGRW funktioniert auch nach Löschung der ASN DLL komplett nicht mehr? Wundert mich insofern, als das ASN nur gewisse Eigenschaften blockiert (Höhenwinde) und nicht das gesamte Programm … FSGRW “geht nicht mehr” wäre also erstmal seltsam.
“Und den bekannten WIN8 Fehler kannst Du defintiv ausschließen” – ja, denn bei Windows 7 gibts den WIN8-Fehler nicht 😉 Zudem wurde der Joystick schon noch erkannt, nur die FSUIPC Achsenzuweisung funktionierte nicht mehr.
FSGRW meldete die Verbindung zum Serve würde nicht funktionieren…
@Boris: Es geht hier auch ein bisschen ums Prinzip: Klar, man braucht nicht beide. Aber dennoch sollte ein Programm grundsätzlich nicht ein zweites und drittes an seiner Funktionalität hindern.
Dann würde ich raten das Hifi Forum aufzusuchen, sowie evtl. auch das FSUIPC Forum. Und auf die Lösung des Problems wäre ich wirklich sehr sehr gespannt 😉
Na typisch habe ich erst einmal gedacht…zum Glück habe ich mich seit FSGRW endgültig von AS und was für eine Version auch immer endgültig verabschiedet. Mir gefiel weder deren Selbstdarstellung noch der Support und die Revolutionen in der Wetterdarstellung waren eher kleine Schritte und mehr fürs Auge und Marketing gedacht. Die Kombination aus FEX und FSGRW passt für mich optimal!
Öhem. Könnte mir mal jemand erklären warum man wohl _zwei_ Wettertools parallel brauchen könnte? Ich kann es ja verstehen wenn sie sich ergänzen, z.B. REX wegen der Texturen und dazu eine Wetterengine, oder auch Opus wegen der Kamerafunktionen, aber ASN und FSGRW? Beide machen Wetter, je nach den jeweiligen Vorlieben der Nutzer. Der nutzt also entweder FSGRW oder eben ASN – aber doch nicht beide, oder?
Und selbst wenn die ASN-DLL FSGRW unbrauchbar macht – wenn man nach dem Test bei FSGRW bleibt, entfernt man diese DLL eben wieder, und wenn nicht, behält man ASN und entfernt FSGRW.
Oder sehe ich das jetzt falsch weil _ich_ mir einfach nur ein Wettertool wünsche das das Wetter so macht wie es nun mal ist und das ich nur starten muss und nichts weiter?
Boris
Philipp sagt es ja schon es geht um das Prinzip und darum das es keine Info von seiten Hifisim gab für den Kunden. Den du installierst ASN und bist nicht überzeugt also weg damit. So dann installierste FSGRW und bähm es funktioniert nicht wie versprochen.
Und bei wem beschwerste dich zuerst? Genau bei den Machern von FSGRW, die aber nix dafür können.
Was wäre wenn das auch andere Addon Hersteller machen würden?….
Hier geht es vorallem um die Kommunikation von Seiten Hifisim. Erst was sagen wenn andere darauf stoßen und es publik machen.
Siehst Du, und genau deswegen klinke ich mich eifrig in solche Diskussionen ein, weil der Sachverhalt nicht stimmt, wie Du ihn darstellst:
Hifi KONNTE niemanden informieren, weil sie es nicht wußten und auch im Test nichts derartiges festgestellt werden konnte. Jetzt kommt es nur noch drauf an, ob Du mir das glaubst oder nicht.
Desweiteren, wenn Du ASN dann deinstallierst, ist die entsprechende DLL auch deinstalliert und FSGRW funktioniert wieder vollumfänglich.
Damien von HiFi-Sim hat uns bestätigt, dass es ihnen bewusst war.
…und damit haben sie ihren eigenen Ruf ruiniert. Hätten sie das gleich angekündigt (dann hätte mans ja nicht installiert, wenn man FSGRW hat o.Ä.) hätte man ihnen weit weniger vorwerfen können. Sorry, aber sowas geht einfach nicht.
Siehe Antwort von Bernd. Das hat er ja schon weiter oben geschrieben und darauf habe ich mich bezogen
@ Boris: Solange sich die beiden Wetterprogramme unterscheiden und in verschiedenen Punkten ihre Stärken haben, könnte man mal das eine, mal das andere nutzen. Vielleicht abhängig ob IFR oder VFR. Oder jetzt nach Release zum Vergleich, welches für die eigenen Bedürfnisse das bessere Wetter erzeugt. Oder, falls ASN deutlich früher als die Konkurrenz eine Version für P3D2 veröffentlicht, simulatorabhängig. Ich kann mir genug Szenarien vorstellen, beide zu installieren… von daher wäre es schon wünschenswert, dass sie sich vertragen…
@Günter
Du propagierst hier Zurückhaltung, dass man zunächst anklopfen solle, bevor man eintritt, siehst aber offensichtlich keinen Bedarf, diese “Weisheiten” auch für dich selbst anzuwenden! Als ich zum ASN Release geschrieben hatte, dass auch ASN nicht vermag, einen bekannten FSX Bug abzustellen, hatte ich kaum zu Ende geschrieben, da kam dein Hinweis, dass das ein Fehler meinerseits wäre und ich doch ein Support Ticket beantragen solle. Rückblickend war das aber kein Fehler meinerseits! Ich verstehe ja, dass Du dich als Betatester als Teil des ASN Projetkts verstehst und deine Ansichten entsprechend gefärbt sind. Ein wenig Zurückhaltung bevor man endgültige “Weisheiten” verbreitet stünde aber auch Dir gut zu Gesicht…
Du hast damals schon meine Empfehlung, den Hifi Support zu rate zu ziehen, als persönlichen Angriff gewertet. Weder heute noch damals habe ich behauptet, dass es ein Fehler Deinerseits ist!
Und schon wieder wertest Du, dabei habe ich doch gerade noch Dein anklopfen zitiert …
Gedanken sind keine Realität! Dass Du dich angegriffen fühlst, beruht gänzlich und allein auf Deinem Bewertungskonstrukt!
Abgesehen davon ging deine Ratschläge klar in die Richtung eines Fehlverhalten meinerseits. Ist ja für jeden noch nachlesbar. Ich habe das nüchtern und emotionslos entwertet, alles andere liegt in deinem Interpretationsradius.
Na dann ist ja alles klar …
Mika, lies Dir bitte noch mal die Beiträge von Günter durch. Wenn ich mich nicht ganz täusche, bist Du es, der sich angegriffen fühlt, nicht Günter. Damit betrifft Dein Satz “Dass Du dich angegriffen fühlst, beruht gänzlich und allein auf Deinem Bewertungskonstrukt!” nicht für ihn sondern für…. 😉
Er hat Dir doch nur geschrieben, dass das bei Dir auftretende Problem ein Fehler von ASN sein muss. Und ob Du es dem Entwickler mitteilen kannst, damit das ausgebessert wird.
Ich kann nicht ganz nachvollziehen, dass Du ihn so konsequent falsch verstehst und Günter, der sich sehr für die Community einsetzt, dafür noch mit negativen Bewertungen belegt wird.
So ist das mit unserer Community: Man darf viel Arbeit und Herzblut investieren, ohne sich mit Geld oder Anerkennung herumschlagen zu müssen. 😉
Ich hatte Günter so verstanden, dass es ein Fehler seitens ASN sein muss, nicht ein Fehler von Dir. Wenn Du einen Fehler gemacht hättest, wäre es ihm wohl nicht so wichtig gewesen, dass Du den Fehler beim Entwickler bekannt machst.
Was für ein Kindergarten. Das Problem wurde erkannt, an dessen Behebung wird gearbeitet PUNKT! Aber nein, erst mal muss sich künstlich aufgeregt werden und das jeweilige Konkurrenzprodukt samt Firma und Entwickler als untauglich, fehlerhaft und was weiß ich nicht alles bezeichnet werden.
Diese Diskussion passt eher zum Stammtisch als zu dieser Platform. Meine Meinung!
>Diese Diskussion passt eher zum Stammtisch als zu dieser Platform. Meine Meinung!
Dem widerspreche ich! Ich verliere immer mal wieder die Lust, überhaupt noch etwas für den FS zu entwickeln, wenn ich die Kommentare hier lese. Beim Stammtisch trifft man nette Leute, mit denen man dann gemeinsam dem Kopf über das Geschriebene schüttelt, anschließend lacht und dann sieht die FS Welt wieder ein bisschen besser aus.
Grundsätzlich stimme ich Dir zu, im besten Falle kann man schmunzeln und sich kopfschüttelnd von Beiträgen hier unterhalten lassen. Meistens vergeht einem aber sämtliche Freude – und wenn man die Menschen und Geschichten hinter den Add-ons kennt verzweifelt man auch mal an der Ungerechtigkeit, mit der sich die Entwickler auseinander setzen müssen.
Und nicht mal die vorweihnachtliche Zeit macht uns friedlicher oder zufriedener… 😉
Herr je…dann lies diese nicht! Lass die Möchtegern-Oberlehrer und lizensierte Dauernörgler doch ihre unwichtigen Kommentare in die Welt hinauspusten. Ist doch sowas von wurscht. Ganz erhlich, ich weiß nicht wo das Problem ist. Wenn ich mir jeden Kundenkommentar zu Herzen nehmen würde dann würde ich schon längst meine Rente verlangen. Kritik ist notwendig, solange sie konstruktiv ist. Was ich hier größtenteils lese ist ein Möchtegern-Rhetorik-“Battle” mit unwichtigem Inhalt.
Wie ich schon sagte: Problem erkannt, Problem wird behoben. Ende aus! Aber wie ich lese, geht es hier munter weiter. Mir egal. Sollte auch dir egal sein. Auf dem freien Markt muss man Stärke zeigen. Mimosen werden gefressen. Das ist Fakt.
Im diesem Sinne. Weitere Kommentare spare ich mir. Mir ist die zeit zu schade für Unwichtiges.
Jaja, recht hast Du – ich hatte es geschafft, mich einige Monate den Kommentaren fern zu halten. Vielleicht sollte ich noch mal einen zweiten Versuch wagen… 😉
Diese Kommentare beeinflussen unsere Community. Und sie beeinflussen Entwickler, die kurz davor sind das Handtuch zu werfen: Weil die meisten Add-ons nicht genug Geld im Verhältnis zu Arbeit bringen und man sich obendrein mit entsprechenden Kommentaren rumschlagen muss. Für eine tolle Community nimmt man eher die Mühe auf sich. Noch viel mehr betrifft das Freeware. Irgendwann trifft es auch die Nörgler, weil es weniger Vielfalt im Hobby gibt, aber diesen Zusammenhang werden sie selbst dann nicht realisieren und wieder anderen die Schuld zuschieben.
Ich kann etliche Zusammenhänge nennen, wo wir uns schon sehr deutlich geschadet haben. Das betrifft z.B. die deutschen Tutorial-Videos zur Q400 oder dass man nicht mehr online fliegt, weil man unfreundlich behandelt wurde, etc. Und ich kenne Fälle, in denen Entwickler kurz davor sind, sich nicht weiter zu betätigen. Das fände ich sehr schade.
Dein zweiter Absatz ist sicher richtig, aber will man in so einer (FS-)Welt wirklich dauerhaft leben? Dann ist die Freizeitbeschäftigung ja schon genau so übel wie der Berufsalltag…
Wenn man kein Problem damit hat, sich ein anderes Hobby/Beruf zu suchen oder auf die Vielfalt verzichten kann, ist das sicher alles unwichtig hier. Noch denke ich aber anders darüber…
Zu Kommentaren bei Freeware kann ich nichts sagen da ich mir die meistens nicht durchlese. Bei Freeware bin ich auch bereite mit unannämlichkeiten zu leben ist ja auch kostenlos ;).
Aber bei Produkten die Geld kosten sollte man damit leben können das es auch mal negative Kommentare gibt. Klar sollte man jemanden nicht angreifen sondern sachlich bleiben.
Auch wenn unsere Community klein ist sollte man nicht alles nur bejubeln ;).
Ich will damit nicht sagen das man mit ASN schrott kauft.
…was anderes: gibt es Pläne das nun machbare Wetterradar in Cockpit Displays einzubauen? PMDG Planes vielleicht?
Pläne gibt es, aber keine Addonsankündigung offiziell
Mannomann. Was aus einer unglücklich programmierten DLL alles erwachsen kann… Nun ist’s aber gut, oder? Ich habe keine Lust, zu moderieren, werde es aber tun, wenn das Niveau noch weiter absackt.
Besten Dank der Kenntnisnahme.
Ich weiß erhlich gesagt nicht, wozu es überhaupt ein Kommentar-Bereich gibt, wenn regelmäßig bei Diskussionen (und diese Diskussion bewegt sich auf einer relativ sachlichen ebene, keine Partei ist beleidigend den anderen Gegenüber geworden, das Niveau ist nicht so schlecht wie’s gerade gemacht wird…) diese wie das allerletzte hingestellt werden. Diskussionen sind gut, und diese Diskussion hat nix mit lächerlich zu tun, da sind sich glaub ich alle diskutierende Parteien einig (der einzige Punkt vermutlich in dem sie sich einig sind).
Also einfache Lösung: Kommentarbereich streichen… oder akzeptieren das hier mitunter auch mal diskutiert wird…
Wenn man die Diskussionen hier so verfolgt, kommt man sich vor wie im Kindergarten. Es gibt kein Programm, was fehlefrei ist. Wenn ich mich auf der Arbeit, laufend an allem hochziehen würde, was falsch läuft, dann brauch ich nicht mehr arbeite zu gehen. Es ist mir auch egal, ob Leute bei mir jetzt, den Daumen runter machen !
Kern ist doch das es von Seiten der Entwickler bekannt war und die es nicht Publik gemacht haben. Deswegen ist es doch erst zu der Diskussion usw. gekommen.
Und ja kein Programm ist fehlerfrei, aber wenn man weiß das man Funktionen einer von jeden benutzten Schnittstelle blockiert und trotzdem das Tool Release ist einfach fail. Wenn das stimmt das die auch nicht vorhaben den Umstand zu ändern ist es kein Fehler der mal passiert sondern eine klare Software-Design Entscheidung.
Ja in unsere Community wird aus allem ein riesen Problem gemacht, aber hier kann ich es verstehen wenn andere Entwickler sagen hey das Problem kommt nicht von uns sondern von xy.
So, damit nun die Gegenseite auch Gelegenheit bekommt, sich erklären zu können, hier das folgende Statement von Damien Clark:
“As we have publicly stated in our forums, in response to public claims that we are intentionally blocking anything, we did not know this was an issue, have been testing for over a year, with several testers having using both products, and not once has this issue come up. To be honest, we did not anticipate that a user would need to have ASN and a competitive product running simultaneously or interchangeably. This is a “non-issue” if each product is installed and run without the other. The only way this becomes a problem currently is if ASN is installed, then FSGRW is run. This is due to our module being installed, ready to respond to ASN and provide integration for ASN. As we have clearly documented in our User’s Guide, FSUIPC weather functions are disabled when ASN and ASConnect module are installed, as necessary to provide advanced weather integration.
We have been having email conversations with Peter Dowson as well as Stefan and we have explained all of this, and Peter is working on providing a way to have FSUIPC keep its weather functionality even with ASConnect module installed, thus ASN and FSGRW will be able to be run next to each other and interchangeably without the need to uninstall ASN before running FSGRW.
I must say it is quite unfair, in my opinion, to have misleading accusations coming from the developer himself when we have clearly explained this, and obviously have not intentionally blocked anything, and also this DOES NOT BLOCK FSX FUNCTIONALITY. This only affects FSUIPC WEATHER FEATURES, as we have documented. We have been graceful and cooperative in trying to resolve this issue for FSGRW, and would appreciate the same kind of grace and cooperation from the other side. Thank you. ”
Damit sind nun alle Beteiligten zu Wort gekommen und es kann sich jeder sein eigenes Bild von der Sache machen.
Tut mir leid, aber dieses Statement klingt eher nach einer “beleidigten Leberwurst”-Haltung. Es ist unerheblich, ob HiFi gewusst hat, ob ein Konfliktpotenzial besteht oder nicht. Dass ein betroffener Hersteller eines Konkurrenzproduktes sich mit aller Vehemenz (und nötigenfalls mit allen Konsequenzen) wehren muss, ist absolut verständlich. Es muss schon mit aller Klarheit gesagt werden: den Scheiss hat Hifi gemacht, nicht FSG! Darauf hinzuweisen, dass “this DOES NOT BLOCK FSX FUNCTIONALITY” trägt für mich einen unsichtbaren Nachsatz zwischen den Zeilen den ich hier aber nicht zitieren möchte. Davon war nie die Rede. Es muss einfach vermieden werden, dass am Schluss das Opfer noch als Täter dasteht. Diese Manipulationsgefahr besteht bei allen derartigen Kommunikations-Vorgehensweisen. Ich glaube allerdings schon, dass sich HiFi der Brisanz ihrer Situation bewusst ist, denn nach meinen Informationen würden sie bei einer rechtlichen Auseinandersetzung den Kürzeren ziehen, und das würde wohl der ganzen Community nichts bringen. Hoffen wir einfach, dass die Angelegentheit bald erledigt ist und wir wieder zur Tagesordnung übergehen können 😀
Von Pete Dowson kommt auf AVSIM folgende Information.
“There’s nothing in FSUIPC 4.92 that conflicts with ASN. the only changes (which are listed in the Changes documnet), are the suppression of errors being logged which are caused by ASN grabbing the hooks into the FSX weather system which FSUIPC uses for smoothing, and some additional facilities for showing the route weather on a Wideclient PC.
There’s a newly discovered problem with FSGRW if it is used on a system on which ASN is installed, because it uses parts of FSUIPC which needs the hooks taken by ASN. Those hooks are taken by the loaded Module 9DLL.XML) and might still be in place even without ASN in use. I will be releasing a further update (4.925) to deal with this within the next day or so. Still testing at present.
If you ever want some support or have questions on FSUIPC over in my Support Forum, that will be the time i would expect you to first install the latest version at that time. I cannot really support old versions.”
Nicht bös sein, aber der Satz “To be honest, we did not anticipate that a user would need to have ASN and a competitive product running simultaneously or interchangeably.” ist doch nichts anderes als Augenauswischerei.
Ich biete eine Demo an, die 7 Tage läuft und rechne nicht damit, dass man gleichzeitig zwei Tool installiert hat? I call Bu****it.
Würde ich ASN testen wollen, dann würde ich mich auf einen Flughafen stellen und die Wettertools side-by-side ausprobieren um zu sehen, wie die Darstellung aussieht. Was mich ärgert ist, dass, wie Bernd es schon gesagt hat, manche User, die keine News oder Foren konsultieren, ein schlechteres Erlebnis mit FSGRW haben und eventuell garnicht wissen, wieso; Und dann evtl. ASN kaufen – kein Wunder, mit FSGRW hauts “irgendwie nicht mehr so hin”. Ich hoffe, dass du Bernd, beim nächsten Build eine große Warnmeldung generierst, wenn besagte .DLL vorhanden ist, damit sich jeder User des Problems bewusst ist.
lg, Alex
Mitteilung von Stefan Schäfer:
“Wenn Sie Active Sky Next (Voll- oder Testversion) für FSX installiert haben und auch
FSGRW verwenden moechten, muessen Sie eine FSUIPC Version spaeter als 4.925
installieren. Laden Sie diese bitte ueber den Link auf unserer Webseite herunterr.
Fruehere Versionen verhindern, dass Sie in FSGRW korrekte Hoehenwinde vorfinden.
Verwenden Sie niemals beide Wetterprogramme gleichzeitig!
Wir danken Pete und Damian für Ihre rasche Reaktion und Unterstuetzung.”
Stellt sich im Nachgang natürlich die Frage, ob nicht schlicht ein Bug bzw eine nicht so optimal programmierte fsuipc.dll Schuld trägt, wenn ein Patch derer Abhilfe schafft. Mir ist auch ein wenig Schleierhaft, wie eine Funktionsbibliothek (und programmiertechnisch gesehen sind dll’s eben nur das) eine andere soweit ausknocken kann, dass diese Fehler schmeißt und nichtmehr funktional ist; wie mit fsuipc geschehen.
Schade finde ich auch, wie schnell ein Verdacht der Wettbewerbsbehinderung aufkommt. Was würde ich denn als Käufer machen, wenn sich herausstellt, dass asn andere Addons unbenutzbar macht? -klar, deinstallieren und asn nichtmehr nutzen.
Anmerken möcht ich noch: bis ich opus und nun fsgrw nicht kannte, hatte ich AS2012 genutzt. Ich sehe für mich keinen Grund wieder auf asn umzusteigen oder was dessen tollere Features gegenüber fsgrw sein sollten und bin absoluter Fan von fsgrw. Aber ich fand die Reaktionen ein wenig durch die Blume gegen ASN geschimpft. Immerhin haben die sich Gedanken gemacht und die für ihre Zwecke unzulänglichen Funktionen von fsuipc verbessert bzw. eigene Methoden implementiert. Dass eine dll vom FSX geladen wird, liegt in der Programmierung des FSX. Ich würde sogar soweit gehen, zu sagen, fsuipc war der Stenkerfritze, denn die asn-dll kommt ja mit den von fsuipc genutzten Funktionen aus.
Vielleicht könnte Bernd einen technischeren Einblick geben, was hier softwaretechnisch Sache ist/war? Ich programmiere allenfalls in C# kleine Minihelferlein, aber bei weitem ohne dll’s und meine Linux c-Zeiten sind schon ein paar Jahre her. 😉 Aber mich würde es interessieren.
Nanu, so ruhig hier? Was ist los? 😉
Pete Dowson hat eine neue FSUIPC Version herausgebracht: 4.926
http://forum.simflight.com/topic/66139-updated-modules/
Die vorherige hatte ASN geblockt!
(ich vermute, nein besser, behaupte jetzt einfach, das war ganz, ganz böse Absicht von Pete Dowson. Auch wenn er sicherlich etwas anderes behauptet … 😉 [wer Sarkasmus findet, darf ihn behalten])
Mir ist irgendwie nicht ganz klar, warum FSUIPC überhaupt gebraucht wird. Die vorgängerversion ASE jedenfalls geht rein über die SimConnect Schnittstelle, und mir ist keine FSUIPC funktion bekannt, die über direktem weg nicht auch erreichbar währe.
Es wird nicht gebraucht. Allerdings hat FSUIPC ja auch eine Art Wetterinterface (womit man z.B. bei früheren AS Versionen den Wind und Temperatursprünge “smoothen” konnte). ASN hat diese und andere Schnittstellen – die FSGRW benutzt – blockiert. (Bzw FSUIPC hat diese bisher nicht umgangen oder wie auch immer die letztlich entscheidende technische Lösung lautet.)
Mit der neuen Version haben die Schnittstellen von FSGRW und FSUIPC nun freie Fahrt, sozusagen.
Brauchen tust Du FSUIPC für ASN aber nicht!
Nur wenn Du es benutzt oder eben parallel FSGRW, dann muss man nun unbedingt auf die neueste Version von FSUIPC updaten!
Das “smoothen” hatte bei ASE nichts mit FSUIPC zu tun, eher im gegenteil. Da beide Schnittstellen über nahezu identischer funktionalität (API´s) in Bezug auf Wetterdaten verfügen, ist es eher als Redundanz zu verstehen. Auch FSGRW nutzt ausschließlich SimConnect (sonst währe WideFS bei Multi-PC nötig), denn mehr wird auch nicht gebraucht.
Wie auch immer: trotzdem wüsste ich gerne, wie man programmiertechnisch FSUIPC calls blockieren kann. Auf Anhieb hätte ich da jedenfalls keine Idee. Interessant ist allerdings, das tatsächlich jemand auf fs-developer.com vor ein paar Monaten nach sowas gesucht hat (und sich jeder noch gefragt hat, wozu man sowas brauchen könnte).
Kurz erklären möchte ich mal, was eine dll überhaupt ist.
Nehmen wir an, wir programmieren ein kleines Fenster mit einem OK Knopf. Das Betriebssystem gibt uns hier die Möglichkeit low level zu arbeiten (analog besitzt der FSX ein SDK mit einer dokumentierten API). Nun gebe ich dem Betriebssystem folgendes:
Pixel 1 – Farbe blau – Position xyz
Pixel 2 – Farbe blau – Position x+1yz etc.
So wird Stück für Stück ein Fenster aufgebaut was einen OK Knopf hat. Wenn der Programmierer nun mehrere solche Fenster bauen will, schreibt er einfach eine Funktion/Klasse/Methode/Header-Datei (je nach Programmiersprache unterschiedliche Begriffe) und braucht dann jener Funktion nur noch Mitgeben:
Fenster – Ausmaße xyz
OK Button an Position xyz
Somit kann man nun wesentlich schneller programmieren. Ist derjenige Programmierer nett, so lagert er diese Funktionalität aus, dokumentiert sie gut und gibt sie zum dynamischen Linken für andere Entwickler frei (im Windows-Fall: dll’s). Ohne am Urschleim zu beginnen können die Addon-Dev’s effizienter Programmieren.
Im Vorliegenden Fall haben sich die asn Leute gedacht, fsuipc reicht denen nicht, die bauen eine eigene dll dazu. Was auch immer nun dazu führte, dass 1 dll den Dienst verweigerte, anstatt die API-Aufrufe der anderen dll zu ignorieren, weiß ich nicht. Böserweise könnte man behaupten, fsuipc würde keine “Konkurenz” zulassen wollen und blockt sich selbstständig wenn ein anderes Addon jene Aufrufe nutzt. Auch könnte man von einem Bug reden, welcher bisher nie auffiel. Auch Schlampigkeit der asn Dev’s könnte man unterstellen. Weiß man derartiges Verhalten, kann man ja schließlich einen dynamischen Loader davorschalten, welcher die dll bei Bedarf installiert (quasi erst asn starten, und über dieses FSX). Dagegenhalten kann man dann wieder: es gibt ja noch die Fraktion der notorischen Handbuchverweigerer welche dann sicherlich das Supportforum von asn flooden würden, wieso denn die Software nicht funktioniert (wie oft musste im PMDG Forum der highmemfix erklärt werden; und der steht sehr wohl im Handbuch).
Ohne weitere Details kann man nur mutmaßen; fakt ist: ein Patch von fsuipc hat das Problem behoben. An der Uni hat man uns gelehrt, nur der Verursacher eines Bug’s kann diesen beheben.
Hier kommt nur Halb-(Viertel)wissen:
“Böserweise könnte man behaupten, fsuipc würde keine “Konkurenz” zulassen wollen und blockt sich selbstständig wenn ein anderes Addon jene Aufrufe nutzt. ”
Soweit ich weiß, klinkt sich ASN noch hinter FSUIPC ein. Selbst wenn in FSUIPC das Windsmoothing z.B. aktiv ist, “überschreibt” ASN dies.
Es gibt kein “vor” oder “hinter” bei Funktionsbibliotheken : ein API call ist verfügbar, oder ist es nicht. Anders ausgedrückt: entweder die DLL wurde geladen, oder sie wurde es nicht. Die Reihenfolge ist völlig wurscht, es gibt keine prioritäten.
“wenn in FSUIPC das Windsmoothing z.B. aktiv ist, “überschreibt” ASN dies”, da hätte ASN aber viel zu tun, da FSUIPC das sonst permanent “korrigieren” würde.
FSUIPC und SimConnect kennen einander nichtmal – wozu auch, wäre ja redundant. Die genau Schnittstellendefinition würde allerdings den Rahmen hier sprengen, denke ich mal. Wer´s genauer wissen will : fsdeveloper.com oder nach ‘SimConnect API Reference’ googlen.
ASN wird daher wohl eher auf die ‘SimConnect_WeatherSetModeCustom’ funktion zurückgreifen um das zu unterbinden.
“da hätte ASN aber viel zu tun, da FSUIPC das sonst permanent “korrigieren” würde.”
Verzeih mir meine lainhafte Darstellung. Du hast als Profi sicher auf den ersten Blick erkannt, dass ich davon keine Ahnung habe.
Aktiviert man die FSUIPC Wetterfunktionen, werden diese durch ASN komplett ignoriert und die ASN Winde etc ermöglicht.
Als Laie würde ich dazu sagen, ASN “überschreibt” das halt irgendwie. Warum und wieso, weiß ich nicht und ist letztlich auch völlig egal.
Grundsätzlich geht es bei der ganzen Sache ja eh nicht um den technischen Aspekt, sondern wer wen wann und warum und wie vorsätzlich geblockt hat und wie man damit in der Öffentlichkeit umgeht.
Deine Kernfrage war eigentlich “… trotzdem wüsste ich gerne, wie man programmiertechnisch FSUIPC calls blockieren kann.”. Warum dazu nicht Pete Dowson persönlich fragen?
War eher ironisch gemeint, weil es
a) eben eintlich gar nicht geht (der Hund muss also woanders begraben liegen) und
b) nichts mit FSUIPC als solches- sondern eher mit allgemeinen programmiertechnischen Konventionen zu tun hat, die sowas eben gar vorsehen, bzw. zulassen.
Naja, ist ja auch egal: ich finde es halt immerwieder abenteuerlich, welche Begründungen manche Kollegen sich so alles einfallen lassen …die Richtung wird schon stimmen, nur halt eben “sehr trivialisiert” ausgedrückt.
Es gibt nunmal keinen logischen Grund, überhaupt noch auf FSUIPC funktionen zuzugreifen, wenn man schon eine SimConnect Schnittstelle definiert hat – es sei denn, aus reiner bequemlichkeit (ist ja nicht so, dass man das nicht schon selbst auch so getan hätte :D)
Ich verstehe immer noch nicht so ganz, auf was Du hinaus willst:
“Es gibt nunmal keinen logischen Grund, überhaupt noch auf FSUIPC funktionen zuzugreifen,”
Tut ASN doch auch nicht?
Oder wie meinst Du das nun?
Nein, ASN nicht, jedoch viele andere Programme. Jene Entwickler, welche sich eigene Routinen programmiert haben, stört es nicht weiter; eine PMDG777 läuft auch ohne fsuipc weil diese eigene dll’s implementiert hat mit den nötigen Calls. Dies wurde notwendig, weil eben mehr gefordert wurde, als fsuipc liefern könnte. Für eine Wetterengine aber ist fsuipc so ich mitbekommen habe sehr wohl ausreichend mit dem Manko, dass man eben keine Wolken auf den Meter genau bestimmen kann; dies soll wohl mit ASN möglich sein, was auch Wetterradars realistisch erscheinen lässt, so eine Softwarebude sich dazu bereit erklärt, die asn.dll zu nutzen (und HiFi diese überhaupt dazu freigibt).
Im Gegenteil: viele haben ihre eigenen dll’s programmiert (PMDG, Majestics) welche fsuipc Funktionalitäten quasi redundant zur Verfügung stellen, allerdings scheinbar mehr Funktionsumfang bieten. Und bei all denen gab es keine Probleme; bei einer Wetterengine plötzlich jedoch schon. Ich vermute hier schlichtweg wirklich einen kleinen Programmierfehler oder ein nicht erwartetes Verhalten. Soweit ich weiß, ist asn auch das erste Wettertool, welches eine umfangreiche dll zur Verfügung stellt und die Wettertransfers nicht per simconnect oder fsuipc in den FSX speist. Dass das Problem bisher nicht auftrat ist nur mehr als verständlich.
Auch kann man nicht erwarten, dass fsuipc plötzlich “alt”, “outdates” oder “überflüssig” wäre. Es bietet neuen Dev’s sehr rudimentäre und fortschrittliche Funktionen an und erleichtert die Arbeit enorm. Man darf nicht vergessen: sowohl pmdg, hifi als auch majestics haben zu Anfang immer auf fsuipc gesetzt und erst nach und nach ihre eigenen Sachen programmiert um sich von fsuipc zu entfernen um ihre eigene Datei weiter auf ihr Produkt zu fixieren.
Aha, jetzt kommen wir der sache schon näher.
Das ist eben im HifiSim Forum anders beschrieben. Demnach sollen FSIUPC calls exclusiv durch ASN erfolgen und deswegen selbiges blockieren (was eben nonsens währe). Trotzdem frage ich mich immernoch nach dem kausalen Zusammenhang, aber andereseits…mir egal : ist ja nicht mein Problem :D))
@ Andreas (nicht Andy)
ASN läuft auch ohne installiertes FSUIPC … ich kann aber leider immer noch nicht folgen … Deiner Meinung nach benutzt ASN aber doch FSUIPC, oder wie?
Hallo Andy, “Kurz erklären möchte ich mal, was eine dll überhaupt ist.”
Ich bin kein Informatiker, wohl eher der Idiot der 20cm vor der Tastatur sitzt. Es war mit Sicherheit gut gemeint Dein Erklärungsversuch: nur verstanden haben ihn sicherlich nur die wenigsten. Es gibt auch viele Simmer wie ich die nicht diese fundierten EDV- Kenntnisse haben und über den Fachjargon verfügen.
Die Kunst der Kommunikation besteht darin verstanden zu werden.
Ist aber definitiv kein persönlicher Angriff auf deine Person, eher die Bitte an alle allgemeinverständlcher zu formulieren.
Werte ich auch nicht als Angriff. Im Grunde hatte ich versucht, für den Laien zu erklären, was eigentlich eine dll ist. Damit schein ich kläglich gescheitert zu sein.
Vielleicht kann ich es so verbildlichen:
Formel 1: jedes Team baut sich sein eigenes Auto und forscht dran rum. Jeder hat mehr oder weniger etwas unterschiedliches. Red Bull z.B. baut sich sein Auto wie es das will, und definiert genaue Layouts. Sie gehen quasi ins kleinste Detail. ASN scheint dies (abstrakt gesehen) auch zu machen: die Jungs haben ne eigene DLL geschrieben.
IndyCar (damals zu meinen Zeiten von papyrus hieß es noch so): andere machen sich Gedanken. Es werden Einheitsautos gebaut. Die Teams nutzen am Ende nur die schon fertige Karosse und Kombinieren die mit eigenen Erfindungen bzw selbst ausgesuchten Motoren. Die Zulieferer welche z.B. die Karosse bauen, stellen sinngemäß eine dll dar. Das Team greift auf die Funktionen einfach zu, und kann anhand der guten Dokumentation ihr Auto zusammenbauen und benutzen. Die Hauptarbeit aber liegt in der Forschung vom Zulieferer (FSX=fsuipc). Sprich: ein Programm/Auto baut auf die Arbeit anderer auf.
@Guenther S. :
Ja eben nicht, das ist ja eben dass, was mich wundert ! Es gibt keinen kausalen Zusammenhang zwischen FSGRW, ASN und FSUIPC, also was soll soll denn nun ein FSUIPC update eingentlich bewirkt haben und wieso ?
Ich ging davon aus, ASN würde es brauchen, wenn das aber nicht der fall ist, hat ein FSUIPC update mit “FSGRW und ASN verstehen sich wieder” garnichts zu tun.
Man repariert doch ein defektes Getriebe nicht durch austausch des Kühlwassers, die wahrheit muss also wo ganz anders liegen.
Hilft Dir diese Antwort von Pete Dowson irgendwie?
“ASN uses the same hooks into the weather system as FSUIPC does for wind, temperature and pressure smoothing. There is no need and no point in FSUIPC also trying to do the same thing in any case, so the FSUIPC hooks aren’t needed. Please do not worry about them — update to 4.924 when available. There’s also a new facility in 4.924 which can provide a display of ASN’s plan weather weather data on WideFS clients.”
Aus der List of Changes bei Pete’s Updated Modules:
“A problem where the hooks used by FSUIPC4 to provide direct wind control were taken over by ASN’s installed FSX module, and thus stopping others making use of these even when ASN was not actually running, is fixed by enabling the full use of those hooks despite the module being loaded, yet allowing ASN to take over when it is actually running.
The actions of ASN taking over wind control and relinquishing it are logged in the FSUIPC4 log. For this to work, FSUIPC needs to detect the running of ASN. This needs an update of ASN from HiFi with a modified FSX module which gives an efficient and foolproof indication. Meanwhile, the only way to let FSUIPC direct wind controls operate is by disabling the loading of the AS CONNECT module(s) in the FSX DLL.XML file.”
Aha, joa, eben wird´s logischer, d.H. streng genommen, das problem wurde also durch die vorhergehende FSUIPC (respektive DWC, eine funktion die FSUIPC bis vor kurzem gar nicht kannte) verursacht, und durch eine neue Version, bei der man es schlichtweg abschalten- und einer anderen instanz (z.B. ASN Connect modul) überlassen kann.
FSGRW kennt DWC eigentlich gar nicht, d.H. es hätte OpusFSX, REX etc. ebenso betroffen. Klassischer fall von “dumm gelaufen”, ohne FSUIPC wäre es jedoch nie aufgefallen.
Danke dir !
Erklärt einiges…
fsuipc speist Wetter (wie eh und je) direkt in den FSX mittels hooks. Bisher haben alle Programme eben jene fsuipc calls verwendet. ASN nun hat eigene hooks implementiert, und fsuipc dachte sich “oh das macht schon ein tool? na da brauch ich ja nicht”… sogesehen 😀
Klingt programmiertechnisch auch mehr als logisch dies so zu lösen. Also ist demnach der Vorwurf der absichtlichen Wettbewerbsverzerrung seitens asn nicht haltbar.