= Englisch [EN], 
= Deutsch [DE], 
= Französisch [FR]. Wenn du die angegebene Sprache nicht beherrschst, schreibe auf Englisch! Es muss irgendwo hin, wo der Code in jedem Frame ausgeführt wird.
Auf Nummer sicher gehst du auf jeden Fall, wenn du das direkt in den {frame}-Bereich des Busses direkt irgendwo einfügst.
Allerdings haben ja auch manche "Buskomponenten" eigene Frame-Makros, die aus dem {frame} heraus aufgerufen werden.
Dort könntest du es theoretisch genau so eintragen. Das ist ziemlich Banane.
Ich bin mir nicht 100% sicher, ob ich dein Problem bzw. Anliegen richtig verstanden habe. Du willst also eine Art "Timeout" haben, dass, wenn ein Trigger einmal ausgelöst wird, er für eine Zeitspanne von x Sekunden quasi blockiert und nicht ausgeführt wird, bis diese Zeitspanne eben um ist. Quasi ein Cooldown. Das kannst du relativ einfach mit etwas Gescripte lösen.
Hier mal ein Beispiel:
Dieser Script-Abschnitt muss in jedem Frame ausgeführt werden.
Du musst ihn also in deinen Bus-Frame einfügen bzw. in ein passendes frame-Makro
{frame}
'Aktualisiere den Cooldown-Timer (allerdings begrenzt auf die Cooldown-Zeit, um einen Überlauf zu verhindern.
(L.L.dein_trigger_cooldownTimer) (L.S.Timegap) + (C.L.dein_trigger_cooldownTime) min (S.L.dein_trigger_cooldownTimer)
{end}
{trigger:dein_trigger}
'Führe den Trigger nur aus, wenn der Cooldown abgelaufen ist
(L.L.dein_trigger_cooldownTimer) (C.L.dein_trigger_cooldownTime) >=
{if}
'Hier kommt dein eigentlicher Trigger-Code hin
'...und am Ende den Cooldown-Timer auf 0 setzen (um den Cooldown quasi zu "starten")
0 (S.L.dein_trigger_cooldownTime)
{endif}
{end}Folgende Variable (kannst sie letztendlich auch anders nennen) muss in die Varlist eingetragen werden:
Die gewünschte Cooldown-Zeit legst du am elegantesten in einer Constfile fest:
Hier die gewünschte Cooldown-Zeit (in Sekunden) für deinen Trigger eintragen (hier z.B. eine Sekunde)
[const]
dein_trigger_cooldownTime
1Ich hoffe, das ist alles so verständlich, sonst frag' gerne nach.
Einen guten Tag zusammen,
beim Werkeln und Scripten an meinem Nuntius-Drucker bin ich auf die Idee gekommen, dort auch eine Anzeige zu implementieren, die mir auf dem Bildschirm anzeigt, in wie vielen Metern die nächste Haltestelle kommt.
Man kennt das ja heutzutage vom ein oder anderen, modernen Drucker, wenn die mit GPS ausgestattet sind, dass sie anzeigen, wie weit die nächste Haltestelle noch entfernt ist.
Leider hat OMSI kein direktes Makro oder Variable, mit der es möglich ist, die Entfernung zur nächsten oder zwischen Haltestellen direkt abzufragen und anzuzeigen.
Dennoch dürfte es mit einigen Tricks und etwas Gerechne möglich sein, diese zumindest angenähert zu bestimmen.
Dieses Konzept möchte ich euch hier gerne kurz vorstellen. Ganz unten findet ihr dafür auch ein fertiges Script, was ihr gerne in euren Bussen und für eure Projekte verwenden dürft. Ich erhebe kein Copyright darauf. Feel free to do what you want. 
Für alle, die nicht einfach nur das fertige Script (ihr findet es unten) kopieren wollen, sondern auch tatsächlich verstehen wollen, warum und wie es funktioniert, hier die Erklärung, wie ich es mir überlegt habe und was der "Plot" ist:
Es ist zuerst wichtig, die folgenden Informationen bzw. Konzepte notwendig zu kennen/verstehen.
Wichtig ist noch, dass wir immer nur von einer Haltestelle zur nächsten denken. D.h. wir gehen immer davon aus, wir befinden uns gerade irgendwo zwischen zwei Haltestellen einer Route und wollen die Entfernung zur nächsten bestimmen.
Tatsächliche Abfahrt an der letzten
Haltestelle (inkl. Verspätung): 12:00:00 Uhr
----------------------------------------------------------
Voraussichtliche Ankunft an der
nächsten Haltestelle
(Fahrplanzeit + derzeitige Verspätung): 12:01:00 Uhr
----------------------------------------------------------
Aktuelle Uhrzeit: 12:00:15 Uhr
----------------------------------------------------------
"An nächste Haltestelle - "Ab letzte Haltestelle" = 60 Sek.
"Aktuelle Uhrzeit" - "Ab letzte Haltestelle" = 15 Sek.
15 Sek. / 60 Sek. = 0.25
====Das bedeutet jetzt also, dass ein Viertel der Zeit zwischen beiden Haltestellen verstrichen ist. Wenn wir nun von einer konstanten Geschwindigkeit ausgehen, bedeutet das, dass auch ein Viertel der Strecke bereits zurückgelegt wurde und dementsprechend noch 3/4=0.75 fehlen.
Wenn wir jetzt auch noch von einem konstanten Haltestellenabstand insgesamt ausgehen würden, könnten wir die übrige Entfernung bereits exakt berechnen. Gerade auf Überlandmaps, wo innerhalb von Ortschaften Haltestellen eng zusammenliegen können, zwischen Orten aber auch große Entfernungen haben, ist das jedoch etwas doof. Deshalb wollen wir das nun ändern. Dazu brauchen wir nur die Variablen kmcounter_km und kmcounter_m, welche zusammen den Kilometerstand repräsentieren.
25% Zeit vergangen => 100m gefahren.
100m / 25% = 400m => gesamte Entfernung zwischen den Haltestellen
Bereits zurückgelegte Entfernung wieder subtrahieren:
400m - 100m = 300m
====Damit haben wir nun also die Entfernung zu nächsten Haltestelle auf 300m bestimmt.
Wie bereits zum Anfang betont, ist das kein exakter Wert sondern nur eine Annäherung, da wir immer von einer konstanten Geschwindigkeit ausgehen müssen. Besser geht es leider nicht. Es ist und bleibt also immer eine "Prognose".
Der Wert wird jedoch genauer, je weiter wir fortgeschritten sind. Nach 10% Strecke haben wir nur eine sehr kleine Stichprobe an bestehenden Daten und die 90% übrige Strecke werden aus dieser Stichprobe nur "hochgerechnet". Das ist natürlich nicht so genau, wie wenn schon 90% gefahren wurden und nur noch 10% errechnet werden müssen.
Die Berechnung wird genauer, je dichter man die Zielhaltestelle erreicht.
Damit das ganze aktuell bleibt, muss man natürlich diese ganze Berechnung regelmäßig (z.B. alle 10 Sekunden) neu durchführen.
Wichtig ist, dass man nicht nur die Entfernungsberechnung ("2. Teil vom Beispiel") neu berechnet, sondern tatsächlich alles, da sich ja z.B. beim schnellen oder langsamen Fahren auch die Verspätung ändern kann, die man dann immer wieder neu einrechnen und daher auch die Haltestellenzeiten immer wieder neu berechnen sollte, um möglichst genaue Werte zu erhalten.
Hier findet ihr nun meine Implementierung der Idee in OMSI. Es sind Kommentare vorhanden, die das meiste klären sollten. Baut euch den "Scriptschnippsel" gerne in eure Busse ein.
Als erstes müsst ihr euch allerdings noch die folgenden Variblen in einer Varlist eintragen:
busstopDistance_timer
busstopDistance_lastKmCounter_km
busstopDistance_lastKmCounter_m
busstopDistance_nextBusstopDistance
busstopDistance_lastIndexDies ist dann der Codeabschnitt für die Script-Datei.
Den Bereich im Frame-Abschnitt solltet ihr euch am besten einfach in euren Bus- bzw. Drucker-Frame mit integrieren. Das Makro busstopDistance_recalculateDistance kann bzw. sollte also in jedem Frame ausgeführt werden.
Das Makro busstopDistance_restartDistanceCalc muss immer dann ausgeführt werden, wenn die Abstandsmessung neu begonnen soll, d.h. wir z.B: eine Haltestelle erreicht haben und nun von dort den Abstand zur darauf folgenden bestimmen wollen. Darum kümmert sich der Frame-Abschnitt hier.
Am Ende steht in der Variable busstopDistance_nextBusstopDistance immer die Entfernung zur nächsten Haltestelle in Metern bzw. "-1" falls der Wert nicht ermittelt werden kann. Diesen könnt ihr nun mit einem Textfeld verbinden oder z.B. auf eine Texttextur schreiben.
'Frame-Abschnitt (am besten in euer Frame-Makro mit einfügen)
{frame}
'Wenn ein Fahrplan aktiv ist und die nächste Haltestelle sich von der im letzten Frame unterscheidet...
(L.L.schedule_active)
(M.V.GetTTBusstopIndex) (L.L.busstopDistance_lastIndex) = ! &&
{if}
'...wollen wir die Messung für die nächste Haltestelle neu starten
(M.L.busstopDistance_restartDistanceCalc)
{endif}
'In jedem Frame lassen wir die Distanz aber ggf. neu berechnen
(M.L.busstopDistance_recalculateDistance)
'Und wir merken uns den neuen Haltestellenindex.
(M.V.GetTTBusstopIndex) (S.L.busstopDistance_lastIndex)
{end}
'Zurücksetzen der Messung (notwendig, wenn eine Haltestelle erreicht wurde und nun die Messung zur darauffolgenden Haltestelle starten soll
{macro:busstopDistance_restartDistanceCalc}
(L.L.kmcounter_km) (S.L.busstopDistance_lastKmCounter_km)
(L.L.kmcounter_m) (S.L.busstopDistance_lastKmCounter_m)
5 (S.L.busstopDistance_timer)
(M.L.busstopDistance_recalculateDistance)
{end}
'Berechnet die Entfernung zur nächsten Haltestelle
{macro:busstopDistance_recalculateDistance}
'Timer aktualisieren
(L.L.busstopDistance_timer) (L.S.Timegap) + s0 1 % (S.L.busstopDistance_timer)
'Wenn Timer < 1 (d.h. jede Sekunde) neu ausführen (= Entfernung neu berechnen)
l0 1 >=
{if}
'Wenn wir uns noch vor der ersten Haltestelle befinden oder garkein Fahrplan aktiv ist, ist leider keine sinnvolle Berechnung möglich (d.h. Wert auf "-1" für "undefiniert" setzen)
(M.V.GetTTBusstopIndex) s0 0 = (L.L.schedule_active) ! ||
{if}
-1 (S.L.busstopDistance_nextBusstopDistance)
{else}
'Register-Verwendung:
'0 = Aktueller Haltestellenindex
'1 = Aktuelle Verspätung (in Sekunden)
'2 = Tatsächliche Abfahrtszeit an der letzten Haltestelle (eigentlich nicht die tatsächliche, sondern die basierend auf der aktuellen Verspätung)
'3 = Tatsächliche (prognostizierte) Ankunftszeit an der nächsten Haltestelle
'4 = Zeitdifferenz zwischen der letzten und der nächsten Haltestelle (in Sekunden)
'5 = Verstrichene Zeit seit Verlassen der letzten Haltestelle (basierend auf der aktuellen Verspätung)
'6 = Prozent (0...1), wo wir uns zeitlich zwischen der letzten und der nächsten Haltestelle befinden
'Verspätung abrufen
(M.V.GetTTDelay) s1
'Tatsächliche Abfahrtszeit an der letzten Haltestelle und Ankunftszeit an der aktuellen berechnen (Fahrplanzeit + Verspätung)
l0 1 - (M.V.GetTTBusstopDep) l1 + s2
l0 (M.V.GetTTBusstopArr) l1 + s3
'Differenzen berechnen
l3 l2 - s4
(L.S.Time) l2 - s5
'Relativen Wert bestimmen, wo wir uns auf dem "Zeitstrahl" befinden
l5 l4 / s6
'Nur berechnen, wenn die Stichprobe groß genug ist.
'Das bedeutet, dass das Script erst ab einer bestimmten relativen, zurückgelegten Distanz überhaupt anfängt, die Entfernungen tatsächlich zu berechnen, da bei kleineren Stichproben die Werte viel zu ungenau sind.
'Ich habe hier mit dem Wert 0.5 (also ab Hälfte der Strecke) gute Erfahrungen gemacht:
0.5 >=
{if}
'Register-Verwendung (ab hier Änderungen):
'2 = Gesamter Abstand in Metern von der letzten Haltestelle zur aktuellen Position
'7 = Berechnete Gesamtdistanz zwischen der letzten und der nächsten Haltestelle
'Differenzen der Entfernungen berechnen
(L.L.kmcounter_km) (L.L.busstopDistance_lastKmCounter_km) - 1000 *
(L.L.kmcounter_m) (L.L.busstopDistance_lastKmCounter_m) -
'...und zu einem Wert zusammenfassen
+ s2
'Gesamtdistanz zwischen den Haltestellen berechnen
l2 l6 / s7
'...und den bereits zurückgelegten Wert davon abziehen
l7 l2 - (S.L.busstopDistance_nextBusstopDistance)
{else}
-1 (S.L.busstopDistance_nextBusstopDistance)
{endif}
{endif}
{endif}
{end}Das war's soweit. Viel Freude damit.
Wenn ihr weitere Fragen oder Anmerkungen habt, könnt ihr sie im Folgenden gerne posten. 
Wenn dein oben gepostetes Logfile vollständig ist (wovon ich mal ausgehe), dann stürzt OMSI bei dieser Aktion ab:
D.h., OMSI versucht, einen KI-Bus auf der Map zu spawnen, kriegt es aber aus irgendeinem Grund nicht gebacken.
Hast du mal dein AI-List kontrolliert? Ist da vielleicht irgendetwas komisch oder sind einige Busse, die du als KI verwendest, defekt, sodass OMSI diese nicht spawnen kann?
Thomas U. Wir schicken jedes Jahr eine Rundmail automatisch an alle User los, dafür brauchst du nichts eingestellt zu haben.
Es kann sein, dass die nur bei dir im Spam Ordner gelandet ist.
Ich habe auch nie eine bekommen. Lag aber daran, dass ich (aus irgendeinem Grund) in den Einstellungen "Emails der Administration" deaktiviert hatte. Vielleicht ist das bei Thomas U. der gleiche Fall...
Jetzt ist es aktiviert:
Ich bin noch nie auf die Idee gekommen, OMSI von einer externen Festlatte aus zu starten.
Da das für das OMSI-Dateisystem eigentlich keinen Unterschied macht, sollte es aber in der Theorie auch eigentlich egal sein.
Was für eine externe Festplatte ist das denn? SSD oder HDD?
Falls es sich um eine HDD handelt (und du möglicherweise sehr viel Content, also Busse und Maps) installiert hast, kann es sein, dass der Startvorgang einfach wesentlich länger dauert. HDDs sind per se langsamer und wenn deine externe Platte dann noch nur per USB 2.0 am PC hängt, kann es gut sein, das OMSI beim starten deutlich länger braucht, alles einzulesen als vorher.
Falls du dieses Problem ausschließen kannst, gibt's noch weitere Gründe:
Ich meinte damit nur, dass deine Karte, solange du sie nirgends hochgeladen/also veröffentlicht hast, ja (logischerweise) noch privat ist, da nur du sie besitzt.
Wenn deine Karte fertig ist und die sie hier in der WebDisk hochladen und veröffentlichen möchtest, gehst du einfach auf die WebDisk-Startseite und klickst auf den "Hochladen"-Knopf rechts unten (bei mir ist die Oberfläche englisch):
Auf dieser Seite kannst du dann ganz oben deine Map als Archiv-Datei hochladen und alle weiteren Daten, die wichtig sind, angeben
(z.B. Name, Kateogrie, Versionsnummer, sowie natürlich Vorschaubild und eine Beschreibung).
Scrolle einfach durch das Formular durch und fülle alles aus.
Dann kannst du das ganze abschicken.
Die Filebase-Prüfer checken dann, ob mit deiner Datei alles passt (dass die Ordnerstruktur stimmt, alles richtig angegeben ist und es keine Urheberrechtsverletzung gibt).
Und dann wird es freigeschaltet und steht ab dem Zeitpunkt jedem öffentlich zum Download verfügbar.
Den Haken setzt du in der Filebase, wenn du eine neue Datei hochlädst. Dort gibst du auch Name, Vorschaubild usw. alles an und kannst dort dann auch diesen Haken setzen.
Deine Map kannst du da hochladen, wenn sie fertig ist. Wenn dann keine Copyright-Verstöße o.ä. vorliegen, wird sie auch von den Filebase-Prüfern freigeschaltet.
Allerdings solltest du die Map erst hochladen/veröffentlichen, wenn sie wirklich fertig ist. Solange du noch daran arbeitest, ergibt das nicht so viel Sinn und (noch) private Maps wird Pedepe wahrscheinlich nicht bei sich aufnehmen.
Das wird nichts bringen. Diese Gruppen müssen zusätzlich in der Datei unsched_vehgroups.txt hinterlegt werden.
Alle dort eingetragenen Gruppen müssen zwar auch in der AI-List unter gleichem Namen vorhanden sein, diese Datei teilt OMSI aber mit, dass die dort ebenfalls hinterlegten Gruppen für den unfahrplanmäßigen Verkehr (also keine Busse/Züge etc.) bestimmt sind.
Die Zahl darunter teilt OMSI mit, ob:
1. diese Fahrzeuge überall standardmäßig fahren dürften und dementsprechend ggf. Pfade manuell zu sperren sind
0. diese Fahrzeuge standardmäßig überall gesperrt sind (d.h. überall wo sie fahren dürfen, müssen die Pfade explizit freigeschaltet werden).
Beispiel:
Unscheduled Vehicle Group (UVG)
[group]
<aigroup-name>
<default density? 0 = no traffic by default, 1 = use density of first UVG by default, 2 = ...second..., ...;
if this is the first UVG, then 1 = use density class Medium by default
[group]
NormalCars
1
[group]
Trucks
0
[group]
Commercials
1
[group]
Ambulance
1Du meinst, wie "fein" du quasi malen kannst?
Das hängt von der Auflösung ab, die du beim erstellen des Layers eingestellt hast.
Das sind standardmäßig 64x64px, was relativ wenig ist.
Je höher du es stellst um so genauer wird es - um so schlechter wird es allerdings auch. 256 oder 512 sind aber dennoch völlig okay.
Ach und noch ne sache,bei mir dispawnen die Autos nach kurzer zeit auf meiner map wenn sie an mir vorbei gefahren sind, wieso?
Das wird daran liegen, dass Pfade nicht richtig verbunden sind.
Erstelle für das Problem aber am besten einen separaten Thread.
Ansonsten ist eine gute und einfache Practice für die Dauer auch, dass man grundsätzlich niemals eigene OMSI-Mods etc. direkt bzw. ausschließlich direkt im Hauptverzeichnis erstellt.
Ich habe separat auf einer anderen Festplatte einen OMSI-Projekte Ordner. Dort lege ich alles ab, was ich brauche, wenn ich in irgendeiner Form Content erstelle (sein es neue Objekte, Änderungen an Bussen oder was auch immer. Dort habe (und belasse) ich dann auch alle weiteren Dateien, die OMSI direkt eigentlich nicht braucht (z.B. blend- oder xcf-(GIMP)-Dateien)
Wenn ich fertig bin, ziehe ich mir die Sachen in's OMSI Hauptverzeichnis rüber und nehme nur das mit, was OMSI tatsächlich braucht (also cfgs, Texturen, o3d-Dateien usw.).
(bei komplexen Projekten mit vielen Dateien wo man häufig zum Testen Dinge "rüberziehen" muss, kann man sich auch mit wenig Programmierkenntnis eine einfache Batchdatei anlegen, die per Dopppelklick alles ins OMSI-Hauptverzeichnis synchronisiert).
Durch dieses Vorgehen habe ich den großen Vorteil, dass mein OMSI-Ordner frei von unnötigen Dateiformaten (wie Blender, GIMP oder PowerPoint (nutze ich für Texturen)) bleibt und ich gleichzeitig automatisch eine Art "Backup" ja immernoch in meinem Projektordner habe. Wenn Steam nun anfängt, mein OMSI zu überprüfen, sind die Mods in OMSI zwar weg aber ich kann das, was ich brauche recht unkompliziert einfach wieder "reinziehen" und fertig.
Zitat von logfile.txt71 13:22:30 - - Warning: Loading plugin plugins\OMSIPresentationTools.dll: procedure "AccessVariable" not found!
72 13:22:30 - - Warning: Loading plugin plugins\OMSIPresentationTools.dll: procedure "AccessTrigger" not found!
73 13:22:30 - - Warning: Loading plugin plugins\OMSIPresentationTools.dll: procedure "AccessSystemVariable" not found!
74 13:22:30 - - Warning: Loading plugin plugins\OMSIPresentationTools.dll: procedure "AccessStringVariable" not found!
Was hast du so an Plugins installiert?
Kannst du diese mal testweise deaktivieren (am einfachsten, indem du die opl-Dateien in eine andere Dateiendung umbenennst)?
Ansonsten hast du auch diverse Fehler mit anderen KI-Fahrzeugen, wie z.B. dem Mx200-C2:
Zitat von logfile.txt164 13:40:41 - - Error: vehicles\MB_C2_EN_BVG\MB_C2_E6_Gn_trail.bus: Scriptshare-Command but no equal variable count!
165 13:40:47 - - Information: Menu pos set
166 13:40:48 - - Error: Fehler: im Befehl "(M.L.IVU_Ticketbox_frame)" (vehicles\MB_C2_EN_BVG\\script\C2_LE_main.osc) ist der Macroname ungültig!
167 13:40:48 - - Error: Fehler: im Befehl "(M.L.IVU_Ticketbox_init)" (vehicles\MB_C2_EN_BVG\\script\C2_LE_main.osc) ist der Macroname ungültig!
Tatsächlicher Auslöser für deine FPS-Einbrüche ist allerdings scheinbar ein DirectX-Fehler:
Zitat von logfile.txt21810 14:57:12 - - Error: Draw Normal Mesh - Direct9 Error: D3DERR_INVALIDCALL (-2005530516)
Eine Neuinstallation von DirectX könnte das Problem lösen. Probiere es mal auch. Für mich sieht es allerdings danach aus, dass bei dir irgendein Mesh eines Standardobjekts fehlerhaft ist, was zu den Fehlern führt, sobald das Objekt in deinem Blickfeld liegt.
Du sagst, du hast das Problem auch auf Grundorf. Magst du das mal dort reproduzieren und erneut ein Logfile posten? Das würde es deutlich übersichtlicher machen.
Moin,
direkt ganz sauber aneinander legen kannst du Splines im Editor nicht.
Der einzige Weg, über den sich Splines (und Objekte) aneinander ansnappen lassen, sind tatsächlich Pfade bzw. das Meter-Raster. Dabei kann man (standardmäßig mit der Strg+Taste gedrückt) die Splines an einem größeren Raster (von 1x1 Meter) platzieren. Das funktioniert aber auch nur solange die Splines irgendwie ganzzahlige breiten haben und eine Rotation, wie exakt 0, 90, 180 oder 270 grad haben.
Ansonsten ist das tatsächlich einfach meist nach Augenmaß gearbeitet. Wenn du dir deshalb solche Maps mal ganz genau anschaust, siehst du daher auch oft, dass die Splines garnicht perfekt aneinander liegen, sondern kleine Lücken aufweisen oder sich (meist eher) minimal überlagern.
Beim legen von Kurven ist es oft ratsam, die Länge eines Kurvensegments nicht über die Length-Box festzulegen, sondern über den Angel (Winkel) zu definieren. So können alle Teilsplines (z.B. Gehweg und Fahrbahn) gemeinsam den exakt gleichen Winkel haben, sodass auch die Folgesegmente noch genau parallel liegen.
Mit dem Radius muss man dann ggf. etwas ausprobieren oder tatsächlich einfach rechnen, wenn man die Splinebreite kennt.
Genauer bzw. sauberer geht es leider nicht.
Die cleane Variante ist mMn. daher deshalb eher, halt einen Gesamtspline zu haben, bzw. bei komplexeren Verkehrsführungen (mit häufigen Einmündungen, Verkehrsinseln, was auch immer) ganze Straßenabschnitte in Blender zu modellieren und mit Pfaden auszustatten. Da kann man mMn., wenn man sich einmal in Blender reingefuchst hat, viel entspannter und vor allem sauberer bauen, da sich natürlich alles miteinander perfekt verbinden und ansnappen lässt.
Ich hoffe, das hilft dir.
Moin,
Ich gehe mal davon aus, dass das mit deinem hier beschriebenen Problem zusammenhängt.
Im dort angehangenen Logfile gibt es einige Auffälligkeiten:
96 20:57:00 - - Warning: load x File - Direct9 Error: DXFILEERR_FILENOTFOUND (-2005531815)
97 20:57:00 - - Warning: File Sceneryobjects\entrypoint_bus.sco: texture filename entrypoint.bmp not found in mesh file Sceneryobjects\model\entrypoint_bus.x!
105 20:57:01 - - Warning: load x File - Direct9 Error: DXFILEERR_FILENOTFOUND (-2005531815)
106 20:57:01 - - Warning: load x File - Direct9 Error: DXFILEERR_FILENOTFOUND (-2005531815)
107 20:57:01 - - Warning: load x File - Direct9 Error: DXFILEERR_FILENOTFOUND (-2005531815)Da sind scheinbar irgendwelche Model-Dateien vom Spandau-Content kaputt. Wenn du kein Backup davon hast, wirst du warscheinlich um eine OMSI-Reperatur/Neuinstallation via Steam nicht drum herum kommen. Was dabei zu beachten ist, kannst du auch hier nachlesen: Articles and FAQ
Beachte, dass bei einer einfachen Steam-Reperatur, Steam alle geänderten Dateien von OMSI selbst und Addons überschreibt und durch die Originale ersetzt. Hast du zum Beispiel an DLC-Dateien etwas gemoddet, solltest du deine Änderungen dort unbedingt vorher sichern.
Alles anzeigenAlles anzeigenMoin,
die Haltestellenweiterschaltung kannst du nicht direkt beeinflussen, die ist in OMSI fest programmiert, ab welcher Distanz auf die nächste Haltestelle geschaltet wird.
Was du allerdings im Drucker umsetzen kannst, ist eine Zeitverzögerung einzubauen, dass die Ansage also nicht sofort beim weiter schalten der Haltestelle abgespielt wird, sondern das Script beispielsweise noch 10 Sekunden wartet.
Das jedoch tatsächlich von der gefahrenen Distanz abhängig zu machen, ist jedoch in OMSI nicht so ohne weiteres direkt möglich, da das Scriptsystem dir nicht die Möglichkeit gibt, die Distanz zur vorherigen oder nächsten Haltestelle abzufragen.
Der Atron im Mx200-C2 schafft das zwar, allerdings wird das dort relativ kompliziert berechnet, indem die Fahrplanzeiten der letzten und nächsten Haltestelle (die man per Script abfragen kann), sowie aktuelle Uhrzeit und derzeitige Verspätung miteinander verglichen werden. Dadurch lässt sich ungefähr bestimmen, wo genau der Bus sich zwischen zwei Haltestellen gerade befindet (also wieviel "Prozent der Strecke") von A nach B abgeschlossen wurden. Wenn man das dann mit einem durchschnittlichen Haltestellenabstand multipliziert, kann man ungefähr berechnen, wieviele Meter die nächste Haltestelle entfernt ist. Damit bekomme ich aber auch nur einen ganz grob angenäherten Wert, der gerade bei sehr kleinen oder großen Haltestellenabständen auch ganz schön daneben liegen kann.
Ganz theoretisch: Wollte man es exakt machen, könnte man alle Haltestellenabstände im Druckerscript hardcoden. So würden tatsächlich alle Abstände exakt berechnet werden können, allerdings ist das natürlich 1.) ein extremer Aufwand und 2.) vermutlich auch nicht gerade performancefreundlich, wenn ein massiver Scriptblock, der eigentlich nur Daten speichert, geladen und ausgeführt werden muss.
Bedeutet das, man könnte es theoretisch so umsetzen, das man die Abstände zwischen beider HST berechnen lässt und dann sobald 1/3 des Weges erreicht ist, die Ansage abgespielt wird? So ist es bei uns der Fall.
Richtig, dass dürfte sich aus Abfahrtszeit an der letzten Haltestelle, Ankunft an der nächsten, Verspätung und aktueller Uhrzeit zumindest grob berechnen lassen, das wird aber nicht sehr präzise funktionieren.
Diese Busse schildern aber auch das richtige Ziel?
Ich habe leider beide Addons nicht, daher kann ich nichts konkretes dazu sagen, aber falls es von den Bussen spezielle KI-Varianten gibt: Hast du auch diese in der AI-List eingetragen und nicht die "normalen"?
Hier habe ich fix mal einen neuen Link hinterlegt. Hätte nicht gedacht, dass noch jemand sich für meine mittlerweile schon etwas in die Jahre gekommenen Repaints interessiert. VG
Moin, leider ist der neue Link bereits nicht mehr verfügbar, da, die Datei zumindest im kostenlosen Plan laut des Upload-Dienstes nach dem ersten Download automatisch gelöscht wird.
Vielleicht magst du es so hochladen, dass es dauerhaft verfügbar bleibt. Das geht auch direkt hier in der WebDisk.
Oh stimmt, man kann ja mit dem Kilometerzähler arbeiten... 
