Posts by Tatra

    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.

    Das wird nicht im Script geregelt, sondern in der model.cfg.

    Du mußt lediglich die Leuchtvariable in der model.cfg einstellen


    [matl_change]

    Tagestextur.bmp

    0

    gangwahl_N


    So könnte es drin stehen. Das muß nun geändert werden:


    [matl_change]

    Tagestextur.bmp

    0

    elec_busbar_main


    Bedeutet nichts anderes, das der Texturwechsel nicht mehr dann stattfindet, wenn die Variable gangwahl_N aktiv ist, sondern wenn die Variable elec_busbar_main aktiviert wird (Fahrzeugstrom eingeschaltet).

    Eine Änderung hat nichts mit den Systemdaten deines Rechners zu tun.

    Man kann in jedem Bus (egal ob Payware oder Freeware) die Türfunktionen und Abläufe verändern. Dazu sind lediglich Änderungen im Script notwendig und Anpassungen oder hinzufügen von Sounds notwendig. Was man dazu benötigt sind Kenntnisse im Umgang mit Scripten. Ohne Wissen, wie Scripte aufgebaut sind und funktionieren, ist es kaum möglich. Aber Ändern kann man alles. Von der Art der Türbewegungen (Aussenschwenktüren, Innenschwenktüren, Schiebetüren etc.) bis hin zum Bewegungsablauf.

    Der Setra SG221UL wurde bereits angefangen. Grundlage ist der Setra S 215UL. Hier liegt sogar die Genehmigung vor und es wurden sogar die originalen Blenderdateien gegeben. Aber wie das mit den Studenten so ist. Manchmal fehlt neben der Zeit zum studieren, auch die Zeit, viele Hobbys zu betreiben. Ob Pennermaster an dem Projekt irgendwann weiter macht, ist unbekannt.

    Dann hättest du vielleicht mal dazu schreiben sollen, das niemand hinten aussteigt. Du mußt den einen [exit]-Eintrag ändern und die Zahl des zweiten [entry]-Eintrag drunter schreiben.

    Also statt

    [exit]

    0

    muß dort stehen

    [exit]

    11

    oder

    [exit]

    13

    Den zweiten [entry]-Eintrag kannst du entfernen. Das geht aber nur, wenn die Wege im Bus, nicht als "Einbahnstraße" gesetzt wurden. Der ganze Bus ist vermurkst. Wenn du umstellst, werden vermutlich die Fahrkunden hinten durch die geschlossene Tür ein- und aussteigen.

    Das Geld hättest du dir sparen können. Nutze den Bus von CCV-520, den du hier im Forum findest. Der hat kaum Fehler.

    In der passengercabin.cfg muß der Eintrag [exit] mit der geringesten Zahl entfernt werden.

    Du findest dort mehrere Einträge, wobei [entry] für den Eingang steht und [Exit] für den Ausgang.

    Ein Schalter besitzt nur einen Trigger, indem die Animationsvariable verändert wird. Mit jedem Klick, eine Bewegung.

    Für einen Taster fügst du einen zweiten Trigger hinzu, damit der "Schalter" die zweite Animation selbständig ausführt. Zudem wird der erste Trigger verändert:

    {Trigger:Taster_on}

    1 (S.L.roter_Taster)

    {end}


    {Trigger:Taster_off}

    0 (S.L.roter_Taster)

    {end}


    In der Model.cfg gibt es nur eine Animationsvariable, die durch ein Klickpoint ausgelöst wird, also auch nur ein Mausevent.

    Das zweite Event wird demnach von Omsi selbst ausgeführt, wenn die vorherige Bedingung, dem Ausführen nicht widerspricht.


    Außerdem mußt du noch die Animation in der model.cfg verändern. Aus einer Rotation wird eine Verschiebung

    Das heißt, dass ich damit den Rotationswert manuell festlegen?


    Quasi ja (richtig gedacht, falsch ausgedrückt). Du verdrehst damit den Objektursprung für die Rotation neu, damit das Objekt nun nicht mehr vom eigentlichen Objektursprung ausgeht. Das ist zwingend notwendig, wenn du beispielsweise zwei oder mehr verschiedene Rotationen ausführen möchtest. Du kannst aber im 3D-Programm nur einen einzigen Objektursprung festlegen. Für jedes Objekt, gibt es immer nur einen Objektursprung. Aber es gibt für ein Objekt mehrere Animationen ...

    - Türen mit Hubverriegelung

    - Räder

    - Blinkhebel (Kombischalter)

    - Dachluken
    Du kannst als den Objektursprung für eine Animation festlegen, aber du mußt weventuell weitere Objektursprünge für andere Animationen erstellen, obwohl es immer nur einen Objektursprung geben kann. Daher kannst du den Objektursprung für jede Animation passend einstellen ... für die Erste (und einzige) und für alle weiteren Animationen.

    Also setzt du entweder deinen Schalter so ein, dass der Objektursprung verwendet werden kann, oder du vestellst den Objektursprung so, dass er zu deiner Animation passt. Für deinen Schalter gehst du nun vom Objektursprung deiner Blenderdatei aus. Nach dem Bild scheint die Position zu passen, aber der Winkel nicht.

    [new_anim]

    origin_from_mesh

    origin_rot_x

    0

    origin_rot_y

    8

    origin_rot_z

    5

    Diese beiden Werte veränderst du solange, bis es perfekt ist. Du bleibst bei ganzen Zahlen (Angabe in Winkelgrad) und veränderst im positiven oder negativen Bereich. (Keine Verdrehung über 180° - Ist Möglich aber unsinnig). Du kannst auch alle 3 Werte ändern. Es sind aber auch Zahlen mit Kommastellen möglich (maximal 7 Stellen nach dem Komma).


    Kommst du zu keinen zufriedenstellendem Ergebniss, mußt du den Objektursprung verändern (auf eine neue Position verschieben).

    [new_anim]

    origin_trans

    X

    Y

    Z

    origin_rot_x

    usw


    Der Vorsatz "origin" bezieht sich ausschließlich auf den Objektursprung, nicht auf das Objekt. Für das Objekt wird der Vorsatz anim verwendet. anim_rot für eine Objektrotation, und anim_trans für eine Objektverschiedung.


    Alles andere, ist eine Frage zu Blender. Damit kenne ich mich nicht aus. Aber du kannst den Objektursprung für das Objekt genau anpassen. Andere haben es ja auch geschafft. Die Frage ist also nicht, ob, sondern wie es in Blender gemacht wird.

    Im zModeler stelle ich zuerst das Objekt auf die richtige Position, dann den Objektursprung+Objekt zusammen und am Ende verdrehe ich den Objektursprung+Objekt, bis die Ausrichtung der X-Achse stimmt.


    PS: Objektursprung = Pivot

    Weil es zwei Einstellungen nacheinander gibt, um den Objektursprung zu verstellen. Du kannst in Blender (oder jeden anderem 3D-Programm, den Objektursprung und das Objekt zusammen oder getrennt verschieben / verdrehen. Du wirst beim letzten Mal alle Bewegungen zur Anpassung zusammen gemacht haben, aber diesesmal getrennt.

    Oder du hast einen Fehler beim Dateiexport gemacht ...

    Diese dürfen für den Export nicht auf 0 gesetzt werden,

    Vergiß bitte nicht .... egal wie du dein Objekt in Blender drehst ... Omsi rotiert Objekte generell immer, über die eingestellte X-Achse!


    Lass am besten alles so wie es ist und verändere nur die Position in der model.cfg

    anim_rot_x

    0


    anim_rot_y

    0


    anim_rot_z

    0


    Verändere hier die Werte in sehr kleinen Schritten, da dein Objektursrung schon "fast" richtig steht.

    Die Frage:

    gibt es eine Möglichkeit ein IBIS 2 auf dem Seitenpodest neben der Tankanzeige (siehe Bild) des O305 G einzubauen ...

    Die Antwort:

    mittels Daueranimation?

    Frage richtig beantwortet! :thumbup:


    Alles was du brauchst, sind die 3D-Objekte* die du aus einem anderen Fahrzeug kopieren kannst. Dies wird mittels der Daueranimation , schön und anständig hingehängt oder wunderschön aufgestellt. Zum Schluß werden noch das IBIS-Script kopiert und eingesetzt und zum funktionieren gebracht.

    Mittels einer Daueranimation kannst du Objekte, ausgehend vom Objektursprung des Busses, verschieben und/oder verdrehen. Dies geht mit einer Daueranimation oder mit mehreren.

    *Bei einem Ibis handelt es sich um mehrere 3D-Objekte, nicht nur um eines. Neben dem Korpus, gehören auch die einzelnen Tastenfelder (sichtbare oder unsichtbare Klickpoints) und die Displayfelder dazu.

    String 10 muß einen höheren Wert erhalten, damit die Reichweite verändert wird. Mit der Ausrichtung auf den einzelnen Achsen, kannst du das Licht (Ausrichtung auf der Z-Achse) etwa erhöhen, damit der Lichtstrahl ein wenig weiter reicht. Mit Änderung der Reichweite erhöhst du auch die Helligkeit.


    Der Artikel beschreibt die Lichteinstellungen mit zusätzlichen Spotlicht, wie im MB O307 V2 oder MB O407 von Perotinus. Die meisten Busse, die hier angeboten werden, haben nur 2 Spotlichter (Abblendlicht und Fernlicht), womit die Zusatzscheinwerfer, keine Veränderungen der Ausstrahlung auf der Straße bewirken. Hier müßten weitere Spotlichter eingetragen und im Script umgesetzt werden.

    [GER] NickiiiBoy

    Die Werte ansich sind schon real, auch wenn es dir selbst nicht so erscheint. Du kannst die Werte aber für dich ändern, nur realer werden diese nicht.


    Streicher

    Wo kann ich denn einstellen wie hell das Licht (ist es eher eine Texture) ist? Ich finde das Licht von außen betrachtet bei einigen Bussen etwas dunkel.

    Kommt drauf an, von welchem Licht du redest. Einige sind Lichttexturen (beispielsweise Standlicht, Rücklicht oder die Zusatzscheinwerfer) und es gibt Lichter, die ohne Texturen auskommen (Abblendlicht, Fernlicht). Jeder Buserbauer arbeitet da anders. Leider gibt es viele Möglichkeiten, Licht umzusetzen. Das Betrifft auch die Texturen, selbst hier kann man zwei verschiedene Arten von Lichttexturen umsetzen. Kommt nur darauf an, was besser aussieht und wirkungsvoller ist.

    Besonders deutlich wird der Unterschied zwischen Innen- und Außenlicht. Nur beim Innenlicht, werden Lichtquellen verwendet, die niemand sehen kann, sondern nur die Wirkung des Lichtes Anwendung findet. Hier wird der sichtbare Teil mit Texturen geregelt.


    Grundlegend wird die Helligkeit nur in der model.cfg geregelt. Über das Script wird nichts geregelt, es sei denn, es handelt sich um gedimmtes Licht. Hier wird nur der Objektwechsel zwischen beleuchteten und unbeleuchteten Objekt mit der Variable verschoben.

    Das ganze Lichtthema ist aber viel zu umfangreich, als das ich hier alles detalliert darstellen könnte.

    Dieser Wert soll nur die Wahrscheinlichkeit ein wenig steuern. Omsi ist es egal, ob ein Passant einen Fahrschein hat oder nicht. Es ist nur als eine Art zusätzlicher Spielspaß für den Spieler. Ansonsten ist es Omsi egal, was für Fahrkarten verkauft werden. So kann der Verkauf einer Fahrkarte (oder einer Gruppe von Karten) ein wenig zeitlich beeinflußt werden. Mehr ist nicht möglich.

    Dadurch ist dies nur eine kleine Möglichkeit, die Wahrscheinlichkeit dieser Fahrkarten ein wenig zu beeinflußen. Mehr ist das nicht.