Beiträge von ma7t3

Willkommen in der OMSI-WebDisk!
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: = Englisch [EN], = Deutsch [DE], = Französisch [FR]. Wenn du die angegebene Sprache nicht beherrschst, schreibe auf Englisch!

    Ich will mich hier jetzt auch mal zu Wort melden und ebenso grundsätzlich mein Lob aussprechen. Das Update gefällt mir soweit sehr gut.

    Insbesondere die neuen Sounds empfinde ich verglichen mit den NLCs, die hier so in der Realität rumfahren, als deutlich realistischer und authentischer.

    Ein Kritikpunkt wurde schon angesprochen: Der Kinderwagenschalter: Cooles Feature, allerdings wird er auch für meinen Geschmack viel zu häufig ausgelöst, vielleicht kann man das etwas reduzieren.

    Außerdem kommt mir das Display im Dashboard (wo die Geschwindigkeit und die geöffneten Türen während der Fahrt angezeigt werden) spontan recht dunkel vor. Ist das ein Fehler oder soll das so tatsächlich realistisch sein?

    Versuche, den Frame-Teil beim NLC z.B. in das Macro "cockpit_frame" einzufügen (Bei mir Zeile 1792 in der cockpit.osc).

    Einfach am Anfang (oder Ende) des Makros mit hinzufügen, in etwa so:

    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:

    Folgende Variable (kannst sie letztendlich auch anders nennen) muss in die Varlist eingetragen werden:

    Code: varlist.txt
    dein_trigger_cooldownTimer

    Die gewünschte Cooldown-Zeit legst du am elegantesten in einer Constfile fest:

    Code: constfile.txt
    Hier die gewünschte Cooldown-Zeit (in Sekunden) für deinen Trigger eintragen (hier z.B. eine Sekunde)
    [const]
    dein_trigger_cooldownTime
    1

    Ich 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. :)



    Die Theorie

    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.

    1. Mit den Makros (M.V.GetTTBusstopDep) und (M.V.GetTTBusstopArr) lassen sich die planmäßige Abfahrtszeit der letzten Haltestelle bzw. Ankunft an der nächsten abfragen.
    2. Über (M.V.GetTTDelay) lassen sich aus den planmäßigen Zeiten die tatsächlichen (bzw. prognostizierten für die nächste Haltestelle) errechnen.
    3. Vergleicht man diese nun mit der aktuellen Ingame-Uhrzeit ((L.S.Time)), kann man daraus einen relativen Wert bestimmen, wieviel Zeit bereits seit der letzten Haltestelle vergangen ist, bzw. wo auf der "Zeitachse" wir uns gerade zwischen Zeit Haltestellen befinden. Dazu ein Beispiel:

    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.

    1. Beim Verlassen einer Haltestelle merken wir uns den aktuellen Kilometerstand in einer Variable.
    2. Nun können wir jederzeit den aktuellen Kilometerstand mit dem gespeicherten vergleichen und so die zurückgelegte Strecke seit der letzten Haltestelle ermitteln.
    3. Aus all diesen Daten lässt sich nun bereits eine Prognose erstellen. Wir haben nun unsere zurückgelegte Strecke auf z.B. 100m bestimmt.
    4. Wenn wir weiterhin von einer konstanten Fahrtgeschwindigkeit ausgehen, so ergibt sich:
    Code
    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.



    ...und in OMSI

    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:

    Code: varlist.txt
    busstopDistance_timer
    busstopDistance_lastKmCounter_km
    busstopDistance_lastKmCounter_m
    busstopDistance_nextBusstopDistance
    busstopDistance_lastIndex

    Dies 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.

    Das war's soweit. Viel Freude damit.

    Wenn ihr weitere Fragen oder Anmerkungen habt, könnt ihr sie im Folgenden gerne posten. :thumbup:

    Wenn dein oben gepostetes Logfile vollständig ist (wovon ich mal ausgehe), dann stürzt OMSI bei dieser Aktion ab:

    Code
    293 14:11:35 -  -       Information: Try placing random bus: 

    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:

    • Hast du mal versucht, OMSI als Administrator zu starten?
    • Wenn nichts weiterhilft, kannst du auch versuchen, OMSI mit erweitertem Logging zu starten. (Verwende dazu den Startparameter -logall). Das erzeugt mehr Details im Logfile und gibt dann vielleicht mehr Informationen dazu, wo es hakt.

    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:

    Du 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.txt

    71 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.txt

    164 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.txt

    21810 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:

    Code
    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.

    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. :)