IVU.ticket.box CE70 mobil - Version 1.0_Pre verfügbar!

" Abgeschlossen", aber die Reise geht weiter...

 IVU.ticket.box CE70 mobil

Herzlich Willkommen im Entwicklungsthread der IVU.ticket.box CE70 mobil.

Die Software beinhaltet dabei den - zu diesem Zeitpunkt bekannten - neusten Status.

Diese IVU läuft auf eigenständigen Scripten und stößt mit keinen anderen Objekten des Busses zusammen. Der Einbau erfolgt somit kinderleicht... normalerweise!

Im Nachfolgenden könnt ihr ein paar Informationen zu den zukünftig geplanten bzw. bereits eingebauten Funktionen lesen. Darunter findet ihr auch Bilder.

Aber auch ihr als Community könnt bei gewissen Dingen mitwirken.

Ebenso werde ich mich bei den Funktionen daran richten, ob diese in OMSI einen gewissen "Wichtigkeitspegel" erreichen. Als Beispiel könnte ich die Funktion des Verkaufsjournals nennen. Ist zwar eine schöne Sache am Ende einer Fahrt zu sehen (oder zwischendrin), welche Tickets man wann und für wie viel Geld verkauft hat, jedoch sehe ich da keinen Mehrwert für OMSI. Aus diesem Grund werden solche Funktionen nicht mit umgesetzt! Näheres dazu findet ihr unten unter  Funktionen.

Und nun viel Spaß beim durchstöbern!

 Alle hier gezeigten Inhalte sind nicht final, können demzufolge Fehler beinhalten und teilweise einen älteren Stand aufweisen!

 Beta-Programm

-

 Download

Offizielle Vollversionen: IVU.ticket.box CE70 mobil - OMSI - WebDisk & Community

Zum Supportthread: https://reboot.omsi-webdisk.de/community/thread/6587

 Experimenteller Selbsteinbau

Die nachfolgende Datei beinhaltet die jeweils aktuellste Version der IVU.ticket.box CE70 mobil.

Zu dieser Datei gibt und wird es auch keine Einbauanleitung geben! Daher auch "experimentell" (seht es als Beta-Test an) und "Selbsteinbau". Ihr könnt höchstens die Kurzbeschreibung bei der oben verlinkten Datei nutzen.

Ich möchte zwar nicht jede einzelne Änderung als extra Datei mit hochladen, jedoch will ich euch das auch nicht vorenthalten, gerade für einige Modder, die das Ding selber einbauen möchten und meine Erlaubnis dafür haben!

Die Datei liegt auf einem externen Server (Mediafire) und wird stets geupdatet; der Link bleibt also immer der gleiche. In der Datei selbst befindet sich eine Textdatei, welche den Stand (Datum des Uploads) widergibt. Ansonsten findet ihr im Handbuch in der Änderungsliste auch nochmal die Änderungen im Überblick.

Alle weitere, vordefinierte Dateien werden auch die jeweils aktuellste Version der IVU enthalten. Bei "Weitere Versionshinweise" beim offiziellen Download, wird das Prinzip auch nochmal erläutert.

https://www.mediafire.com/file…CE70_mobil_OMSI2.zip/file

 Mitwirkende

     Kxlle

     Lion's Coach - Fan

     Luca´s Texturewerkstatt

+ 1 weitere (noch) ausstehende/nicht genannte Person(en)

 Tester,  Informationen,  Bild-/Videomaterial,  Sound

 Funktionen

 realgetreues Booten

 Anmelden ITCS mittels Umlaufnummer, oder Linien- und Fahrtnummer

 Abmelden ITCS

 beliebig viele Umlaufnummern selber mit Routen/Fahrten definieren

 manuelles Ändern des Ziels

 Anmelden Ticketing mittels Fahrernummer und PIN

 Abmelden Ticketing mittels PIN

 Durchsagen / Sonderansagen

 Wechselgeldrechner

 Gutschrift statt Wechselgeld

 automatische Haltestellenweiterschaltung

 manuelle Korrektur der Haltestellenposition

 Ticketverkauf (derzeit max. 60 verschiedene Fahrscheine)

 Zwischenbeleg/-summen

 Ticket stornieren (evtl. in abgewandelter Version)

 Overscreen-Meldungen, wie z.B. "Bitte abfahren", "Verspätung", "Verfrühung", ...

 Verkaufsjournal

 Servicemenü (zu viele "Useless-Funktionen" in OMSI)

 Möglichkeit des (De)aktivierens der Fahrgastinformation (Innenanzeige + Ansagen)

 verzögerte Ansage und Entwerter-Weiterschaltung

 automatischer Wechsel ITCS > Ticketing bei offenen Türen

 automatischer Wechsel Ticketing > ITCS beim losfahren

 Symbole in der Kopfzeile funktional machen

 Fehlermeldungen in der Kopfzeile

 Papierrollenwechsel

 Kalenderwoche in Kopfzeile funktional machen (z.Zt. "00")

 eTicket-Funktion

 Pausenmodus

Stand: 07.04.2022 · 19:44

Legende:

 vollständig eingebaut

 in Entwicklung / geplant

 wird nicht umgesetzt

 Bilder

Auswahl der Fahrt nach Eingabe einer Umlaufnummer:

Grundbildschirm ITCS:

Grundbildschirm Ticketing:

Funktionen im Ticketing:

Durchsagen:

Grundbild Menü:

verschiedene Hinweistexte in der Kopfzeile (können per Klick quittiert werden):

Verschiedenste Icons in der Kopfzeile, welche den Status des Rechners vermitteln:

Gerät:

Alle Tasten, welche grau sind, haben in OMSI (noch) keine Funktion.

- IRE612 -

Omsi2022 - Wie Hamburg-Harburg bereits im Bearbeitungsgrund schreibt, sind Release-Anfragen nicht gern gesehen. Da ich im Startthread aber auch nicht wirklich etwas über die Bauzeit geschrieben habe, konnte man sich auch schlecht eine Meinung bilden. Normalerweise hatte ich vor das Ding in meinem derzeit insgesamt 3-wöchigen Urlaub fertig zu stellen. Ob dies dann auch tatsächlich der Fall ist, ist fraglich.

Ansonsten einfach die oben genannte Liste bei  Funktionen beachten. Sobald da alles voller grüner Haken () - neben den roten Kreuzen () - ist, kann theoretisch die Überprüfungsphase starten.

TheRichienator

Gut, dass du das Thema ansprichst! Ich hatte da an folgendes gedacht:

Eine Art "Anschluss"-Scriptabschnitt!

Die Inhalte der Strings werden auf interne IVU-Stringvariablen geschrieben. In dem oben zu sehenden Abschnitt müssen dann die Platzhalter-Strings (IVU_freier_Port_xx) durch eure benötigten Strings ersetzt werden. Somit fungiert das Ganze als eine Art Brücke.

Bei jeder Zeile steht auch geschrieben, welcher String welchen Inhalt besitzt.

Mir fielen spontan jetzt erstmal keine weiteren Innenanzeigen ein, welche eine besondere Formatierung oder Darstellung benötigen. Ansonsten bitte ich einmal um Rückmeldung wenn noch was fehlen sollte.

- IRE612 -

Zitat von DerGrafikfehler

Anzahl der möglichen Zeichen für die Strings im Script begrenzen würdest

Das wäre eher semioptimal, da es eine proportionale Schrift ist. Also jedes Zeichen hat eine eigene Breite. So nimmt bspw. "mmmmm" mehr Platz ein, als "iiiii". Dass die Inhalte daher nicht ganz in die Textfelder passen, läuft im Endeffekt auch auf die Software hinaus. Ist in echt auch so... ist das Ziel zu lang, ist es eben nicht ganz sichtbar. Ich werde den Inhalt des Textfeldes für die Linie noch einmal stauchen, sodass problemlos eine 4-stellige Linie hineinpasst. Das Ziel muss sowieso ein Stückchen kleiner geschrieben werden.

Zitat von DerGrafikfehler

Wie viele Texttexturen nutzt der Drucker eigentlich?

Bislang 55. Man könne bei einigen Modi die Textfelder auch zusammenfassen und mit "@" arbeiten... muss ich mal schauen. Wobei es glaube keinen Unterschied macht, ob man dann z.B. 50 oder 55 TextTexturen hat. Der Beginn liegt bei 38.

Ich habe zumindest den Vorteil, dass ich OMSI selber nur auf einem "billig" Laptop spiele und somit bereits weit im Voraus merke, wenn die Performance am abkratzen ist.

Zitat von DerGrafikfehler

Für die ganzen TFTs braucht man eigentlich immer nochmal ein bisschen extra-Ansteuerung, weil sie mindestens eine Ansteuerung für die Tauschtexturen brauchen.

Das stimmt... Es gibt leider unzählig viele Innenanzeigen für OMSI. Da kann ich leider nicht auf jede Rücksicht nehmen... wäre auch in echt so. Da muss man eben dann selber noch etwas im Script mit eintragen, bzw. kann ich das ja noch mit einbinden. Wobei die Innenanzeigen sowieso erstmal Nebensache sind. Man sitzt doch eh vorm auf'm Fahrersitz und schaut nicht jede Sekunde auf die Innenanzeige

Zitat von DerGrafikfehler

Komplexere Innenanzeigen wie z.B. die aus dem NLC oder die von Chrizzly nutzen sowieso eigene Scripts, die sich nur die aktuelle Linie, Route (und vielleicht Ziel) aus den regulären IBIS-Variablen holen

[...]

Um diese Scripts anzusteuern, brauchst du wieder eigene Scripts, die die Druckervariablen auf die Innenanzeigen-Variablen umsetzen.

[...]

und dieses Makro dann in eine eigene .osc packst

Alles anzeigen

Letzten Endes werden die regulären IBIS-Variablen auch mit Informationen versorgt, da sonst jegliche Matrizen nichts anzeigen würden. Damit wäre also dieses Problem auch schon gelöst.

Da braucht es auch kein extra Script. So wie ich es für die Stringvariablen gemacht habe, kann man es auch für die normalen Variablen machen. Und sollten mehrere Fahrzeuge auf dieses eine Script zugreifen, kann man problemlos auch mehrere (String)variablen hinten dran schreiben.

Hatte ich anfangs auch geplant, nur dann müsste man wieder bei Bedarf eine Script-Datei mehr in die bus-Datei schreiben und darauf achten, dass die unter der IVU_Ticketbox.osc steht (sonst wird glaube das Makro nicht gefunden, oder?). Und ich weiß wie anstrengend ReadMe lesen für manche ist... da wird sich ganz schnell gewundert, warum, wieso, weshalb das nicht geht.

Aber danke für's Feedback!

 Late News

Die Umlaufnummern können nun direkt in der Hof-Datei eingetragen werden!

a) max. siebenstellige Umlaufnummer

b) Seitenzahl (pro Seite können maximal vier Fahrten definiert werden)

c) Abfahrtszeit (Format: HHMM) - "8888" für keine Abfahrtszeit!

d) Linie

e) Prä-/Suffix, Zusatz (z.B. für Schulbuszeichen)

f) Routennummer

Vielen Dank an der_Nik_ für die Idee und Hilfe!

Des Weiteren wurde die eTicket-Funktion mit eingebaut:

Leider wurde mir erst im Nachhinein klar, dass es für das entwerten keine Variable zum auslesen gibt... lediglich ein interner Soundtrigger (ev_stamper) existiert. Nur der bringt mir nicht viel.

Geplant war eigentlich, dass die entwertenden Fahrgäste ein eTicket oben auf den Scanner legen und das oben zu sehende Display aktiviert wird.

Wenn doch noch jemand eine Lösung findet, lasst sie mich bitte hören!

- IRE612 -

DerGrafikfehler - Dieses PVS-Gerät im eCitaro kontrolliert jedoch nur über GetHumanCountOnPath (?)… fungiert also eher als Lichtschranke. Das wäre bei dem eTicket nicht gerade die beste Lösung…

Morpheus - Hmm... schade. Ich hatte ja wenigstens noch gedacht, dass man den Soundtrigger als Bedingung bzw. als Auslöser setzen kann. So nach dem Motto:

(T.L.ev_stamper)
{if}
    ...
{endif}

Die Sache mit den Scripttexturen lass' ich erstmal sein, da ich null Ahnung davon habe und zweitens das ganze Script wieder umstellen müsste. Anstelle von Textfeld nicht sichtbar müsste dann der Inhalt des Strings geleert werden. Letzten Endes ist es keine große Sache mal paar Zeilen via Copy&Paste einzufügen. Wer sich dafür immer noch zu fein ist, Pech gehabt.

- IRE612 -

FD-UB 501 - Freut mich, dass dir da Projekt gefällt!

Die eTicket-Funktion habe ich nun wie folgt umgesetzt:

Ich habe einen zusätzlichen Pfad und -punkt eingefügt, welcher nur von den entwertenden Fahrgästen genutzt wird. Somit kann ich dann via GetHumanCountOnPathLink abrufen, ob da eine Person durchläuft. Das Ganze funktioniert auch problemlos! Habe es auf ein paar Maps ausprobiert.

Da jedoch dazu die passengercabin- und path-Datei abgeändert werden muss, werde ich das ganze als Toogle festlegen; man muss also in der constfile einfach den "Schalter umlegen", dass eben nicht am Entwerter abgestempelt werden soll, sondern am eTicket-Icon.

Das Ganze ist aber super einfach umzusetzen.

Zitat von FD-UB 501

alle Fahrten dieses Umlaufs/Fahrplans einzusehen

Das ist OMSI-bedingt nicht möglich. Du kannst nur die Route deines aktiven Fahrplans, und die Abfahrtszeit des nächsten Umlaufs einsehen.

Die Umlaufnummer kann frei gewählt werden (deine 10201 wäre also vollkommen in Ordnung), es werden dann definierte Routen aus der Hof-Datei angezeigt, mit Start- und Zielhaltestelle.

Die Uhrzeit hat keine Funktion. Die kann frei gewählt werden, wenn du z.B. eine Route hast, die nur um diese eine Uhrzeit benutzt wird... Ansonsten ist das nur wegen der Realität mit eingebaut. Du kannst die aber (wie oben beschrieben) mit der Eingabe "8888" auch ausblenden.

Zitat von FD-UB 501

Ich weiß, dass man sich auch via Linien und Fahrtnummer anmelden kann, hierzu muss man in Realität zuerst im Umlauf 0 eingeben, und bekommt dann das Linienfenster zur Auswahl. Nach eingeben der Linie kommt dann das Fahrtnummernfenster. Wie läuft das ganze dann in OMSI mit der Fahrtnummer ab? Soll die Fahrtnummer dann einfach = Route sein?

So sieht's aus! Die Fahrtnummer ist einfach die Route, damit das OMSI-übliche Hof-Datei-System erhalten bleibt und weiterhin problemlos genutzt werden kann.

Bei einigen Software-Versionen muss bei Umlauf nur eine Null eingetragen werden, bei dieser / meiner Version müssen es fünf in der Zahl sein.

Zitat von FD-UB 501

Werden die Ansagen dann nach bestimmten Sekunden kommen, oder wie ist das geregelt?

Bei uns ist es so, dass die Ansagen nach 1/3 des Fahrtweges beginnen abzuspielen.

Normalerweise werden die Ansagen erst etwa frühestens 400m vor der nächsten Haltestelle angesagt. In OMSI kann man jedoch nur ermitteln, wann ein Bus eine Haltestelle verlässt. Somit bleibt nur dies als Möglichkeit über. Man kann zwar den Abstand zwischen den einzelnen Stationen in der Hof-Datei angeben... evtl. wäre das 'ne Idee für eine spätere Version, vorerst belass' ich es aber beim verzögerten Ansagen beim verlassen einer Station.

- IRE612 -