Beiträge von ACMG

Das Forum befindet sich im reduzierten Betrieb. Die Addon- und Supportforen bleiben weiterhin verfügbar.
Bitte beachte, dass OMSI nicht mehr weiterentwickelt wird. Ein Teil der Entwickler widmet sich inzwischen der Entwicklung eines neuen Simulators. Weitere Informationen zum LOTUS-Simulator findest Du hier.

    Ich sehe keine Zeilenumbrüche, wo ich eigentlich welche erwarten würde. Geht OMSI vielleicht auch so. Für jedes Fahrzeug müsste zum Beispiel eine Zeile vorhanden sein. Ansonsten erwartet OMSI nach dem Repaint-Namen nämlich ein Anfangsdatum, ab wann dieser Eintrag gilt. Hier folgt aber die Wagennummer des nächsten Fahrzeugs. Und die ganzen Group-Einträge müssten auch in einer eigenen Zeile stehen.

    Auch hätte ich mir KI-Versionen der Busse gewünscht, die reduziertere Skripe haben und so auch noch etwas mehr zur Verbesserung der Performance beigetragen hätten.


    Die KI-Version ist quasi schon mit drin, so wie es eigentlich immer gemacht werden sollte: Es gibt ein Main-AI-Skript, das einen {frame_ai} enthält. Der {frame}-Teil aus dem normalen Main-Skript sollte dann gar nicht mehr ausgeführt werden. Im AI-Frame stehen nur ein reduziertes Antriebsskript (direkt) und die Aufrufe des Frame-Teils vom Türskript, Lichtskript, Wimpelskript, eines Trägheits-Makros und eines speziellen KI-Makros für die Zielbeschilderung. Hat den Vorteil, dass die Performance geschont wird und die Busse trotzdem vom Spieler übernommen werden können.


    Schade dass es noch kaum Repaints für die Busse gibt (oder hab ich was verpasst?), ich hätte sie ja gerne auch in HH, Berlin und Mainz eingesetzt.


    Das finde ich auch schade, mich würden jedoch eher ASEAG-Werberepaints interessieren.

    Zitat

    86 19:51:00 - - Error: Failed loading AIList maps\X10 Berlin\ailists.cfg


    Tja, mit der AI-Liste stimmt ganz offensichtlich irgendetwas nicht. Mögliches Vorgehen:

    • Dateiname überprüfen, also heißt die Datei richtig?
    • Eine Kopie der Liste anlegen und dann die Liste stark reduzieren und nach und nach mit dem Inhalt aus dem Backup erweitern. Nach jeder Änderung einmal versuchen, die Map zu starten und schauen, ob der Fehler im Logfile ist.
    • Sobald der Fehler erscheint, muss das Problem wohl dem davor eingefügten Abschnitt liegen.

    die Stützen vom Dach werden gerade gebaut ist auch so gut wie fertig, dann kommt noch Bahnhof Schilder wo Rathaus Spandau steht, sollte es reichen?


    Schon besser, aber noch etwas filigran. Die Stützen sehen in echt noch was dicker aus. Hier hat es noch etwas von einem Gewächshaus durch die dünnen Stützen und Träger.
    Dass es beim DB-Bahnhof "Berlin-Spandau" auf den Schildern heißen muss, wurde ja schon gesagt. Damit könnte es für meinen persönlichen Geschmack dann auch schon reichen, aber das müsste ich dann auch nochmal auf Bildern sehen und vergleichen, um es wirklich bewerten zu können. Oberleitung fehlt da ja auch noch, die trägt viel zum optischen Eindruck bei.

    Die genauen Komponenten wären noch interessant. Wenn du selbst konfiguriert hast, solltest du ja eine Liste haben. Wenn der Laptop sozusagen ein Fertigprodukt ist, müsste es eine Modellbezeichnung geben.
    Zum Beispiel hast du nicht geschrieben, ob es noch einen weiteren Grafikchip auf dem Motherboard gibt.

    Dass Grundorf bei der Hardware stark ruckelt oder sonstwie Probleme macht (so wie ich das verstehe, hängt OMSI sich auch oft komplett auf?), ist definitiv nicht normal, jedenfalls keine Sache der Grafikeinstellungen. Ich hatte selbst auf meiner 2009er Kiste (bis vor 1,5 Jahren noch genutzt) auf Grundorf mit recht hohen Einstellungen nicht diese Probleme.
    Hat der Laptop auch so einen billigen Onboard-Grafikchip mit Shared Memory? In diesem Fall kam es bei anderen schon mal vor, dass dieser statt der Grafikkarte verwendet wurde, wenn ich mich recht entsinne.

    Erst einmal danke für deine ausführlichen und bebilderten Erklärungen. Die Geschichte mit der X-Achse und dem Objektursprung hatte ich bereits verstanden.


    Hier hakt es mit meinem Verständnis: Ich habe einen Objektursprung im 3D-Modell (o3d- oder x-Datei). Wenn ich das Objekt in den Bus einsetze, liegt der Objektursprung zwangsweise immer dort, wo alle anderen Objekte auch ihren Ursprung haben, bei einem Bus also sozusagen in dem Bus-Ursprung, also dem (0,0,0) des Bus-Koordinatensystems (BKS). Nun kann ich das Rad direkt an der richtigen Stelle im BKS exportieren oder mit seinem Ursprung in der Mitte des Rades. Im ersteren Fall muss ich mit origin_trans den Ursprung für die Drehanimation dann verschieben. Im zweiten Fall muss ich erst dafür sorgen, dass das Rad an der Stelle landet, wo die Achse ist. Das geht offenbar nur per Daueranimation. Da brauche ich dann ein origin_rot_ und ein anim_trans darunter. Für die Drehung müsste ich dann ein zweites newanim einfügen und in diesem kann ich origin_from_mesh benutzen, weil dieser sich dann auf den durch die Daueranimation verschobenen Ursprung des Rad-Objektes bezieht. Habe ich das richtig verstanden?


    Mit der Weite -1 wird die Animation vom Script festgelegt (Siehe Tachonadel, Räder, etc.), dann steht die Bewegungsweite in der Konstantendatei drin. Das ist wichtig, wenn etwas nicht linear bewegt werden soll (siehe Motortemperatur, Tachonadel oder ähnliches). Das hat etwas mit der Skalierung der Texturen zu tun.


    Das verstehe ich nun überhaupt nihct mehr. Welcher Wert soll -1 sein? Und das Script bestimmt doch sowieso den Wert der Variablen. Da gibt es noch die curves, meinst du so etwas?


    Außerdem kann ich noch eine Animationsgeschwindigkeit festlegen:
    maxspeed
    300


    Eine Geschwindigkeit ist eine physikalische Größe Weg pro Zeit. Was bedeuten die 300? Meter pro Sekunde? Kilometer pro Stunde? Grad pro Minute?


    Jede einzelne Animation kann nur eine einzige Variable haben. Eine zweite Variable benötigt einen weiteren [new_anim] Befehl. [...] Da du zwei Variablen nutzen möchtest, mußt du zwei Animationen einstellen. Hierfür kannst du den Objektursprung immer wieder neu einstellen. Achtung, nicht umstellen, sondern von Grund auf neu einstellen!


    Danke für die Klarstellung!


    Nein mehr gibt es aber nicht. Du kannst den Objektursprung drehen oder / und verschieben und das Objekt selbst. Alles weitere unter der Weite sagt nur aus, wie die Animation gemacht werden soll.


    Schon, aber das ist ja nicht ganz irrelevant. Sonst gäbe es das nicht.

    ;)


    Soetwas wird niemand erstellen, weil die Möglichkeiten einfach zu umfangreich sind.
    Ein kurze Erklärung wäre es für jeden Bedarf einzeln anzupassen.


    Ich will ja nicht jede Möglichkeit erklärt haben, aber die möglichen Befehle und ihre Bedeutung würden mir schon reichen:

    • origin_from_mesh
    • origin_rot_x, origin_rot_y, origin_rot_z
    • anim_trans
    • anim_rot
    • anim_scale (falls es das geben sollte?)
    • ...(hab in manchen CFGs noch was anderes gesehen, kann mich aber nicht dran erinnern)...


    Und dann eben zusätzlich der generelle Aufbau und das Konzept (alles auf X-Achse bezogen und so weiter). Dabei könnte auch die Frage beantwortet werden, ob ich in einem [newanim] ein anim_trans, dann ein anim_rot und darunter wieder ein anim_trans packen kann oder nicht.
    Würde das Wiki funktionieren, könnte ich dort Beiträge editieren und würde ich mich auskennen, dann würde ich selbst zum Beispiel wenigstens versuchen, eine solche grobe Doku dafür zu erstellen. Dass das nicht jedem blutigen Anfänger hilft, der keinen Plan von Scripting hat, mag ja sein. Aber wer das Skriptsystem verstanden hat, der versteht eben noch lange nicht das Konzept von newanim.


    Jedenfalls sahen nicht alle [newanim]-Einträge so aus:
    [newanim]
    (origin_... oder XYZ mit Wert)
    anim_(trans/rot)
    Variable
    Wert


    Was macht zum Beispiel das hier aus Morphis Citaro FL?


    Dein Denkfehler liegt in der Überlegung in einer Dimension. Du möchtest aber in zwei Dimensionen verschieben. Also mußt du auch die Achse entsprechend ausrichten. Die kürzeste Verbindung zwischen 2 Punkte ist die Gerade und nicht der Umweg. In der von dir vorgegebenen Variante führt Omsi beide bewegungen aus. Allerdings hättest du das auch mit einer Bewegung machen können.


    Geht nicht, weil ich die Werte der Verschiebungs-Variablen nicht kenne und diese unabhängig voneinander sind. Nun kann ich mir natürlich kompliziert daraus einen Vektor machen und mir mit den trigonometrischen Funktionen den Winkel ausrechnen sowie die Länge des Vektors, damit ich das in einer origin_rot-Geschichte unterbringen kann (falls die auch Variablen statt Werte nehmen, ist ja nicht dokumentiert?). Oder ich verschiebe gleich komponentenweise, was deutlich einfacher machbar sein sollte. Das Ergebnis ist ja dasselbe.


    origin_from_mesh


    Hier wird der Objektursprung in Blender ausgerichtet.


    Hier frag ich gleich mal ganz blöd: Welchen Objektursprung habe ich denn sonst noch? origin_from_world? Oder nur die Angabe XYZ? Was an einem Bus hängt, das ist ja erst mal immer auf dasselbe Bezugssystem konstruiert bzw. wird von OMSI so interpretiert. Für meine Verschiebungen brauche ich beides eigentlich nicht, der Ursprung soll in (0,0,0) liegen.


    Heißt für deine Animation:
    Du möchtest nach hinten (-Y) und nach Oben (+Z) verschieben. Dann mußt du auch beides eintragen und nicht über zwei Um-Wege einen Weg ausführen:


    Wie gesagt, ich will das von zwei Variablen abhängig haben. verschiebung_X soll in negative Y-Richtung wirken und verschiebung_Y in positive Z-Richtung. Das ist sozusagen Vorgabe und daher passt dein Beispiel leider nicht.


    WICHTIG: Omsi kann immer nur eine einzige Animation ausführen. Diese Animation wird generell nur über die X-Achse ausgeführt. Also muß der Objektursprung entsprechend verdreht werden!


    Was heißt das genau? Dass es nur einen anim_trans oder anim_rot oder anim_wasesimmersonstnochgebenmag pro newanim geben kann?


    Eine Verschiebung um 1 mm ist aber auch sehr gering. In Omsi kaum feststellbar. Die Werte beziehen sich auf 1 meter mit 7 Stellen nach dem Komma. Solche Millimeter oder µm machen nur bei der Festlegung von Rotationen Sinn, damit das Objekt nicht eiert.


    Da sind doch noch die Variablen. Wenn in einer davon 500 steht, dann wird das Objekt um einen halben Meter verschoben, weil 0.001 Meter x 500 = 0.5 Meter.


    Soweit Verstanden?


    Ich glaube zumindest verstanden zu haben, dass ich nur ein anim_... pro newanim verwenden darf. Richtig?

    :)


    Danke für deine Erklärungen! Einen Überblick über die Möglichkeiten vermisse ich jedoch immer noch. Das zitierte Beispiel aus dem Citaro FL etwa zeigt ja, dass es noch mehr gibt als origin und anim.

    Hallo,


    ich habe bereits die Foren- und Google-Suche bemüht, bin aber immer nur auf Problemlösungen für konkrete Fälle gestoßen.
    Gibt es irgendwo eine vernünftige Dokumentation für [newanim], wo die gegebenen Möglichkeiten und Unmöglichkeiten für Animationen in OMSI richtig erklärt werden?


    Mein konkretes Problem ist eher von geringer Dringlichkeit, weil ich es auch mit zwei getrennten newanim-Einträgen lösen konnte:
    Ich will ein Objekt in zwei Richtungen verschieben, z.B. Y- und Z-Achse. Ich bin davon ausgegangen, dass ich das mit einem newanim-Einträg folgender Struktur machen kann, aber dann wird nur die zweite Verschiebung durchgeführt.


    verschiebung_Y soll in negative Y-Richtung verschieben.
    verschiebung_Z soll in positive Z-Richtung verschieben.


    Sichtbar ist nur die Z-Verschiebung. Anders ist es bei Aufteilung auf zwei newanim-Einträge:


    Und ich würde gerne verstehen, warum das so ist und ob ich das auch in einem Eintrag erledigen kann. Ohne Dokumentation für Animations-Anfänger in OMSI kaum möglich.

    Die Frage wäre eher, was genau für Scripts. Beim Ibis kann ich nämlich nicht wirklich den unterschied zwischen normalen Citaro und RB finden. Aber irgendwo muss es ja sein, wenn es 2 versch. gibt. Da es ne Schrift ist, wäre es an sich ja eigentlich eine Font noch nicht?


    Schau dir in der zugehörigen model.cfg die Einträge der Texttexturen an. Die Font könnte anders sein, aber auch die gewählte Auflösung der Texttextur hat Einfluss auf die Darstellung: Wenn ich die Breite der Textur erhöhe, dann wird der Text horizontal gestaucht, bei Verringerung in die Breite gezogen.
    Mit Scripts hat das gar nichts zu tun.

    Beim Bahnhofdach gibt es bei der Betrachtung von innen noch Fehler mit der Transparenz bzw. dem Z-Buffering. Gebäude sind durch das Glas nicht sichtbar, sondern nur Bäume, so als stünde der Bahnhof irgendwo auf freiem Feld statt in der Stadt (s. Bild 3 und Bild 7). Vielleicht könnte das noch behoben werden, auch wenn man als Busfahrer so schnell nicht in diese Perspektive gerät.
    Aus letzterem Grund würde ich den Bahnhof nicht zu sehr mit Objekten vollpacken. Das Dach sieht noch ziemlich filigran aus, weil keinerlei Träger und Stützen vorhanden zu sein scheinen. Das wäre das erste, was meiner Meinung nach verbessert werden sollte, weil es auch den Eindruck von außen stört. Aber schön, dass es schon mal durchsichtig geworden ist!

    Leider muss ich mein sehr positives Urteil nochmal revidieren: Die Karte ist um 60 Grad im Uhrzeigersinn gedreht. Warum um alles in der Welt achtet eigentlich kein Erbauer auf die Ausrichtung seiner Map?? Wird da vor einem realen Projekt einfach eine Kachel gesetzt und angefangen zu bauen? Wie soll denn ein Kenner der Location einen Wiedererkennungswert haben, wenn die Sonne im Nordwesten aufgeht? Mein Glück ist, dass ich noch nie in Vegesack war und deshalb auch keinen Wiedererkennungseffekt erwarte. Bei Wien war das anders, da kannte ich Kagran und war vom Lichteinfall irritiert.
    Sehr schade, wenn so kapitale, irreversible Fehler gemacht werden.


    Das finde ich auch wirklich ärgerlich. Wie speichert OMSI die Höhendaten und Bodentexturen? Objekte und Splines lassen sich ja evtl. noch per selbsterstelltem Tool drehen, weil die m.W. alle samt Positionierung in Textdateien hinterlegt sind.

    die fehlende Innenschwenktür (das darf nicht passieren, sowas muss fertig sein!)


    So etwas finde ich jetzt nicht so kritisch. Die Bremer Busse haben diese Türe ja meines Wissens nicht und entscheidend ist zunächst einmal, dass das Bremer Vorbild gut umgesetzt wurde. Solche Anpassungen können durchaus kurzfristig nach Release nachgeliefert werden, finde ich.