Beiträge von FlyTweety

    Geht mir nicht in den Kopf wie die ein für's andere mal die Installation nicht auf die Kette kriegen.

    Was haben wir alle damals "gelacht", als Aerosoft permanent mal eine Datei vergessen hat oder eine alte in den Ordner gerutscht ist.

    Aber der Gigant Microsoft ist ja mittlerweile auf Augenhöhe, da fehlt mir gleich Content im Wert von 50 €...

    P.S.: Eigentlich fehlt er gar nicht, in der Installation ist er drin, der Sim zeigt ihn nur nicht an :/

    Glaube wir reden da komplett aneinander vorbei:

    ich sprach von UTL als "Konkurrenzprodukt" (nicht AIFP vs AIM!)

    OK, das habe ich tatsächlich mißverstanden.

    Aber ich sehe technisch AIM und UTL nicht direkt als Konkurrenz.

    Lässt man die Originalflugpläne ( die Outdatet sind) mal aussen vor, bietet UTL lediglich ein interessantes Framework für AI Traffic.
    Es ist in der Lage, die Schwächen, die bgl-basierter Traffic hat, auszumerzen oder zumindest zu verbessern.

    - Der FPS Impact ist deutlich geringer als bei bgl Traffic. Allein das macht eigentlich den Wert von UT2/UTL aus.

    - UTL Traffic folgt Routen. Die mögen derzeit nicht IRAC-aktuell sein, aber auch hier kann ein guter Programmierer was drehen. Roland Forster war (nicht nur in diesem Punkt) bei seinem AI Controller v2 schon auf einem richtig guten Weg, bevor er Sang und Klanglos von der Bildfläche verschwand :(

    Offenbar ist es möglich, sinnvolle Routen nach AIRAC Cycle als Batch zu erstellen (und somit die alten aus UTL zu ersetzen).

    - Es existiert ein grafisches Menü, das auch nach Erstellen des Traffics "Manipulationen" zulässt wie das schnelle Austauschen einer Livery oder gleich eines kompletten Models

    - sowie Spielereien wie Statistiken, Trockensimulationen ect..

    Wie gesagt, UTL ist für mich nur ein weiterer Microkosmos, in den der AIG Traffic eingebaut wird.

    Was um so leichter ginge, wenn AIM direkt XML Files ausgeben würde, so wie z. B. AIFP mittlerweile oder das Tool, das "koala" seinerzeit veröffentlichte.

    Damit wäre eine Zusammenarbeit für mich logischer gewesen.

    Zitat

    Wieso sollten wir "Konkurrenzprodukte" unterstützen?

    Genau darauf will ich ja hinaus. Warum? muss es als Konkurrenzprodukt erstellt werden?
    AIFP wird von einem Don Grovestine entwickelt, AIM offenbar von einem Kai P. Kamjunke.

    Ich kenne beide nicht persönlich, aber beide sind im Alpha India Forum hochaktiv.

    Warum war es nicht möglich, dass 2 Leute sich irgendwie verständigen können, die Brocken zu einem großen Wurf zusammenzuwerfen?

    Wir reden hier doch von Freeware, da gibt es keine Pfründe zu verteidigen oder Einkünfte zu verteilen.

    Ich naivling glaube immer, es geht darum, etwas besser zu machen als es vorher war. Und beide Programme in einem wären RICHTIG VIEL besser!

    So aber... haben beide vielleicht ihre Credits frei von anderen Namen, der unerfahrene Simmer aber hat immer noch einen Wildwuchs an Tools, aus denen er dem Baum im Wald nicht sieht...

    Wie wird dieser AI gesteuert?
    Extern so wie bei PSXSeecon oder UTLive oder per bgl/simintern?

    Ja, akutell mit BGL's vielleicht lassen die sich ja noch etwas einfallen wie es anders geht.

    Ich glaube das Flo darüber am meisten weiß.

    Da scheint es wieder eine bedauerliche Parallelentwicklung zu geben.

    In der AIG gibt es ja die Kompetenz, Flugpläne direkt für UTL verfügbar zu machen, der AIFP zeigt es ja bereits in der aktuellen Ausbaustufe, dass man es kann (OK, ist Beta, aber das tut der Sache keinen Abbruch).

    Warum man den Manager also von Grund auf auschließlich .bgl-Basiert entwickeln sollte erschließt sich mir nicht.
    Bzw. erstmal nur .bgl und dann später mal mühsam reinfrickeln.

    Eigentlich wäre so ein Tool der Grund, warum es eine sogenannte AI "Group" gibt. In der Gruppe kann man Wissen und Kompetenzen bündeln und zusammen entwickeln.

    Schon die Parallelentwicklung von Flight Planer und Manager kommt mir hier seltsam vor, rein von der Logik sind das 2 Module aus der selben "Problemgruppe", nämlich AI-Traffic.

    Somit sollte eigenlich der Manager ein Teil des Planers sein, oder der Planer eine erweiterung des Managers. Aber nicht 2 einpelne Programme...

    Schade, dass sich hier die Developer der AIG nicht auf einen gemeinsamen Nenner einigen können...

    D...Das Einzige, was ich mir bei P3D neben der 64-Version wuenschen wuerde, ist die Moeglichkeit des schnellen Repositionings. In der professionellen Flugsimulation existiert dafuer eine IOS (Instructor Operating Station), von der aus alle Szenarien, Malfunctions etc. ausgeweahlt werden koennen, uneter anderem auch eine Page mit Repositionings. Hier sind verschiedene Eintrittsspunkte fuer den Final Approach (12 Meilen, 3 Meilen etc. Entfernung zum Airport) definiert, ideal fuer das Landetraining und zum Testen. Ich vermute mal, das es P3D in den teureren Versionen mit enthaelt.

    Prinzipiell gibt es ja sowas ---> http://www.fsipanel.com/

    Ich habe jetzt nicht auf dem Schirm ob du Dickblech oder Windhunde fliegst, aber für ausgewähltes Dickblech und kleines A2A ist zumindest das Landetraining zu machen.

    Ohne das jetzt wieder im Kreis totdiskutieren zu müssen:

    Wenn alles taco ist solange die Kerne 2-6 nicht voll ausgelastet sind... warum hat dann nicht jeder 400 FPS bei 100% Traffic und einem tiefsystemer wie PMDG oder AXE bei einem Auslastungsbild wie bei dir?
    Da sind doch noch endlos Reserven, warum werden die nicht angetastet? An der GraKa kann´s nicht liegen, da der Traffic und die Systeme nicht zu 100% im Bild sind sondern nur im Hintergrund gerechnet werden.

    Oder zumindest stabile 60 FPS begrenzt, CPU Auslastung siehe oben.
    Nee, ich denke schon, in den 100% Auslastung stecken immer noch genug Tasks, die nicht auf getrennten Kernen arbeiten können und somit zum limittierenden Faktor werden.

    Nevertheless, wir gackern hier über ungelegte Eier solange LM nicht eine Roadmap auf den Tisch legt...

    @Flüchti
    Du hast soweit Recht, LM hat mehrfach geschrieben, die 64 Bit Geschichte würden sie gerne angehen, man wüsste nur nicht wann, viel Arbeit ect...

    Das mag ein (dieser) übereifriger Moderator überinterpretiert haben und schon mal das Statement raushauen, es würde bereits fest in die Tastatur gehauen. Übereifrige Moderatoren gibt es ja überall (hat da jemand Aerosoft gerufen? :D )

    Immerhin bekommt man derzeit das Gefühl, "offizielle" LM Vertreter sind im Forum nicht grade überaktiv. Ob die das überhaupt mitbekommen haben?

    Time will Show...

    P.S: Nach wie vor krankt P3D daran, das zuviele Sim-Prozesse auf dem ersten Kern (bzw. dem Hauptkern) laufen. Mit jeder Designänderung, die weitere Tasks auf Nebenkerne (oder weitere Rechner im Netzwerk) auslagern, ist Verbesserung der Performance in Sicht. Und das kann auch das Datenbankhandling sein.

    Ob Szenerie-Add Ons gar nicht betroffen sein werden halte ich für verfrüht spekuliert.

    Denn niemand (na ja, LM warscheinlich doch) weiß, wieviel alten Ballast sie bei einem so großen Projekt noch über Bord werfen. Baustellen gibt es ja genug.
    Warum sollten die nicht die gesamte Navaid-Struktur über den Haufen werfen? Diese völlig veralteten Daten, vollkommen unübersichtlich in hunderten bgl´s verteilt, dennoch arbeiten die Flächenaddons immer noch damit.
    Wenn dieses System also im Eifer des Gefechts mit grundüberholt wird (und ich hoffe inständig darauf), endlich auf eine AIRINC 424(A) kompatible Datenbank gesetzt wird (immerhin entwickelt LM in erster Linie für die professionelle Industrie), dann werden auch viele Szenerien über Bord gehen.

    Man kann nur feststellen, ein Moderator (NICHT LM) bestätigt, es wird an 64 bit gearbeitet. Nicht erwähnt wird, was im einzelnen in diesem 64 bit Progrämmchen alles aufgemöbelt wird...

    Ich gehe mal davon aus.

    Die Webseite hat NLS schon vor laaanger Zeit abgeschaltet weil es im Prinzip nichts zu zeigen gab (wer will schon Code Zeilen aus der Systemlogik als Screenshot haben :P ).

    Nach der Nummer mit den Scammer, der mit Screenshots von NLS ahnungslose Trottel abzocken wollte ist es sicher noch vernünftiger sich einfach geschlossen zu halten, bis es fertig ist.
    Jedenfalls ist es nach meinem Wissensstand jetzt nicht mehr an der sichtbaren Hülle sondern an der Software. Und da gibt es halt nix zu vermelden.

    Als hätten die Menschen nichts anderes zu tun.

    Die Menschen haben mit Sicherheit was anderes zu tun. Nur die Kinder, zu viele Jugentliche und die Masse an entwicklungsverzögerten "Erwachsenen" haben genug Motivation, eine Add On in diesem Entwicklungsstadium zu zerreissen.
    Ob sie sich in den 80´ern, in denen ich in diesem Alter war, auch die Mühe gemacht hätten, einen Leserbrief mit Tinte und Papier an die Redaktion zu schicken? Eher nicht... Internet halt, auch der Geringste kann die Stimme erheben!

    Ich habe grade mal aus Neugier den Unigine Valley Benchmark durchgejagt.

    Ergebnis: Bestialische Performance, stabil volle Taktung auf der GPU, maximale Temperatur 80° bei 53% Lüfterdrehzahl.

    Tatsache ist, an der Hardware liegt es nicht, die tut was sie soll und kann wenn die Software sie fordert.
    Und P3D v2.2 tut es nicht!

    So ähnlich schaut es auch bei mir aus. Die GPU taktet lastabhängig (Sapphire R290 Tri-X).
    Geht ja eigentlich auch, über Wiesen und Feldern mit aufgedrehten Wolkenschatten habe ich ja vollen Takt und 90% GPU (ohne, dass mir die Temperaturen an die Decke gehen) Tja, und dann kommt die Stadt und alles rauscht in den Keller ?(

    Das wage ich auch ziemlich auszuschließen.
    Ja, die GraKa taktet lustig hoch und runter, aber mit Temperaturen wird das nichts zu tun zu haben.
    Für die Übertaktung der CPU habe ich ja natürlich auch Stabilitätstests gemacht. Also alle Kerne100% mit Prime 95 über Stunden.
    Um die erreichten Temperaturen (max. 69°) gegenzutesten habe ich dann mal eine Zeitlang die Seitenwand aufgemacht. Dabei ist die Temperatur der Kerne grade mal um 2° gefallen.
    So ein Ergebnis hätte ich warscheinlich nicht, wenn ich im Gehäuse Durchlüftungsprobleme hätte. Da ist schon ein guter Umschatz gegeben.
    Man kann das nochmal explizit testen, mit mehr Luftstrom direkt auf das Board, aber wie gesagt, ich glaube nicht daran.

    Wie schon zuvor getextet kann ich Ralfs Beobachtung fast voll bestätigen.
    Nur die Vector-Geschichte kann ich nicht unterschreiben. Natürlich habe ich auch da gesucht und es probeweise mal deaktiviert, aber bei mir hat das keine Erlösung gebracht.

    Aber die Formel "je dichter die Bebauung desto geringer die Hardwarebelastung und somit auch die Frames", die kann ich bestätigen.

    Die gleiche Absurdität habe ich auch mal über Aerosofts Heathrow gemacht: Wollte den Traffic beobachten wegen neuer Shedule.
    Ich habe mich also mit dem ORBX BOB im Slew über den Platz gehängt. Nach ein paar Sekunden brechen die Frames weg auf 10-11. CPU runtergetaktet auf 3.6 Ghz, Last nur auf 70%.
    Einmal voll den Hebel nach vorne, über den Platz, am Ende wieder rückwärts. Unterwegs taktet die CPU wieder hoch auf 4.2 Ghz, die Last ist ordentlich bei 90-95% (immer nur den Hauptprozess). Frames jetzt auch ordentlich bei 20 (für EGLL mit satt Traffic nicht so übel).

    Das dauert dann 10 Sekunden, dann bricht alles wieder ein, CPU taktet runter, Last fällt, 10 FPS. Das Spiel kann man immer und immer wieder wiederholen.
    Das ist echt beknackt...

    Devinitiv ärgerlich!
    Die Testphase ist eh schon abgelaufen, außerdem, was ist die Alternative? Zurück zum FSX? Nicht wirklich!

    Rechnerseitig ist absolut kein Stein auf dem anderen geblieben, das einzige was seit dem FSX gleichgeblieben ist ist das Gehäuse und das Netzteil. Beides nicht wirklich im Verdacht, Performancebremsen zu sein.
    Gestern habe ich nochmals einen Testflug gemacht, in Schönefeld (Default) mit der F22 gestartet und dann immer richtung "Pott" mit 250 kts auf 3000ft. Interessanterweise tritt dabei mein Phänomen deutlicher zu Tage.

    Bis hinter Paderborn (Default) immerhin doch 33 PFPS gelockt. Mit Wolkenschatten sogar, Graka-Last sogar bis 90%.
    Dann in Sichtweite von Dortmund (Aerosoft) geht die Prozessorlast merklich um 10 % runter auf Durchschnittlich 70-75%, die GraKa geht auch runter auf 50-60%, und die Frames stürzen senkrecht ab Richtung 15-20 FPS , gelegentliche Ausreisser in den einstelligen Bereich.
    Das ging dann so bis hinter EDDL von Aerosoft, ungefähr im Queranflug von Mönchengladbach klettern die Frames wieder, analog zur Hardwarenutzung, die Landung in Geilenkirchen war wieder smooth bei 33.

    Es ist also offenbar so bei mir, je anspruchsvoller die Szene (es hat ja schon eine Menge Häuser im Ruhrgebiet) desto weniger wird meine Hardware ausgenutzt. Die Last sinkt, die Frames werden lächerlich!

    Finde den Widerspruch...