Posts by Marcel Kuhnt

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.

    Na, da steht doch immer z.B.


    [pnt]
    2100
    641


    So, "641" ist das Moment, also gewissermaßen die Kraft des Motors bei 2100 Umdrehungen pro Minute. Wenn der Motor stärker sein soll (und damit der Bus schneller auf Geschwindigkeit kommen soll), dann muss der Wert z.B. auf 1000 erhöht werden (ist etwa 50% mehr):


    [pnt]
    2100
    1000

    Nein, "gear_efficiency" hilft nicht, weil das lediglich die Verlustenergie ist, die übers Getriebe als Wärme verloren geht.


    Viel besser ist es, wenn du die Leistungsdaten des Motors erhöhst. Diese findest du in der engine_constfile:



    Der jeweils erste Wert ist die Drehzahl, der zweite ist das Moment, das der Motor bei "maxThrottle" als Moment erzeugen soll. Diesen zweiten Wert kannst du gleichmäßig erhöhen, z.B. um 50%. Dann erhälst du einen stärkeren Motor!

    :)

    1.) Find the depending "engine_constfile_....txt" (take a look into the *.bus file!)
    2.) Search for the entry "[const] / engine_fuel_value" and change the "16" into a lower value! This value means "kWh/litres", so it tells you how many kWh can get from one litre fuel.

    Unter "Path Edit" kannst du ja alle Pfade nacheinander durchschalten. Prüfe dabei mal, ob auch wirklich IMMER jeweils ein (sichtbarer) Pfad blinkt! Denkbar ist, dass es irgendwo nen Pfad mit der Länge "0" gibt - dann könnte es vieleicht zu Problemen kommen (allerdings hatte ich das Problem bisher nicht, weshalb das auch nur eine Idee ist)...?

    Damit mal eins klar ist: Es hat nichts mit freier Meinungsäußerung oder Diskriminierung zutun, wenn wir einfach von euch allen erwarten, dass ihr euch Mühe beim Beitragsschreiben gebt. Und wer - obwohl er es mit 20 können sollte - einfach Kommas komplett weglässt, der gibt sich definitiv keine Mühe! Es ist aber eine der Regeln, sich beim Verfassen von Beiträgen Mühe zu geben. Und die Beachtung unserer Regeln ist eine Bedingung für die Teilnahme hier im Forum. So einfach ist das.


    Da bringt es überhaupt nichts, beleidigt zu sein.

    Achte bitte auf deine Beitragsstruktur! Du setzt keine Satzzeichen, so geht das hier nicht!


    "ANNAX" ist der Name der Matrixanzeigen in den Bussen ab SD82. Und wir werden das X erst einfügen, wenn wir es auch mal brauchen sollten...


    Edit: Mein obiger Hinweis bezieht sich auch auf die Art, einen Thread neu zu erstellen: Erstens kann man ja WENIGSTENS DA darauf achten, dass man keinen Tippfehler macht ("Farge") und ihn dann bitte auch an der richtigen Stelle platzieren! (Bus- und nicht Streckenbau!)

    Also, wenn ich das richtig verstehe, möchtest du die Spline aus OMSI nach Blender konvertieren?


    Das geht sogar, ist aber eine bisher undokumentierte Funktion! Du findest sie auf der Registerkarte "Spline-Exp.". Beginne hierfür mit der Spline, deren Ursprung nachher am Nullpunkt sitzen soll und klicke nachher alle zu exportierenden Splines an. Mit "Clear" kannst du die Liste auch wieder löschen. Mit Export kannst du sie in eine x-Datei exportieren!

    Es gibt zwei Möglichkeiten, die wir aber bisher noch nicht öffentlich erklärt haben (ich bin aber gerade dabei, das Fahrzeug-SDK, was Rüdiger angefangen hat, in das Wiki zu übertragen!).


    Entweder man erzeugt eine perfekte Kopie der Scheiben, indem man das Original dubliziert (ohne zu verschieben!) und ggf. darf man dann natürlich noch Polygone löschen aber NICHT verschieben! Dann flimmert es tatsächlich nicht! Genauso haben wir es mit unseren Bussen gelöst.


    Die zweite Variante ist der [matl_noZwrite]-Befehl:


    Angenommen, du hast zwei Objekte, die nacheinander gezeichnet werden sollen, z.B. Glas und Dreck auf Glas. Dann kannst du beim Glas mit diesem Befehl das Schreiben in den Z-Buffer abschalten, sodass der folgende Rendervorgang (Dreck auf Glas) nicht flimmert. Gaaanz wichtig aber: Der zweite Rendervorgang muss dann aber dafür sorgen, dass die entsprechenden Bereiche dann doch noch in den Z-Buffer geschrieben werden! D.h. diese müssen dieselbe Form haben und alle Polygone, die auch das Glas bereits haben.


    Das ist jetzt alles seeeehr verkürzt wiedergegeben... aber als zusätzliche Literatur empfehle ich: http://de.wikipedia.org/wiki/Z-Buffer

    In der .x-Datei muss nun aber auch hinter den Texturen .dds stehen.

    ;)


    Nein, das muss nicht so sein! OMSI durchsucht automatisch auch nochmal nach .dds-Dateien, wenn man (wie wir) während der Entwicklung die unkomprimierten bmps verwendet und dann einmal ALLE Dateien auf .dds komprimiert. Dann muss man nicht umständlich alle x-/od3-Dateien anpassen!