[Tutorial] Aufbau einer Hofdatei und erstellen einer Universelle Hofdatei

Das Forum befindet sich im reduzierten Betrieb. Die Addon- und Supportforen bleiben weiterhin verfügbar.
Bitte beachte, dass OMSI nicht mehr weiterentwickelt wird. Ein Teil der Entwickler widmet sich inzwischen der Entwicklung eines neuen Simulators. Weitere Informationen zum LOTUS-Simulator findest Du hier.
  • Guten Abend,


    Ich habe das Thema Hofdatei aufgegriffen und bei Omsi-wiki, einen Beitrag veröffentlicht. Dabei geht es, im ersten Kapitel, um folgende Punkte:


    - Wie eine Hofdatei aufgebaut ist,
    - Was alles in einer Hofdatei drin steht,
    - Was man beachten muß, beim erstellen einer Hofdatei


    Im zweiten Kapitel geht es um eine "universelle Hofdatei" und richtet sich an alle Bus-Erbauer, Map-Ersteller und besonders Add-On-Hersteller.
    Da geht es um folgende Punkte:


    - Was eine universelle Hofdatei ist,
    - Welchen Sinn eine universelle Hofdatei hat,
    - Vor- und Nachteile,
    - Welche Strings bereits vergeben sind,
    - Wie man in den entsprechenden Scripten, bestimmte Strings auslesen läßt,
    - Wie man auf Ersatzstrings ausweichen kann,


    Ich biete dazu gern meine Hilfe an und unterstütze alle, die künftig eine Universelle Hofdatei umsetzen möchten.


    Beitrag wurde von Rumpelhans komplett überarbeitet. Womit der gesamte Eintrag nun wedentlich Übersichtlicher und einfacher struktuiert ist.


    Omsi-Wiki Eintrag zum Thema Hofdatei

  • EN:


    That would be difficult, as there are hundreds, if not tens of maps in the OMSI community as a whole. That also includes the routes, and they would conflict with others. however, if you do choose to do this, I salute you. Good luck

    :thumbup:


    DE:


    Das wäre schwierig, da gibt es Hunderte, wenn nicht Zehn Karten in der OMSI Gemeinschaft als Ganzes. Das schließt auch die Routen und sie mit anderen zu kollidieren würde. Allerdings, wenn Sie sich entscheiden, dies zu tun, ich grüße Sie. Viel Erfolg

    :thumbup:
  • You misunderstood his suggestion. He doesn't want to make a huge Hof file for all maps, but he proposes a uniform structure for Hof files which should be usable for all buses, no matter what destination displays they use. In order to achieve that, he suggests to extend the Hof file format with additional strings.
    Each bus creator and modder would have to follow the rules which is hard enough. There are plenty of possible extensions of the format depending on the configuration of a bus. The idea is good, but I'm quite a sceptic about it.

  • Ich finde grundlegend die Idee mit der universellen HOF-Datei sehr interessant, da muss man auch erst drauf kommen

    :)


    Ich wollte mal aus meiner Sicht schreiben, wo es gut, und wo es noch nicht gut funktioniert (Vielleicht kannst du das noch in den Artikel reinschreiben), oder vielleicht schon umgesetzt ist:


    Rollband-/Annax: Das "Ur"-System.
    KRUEGER: Die greift das ANNAX-System wieder auf (Es funktioniert sogar mit dem "alten" Format, mit HOF-Creator), wobei es auch ein neueres Format mit Tabs gibt.
    Busfanat-VM: Greift auf das ANNAX-System zurück, nur mit erweiterten Möglichkeiten (z.B. *I/*B), um ohne KRUEGER-Script eine Benutzung als Vollmatrix zu ermöglichen (ein, zweizeilig, groß, klein,...)
    BUSE: Umsetzung ist schwierig, HOF-Dateien fallen aus dem Rahmen. (Klappt nicht gut)
    MOBITEC: Ist mE gut gelöst, da man die Strings aus einer ANNAX-Datei aufgreift, nur ohne Eingabe von konkreten Namen, sondern mit Angabe eines Bitmaps.


    Am besten ist die Idee einer universellen HOF-Datei in der Krüger+(+) umgesetzt, da die spezifischen Ziele mit 20.000 addiert werden, was eine Eingabe über das IBIS unmöglich macht. Bei richtiger Angabe können auf die Krüger+(+) angepasste HOF-Dateien noch mit ANNAX, KRUEGER und Busfanat kombiniert werden. Funktionieren tut dies trotzdem, da die Krüger+(+)-Matrix im Bus immer wenn vorhanden ein Ziel addiert mit 20.000 nimmt. Ist keins mit 20.000 da, nimmt es das "normale". Somit sind
    a) Krueger+(+) - Busse mit ANNAX, KRUEGER und BUSFANAT - Hof-Dateien kompatibel und
    b) Krueger+(+) - Hof-Dateien mit ANNAX, KRUEGER und BUSFANAT-Bussen kompatibel.


    Edit:
    Tatra:
    Wenn du noch Hilfe bei der Formatierung im Wiki brauchst (z.B. Tabelle, ...), kannst du das einfach in die Diskussionsseite von deinem Wiki-Artikel reinschreiben

    :)
  • Guten Abend,


    Auch wenn es manchem als Erbsenzählerei vorkommen wird, möchte ich mich zu deinem Satz äußern, Rumpelhans:

    Am besten ist die Idee einer universellen HOF-Datei in der Krüger+(+) umgesetzt, da die spezifischen Ziele mit 20.000 addiert werden, was eine Eingabe über das IBIS unmöglich macht.


    Nur weil es über das IBIS unwahrscheinlich ist, diesen Zielcode einzutippen (man kann natürlich das IBIS-Script ändern und die Anzahl der Zielcode-Ziffern erhöhen), ist das nicht ideal. Insbesondere Einsteiger könnten bei ihren ersten Gehversuchen in OMSI im ALT-Menü bei der Zieleinstellung den 20 000er-Code erwischen.


    Ganz klar festzuhalten bleibt, dass die Anforderungen an Hofdateien im Laufe der Zeit gestiegen sind. Am Anfang gab es schließlich nur Rollband oder ANNAX. Beide waren in der gleichen Hof-Datei möglich und es gab nur Routen und Ziele.
    Heute werden in der Hof-Datei zum Beispiel Wechselziele gespeichert. Manche haben in Eigenregie Zielwechsel während der Fahrt in die Hofdatei gespeichert oder Anschlussrouten definiert, die nach Fahrtende automatisch vom IBIS eingestellt werden.


    Wer weiß, welche Informationen in Zukunft in der Hofdatei gespeichert und vom Bordcomputer-Script verwertet werden?


    Ich halte ein einheitliches Hofdateienformat grundsätzlich für eine gute Idee. Trotzdem bin ich gespannt, ob sich diese Idee durchsetzt. Schließlich müssen die Busbauer bzw. deren Scripter das erst als "Standard" anerkennen und dann danach handeln. Weil sonst ist die Geschichte für die Fische.


    Übrigens eine kleine Randnotiz: Zu OMSI1-Zeiten war es sehr wohl möglich, eine einheitliche Hofdatei für meine Vollmatrix und die ANNAX zu erstellen. Hat aber fast niemand wahrgenommen. Leider dies seit OMSI2 und den $cutSpaces bzw. $SetLengthC-Befehlen in den ANNAX-Scripten nicht mehr ohne Scriptänderungen möglich.


    Ich wünsche euch noch einen schönen Abend,


    Busfanat

  • Hallo Rumpelhans 104,


    Deine Hilfe werde ich sehr gern in Anspruch nehmen. Hat Vorteile, wenn man einen Profi fragt, als sich alles selber raussuchen zu müßen.


    Deine "Sicht der Dinge" kann ich aber nicht ganz nachvollziehen, weil ich nicht genau weiß, was du meinst. Das liegt daran, das ich in Scahen Scripte eine absolute Null bin. Wenn ich deinen Beitrag lese, scheint es mir, als würdest du bei der Fortgeschrittenenstufe beginnen ... da haste die Anfänger wie mich vergessen.


    Rollband- /ANNAX: Was meinst du da mit Ursystem ? Meinst du die ursprüngliche Hofdatei von M+R Software aus Spandau in Omsi 1 ?
    Da hat man ja nur die Felder für IBIS1 + IBIS 2, Rollbandtextur, ANNAX-Anzeige vorn und Seite.


    Bei den ganzen Anzeigesystemen, schreibst du die Nachteile (aus meiner Sicht) warum diese nicht die originale ANNAX-Einträge auslesen / auslesen können. Dieses Problem würde ja mit der universellen Hofdatei entfallen. Meine Hofdateien für Spandau habe 20 Strings. Und die Busse habe ich auch umgestellt. Somit kann ich den LU-200 aus Wien ganz bequem in Spandau benutzen und es funktioniert hervorragend. Auch der Bus MB O 405 N² von Julian funktioniert problemlos, mit der Busfanat-Vollmatrix. Weil ebend alle Busse (mit einem anderen Anzeigesystem) andere Strings benutzen. Sogar Busse mit einer BUSE-Vollmatrix funktionieren sehr gut, auch wenn ich nur die Ziele aus Omsi 1 drin habe, weil ich den BUSE-Creator nichtmehr gefunden habe. Den brauche ich aber auch nicht, weil das System vermutlich eh bald vergessen ist.


    Ich möchte mal versuchen zu erklären, wie ich dein Beitrag verstanden habe:


    - Wir gehen mal davon aus, daß Perotinus sein MB O 307 Bahnbus, nicht umgestellt wurde, auf andere Strings - Ziel: Zoologischer Garten / Linie 100 -


    Der Vergleich an der Stelle zum MAN ÜL von Perotinus ist dazu recht passend.


    Eine Hofdatei für eine ANNAX-Anzeige hat im MB O 307 kein schönes Bild. Vorn am Bus steht "Zoologischer" genauso wie an der Seite. Hinten steht aber nur "Zool". Ist recht unpassend. Hier müßte die Hofdatei wieder angepasst werden, was dann aber im SD 200 oder SD 202 unpassend wirkt. Und so hat jedes System seine Probleme, die dargestellten Informationen auszulesen - wobei die Busfanat-Vollmatrix noch am besten damit auskommt und die BUSE-Vollmatrix da komplett versagt. Die BUSE-Anzeige ist nicht schwierig, sondern ohne Hilfsprogramm nicht möglich.


    Die Nachteile stehen aber schon alle im Beitrag von Busfanat auf Omsi-Wiki - Fartzielanzeige an Bussen. Das braucht ja nicht nochmal bei der Hofdatei stehen. Zumindest denke ich so darüber.


    Jetzt nochmal konkret, wieso ich deinen Beitrag nicht verstehe:


    Bei richtiger Angabe können auf die Krüger+(+) angepasste HOF-Dateien noch mit ANNAX, KRUEGER und Busfanat kombiniert werden. Funktionieren tut dies trotzdem, da die Krüger+(+)-Matrix im Bus immer wenn vorhanden ein Ziel addiert mit 20.000 nimmt. Ist keins mit 20.000 da, nimmt es das "normale".


    Sorry, entweder hast du mich falsch verstanden (dann muß ich den Beitrag anders schreiben, da habe ich mich vermutlich unpräzise ausgedrückt oder "zu lang geschwaffelt". Das ganze System funktioniert, ohne das eine Matrix den IBIS-Code umrechnen muß.



    Im fogenden stehen die Strings für die entsprechenden Anzeigen: der Nummer nach


    Die schreibweise ist dabei egal, ob nun untereinander wie in Omsi 1 oder mit Tabulator-Taste wie in Omsi 2. Der große Nachteil an dem Omsi 2-Format mit Tabulator-Taste ist die Übersicht, die dabei verloren geht. Man muß nur die Busse entsprechend anpassen und jeder Bus ließt nur die Zeilen aus, die für sein System passend ist. Mit der universellen Hofdatei, so wie sie Marcel und Rüdiger ursprünglich eingeführt haben, funktioniert es genauso, wie mit meiner erweiterten Hofdatei. Sie hat halt lediglich einige Stringsmehr, als ein einzelner Bus.
    Sicher, ist es für den MB O 405 N 1 aus dem Hamburg Add-On etwas seltsam, in der Hofdatei nach dem Endstellennname dann 17 leere Zeilen zu haben, wenn man die Hofdatei nur für diesen einen Bus erstellt. Aber dazu hatte ich Darius schon mehrere Mail's und auch PN's geschrieben, auf die er nicht reagiert hatte.


    Marcel hat bei der folgenden Umsetzung für die Add-On's nicht auf die universelle Hofdatei geachtet, weil er und Rüdiger anfang's den Verdacht hatten, daß eine Universelle Hofdatei bei der Fülle der Anzeigesysteme nicht funktionieren könnte. Der Verdacht beruht aber nur darauf, das eine Hofdatei mit mehr als 10 Strings (also von String 0 bis string 9), nicht von Omsi akzeptiert wird. In Wirklichkeit akzeptiert Omsi aber 999 String, wobei man nun weiß, daß man nichtmal 99 Strings benötigen wird. (Im wesentlichen die Einschätzung von Marcel via PN)


    Solltest du mit deinem Beitrag die Reihenfolge der verwendeten Strings für die jeweiligen Anzeige-Systeme meinen, so bedenke bitte folgendes:
    Ich habe mich anfangs mit Busfanat und mit ViewApp unterhalten. Daher wollte ich diese Systeme zuerst einsetzen. Darius hat ja nicht reagiert. Und auch Perotinus hat meine PN's dazu leider nicht gelesen (bei der Fülle an PN's die er bekommt, ist das kein Wunder). ViewApp hat mich mit Davidps verbunden, der für solche Dinge im Add-On Wien zuständig ist. Es wurde nur leider für die Linie 24A in Wien nicht umgesetzt (Vermutlich vergessen).
    Darum stehen die Systeme in der Reihenfolge, wie ich diese erweitert habe und wie Busfanat und Perotinus diese umgesetzt haben.


    Sei mir bitte nicht böse, Rumpelhans 104, aber deinen Beitrag versteht sicher Busfanat, der sich in den Scripten besser auskennt als in seinem eigenen Wohnzimmer. Er hat seine Matrix umgestellt ohne Omsi 2 zu besitzen und es funktioniert. Daher haben WIR - also Busfanat, Perotinus und ich - die Reihenfolge so festgelegt. Für die anderen Anzeigesystemen muß nun die Hofdatei erweitert werden, wenn sich die entsprechenden "Erfinder" mal mit mir in Verbindung setzen würden, um die Anzahl der benötigten Strings genau abzusprechen und diese einzustellen.


    ACMG schrieb ja, das er die Umsetzung sehr skeptisch sieht. Ich weiß nicht genau wie er es meint. Für die einzelnen Anzeigesysteme und Bussen ist es einfach und kein wirklicher Akt. Die Hofdatei kann ich schnell erstellen, aber es ist sinnlos, wenn die Add-On-Hersteller und Busbauer nicht mitziehen. Das Problem der Umsetzung ist die fehlende Kommunikation zwischen, den Add-On-Herstellern und Busbauern mit mir. Und das soll kein Vorwurf sein.


    Ich finde grundlegend die Idee mit der universellen HOF-Datei sehr interessant, da muss man auch erst drauf kommen


    Auf die Idee kamen Marcel und Rüdiger, nicht ich. Und die beiden haben sich bestimmt etwas dabei gedacht. Mir fiel das ganze nur auf, als ich den Solaris Urbino 15 auf Wien fahren wollte. In der Anzeige steht nichts drin und das IBIS zeigte mir Zahlencodes statt die Haltestellennamen. Noch schlimmer war es im Add-On Hamburg. Der Solaris Urbino 15 (mit ANNAX-Anzeige) zeigte die obere Zeile der Frontanzeige, die zweite Zeile an und in der unteren garnichts und das IBIS zeigte nur Abkürzungen. Aber das Problem war das Plug-In von holmexx für die Logitech-Tastatur mit Display. Diese lesen den String für das IBIS 1 aus. Steht hier nicht alles in Großbuchstaben, zeigt das Display ganichts an.
    Also hatte ich mich mit Busfanat und Davidps unterhalten, die mir erklärt haben wo die Fehler liegen. So habe ich die Hofdatei erweitert und dann wollte ich die Add-On-Hersteller von der Umsetzung überzeugen. Alles ohne es im Forum öffentlich zu machen. Leider klappt die Kommunikation zwischen Software-Firmen und Kunden garnicht, bis sehr mangelhaft........


    Übrigens Rumpelhans 104: Du darfst gern den Beitrag vervollständigen. Ich habe nichts dagegen. Würde mich freuen, denn es ist bereits jetzt schon ein Gemeinschaftsprojekt, dank Busfanat, Perotinus und Davidps. Und natürlich auch Dank deiner Hilfe, für die Erklärungen der Formatierung des Beitrages. Ich habe es nur veröffentlicht als Schreiber.


    Die Hofdatei wieder auf eine universelle umzustellen, ist eigentlich von Busfanat, weil er mir erklärte das man nur die Busse umstellen müßte.


    EDIT: Wieder war Busfanat schneller als ich und hat es auf einen Punkt gebracht, wo das Problem mit der universellen Hofdatei liegt:

    Zitat

    Ich halte ein einheitliches Hofdateienformat grundsätzlich für eine gute Idee. Trotzdem bin ich gespannt, ob sich diese Idee durchsetzt. Schließlich müssen die Busbauer bzw. deren Scripter das erst als "Standard" anerkennen und dann danach handeln. Weil sonst ist die Geschichte für die Fische.


    Genau das meinte ich.

  • Ach so, dann habe ich deinen / euren Ansatz etwas falsch gedeutet.
    Nachvollziehen kann ich das "Problem", was sich aus einer nicht-universellen Matrix/Datei ergibt, aber.


    Hier sind aber - wie Busfanat schon sagte - die Busbauer in der "Pflicht", bis dahin mache ich schön meine HOF-Dateien für verschiedene Systeme.
    Ist zwar ein bisschen Arbeit, aber wenn man ordentlich arbeitet, geht das mit unterschiedlichen Templates im Hof-Creator recht leicht.

    :)


    Ich finde es übrigens gut, dass das von Anfang an so gewollt ist, von M(R), denn erst so kam das ganze System überhaupt zu Stande.


    Ich werde dann mal die Links im Wiki-Artikel korrigieren, und Tabellen einrichten

    ;)
  • Ich hatte ja schon per PN geschrieben, was ich meinte, will es aber hier nochmal öffentlich machen. Da ist zum einen das Zitat von Busfanat, dem ich mich anschließe. Zum anderen ist potenziell ja eine Fülle von Varianten bei den Anzeigensystemen möglich. Busfanat hat das auch schon angedeutet: Ein paar Änderungen im Matrix-Skript und schon sind neue Features möglich, für welche die Hof-Datei angepasst werden muss, obwohl die Anzeige im Grunde immer noch dieselbe ist. Ich selber bastel noch an einem Mod, bei dem ich ein eigenes Rollband einbinde. Das benötigt aber eigene Texturen, die selbstverständlich in der Hof-Datei stehen müssen - wieder 2 Strings mehr. Bei den Krüger-Bitmaps besteht auch die Möglichkeit von verschiedenen Varianten, je nach Auflösung der Matrix, oder jemand macht einen Mod, mit dem seitlich was anderes angezeigt werden kann als auf der Front. Jemand anderer macht das gleiche dann für Busse mit breiter Heckmatrix für die Heckanzeige.
    Und das betrifft jetzt erst einmal nur das Thema Zielanzeiger und Endstationen (also den Terminus-Block). Bei den Routen und Zwischenhaltestellen ist ja noch mehr denkbar. Die eine Innenanzeige kann nur Großbuchstaben und maximal 16 Zeichen darstellen. Wenn der Entwickler aufpasst, dann akzeptiert sie auch Kleinbuchstaben und wandelt das "ß" in "SS" um, mehr ist aber schlecht drin. Eine andere kann Groß- und Kleinbuchstaben, Symbole (z.B. S-Bahn-Logo) und durch Scrolling beliebige String-Längen darstellen. Der zugehörige Fahrscheindrucker ist aber evtl. limitierter und will deshalb wieder eigene Strings. Das lässt sich einfach schwer unter einen Hut bringen, wenn dazu erst mal die Entwickler alle koordiniert werden müssten ("Verwende String Nr. 167 für dieses und 184 für jenes). Dazu leidet die Übersicht der Hof-Datei immens, wenn man das alles da reinpackt.
    Deswegen meinte ich, dass ich skeptisch bin: Einerseits die notwendige Akzeptanz durch die Entwickler (Busbauer und Modder), andererseits die Unzulänglichkeiten des Dateiformats, das für die Fülle an Informationen irgendwann nicht mehr geeignet ist. Man sieht es ja schon daran, dass es das alte Format gibt, bei dem man schön die Strings untereinander schreibt und daher innerhalb eines Eintrags schnell die richtige Position findet, und parallel dazu das neue, bei dem man viel schneller z.B. einen Terminus findet und eine Übersicht hat, weil der Bildschirm besser ausgenutzt wird und nicht für jede Mini-Information eine neue Zeile verwendet wird. Hat beides Vor- und Nachteile.


    Sinnvoll wäre für ein solches Vorhaben (einheitliche Hof-Datei für alles Mögliche) die Nutzung eines anderen Datenformats. Ich würde da spontan an ein XML-basiertes Format denken, bei dem jeder Content-Ersteller seine eigenen Daten z.B. durch Nutzernamen-Präfix eingliedern kann. Gute Editoren gibt es dafür reichlich (ein Texteditor tut es dann natürlich nicht mehr), die einem die Baumstruktur mit Möglichkeiten zum ein- und ausklappen anzeigen oder per Filter nur bestimmte Elemente, etc. OMSI könnte dann einen einfachen Query-Mechanismus per System-Makro anbieten, mit dem man alles auslesen kann, was einem beliebt. Dafür müsste Marcel aber erst einmal OMSI anpassen, d.h. das liegt nicht in unserer Macht.


    Ich will damit jetzt nicht sagen, dass die Idee schlecht ist oder zum Scheitern verurteilt. Vorübergehend mag das praktikabel und umsetzbar sein, doch in meinen Augen ist das aus den oben genannten Gründen keine Dauerlösung.

  • Zum anderen ist potenziell ja eine Fülle von Varianten bei den Anzeigensystemen möglich. Busfanat hat das auch schon angedeutet: Ein paar Änderungen im Matrix-Skript und schon sind neue Features möglich, für welche die Hof-Datei angepasst werden muss, obwohl die Anzeige im Grunde immer noch dieselbe ist.


    Das ist absolut richtig, ACMG. Es ist eine große Möglichkeit gegeben wie man ein und das selbe Ziel im Bus oder am Bus anzeigen lassen kann. Hier sollte natürlich die Möglichkeit genutzt werden, wie bei der Busfanat-Vollmatrix, mit Buchstaben-Codes zu arbeiten. Es könnte zwar auch eine Möglichkeit geschaffen werden, weitere Strings für eine Anzeige einzurichten und die Form der Anzeige Stringsabhängig zu machen, ist aber nicht Sinn der Sache.


    Das klingt in etwa nach einem Aufruf zum Rekordversuch ... So schnell wie möglich, so viele Strings in der Hofdatei wie irgend machbar zu erstellen. Das soll natürlich nicht zum Omsi-Sport ausarten, eine Hofdatei zu verfassen die 872 Strings aufführt. Es kommt immernoch darauf an, die Hofdatei sinnvoll zu nutzen.
    Dazu ein schönes Beispiel:

    Ich selber bastel noch an einem Mod, bei dem ich ein eigenes Rollband einbinde. Das benötigt aber eigene Texturen, die selbstverständlich in der Hof-Datei stehen müssen - wieder 2 Strings mehr.


    Dein Mod klingt interessant, aber die Umsetzung ist noch nicht durchdacht. Sicher kann man für jedes Rollbandgerät einen eigenen String verwenden - aber es reicht auch ein einziger String. Selbst wenn der Bus 6 verschiedene Rollbandanzeigen im und am Bus hat, reicht doch der vorhandene String 4 vollkommen aus. Es geht ja nicht um einen Rekord, die Hofdatei auf biegen und brechen mit hunderten Strings zu füllen.


    In deinem Beispiel ist es ausreichend die Rollbandanzeigen von String 4 zu steuern. In den Scripten gibst du ja für jedes Rollbandgerät ein:
    - welche String soll das Gerät auslesen und
    - wo findet das Script die Textur dazu.
    Daher solltest du 3 Texturen anfertigen, die aber alle den selben Dateinamen haben und die selbe Dateiendung. Da du nicht blöde bist, kannste dir den Rest schon alleine ausrechnen. Der Pfad lautet (wie du nun richtig vermutest):
    Omsi\Vehicles\Anzeige\Omnibus\Map\Rollband.....
    - Rollband1
    - Rollband2
    - Rollband3
    - Rollband4
    usw.
    So kann ein Bus über 6 oder mehr Rollbandgeräten verfügen, ein String reicht vollkommen aus.
    Man kann es maßlos übertreiben, daß ist mir schon klar, aber man sollte dabei die Kirche im Dorf lassen. Im Übrigen ist auch diese Idee nicht von mir, ich denke mir hier also nichts aus was nicht schon vorhanden ist. Der LU-200 aus dem Add-On Wien von ViewApp, besitzt auch zwei Rollbänder mit unterschiedlichen Texturen, liest aber trotzdem nur einen einzigen String aus. Also wozu braucht deine Rollbandtechnik nun mehr als einen String? Die Frage meine ich keineswegs ironisch. Darum habe ich in den Beitrag auf Omsi-Wiki auch geschrieben, daß ich meine Hilfe anbiete. Damit alles eine Adresse hat, wer alles im Überblick behält. Wenn du Hilfe brauchst, darfst auch du dich bei mir melden. Das gilt für alle, egal ob nun etwas kommerzielles oder nichtkommerzielles entwickelt wird.


    Bei den Krüger-Bitmaps besteht auch die Möglichkeit von verschiedenen Varianten, je nach Auflösung der Matrix, ...


    Darum sollte man sich vorher überlegen was man macht. Man kann hunderte Strings verwenden, aber ist es sinnvoll? Besonders wenn es darum geht das Anzeige XY String 14 und 15 benutzt und durch eine Änderung der Auflösung nun noch String 22 und 23 ausliest. Man kann auch ein und das selbe Ziel in 30-40 Varianten anzeigen lassen ... Aber wo ist der Sinn ? Bei aller Liebe zum Detail, sollte man auch das ganze mit bedacht einsetzen. Oder vielleicht kann ich die Matrx XY auch die bereits vorhandenen Infos, einer anderen Matrix auslesen lassen ? Man könnte sicher auch die Busfanat-Vollmatrix so umstellen, daß diese Ziele je nach Eintrag in der Hofdatei anders dargestellt wird ....
    - String 1 & 2 = normale Darstellung
    - String 11 & 12 = Großschrift
    - String 13 & 14 = Negative schriftform usw
    Dann komme ich natürlich recht schnell auf weit über einhundert Strings die benötigt werden. Gerade aus diesem Grund, biete ich natürlich auch meine hilfe an, damit das ganze nicht sinnlos aus dem Ruder läuft.
    Wie gesagt, es geht nicht darum die Hofdatei mit bis zu 999 Strings auszulasten.


    Bei den Routen und Zwischenhaltestellen ist ja noch mehr denkbar. Die eine Innenanzeige kann nur Großbuchstaben und maximal 16 Zeichen darstellen.


    Wo ist denn da das Problem ? 16 Buchstabenfelder und nur Großschrift ... aha String 0 für das IBIS 1 - wie gesagt es geht nicht darum alles auf biegen und brechen zu erweitern. Wenn ein Format vorhanden ist, kann man das auch für andere nutzen und nicht für jedes einzelne System eigene Strings erfinden. Es ist doch nicht gesagt, das auschließlich ein einziges Gerät im Bus auf einen String zugreifen darf, auch andere Geräte dürfen darauf zugreifen.


    Wenn der Entwickler aufpasst, dann akzeptiert sie auch Kleinbuchstaben und wandelt das "ß" in "SS" um, mehr ist aber schlecht drin. Eine andere kann Groß- und Kleinbuchstaben, Symbole (z.B. S-Bahn-Logo) und durch Scrolling beliebige String-Längen darstellen.


    Für solche Zwecke kann man dann neue Strings erweitern, wenn diese noch nicht da sind. Oder wenn ein Format nicht passend gefunden werden kann. Wenn ein Entwickler natürlich auch 300 Informationszeilen zwischen den Haltestellen einrichten möchte, ist es egal ob er eine neue Hofdatei nur für seine Zwecke erstellt oder die erweiterte Hofdatei anwendet. Er wird dann so oder so 300 Strings einrichten müßen. Da fallen die 4 bestehenden nicht weiter auf.


    Der zugehörige Fahrscheindrucker ist aber evtl. limitierter und will deshalb wieder eigene Strings.


    Soviele Fahrscheindrucker gibt es nicht, derzeit sind es nur 4 Strings und in Verbindung mit Anzeigegräten werden es nur einige sehr wenige mehr. Mit den Bussen aus dem Hamburger Add-On und dem Wiener LU-200 werden es maximal 6. Wenn man natürlich auf Teufel komm raus, weitere Strings einrichten möchte, kann ich das auch nicht verhindern. Aber das würde ja dann auch wieder auf die Meisterschaft hinauslaufen, soviele Strings wie möglich zu nutzen. Allerdings denke ich das auch in Zukunft die Anzahl der zu verwendeten Strings überschaubar bleibt. Ich kann es leider auch nur so erklären, warum ein neuer Bus eine eigene Hofdatei bekommen muß, weil es einfacher ist, das entsprechende Script komplett zu kopieren als ein oder zwaei Ziffern auszutauschen. Und mehr als meine Hilfe (kostenlos ohne Gegenleistung) kann ich nicht anbieten. Also alles im Allem, bleibt letzlich nur noch ein einziges Problem übrig, daß schon bekannt ist.


    Das lässt sich einfach schwer unter einen Hut bringen, wenn dazu erst mal die Entwickler alle koordiniert werden müssten ("Verwende String Nr. 167 für dieses und 184 für jenes).


    Das koordinieren ansich ist nicht das Problem, sondern eher die Bereitschaft der Entwickler, mit einem Kunden in Kontakt zu treten. Wie schon erwähnt habe ich Darius mehr als eine Mail und PN gesendet. Ich kann ihn ja wohl schlecht zwingen mir zu antworten. Außerdem ist es einfacher, wenn man nicht auf die Kundenwünsche eingeht, denn viele haben geschrieben, daß ihr Lieblingsbus in Hamburg nicht richtig anzeigt. Darius ist nicht auf einen einzigen dieser Beiträge eingegangen (zumindest so weit wie ich das verfolgt haben und verfolgen konnte).
    Und was ist eigentlich einfacher, eine Hofdatei komplett neu zu schreiben oder eine vorhandene einfach zu erweitern ? Ich habe mehrfach Darius angeboten ihm eine Hofdatei für Hamburg zu senden und seine veränderten Scriptdateien. Ich möchte dafür kein kostenloses Add-On haben, keine Bezahlung oder andere finanzielle Aufwendung, nichtmal eine namentliche Erwähnung. Denn die Idee ist ja nicht von mir.


    Deswegen meinte ich, dass ich skeptisch bin: Einerseits die notwendige Akzeptanz durch die Entwickler (Busbauer und Modder), andererseits die Unzulänglichkeiten des Dateiformats, das für die Fülle an Informationen irgendwann nicht mehr geeignet ist. Man sieht es ja schon daran, dass es das alte Format gibt, bei dem man schön die Strings untereinander schreibt und daher innerhalb eines Eintrags schnell die richtige Position findet, und parallel dazu das neue, bei dem man viel schneller z.B. einen Terminus findet und eine Übersicht hat, weil der Bildschirm besser ausgenutzt wird und nicht für jede Mini-Information eine neue Zeile verwendet wird. Hat beides Vor- und Nachteile.


    Also ich finde den Aufbau der Hofdatei aus Omsi 1 vorteilhafter, weil man hier genau sieht, welcher Eintrag für was ist. Beim Omsi 2 Format leidet schon jetzt die Übersichtlichkeit. Sicher wird der Bildschirm besser ausgenutzt, aber nicht alle haben eine 24'' Monitor, oder können noch alles lesen, wenn ich auf einen 20'' Monitor die Schriftgröße "8" eintrage. Denn wenn ich mit der Tap-Taste arbeite, steht auch nicht alles richtig untereinander. Da leidet die Übersichtlichkeit schon jetzt.
    Zum Dateiformat: Es geht darum, Omsi mit einfachsten Mitteln verändern zu können, also mit Mitteln die auf dem Rechner bereits vorhanden sind - auf jedem Rechner. Sicher ist eine Exel-Tabelle übersichtlicher. Aber entweder nutze ich Microsoft Office, was einen horenten Preis hat, oder Open-Office was ja Freeware ist - Programme die nicht zum Windows-Standard gehören. Die Hofdatei im Textformat ist vollkommen ausreichend, sicher kann ich dort kein S-Bahn-Logo einsetzen. Aber dafür kann ich Bilddateien verwenden oder Zeichencodes. Denn auch EXEL hat seine Grenzen und passt teilweise nicht auf einen Bildschirm, wenn ich alles ausfülle. Und Omsi ist es egal, ob ich die Hofdatei im Omsi 1 oder Omsi 2 Format darstelle. Es kommt nur darauf an, wie ich bei der Erstellung der Hofdatei den Überblick behalte. Nichtumsonst, habe ich auf die Verwendung eines externen Schreibprogramms oder eines Tabellenprogrammes verwiesen. Wie es dann in der Hofdatei aussieht, ist nach getaner Arbeit fast egal. Für die Fehlerbeseitigung, öffne ich es wieder mit Office.


    Eine Dauerlösung, ist es sicher nicht, besonders wenn sich einzelne Busbauer oder Add-On ersteller nicht daran halten. Aber eine Hofdatei für fast jeden einzelnen Bus, ist sicher die schlechtere Alternative. Welcher Freeware-Map-Bauer, erstellt 7 oder mehr Hofdateien, für alle Busse ? Und dann kommt das größere Problem - nicht jeder ist so fit wie du am Rechner und kann mal ebend schnell eine Hofdatei erstellen. Und genau darum geht es ja - für jedes Anzeigesystem eine Hofdatei - sehr sinnvoll ist es nicht. Aber viel schlimmer ist es, wenn eine neue Strecke kauft (und damit meine ich, jetzt kostenpflichtige Add-Ons, wie Hamburg oder Wien) die ich installieren und dann feststellen muß, daß mein Lieblingsbus nichts anzeigt oder Blödsinn anzeigt und die Fahrkunden nicht einsteigen. Ich kann eine Hofdatei erstellen. Aber sehr viele Kunden können das nicht. Die müssen sich jemanden sucher, der das macht, oder warten bis eine Hofdatei erscheint, um dann zu merken das diese nicht passt. Und ich bin mir ziemlich sicher, daß das Add-On Wien, sicher mehr Käufer gefunden hätte, wenn man darauf verzichtet hätte nichtnur eine einzige Linie, einen uralten Bus und eine eigene speziell auf den LU-200 abgestimmte Hofdatei rausgebracht hätte. Ich habe einige Freunde, die sich den Kauf dieses Add-On verkniffen haben, weil es noch keine brauchbare Hofdatei gab. Da frage ich mich allerdings, wie schwer war es wohl in 2 Scripten insgesamt 3 Ziffern zu ändern? Für ViewApp, war es nicht möglich, da schreibt man lieber eine Hofdatei für einen Bus, der bei der Community nicht besonders gut ankommt.
    Und in Hamburg hat man nichtnur die Ziffern verändernt, sondern auch dadurch den Aufbau der Hofdatei, nur damit die User wirklich nur die mitgelieferten Busse benutzen müßen. Wieso sollte ein User auch die Möglichkeit erhalten, Freeware-Busse auf dieser Map zu fahren, die von der Qualität oder von der Steuerung besser sind, als die original mitgelieferten Fahrzeuge ? Versuche mal den MB O 305 mit der Hofdatei des originalen Hamburger MB O 405 N1 zu füttern - und sage mir bitte das das eine Kundenfreundlichkeit der Firma ist. Mir ist schon klar, daß ich von einigen Fiormen unmögliches verlange, aber versuchen sollte ich es wenigsten's


    Da gab es mal einen schönen Beitrag dazu, wo es darum geht, warum Add-On Hersteller ihre eigene Sache machen:

    Zitat von Busfanat


    Zitat von »fw-online.de«
    Die Payware-Ersteller werden da schon ihre klaren Gründe haben warum sie da nicht drauf eingehen. Ist schließlich immer noch deren Sache.


    Theoretisch. Wenn dann nicht 100 "Neulinge" rumflennen, weil sie das Fahrzeug nicht auf Spandau fahren können, weil er nicht richtig schildert, ist das nicht mehr deren Sache, sondern müllt das Forum zu (Weil die <- das würde sowieso zensiert werden -> es ja nicht schaffen, in das verdammte Support-Thema des Addons zu schreiben). Dann ist es einfach eine vermeidbare Gemeinheit gegenüber der Moderation.

  • Das ist absolut richtig, ACMG. Es ist eine große Möglichkeit gegeben wie man ein und das selbe Ziel im Bus oder am Bus anzeigen lassen kann. Hier sollte natürlich die Möglichkeit genutzt werden, wie bei der Busfanat-Vollmatrix, mit Buchstaben-Codes zu arbeiten. Es könnte zwar auch eine Möglichkeit geschaffen werden, weitere Strings für eine Anzeige einzurichten und die Form der Anzeige Stringsabhängig zu machen, ist aber nicht Sinn der Sache.


    Ich verstehe jetzt nicht ganz, was du meinst. Die Buchstabencodes von Busfanat werden ja nicht unbedingt von jeder Anzeige gefressen. Dazu kann selbst die Anzeige für einen Terminus bei einem Bus anders aussehen als bei einem anderen, obwohl beide rein optisch dieselbe Matrix zu verwenden scheinen.


    Das klingt in etwa nach einem Aufruf zum Rekordversuch ... So schnell wie möglich, so viele Strings in der Hofdatei wie irgend machbar zu erstellen. Das soll natürlich nicht zum Omsi-Sport ausarten, eine Hofdatei zu verfassen die 872 Strings aufführt. Es kommt immernoch darauf an, die Hofdatei sinnvoll zu nutzen.


    Das sollte es natürlich nicht sein. Doch irgendwann kommt man mit dem aktuellen System einfach an eine Grenze. Mag noch Jahre dauern, deswegen würde ich mich auch für ein flexibleres Format als Basis aussprechen.



    Ich gebe dir eingeschränkt recht. Das Rollband bekommt ein eigenes Verzeichnis im Anzeigen-Ordner, da können dann natürlich auch die passenden Texturen mit demselben Namen rein wie bei dem SD79-Rollband. Wenn aber ein zweites Rollband verbaut ist, bei dem für dasselbe Ziel unterschiedliche Texturen verwendet werden können, muss das doch irgendwie in der Hofdatei abgebildet sein. Das Scriptsystem lässt da einige Spielereien zu, die ich nicht zum Einsparen eines Strings opfern würde. Da geht für mich die Funktion vor der Einhaltung von gegebenen, aber an sich ja flexiblen Strukturen. Ich behalte lieber die Flexibilität. Wenn das Ding weiter gediehen ist, kann ich gern auf dich zukommen und dir erklären, warum ich es auf diese oder jene Art löse. Vielleicht fällt dir dann auch ein besserer Weg sein, dafür bin ich dann auch nicht undankbar.



    Wo ist denn da das Problem ? 16 Buchstabenfelder und nur Großschrift ... aha String 0 für das IBIS 1 - wie gesagt es geht nicht darum alles auf biegen und brechen zu erweitern. Wenn ein Format vorhanden ist, kann man das auch für andere nutzen und nicht für jedes einzelne System eigene Strings erfinden. Es ist doch nicht gesagt, das auschließlich ein einziges Gerät im Bus auf einen String zugreifen darf, auch andere Geräte dürfen darauf zugreifen.


    Wenn im IBIS 1 aber etwas anderes stehen soll, dann funktioniert dieser Weg nicht mehr. Darum ging es mir, deswegen auch das Beispiel mit der flexiblen Anzeige mit Logo-Anzeige usw. Ich wollte nicht sagen, dass man für alles immer einen neuen String braucht.

    ;)



    Soviele Fahrscheindrucker gibt es nicht, derzeit sind es nur 4 Strings und in Verbindung mit Anzeigegräten werden es nur einige sehr wenige mehr. Mit den Bussen aus dem Hamburger Add-On und dem Wiener LU-200 werden es maximal 6. Wenn man natürlich auf Teufel komm raus, weitere Strings einrichten möchte, kann ich das auch nicht verhindern. Aber das würde ja dann auch wieder auf die Meisterschaft hinauslaufen, soviele Strings wie möglich zu nutzen. Allerdings denke ich das auch in Zukunft die Anzahl der zu verwendeten Strings überschaubar bleibt. Ich kann es leider auch nur so erklären, warum ein neuer Bus eine eigene Hofdatei bekommen muß, weil es einfacher ist, das entsprechende Script komplett zu kopieren als ein oder zwaei Ziffern auszutauschen. Und mehr als meine Hilfe (kostenlos ohne Gegenleistung) kann ich nicht anbieten. Also alles im Allem, bleibt letzlich nur noch ein einziges Problem übrig, daß schon bekannt ist.


    Die Indizes zu ändern ist nun wirklich nicht viel mehr Aufwand als Copy&Paste. Bei meinem Einwand ging es nicht darum, auf Teufel komm raus neue Strings einzurichten (ich weiß nicht, wieso du das mehrfach unterstellst), sondern auf "Realität komm raus". Wenn es in der Realität so ist, dass das Gerät andere Stringlängen und Zeichen wiedergeben kann als es der OMSI-Standard vorsieht, dann würde ich es auch so bauen, dass es in OMSI ebenso ist und mich nicht limitieren.


    Also ich finde den Aufbau der Hofdatei aus Omsi 1 vorteilhafter, weil man hier genau sieht, welcher Eintrag für was ist. Beim Omsi 2 Format leidet schon jetzt die Übersichtlichkeit. Sicher wird der Bildschirm besser ausgenutzt, aber nicht alle haben eine 24'' Monitor, oder können noch alles lesen, wenn ich auf einen 20'' Monitor die Schriftgröße "8" eintrage. Denn wenn ich mit der Tap-Taste arbeite, steht auch nicht alles richtig untereinander. Da leidet die Übersichtlichkeit schon jetzt.


    Ich hatte vor einiger Zeit mal gelesen, dass die Entwickler hierbei eine Excel-Tabelle im Sinn hatten. TABs sind in Textdateien kein Mittel, um Strings unterschiedlicher Länge zu trennen und gleichzeitig ein übersichtliches Bild zu erhalten. Wenn man aber ein einer Excel-Tabelle ausgeht, in der die Einträge bearbeitet werden und die dann exportiert wird, ergibt das schon mehr Sinn. In der Kopfzeile kannst du dir die Bedeutung der Einträge dann eintragen und stets im Blick behalten. Da M&R so vorgegangen sind, wäre das vielleicht auch für die Nutzer eine Überlegung wert, statt am Texteditor festzuhalten. Dies nur als Hinweis, wie der Umgang mit dem neuen Format erleichtert wird, ich will damit nicht vorschlagen, Hof-Dateien im xls- oder xlsx-Format anzulegen.


    Zum Dateiformat: Es geht darum, Omsi mit einfachsten Mitteln verändern zu können, also mit Mitteln die auf dem Rechner bereits vorhanden sind - auf jedem Rechner. Sicher ist eine Exel-Tabelle übersichtlicher. Aber entweder nutze ich Microsoft Office, was einen horenten Preis hat, oder Open-Office was ja Freeware ist - Programme die nicht zum Windows-Standard gehören. Die Hofdatei im Textformat ist vollkommen ausreichend, sicher kann ich dort kein S-Bahn-Logo einsetzen. Aber dafür kann ich Bilddateien verwenden oder Zeichencodes. Denn auch EXEL hat seine Grenzen und passt teilweise nicht auf einen Bildschirm, wenn ich alles ausfülle. Und Omsi ist es egal, ob ich die Hofdatei im Omsi 1 oder Omsi 2 Format darstelle. Es kommt nur darauf an, wie ich bei der Erstellung der Hofdatei den Überblick behalte. Nichtumsonst, habe ich auf die Verwendung eines externen Schreibprogramms oder eines Tabellenprogrammes verwiesen. Wie es dann in der Hofdatei aussieht, ist nach getaner Arbeit fast egal. Für die Fehlerbeseitigung, öffne ich es wieder mit Office.


    XML ist nicht Excel, sondern eine sogenannte Auszeichnungssprache: Wikipedia XML-Dateien sind textbasiert (also mit jedem Texteditor grundsätzlich editierbares) und hierarchisch strukturiert. Die Arbeit mit einem Texteditor ist jedoch sehr unübersichtlich bei größeren Dateien, deswegen gibt es etliche freie und komfortable XML-Editoren, mit denen das wesentlich leichter geht und die Features besitzen, die den Umgang mit dem Format deutlich erleichtern.
    Dass man ein S-Bahn-Logo als Bild in eine Hofdatei packen können sollte, habe ich nicht im Sinn gehabt. Wo das Problem ist, sich ein Freeware-Tool zum Editieren herunterzuladen, verstehe ich allerdings nicht. Mit MS Paint macht ja auch niemand hier seine Repaints, bei den Sounds bezweifle ich auch, dass viele Leute auf die Windows-Basisausstattung setzen. Der Windows-Notepad-Texteditor ist nur mäßig geeignet für seine Kernaufgabe, weil etliche Funktionen fehlen, vom Schreiben von Skripten mit dem Teil würde ich üble Schmerzen bekommen. Wer will, kann XML ja gern mit Notepad editieren, also sollte das auch kein Problem sein. Ich würde nur am Geisteszustand der Person zweifeln.

    ;)


    Nebenbei bemerkt ist Office in den Basisversionen für den normalen Hausgebrauch gar nicht so teuer.


    Eine Dauerlösung, ist es sicher nicht, besonders wenn sich einzelne Busbauer oder Add-On ersteller nicht daran halten. Aber eine Hofdatei für fast jeden einzelnen Bus, ist sicher die schlechtere Alternative. Welcher Freeware-Map-Bauer, erstellt 7 oder mehr Hofdateien, für alle Busse ? Und dann kommt das größere Problem - nicht jeder ist so fit wie du am Rechner und kann mal ebend schnell eine Hofdatei erstellen. Und genau darum geht es ja - für jedes Anzeigesystem eine Hofdatei - sehr sinnvoll ist es nicht.


    Exakt aus diesem Grund wäre ein erweiterbares Format auf XML-Basis (das X steht ja genau dafür) eine bessere Lösung als Textgewurschtel à la CSV. Dass das Problem vorhanden ist, darüber sind wir uns doch einig. Ich würde mir lediglich in einer künftigen OMSI-Version eine andere Lösung für dieses Problem wünschen, die keine Abstimmung zwischen den Autoren benötigt, niemanden einschränkt und gut zu editieren ist. Auch wenn man dafür mal andere Software anfassen muss als das, was Windows im Paket hat. Geht bei Texturen doch auch.


    Und in Hamburg hat man nichtnur die Ziffern verändernt, sondern auch dadurch den Aufbau der Hofdatei, nur damit die User wirklich nur die mitgelieferten Busse benutzen müßen. Wieso sollte ein User auch die Möglichkeit erhalten, Freeware-Busse auf dieser Map zu fahren, die von der Qualität oder von der Steuerung besser sind, als die original mitgelieferten Fahrzeuge ?


    Das war ganz sicher nicht der Gedankengang von Darius dabei. Abgrundtiefe Bosheit schien mir bisher keine seiner Charaktereigenschaften zu sein.


    Versuche mal den MB O 305 mit der Hofdatei des originalen Hamburger MB O 405 N1 zu füttern - und sage mir bitte das das eine Kundenfreundlichkeit der Firma ist.


    Der O 305 ist zum einen auch Payware, zum anderen würden ja die Texturen für das Rollband schon fehlen. Die hätten dann auch noch mitgeliefert werden müssen.
    Die Payware-Addons sind grundsätzlich so ausgelegt, dass sie innerhalb ihres Pakets funktionieren. Für fremde Komponenten mag niemand Verantwortung und Support übernehmen. Das geht einfach nicht. Dass der Bedarf der User anders aussieht, da hast du natürlich recht. Dass zumindest bei den 3G-Bussen eine andere Anzeige mit der Krüger-Methodik und entsprechenden Hofdateien schöner gewesen wäre, stimmt auch. Aber wenigstens wurde der Bedarf erkannt, dass die Busse auch auf anderen Maps fahren sollen und dies mit begrenztem Erfolg auch umgesetzt.


    Da gab es mal einen schönen Beitrag dazu, wo es darum geht, warum Add-On Hersteller ihre eigene Sache machen:


    Das Warum bleibt bei dem Zitat leider unbeantwortet.

    ;)
  • Guten Abend,


    ich misch' mich dann auch mal wieder ein...


    Kurz zusammengefasst, ich geb euch beiden, ACMG und Tatra, zu einem gewissen Teil Recht.


    Natürlich würde man, um jedes Anzeigesystem in OMSI realitätsgetreu mit einer einheitlichen Hof-Datei einsetzen zu können, eine riesige Hofdatei brauchen. Ob im pseudo-csv-Format oder XML sei mal dahingestellt. Solange sich M&J zu diesem Thema nicht äußern, müssen wir sowieso die Möglichkeiten nutzen, die uns OMSI aktuell gibt.


    Wenn man sich aber anschaut, wie viele Busse, die umgesetzt wurden, mit großteils den gleichen Scripts rumfahren, dann ist meiner Meinung nach der Bedarf nach verschiedenen Strings sowieso bald gedeckt. Ich glaube, mit 25 Strings pro Zielcode kommen wir die nächsten Monate wenn nicht Jahre über die Runden, weil sich einfach die Anzahl der Scripter in Grenzen hält.


    Mein Gedankengang zu dem Thema ist halt, besser die Anzeige weicht zu 5% von der Realität ab, als dass sich die lautesten und nervigsten Stimmen im entsprechenden Thread (wenn sie sich wenigstens auf den Thread beschränken würden und nicht das ganze Forum zuspammen, aber das ist ein anderes Thema...) darüber aufregen, dass man schon wieder eine eigene Hof-Datei braucht, bzw. warum "die Anzeige auf Bus XY falsch is"...


    Schönen Abend noch,


    Busfanat

  • Guten Morgen an alle Experten im Punkt HOF-Datei und Mapbau,


    ich hätte da mal eine frage, bezüglich der automatischen Auswahl der Hof-Datei bei der Busauswahl.
    Welcher Eintrag bewirkt, das die Busse eine Hof-Datei automatisch zu der passenden Karte laden?


    Bin gerade am herumexperimentieren, aber ich finde einfach die Lösung nicht. Bei Berlin-Spandau und Bad Kinzau zum Beispiel, funktioniert das, bei Felsheim aber nicht???


    Ich hoffe, ich hab mich leidlich verständlich ausgedrückt und hoffe auf eine Antwort.


    mfg


    Daniel

  • öffne die Glogal.cfg und unter [standarddepot] die Hofdatei reinschreiben!


    Danke Busfahrer Andi, für Deine schnelle Antwort.

    :)


    Allerdings ist Dein Tipp genau das, was ich als erstes ausprobiert habe.


    Um mal zu verdeutlichen, was ich bisher alles ausprobiert habe:


    - Map-Ordner Name = Felsheim


    - Global.cfg angepasst:


    [name]
    Felsheim


    [friendlyname]
    Felsheim


    [standarddepot]
    Felsheim


    - AI-Liste angepasst:


    [aigroup_depot]
    Solo
    Felsheim


    [aigroup_depot]
    Gelenk
    Felsheim


    - HOF-Dateiname = Felsheim


    Und jetzt fällt mir nix mehr ein, ausser das es auf Baumgarten 100% funktioniert, auf Bad Kinzau wars wohl nur Zufall, da die Hof-Datei alphabetisch die erste in der Reihe ist.


    mfg


    Daniel

  • Ersetzte Felsheim durch "Hof Felsheim"


    Leider keine Änderung, so stand es von Anfang an drin.
    Noch andere Vorschläge?


    Edit: nur um das nochmal zu verdeutlichen, Felsheim dient hier nur als Beispiel und es "stört" mich ja auch nicht direkt, das das nicht automatisch funktioniert, sondern ich möchte nur wissen, warum es nicht funktioniert.

    ^^


    mfg


    Daniel

  • Ich grabe diesen Thread hier einfach mal aus. Ich habe zur universellen Hofdatei ein paar Fragen. Ich selbst ändere an Scripts ungerne Sachen, jedoch würde ich meine Hofdatei dennoch für andere "universell" machen. Meine Frage: Wie Funktionieren die Strings von Ikarus 280, LU200 oder BUSE? Von den ersten beiden habe ich keine Ahnung und vom BUSE-System dachte ich immer, es wäre diese Sache mit den "0 = kein Pixel" und "1 = Pixel", oder so ähnlich. Hier mal ein Bild:


    (klicken für volle Auflösung)


    Welchen Stringcount muss ich eigentlich angeben?