Beiträge von Boris

Das wird vermutlich deswegen nichts nützen, weil auch der alte Flughafen Quito nicht bedient wird. Siehe UTLive Ecuador (in Statistics).

Da gibt es nur SETN, SEGU und SETM - und sinnigerweise zwei (!) Airports auf den Galapagos-Inseln

Moin,

Das liegt dann wohl daran dass SEQM bei UTLive standardmäßig nicht bedient wird. Auch nicht nach dem Update von letztem Dezember (das ich mir gerade gezogen habe und dann festgestellt habe dass es einen 5-seitigen Forenthread generiert hat - möchte nicht wissen was es mir wieder alles zerschossen hat )

Man kann wohl händisch fuddeln, da habe ich aber keinen Plan von.

Die Bezahlware geht nicht für v4.5, oder?

Du sollst bei Tag fliegen

Zitat von strzag

Boris , hast du die Pappnase gesehen läuft voll in die Turbine springt aber über den Schlauch

Irgendwie erwarte ich immer noch dass Alice um die Ecke kommt und die beiden mit ihrer Pump Gun umnietet...

Zitat von Rafi

Bei mir verlief das Update ohne Problem und GSX sowie alles andere funktioniert weiterhin einwandfrei (abgesehen von den üblichen GSX Macken).

Schmeiß deinen PC aus dem Fenster

Darf ich dich ein bisschen bewundern oder beneiden?

Wenn noch einer postet dass das Update bei ihm funktioniert hat schmeiß ich MICH aus dem Fenster...

Gibt's auch Kanisterbetankung?

Aber das sind vielleicht Sausäcke! Nach dem letzten Update ist Flightbeam als Publisher aus dem Addon-Manager verschwunden, und damit auch die darüber verwalteten Szenerien. So long, KPHXv1 - kauf die gefälligst die neue Version...

Dann haben sie schon einen 5 Seiten langen Thread im Forum "GSX is not working after update" - ich trau mich gar nicht, es auszuprobieren.

Weiters stürzt mir dauernd Couatl ab, mit einem seitenlangen error log, und ich soll die neueste Standalone-Version installieren - ja was hat das Update denn dann gemacht???

Mann mann mann

Ich habe keine Markierung erwischt bei der überhaupt etwas angezeigt würde. Liegt wohl an der Karte und nicht an Google Maps.

Aber schau hier nach - ist die gleiche Karte.

Spotlights sind installiert, und das ist ja nun wirklich eine deutliche Verbesserung der Cockpit-Beleuchtung. Endlich nachts fliegen ohne Augenkrebs, und auch wenn alles an ist, bleiben die Frames gleich

Es soll wohl ein Thema geben, dass wenn an einem Airport viel Dynamic Lighting ist, P3D dann wahlfrei Lichtquellen wegschaltet, und als erstes die in der Nähe des Blickpunkts, aber ma guggn. Jetzt müssten sich die Lichter nur noch extern (Key Command, FSUIPC) ansteuern lassen - da tun sich Möglichkeiten auf...

Insofern hat mein Gemecker meine sachlich vorgebrachte Kritik am Unwillen des Entwicklers, sein am Markt eingeführtes Produkt nach Kundenfeedback weiter zu pflegen, mir ja doch was gebracht. Jetzt könnt ihr auch das Wasser auf die Scheiben bekommen

Na dann warte ich mal bis der Herr Kalamares meine Registrierung in seinem Forum bestätigt.

Die .profile - Datei ist für Tomate, oder?

So wie ich die .ini - Datei verstehe wird bei der -700 die x-Position der Lampen nicht passen. Aber die kann man ja ändern. Sind ja nur 60 Einträge

Aber gehen die ganzen zusätzlichen Lichtquellen nicht auf die Performance?

27 Beiträge - und ich dachte es gibt Diskussion / Überlegungen (Informationen eh nicht) zu dem Unfall. Statt dessen wird wegen einer flapsigen Bemerkung kollektiv gebasht. Das erinnert mich doch leider sehr an die versammelten Kleingärtner und Kaninchenzüchter die damals Nico und Stephan rausgeekelt haben - und so was will ICH hier nicht mehr haben.

Und die Maik-Moralkeule lass ruhig stecken, Peter. Auch ich habe ihn gekannt und gemocht, aber deswegen schleiche ich nicht den Rest meines Lebens im Flüsterton um das Thema rum. Aber ich begrüße es immerhin dass du dich auch außerhalb der Politikecke mal in ganzen Sätzen artikulierst uns nicht nur in Videos.

Wenn ein Austausch, wie auch immer der aussieht - und es sind IMMER Spekulationen, denn NIEMAND hier hat die Fakten (außer vielleicht Peter, der ja stets alle kennt) - zu Flugunfällen hier nicht gewünscht wird, dann bitte auch die Originalposts dazu grad löschen oder sperren. Verfolgen kann man das auch anderswo.

Gib ma Screenshot

Vergiss Mouse Macros in einem Home Cockpit. Hab ich alles durch, schafft nur Frust. Mal geht's, mal nicht. Mach dich mit der Programmierung vertraut und "verdrahte" Hard- und Software eindeutig und nachvollziehbar

FSUIPC / Linda alleine bieten nur Eingabemöglichkeiten für direkt registrierte Eingabegeräte (also Tastatur und Controller). Für alles andere, also Eingabe über Cockpit-Hardware bzw. Ausgabe an diese) brauchst du irgendeine Schnittstellensoftware wie z.B. SIOC, die zwischen FSUIPC und der Hardware sitzt.

Klar könntest du einen Encoder über ein Controller-Interface (z.B. von Leo Bodnar) als zwei Buttons konfigurieren und dann jedem Button über FSUIPC ein Tastaturkommando zuordnen, über das du dann in einer PMDG die Höhe im MCP rauf- und runterdrehst, aber glaub mir, damit wirst du auch nicht froh. Außerdem willst du die Höhe dann immer noch auch im Display deines Hardware-MCP sehen, und da muss sie ja irgendwie hineinkommen.

Der XFR-Switch geht auch nur in Zusammenhang mit dem kompletten COM-Modul

Das COM der 747 sollte doch wie auch bei der 737 mit FS-Standardfunktionalität laufen. SIOC hat ein Script dafür, das du dir an deine Hardware anpassen musst: modulo_COM.txt (nur für COM1).

Zu definineren ist:

• zwei Encoder
• zwei Displays
• zwei Ausgänge (die Dezikmalpunkte)
• ein Schalter als Pushbutton

Dann sollte das eigentlich schon laufen. Erst mal mit einem Standardflugzeug testen.

Zitat von Speedbird 2652

Was ist denn an dem VC so grässlich?

Das hier:

Wasser auf der Scheibe, du lieber Himmel

Dass sie all die Jahre nix gegen diese grässlichen VC-Nachttexturen getan haben find ich viel trauriger. Aber da bekommst du immer nur zu lesen das geht bei dieser Technologie nicht anders.

Aber The Great Randazzo wird's schon richten...

Was willst du denn jetzt machen? Was für Flugzeug/Cockpit-Software verwendest du? COM / Audio Panel / XPDR sind da ja einigermaßen trivial, da Standard-Sim-Funktionen, aber SIOC kann es schon in sich haben, und über die Dokumentation brauchen wir nicht reden

Falls es PMDG ist, schau dir diese Seite an: http://flightsim4fun.com/index.html - ohne das geht's da nicht. Vergiss PMDG Cockpit Builder, das wird nie was.

Für COM etc. gibt es fertige Skripts, aber die muss man trotzdem lesen können um sie auf den eigenen Sim anzupassen. Fang mit was Einfachem an - Lichtschalter oder so was, damit du ein Gefühl dafür bekommst.

Ich will da auch demnächst wieder ran

Herrje, jetzt komm ich auch noch mit den Begriffen durcheinander Natürlich add-on.xml. Aber mit der Antwort kann ich trotzdem nix anfangen. SDK-konform? Weil wegen isso? Sorry wenn ich als Nicht-Entwickler das SDK nicht auswendig kenne, aber welchen Sinn soll das haben, allen Szenerien dann doch den gleichen Layer zu geben? Und müsste das dann nicht regelmäßig mit der scenery.cfg abgeglichen werden?

Ich gehöre nun mal zu denen die sich nicht einfach auf Tools verlassen sondern verstehen und auch kontrollieren wollen, was in ihrem Simulator passiert. Hilft manchmal weiter #SODEwindsocks...

Können wir bitte mal eindeutige Begriffe verwenden - da kommt man ja ganz durcheinander, zumal in meinem Alter

add-on.xml: Das sind die Dateien, in denen die Komponenten einzelner (oder mehrerer) Addons beschrieben sind. Also scenery, texture, effects, simobjects usw. Davon hat der durchschnittliche P3D-Bastler und Flieger für gewöhnlich JEDE MENGE.

add-ons.cfg: Das sind die Dateien mit denen die Addons im Simulator registriert werden. Davon gibt es zwei: Eine in %ProgramData%, eine in %AppData%, jeweils bei "Lockheed-Martin\Prepar3d v4". Die in %ProgramData% ist für alle Benutzer, die in %AppData% nur für den, dessen AppData das sind.

Alle Addons, die unter \Benutzer\Dokumente\Prepar3d v4 Add-ons\ eingetragen sind, werden in der add-ons.cfg in %AppData% registriert. Macht ja auch irgendwie Sinn. Leider scheren sich die meisten Addon-Hersteller nicht um irgendeinen Standard, sondern melden sich an wo es ihnen gerade passt - auch ungefragt. So was hasse ich.

Welche Addons dann per LM-Konzept in %ProgramData% registriert werden sollen, erschließt sich mir jetzt allerdings nicht, denn alle Addons sind ja irgendwie benutzerspezifisch.

Fallbeispiel (wer's glaubt, wird selig):

Benutzer A und B verwenden den P3D auf dem gleichen PC. Benutzer A hat investiert und sich Airports von FS Dreamteam gekauft. Die tragen sich in seiner (%AppData%) Konfiguration ein. Benutzer B hingegen, der kein Geld für FS Dreamteam ausgeben will, fliegt Default-Szenerie.

Anmerkung / Frage: Kann man den P3D tatsächlich unterschiedlich konfiguriert für mehrere Benutzer einrichten? Wenn ja, würden alle Konfigurationen in %ProgramData% für alle Benutzer angewendet werden (es gibt ja auch die exe.xml und dll.xml doppelt) und die Konfigurationen in %AppData% jeweils benutzerspezifisch dazu geladen werden.

Zur Frage 2:

Ich löse das innerhalb des jeweiligen Addons über die Reihenfolge der Einträge und das "Layer"-Argument. In meiner scenery.cfg (in %ProgramData%, also für alle Benutzer) steht nur P3D-Standard und ORBX - die machen das ja noch so. Sie endet aktuell bei Layer 220. Ein Addon, das eine Höhenkorrektur mitbringt, die sich mitunter gerne ungefragt in \scenery\world\scenery installiert, bekommt einen eigenen \AEC\scenery - Ordner, der wie folgt in der add-on.xml eingetragen ist:

<?xml version="1.0" encoding="UTF-8"?>
<SimBase.Document Type="AddOnXml" Version="4,0" ID="add-on">
  <AddOn.Name>SBSL Sao Luis</AddOn.Name>
  <AddOn.Description>Freeware Sceneries</AddOn.Description>

  <AddOn.Component>
    <Category>Scenery</Category>
    <Path>E:\P4D_AddOns\Scenery\Freeware\SBSL Sao Luis\AEC</Path>
    <Name>SBSL AEC</Name>
    <Layer>2</Layer>
  </AddOn.Component>

  <AddOn.Component>
    <Category>Scenery</Category>
    <Path>E:\P4D_AddOns\Scenery\Freeware\SBSL Sao Luis\SBSL_LC</Path>
    <Name>SBSL Terrain</Name>
  </AddOn.Component>

  <AddOn.Component>
    <Category>Scenery</Category>
    <Path>E:\P4D_AddOns\Scenery\Freeware\SBSL Sao Luis\SBSL</Path>
    <Name>SBSL Sao Luis</Name>
  </AddOn.Component>

</SimBase.Document>

Gelesen wird die add-on.xml von oben nach unten - was zuerst kommt, wird zuerst geladen. Das Layer-Argument wirkt auf die Priorität der Szenerie. Wie genau der Ladevorgang nun funktioniert, kann ich nicht sagen, aber im Prinzip verhält es sich so:

In der scenery.cfg staht auf Layer 2 das hier:

[Area.002]
Title=Default Scenery
Local=Scenery\BASE
Active=TRUE
Required=TRUE
Layer=2

[Area.003]
Title=ORBX!VECTOR_AEC
Local=ORBX\FTX_VECTOR\FTX_VECTOR_AEC
Active=TRUE
Required=FALSE
Layer=3

Jetzt kommt meine add-on.xml und schiebt die Höhenkorrektur für SBSL dazwischen - so passt die Priorität dann später. Dann geht es mit der scenery.cfg weiter bis zum Layer 220, dann kommen (quasi als 221 und 222) die Layer für die SBSL Landclass (zuerst) und den Airport (danach).

Abschließende Frage an Capt. PERO: Warum setzt SimStarter ein Layer-Argument in die add-on.cfg - Dateien? Bei mir steht überall Layer 212 (weil bei der Einrichtung von SimStarter das höchste Layer in der scenery.cfg 211 war. Das ist jetzt nicht mehr der Fall. Auf Airport-Ebene macht das zwar nix, aber mit diesem Layer-Eintrag werden jetzt alle von Simstarter bei der Einrichtung erfassten Szenerie-Addons zwischen meine ORBX-Airports geschoben. Wenn das mal nicht irgendwann Probleme gibt...