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!

    Ach über die Sekunden läuft das? Das ergibt Sinn, danke für die Erläuterung.

    Ich habe mich das schon gefragt, weil ja sonst eigentlich im Script jede einzelne existierende Fahrt irgendwie mit der dazugehörigen Umlaufnummer hinterlegt ist, was aber offentsichtlich nicht der Fall ist. Das ist natürlich echt clever, über die Sekundenstelle der Abfahrt zu "kodieren", welcher Umlauf das ist. Ist zwar (wie fast alles an dem System) nicht so wirklich sauber, aber es geht halt nicht viel besser.

    Moin,

    das alles wird vom Ticketprinter- (also Drucker) Script übernommen.

    Das Script wurde von Darius Bode (dem Entwickler der Hamburg-Addons) eben für die Map entwickelt und veröffentlicht.

    Allerdings ist das Script sehr komplex und ich glaube, niemand außer Darius selbst ist bisher wirklich zu 100% dadurch gestiegen, wie es tatsächlich genau arbeitet.

    Zudem ist es eben speziell auf die Hamburger Busse, Linien und Fahrpläne zugeschnitten. Dementsprechend funktioniert das ganze auf Fremdkarten auch nur eingeschränkt.

    Allerdings gibt es in OMSI keine Möglichkeit, über das Script direkt die derzeit aktive Linie/Umlaufnummer herauszufinden. Der Hamburger Drucker geht hier - soweit ich es richtig durschaut habe - einen sehr aufwendigen Workaround. Es wird von der aktuellen Fahrt ermittelt, an welcher Haltestelle diese startet und was die planmäßige Abfahrtszeit ist. Aus diesen Infos kann der Drucker dann schlussfolgern, auf welchem Umlauf man sich gerade befindet. Ziemlich kompliziert, aber es funktioniert offentsichtlich. Aber hier siehst du eben auch wieder: Das Script ist speziell für die Hamburger Fahrpläne programmiert und funktioniert daher nur dort.

    Ein Umbau für eine andere Map wäre vermutlich sehr aufwendig.


    Natürlich kann man ein vergleichbares System auch für jede andere Map entwickeln. Zu deiner Frage also: Ja, natürlich wäre das auch bei anderen Karten und Bussen möglich. Ist halt nur entsprechend kompliziert und man benötigt die entsprechenden Kenntnisse im OMSI-Scriptsystem. Ein einfaches "Aus- und wieder Einbauen auf einer anderen Map" wird hier leider kaum funktionieren.


    Schau dir sonst gerne im Almex-Script in einem Hamburger Bus deiner Wahl den Abschnitt unter {macro:hamburg_umlauf} an. Das ist die Umlauferkennung.

    Vorraussetzung dafür ist aber, dass der Bus ein Textfeld für das Kennzeichen hat, was dann eben frei beschriftet werden kann.

    Ich vermute, dies ist garnicht vorhanden und das Kennzeichen steht eben, so, wie man es sieht, direkt auf der Bus-Textur drauf, somit ist alles, was in der bus-Datei definiert wird vermutlich völlig irrelevant und rein kosmetisch.

    Dass die Kacheln keine exakten 300x300 m haben, sobald man mit Weltkoordinaten arbeitet, ist in der Tat normal. Das hängt einfach damit zusammen, dass unsere Erde ja in Wirklichkeit eine Kugel ist, die hier in OMSI aber als quasi flache Map abgebildet wird. Wir kennen das Phänomen alle von Landkarten. Je näher wird an die Pole kommen, desto verzerrter und größer wirkt alles. Und genau so ist es auch in OMSI, je näher am Nord- oder Südpol du deine Weltkoordinaten ansetzt, um so mehr muss OMSI dieser Verzerrung ja irgendwie ausgleichen und die Kacheln werden größer. Ich erinnere mich, in Norddeutschland (also ca. 50. Breitengrad) immer so um die 340x340m Kachellänge gehabt zu haben.

    Warum OMSI dir das in Blender scheinbar nicht gescheit mitexportiert, kann ich nicht sagen. Ich habe das Kachelexport-Feature vom Karteneditor irgendwie nie so wirklich benutzt.

    Stattdessen habe ich immer aus Google Earth Bilder genommen und in Blender als Hintergrundbild eingefügt. Vorher auf dem Bild eine gerade Linie mit dem Lineal gezogen, als Referenz, wie groß das Bild skaliert werden muss.

    Damit bin ich eigentlich immer gut gefahren.

    Da ich dort auch besser selbst auswählen kann, welche Bereiche ich gerade als Referenz brauche, konnte ich auch entsprechend mehr reinzoomen und in Google Earth das Bild tendenziell bis zu 8k exportieren. Somit hatte ich einfach eine wesentlich höhere Auflösung und somit viel mehr Details (vorrausgesetzt natürlich, Google Earth hat in deiner Region entsprechend hochauflösende Aufnahmen mal gemacht).

    Kann ich auch bestätigen.

    Hatte auch mal einen USB-Stick, der anfing zu spinnen. Windows wollte damit auch kaum noch was mit anfangen, unter Linux konnte ich völlig ohne Probleme zumindest sämtliche Daten noch retten.


    Habe hier immer einen bootfähfigen Linux-Stick liegen.

    Sowas kann man sich auch wirklich einfach selbst "basteln". Einfach iso-Datei des Linux-Systems der Wahl runterladen und mit Rufus oder LinuxLiveCreator oder was es da noch an Tools gibt, auf einen Stick schreiben.

    Moinzusammen,

    Ich habe dem Startpost soeben im Anhang den Download der aktuellen Version hinzugefügt.

    Bitte beachtet, wie bereits erläutert, dass das Projekt natürlich noch nicht final ist. Es handelt sich um die aktuellste Beta-Version mit allen neusten Funktionen aber auch Bugs oder Problemen.

    Eine kurze Erläuterung zum Einbau ist enthalten. Allerdings nur für bereits etwas erfahrene Modder geeignet.


    Wenn ihr auf Probleme stoßt, Fehler findet oder Vorschläge habt, weiterhin immer gerne her damit!

    Genial wäre es auch, wenn man mit dem Drucker nicht nur die Standard-Tickets, sondern dynamisch alle verkaufen könnte.

    In Hamburg hat man ja viel mehr Tickets als in Spandau.

    Das ist in der Tat dynmisch. Es sind acht Buttons für Tickets vorhanden, welche aus dem TicketPack ausgelesen werden. Ich glaube, Hamburg hat zwar noch mehr als acht, aber vom Grundprinzip ist es dennoch dynamisch, kann ich sonst bei Gelegenheit auch mal demonstrieren. :)


    Verwende eine einheitliche Schrift

    Danke für den Hinweis, auch das steht bereits auf meiner Liste . Langfristig plane ich alles in Ubuntu. Hatte bloß bisher nie Lust, die Ubuntu-Font in OMSI zu implementieren. Aber die DIN ist eigentlich nur Platzhalter.


    Zu den Sonderansagen: Mach die dynamisch und Hof-gebunden.

    Das klingt tats sehr interessant. Aktuell habe ich nur vier statische Ansagen geplant: nach hinten durchgehen, Tür freimachen, Umleitung und Fahrtende, glaube ich.


    Wie siehts eigentlich bis jetzt mit der Scriptgröße aus? Wir haben ja in einem anderen Thread herausgefunden, das dies durchaus zu nervigen Abstürzen führen kann...

    Da ich das ganze versuche, möglichst sauber und modular zu scripten, hat das Teil tatsächlich bereits jetzt eine nicht gerade geringe Anzahl an Variablen und Macros. Die Anzahl der Zeilen im Script liegt auf jeden Fall bereits über tausend.

    Auch dazu morgen gerne konkretere Infos.

    Tatsächlich ist das auch mein erstes Größeres Script-Projekt, ich habe deshalb keine Erfahrung, was Performance usw. angeht. Ich kann nur melden, dass es bei mir bisher ohne Probleme läuft und ich keine Ladezeiten, Rucker oder Abstürze in diesem Zusammenhang bisher feststellen konnte.

    Hallo Leute,

    hiermit stelle ich euch (relativ spontan) mal ein Projekt von mir vor. Das Nuntius-Fahrgast-Informationsystem.

    Hierbei handelt es sich derzeit im wesentlichen um eine Software für einen neuen, fiktiven Bordcomputer. Ziel (und auch teilweise schon in Arbeit) ist, das System auf ein - wie der Name schon vermuten lässt - vollwertiges Fahrgast-Informations-System auszuweiten, mit Ansteuerung für Matrix, Innenanzeige usw.

    Hintergrund ist, dass mich genervt hat, dass es in OMSI verschiedenste Drucker, Matrizen und Innenanzeigen gibt, die allesamt sehr unterschiedlich funktionieren und es oft sehr mühevolle und nervige Arbeit ist, bswp. nach dem Einbau eines neuen Druckers alle Skripte anzupassen. Nuntius soll das etwas fixen. Nuntius soll ein Scriptsystem werden, welches zentral für die Fahrgastinformation zuständig ist und über kleine Script-Schnittstellen jede Matrix oder Innenanzeige direkt ansteuern kann.

    Zentrum des ganzen ist der bereits angesprochene Nuntius-Drucker, ein voll funktionsfähiger, fiktiver Fahrscheindrucker, an dem bereits gearbeitet wurde, und der bereits alle gängigen Funktionen unterstützt.


    "Nuntius" ist übrigens Latein und bedeutet soviel wie "Bote" oder auch "Nachricht". :)


    Ich mache einfach mal eine Liste, was schon alles geht, und was noch geplant ist:

    Bereits umgesetzte Features:

    • Login-System mit Fahrerkarte und Pin
    • Auslesen und Anzeigen von Haltestellen, Liniennummer und Ziel (sowohl ein Hofdatei- als auch Fahrplan-gestützen Modus gibt es)
    • Automatische Haltestellenweiterschaltung und Ansagen
    • Fahrscheinverkauf
    • Native Unterstützung für die K++-Matrix
    • Kompaitibilität mit den Gängigen IBIS-Triggern, damit die OMSI-Standard-Tastenkombinationen funktionieren

    Was noch geplant ist:

    • "richtiges" Schnittstellensystem für andere Fahrzeugkomponenten (Matrix, Innenanzeige, Wechselgeldtisch (bswp. zum sperren, wenn der Fahrer nicht angemeldet ist)
    • Sonderansagen
    • Druckereinstellungen (darunter Dark Mode) (derzeit lassen sich nur einige wenige Optionen über die Constfile beeinflussen)
    • Automatisches Schildern von "Fahrtende" am Ende einer Route
    • uvm.

    Im folgenden sehr ihr ein paar Bilder des Druckers.

    Bitte beachtet: sämtliche Meshes (der Drucker an sich, die sichtbare Fahrerkarte usw.) sind nur Prototypen, also nicht ansatzweise final. Ich konzentriere mich derzeit mehr auf die Funktionalität und weniger auf den Look. Wenn man Lust hat, einen Drucker in Blender oder dergl. zu modellieren, darf man sich gerne bei mir melden!



    Warum dieser Thread jetzt?

    Ich arbeite an dem Projekt jetzt schon seit fast einem Jahr. Nicht besonders regelmäßig oder ehrgeizig, mehr nur, wenn mir gerade danach ist. Doch der Drucker ist nun in einem Zustand, wo man ihn durchaus schon beim normalen Spielen benutzen kann, daher dachte ich, kann ich das Projekt schonmal öffentlich machen. Natürlich seid ihr herzlich dazu eingeladen, Feedback zu geben, Wünsche zu äußern, Vorschläge zu machen oder Fragen zu stellen.


    Ich plane außerdem in den nächsten Tagen das Projekt im jetztigen Zustand für alle Interessierten bereits als Public Beta/Testversion zu veröffentlichen. Sagt gerne, wie ihr auch dazu steht.


    Derzeit habe ich den Drucker in den MAN NL Enhanced von Sobol eingebaut und er funktioniert dort mit der K++-Matrix und der dort eigens von mir erstellten Innenanzeige bereits einwandfrei. Aber wie ich oben schrieb: Eine abstraktere, allgemeine Schnittstelle ist bereits geplant.




    Im Anhang findet ihr die aktuelle Version zum Download als zip-Datei. Bitte readme.txt beachten!

    Nein, das ist leider nicht möglich.

    OMSI macht keinen Unterschied zwischen Steh- und Sitzplätzen, die Passagiere wählen immer einen zufälligen Platz aus. daher stehen sie auch, wenn der Bus unter Umständen noch komplett leer ist.

    Klar, das geht. Grundsätzlich kannst du über das Fahrzeugmenü jeden Bus auf jeder Map frei platzieren.


    Es ist allerdings so, dass bestimmte Busse natürlich auf bestimmte Maps ausgelegt, bzw. "gemacht" sind. Sämtliche Busse aus den Hamburg-Addons z.B. Diese sind explizit nach Hamburger Vorbild und z.B. das ganze Drucker-IBIS-System speziell auf die Map Hamburg abgestimmt und funktioniert woanders nur eingeschränkt.

    Grundsätzlich kannst du die Busse dennoch überall fahren.


    Edit: Es ist nur wichtig, dass du beim platzieren des Busses im Menü immer unter "Betriebshof" die aktuelle Karte einstellst, sonst hast du nicht die richtigen Routen und Zielbeschilderungen.


    Wenn die Karte dort nicht angezeigt wird, musst du die entsprechende Hof-Datei im Ordner OMSI 2\Vehicles in den Ordner "deines" Busses kopieren.

    Wird es in der neuen Version bei den Linien (in Grundorf und Einsteindorf etc.) auch Linienwechsel, Lenkzeitpausen o.ä geben?

    Sicherlich :)


    Da noch nicht alle Linienverläufe final stehen, kann man natürlich zum Fahrplankonzept bisher auch eingeschränkt nur etwas sagen, aber ja, wir sind aktuell dabei, Fahrpläne zu entwickeln. Abwechslungsreiche Dienste mit Kurzläufern, Einsatz- und Shuttlebussen usw. sind auf jeden Fall geplant, und natürlich auch nach den Vorschriften gesetzlich erlaubte Dienste (im Bezug auf Fahrtzeit, Pausen, usw.)

    Die Autokraft ist tatsächlich für die V2 bereits fest eingeplant, dann kann man überlegen, ob man das alles etwas realitätsnäher gestaltet. :)

    Moin!

    Ich hatte das auch überlegt.

    Andererseits soll die Karte ja auch fiktiv sein. Vorbild war natürlich Schleswig-Holstein, allerdings gibt es trotzdem keinen konkreten Ort, an dem die Karte spielen soll, daher hatte ich mich damals dazu entschieden, jegliche direkte Parallelen zur Realität rauszulassen, das Unternehmen VLKS existiert ja auch nicht in Wirklichkeit, dann fand ich es etwas komisch, dann ein reales Logo des Verkehrsverbundes da drauf zu klatschen.

    Joa, das würde ich schon mal behaupten ^^


    Zum Vergleich: dieses Haus habe ich schon recht detailliert gestaltet (ausmodellierte Regenrinne usw.) und es kommt mit gut 2.200 Faces aus. :"D



    ... und das ist für OMSI-Verhältnisse eigentlich auch echt schon sehr viel.

    Es scheint da Probleme mit den Sounds der KI-Fahrzeuge zu geben. Hast du mal das Bad-Hügelsdorf-Addon neu installiert?