Beiträge von wurstbrot

Versteh ich nicht, dann wäre exakt nur ein Repaint möglich, nur mit diesem Namen... Es sollen ja mehrere sein.

Ich wollte per CTI eine Innenraum Textur ändern lassen um jeweils den aktuellen Netzplan anzuzeigen. Beim Mainzer MAN LC G hat das nach einem Fehlversucht geklappt, beim Solo trotz gleichem Vorgehen bisher nicht. Ich habe dazu in die Model-Config folgenden Eintrag zugefügt:

[CTCTexture]

farbschema_icons

icons.dds

Und in der CTI dann entsprechend zum Beispiel:

[item]

Kentucky Fried Chicken 2007

farbschema_icons

icons_2007.dds

Der Bus frisst das aber nicht und zeigt die originale icons.dds an. Im Debug Fenster taucht aber diue "icons2007.dds" unter den nicht geladenen Texturen. Versteh ich nicht... Bei G ging es erstmal auch nicht, da hiess es aber jeweils "farbschema_tex6". Dann geändert auf "farbschema_icons" und plötzlich ging es. Auch seltsam, _tex6 war auch nicht vergeben oder so.

Ich hatte schonmal in ein einem anderen Bus ähnliche Probleme als ich den Display Hintergrund eines Innenmonitors ändern wollte. Hab ich da irgendwas vergessen?

Das wäre naheliegend, ist aber nicht der Fall. Es gibt mehr als genügend Wagen. Außerdem warum sollte dann der Vorderwagen ein Kennzeichen bekommen und der Nachläufer nicht?

Ich kenne das CoD Script nicht, hatte aber zu Wechselzielen letztens was gelesen. Und da wurde gesagt das gilt nur für den Spieler und nicht für die KI. Sonst würde ich ja alle drei Ziele aus dem Beispiel unter dem gleichen Namen in der Liste haben und das Script dann auswählen lassen für die KI. Beim Spielerbus wäre es da egal, er kann das in der Route vorgegebene Ziel nutzen, oder es durch die anderen beiden direkt überschreiben. Da wäre eher die KI das Problem.

Moin!

Ich grübele wie ich es am Besten löse mit der gleichen Hof-Datei sowohl der KI als auch dem Spielerbus zu ermöglichen das gleiche Ziel mit verschiedenen Anzeigen anzufahren, aber dass auch Fahrgäste einsteigen. Wir wissen ja dass die Leute blind sind und nicht wirklich auf die Anzeige schauen sondern auf das was im Trip steht (das muss dann gleich mit dem Eintrag zur Anzeige sein).

Beispiel Ziel "Hauptbahnhof":

Es sollen Leute einsteigen wenn der Bus eines der folgenden Anzeigen schildert:

- Campuslinie Hauptbahnhof

- Hauptbahnhof

- Mainz Hauptbahnhof

Das geht wenn jeweils alle drei Ziele im ersten String "Hauptbahnhof" stehen haben und dieser jeweils in die Trips eingetragen ist. Allerdings nur für den Spielerbus. Die KI würde das Ziel wählen, welches als erstes in der Hof-Datei zu finden ist. Da hätte ich aber gerne dass sie unterscheidet, wofür ich die Bezeichnung im Trip und im ersten String ja jeweils ändern müsste und damit im Endeffekt 3 Ziele hätte. Fahre ich also als Spieler und schildere das andere, steigt keiner mehr ein.

Ich dachte dass ein #-Zeichen das löst (weil es zum Beispiel in Spandau verwendet wird: "Hakenfelde" und "Hakenfelde#über Golzstr". Ich ging davon aus dass die KI hier bei der Auswahl unterscheidet, es aber eigentlich das gleiche Ziel ist. Doch dem ist nicht so, das #-Zeichen hat keine besondere Funktion.

Sonst hätte ich meine 3 Beispiele auch so gelöst:

-Hauptbahnhof#Campuslinie

-Hauptbahnhof

-Hauptbahnhof#Mainz

Bestimmt hat sich schon der ein oder andere darüber Gedanken gemacht. Gibts vielleicht doch einen Trick?

Zitat von Maerkertram

Also DockDist hat einen Einfluss, wie weit im Umkreis nach People Boxen gesucht wird. Hatte das am Bahnhof Berlin-Zoo mit seinen mehreren Bussteigen herausgefunden.

Wenn du mehrere Würfel im Abstand von 1,5 Metern hast, funktioniert es erfahrungsgemäß trotzdem.

Fußgängerpfade brauchst du eigentlich gar nicht. Das Fehlen führt nur dazu, dass die Leute sich beim aussteigen wegbeamen.

Ich seh das auch auf der Karte Mainz am Hbf wo die Leute vom Haltebereich unter dem Hochhaus zur Haltestelle außen am Hochhaus laufen. Dort lass ich das aber so, denn das ist in der Realität dort auch so dass die Leute da rüber laufen

Die meisten Stellen hab ich nun durch verschieben und probieren hingekriegt. An einer Stelle allerdings nicht, und woanders sind Menschenmassen da, steigen aber nicht ein. nun ja, aber ich bin schon viel weiter als vorher;-D

Was mich nur wundert ist dass wenn ich manchmal mehre People Boxen habe, zum Teil gar nicht weit weg von einander, immer nur eine mit Leuten befüllt wird, auch wenn gemäß OMSI und Buswürfel Einstellung deutlich mehr als 7 Leute da sein müssten. Dabei sind diese Boxen nun auch nicht unbedingt weit weg vom Würfel, sondern oft sogar sehr sehr nah und definitiv näher als die DockDist.

Das ganze ist schon recht nervig, weil die Position und die DockDist auch erheblich Einfluss auf das Anhalte und Abfahrverhalten haben. Und ich will eigentlich nicht an jede Haltestellenbucht extra Pfade legen, die KI soll auch mal durchfahren können wenn wirklich keiner da steht.

Moin!

Gute Frage ob das nun in den Bereich "Fahrzeuge" hier gehört... Falls nicht, bitte verschieben;-)

Ich glaube das Problem dass Busse ohne Kennzeichen rumfahren kennt jeder. Lustigerweise sind es auch immer die aus der letzten Gruppe eines Hofs, von daher kann man das bedingt etwas Steuern. Ich dachte dass ich das Problem wieder hatte, und das hatte ich auch: ein C2 G fuhr mit einem bestimmtem Repaint herum, welches eigentlich nur 1x in der AI List vorkommt, und ganz ohne Kennzeichen.

Jetzt ist mir aber beim Beobachten aufgefallen dass es andere Busse gab wo nur beim Nachläufer das Kennzeichen weiss war, vorne aber angezeigt wurde samt Fahrzeugnummer. Da dachte ich dann an irgendeinen Fehler meinerseits beim Einbau der Krüger++ Matrix, allerdings war nicht jeder Wagen des Typs betroffen (MAN LC G Mainz), denn mir fielen auch MAN NG's aus der Stadtbusfamilie auf wo das auch der Fall war, und dort hab ich bisher gar nicht Hand angelegt, außer aus dem Repaint die Wagennummer von der Textur entfernt. Und ehrlich gesagt ist mir in OMSI das noch nie begegnet dass nur der Nachläufer kein Kennzeichen hatte, außer vielleicht bei irgendwelchen anderen missglückten Moddingversuchen, wo dann aber noch anderes im Argen war wie zum Beispiel falsches Repaint beim Nachläufer. Hier stimmts aber. Und vor allem: nicht jeder Wagen ist betroffen, genutzt wird bis auf einen Wagen hier das gleiche Repaint.

Ideen? Was könnte die Fehlerquelle sein?

7000 MB bei Grafik einzustellen ist Unfug. OMSI kann insgesamt nicht mehr als vielleicht 3 GB (in der Theorie um die 4 GB) verwalten da es ein 32 Bit Programm ist. Der 64 Bit Patch mogelt dem Code da was vor, aber OMSI wird nie drüber kommen ohne einen Crash. Ich würde da entweder "0.0" eingeben oder mit irgendwas unter 3000 experimentieren. Ich selbst habe da 0.0 und ich habe ein sehr ähnliches System (R7-7900X+RTX4070).

Die ganzen Nachladeruckler kommen halt daher weil sich OMSI da selbst ein oder zwei Beine stellt. Jede heute erhältliche SSD ist da kein Flaschenhals mehr. Einzig verbessern kann mit besseren CPUs die reinen FPS. Das sogar erheblich, es fühlt sich aber wegen dem Nachladen trotzdem unflüssig an, wenn auch das Nachladen leicht besser wird mit überproportional mehr CPU Power: z.b doppelt so schnelle CPU schafft etwa doppelts o viel FPS, aber sorgt nur für nur 10% besseres Nachladen..

In den meisten Fällen ist sie bei 30. habe aber irgendwo gesehen dass eine Änderung auf 15 eine Haltestelle wieder deaktiviert hatte.

Ich habe bei Tests mehrere Würfel hintereinander platziert um dann im Debug Fenster zu schauen welche davon funktionieren. Da hatte ich manchmal aber auch zwei dicht hintereinander die beide aber aktiv waren. Das wäre doch so ein Streitfall. in dem sich dann eine durchsetzen müsste?

Position des People-Objekts ist wohl auch nicht unwichtig, eventuell dann im Zusammenspiel mit der DockDist. Aber auch nur eine wage Vermutung.

Bisherige Erkenntnisse:

Das ist ein Bisschen wirr... Es hängt scheinbar auch von der Position des Haltestellenwürfels ab. Die Frage ist zur was? Entfernung zur People Box? Sehe da kaum Zusammenhänge, aber diffuses verschieben und probieren aktiviert oder deaktiviert die Haltestelle... Das ist nicht unbedingt gut, denn ist die Position des Würfels mal ausgetüftelt für ein gutes An- und Ablegeverhalten der KI-Busse, kann dies unter Umständen bedeuten dass sie nicht funktioniert. Oder sie funktioniert an einer Stelle wo dann der Bus eben über den Bordstein fährt und ähnliches.

Hast Du das Enviroment Pack? Ich glaube ich hatte damit Probleme im Zusammenhang mit AUXI. Jedenfalls habe ich bei mir im Texture Ordner folgende Texturen:

- himmel01.bmp

- himmel04.bmp

- himmel05-bmp

Diese sind aber eigentlich Kopien der jeweiligen Texturen aus dem Skybox-Unterordner in Texture. Denn wenn ich mich nicht alles täuscht hatte ich in Auxi auch irgendwelche Probleme mit dem Himmel und hab dabei festgestellt dass AUXI eben diese Himmel-texturen nutzt wenn das reale Wetter dort aktiviert ist. Und seit Wochen funktioniert das super stabil.

In der Envir-Datei hab ich nämlich folgendes stehen:

[sky_textures]
Texture\skybox\day01.bmp
Texture\skybox\sunset01.bmp
Texture\skybox\night01.bmp

und das wurde ignoriert durch Auxi. Wenn das bei Dir in der envir-Datei auch so steht und Du das Enviroment Pack nutzt, dann könnte die Lösung ähnlich wie bei mir sein.

Die Matrix funktioniert nun prima im LC. Es nervt mich nur dass die Liniennummer kleiner wird wenn sie auf die "Abfahrt in X Minuten" wechselt. Hab in der Hof versucht den Text kleiner zu kriegen, aber das ändert nichts daran dass die Liniennummer dann immer gestaucht wird.

Abhilfe wäre aber auch im LC diese Funktion abzuschalten, weiss aber nicht wo das genau im IBIS Script steckt.

So in etwa. Das ist dann die Feinarbeit, muss auch den Rand in den Texturen noch anpassen, der ist im Vergleich zur Matrix zu grau. War bei der alten Matrix okay, hier fällt es aber auf.

Kann ich eigentlich beim Testen schon das Ergebnis sehen wenn ich den Bus neu setze oder muss ich OMSI neu starten?

So, das Matrix-Objekt vom Solo-Mod zerschnitten, und im Vorderteil funktionsfähig. Im Heck noch nicht, ich nehme mal an das ist noch nicht genau genug positioniert. Aber für Quick and Dirty schon mal super, keine Matrix mehr in der Luft hinten ;-D

Und nun auch hinten gut. Hat sich vorhin versteckt;-)

Jetzt kann ich vielleicht auch die Vordermatrix schöner hinkriegen dass die die Fläche ganz ausnutzt.

Aaaaah, ich dachte o3d kann man nicht importieren. Das ist ja fantastisch! Dann würde ich mir für den G da einfach die Heckmatrix ausschneiden und als separates Objekt positionieren.

Überhaupt ergeben sich da nun für mich viele Möglichkeiten, allein wenn ich nur an Wagennummern denke die ich nun recht individuell positioneren kann und garnicht in Verlegenheit käme pro Wagen ein Repaint zu machen...

Aber zurück zur Matrix:

es braucht definitiv ein eingenes Objekt und man kann es nicht auf das Ursprüngliche draufmappen? Der LC Solo hatte ja eigene separate, im Mod wurden die durch ein gemeinsames neues ersetzt.

Moin!

Ich finde immer mehr Gefallen an der K++ Matrix und möchte diese gerne auch in andere Busse einbauen. Kandidaten dafür wären erstmal:

- Aachener Citaros

- Mainzer MAN LC G / GUE

Für den Mainzer Solo-LC hab ich eine Mod gefunden, die aber in den G einzubauen ist gescheitert. Das Skript etc funktionierte dort, die Matrix selber auch, allerdings ist das Objekt auf dem die Matrix gemappt ist eins für den gesamten Solo-Bus. mit der Folge dass die Heckmatrix bei der Gelenkvariante deplatziert ist.

Die Frage wäre: muss ich dafür nun ein (einfaches) flaches Objekt in Blender selber bauen? Wäre ja machbar, aber die Koordinaten dann zu finden wäre grausig. Kann ich nicht vielleicht das "alte" Objekt nutzen, welches für die alte Matrix gedacht war und das dann draufmappen? Wenn ja, warum wurde im LC Solo Mod das ganze über ein eigenes Objekt gelöst?

Vor Jahren hatte ich diverse LCD/LED Matritzen in den Alterr O530 eingebaut, und kann mich nicht erinnern dass da neue Objekte benötigt wurden.

Ich habs gestern bei einer Runde getestet und gefühlt war der Effekt bei Null;-) Ich denke das liegt echt daran was Chrizzly92 schreibt. Es ist exakt so: das Lenkrad spielt dann etwas verrückt und nicht das FF an sich. Früher als Mausfahrer hat das keine Rolle gespielt, aber jetzt finde ich das schon seltsam wenn an einer Haltestelle sich einfach das Lenkrad mal etwas links,dann etwas rechts dreht wenn man schief steht.

Ich habe aber bei den SDs im Stand nie ein Vibrieren gehabt über das Force Feedback. Ich höre den Soundeffekt, aber Lenkrad vibriert da nicht. Ansonsten bei Fahrt alles gut, angemessenes Rütteln auf Kopfstein etc, guter Lenkwiderstand.

Danke ich teste das mal.

Das FF Script ist bis auf ganz wenige Ausnahmen in jedem Bus gleich, nämlich eine Kopie aus den Doppeldeckern.

Das Lenkrad verhält sich ja genau wie man es ihm sagt, und wenn man eben krumm steht kriegt er die entsprechenden Signale. Und wir wissen ja wie OMSI insbesondere bei schlechtem Kartenbau gewisse Sachen interpretiert. Das was Du vorschlägst löst ja nicht das beschriebene Problem, denn ich will ja garnicht die Stärke des FF reduzieren, sondern es nur im Stand verhindern. Mache ich das was Du vorschlägst habe ich auch sonst unterwegs zum Beispiel auf Platten oder Kopfsteinpflaster weniger Effekt. Und das möchte ich nicht, denn da ist die Stärke absolut okay.

Moin!

Ich hab mir gedacht dass man doch die Force Feedback Scripte so konfigurieren könnte, dass das FF nur aktiv ist wenn der Bus auch fährt, z.B. mindestens 1 km/h. Hintergrund ist der, dass ich es für total unrealistisch halte dass das Lenkrad sich manchmal dauernd nach links und rechts im Stand bewegt samt Rütteln wenn man eine unbeabsichtigte Berührung mit dem Bordstein an der Haltestelle hatte. Das nervt und ich würde deshalb gerne diese Effekte bei Stillstand des Fahrzeugs ausstellen. Jemand eine Idee wie das im FF Script zu lösen wäre?