Posts by Tatra

The forum is in reduced operation. The Addon and Support forums remain open.
Please note that OMSI is no longer under development. Some of the developers are now working on a new simulator. Further information concerning the LOTUS-Simulator can be found here.

    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.

    Das findest du in der jeweiligen Modeldatei des Busses (model.cfg)

    Unter dem Befehl [spotlight] befinden sich die ganzen Eintragungen. Dort sollte ein Wert von 100 bis 200 für das Abblendlicht stehen und für das Fernlicht, soetwas um die 500. Diese Werte stehen für die Reichweite des Lichtes in Meter.

    Im Profiler

    Genau so sieht es aus. Du kannst das Lenkrad ohne Profiler nutzen, aber damit versagst du dir diverse Einstellmöglichkeiten, die Omsi nicht bieten kann. Nur im Profiler kannst du die Rücklaufstärke des Lenkrades (Kraft der Zentrierfeder), Pedalwege usw. einstellen.

    Ich bin der Meinung, man muss doch für bestimmte Lichtarten (Standlicht, Abblendlicht, Lichthupe, ...) die entsprechenden Lichtpunkte (also von wo das Licht aus geht) definieren, oder?

    Welchen Sinn macht es, bereits bestehende Lichttexturen oder eingetragene Lichtpunkte nochmal einzusetzen??? 8o

    Nicht viel, denn was schon da ist, muß nicht nochmal eingetragen werden. Es geht doch am Ende nur noch darum festzulegen, wann diese Lichtpunkte und Lichttexturen, aktiviert werden sollen.


    Uff geht das in den Scripten?

    Dein Geistesblitz ist natürlich ein Volltreffer. :thumbup:


    In der model.cfg stehen nur, welche Texturen auf die originalen aufgelegt werden sollen (Lichttexturen) und da stehen auch die Art der Lichtpunkte, wo diese sind und so weiter.

    All diese Einstellungen haben etwas gemeinsam. Ist auf den ersten Blick nicht ersichtlich, aber alle haben nur eine Variable drin stehen. Und genau die brauchst du.


    Viele Wege führen nach Rom, aber hier sind nur zwei Wege möglich. Ich beschränke mich auf eine Variante. Im Script (vielleicht cockpit.osc) stehten die Trigger für den Schalter. Bringt uns nicht weiter, aber manchmal stehen auch Lichteinstellungen in diesem Script. Manchmal stehen diese auch im Script (light.osc) drin. Hier suchen wir nach der Variablen, die wir aus der Model.cfg kopiert haben und sollten einen Eintrag finden.

    (S.L.gefundene_Variable)

    darüber stehen die Bedingungen, wann die Variable: "Gefundene_Variable" aktiviert werden soll. Hier fügt man dann einfach weitere Bedingungen hinzu. Also kann man hier zustellen, das die Zusatzscheinwerfer leuchten sollen, wenn der Schalter bedient wird (sollte bereits vorhanden sein), der Strom vorhanden ist, und weitere Bedigungen. Hier setzt man die Schaltervariable des Blickhebels hinzu.

    (L.L.Blinkhebenvariable) &&

    So fubnktionieren die Nebelleuchten weiterhin wie gewohnt und zusätzlich noch, wenn die Lichthupe betätigt.

    Das ist kein Omsi-Fehler, sondern ein resultierender Fehler auf einen Fehler innerhalb von Omsi. Damit kann man wenig anfangen.

    Die Zugriffsverletzung bei einer Adresse, kann ein Fehler beim auslesen eines Scriptes sein. Dann steht aber in der Logfile, das es einen Fehler in der Busdatei gibt (in der das beschädigte Script eingetragen ist).

    Es könnte sich dabei um einen fehlerhaften Eintrag unter einem {init}-Abschnitt handeln.

    - fehlendes Macro

    - fehlerhaftes Macro

    - falsch geschriebenes Macro

    - fehlerhafte Befehlszeile eines Macros.


    {Macro:xyz} - Macro starten

    {end} - Macro beenden

    (M.V.xyz) - Macro abfragen (und verifizieren)

    * unterschiedliche Klammern beachten!!!

    1. Ein Objekt mit Mausevent kann zwei Formen annehmen, Entweder einen Taster oder einen Schalter. Doe Form des Objektes und die Animationsart ist vollkommen egal. Im Script wird dann festgelegt, wie dein Klickpoint arbeitet.

    Ein Schalter arbeitet mit einem {Trigger:---}. Hier wird von der einen Position zur anderen geschaltet. Animationsform, Animationsweite und Animationsgeschwindigkeit werden über die Modeldatei gesteuert.

    {Trigger:Lichtschalter}

    (L.L.sw_licht) ! (S.L.sw_light)

    {end}

    Mit jedem Klick wird die Animation ein mal ausgeführt, bis die andere Position erreicht wurde. Heißt in der Scriptsprache. Mit einem Klick, wird die Variable sw_light in den Zustand 1 gesetzt (wahr) mit dem näcvhsten Klick in den Zustand 0 (unwahr) und das wiederholt sich.


    Ein Taster arbeitet mit zwei Triggern. Der erste ist zum ausführen des Klicks, wobei die Animation ausgeführt wird. Mit dem deaktivieren des Klickpoint, wird der zweite Trigger ausgeführt. Hierbei wird das Objekt wieder in den Ursprungszustand zurück gesetzt.

    {Trigger:Hupe_on}

    1 (S.L.Hupe_an)

    {end}


    {Trigger:Hupe_off}

    0 (S.L.Hupe_an)

    {end}

    Du kannst nur eine Animation ausführen. Die erste. Also mit der Maus drückst du den Taster. Solange du die Maus gedrückt hälst, wird die Variable auf 1 (wahr) gesetzt. Drückst du nicht mehr, wird auotmatisch der folgende Trigger ausgeführt. Die Variable ist 0 (unwahr) und der Knopf jehrt in seinen Ursprungszustand zurück. Du kannst den zweiten Trigger nicht ausführen.


    2. Hier muß das Lenkrad (Objektdatei und Modeldateieitrag) aus dem einem Bus kopiert und in den anderen bus eingetragen werden. Die richtige Position kannst du nur mit einer Daueranimation auführen.


    3. siehe 2. Hier kommen noch die Scripte dazu. Ohne Scriptfähigkeiten ist es nicht machbar. Eine detaillierte Anleitung ist mir zu langewierig.


    4. siehe 3.

    Hast du eventuell einen Tipp für mich, damit der kleine Spiegel nicht ständig mitgerendert wird,

    Mein Tip:


    Ich würde ja eher schreiben, dass man alle Spiegel, die nicht links sind geändert werden, also
    [add_camera_reflexion_2]
    nach
    [add_camera_reflexion]

    Beide Befehle grundverschieden. Der Befehl [add_camera_reflexion] sorgt dafür, das der Spiegel nur dann gerendert wird, wenn dieser im Bildschrimbereich auftaucht.

    Heißt bei dir - alle Spiegel werden dargestellt, die im Sichtbereich sind ... also alle Vier!

    In Omsi ist festgelegt, das der Befehl nur SIEBEN Zeilen hat, die ausgelesen werden. Du hast eine weitere, achte Zeile eingetragen. Macht nichts, du kannst gern noch 284 weitere Zeilen eintragen, die sieht Omsi auch nicht.


    Der Unterschied liegt im Präfix _2. Dieser sagt aus, dass Omsi nicht SIEBEN, sondern ACHT Zeilen auslesen soll. Damit verändert sich auch das Verhalten der Spiegeldarstellung. Der Spiegel wird nun dann gerendert, wenn dieser vom Bildmittelpunkt, innerhalb der in Zeile 8 angegebenen Distanz liegt. Die Angaben werden in Metern (wie bei allen Entfernungsdaten in Omsi) angegeben. Oben stehen also die Werte 60 cm, 50 cm und 30 cm.


    Also gehe wie folgt vor:

    Der Spiegel "Nummer 2" bekommt den Befehl [add_camera_reflexion_2] mit Präfix und stelle den Wert in Zeile 8 auf 0.2. Damit wird der Spiegel nicht gerendert. Testen und du wirst den Erfolg sehen. Nun stelle den Wert "langsam hoch" bis der Spiegel gerendert wird. ZUletzt stellst du den Wert in kleineren Schritten runter, bis diese nicht mehr gerendert wird. So bekommt der spiegel ein Standbild und wird gerendert wenn du einige wenige Zentimeter nach Rechts schaust.


    Im Übrigen darfst du die Zeile 8 bei den Befehlen ohne den Präfix gern löschen. Macht keinen Unterschied.


    Viel Spaß

    Also einstellen kann man das, wie bei jedem anderen Bus aus, in den Scripten. Bei den Türen wird es vermutlich in den Türen (door.osc) geregelt und für das Fahrgestellt, könnte es im Motorscript oder im Antrieb stecken. Muß aber nicht sein. Ich habe wenig Lust, hier nun alle möglichen Punkte für die ganzen Citaros aufzuschreiben.

    Also 1. In den Scripten.

    Suchen mußt du aber in mehreren Bereichen. Es ist nicht mit der Einstellung einer Konstante getan. Aber, wie schon gesagt, kann es bei jeden der angebotenen Citaros anders gelöst sein.

    was der Realität eines nichtdefekten Fahrzeuges entspricht. Aber die Türen öffnen sich damit nicht von allein.

    Bei einem nichtdefekten Fahrzeug, hängt der Bus erst nach mehreren Stunden. Das können manchmal 3 bei vielen 6, bei den meisten 9 Stunden sein. Gibt aber auch Ausnahmen, wo es 12 Stunden dauert.


    und man kann die Tür per Hand öffnen

    Wenn man die Tür per Hand öffnen, dann hat sich die Tür nicht von allein geöffnet.

    Im wesentlichen hast du fast alle Kosten gefunden.

    Punkt 1 - Leider ist das Fahrzeug noch relativ jung. Baujahr 1998 bekommt noch kein H-Kennzeichen, was die Kosten für Fahrzeugsteuer senken würde. Unter bestimmten Voraussetzungen kann man ein H-Kennzeichen bereits nach 25 bis 27 Jahren beantragen. Die sind beim Neoplan nicht gegeben (Anzahl produzierter Fahrzeuge/Haltbarkeit/Nutzungsdauer).

    Punkt 2 - Abstellen des Fahrzeuges sollte 100% sicher sein. Also entweder etwas eigenes oder ein Stellplatz der auf lange Sicht, nicht geräumt werden muß. Eine Scheune sollte also dicht sein und weitestgehend keine Waldtiere rein lassen (Mader).

    Punkt 3 - Du mußt (oder solltest unbedingt) im Vorfeld etwas Geld haben, um eventuelle Reparaturen zeitnah ausführen zu können. Besonders bei einem 20 Jahre alten Fahrzeug, mußt du dir auch über den Ersatzteilzugriff sicher sein. Denn wenn dein Bus einmal kaputt geht, mußt du ihn zeitnah reparieren, ansonsten steht sich der Bus kaputt. Damit kommen dann schnell höhere Reparaturkosten dazu. Schaue auch im Vorfeld nach Ersatzteilen und den Kostenpunkt. Besonders bei Westeuropäischen Modellen muß man genau hinsehen, ob etwas passt und günstig ist. Da haben die osteuropäischen Modelle den Vorteil auf ihrer Seite, weil die hohen Stückzahlen auch viele Ersatzteile mitbrachten, die man heute (teilweise) günstig bekommen kann.

    Punkt 4 - Eine Gruppe von Fans, können solch ein Projekt schon etwas eher in Angriff nehmen. Für einen alleine ist solch ein großes Projekt, eine finzanzielle Zeitbombe. Besonders, wenn der Unterstellplatz wegfallen könnte.

    Punkt 5 - Anmelden mußt du ein Fahrzeug nicht unbedingt. Somit fallen TÜV- und Steuerkosten weg. Dennoch solltest du einen Platz haben, wo du den Bus ein wenig bewegen kannst. Du selbst brauchst auch keine Fahrerlaubnis. Du kannst dich als Fahrzeughalter eintragen lassen. Somit benötigst du jemanden mit einer entsprechenden Fahrerlaubnis. Machst du selbst eine Fahrerlaubnis, benötigst du keinen PBO-Schein (Kosten etwas 350€ für 24 Monate).

    Zum TÜV sei noch soviel gesagt: Jeder zweite Bus fällt durch. Heißt also, die TÜV-Prüfer finden immer etwas. Das hat nicht immer etwas mit Sicherheit zu tun, sondern mit Geldmacherei - also bereite dich auch darauf vor. Suche Kontakte zu anderen Gruppen und Vereinen, die dir mit Rat und Tat, hilfreich zur Seite stehen können (Erfahrungswerte sind unbezahlbar).

    Punkt 6 - Die Versicherung ist ein eigenes Thema. Selbst ein nichtangemeldeter Bus sollte unbedingt versichert werden. Gibt genügend Idioten und Neider, die dir dein Projekt gern zerstören möchten. Sprich nicht mit einem Versicherungsmakler, sondern sprich die Versicherung direkt an. Eine Fahrzeugversicherung brauchst du unbedingt. Wenn du den Bus anmelden möchtest, empfehle ich unbedingt ein Saisonkennzeichen. Die Vorteile sind

    - kein ständiges an- und abmelden

    - Haftpflicht läuft weiter

    - TÜV-Pflicht erst im ersten Betriebsmonat (auch wenn die Zeit abgelaufen ist)

    Du kannst den Betriebszeitraum selber wählen (2 Monate mindestens, 11 Monate maximum). In der Zeit läuft die Haftpflicht weiter (Versichert gegen Diebstahl, Brand, Vandalismus). Laß dir von der Versicherung mehrere Modelle vorrechnen. Versuche auch einen Busfahrer aus deiner Nähe zu finden, der als Fahrer eingetragen wird (senkt die Kosten). Egal ob du die Fahrerlaubnis noch machst oder nicht. Du wirst als Fahranfänger auf privater Basis geführt, was die Versicherungskosten hochtreibt. Außerhalb der Betriebszeit muß dein Stellplatz absolut sicher sein (Befriedeter Bereich - also Privatgrundstück). Auch das kurzzeitige abstellen im öffentlichen Straßenland, kann Kosten und auch Punkte in Flensburg verursachen. Von den Abschleppkosten schweige ich mal.

    Machbar ist es. Dafür muß nur der Luftverlust assiv erhöht werden. Derzeit ist der Luftverlust sehr gering eimngestellt, was der Realität eines nichtdefekten Fahrzeuges entspricht. Aber die Türen öffnen sich damit nicht von allein. Das wäre schon fern ab jeglicher Realität.

    Normal braucht ein Bus sehr viele Studnen um den Luftdruck im Kreislauf zu verlieren. Solange der Motor an ist, ist der Verlsut ohnehin nicht bemerkbar. Und das ein Bus den Luftvorrat an der Endstelle verliert ist auch unreal, da selbiger nicht so lange steht.

    Hallo Tatrafan

    314 12:29:07 - - Warning: File vehicles\Tatra_KTNF6_Cottbus\model\model_KT4Dtm_2A.cfg: texture filename T_Fenster_MX.tga not found in mesh file vehicles\Tatra_KTNF6_Cottbus\model\FF\FF_Fenster_H_A.o3d!

    Deine Logfile zeigt nur ein Fehler an. Alle folgend angezeigten Errorfehler resultieren daraus.

    Fahrzeugdatei\Tatra_KTNF6_Cottbus\model\model_KT4Dtm_2A.cfg: der Texturdateiname T_Fenster_MX.tga ist nicht in der Objektdatei eingetragen vehicles\Tatra_KTNF6_Cottbus\model\FF\FF_Fenster_H_A.o3d!

    Du hast einen Fehler in der model.cfg eingetragen.

    In jeder o3d-Datei stehen die ganzen benötigten Texturennamen mit Dateiendung drin. T_Fenster_MX.tga steht aber nicht im Objekt FF_Fenster_H_A.o3d drin. Diesen Texturnamen hast du in die model_KT4Dtm_2A.cfg unter [matl] oder [matl_chance] eingetragen. Dort muß aber die originale Textur eingetragen sein, die zum Mappen benutzt wurde.


    Den Fehler kannst du auf zwei Arten lösen:

    1. Du verwendest einen HexEditor und veränderst den eingetragenen Texturnamen in der o3d-Datei ODER

    2. Du kannst auch das neue Repaint den selben Namen geben, wie die eigentliche Textur und erstellst einen Unterordner im Repaintordner - Beispiel:

    Repaint\Tatrafan. Dort muß die neue Textur eingesetzt werden, die den selben Dateinamen (inklusive der gleichen Dateiendung) hat. In der model.cfg kommt dann nur der Link dazu:

    [matl]

    Tatrafan\originalen Texturnamen


    Gruß Tatra


    Wenn dein Schalter beim Anklicken verschwindet, dann befindet sich der Fehler an folgender Stelle:


    Hier sind die Koordinaten eingetragen, wo dein Rotationspunkt für die Animation stehen soll. Der Rotationspunkt muß also genau unter dem Schalter liegen, wo das "Garnier" des Schalters ist. Den Wert kannst du nicht wirklich sauber errechnen. Teste es aus oder nutze den Positionswürfel, um die genaue Position zu finden (auch ohne Blender).

    Mit diesem Wert legst du fest um (bei einer Rotation) wieviel GRAD, das Objekt animiert werden soll. Fange mit kleineren Werten an.


    Im übrigen verschwindet dein Schalter nicht, sondern wird nach Ausführung der Animation von anderen Objekten verdeckt. In welche Richtung er sich dabei bewegt, erkennst du, wenn du den grünen Wert auf ein Minimum setzt (z.B. 0.5). Je näher du mit dem Rotationspunkt dem Objekt kommst, desdo geringer die Bewegung des Objektes (bei gleichbleibender Animationsweite).

    .., würde ich allenfalls als funktionsloses Objekt einbauen.

    Wie meinst du das, mit "funktionsloses" Objekt. Die Animation sollte schon mit eingesetzt werden. Lediglich die Funktion bleibt dann außen vor, wie besipelsweise die Spiegelheizung. Also nur mit einer Dummyfunktion.

    Da gibt es noch einige andere Dinge im Amaturenbrett, wo man über die Funktionen debattieren könnte. Beispielsweise Spiegelverstellung oder Standheizung, Hier kann man dann auf eine Animation verzichten, da Omsi eine Umsetzung nicht ermöglicht oder eine Umsetzung unnötig ist. Die anderen Schalter können später von Moddern mit brauchbaren Funktionen erweitert werden.


    Aus Gründen, die ich noch nicht kenne, habe ich um das Armaturenbrett etwas viel Platz.

    Davon ausgehend, dass das Amaturenbrett genau so dick ist, wie es verbaut ist, kannst du den Platz lassen, falls du die Lenksäule einstellbar machen möchtest, oder Lenksäule plus Sitz, etwas nach vorn setzen. Besonders beim Sitz ist eine genaue Positionierung nicht möglich, weil dieser in der Realität verstellbar ist (Eine Verstellung in Omsi, hat aber keinen Nutzen). Standardmäßig setzen alle Busersteller, den Fahrersitz so weit nach hinten wie möglich.

    Zudem kannst du die Lenksäule erst später genau anpassen, wenn du die passende Sichtposition (mit einer Kasse, Außenspiegel, sonstiges) gefunden hast. Dann kannst du das Lenkrad richtig positionieren, damit die Sicht auf das Amaturenbrett wieder passt.


    PS: Ist die Lenksäule in der Seitenansicht nicht etwas zu schmal? Besonders der gesamte Schalterkasten scheint mir zu klein geraten zu sein.

    Die Ursache liegt in der fehlenden Textur für das o3d-Objekt.

    Wenn du einen Schalter kopieren möchtest, statt einen neuen Schalter zu erstellen, geht das nicht einfach so, weil der Dateiname der Textur in der o3d-Datei enthalten ist. Der Schalter bekommt also immer die Textur, die in der o3d-Datei als Textur eingetragen ist. Was du in der Modeldatei einträgst, ist nur die späteren Änderungen, die mittels Script geändert werden sollen (Lichttexturen, Objekterhellungen, etc.).


    Zum kopieren, gehe wie folgt vor:

    1. o3d-Objekt kopieren und umbenennen.

    2. Originale Texturdatei kopieren und umbenennen.

    3. kopierte Texturdatei verändern, wobei hier nur das Aussehen des einen Schalters verändert wird, nicht dir ganze Datei.

    4. kopierte o3d-Datei mit einem Hex-Editor öffnen und nach unten scrollen. In der Nähe des Endes der Datei steht die verwendete Texturdatei. Dieser Dateiname muß geändert werden. Datei speichern!

    5. In der model.cfg den Namen der Texturdatei unter [matl_...] verändern.


    Der originale Texturdateiname darf nicht entfernt oder verändert werden.

    Der Bus verschwindet, sobald du in der Modeldatei unter [matl] oder [matl_change] einen Dateinamen einträgst, der nicht mit dem Dateinamen in der o3d-Datei übereinstimmt oder der nicht auf der angegebenen Texturebene liegt. Es entsteht ein Wiederspruch den Omsi nicht anerkennen kann.


    Übrigens ist das auch genau die Aussage in der Logfile: Der eingetragene Texturname konnte in der Objektdatei (mesh file) nicht gefunden werden.

    Es gibt bereits viele verschiedene Stadtmaps. Es gibt einige Stadt- /Überlandmaps. Was fehlt ist eigentlich eine wirklich schöne Überlandmap. Die kann man auch richtig schön Interessant gestalten. Wenn alles fiktiv ist, hat man wahnsinnig viele Möglichkeiten, um die Map interessant, abwechslungsreich zu bauen, aber auch die Linienführungen zeitlich anpassen. Mal durch das Dorf, mal durch Teile des Dorfes und mal außen rum. Vor allem kann man unterschiedliche Linien erstellen. Ausflugslinien gab es bisher noch nicht. Als Startpunkt kann man den Rand einer Großstadt erstellen oder in einer mittleren oder Kleinstadt erstellen.


    Eine schöne Map, wo man einige Minuten, mal mit 60 oder 70 km/h cruisen kann. Kein Durcheinander, bei den Fahrplänen, wie auf der Map Blankwitz, aber vielleicht kann man die ein oder andere Idee aus Ettbruck und Blankwitz übernehmen. Fragen kostet ja nichts.

    Das wird nicht ganz funktionieren. Im Reg-Editor werden ja nicht die originalen Seriennummern eingetragen, sondern die Aktivierungsnummern, die durch den Launcher errechnet werden. Wenn du diese Regestrierungsdateien gesichert hast, dann reicht es nicht aus, wenn du Omsi vollständig auf die neue FP kopierst und dann die Reg-Einträge wieder eintragen läßt. Weil die eingetragene Nummer nur im REG-Editor steht, aber nicht im Launcher. Warum die Aktivierungsnummer im Reg-Eitor nicht ausreichen, weiß ich nicht, weil der Launcher beim Omsi-Start nicht mitstartet.

    Ich würde folgendes versuchen. Wenn Omsi mit allen Add-Ons auf der neuen FP drauf ist, den Launcher starten, alle Add-Ons deaktivieren und dann neu aktivieren. Wichtig ist dazu, ob du die Add-Ons online oder offline aktiviert hast. Wurden diese zuvor offline aktiviert, kannst du die selben Nummern wieder übernehmen. Wurde es online aktiviert, mußt du zwangsweise alles neu installieren.


    Versuche auch die Konfigurationsdateien vom Launcher neu schreiben zu lassen, indem du die Ini-Dateien aus dem RegAddon-Ordner entfernst (rauskopieren, nicht löschen).


    Der ganze Schutz würde ja sinnlos werden, wenn ich die vollständigen Reg-Einträge vom Kumpel bei mir eintragen würde und das Add-On würde laufen.

    Unpraktisch ist aber reine Ansichtsache (Geschmackssache). Ich erstelle zuerst alle Ziele und wenn alles fertig ist, dann sortiere ich die Ziele für die Rollbänder. Eine vorgegebene Sortierung nutzt mir persönlich nichts, da ich IBIS-Codes anders anlege, als die Realität es vorsieht.