Posts by Tatra

    Mit "interessant" meine ich, dass diese Schattierung nicht billig aussieht. Also keine Sache, die man scheinbar in zwei Minuten in Paint erstellt. Optisch passt es sehr gut. Wenn das auf den Texturen mit drauf ist, sieht das schonmal sehr passend aus. Das hat was und das meine ich wirklich positiv.

    Hallo Starpellurch,


    Die Schattierungen auf dem Boden sehen irgendwie interessant aus. Ist das Texturbedingt oder durch Lichteinstellungen? Sieht auf alle Fälle schonmal sehr vernünftig aus. Zumindest meiner Meinung nach, worüber man nun streiten könnte. Aber lieber leichte Schattierungen als keine, weil das saubere cleane etwas unnatürlich aussieht. Tageslicht und Innenlicht- spezifische Schattierungen kann man ohnehin nicht einstellen, weil Omsi nur eine Schattentextur erstellen kann.

    Mir gefällt es auf jeden Fall, so wie es bisher aussieht.

    Ist es normal das beim C2 die Schrift relativ klein ist und nicht ganz Links ausgerichtet ist?

    Wie eine Matrix etwas anzeigt oder was genau eine Matrix darstellen kann (z.B. Umlaute, Zeichen) wird im Matrixscript festgelegt. Derzeit gibt es nur eine Matrix, die mittels Codezeichen, Zeichen in der Matrix darstellen kann: Die Busfanat-Matrix.

    Bei den Bussen von Darius gilt: Je mehr Buchstaben ein Ziel hat, umso kleiner die Darstellung, damit alle Buchstaben auf der Matrix erscheinen. Und alle Ziele werden generell zentriert dargestellt. Darius hat diese Busse nach Hamburger Vorbild erstellt (ist also kein Fehler!). Es kann also nicht immer mit allen real existierenden Matritzen, gleiche Anzeigen darstellen.


    In der Hofdatei stehen nur die Wörter die die Matrix anzeigen soll. Was sie davon anzeigen kann, ist aber Scriptabhängig.

    Halycon? Halycon ist doch nur der Publisher. Die Map wird aber nicht von Halycon erstellt. Die Infos sind zwar recht dürftig, aber vielleicht gibt es noch nicht so viel, was man zeigen möchte, oder man möchte einfach eine Spannung aufbauen. Aber "vorführen" will man die Kunden sicher nicht.

    Du hast beim Einbau, Fehler in den Scripten hinterlassen:

    Der oder die Fehler sind so gravierend, dass Omsi diese nicht mehr einzeln anzeigen kann, sondern nur noch die Busdatei als fehlerhaft ansieht. Die Fehler in den Scripten sind meist Schreibfehler, wie falsche Klammerformen, falsche Berechnungen oder Formatsfehlern.

    Überprüfe alle einkopierten Eintragungen in den Scripten, ob alles notwendige eingetragen wurde, und keine Fehler gemacht wurden.

    Die Payware-Addons und auch Omsi 2 selbst, mußt du neu installieren, denn du brnötigst die Einträge in die Registry. Andernfalls kannst du die Add-Ons nicht registrieren. Daher sollte du am besten zuerst Omsi installieren (via Steam oder CD) und es neu registrieren. Anschließend via Netzwerk, den gesamten Omsi-Ornder kopieren und neu einfügen und zum Schluß alle Payware-Adons neu installieren und ebenfalls aktivieren.

    Dann hast du unter setvar, die falsche Ziffer eingetragen.

    Im Handbuch (dies kann man sogar lesen!!!) steht drin:

    "Eine weitere Möglichkeit zur Gestaltung des Innenraums betrifft den Fahrscheindrucker. Standardmäßig ist der elektronische Drucker vom Typ AEG AFR200 eingebaut (s.o.). Der alte ... in Benutzung gewesene Almex PDR 1518 lässt sich mit folgendem cti-Eintrag aktivieren:"

    [setvar]

    vis_almex

    1

    Beudeutet also, mit diesem Eintrag in die CTI, wird der alte Rippendrucker eingesetzt. Möchtest du den AFR200 haben, dann lasse diesen Abschnitt weg oder setzte die Ziffer auf 0. Das MUSS für jedes einzelne Repaint gemacht werden!


    Bitte schau in das Handbuch auf Seite 9.

    Natrülich kann man den Inhalt des Tank selber festlegen.

    Ich habe mal das Beispiel aus dem MB O305 von Rolf genommen:

    In einer der Scriptdateien, bei Rolf war es das Motorscript (engine.osc) wird die Größe des Tankinhalts abgefragt.

    In der dazugehörigen Konstantendatei:

    engine_constfile_OM200PS_Berlin.txt findest du den Eintrag:

    [const]

    engine_tank_capacity

    250


    Weitere Worte sind wohl dazu nicht notwendig.

    Das ist nur bedingt möglich.

    Diese Kurzsteuerung der Sicht, per Tastendruck zur Kasse oder zum Fahrplan. sind die einzigen beiden, die es gibt. Weitere können nicht definiert werden (Info ist von Marcel).

    Demnach bleibt nur das ersetzen der bereits existierenden Tastenevents, wobei die Sichten auf Fahrplan / Kasse dann nicht mehr zur Verfügung stehen.

    In der BUS-Datei muß unter der jeweiligen Sicht der Zusatz:

    [view_schedule]

    [view_ticketselling]

    eingetragen werden. Diese beiden Befehle dürfen aber nur einmal in der BUS-Datei stehen.

    Der grün markierte Wert, ist die Animationsweite der Objekte. Es ist also egal, um was für ein Objekt es sich handelt, es ist nur die Bewegungsweite für die Animation (in eine Richtung).

    Mit dem Befehl: anim_trans = wird die Animationsweite in Meter angegeben.

    Mit dem befehl: anim_rot = wird die Animationsweite in Grad angegeben.


    Hier ist es also die Rotationsgröße für das Lenkrad, wie weit es sich dabei drehen soll. Original, wäre der Wert 900° für alte oder ältere Busse (2 1/2 Umdrehungen - für eine Richtung) oder 630° für modernere Busse (1 3/4 Umdrehungen). Der eingetragene Wert ist aber einzig und allein, nur für die Animation da. Es hat keinerlei Auswirkungen auf das Fahrverhalten des Fahrzeuges in Omsi. Egal ob du 1440° oder 180° eintragen würdest. Der Wert verändert nicht den Lenkeinschlag der Räder oder das Fahrverhalten ansich. Es ist nur der Wert, wie weit das Lenkrad drehen soll. Wenn sich der Bus also schwammig fährt oder unnatürlich, dann liegt es an den Scripten und / oder falschen Werten in der Busdatei.


    Die meisten User stellen sich den Wert auf 450°, damit das Lenkrad die selbe Bewegungen ausführt, wie das Lenkrad vor dem Monitor (je nach Art des Lenkrades).

    Nicht alle Busse, wurden bei der Erbauung der Räder mit Regeneffekten ausgestattet. Diese können auch nicht nachträglich eingesetzt werden, weil man dazu die Objektdateien (also die 4 Räder) mit einer weiteren Texturebene ausstatten muß. Da du keine o3d-Dateien öffnen und bearbeiten kannst, ist es nicht möglich. Sind Blender-Dateien veröffentlicht worden, kann man die Regeneffekttextur nachträglich einsetzen.

    Ein einfacher Eintrag in der model.cfg reicht da nichts aus.

    Ganz recht. Mit (L.L.Variablenname) wird ein Variablenwert gelesen, mit anderen Werten berechnet und das Ergebnis wird dann in (S.L.Variablenname) gespeichert.

    Was genau gespeichert wird, kannst du aus der laststn.osn in der Mapdatei auslesen. Dazu kannst du einen einfachen Test machen:

    Stelle einen Bus auf Grundorf und fahre einen Meter, dann stoppen (Spiel wird gespeichert). Öffne die laststn.osn aus der Mapdatei Grundorf und suche die variable door_0.

    Öffne die Tür 0, (also den ersten Flügel oder die erste Tür) und rucke kurz an, so das das Spiel wieder gespeichert wird. Öffne wieder die laststn.osn und vergleiche den Variablenwert door_0.

    Alternativ kannst du Omsi auch jedesmal ausschalten ... das funktioniert mit allen variablen, die du in den Scripten findest.

    Mit einem Repaint kann man aber keine bestimmten Sounds abspielen. Repaints zeigen einen Bus lediglich mit einer anderen Textur.

    Türwarntöne müssen gescriptet werden, damit bei einer bestimmten Aktion ein Sound abgespielt wird.

    Also die Anzahl, wieviele Personen in einen Bus einsteigen, legt man in der Datei: "passengercabin.cfg" fest. Es gibt aber nicht eine feste Zahl, die angibt wieviele Personen einsteigen dürfen, sondern wird allein durch die in der passengercabin angegebene Anzahl von Sitz- und Stehplätzen festgelegt. Da läuft beim Fahrzeugbau nichts schief. Gibt man als Beispeil 20 Sitzplätze ein und 30 Stehplätze, dann können im Bus maximal 50 Personen mitfahren. Sind 50 Personen an Bord, gilt der Bus als voll und es steigt niemand mehr ein, da es keine Plätze mehr gibt. Manchmal haben die Fahrzeugerbauer keine Lust, weitere Sitz- und Stehplätze zu definieren. Denn jeder Platz muß einzeln eingetragen werden.


    Außerdem kann man nicht (direkt) festlegen, welche Sitz- oder Stehplätze zuerst benutzt werden. Wenn ein Passagier einsteigt, entscheidet Omsi per Zufall, welchen Platz der Passagier verwendet. Dabei ist es egal, wo dieser Platz ist. Einzig und allein eine fehlerhafte Lichtzuweisung, kann die vorrangige Benutzung von Plätzen beeinfussen.


    Im Downloadthread hat jemand bereits eine Lösung gefunden:

    Was du gefunden hast, beschreibt nur die Ausrichtung der Person im Bus, wenn ein Sitz- oder Stehplatz eingenommen wurde. Mit der Ausrichtung legt man fest, ob eine Peron in Fahrtrichtung sitzt (Wert 0), nach Rechts oder Links (-90 oder 90) oder nach hinten ausgerichtet ist (180). Hat aber nichts mit der zulässigen Gesamtanzahl von Personen im Bus zu tun.


    In der WebDisk gibt es einen Würfel (einfache Box), mit den man Positionen im Bus rausfinden kann, um weitere Plätze einzutragen. Somit kann man jeden Bus auch richtig voll werden lassen, wenn man einige kleine Punkte beachtet.

    Das Schlagwort würde wohl "Renderreihenfolge" heißen.


    Wichtig ist, dass die Glasscheiben (also alle transparenten Teile von Objekten), in der jeweiligen Modeldatei, immer als letztes eingetragen sind. Zudem kannst du testen, ob es sich bemerkbar macht, wenn du statt 2, die 1 verwendest.

    [matl_alpha]

    1

    Versuche es einfach.

    Ich hänge mal den Abschnitt aus der Model.cfg an:

    Gute Entscheidung. Das passt auch.



    Dann habe ich den Befehl tuersperre erstmal allgemein in den Scripts gesucht.

    Dieses Scriptschnipsel ist lediglich der Befehl für den Schalter ansich. Es steckt irgendwo in den Scripten nocheinaml die Schalterabfrage (L.L.tuersperre_sw) drin. Diese mußt du zuvor suchen.


    Ich weiß nicht ob es einfacher ist bzw. änderbar ist, dass ich z.B. nicht z.B. erst zwei mal drücken muss, dass der Schalter die linke Tür sperrt

    Also änderbar ist es. Einfacher aber nicht. Dazu muß das Script umgeschrieben werden. Außerdem benötigst du ein weiteres Mesh. Wie gut bist du im 3D-Objektbau?

    Da der Schalter nur ein Objekt ist, gibt es nur die Möglichkeit, den Schalter (also das 3D-Objekt) in einem 3D-Programm zu ändern, oder ein kleines Mesh zu bauen, was man auf einer Seite des Tasters auflegt.


    Zum Script:

    Ich habe mal reingeschaut und sehe sofort ein kleines Problem.

    Es gibt mehrere Türscripte. Macht es für dich nicht gerade einfacher, aber es ist immernoch änderbar. Also keine Angst vpr den Scripten, einfach schauen.


    Welcher Bus genau welche Scripte verwendet, siehst du in der jeweiligen Busdatei. Die ganzen Versionen des Urbino 12 verwenden 3 verschiedene Scripte (door.osc/door_auto.osc/ und eine Variante für den 3 Türer), die sich in verschiedenen Ordnern befinden. Ist zwar nicht gerade die beste Lösung, hat aber für dich den Vorteil der Übersichtlichkeit. Also schau in die Busdatei, welches Türscript aufgerufen wird.



    Hier sind die im vorherigen Beitrag erwähnten Abfragen für den Schalter. Die Variable trg_bus_doorfront0 ist für den vorderen Türflügel, und trg_bus_doorfront1 für den folgenden Türflügel. Je nach Stellung des Schalters soll das entsprechende Türmacro ausgelöst werden. Hier mußt du nur die Operatoren auswechseln:

    (L.L.tuersperre) 0 >

    Der Operator ist das > und < (größer als-Zeichen / kleiner als-Zeichen)

    Größer als 0 bedeutet der Schalter ist nach Rechts gekippt. Beachte bitte, das zwischen der Ziffer 0 und dem Operator ein Leerzeichen stehen muß.


    Das salber findet sich auch bei den Automatischen Türen im {Macro:door_init} Erst kommt die Schalteranimation und dann die Türflügelsperre, für das Öffnen der Türen und dann für das Schließen der Türen. Damit es hier nicht ausartet, lasse ich den Teil bis hier stehen.

    Das ist schon richtig. Kann ich nicht mit einem Wort erklären. Hier gibt es mehrere Fragen, was du haben willst.

    Nun ist die Frage, wie dein Schalter aufgebaut ist. Ich vermute mal, das es ein einziges o3d-Objekt ist. Daher beschreibe ich nur diese Variante. Die Animation läuft vermutlich wie folgt ab: Von Position 0 nach recht - nach Links - zurück zu Position 0. Sollte es zwei Mausevents geben, dann melde dich nochmal.

    Somit hast du nur ein Mausevent in der model.cfg:

    Suche dieses

    [mouseevent]

    was_weiß_ich

    in der model.cfg. Als nächstes, suchst du dieses Mausevent im Script (Vorzugsweise zuerst wo es eigentlich hingehört. Der Schalter gehört zum Amaturenbrett. Also schaue in die cockpit.osc rein. Du solltest einen Trigger finden.

    {Trigger:was_weiß_ich}

    Darunter findest du die Variable "Schalteranimation", die ausgelesen wird:

    (L.L.Schalteranimation)

    Hier findet sich, wann etwas passieren soll. Indem Falle soll die Animation von 0 nach 1 nach -1 wieder auf die Position 0 gehen. Merke dir die Variable "Schalterposition".

    Suche nun in den Scripten, wo dieser Wert nochmals ausgelesen wird. Vielleicht in der Door.osc (kann sein, muß nicht).

    Irgendwo steht nochmals (L.L.Schalteranimation) und darunter finden sie die Variablen "Funktionsname_1" und "Funktionsname_2".

    Diese legen fest, wann eine bestimmte Funktion umgesetzt werden soll.

    (L.L.Schalteranimation) 0=

    Das bleibt unverändert.

    (L.L.Schalteranimation) 0 >

    (S.L.Funktionsname_1)

    und

    (L.L.Schalteranimation) 0 <

    (S.L.Funktionsname_2)

    Hier mußt du nur die variablen Funktionsname_1 und _2 austauschen.


    Soweit die Theorie, die Praxis ist leider kompliziert. Wie ist das Script aufgebaut, Wie wurde die Animation umgesetzt, gibt es einen kompletten Schalter oder 2 zusammenhängende Objekte??? Es kann auch ausreichend sein, wenn du in der model.cfg die Animationsrichtung änderst:

    [newanim]

    origin_from_mesh

    anim_rot

    Variable "Schalteranimation"

    12


    Mach hier einfach ein Minus vor die 12 und teste es! Vielleicht reicht es. Mir scheint so, als wenn es der MB von Alterr ist. Hier sind die Scripte sehr einfach und klar. Morphi setzt mehrere Funktionen hinzu, womit Scripte leider auch komplizierter werden können. Schau mal was du mit dem hier stehenden erreichen kannst.