= Englisch [EN], 
= Deutsch [DE], 
= Französisch [FR]. Wenn du die angegebene Sprache nicht beherrschst, schreibe auf Englisch! 3 Fragen hab ich noch: Die global.cfg datein die ihr Mitliefert, sind die auch so ausgelegt wie die Batch-Datei? Weil ich möchte gerne das Ticket-Pack ändern und halt auch das DavidM Moneypack ändern, ist das möglich?
Ich habe es so gelöst, daß ich mein Wunsch - Moneypack einfach in jede der vier verfügbaren global Dateien eingetragen habe. Mit copy und Paste kein Problem und es funktioniert sogar.
Ich habe nochmal eine, respektive zwei Verständnisfragen. Bei den Umlauflisten steht bei einigen Fahrten hinter der Fahrzeugart noch "(SN)" Was bedeutet dies?
Wenn ich per Batchdatei die Fahrgastzahlen anpasse und dann auch aus derselben Batchdatei OMSI starte, bei der nächsten OMSIsitzung aber vergesse, dies zu tun, sondern OMSI "normal" starte, benutzt OMSI dann die zuletzt gewählte global.cfg oder die Standard global.cfg und wenn ja, welche ist dies? Und dann noch: wenn ich mir die Batchdatei auf den Desktop lege, funktioniert sie dann immer noch, oder muß sie aus ihrem Mapunterordner heraus gestartet werden?
Im übrigen möchte ich hier gerne einmal sagen, daß Ahlheim 5 die vergessene Ahlheimsucht bei mir wieder entfacht hat. Nachdem die V4 und ich nie so richtig Freunde wurden, bin ich nun wieder begeistert in Ahlheim unterwegs, seit der 5.1 auch fehlerfrei. Vielen Dank also für die Mühe, Arbeit und die Bereitschaft, all das mit der Community zu teilen. Selbstverständlich ist das nicht.
Wahrscheinlich habe ich die Lösung überlesen, aber ich habe immer noch keine Umläufe zur Auswahl, die dem Betriebshof Eichenhoehe zugeordnet sind. Die Map läuft tatsächlich wie frisch geölt, nur eben die Eichenhoehener Fahrplanfahrten lassen sich nicht aufrufen.
Diese Logfile ist von gestern abend, ich wollte zunächst die 135 fahren, ging nicht und bin dann nach BEtr. Kranenburg gewechselt, um die 149 unsicher zu machen.
LG
Meine Güte, muß ich dann schon wieder OMSI spielen, um eine Logfile zu erstellen??? Also gut....
So, ich muß mich korrigieren, bereits seit dem Update auf 5.01 kann ich keine Eichenhoehener Fahrpläne mehr auswählen. Deshalb habe ich die 5.00 wieder aufgespielt (ja den anderen Mapordner vorher gelöscht) Diese Logfile ist also mit der V 5.0 entstanden. Der Map translate Fehler taucht hier zum ersten Mal nach 24 Minuten Fahrzeit auf der Linie 132 nach Start an der FH auf, also ungefähr Kuhlmannsfeld, Campus Hayerstr, Rhenaniabad.
So, Logfile, Teil 2 ist nun die Fortsetzung der Fahrt, nachdem OMSI im Pausenmodus abgeschmiert ist. (Das hat nichts mit der Map zu tun, das hat OMSI immer schon gemacht, wenn ihm langweilig wurde) Der map translate Fehler taucht hier nach ca 5 Minuten Fahrzeitzum ersten Mal wieder auf, nachdem ich auf der 132 am Abteigarten die Fahrt wieder aufgenommen hatte, also ca. Paradestraße, Am Kreuzfeld.
Meine Güte, muß ich dann schon wieder OMSI spielen, um eine Logfile zu erstellen??? Also gut.... 
Das ist schonmal eine gute Eingrenzung.
Tritt bei den anderen der Fehler Error: Fehler bei Bereichsprüfung: map.translate ebenfalls im Bereich des Eichenhöher Betriebshofes auf?
Ich habe das auch am und um den Bf. Eichenhoehe. Es führt zwar nicht zum Absturz, aber zu einem temporären Freeze. Je nach gefahrener Linie taucht die Zeile mit dem map.translate Fehler zwischen 50 und 100 mal in der Logfile auf.
Ebenfalls sind seit dem 5.02 Update / Fix keine Eichenhoeher Fahrpläne mehr auswählbar.
Gruß Achim
Ich meine mich erinnern zu können, daß es so etwas mal zumindest für die erste Generation der HH Busse gab und ich glaube auch für das 3gen. Das war dann wohl im OOF; ob die irgendwann einmal hierher immigriert sind, weiß ich grad nicht
Du benutzt den 4 GB Patch?
Dann setze ich mich mal ans Basteln, dankeschön IREgio612
Hi Perotinus, ich habe die Situation, daß der AFR auf einer anderen Map eingesetzt (bei allen Busmodellen aus Thüringen) den Standardfahrschein nicht korrekt anzeigt. Also den Ticketnamen schon, aber beim Preis wird ein Cent zu wenig angezeigt. Als Beispiel nehme ich hier mal Lemmental-Neuenbreid. Der Standardfahrschein schlägt mit €4,70 zu Buche, in der AFR LED Anzeige wird aber €4,69 angezeigt. Das ist nur beim Standardfahrschein der Fall, alle anderen werden korrekt angezeigt. Der Verkauf ist nicht beeinträchtigt, niemand beschwert sich über einen Cent Rückgeld zu wenig oder ein falsches Ticket.
Nochmal nachgefragt, gibt es hierfür eine Workaroundlösung, wie z.B. eine Wertänderung in der .osc oder welcher Script auch immer dafür verantwortlich ist?
Hi Perotinus, ich habe die Situation, daß der AFR auf einer anderen Map eingesetzt (bei allen Busmodellen aus Thüringen) den Standardfahrschein nicht korrekt anzeigt. Also den Ticketnamen schon, aber beim Preis wird ein Cent zu wenig angezeigt. Als Beispiel nehme ich hier mal Lemmental-Neuenbreid. Der Standardfahrschein schlägt mit €4,70 zu Buche, in der AFR LED Anzeige wird aber €4,69 angezeigt. Das ist nur beim Standardfahrschein der Fall, alle anderen werden korrekt angezeigt. Der Verkauf ist nicht beeinträchtigt, niemand beschwert sich über einen Cent Rückgeld zu wenig oder ein falsches Ticket.
Wahnsinn! Klasse! Es scheint ein wenig ruhrgebietisch angehaucht zu sein, damit meine ich das echte Ruhrgebiet, nicht eine Map gleichen Namens.
Hai, Perotinus,
wäre es theoretisch möglich, diese "neue" Version des AFR auch in deine älteren Fahrzeuge einzubauen, auszutauschen? Ich frage NICHT, ob du das tust, sondern ob es möglich ist 
Ich kann berichten, daß es funktioniert!
Alles anzeigenHabs probiert: Leute steigen hinten nur aus, wenn vordere Türe auch geöffnet wird.
Das ist auch kein Wunder wenn ich mir den Script door_213.osc anschaue:
Code(L.L.door_1) 0.9 > (L.L.dopka_pos) 0.3 < && (S.L.PAX_Entry0_Open) (S.L.PAX_Exit0_Open) (L.L.door_2) 0.9 > (S.L.PAX_Entry1_Open) (S.L.PAX_Exit1_Open)Der erste Exit Eintrag in der Passangercabin steuert die Tür 1 ob der freigegeben ist oder nicht.
Entferne im gezeigten Scriptteil (Dies kommt nur einmal vor) das (S.L.PAX_Exit0_Open) und füge an den PAX_Exit1_Open an
Code(L.L.door_1) 0.9 > (L.L.dopka_pos) 0.3 < && (S.L.PAX_Entry0_Open) (L.L.door_2) 0.9 > (S.L.PAX_Entry1_Open) (S.L.PAX_Exit0_Open) (S.L.PAX_Exit1_Open)
Ganz wichtig: Mache vor der Änderung einen Sicherungskopie und am besten auch nach der Änderung!
Kurz mal nachgefragt, Pro fragte ja nach der Situation beim 215H. Deine hervorragende Erklärung bezieht sich allerdings auf die door_213.osc. Bei der door_215.osc sehen diese beiden Zeilen geringfügig anders aus. Kann ich die dann dort trotzdem so abändern wie von dir beschrieben?
In der door_215.osc lauten diese Zeilen wie folgt:
(L.L.door_1) 0.9 > (L.L.dopka_pos) 0.3 < && (S.L.PAX_Entry0_Open) (S.L.PAX_Exit0_Open)
(L.L.door_2) 0.9 > (L.L.dopka_2_pos) 0.3 > && (S.L.PAX_Entry1_Open) (S.L.PAX_Exit1_Open)
Du mußt den hinteren [exit] definieren. Standardmäßig ist 0 eingetragen, d.h. sie steigen vorne aus. Trag mal 17 dort ein.
SIe heißt "passengercabin_221_main.cfg" und "passengercabin_221_trail.cfg" Sie befinden sich im Modelordner. Mach auf jeden Fall backup Kopien, bevor du die Dateien mit Hilfe eines Texteditors veränderst.
Den Einstieg an allen Türen in der passenger.cfg herausnehmen. Dann steigen alle Fahrgäste nur noch vorne ein
Hallo Perotinus, ich habe zwei Fragen zum AFR und zwar erstens ist es theoretisch möglich den jetzigen Drucker in deinen älteren Bussen zu verwenden (gegen den dort eingebauten auszutauschen)? Und zweitens kommt es mir so vor, und das ist rein subjektiv, daß die Schrift des AFR, also die Displayschrift etwas zu groß geraten ist.
Genieße deinen Urlaub!
Nein, es geht nur das eine Tor auf.
Also auch das rückwärtige gegenüber des zu öffnenden läßt sich nicht öffnen? (Einrückfahrt)
