Beiträge von wurstbrot

Schlecht funktionierende Heizungen und Klimaanlagen sind in OMSI leider Standard, sowohl bei Payware als auch Freeware. Hauptsache man kann per Modmenü eine Klimaanlage aufs Dach klatschen, ob sie korrekt funktioniert ist leider egal. Dabei unterscheiden sich Klimaanlagen und Heizungen in Bedienung und Funktion grundverschieden. Hab ich noch nie verstanden warum hier so wenig Priorität in der Entwicklung ist. Das geht soweit dass wenn man seine verknüpften Tasten für Heizung oder Stadtheizung drückt dann eben diese in den Bussen losheult obwohl es kein Bedienelement dafür gibt. Im Falle vom Stadtbus-C2 ist das aber glaub ich nicht der Fall, da musste ich auch bei 0 Grad ohne fahren weil sich der Bus einfach nicht aufheizen ließ. Ich wünsche mir hier grundsätzlich dass man sich dem Thema Temperatur bei jeglichen Bussen annimmt und nicht darauf hofft dass der User zum Beispiel mit AUXI sich die gewünschte Temperatur ercheatet. Hier beim C2 wäre es angebracht gewesen mit Klima eine Automatik zu verbauen, ohne eben ein klassisches Heizungsbedienteil für den Fahrer und entsprechende Schalter für den Fahrgastraum. Das kann ja ruhig dauern den Bus warm zu kriegen. Aber dann bei Türöffnung bitte nicht mit 1 Grad pro Sekunde abkühlen

Ich weiss garnicht ob die Cooper Matrix überhaupt taugen würde. Müsste ich mir mal anschauen. K++ wird halt von nahezu allen anderen Bussen genutzt die ich gerade einsetze, das hätte auch den Vorteil einer Hofdatei.

Ich hab beim Mainzer MAN LC G die K++ aus einem Mod für den Solo eingebaut, das ging recht einfach. Aber da musste ich nur die Position der Heckmatrix anpassen, sonst nix. Beim Stadtbus müsste ich glaub ich die Objekte neu erstellen und entsprechend texturieren, das kann ich noch nicht.

Ich hab jetzt mal in den Trips die Ankunftszeit auf Abfahrzeit gesetzt. Damit haben anscheinend die KI-MANs weniger Probleme. Da ist zumindest bei den zwei drei Versuchen keiner zu früh abgefahren.

Hat jemand eigentlich die K++ Matrix in den Bus eingebaut? Da ich keine finde glaube ich fast dass es da irgendwelche Probleme gibt.

Natürlich, das muss man schon berücksichtigen. Wäre ja auch ohne AUXI nicht anders dass an Haltestellen ohne zweite Peoplebox niemals mehr als 7 da wären. Oder wenn man mehrere Boxen hat aber einige aus ominösen OMSI-Gründen eben nicht funktionieren Und Minuswerte in den Haltestellen werden natürlich auch (leider) multipliziert;-)

Nein, 100% ist die Basis, also gleich 1.000 in der global. 150% wäre wie 1.500 in der global wenn dort für den Zeitraum 1.000 eingetragen ist. Kannst ja in Grundorf an einer Haltestelle testen: Trag dort 10 Fahrgäste min/max ein und teste es. Wichtig ist halt dass sich das mit dem Wert in der Global multipliziert, also dort auf besten immer auf 1.000 lassen und über AUXI regeln.

2005 spielt das laut Text. Es wird wohl Busse wie damals in HH T&N geben.

Ich dachte auch "da hat ja OMSI Hamburg" mit allem drum und dran bessere Performance;-D Optisch finde ich das gezeigte nicht über OMSI Niveau. Abwarten und Tee trinken.

Und wie soll OMSI diese 18GB adressieren?

Ja, es funktioniert wunderbar, zumindest mit den Prozenten. Ich würde aber um nicht ein heilloses Durcheinander zu haben in allen Karten wo man das nutzt 00:00-24:00 das Fahrgastaufkommen in der global.cfg auf 1.000 stellen und dann mittels AUXI die Zahlen regeln, sonst überlagert sich das alles.

Zitat von messi1984

Ja das stimmt und man hat viel geld dafür bezahlt und ich Hoffe dass das Problem bald Hoffentlich gelöst wird

weil es ist nämlich ein einfach schönes dlc wo man einfach nicht Deinstallieren will.

Du hast recht. Ich könnte nicht mehr fahren ohne die mitführende Kamera beim lenken

Oder die Möglichkeiten die Fahrgastzahlen wochentagsweise anzupassen...

Ist das nun ein weißer Himmel? Ich hab im Sommer wenig gespielt, im Herbst ist mir das jetzt nicht negativ aufgefallen. Aber so sieht's bei mir aus.

Wobei es mich gestern bei einer Fahrt doch ganz schön wunderte als plötzlich der Himmel unterwegs auffällig blau wurde.

Als Kunde möchte ich nicht unbedingt das Alt-modisch einstellen. Rollbänder rollen ist eine uralte OMSI-Funktion, per Kurbel oder Steuergerät. Wenn man einen Bus mit Rollband kauft erwarte ich eigentlich dass eine dieser Möglichkeiten funktioniert.

Der NG272 war auch schon in der AI Liste und ist nicht negativ aufgefallen. Ansonsten fahren da gerade MX200 C2, MZ-LC, vereinzelte O530FL und eben der Stadtbus-MAN in KI-Variante. Mich wundert halt das unterschiedliche Verhalten Normal vs KI-Version...

Ich denke fürs erste nutze ich die normale nicht-KI Variante in der KI, geht ja auch. Wenn ich da nichts negatives sehe versuche ich mal einige Scripte davon in die KI-Version zu ziehen und schaue dann. Im Grunde ist der Bus performancemässig im Vergleich ein Leichtgewicht, aber wenn's eine KI Version gibt ist diese ja definitiv vorzuziehen in der KI.

Was ich mir aber auch noch vorstellen kann ist dass sich das Verhalten vielleicht ändert wenn ich im Trip Ankunftszeit gleich Abfahrtzeit mache, im Beispiel also auch Ankunft auf 01:00 statt 00:56. Wäre komisch, aber wer weiß...

3-4 Minuten. Zum Beispiel Ankunft 00:56 / Abfahrt 01:00 - Bus kommt pünktlich an, führt Fahrgastwechsel durch und fährt weiter ohne 01:00 abzuwarten. Andere Busse und die normale Version warten brav ab, nur der KI nicht. Habe es beim NG beobachtet, hab aber nicht mehr im Kopf ob 3- oder 4-Türer, da ich beide verwende. Irgendwas muss ja unterschiedlich ablaufen, siehe auch die Sache mit dem Licht.

Zitat von fOcUs04

Max. Speicherbedarf für hochauflösende Texturen bitte mal auf 3/4 deines Grafikkartenspeichers einstellen (oder auf max 4096 MB).

mfg

fOcUs04

Meiner Erfahrung nach gibt es bei heutigen Rechnern keinen Unterschied mehr was man da einträgt. Die 3/4 oder 2/3-Regel hat vielleicht zu OMSI 1 Zeiten Sinn gemacht als man 1 GB RAM hatte und 512 MB auf der Grafikkarte an VRAM. Trag da mal 0.0 ein und Du siehst es läuft weder besser noch schlechter. Gleiches mit großen werten. Fakt ist OMSI ist 32 bittig und da hilft auch der 4GB Patch irgendwann nur ein Bißchen die Grenze zu verschieben, mehr aber auch nicht. Irgendwann gibts zu viele Texturen und Fahrzeuge werden weiss, ganz egal was Du im Texturspeicher einträgst. Daher hab ich nach der AI-Liste gefragt. Viele Verschiedene Busse heisst viele verschiedene Texturen und irgendwann ist Schicht im Schacht, vor allem wenn man Busse einsetzt mit tausenden Textürchen, einer 4-8K Haupttextur und dann womöglich unterschiedliche Werberepaints. Will garnicht erst davon sprechen wenns Busse sind die auf jpg oder gar png Texturen setzen. Der VRAM gehört übrigens auch zum Adressraum, genau wie der Arbeitsspeicher. Daher zählt das zusammen zur 32-Bit Grenze;-)

Ich würde an der AI-Liste beziehungsweise der maximalen Anzahl der Busse ansetzen um das Problem zu beheben. Da halt einen Kompromiss finden. Und natürlich drauf achten welche Busse man einsetzt.

Mir ist aufgefallen dass die KI-Versionen des Busses Probleme haben die eingestellte Abfahrtzeit abzuwarten. habe ich zum Beispiel Abends eine Wartezeit mittels "always & wait for dep. time"), wird diese nicht immer abgewartet. Es ist nicht in 100% der Fälle, aber doch sehr häufig. Ein Versuch mit der non-KI Variante zeigte mir dieses Verhalten nicht. Nun wäre es etwas sinnfrei eine KI-Variante in der AIlist durch die volle Version zu ersetzen, denn ich denke mal eine KI-Version sollte im KI Verkehr genau das auch können;-) Vielleicht kann ich das ja irgendwie mit einem Fix per Hand lösen? Weiss jetzt leider nicht welches Script dafür zuständig ist. Ich möchte in der KI schon keine "Vollversionen" fahren lassen...

Bei der Gelegenheit fiel mir auf dass bei Dunkelheit die AI-Version wenn sie denn mal abwartet den Motor abstellt und auf Standlicht schaltet aber den Blinker anlässt, die Standard-Version schaltet Blinker und Licht komplett ab.

Ist das auch richtig dass der Matrix-Font kein "/" hat? Würd ja zu gerne K++ einbauen...

Hilfreich wäre auch Deine aktuelle Hamburg AI-Liste, sofern Du nicht die originale nutzt.

Zitat von IREgio612

Das liegt aber nicht am "Standart", sondern an der Faulheit der Modder. In den OMSI-Standartfahrzeugen (MAN) gab es nun mal links ein Pedal, welches für die Ansagen bzw. für's Mikro zuständig war. Das war nun mal so im Script festgelegt. Und wenn man das nicht entfernt, bleibt dieses (mehr oder weniger) Feature in zukünftigen Bussen drin. Wobei mir aber eher mehr Busse geläufig sind in denen es diese Funktion nicht mehr gibt. Letztendlich schaltet man immer am Drucker oder über einen separaten Schalter die Haltestelle weiter, sofern dies nicht automatisch erfolgt.

Ja, stimmt. In diesem Fall finde ich das aber praktisch, an anderen Stellen wie bei Geister-Heizungen oder Geister-Knickschutz etc ist Script-Müll natürlich schlecht.

Was ich sehr begrüßen würde wäre zwei Dinge auf übliche OMSI-Standards gebracht werden:

1. Blinker:

Der Blinker verhält sich so wie der OMSI-Trigger zum setzen des Blinkers (blinker_set) auch beim Trigger der eigentlich "Über aus" gehen soll. Blinkt man also rechts und drückt die linke Wippe schaltet sich der Blinker direkt auf links und nicht erstmal auf aus. Das sollte für den über-aus-Trigger so nicht sein.

2. Kupplung zur Haltestellenweiterschaltung

Seit jeher dient das Kupplungspedal in OMSI zum manuellen Weiterschalten der Haltestellen. In diesem Bus aber nicht, es passiert garnix. Die Weiterschaltung gibts auf dem üblichen Trigger, über das Pedal geht es aber leider nicht. Die einzigen Busse bei denen auch so ist sind welche mit manuellem Getriebe. Logisch;-D

Ich denke im Sinne aller Lenkradnutzer sollten gewisse Standards eingehalten werden und nicht separate Input-Konfigurationen erfordern, da hier leider Mehrfachbelegungen wie bei der Tastatur nicht möglich sind. So hat zum Beispiel fürs Kneeling jeder Bus einen anderen Trigger...