Warte, bis der Bus genügend Druckluft aufgebaut hat. Das kann seine Zeit dauern.
Beiträge von DerGrafikfehler
Als Gast kannst du nur Inhalte in deiner ausgewählten Sprache sehen. Registrierte Nutzer können die Sichtbarkeit anderer Sprachen in ihrem Kontrollzentrum aktivieren, weitere Infos hier.
Alle Themen sind in den Foren mit einer Sprachflagge gekennzeichnet:
-
-
Da hast du dann ganz offensichtlich in der model.cfg unter einem [matl]-Eintrag eine Textur eingetragen, die in der Modelldatei (sei es eine .x oder .o3d) nicht vorhanden ist. Passiert gerne mal bei Schreibfehlern. Omsi scheint diese Fehler aber auch öfter mal auszuspucken, weils gerade passt.
-
Kleines Werkstättenründchen am 302er. Es wird ein neuer Bus samt neuem Zieletxtautomaten getestet.
Nach einer Runde dann als Einzier zum Bahnhof.....
....und von dort aus als Sonderwagen zurück zum Betriebshof.
Bus: G&S LU200M11 mit aesys-LED-Matrix
Map: Neuendorf
Repaint: Neuendorf
-
Mit Paint.net wirst du da wahrscheinlich nicht allzu weit kommen, weil du in Paint.net als solches keine Vektorgrafiken erstellen kannst. Da müsstest du mit einem anderen Programm wie z.B. Inkscape arbeiten, dass Vektorgrafiken unterstützt. Dann hast du auch diesen verlustfreien Effekt, den du in der pdf haben willst.
-
Ticket machine (any ideas on what make/model? I'm still not sure what to add)
Destination controller (will probably be some sort of LAWO compact unit, but I haven't started anything yet so change is completely possible)
Just throwing it in here, becaus why not: Something that definetly doesn't exist in Omsi: Transelektronik B2805 as IBIS combined with Krauth AK0139 (compact) as ticket machine. Or maybe a combination with Mobitec ICU 6020 with some sort of Atron Ticketprinter?
-
Mahlzeit in die Runde!
Ich habe (mal wieder) ein etwas größeres Problem. Ich istze momentan am AGG und versuche, dem ein anderes IBIS-System zu verpassen. Einfacher gesagt als getan. IBox rein, Heckmatrix geht nicht mehr. (Aufbauend auf dem K++-Mod, den ich gestern veröffentlicht habe.) Nachdem in Omsi aber Scripttexturen nur im ersten Nachläufer übernommen werden, muss ich hier mit zwei Matrixscripts arbeiten. Beide sind die gleiche Datei. Das funktioniert im Ursprungsmod einwandfrei. Nur eben mit dem Almex+Brückenscript. Nachdem die IBox aber bekanntlich legendär fehlerhaft ist, bin ich davon ausgegangen, dass es an den IBox-Scripts liegt. (Ansagen haben auch nur so halb bei aktiviertem Fahrplan funktioniert.) Also IBox-Scripts raus, standard-IBIS2-Scripts rein. Selbes Ergebnis, aber um eine Information schlauer, denn die Heckmatrix schildert erst, wenn ein Wechselziel geschildert wird.
Wenn ich ein einzelnes Ziel schildere (kein Wechselziel), sieht das so aus:
Die Matrix im Vorderwagen funktioniert einwdfrei, die Heckmatrix rührt sich gar nicht.
Wenn ich nun ein Wechselziel einschildere, funktioniert die Heckmatrix und wechselt das Ziel auch synchron mit der Frontmatrix durch, scildert das Ziel aber erst bem zweiten Wechselziel:
Wenn ich jetzt wieder ein normales Ziel einschildere, hängt sich die Heckmatrix wieder auf und zeigt nur das zuletzt geschilderte Wechselziel an:
Manuell ein Ziel zu überschildern bringt da auch nichts, das habe ich schon mehrfach probiert. Da kann man so oft überschildern, wie man will, die Matrix zeigt immer das letzte Wechselziel an.
Ich habe auch schon probiert, das Heckmatrixscript weitestgehend eigenständig zu machen seitens eigener Variablen, mit dem Ergebnis, dass diese dann gar nicht mehr funktioniert hat.
Mit meinem Latein bin ich jetzt komplett am Ende. Wo liegt da der Unterschied zwischen der vom Brückenscript beschriebenen Variablen und der vom IBIS beschriebenen Variablen? Sie müssen ja zwangsweise den gleichen Inhalt haben. Oder gibt es in Omsi eine Möglichkeit, Scripttexturen in ein anderes Fahrzeug zu kopieren?
Hat da jemand von euch eine Idee?
-
-
-
-
-
Das zeigt Omsi so an, braucht aber trotzdem nur ein einfaches Slash.
-
Gerne doch.
Also: Ursprünglich wollte ich ja diese Funktion aus dem Bremer MAN übernehmen, aber die VDV-Scripts vom Bremer und der Stadtbusfamilie verhalten sich komplett unterschiedlich, sodass ein einfaches Trigger eintragen nicht funktioniert. Der Code hier übernimmt diese Aufgabe:
Code
Alles anzeigen(L.L.bremse_halte_sw) {if} 1 (S.L.frei_geloescht) {endif} ' MÖÖÖÖP bei allen Türen zu: (L.L.door_0) 0.01 < (L.L.door_1) 0.01 < && (L.L.door_3) 0.01 < && (L.L.door_5) 0.01 < && (L.L.door_7) 0.01 < && (L.L.bremse_halte) && (L.L.abfahrtston) && (L.L.frei_geloescht) && (L.L.bremse_halte_sw) 0 = && {if} (T.L.ev_VDV_abfahrt) 0 (S.L.abfahrtston) {endif} (L.L.bremse_halte) 0.01 < (L.L.abfahrtston) ! && {if} 1 (S.L.abfahrtston) 0 (S.L.frei_geloescht) {endif}
Ich habe das hier bestmöglich nach Wiener Vorbild umgesetzt, heißt: Der Abfahrtston wird nur abgespielt, wenn zuvor die Türfreigabe gelöscht wird. Um das zu erkennen, wird eine entsprechende Variable ("frei_geloescht") beim Betätigen der Türfreigabe auf 1 gesetzt, und beim Lösen der Haltestellenbremse wieder auf 0 gesetzt.
Der eigentliche Block fragt ab, ob alle Türen zu sind (kleiner Bug existiert hier noch: wenn man einen Haltewunsch hat und die Türfreigabe setzt und direkt wieder löscht, löst der Summer trotz geöffneter Tür aus), die Haltestellenbremse angelegt ist und die Türfreigabe gelöscht wurde. Ist das der Fall, wird der Summer abgespielt. Die Variable "abfahrtston" dient hier als sehr primitive Lösung, um ein Dauerfeuer zu verhindern.
Wenn die Haltestellenbremse gelöst wird, dann wird die Variable wieder "scharf geschalten".
-
Für das Problem wäre glaub ich tempo1 der beste Ansprechpartner, der hat mWn die NF6D gebaut/war an der beteiligt, und bei der sind ebenfalls verschiedene Scripte in verschiedenen Fahrzeugteilen eingetragen.
-
-
-
So, Problem hab ich gefunden. Man sollte vielleicht nicht nichts mit irgendwas verunden und hoffen, dass dabei was rauskommt....
-
Guten Morgen allerseits!
Ich habe mich jetzt auch mal an die Omsi-Scriptsprache gewagt und versucht, dem NG313 einen Abfahrts-Summer zu verpassen. Soweit, so gut, der erste Code-Schnipsel funktioniert auch (so halb
).
Das hier ist der Code:
Code
Alles anzeigen' MÖÖÖÖP bei allen Türen zu: (L.L.door_0) 0.01 < (L.L.door_1) 0.01 < && (L.L.door_3) 0.01 < && (L.L.door_5) 0.01 < && (L.L.door_7) 0.01 < && (L.L.bremse_halte) && (L.L.abfahrtston) && (L.L.bremse_halte_sw) 0 = && {if} (T.L.ev_VDV_abfahrt) 0 (S.L.abfahrtston) {endif} (L.L.bremse_halte) ! && (L.L.abfahrtston) ! && {if} 1 (S.L.abfahrtston) {endif}
Mit dem Code bin ich schon mal so weit, dass ich, wenn ich die untere if-Abfrage und die Verundung der Variable Abfahrtston in der oberen if-Abfrage auskommentiere, (fast) den gewünschten Effekt erziele. Ohne diese Abfrage+Variable habe ich das Problem, dass der Summer auf Dauerfeuer ist, sobald alle Türen zu sind und die Türfreigabe raus genommen wurde.
Die Zusatzvariable samt if-Abfrage soll nun dazu dienen, um dieses Dauerfeuer zu unterbinden und den Summer bei geschlossenen Türen und gelöschter Türfreigabe genau ein Mal abgespielt wird. Das funktioniert auch, nämlich genau ein Mal nach dem Spawnen des Busses. Dementsprechend müsste hier der Fehler liegen. Mit meinem mäßigen Programmierer-Latein bin ich hier aber am Ende.....
Ich gehe aber davon aus, dass die Variable für die Haltestellenbremse (die ist bei gelöschter Türfreigabe und geschlossenen Türen ja noch aktiv, bis man das Gaspedal antippt) hier nicht die richtige ist. Kann das sein? Und wenn ja, wo würde ich die richtige Variable hierfür finden?
-
Oder missachtet die KI schon immer die roten Ampeln??
Es gibt tatsächlich eine Einstellungsmöglichkeit für KI-Fahrzeuge, hießt Rowdy-Faktor oder so ähnlich. Da kann man irgendwie einstelllen, wie extrem die KI Verkehrsregeln missachtet. Wird in der .ovh eingestellt.
(Angaben ohne Gewähr, mein Wissensstand ist aus 2014.)
-
-
Die Dateien dafür sind so ziemlich alle anderen Dateien, die mit "chrafont-n" beginnen. Welche da für welche Textlänge zuständig ist, ist da leider relativ schwer zu sagen....