Display im echten Zug

Das wäre doch mal eine schöne Aufgabe für Bastler, wie die Kollegen von Versystem, nachdem sie das Thema Ansagen erfolgreich bewältigt haben und nun nach neuen Herausforderungen suchen. Und nebenbei auch ein Geschäftsmodell.
Ein vorkonfigurierter Ebula-Monitor, den die Kreateure als konfigurierbares (sprich austauschbares) Child-Objekt bereits mitliefern oder der später (wie das Soundsystem) nachgerüstet werden kann und die entsprechenden Ebula-Pläne für die jeweiligen Strecken zum Hinzukaufen.
Das wäre mir sogar ein paar Euronen pro Plan wert, um das F4-HUD loszuwerden. Im Moment habe ich wegen der vielen Strecken und der wenigen Zeit noch nicht so viel Streckenkunde, dass ich auf die Anzeige der Streckengeschwindigkeiten und Las im HUD verzichten könnte.

Gruß
Norbert

Hatte Trainworks da nicht mal was in Entwicklung gehabt, also einen Ebula?

Gruß alias203

Die Ansagen sind aber eben komplett extern. Das einzige was im TS passiert, ist dass die Trigger beim Überfahren eine Zeichenkette in eine Datei schreiben. Diese Datei wird von dem Soundboard im Hintergrund monitored und ausgelesen. Das kann man für Ansagen sicher machen, für eine EBuLa denke ich muss man die Daten anders aus dem TS rausbekommen. Dass das geht weis ich, aber da gehören dann etwas umfangreichere Programme programmiert als das Soundboard dass letztlich nur ein Soundplayer ist der ferngesteuert wird (nein, ich möchte das Soundboard nicht abwerten, aber der Unterschied zum Aufwand eine EBuLa zu bauen ist meiner Meinung nach gewaltig). Ausserdem warum ein neues Programm schreiben. Es gibt eins. Es will nur mit den richtigen Daten gefüttert werden. Man braucht also eine Übersetzungsmaschine zwischen der eigenen Datenausleitungslösung und dem Zusi-TCP Server der dann die Daten an ZusiDisplay weiterreicht. Das ist eine reine Theorie. Wers versuchen will, nur zu.

Zitat von Christoph Otto

Die Fahrpläne mit zu schleppen wäre nicht das Problem, jeder Tf hat ja seine Ebulakarte

Könnte man sowas vlt als Extra Programm Erstellen, um es via Tablet oder ähnlich dar zu stellen? ( Habe davon wenig Ahnung )

Also EBuLa Karten haben die Tf schon lange nicht mehr, heute werden alle Daten via Echtzeit und überwiegend aktuell über den digitalen Funk abgerufen

Wenn eben keine Möglichkeit einer technischen Umsetzung möglich / in Aussicht ist, bliebe bei einer vorhandenen, vernünftigen und ersichtlichen Kilometrierung (Hektometerzeichen) ein "gedruckter" Ersatzfahrplan. Diesen muss man dann natürlich in Anlehnung an das Original erarbeiten.

Frank

Ich könnte mir tatsächlich eine App vorstellen die das "Gedruckte" ersetzt. Die App müsste dann also als externe, selbstbediente EBuLa fungieren und irgendwer muss dafür die passenden Buchfahrpläne erstellen. Das Problem bei Apps: es gibt mehrere Plattformen und kaum eine Möglichkeit effektiv für alle Plattformen gleichzeitig zu programmieren. Zumindest ist mir da nichts bekannt. Entschliesst man sich für iOS dann muss man eben in den üblichen Apfelbottich springen und schwimmen lernen in der zähflüssigen Brühe (Kosten, und Prozedere). Baut man auf Android oder Windows, oder gar beide, muss man letztlich eigentlich 2 Programme schreiben. Sicher gibt es Software die als eine Art Baukasten für alle Plattformen ein Build erstellen kann, aber das taugt eigentlich nicht so viel ausser für Spiele wie bei der Unity-Engine oder den dicken wie CryTec und Unreal. Für den PC lässt sich so eine Software recht schnell entwickeln, denn letztlich muss die nicht viel können, aber auf dem PC will ja dann keiner ein extra Fenster haben und deswegen das Spiel im Fenstermodus spielen müssen. Das ist also auch keine Lösung. Soweit zu den Überlegungen. Irgendwer braucht jetzt Zeit und Mut sich da ranzuwagen. Ich würde es machen aber ich habe keine Zeit dafür.

Was macht man dann bei Strecken die keine Hektos haben?

München-Augsburg, Hamburg-Hannover(Und eventuell noch München-Garmisch) schön einzeln Hektometertafeln setzen?

Aber Maik.
Wenn man so ein EbuLa Programm für PC schreibt (mit externem Fenster), dann kann man iDisplay verwenden, um das Handy/Tablet als Zusatz für den Monitor zu verwenden.
Dann kann man das EbuLa Fenster auf das Handy/Tablet ziehen und so verwenden.
Hab ich so mit Zusi Display gemacht und funktioniert super.

Kann ja auch ein "normaler" zweiter Monitor sein. Die Windows Plattform wäre wahrscheinlich das einfachste und für die meisten von uns kompatibelste, notfalls auch im Fenster z. B. mit dem Laptop im Urlaub.

Wie gesagt, ich hatte vor sowas zu entwickeln. Aber mit Echtzeitdaten aus der Strecke die dann aus dem TS (dem Fahrzeug) ausgeleitet werden und über einen "Server" an eine App weitergereicht werden können. Das wäre für mich der logischste Ansatz weil eben kaum Strecken richtig beschildert sind. Eine Strecke müsste dann aber mit Balisen (sichtbar oder unsichtbar) ausgestattet werden, die GPS und/oder FIS Daten senden. Also eine Art Ersatz-GPS System weil es ja keinen Positionsbestimmung (World-Coordinate) im TS gibt. Die Ausleitung der Daten und das ausrüsten einer Strecke ist prinzipiell bereits erledigt, wenn auch noch nicht getestet ob der fehlenden Programme. Es wird benötigt ein Server-Programm (natürlich ein sivolles Protokoll) und die eigentliche Anwendung die diese Daten dann empfängt, sich also wie bei Zusi mit dem Datenserver verbindet. Der Unterschied zu Zusi ist, dass der Datenfluss nur in eine Richtung geht. Also nur raus aus dem TS, aber nicht wieder rein, ergo nicht bidirektional. Damit könnte man eine sich selbst einstellende und blätternde EBuLa betreiben. Prozedere wäre dann in der Aufgabe einen Trigger mit Daten auszustatten der über das Fahrzeug die Daten an den Server sendet und damit eine angeschlossene EBuLa App mit Infos versorgt. Wenn man dann fährt senden die Balisen über die Lok an den Server eine erreichte Position die man dann auswerten darf. Der Rest passiert in der App. Alles rein Theorie bisher und keine Zeit das auszutesten weil ich auch nicht grad der Crack in Sachen Appcoding und TCP Protokolle bin. Ein Lua Modul welches die TCP Verbinung aufbauen kann, ist ungetestet vorhanden aber müsste entsprechend noch lizensiert werden (ist also mit Kosten verbunden). Apps entwickeln ist aber auch mit Kosten verbunden. Ob das alles lohnt weis ich nicht. Ich würde sagen nein. Aber toll wärs dennoch sowas zu haben. Besser wäre es wenn der TS sich weiterentwickeln würde und sowas ingame erlaubt wie das in Trainz möglich ist. In Trainz wurde das bei PTP über eine einfach HTML Tabelle gelöst die dann mit Daten gefüttert wurde. Diese HTML Objekte kann man da in Fahrzeuge einbauen und damit agieren. HTML kann der TS auch grundsätzlich aber wir haben keine Werkzeuge oder Möglichkeiten an der Hand das in Modell zu integrieren oder überhaupt sinnvoll zu steuern. Es gibt nur diese HTML Meldungsfenster und die sind auch noch alles andere als toll und natürlich nur als Overlay. Die neu integrierte Menütechnik im TS (auf Flash und AS basierend -> Autodesk Scaleform) würde sowas wunderbar bereitstellen, aber es muss auch implementiert werden. Das können nur die da drüben machen. Damit ist der Käse von Teller würd ich sagen. Also back to basics und auf Papier ausdrucken.

Zitat von LuckyCoder

So so, du willst eine Rechnung verursachen...
'Welchen Minimalpreis hätten'se denn Jerne'?

Bitte was?

Wenn ich wüsste wer du bist könnte ich den Sprech vll einordnen, aber so versteh ich nur Bahnhof. Ich wünsche keine Lizenzkosten, ich muss welche zahlen wenn ich das Modul verwenden möchte. Das ist ja grundsätzlich kein Problem, aber das sind halt nicht sie einzigen Kosten dabei. Aber egal, das wird eh alles nix. mein Optimismus lässt stark nach bei neuen Dingen.

Ja gut, jezt weis ich wer du bist Ich bin halt kein Stück weiter damit. Und so wird das auch erst mal bleiben. Vll findet sich wer anderes der Lust drauf hat das Rad neuzuerfinden.

Joa, soll es wohl dann letztlich bedeuten. Die technisch einfache Variante geht nicht wegen Speichervermüllung und die interessante Varainte nicht weil sich keiner findet der den Aufwand treibt und bezahlt. So ist das halt mit den Dingen. Ich hab heut erst wieder zugunsten des Weiterkommens 7800 Zeilen Code in den Mülleimer befördert und mich aus der Mottenkiste bedient, weils einfach nicht anders geht oder 3 Jahre dauert. Man kann halt nicht ewig an Dingen fummeln die keinen sichtbaren Fortgang produzieren. Dazu zählt auch die EBuLa.