Beiträge von S.A.D.

Guten Morgen,

erst einmal Danke für den Nikolausbeitrag

Leider ist beim Packen des Türchens wohl etwas aus dem Nikolaussack gefallen, da Objekte von iStanley und jjb leider nicht mitgeliefert werden.

Glücklicherweise sind beide in der verfügbar:

LG

S.A.D.

Grundsätzlich ja.

Allerdings müsstest du noch aus den so berechneten Sekundenwerten die Stunden und Minuten rausrechnen und als String speichern.

(M.V.GetTTBusstopIndex) (M.V.GetTTBusstopDep) (M.V.GetTTDelay) + s0

l0 60 % s1
l0 l1 - 60 / s0
l0 60 % s2
l0 l2 - 60 / s0

l0 $IntToStr ":" $+ l2 $IntToStr $+ (S.$.Halt0Zeit)

Diese Berechnung kann natürlich noch besser als makro definiert werden um sie nicht x-mal Schreiben zu müssen.

(M.V.GetTTBusstopIndex) (M.V.GetTTBusstopDep) (M.V.GetTTDelay) + (M.L.UhrzeitHHMM)

.
.
.

{macro:UhrzeitHHMM}
s0
l0 60 % s1
l0 l1 - 60 / s0
l0 60 % s2
l0 l2 - 60 / s0
l0 $IntToStr ":" $+ l2 $IntToStr $+
{end}

Und natürlich muss der Text auf dem TFTMonitor richtig platziert werden.

Allerdings solltest du zusätzlich beachten, dass bei diesem Vorgehen die Verfrühung auch wieder Minuten abzieht, sodass dafür eine skriptabhängige Lösung gefunden werden muss, sofern keine vor dem Fahrplan liegenden Abfahrtszeiten angezeigt werden sollen.

Korrektur:

Bei der Berechnung der Abfahrtszeiten muss das (L.S.Time) und auch das + hinter (M.V.GetTTBusstopDep) weg.

(M.V.GetTTBusstopDep) liefert bereits die planmäßige Abfahrtszeit.

Sonst hat man z.B. bei Abfahrt 11:58 auf einmal 23:56 stehen.

Ergänzung:

(M.V.GetTTDelay) entspricht der Verspätung zur Ankunft.

Wenn in einem Fahrplan die Abfahrtszeit nicht gleich der Ankunftszeit ist sollte für eine korrekte Abfahrtsverspätung der Korrekturfaktor (M.V.GetTTBusstopArr) (M.V.GetTTBusstopDep) -  addiert werden.

Heute hat mich, nachdem ich es die letzten Tage noch zurückhalten konnte, ein reales, bzw. in Omsi Semireales, Repaint überrollt.

Daher habe ich mich hingesetzt und nach Fotorecherche dem kürzlich erschienenen Ikarus 417 einen WSW-Lack spendiert.

Da es (aktuell) in Omsi nur den Ikarus 417.08 mit 4 Türen gibt, die WSW 1995 aber 17 Ikarus 417.04 mit nur 3 Türen in Dienst stellten, ist die Umsetzung etwas kompromissbehaftet. Auch wenn ich die Fahrzeuge nie in echt erlebt habe, wollte ich diese Exoten aus meiner Uni-Stadt zumindest grob umsetzen.

Die Testfahrt beginnt an der Zeche Hindenburg in Ahlheim Sternenberg. [Front und Fahrerseite]

Eigentlich würden beim Original eine Heckscheibe und ein steigender Fußboden im Heck ohne Tür 4 anzutreffen sein. Die Logos wären Weißgrundig auf der Heckscheibe zu finden. (Die Spiegelung ist auch ein Workaround um die Anzeige zu verstecken.) [Heck und Türseite]

Alle (echten) Türen auf am S-Bahnhof in Liederbaum. Gut zu sehen sind die Roten Türen und Stangen. Die verwendeten Farben entsprechen denen des (zu diesem Zeitpunkt recht neuen) WSW-Logos. Produktstreifen und Stoßstangen in Blau, wie die Grundfarbe des Logos und Akzente in Rot, entsprechend dem Akzentpunkt.

Angekommen am Bostoner Weg steht erst einmal Pause auf dem Plan. Wer mein das Fahrzeug hätte in diesem Zustand wenig rot: Ausgeliefert wurden die Busse mit Roten Spiegeln und Felgen. Die Ersatzteile wurden dann hinterher nicht extra lackiert, sodass etwas mehr Schlichtheit Einzug erhielt.

Karte/Map: Ahlheim V4 (Webdisk)

Bus: Ikarus 417.08 (Webdisk)

Hallo DanieCeBus ,

Der akute Fehler, durch den die Objekte fehlen ist wohl:

128 19:20:12 -  -   Error:           In "vehicles\AC O530 LE\model\O 530_Sub.cfg" there was an error in line 4695!

Also wäre hilfreich einmal diese und umliegende Zeilen auf Fehler zu überprüfen.

Außerdem kann

127 19:19:59 -  -   Error:           vehicles\AC O530 LE\model\ibox/ibox_body.o3d   o3d reading failed - Could not read the o3d file! Ung ltiger Dateiname - %s

nicht geladen werden, wohl wegen umgekehrtem /.

Da das allerdings der Standarddrucker ist, könnte das wohl auch weg.

Dann zu fehlenden Makros und Variablen:

116 19:19:21 -  -   Error:           Fehler: im Befehl "(S.L.IBIS_Linie_Complex)" (vehicles\AC O530 LE\\script\IVU_Ticketbox.osc) ist der Variablenname ung ltig!
117 19:19:52 -  -   Error:           Fehler: im Befehl "(L.L.IBIS_Linie_Suffix)" (vehicles\AC O530 LE\\script\IVU_Ticketbox.osc) ist der Variablenname ung ltig!
118 19:19:53 -  -   Error:           Fehler: im Befehl "(S.L.IBIS_Linie_Suffix)" (vehicles\AC O530 LE\\script\IVU_Ticketbox.osc) ist der Variablenname ung ltig!
119 19:19:54 -  -   Error:           Fehler: im Befehl "(S.L.IBIS_Linie_Suffix)" (vehicles\AC O530 LE\\script\IVU_Ticketbox.osc) ist der Variablenname ung ltig!
120 19:19:54 -  -   Error:           Fehler: im Befehl "(M.L.KISchilderung)" (vehicles\AC O530 LE\\script\citaro_main_AI.osc) ist der Macroname ung ltig!

Sind in der Busdatei die Zahlen am Anfang der Variablengruppen gleich mit der Anzahl der Einträge? Es scheint nämlich so, als würden nicht alle Scripts/Varlists geladen.

Da der Bus kein eigenständiges Matrix-Script hat, sondern dieses in der originalen ibox.osc mit drin ist wäre das auch zwingende Voraussetzung, damit überhaupt geschildert werden kann.

Evtl. müssen auch noch Brückenscripts zwischen IVU und Matrix installiert werden.

Ich hoffe, ich konnte dir ein wenig weiterhelfen.

LG

S.A.D.

Zitat von Saarlodri

ich kann die AI Group bedenkenlos erweitern ?

Ja, das ist an sich bedenkenlos möglich.

Zitat von Saarlodri

Am besten dann fortlaufend oder und woher weiß man das mit den 45 Solo/ 90 Gelenk ?

Du kannst sowohl einfach fortlaufend, als auch theoretisch mit vollständig zufälligen Nummern arbeiten.

Wenn es realistisch sein soll, dann bekommt jedes Fahrzeug eine eigene Nummer. Doppelte Nummern und Kennzeichen sind aber sonst (zumindest in diesem Fall) nicht weiter relevant.

Die Zahlen habe ich aus der Umlauftabelle in den Begleitdokumenten geschätzt. Daher müssten, wenn man ganz genau ist, eigentlich auch noch ein paar Fahrzeuge für KI-Linien dazukommen (Jeweils 5-10 Stück).

Dieses Problem tritt dann auf, wenn zu wenig einzelne Fahrzeuge für die verkehrenden Dienste eingetragen sind.

Deshalb nimmt Omsi, da kein Repaint festgelegt wurde, das Repaint mit dem niedrigsten Index, also beim HB MAN in deinem Fall das AVG Repaint.

Da keine Nummern und Kennzeichen definiert wurden sind diese entsprechend leer.

Die Rogis Ai-Groups benötigen ca. 45 Solobusse (in der AI-List stehen 16) und 90 Gelenkbusse (in der AI-List stehen 22) um für jeden Dienst ein Fahrzeug zur Verfügung zu haben.

Dementsprechend solltest du bei diesen Ai-Groups noch weitere Busse Hinzufügen (Neue Nummer, Neues Kennzeichen, Repaint).

Mit mindestens 2/3 der maximal benötigten Werte sollte der Fehler bereits nicht mehr in einer normalen Spielzeit auftreten, da ja nicht alle Einsatzwagen gleichzeitig fahren.

LG

S.A.D.

P.S.: Alles gute zum Geburtstag

Bei den PAD-Labs Objekten und Splines handelt es sich um Teile des Addon Köln. Dieses ist daher zwingende Voraussetzung für die Map.

Guten Abend,

da ich mein Omsi gerade vollständig neu Aufsetzen musste suche ich mir aktuell über die Webdisk verschiedene Busse und Repaints wieder zusammen.

Dabei ist mir aufgefallen, dass in der Repaintkategorie Neoplan / N4416 Centroliner (Solo) der verlinkte Bus (https://forum.omnibussimulator…read/51200-neoplan-n4416/) nicht der ist, welcher für die meisten nach nochmaligem nachschauen: alle Repaints vorausgesetzt wird (ja, ich habe jetzt alle runtergeladen...). Die Repaints verwenden folgendes Modell: https://forum.omnibussimulator…-beta-v-0-7-patch-update/

Wäre es möglich den Fahrzeuglink entsprechend an den tatsächlich verwendeten Bus anzupassen?

Außerdem gibt es beim N4416 noch ein paar Zuordnungsfehler (weil ich eh grad was schreibe):

Zitat von B3R71N K1Dz

Lediglich O530G Modded und O530 Modded sind von außen weiß. Der Innenraum wird aber normal geladen. Da weiß ich aber nicht woran es liegt...

In den LemmentalV3.cti der RVL Repaints gibt es einen systematischen Fehler. Im Texturnamen steht immer ...RVL2... obwohl die Dateien nur ...RVL... heißen (jeweils bei den Einträgen für die Außentxtur). Wenn du da die extra 2 entfernst sollten die Busse auch normal aussehen.

Außerdem ist sind durch die abweichende Kodierung bei den Repaints mit ä,ö,ü dort Leerzeichen entstanden, da diese in UTF-8 anders als in ANSI nicht als "normale" Buchstaben gespeichert werden.

Evtl. mach auch die Kodierung den Fehler der KI-Busse, da in beiden Dateien die gleiche (auch verwendete) ai-group VVK steht.

Man kann das Ganze über die Verortung auf der Erde beeinflussen. Dazu müssen in der "timezone.txt" entsprechend Eingaben zur Zeitzone und zur Verortung auf der Welt gemacht werden. Genaueres gibt es in dem Tutorial hier.

Zitat von Rafi_Freiburger

in der cti datei? da kam nämlich nichts mit BC3

Nein, wenn du die .pdn Dateien in paint.net geöffnet hast gehst du in der Menüleiste auf: Datei -> Speichern unter...

Dann öffnet sich erst die Speicherortauswahl (da als Dateityp .dds auswählen), dann öffnet sich ein Einstellungsfenster in dem du dann oben BC3 (Linear, DTX5) auswählst und dann mit diesen Einstellungen speicherst.

Die ggf. auftretende Meldung "Ebenen zusammenfassen" unbedingt mit "Zusammenfassen" bestätigen.

Zitat von Rafi_Freiburger

wo stelle ich das mit BC3 ein?

Beim Speichern als .dds.

Omso kann .pdn Dateien nicht verarbeiten.

Speicher die Dateien bitte als .dds mit dieser Einstellung (und in der .cti als .dds eintragen).

Der Dateiname für den Wagenkasten ist fehlerhaft.

Im ersten [item]-Block muss in der unteren Zeile "Ruhrau\SU12IV_2D_ElectricRuhrau.dds" stehen (ohne ").

Außerdem ist die .cti-Datei, die du hier angehängt hast eigentlich eine .txt bei der das ".cti" Teil des Namens ist.

Am besten aktivierst du im Menü im Bereich Ansicht den Punkt "Dateinamenerweiterungen", damit du auch die Typenbezeichnung der Dateien angezeigt bekommst.

LG

S.A.D.

Hi Jannik,

für die Stop-Anzeige müsstest du beim Monitor (in der Model.cfg) unter dem [Mesh] "Projekt Bremen\_BSAG_Anzeige_STOP.o3d" beim [visible] Eintrag "c2step3_haltewunsch" durch "haltewunsch_geber" ersetzen, dann sollte der funktionieren.

//Edit: Am besten auch im darunterstehenden [matl_lightmap] gleiches ersetzen.

Bezüglich Bildschirmwechsel könntest du versuchen über [matl_freetex] zu gehen, also den Block [matl_change] unter dem [mesh] "Projekt Bremen\_BSAG_Anzeige_Bildschirm_Rechts.o3d" durch einen Block [matl_freetex] ersetzt und dann in einem Skript einen Wechsel programmierst.

[matl_freetex]
BSAG_Innenanzeige_Bildschirm_02.dds
Bildschirmwechselstringvariable

Wobei "Bildschirmwechselstringvariable" Platzhalter für die Variabel ist. Diese müsste noch in eine Stringverlist eingetragen werden.

Das Zusatzskript könnte ungefähr so aussehen:

(L.L.elec_busbar_main)
{if}
    (L.L.WerbungBildschirmNummer) _Maxwert_ <
    {if}
        (L.L.WerbungBildschirmTimer) _Wechselzeit_ >=
        {if}
            (L.L.WerbungBildschirmNummer) 1 + (S.L.WerbungBildschirmNummer)
            "Pfad_zur_Textur_und\Texturname_" (L.L.WerbungBildschirmNummer) $IntToStr $+ (S.$.Bildschirmwechselstringvariable)
            0 (S.L.WerbungBildschirmTimer)
        {else}
            (L.L.WerbungBildschirmNummer) 0 =
            {if}
                1 (S.L.WerbungBildschirmNummer)
                "Pfad_zur_Textur_und\Texturname_1" (S.$.Bildschirmwechselstringvariable)
                0 (S.L.WerbungBildschirmTimer)
            {endif}
        {endif}
    {else}
        (L.L.WerbungBildschirmTimer) _Wechselzeit_ >=
        {if}
            1 (S.L.WerbungBildschirmNummer)
            "Pfad_zur_Textur_und\Texturname_1" (S.$.Bildschirmwechselstringvariable)
            0 (S.L.WerbungBildschirmTimer)
        {endif}
    {endif}
    (L.L.WerbungBildschirmTimer) (L.S.Timegap) + (S.L.WerbungBildschirmTimer)
{else}
    0 (S.L.WerbungBildschirmTimer)
    0 (S.L.WerbungBildschirmNummer)
    "Pfad_zur_Textur_und\Texturname_0" (S.$.Bildschirmwechselstringvariable)
{endif}

Die Variablen "WerbungBildschirmNummer" und "WerbungBildschirmTimer" (auch frei wählbar) müssten in eine Varlist, und die Werte _Maxwert_ (Anzahl) und _Wechselzeit_ (Sekunden) durch eine Zahl ersetzt werden.

Die Texturen liegen alle am gleichen Ort und heißen bis auf die Endziffern gleich (z.B. BSAG_Innenanzeige_Werbung_) wo dann immer die Nummer ergänzt wird.

Der entspechende Pfad und Name wird im ersten Abschnitt ohne Endziffer und bei den Spezialfällen "aus" und "zu 1" mit Endziffer eingetragen.

Das ganze müsste in einen {frame}-Abschnitt eingetragen werden.

Das ganze ist allerding bislang nur Theorie und nicht getestet.

Taurusdriver

Das Standardrepaint hat keine cti, sondern ist das Fahrzeug ohne Textur- und Setvaränderungen.

Wenn du nur setvars anpassen willst kannst du eine neue .cti im Ordner Werbung_21C (ggf. neu erstellen) anlegen und dort mindesten einen Texturtausch eintragen und darunter die Setvars zum Anpassen.

KNSH Ist das evtl. der E6 mit altem Dashboard?

Da war ein Fehler in der Model-Datei, weshalb die Stangen nicht richtig funktionierten.

Zitat von S.A.D.

Zitat von lukas_evag

C2 E6 Solo Altes FAP

Bei dem Modell liegt bei den Stangen ein Fehler in der model_MB_C2_E6_Solo_altesDashboard.cfg vor (Abschnitt Textur-Changes).

Vor dem Dateinamen bei Stangen steht dort noch ein weiteres Zeichen, welches den Texturnamen verändert. Einfach das Zeichen löschen, so dass nur noch der Dateiname da steht und es sollte funktionieren.

Im normalen Editor wird dies allerdings nicht angezeigt.

Einfach den ersten Buchstaben löschen und den "Umbruch" löschen und manuell wider eintragen.

MichaLP Für die IVU müsste folgendes angepasst werden:

In den Text-Texturen (Readme Punkt 3) muss die Stringvariable geändert werden.

Diese steht jeweils direkt unter [texttexture_enh].

Hier die Liste der Stringvariablen in Originalreihenfolge:

IVU_Fahrgastinformation_Ausgang_02

IVU_Fahrgastinformation_Ausgang_03

IVU_Fahrgastinformation_Ausgang_04

IVU_Fahrgastinformation_Ausgang_05

IVU_Fahrgastinformation_Ausgang_10

IVU_Fahrgastinformation_Ausgang_09

IVU_Fahrgastinformation_Ausgang_08

Bei der Matrix handelt es sich um eine Weiterentwicklung der K++, nämlich die scrollMatrix Version.

Diese hat, anders als die normale K++ probleme mit der universellen Hofdatei bzw ist mit dieser nicht/nur eingeschränkt kompatibel.

1891 10:51:01 -  -     Warning:       Did not find texture file "..\..\Anzeigen\Krueger\230x32\palettes\Krefrath V3.2 K++.bmp"!
1892 10:51:01 -  -     Warning:       Did not find texture file "..\..\Anzeigen\Krueger\230x32\scrollMatrix\JVA Ambach%B"!

Bzgl. weiße Liniennummer: Die scrollMatrix verwendet die Strings 13/14 als Texturpfad für eine scrollende Seitenmatrix.

Diese sind in der universellen Hofdatei eigentlich als Lawo Front 1./2. Zeile vorgesehen. Weil in der verwendeten Hofdatei in diesen Strings etwas drinsteht möchte die Matrix eine Textur laden, welche allerdings nicht existiert, weshalb die Anzeige einen Fehler anzeigt, also weiß wird.

Lösungsmöglichkeiten:

1) Die Strings löschen, weil sie von dieser Matrix nicht für den eingetragenen Zweck genutzt werden.

ggf. 2) Eine scrollMatrix erstellen und den korrekte pfad eintragen.

Ansonsten möchte die Matrix noch eine Palette an Farben haben, welche dann über weitere Sonderzuweisungen in der Hofdatei gewält werden können.

Das kann entweder ignoriert werden oder das Template kopiert und umbenannt werden (hat an sich keinen Einfluss ohne extra Einträge).

Vielleicht behebt das auch den Fehler, dass alles weiß wird, weil dazu kann ich gerade nichts in der Logfile finden.

Fehlermeldung:

Bei den 2014-2018er Bussen ist in der .bus Datei ein Tippfehler:

Im Abschnitt [constfile] steht script\churaKrueger\Vmatrix_constfile_K++_po.txt

es müsste allerdings script\churaKrueger\Vmatrix_constfile_K++_pc.txt heißen.

Edit:

Die Constfile für die Orangene Matrix wird nicht mitgeliefert.

LG

S.A.D.