Bugs beim NG in der KI

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.
  • Neben dem heute erwähnten Bug bezüglich des "dunkeleren" Nachläufers des NG habe ich noch paar Dinge gefunden die ich hier noch nicht gelesen habe. Sie betreffen des Betriebs des NG als KI-Fahrzeug:


    1. Steckschild-Ziele:
    Dies kann auch andere Busse betreffen, aufgefallen ist es mir aber beim NG. Fährt ein NG als KI mit Steckschild eine Endstelle an und macht sich dann von dort aus auf den Rückweg, so wechselt er zwar optisch korrekt das Steckschild, nicht jedoch das interne Ziel. In der Statusleiste sieht man dann weiterhin das Ziel was er vorher hatte, somit nimmt nimmt er auch auf dem Rückweg keine Fahrgäste mit.


    2. KI-Busse nicht "aufgepumpt":
    Die KI-NG's fahren anscheinend mit leeren Druckbehältern durch die Gegend. Die Busse sind in dem Zustand wie ein NG bevor man zum ersten Mal die Elektrik einschaltet (bei der sich der Bus dann direkt "hochbockt"). Das sieht sehr eigenartig aus und sollte in den KI-Skripten angepasst werden. Kann auch den NL betreffen, nur fällt es dort mangels Gelenk nicht so krass auf.


    3. Anfahren von Haltestellen als KI:
    Da die Anlegeverhalten-Werte des Haltestellenwürfel anscheinend im Zusammenhang mit den Stationlinks oder grundsätzlich nicht übernommen werden (siehe auch: OMSI2: verschiedene Probleme rund um U Ruhleben Beitrag 9), fährt der NG wie ein Doppeldecker oder NL die Haltestellen an, was an den Endstellen zu großen Problemen führen kann, indem der Nachläufer meistens die Straße blockiert. Neben einer Korrektur des Anlegeverhaltens der Haltestellenwürfel sollte man beim Gelenkbus auch in den Anfahr-Skripten seine Länge berücksichtigen. Zur Zeit verhält er sich so, als wär sein Mittelpunkt etwa in der Mitte des Vorderwagens. Der NG müsste aber um Haltestellen korrekt anzufahren deutlich früher den Pfad verlassen und einlenken als ein NL oder Doppeldecker.


    4. Innenansichten:
    Wechselt man die Position der Passagier-Innenansicht, "vergisst" diese OMSI häufig. Wenn ich also mir eine schöne Position aussuche, dann in die Fahrersicht zurückwechsele, dann wird die Passagieransicht oft auf Standard zurückgesetzt. Allerdings nicht immer...


    to be continued (hoffentlich nicht;-)

  • Neben einer Korrektur des Anlegeverhaltens der Haltestellenwürfel sollte man beim Gelenkbus auch in den Anfahr-Skripten seine Länge berücksichtigen. Zur Zeit verhält er sich so, als wär sein Mittelpunkt etwa in der Mitte des Vorderwagens. Der NG müsste aber um Haltestellen korrekt anzufahren deutlich früher den Pfad verlassen und einlenken als ein NL oder Doppeldecker.

    Da möchte ich widersprechen. Die Busse dürfen ihre Länge nicht berücksichtigen! Die DockDist beschreibt den vom Erbauer gewünschten Einschwenkpunkt. Ist dieser aber statt aus "Schönheit" aus "Sachzwängen" hergeleitet, z. B. parkende Autos vor der Haltestelle, darf sich der Bus nicht über den Erbauerwillen hinweg setzen. Die 3 Meter machen zwar keinen riesigen Unterschied, aber rein logisch gesehen wäre es das falsche Verfahren.

  • Im Moment scheint die DockDist gar nicht zu funktionieren. Angenommen sie täte das wie in OMSI 1, dann beschreibt der Wert sowieso nur einen allgemeinen für alle Fahrzeuge gültigen Wert. Wäre aber schonmal besser als der aktuelle Zustand. Wenn dann noch die KI eines Gelenkbusses ihre Länge mitberücksichtigen würde, dann hätte der Mapersteller doch ausreichend Möglichkeiten. Denn er weiß ja ob eine Haltestelle überhaupt von Gelenkbussen angefahren wird oder nicht, und dann kann er einersteits das Anlegeverhalten mit der (funktionierenden) DockDist trimmen, andererseits berücksichtigen ob dadurch vielleicht Parkplätze beeinträchtigt werden würden oder nicht und diese entsprechend einrichten. Würde also beides funktionieren, würden kurze und lange Busse den eingetragenen Abstand berücksichtigen, und ihre Gesamtlänge, ein langer also etwas früher einlenken als ein kurzer.

  • Zitat

    Wenn dann noch die KI eines Gelenkbusses ihre Länge mitberücksichtigen würde, dann hätte der Mapersteller doch ausreichend Möglichkeiten. Denn er weiß ja ob eine Haltestelle überhaupt von Gelenkbussen angefahren wird oder nicht, und dann kann er einersteits das Anlegeverhalten mit der (funktionierenden) DockDist trimmen, andererseits berücksichtigen ob dadurch vielleicht Parkplätze beeinträchtigt werden würden oder nicht und diese entsprechend einrichten.


    Das setzt aber voraus, dass man in 2011 die DockDists schon auf einen Gelenkbuseinsatz nach deinen Vorstellungen ausgelegt hat. Ansonsten passt deine Argumentation nur für neue Maps. Man hat ja nichts von der Programmierarbeit, wenn es bei der Hälfte der alten Maps auf die eine oder die andere Art nicht perfekt funktioniert.

  • Nein, die bereits ausgetüftelten DockDist-Werte würden doch weiterhin genauso funktionieren wenn OMSI 2 ihre Werte annehmen würde (kann sein dass es das tut wenn man NICHT mit Stationlinks arbeitet...). Das einzige was dann zu berücksichtigen wäre, dass eben Gelenkbusse früher einlenken würden, und man somit eventuell Parkplätze etc einkürzen müsste.


    Gelenkbusse einfach so nun auf OMSI 1 Maps fahren zu lassen dürfte meistens so oder so in die Hose gehen. Man kann natürlich auch Glück haben, aber ich denke man käme um Anpassungen eh nicht herum. Es wird sicher haufenweise Stellen geben wo es sonst zum Chaos käme wenn man einfach nur die Map übernimmt. Weiss nicht ob Du das bei Deiner Map schon ausprobiert hast, aber ich nehme mal an dass beim Einsatz von Gelenkbussen in der KI auch da die Probleme vorprogrammiert wären, Du also sowieso etwas Hand anlegen müsstest wenn Du Gelenkbusse zulassen wolltest. Und ich glaub mit einerseits Korrektur des Bugs bei DockDist und dem früheren Einlenken der Gelenkbusse würdest Du viel weniger Arbeit haben.


    Und wenn es noch eine bessere und praktischere Lösung gäbe... Um so besser.