Beiträge von wurstbrot

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!

    Es ist immer blöd, wenn du an einer Hst vorbeifährst, dann die Wendeschleife hast, bevor du wirklich anhältst, weil OMSI (siehe roter Text) dann denkt, du hast die Hst. angefahren und fährst gerade schon zur nächsten, weil du dich dem glaub 60m Radius der Hst genähert hast und ihn wieder verlassen hast.

    Ja, das sind dann so Stellen mit Brücken wo man zum Beispiel eine Kleeblatt-Auf/Abfahrt nimmt. Da kommt kein automatisches System mit klar. Daher hab ich immer gerne wenn ich kurz vorher auf manuell schalten kann. Ich weiss aber immer noch nicht wie ich bei der IVU manuell mit Ansage weiter schalten kann. Diesen Modus hätte ich nämlich auch gerne für Pendelverkehre oder besonders lange Haltestellenabstände. Wenn ich die Haltestelle in der IVU anklicke und sie markiert erscheint bleibt das System nur an der Haltestelle stehen, ich kann nicht manuell schalten sondern dann nur das automatische System wieder einschalten.

    Moin!

    Mir ist seit längerem aufgefallen dass ich immer wieder an den gleichen Ampeln beo rot stehe und an anderen Ampeln habe ich grün. Es sind immer die gleichen Ampeln und mir kommt es vor als wäre das Timing auch immer gleich. Oder sagen wir mal zu 90%. Das merke ich wenn ich mich an gewisse Ampeln nähere und schon genau weiss dass sie gleich auf rot oder grün springen. Ich erkläre mir das damit, dass ich annehme dass bei Annäherung an eine Kachel die dortigen Ampelphasen starten und durchlaufen, und somit es dann immer gleich ist zu welcher Phase man an der Kreuzung steht. Wenn dem aber wirklich so ist dann wäre es doch für den Mapbauer möglich eine Grünphase zu programmieren. Es heißt aber dass dies nicht ohne weiteres geht, also kann meine Annahme nicht stimmen?


    Ich habe auf einer Karte entlang einer Straße sehr unvorteilhafte Ampeln. Verbaut sind Busdrivers Spline-Ampeln, und die auszutauschen ist so eine Sache. Daher lasse ich es lieber und bau eh die ganze Kreuzung irgendwann um. Hätte da aber dann schon entweder gerne etwas mehr Zufall oder eine Pseudo-Grünphase da in der Realität da tatsächlich der Bus Vorrang kriegt und ich mit unvorteilhaften Ampeln locker mal 4 Min Verspätung bekomme.


    im Moment brauche ich keien konkreten Script-Tipps sondern nur allgemeine Infos.

    Hier haste meine Krummenaab-Hofdatei mit Datenrouten für die DB-Linie 6295.

    Wunderbar, danke. nun hat es wohl funktioniert. Der Fehler war dass mir in der Hof die beiden Zahlenkolonnen mit 1-60 gefehlt haben bzw. Busstop 1, 2 usw. Musste mir das aber auf "altmodisch" erstmal umschreiben und stellte dann fest dass ich Leerzeichen für 2 weitere Strings machen muss:


    Dachte immer dass das nächste [addbusstop] das dann auflöst, aber nein... Komischerweise ging es bei den Umlaufeinträgen ohne Leerzeichen wenn eine Seite mal weniger als 4 Einträge hatte.


    das mit dem Fortschalten ist mal wieder ein Beispiel, dass es leider nicht immer jedem passt. :)


    Ich behelfe mich damit, dass ich kurz vor Fahrtende die Pax Info ausschalte (hat das wenigstens mal einen Sinn, dass mich die Tussi nicht volllabert von wegen nächster Halt ;) ), dann in der Pause neue Route rein, Hst. berichtigen und Pax Info wieder an.


    Als ich vor Jahren mich noch teils mit der Mainzer Ibox "rumgeärgert" hatte, habe ich die .hof-Routen angepasst, dass die zum Fahrplan passen, Sprich Starthaltestelle ggf. doppelt, wenn es einen Terminus gibt, weil sonst die Ansagen am Ende der Route nicht mehr gepasst haben. Die Vorletzte wurde als Fehler angezeigt, weil sie natürlich nicht mit dem Suffix _#terminus existiert haben und dann war Ende.

    Ich wundere mich dass die Systeme das alles so unterschiedlich handhaben. Im Grunde denk ich mir gibt es zwei Möglichkeiten: stur nach den im Fahrplan hinterlegten Daten gehen (Aachener und Mainzer IBOX) oder Stur nach der Route in der Hof, ganz egal was der Fahrplan sagt. Letztes ist mir eigentlich lieber, verstehe aber wenn es wegen Fahrplandaten eben nicht so war. Diese IVU Box ist glaub ich doch auch völlig unabhängig vom Fahrplan? Daher doch das mit den Datenrouten... Aber so ganz unabhängig wieder auch nicht, da sie genau wie alle anderen Systeme auch an manchen Stellen spinnt wie zum Beispiel Aachen vor dem Campus, Mainz ZDF+Landtag. Daher würde ich da an so stellen gerne auf manuell schalten, aber die Trigger für das manuelle Auslösen der Ansagen müsste ich noch rausfinden und eintragen oder irgendwie auf den üblichen Trigger umleiten. Mein Kupplungspedal langweilt sich;-D


    Edit: geht auch wenn du die TextTexturen von 101-104 drinne hast, für die Datenrouten und Uhrzeiten neben der HST

    Sind eigentlich 105. Die letzten beiden haben fälschlicherweise beide die 104.

    Das liegt daran, dass viele Fahrpläne zwei Starthaltestellen in OMSI haben, die Hofdatei jedoch nur eine Starthaltestelle.

    Wenn man die nächste Fahrt auswählt, springt es auch sofort auf die zweite Haltestelle. Ist bisschen doof gelöst aber ich hoffe doch kein Beinbruch. Sieh es als realistischen Programmierfehler an... :dont_see:

    Das ist Richtig, und bei mir ist das in der einen Richtung so, und in der anderen so. Die Frage wäre nun wie verfahre ich damit am Besten für Routen mit a) Pausenhaltestelle=Starthaltestelle und b) Pause und Start getrennt? Fall a) in der Hof eine Hst zum Anfang und bei b) eben zwei? Ich meine ich hätte diese Variante auch versucht.


    Zu den Fahrzeiten:

    Könnte mir jemand zum Testen irgendeine HOF Datei hochladen, wo bei ihm das mit den Fahrzeiten funktioniert? Das würde sicher helfen den Fehler zu finden.

    Die experimentelle Version merkt sich die Seite des Umlaufs, das ist gut.


    Zum Bug mit den gleichen Fahrzeiten:

    Das muss irgendwas im Script sein und ist kein Darstellungsfehler. Auch wenn die Texttextur 105 als 104 in der Vorlage angegeben war hat eine Korrektur nichts geändert. Die Verspätungsanzeige zieht zur Berechnung die falsche Uhrzeit heran, am Schluss einer Tour hat man dann beispielsweise +60 oder sowas. Sie rechnet also mit einem falschen Wert, nämlich Startzeit gemäß Hof-Eintrag minus eine Minute für alle Haltestellen. Und wenns nicht direkt im Script passiert dann irgendwo beim Auslesen der Hof... Auf jeden Fall sehr sehr seltsam.


    Was ganz anderes:

    Es kam öfter vor dass die Haltestellen gerade am Anfang einer Rozte zu schnell fortgeschaltet wurden. Da kam nach Abfahrt direkt Ansage für Haltestelle 2 und dann gleich Haltestelle 3. In einem anderen Fall wurde beim Wechsel der Route an der Endhaltestelle direkt auf Haltestelle 1 gesprungen und diese Angesagt. Im letzten Fall ist Endhaltestelle=Starthaltestelle ohne Betriebshaltestelle. Der erste Fall startet an der Betriebshaltestelle, es spielt aber irgendwie keine Rolle ob in der Hof quasi die erste Haltestelle doppelt eingetragen ist oder nicht.

    Hmm... kurios. Ich hätte jetzt gesagt, ein Fehler bei den TextTexturen in der Modelldatei.

    Bei der Fahrt vorher hat er aber die Zeit auch auf die gleiche Weise falsch angezeigt 15:21 statt 15:22 und das für alle Haltestellen. Ich denke wäre was bei den TT falsch dann gäbe es Artefakte oder garnix.


    Vielleicht hier was falsch?

    Also die 1 oder die 9068 danach?


    Selbes übrigens im C2:


    Edit:
    Hab nun gesehen dass in der Vorlage von der experimentellen Version die Texttextur 104 doppelt ist, und die letzte wohl 105 sein müsste. Dennoch bringt eine Korrektur in den Model-Dateien garnix, auch wenn die 105 tatsächlich aufgerufen wird bei den Modelleinträgen.

    Bei mir erkennt er die Datenroute, zeigt aber die gleichen Zeiten für jede Haltestelle an. Woran könnte das liegen?`

    Die Abfahrt an erster Haltestelle ist auch übrigens 16:47 und nicht 16:46.




    Hier der Part in der Hof:


    Bisschen blöd isz auch dass ich für verschiedene Fahrtzeitprofile die Routen splitten müsste.

    Wenn ich mich nicht irre müssen es beim Umlauf Zahlen sein. Wenn es also Samstags oder Sonntags Umläufe mit gleicher Nummer gibt muss man mit unterschiedlichen Umlaufnummern arbeiten. Ich zum Beispiel hänge dann eine 1 für Mo-Fr, 6 für Samstag und 7 für Sonntag an. Ruf ich also Sonntags Linie 123 Umlauf 1 ein weiss ich automatisch dass ich die Umlaufnummer 12317 eintippen muss. Du kannst Dir aber ein anderes System ausdenken.

    Ich hab jetzt die "normale" Version in zwei Bustypen verbaut, nicht die experimentelle. Verstehe ich das Richtig dass ich die experimentelle nutzen muss um Datenrouten und somit Fahrzeiten darstellen zu können? Ich hab übrigens genau 100 Texttexture.-Einträge, irgendwo stand dass es 104 sein müssen. Was müsste ich beim Update auf Experimentell beachten ausser dem Scripttausch: Komplett die Modelldatei-Einträge auch tauschen?


    Ich nehme deshalb ab dass ich updaten müsste weil das Handbuch der normalen Version sich total ausschweigt zu den Datenrouten und das entsprechende Kapitel erst in der experimentellen Version im Handbuch steht.


    Dann würde mich noch interessieren ob die experimentelle Version eventuell sich die aktuelle Seite des Umlaufs merkt? Bei jeder Endstelle bin ich nämlich wenn der Kurs beendet wurde auf Seite 1. Es wäre toll wenn ich dann auf der Seite landen würde wo ich vorher schon war um da die Fahrt auszuwählen. Ggf könnte man das auch reinmodden?


    Und wenn wir schon beim modden sind: es hat doch bestimmt schon jemand von Euch beim benutzen der Pause-Funktion die Matrix dazu gebracht einen speziellen Terminus für die Pause aufzurufen und nach Beenden der Pause zur letzt angezeigten Matrix wieder zurück zu kehren, oder?


    Für die Sonderansagen hätte ich gerne dass je nach Mandant die Textur mit der Auswahl getauscht wird und ggf ein anderes Verzeichnis mit den Sounds zugegriffen wird, beispielsweise benannt nach Mandanten. Jemand sowas schon gemacht?


    Ehrlich gesagt hätte ich das Ticketauswahl-Fenster auch grafisch nach Mandanten gelöst. Die Namen aus den Ticketpacks sind für die Quadrate dort dann doch meist ungünstig, während sie bei der Detailansicht dann wieder perfekt sind.

    Danke. Ich vermute dass die meisten Busse auf den M&R Scripten dazu beruhen, weshalb auch der Heizungs-/Standheizungs Trigger oft in Bussen funktionieren die entsprechende Schalter garnicht haben. Peinlich wird es dann wenn man in diesen Bussen NUR so eine vernünftige Temperatur hinkriegt;-D


    Ich hab jetzt erstmal nur in der Const der Mainzer LC's rumgepfuscht und ein halbwegs brauchbares Ergebnis erzielt. Da gäbe es die Besonderheit dass diese eine Fahrer-Klima haben, der Fahrgastraum aber klassisch beheizt wird. Fahrerklima wird wohl über das Frontheizgerät simuliert und ist somit auch eher eine Heizung als Klima, der Fahrgastraum lässt sich nur über den normalen Heizungstrigger beheizen mit den Stufen ein/aus, der Bus selber hat dafür keine bedienbare Taste;-D Dafür ist der Standheizungstrigger mit einem Kippschalter verknüpft der eigentlich wohl eher die Fahrgastraumheizung steuern müsste und zusätzlich wohl noch "falschrum" konfiguriert ist. Ich merke aber irgendwie auch dadurch keinen Standheizungs-Effekt.


    Ominös ist aber auch das hintere linke Fenster im O405(G) welches den Bus in Nullkommanix abkühlt, während andere Fenster diesen Effekt nicht haben. Jemand hatte erwähnt dass im M&R NL/NG ein ähnlicher Effekt da ist, hab ich aber selber nicht geprüft.

    Beim Umbau einiger MX200 C2's, was bestens und reibungslos geklappt hat fiel mir auf dass die IVU Ticketbox bei diesem Fahrzeug durchaus in der KI Sinn machen könnte. Wenn ich mir angucke wie viel tausend Zeilen ich in der Model-Datei gelöscht habe und durch viel weniger ersetzt habe könnte das sehr wohl einen positiven Impact haben. Bei speziellen ai-Bussen dann aber halt ordentlich entscriptet.


    Btw: Hab nun die Umläufe zum Teil eingetragen. Aber wie wird rund um 0 Uhr verfahren beim Tageswechsel: 0000 und 0100 oder 2400 und 2500?

    Es war eine KI-Linie die tatsächlich exakt den Weg einer anderen KI Linie fährt, sie gabeln sich quasi außerhalb der Karte erst auf. Das "falsche" Zielschild war aber nicht aus der anderen Linie sondern immer das erste aus der Hof-Datei des Busses. Das sind dann meist Betriebsfahrten. Beim falschen Ziel wo Hinweg und Rückweg vertauscht waren war es dann die gleiche Linie. Total seltsam, vor allem weil mit T&T es anscheinend klappt.


    In Spandau hatte ich bevor ich auf T&T umgestellt hatte am Reimerweg wartend oft eine 92 Richtung Spandau fahren gesehen mit dem Ziel "Stadtgrenze". Oft getaktet zur gleichen Minute, also wohl auch kein Phantombus mit +4000. Dieser despawnte dann immer nach der Kreuzung am Reimerweg. Da war meine Vermutung dass mit StnLinks da die Pause irgendwie klappt und der Bus quasi noch auf dem Hinweg ist, aber dort die Pause übersprungen hat. Mit T&T war das dann erledigt. Vielleicht ist das auch was ähnliches bei mir.

    Moin!

    Ich wollte mal fragen ob jemand auch schon mal beobachtet hat bei Verwendung von StnLinks und Typ 2 Trips dass zum Teil die Zielanzeigen auf den Bussen falsch sind? Ich stelle ja eh nach Möglichkeit alles auf das klassische Tracks & Trips System um, aber bisher hatte das andere Gründe. Nun zur Beobachtung: ich hab bei einer Linie permanent gesehen dass diese einfach nur eines der ersten Einträge aus der Hofdatei schilderte statt dem in dem Trip festgelegten Ziel. Das war dann meist je nach Bus ein Allexit-Ziel, weil die am Anfang sind. Ich glaube das erst beste Ziel aus der Hof war es immer. Ich hatte dann doppelt und dreifach abgeglichen ob die Ziele aus der Hof mit denen in der Trip-Datei exakt stimmen, und ja, es war zu 100 Prozent richtig. Zusätzlich gab es Busse die in Richtung B das Ziel aus Richtung A schilderten. Auch das hab ich doppelt und dreifach geprüft und konnte keinen Fehler feststellen. Nun hab ich die betroffene Linie auf T&T umgestellt und es scheint nun korrekt zu funktionieren.


    Würde gerne wissen ob jemand dieses Verhalten bei StnLinks auch bestätigen kann. Bitte keine Posts a la StnLinks sind eh Mist, es geht darum zu prüfen ob das damit was zu tun hat oder nicht.

    im script musst du gar nix ändern, nur in der Modell.cfg bei der Text Textur der Innenanzeige statt der vorherigen Variable IVU_freier_Port_01 eintragen

    Das hab ich irgendwie überlesen, aber derweil auch über die Suche hier irgendwie rausgekriegt;-) Habs so gemacht, kriege nun immerhin die Liniennummer angezeigt, aber nicht die Haltestellen:



    Hier Test mit normelem Grundorf-Hof und aktivem Fahrplan. So wie ich das Script verstehe müsste auch Haltestelle und "Wagen hält" angezeigt werden, vermutlich im Wechsel.


    Edit: Jetzt klappt es wohl wie es soll beim aktiven Fahrplan und einer Runde;-)


    Aber mal trotzdem noch ne Frage: wie SOLL sich denn die Anzeige verhalten wenn man als Linie zum Beispiel "7610" eingibt? Ich würde erwarten dass dann "76E" erscheint. Es erscheint aber "7610". Wäre das nun eine Sache der IVU oder meiner K++ Matrix?