Beiträge von IREgio612

Ja. Da brauchst du nicht erst die Dateien jeweils einzeln konvertieren und einfügen...

Es gibt hier in der Webdisk auch einen o3d-Importer. Da kannst du auch die komplette Modell-Datei auswählen und es fügt dir ALLE Dateien direkt in Blender rein.

EDIT:

Hatte BusfahrerP ja schon geschrieben

Zitat von BusfahrerP

Es gibt (sogar mit Webdisk-Download!) das Blender Plugin, was sogar theoretisch ganze Model.cfg's einlesen kann. Blender-O3D-IO Plugin

Ja. Egal in welche Varlist, hauptsache in eine, die der Bus auch verwendet.

Oben rechts auf die Ebene

Doppelt drauftippen

Da sich dieser Tag auf den jeweils vorherigen [sound]-Tag bezieht, vorsichtig ausgedrückt: irgendwo darunter.

[sound]

... Also hier

[sound]

... oder hier

[sound]

... oder da.

Da würden eher andere Fehler auftauchen, wenn OMSI an seine Grenzen kommt.

Damit kann in der Sounddatei bestimmt werden, wann der Sound abgespielt werden soll.

[conditionSingle]
Deine Variable
Wert der Variable
Bedingung*

*)

0 = ??

1 = Wert der Variable muss <...> sein

2 = Wert der Variable muss kleiner als <...> sein

3 = Wert der Variable muss größer als <...> sein

4 = Wert der Variable muss kleiner oder gleich <...> sein

5 = Wert der Variable muss größer oder gleich <...> sein

Quelle: Sound config explaination needed - Textur- und Sounddesign - Marcels OMSI-Forum (omnibussimulator.de)

Zitat von Sparky54

Es ruckelte nur hin und wieder kräftig.

Dadurch, dass es die Logfile mit entsprechenden Einträgen befüllt, kann es natürlich dazu führen, dass das Game ruckelt. Ansonsten kann es auch einfach an den Einstellungen liegen, dass diese zu hoch angesetzt sind. Das kann man also so pauschal nicht sagen.

Und da wie gesagt bei deinem Calculate-Error keine weiteren Infos in der Log stehen, kann man nur mutmaßen und weitere "Experimente" durchführen. Also z.B. AI-Fahrzeuge austauschen, auf anderen Maps verwenden, ... - damit man zumindest erstmal weiß woran genau es denn liegt.

Calculate-Error's (J2 bzw. J3) sind eigentlich recht einfach zu bewältigende Fehler. Die sagen einfach nur aus, dass etwas im Script nicht berechnet werden kann. Meist hängt dies aber mit einer fehlenden Variable bzw. Stringvariable zusammen, welche zusätzlich zu diesen Calculate-Error's in der Logfile mit auftauchen sollte.

Man kann das in etwa mit einem Beispiel aus der Realität ganz gut erklären:

Du ziehst in eine neue Wohnung und möchtest deine ganzen Bücher aus'm Regal mitnehmen. Dir wird gesagt, du sollst sie in die Kiste mit der Aufschrift "Bücher" legen. Die betroffene Kiste ist jedoch nicht da. Also stehst du mit deinen Büchern in der Hand da, wartest auf weitere Anweisungen (die nicht kommen) und alle weiteren Aufgaben werden nicht gemacht.

Und so ist das eben auch in OMSI... jede Variable / Stringvariable musst du dir als Kiste vorstellen. Und die ganzen "Kisten" findest du aufgelistet in der Varlist bzw. Stringvarlist.

Das ist richtig, man kann die Farbe auch weiterhin über den Quellcode ändern. Aber die meisten nutzen eben nur die Farbpalette und wenn es da einige Töne nicht mehr gibt, werden die sich da auch nicht wirklich die Mühe machen und das über den Quellcode zu ändern.

Korrekt… das ist hier aber leider kein Wunschbrunnen

Du kannst entweder weitere Helfer suchen, wenn du dich selbst mit dran beteiligst oder ziehst eben den Kürzeren und gehst leer nach Hause.

Eine Map oder in dem Fall ein Fahrzeug zu bauen, erfordert sehr viel (Vorbereitungs)Zeit. Das ist nicht binnen weniger Monate fertig. Da sitzt man gut und gerne 1-2 Jahre dran, wenn‘s wirklich passend werden soll.

Und es wird sich auch keiner beim Lesen deines Threads mit einem Motivationskick versehen fühlen.

Ja, man kann fragen, ob sowas bereits in Bau ist, aber es gäbe auch noch Google, da wäre deine Frage damit beantwortet gewesen.

Wie gesagt, kannst ja gerne schon anfangen den Wagenkasten zu bauen und paar Scripts zu schreiben, dann wäre die Chance — dass sich Helfer finden — deutlich höher.

Es ist schwierig zu sagen, woran es genau liegt...

    (L.L.IVU_schedule_active_2)
    (L.L.IVU_eingegebene_Fahrtnummer) 0 > (L.L.IVU_eingegebene_Umlaufnummer) 0 > || &&
    (L.L.IVU_HST_pos) (L.L.IVU_Anzahl_Haltestellen_Route) 1 - < &&
    {if}
        (L.L.IVU_Ueberpruefer_1) (L.S.Timegap) + 1 min (S.L.IVU_Ueberpruefer_1)
        1 >=
        {if}
            (M.V.GetTTBusstopIndex) (L.L.IVU_TT_Haltestellen_Index_last) =
            {if}
                0 (S.L.IVU_Ueberpruefer_1)
            {else}
                (L.L.IVU_Ueberpruefer_2) 0 =
                {if}
                    (M.L.IVU_Haltestelle_weiter)
                    1 (S.L.IVU_Ansage_aktiviert) (S.L.IVU_FIS_Mod)
                {endif}

                (M.V.GetTTBusstopIndex) (S.L.IVU_TT_Haltestellen_Index_last)
                0 (S.L.IVU_Ueberpruefer_1)
            {endif}
        {endif}
    {endif}

Das wäre der Abschnitt, welcher als einziger das Makro enthält, dass die Haltestellen fortschaltet.

Entweder dieser selbst oder eine Variable triggert falsch und damit ergibt sich das o.g. Problem. Ich finde es aber gerade auf Anhieb nicht woran es liegen könnte...

EDIT:

Es könnte tatsächlich an der Zeile mit (M.V.GetTTBusstopIndex) (L.L.IVU_TT_Haltestellen_Index_last) = liegen, da dort nicht etwa ein Name der Haltestelle abgefragt wird, sondern eine ID. Und wenn Start- und Endhaltestelle nicht unbedingt denselben busstop-Würfel nutzen, erkennt er es als eine andere Haltestelle und schaltet eben schon weiter.

Zitat von some1

Das tun andere Ibis-Systeme aber nicht.

Logisch... weil die entweder keine automatische Weiterschaltung oder die Haltestellen aus dem OMSI-Fahrplan nehmen und nicht aus der Hofdatei.

Was Hä? ?

Dass die IVU direkt auf die 2. Haltestelle schaltet, liegt am Wechsel des Fahrplans (also von der Endhaltestelle des vorherigen Fahrplans auf die Starthaltestelle des aktuellen Fahrplans). Das ist für OMSI eine neue Haltestelle. Da die IVU aber bei der alten Route an der letzten Haltestelle logischerweise nix mehr weiterschalten kann, speichert die sich das (wohlgemerkt ungewollt) und macht das bei nächster Gelegenheit, in dem Fall, wenn du eine neue Route auswählst.

Entfernen kannste da nix. Die IVU schaltet weiter, sobald sich in OMSI die aktuelle Haltestelle (oben in der roten Zeile) ändert.

Da bei einer Endhaltestelle nix weitergeschalten werden kann, sich jedoch der Fahrplan ändert (und demzufolge die aktuelle Haltestelle), merkt sich das die IVU und macht das bei der nächsten Route die man angibt.

Naja, du hast in deinem Script die Variable IBIS_Route durch einen Ausgangsport der IVU ersetzt. Was willst du denn damit erreichen?

 (L.$.IVU_Fahrgastinformation_Ausgang_10) 0 = ! &&

Zumal das hier ohnehin nicht funktioniert.

Wenn, dann bitte so:

' Endhaltestelle anzeigen
    (L.L.TFT_startup_timer_stopped)
    (L.L.startup_fail) ! &&
    (L.L.IVU_eingegebene_Fahrtnummer) 0 = ! &&
    (L.L.TFT_Werbung_anzeigen) ! &&
    {if}
        (L.$.IVU_Fahrgastinformation_Ausgang_10) (S.$.TFT_Endhaltestelle)
    {else}
        "" (S.$.TFT_Endhaltestelle)
    {endif}

Hmm... da steht jetzt nix weiter drin. Hast du denn irgendwas an den Kisten abgeändert/gemoddet?

Übliche Frage:

Was trägst du dazu bei? Lass mich raten: Nichts?

Nach dem Iveco und Setra LE ist nun auch das dritte Mitglied der UBB-Familie in OMSI verewigt!

Unverkennbar ein ehemaliger Setra des Regionalverkehrs Münsterland. Leider sind jedwede Daten über den vorherigen Lebensweg unbekannt...

Der ehem. Wagen 267 steht jedoch seit Ende 2022 abgemeldet auf'm Betriebshof in Ahlbeck, findet aber in OMSI hiermit seinen Neuanfang!

Setra S 319 NF · Friedrichstadt

Noch ein paar "Kleinigkeiten", und dann ist die ehemalige RVM-Bude fertig...

Setra S 319 NF · Tettau