Beiträge von Robert

    Ich kämpfe gerade auch mit mir, ob EZdok, weil gerade eine 64 bit Version gestrickt wird oder Chaseplane.
    Aber offenbar gibt es Chaseplane immer nur in der Betaversion. Nutzt das jemand schon mit P3D V4 und kann was zur Fehleranfälligkeit sagen? Immerhin kostet das Teil in einer Betaversion 39 Schleifen.

    Nein, ich habe da nirgendwo etwas eingetragen. Wo finde ich denn diese cfg und was muss ich denn da definitiv eintragen?
    Das mit den Schatten denke ich, wird es nicht sein, denn bei den anderen scheint es ja auch zu laufen.

    So, habe mir die MTLs geladen (Danke für das zur Verfügung stellen) und entsprechend der Anleitung

    "Die "Installation" ist super einfach. Nur den Ordner herunterladen und im MTL Verzeichnis im Flusi einfügen und überschreiben ;) Die Ordnerstruktur ist passend."


    kopiert. P3Dv4 läuft, die IVAP läuft auch, aber es ist kein Verkehr zu sehen. Habe mich extra mal in Frankfurt platziert, wo gerade B747, A320 etc. runterkamen. Leider war keiner der 4 anfliegenden und landenden Flugzeuge auf dem Schirm zu sehen. Woran kann es liegen?

    By the way: Ich kann keine Deboarding und Boardinggeräusche mehr von den Passagieren bei Groundservices hören. Alle anderen Geräusche wie Catering oder Baggage sind hörbar. Was könnte denn da die Ursache sein? Ebenfalls P3D V4.

    Leider ist GES vpm ORBX mit Fehlern behaftet, die nichts mit Addonscenerien, sondern mit fehlerhafter Programmierung zu tun haben. Ich habe heute GES gekauft und hatte auf meinem Flughafen Plattformen, Mulden und am Anfang und am Ende der Landebahnen (und zwar auf der Landebahn) hohe Hügel.
    Nachdem ich im ORBX Forum darüber berichtet habe, kamen von anderen Usern ebenfalls Meldungen dazu.
    Nach Aussage eines der Entwickler wurde da tatsächlich fehlerhaft gearbeitet und man würde sich bemühen, schnell Abhilfe durch ein Patch zu schaffen. Ich bin gespannt.

    @Flori Wan Kenobi (echt starker Name,wenn ich das mal sagen darf. Bin ein Riesenfan von Star Wars und Co. !!) Warum nicht überzeugende Argumentation? Ich meine, wenn ich die Crashdetection abschalte, dann kann ich fliegen wie ich will, egal, ob ich die physikalischen grenzen überschreiten würde oder nicht. Ich würde niemals bemerken, wenn ich ein Flugzeug überbelasten würde oder nicht.

    Für mich ist es aber beim Flusi wünschenswert, dass ich, nach Möglichkeit der bestehenden Programmierung, auch die simulierten physikalischen Grenzen einer Maschine nicht überschreite, damit sie in der Luft nicht auseinander bricht.
    Ich fand übrigens vor Kurzem einen Flug mehr als interessant. Ich bin dabei in einen Sturm gekommen, der so stark war, dass die Maschine tatsächlich auseinanderbrach. In wie weit das nun real sein könnte, weiß ich zwar nicht, aber es hat mich gelehrt, dass ich nun starke Unwetter, wenn sie auf dem Wetterradar als dunkelrot erscheinen, umfliege, so, wie es echte Piloten auch tun, um Maschine und Passagiere zu schützen. Ich habe vor Kurzem noch ein altes Interview von 2009 gelesen, wo ein Jetpilot erklärte, wann er noch in eine Gewitterzone einfliegt und wann nicht. Das Resultat war, dass eine grüne Zone mit kleinem roten Kern durchgeflogen wird, eine Zone mit kleinem grünen und weit ausgedehnten roten Kern komplett umflogen wird, ohne auch nur den grünen Bereich zu tangieren, so weit das möglich ist.
    Aber mich würde schon interessieren, warum meine Argumentation nicht überzeugt.
    xplaneR: Welche hochgezüchteten Addons haben denn eigene Fehlermodelle?

    Wenn ich Online fliege, was ich momentan aber nicht mache, weil die MTL bei Ivao nicht funktionieren und ich derzeit nicht die Lust verspüre, nach VATSIM zu wechseln (obwohl ich dort einen Account habe....), habe ich vor dem Einloggen natürlich die Kollision abgeschaltet. Kurz vor dem Start schalte ich sie wieder ein. Nach der Landung und dem Verlassen der Rollbahn wird sie wieder abgeschaltet.
    Wenn ich offline fliege, habe ich sie halt immer an, um bei Fehlern auch die "Konsequenzen" zu spüren :)

    Da hast du natürlich nicht unrecht, was das unerwartete "crashen" betrifft. Ich speichere bei längeren Flügen immer mal wieder zwischen, so dass ich ggf. dort weitermachen kann, wo ich crashen würde. Ich habe aber bisher immer das Glück gehabt, dass ich bzgl. Flusifusch erst einmal gecrasht bin. Dabei weiß ich aber nicht mehr, was es war. Kann sogar ein anderes Systemproblem gewesen sein. Und gerade zu Anfang meiner langjährigen Abstinenz war ich eher bei der Landung gecrasht, weil ich zu hart aufgesetzt hatte etc. etc. :-). Da konnte ich dann immer wieder üben, weil ich 10 Minuten vor einer Landung zwischengespeichert hatte.
    Ist es bei dir denn schon öfter dazu gekommen, dass dein Flusi wegen Fusch oder beim taxeln gecrasht ist?
    Das würde mir dann auch zu denken geben.

    Ich rege mich ja auch nicht auf, sondern frage mich einfach, wie so etwas passieren kann und habe mal "laut" über mögliche Folgen nachgedacht. Im Übrigen haben kleinere Firmen kaum einen teuren Supportvertrag. Und wenn da was passiert, bleibt es letzten Endes auch nicht gerade ohne finanzielle Folgen.
    Von der Absturzorgie hier bin ich ja verschont geblieben, da ich eh P3D V4 installiert habe.

    Grundsätzlich finde ich das aber schon unmöglich, dass nach einem kumultativen Update eine Software nicht mehr läuft. Ich habe von Programmierung keinerlei Ahnung, aber ich finde es bedenklich, wenn ein Update gekaufte Software einfach abstürzen lässt.
    Ich frage mich da, wer denn für so etwas dann die Verantwortung trägt. Ich meine, bei einer Software für ein paar Euro kann man das ja noch verschmerzen. Ich denke aber beispielsweise an Firmen, die vielleicht für Zigtausend Euro wichtige Firmensoftware gekauft haben und plötzlich der Betrieb stillsteht, weil ein Betriebssystemupdate die Produktion stoppen lässt, mit all den finanziellen Folgen.