Beiträge von wurstbrot

Zwei Dinge hab ich heute:

Passagierpfade:

Mir fiel öfter schon auf dass an Tür 1 immer mal jemand am zweiten Türflügel auftauchte und wieder verschwand. Jetzt hab ich gesehen wo sich diese Personen hingebeamt haben. Hier ein Bild mit zwei Damen auf Stehplätzen im vorderen Busteil des 18C:

Beide kamen anscheinend durch Tür 2 rein, gingen dann nach vorne zu Tür 1 (zweiter Flügel) und taten so als würden sie aussteigen, verschwanden jedoch an der Türkante und beamten sich zu den Positionen im Screen. Das finde ich ein wenig seltsam, denn sie müssen im Gang ja an den Positionen erstmal vorbeigelaufen sein.

Anfahren 18C bei aktivierter Start-Stop-Automatik:

Im Gegensatz zum 12C hab ich hier oft den Eindruck dass beim Anfahren was hängt bzw nicht gelöst wird. Laut Display ist Gang bereits drin, Umdrehungen öfters schon am Verlassen des grünen Bereichs, erst dann fährt die Kiste los mit relativ heftigem Ruck. Es ist aber nicht immer so, es ist auch öfters wie gewollt: Motor springt an, langsam steigen mit Gas die Umdrehungen, man merkt wie das Heck anschiebt und es geht los. Ich habe den Eindruck dass da irgendwas noch blockiert. Ist Start-Stop deaktiviert verhält sich der Bus auch erwartungsgemäß.

Laut Logfile lädst Du gar nicht Mainz sondern Ingolstadt, und bei dieser fehlen haufenweise Objekte. Das einzige was hier mit Mainz zu tun hat ist ein einziges Mainz-Objekt welches nicht gefunden wird und aus dem Lieferumfang der Karte Mainz stammt.

Danke, jetzt funktioniert's. hab den Bus relativ vollgepackt mit Leuten, dann Uhrzeit auf 11 Uhr gestellt, dann auf 23 Uhr und zurück auf 11. Um 23 Uhr war es mucksmäusschenstill bei 50 Leuten

Jetzt nur noch eine sinnvolle, realistische Kurve austüfteln.

Also wo keine Bordsteine mit im Spiel waren war zum Beispiel mehrfach in Mainz beim runterfahren von der Theodor-Heuss-Brücke Richtung City in etwa da wo die Rampe aufhört. Da bin ich zig mal mit diversen Bussen lang und hatte die Stelle nie als kritisch in Erinnerung, bin mit dem NLC aber mehrfach wohl so aufgesetzt dass alle aussteigen wollten. Bei Tempo unter 30. Sowas ähnliches hatte ich in Grundorf am Bauernhof kurz vor der Ampel beim runterfahren. Man muss aber schon Beförderungsfälle geladen haben, ein normales Rumpeln darf ja schon hier und da natürlich sein.

Ansonsten kann ich Dir leider keine weiteren exakten Stellen benennen. Hohenkirchen will ich zum Beispiel nicht mit aufführen denn da ist es mit jedem Bus problematisch.

Das Küssen der Bordsteine ohne sie sichtbar zu berühren ist zum Beispiel auch nicht an bestimmte Orte gebunden. Es fällt nur auf dass es mit dem NLC passiert und mit anderen Bussen eben nicht.

Zitat von Karbonat Erol

ich musste damals für den Ruhr-Urbino die Boundingbox ebenfalls verkleinern (bzw. höher legen), weil bei der Nitzschmännchen-Splinebauweise die Karre auch überall kollidiert ist. Realismus hin oder her, wenn die Fahrbarkeit drunter leidet, sollte man das gegebenenfalls etwas entschärfen. Nicht jede Karte hat millimetergenaue Kreuzungsobjekte mit perfekter Kollision.

Es sind nicht nur Spline-Straßen. Mich zerhaut es regelmäßig auch an Orten die aus einem individuellen Gesamtobjekt bestehen. Es kann aber schon gut sein dass es bei Spline-Gepfusche häufiger ist. So ganz eindeutig ist es aber auch nicht, ich kenne Stellen da würde ich im Vorfeld sagen dass da sicher gleich die ganze Mannschaft aussteigen will, dem ist dann aber nicht so. Und dann setze ich auf bei Stellen wo ich mir denke was ist denn da los...

Ich finde den Ansatz gut da der Spielbarkeit Vorrang zu geben und zum Beispiel die Boundingbox wenn diese das verursacht eben leicht anzupassen. Wahrscheinlich geht es nur um Millimeter die ausreichen würden.

Hab es vorhin ausprobieren wollen, leider kommt beim Laden dann "Time ist kein gültiger Intergerwert".

######################################
Fahrgäste
######################################

[sound]
chat-low.wav
1

[viewpoint]
2

[3d]
0
0
0
7

[volcurve]
humans_count

[pnt]
0
0

[pnt]
5
0

[pnt]
15
0.5

[pnt]
60
0

[conditionSingle]
humans_count
0
3

[volcurve]
Time

[pnt]
0
0

[pnt]
39600
1

[pnt]
54000
1

[pnt]
86399
0

[sound]
chat-high.wav
1

[viewpoint]
2

[3d]
0
0
0
7

[volcurve]
humans_count

[pnt]
15
0

[pnt]
90
1

[conditionSingle]
humans_count
0
3

[volcurve]
Time

[pnt]
0
0

[pnt]
39600
1

[pnt]
54000
1

[pnt]
86399
0

Kann ich bestätigen. Da wo andere Busse keine Probleme haben gibt es beim 12C und 18C Probleme. Es fühlt sich an als würde der Boden aufsetzen, aber auch mit Bordsteinen gibt es Probleme. Ich hing auch schonmal irgendwo fest obwohl nichts sichtbar war. Ich glaube aber auch vor dem Update war der Bus sehr sensibel was Kaugummi auf dem Asphalt betrifft.

Die Experimentelle Version zeigt die Abfahrtzeiten an den Haltestellen an, sofern eine passende Datenroute in der Hofdatei vorliegt. Weitere Unterschiede hab ich leider nicht auf dem Schirm, da ich gefühlt seit immer schon diese Variante nutze.

11 wird nicht zu 115. 11 bleibt 11. Ab 57 wirds geändert um 50 (experimentelle Version) bzw. 44 (Stable Version).

Du nutzt wohl die IVU in der Stable-version, richtig? bei mir ist es die Experimental Beta, die hat ein paar Texttexturen mehr. An dieser Stelle solltest DU erstmal überlegen ob Du später auch Uhrzeiten für die Haltestellen angezeigt bekommen willst oder nicht. Das geht dann mit der experimentellen Version. Wenn nicht würde ich nun hingehen und bei Dir aus der 57 eine 101 machen, aus 58 eine 102 usw. Also alles plus 44 statt plus 50 wie bei mir.

Und dann musst Du noch die entsprechenden Stellen mit [useTextTexture] entsprechend anpassen, hier danna uch plus 44 statt 50. Bei Dir ind er Datei stehen immer noch überall die alten Werte.

Gut, bei den zwei Zeilen stimmt das. Konnte mir aber nie merken was man dann dazwischen einfügen muss

Ich hab leider keinen direkten Vergleich, aber bei OMSI dürfte X3D vs Nicht-X3D schon einen Unterschied machen. OMSI skaliert nahezu 1:1 mit der Single-Core CPU-Leistung. 20% höhere Kernleistung ergibt fast 20% höhere fps. Da dürfte sich der 3D Vcache gut bemerkbar machen.

Zitat von harmonieeerelax

wurstbrot Ok, irgendwie verstehe ich das nicht so ganz. Was muss ich bei den Texttexuren machen genau? Weil du hast ja mehr als 100 Texttexuren.

Die IVU nutzt die Texttexturen 38 bis 106. Der NLC 0 bis 73. 38 bis 73 überschneiden sich also. Jetzt gäbe es zwei Wege: die IVU anpassen oder den Bus anpassen. Letzteres erscheint aber einfacher, da man alle Texttexturen die für den Drucker bestimmt sind nicht braucht. Der NLC-Drucker nutzt Texttexturen 14 bis 56. Da wir den alten Drucker nicht mehr nutzen wollen sind also Texturen 14 bis 56 egal, können also die IVU als 38 starten. 39-56 können gelöscht werden, den Rest fügen wir nach den von der IVU wieder an und ändern die Indezes zur besseren übersicht. Letzte der IVU ist also 106, danach käme also 107. Da ist dann die ehemalige 57 vom NLC, die nun zur 107 wird. Die 58 zu 108 usw. Erhäht sich also um 50.

Weiter in der Model-Datei wird aber immer noch auf die alten Indezes zugegriffen, das muss man dann per Hand ändern.

Dazu nutzen wir am Besten Notepad++ mit dem Plugin "ToolBucket" und davon dann das "Multiple find and replace" Tool und suchen nach

[useTextTexture]
57

und ersetzen es durch

[useTextTexture]
107

Dann das gleiche mit 58 bis 73. Sicherheitshalber nach jeder Änderung nochmal suchen lassen, es können ja auch mehrere Einträge da seind ie geändert werden müssen.

Zum Schluss natürlich testen: geht das Tacho? die Innenanzeige? Alle Funktionen im Display?

Bei der Gelegenheit sollte sich jeder der in OMSI Dateien rummoddet das erwähnte Plugin anschauen. Ich wüsste kein anderes Tolo zum Suchen und Ersetzen ganzer Passagen. Leider ist da irgendwo ne Grenze. Suchen nach ganzer Passage des alten Druckers und ersetzen mit ganzer Passage des neuen Druckers ist dann leider etwas zu viel;-) Aber mal eben zum Beispiel alle Sichten auf einem Schlag in 100 bus-Dateien ersetzen geht.

Nimm mal als Vergleich meine model-Datei vom 12C, vor allem den Texttexture-Bereich. Aber Achtung:, meine Datei ist für die DGM-Matrix. Tacho etc sind da aber schon angepasst. Da musst Du halt überall gucken dass keine Texttextur über dem Index 57 verwendet wird. Wenn ja müssen die über 57 um 50 erhöhen. Zum Beispiel von 57 auf 107.

Zitat von ma7t3

Ein Kritikpunkt wurde schon angesprochen: Der Kinderwagenschalter: Cooles Feature, allerdings wird er auch für meinen Geschmack viel zu häufig ausgelöst, vielleicht kann man das etwas reduzieren.

Ach dann ist es der Kinderwagenschalter wahrscheinlich der bei mir diese Türfreigabe/Haltewunsch Problematik ausgelöst hat

Meine Erfahrung mit solchen Features ist dass sie tatsächlich irgendwann nerven. Finde aber prinzipiell gut dass es sie gibt, sie sollten aber dokumentiert sein damit man da nicht in die Falle tappt und am besten per Const-Wert auch abschaltbar oder der Timer einstellbar ohne dass man ins Script eingreifen muss.

Jetzt konnte ich mit dem Bus schon ein paar Runden drehen und kann mich nur anderen anschließen, das Update ist gut gelungen. Insbesondere muss ich den Motorsound loben. Wo ich in der alten Version den im Innenraum am Fahrersitz kaum wahrgenommen habe finde ich nun die Lautstärke nahezu perfekt und realistisch eingestellt. Aber auch sonst klanglich prima.

Ein paar Verbesserungsvorschläge habe ich dennoch. Etwas hat mir von Anfang an gefehlt und während der Fahrt fiel mir irgendwann auf dass der Bus kein Bremsquietschen hat. Schnell aus dem MX200-C2 ausgeliehen und schon Problem gelöst. Macht aber echt viel aus beim Fahren wenn es zumindest dezent vorhanden ist. Ja, auch neue Busse quietschen;-D

Irgendein Lüfter/Klima-Sound ging ziemlich abgehackt aus wenn der Motor sich abgeschaltet hat. So als würde man das Sample direkt schneiden ohne dass es einen kurzen Auslauf hat.

Beim Motorstart hab ich ein Zischen an den Türen gehört obwohl ich die E-Türen (Setvar 3) aktiv hatte.

Die Bremsen fand ich viel zu stark. Kein Wunder, der maximale Bremswert in der Const ist mit ca. 170000 weit über dem anderer Busse, die bei um die 100000 drin haben. Also hab ich mir das entsprechend gesenkt. Möglich aber dass das keine allgemeine Aussage ist sondern mir das an meinen Pedalen (G29) so vorkommt.

Ich weiss nicht ob das ein Feature war, aber im Zusammenhang mit der Auto-Kneeling funktion kam es vor dass ich beim 18G beim Zurücknehmen der Türfreigabe für die dritte Tür sofort einen Haltewunsch ausgelöst hatte. Das ging so hin und her bis ich durch wirres öffnen und schließen der Türen das dann irgendwie resetet habe. Konfiguration der Türen war alle manuell plus dritte zusätzlich automatisch.
(ist wohl das Thema "Kinderwagenschalter")

Ach ja, der Bus scheint auch sehr sehr anfällig zu sein für jegliche Unebenheiten auf der Straße. War aber auch vor dem Update so.

Das wärs erstmal;-)

Zitat von ma7t3

Es muss irgendwo hin, wo der Code in jedem Frame ausgeführt wird.

Auf Nummer sicher gehst du auf jeden Fall, wenn du das direkt in den {frame}-Bereich des Busses direkt irgendwo einfügst.

Allerdings haben ja auch manche "Buskomponenten" eigene Frame-Makros, die aus dem {frame} heraus aufgerufen werden.

Dort könntest du es theoretisch genau so eintragen. Das ist ziemlich Banane.

Gestern auf die schnelle noch ausprobiert im NLC beim Display, das ganze hatte aber dazu geführt dass das Display komplett den Dienst aufgegeben hat Ich hatte den frame in die MAN_Cockpit.osc integriert wo die Trigger sind. vielleicht war das das Problem.

ist aber schon gaga ein Script zu ändern weil die Hardware eine Macke hat Aber sonst wüsste ich nicht wie und das Rädchen wäre unbenutzt.

Zitat von Thomas U.

Wer DLC-Dateien niemals verändert, kommt dementsprechend auch nicht zum Vergnügen einer Steam-Datenprüfung. Das dürfte wohl der Großteil der OMSI-Nutzer sein.

Genau das denke ich auch.

Ich verstehe nur nicht warum sich da so drüber aufgeregt wird. Wir wissen ja um die Problematik Bescheid, es gibt zahlreiche Lösungsansätze das ganze zu lindern und trotzdem wird gejammert oder sogar Drittanbietern vorgeworfen sie würden das mit ihren Addons absichtlich auslösen

Zitat von Eschy5

Zu diesem Thema kann ich mittlerweile einen Tipp geben.

Klickt in Steam mit rechts auf Omsi und dann auf Eigenschaften. Im neuen Fenster unter Updates wählt ihr den Punkt "Dieses Spiel nur beim Start des Spiels aktualisieren".

Seit dem ich diese Einstellung verwende gehen die Updates wieder schnell und bisher kam keine ungewollte Steamüberprüfung. Leider ist der Punkt nicht so benannt, wie er benannt sein müsste, denn daraus geht nicht wirklich hervor, dass man keine Zwangsüberprüfung mehr bekommt.

Diese Einstellung habe ich bei OMSI aktiv. Und es schützt nicht davor;-) Es führt den Download und die Installation nicht gleich durch, also hat man etwas mehr Luft um eventuell noch ein Backup zu machen. Starten kannst Du aber OMSI dann nicht mehr bevor Du nicht das Update und die Überprüfung ausführst.

Ich denke wenn Ihr nichts modden würdet dann gäbe es die Überprüfungen nicht. Dann wäre es aber auch egal Je mehr ihr gemoddet habt desto eher wird die Überprüfung aktiviert. Und klar ist auch dass es um veränderte Dateien geht, nicht um zusätzliche. Deshalb macht es schon Sinn anstatt zum Beispiel eine door.osc zu modden, eine Kopie davon zu erstellen und dann auch in eine Kopie der .bus-Datei einbinden. Aber kaum wer wird das so 100%ig sauber machen Um die Backups kommt man kaum herum.

Und manchmal ist so eine Überpüfung samt Reparatur ein guter Moment mal sein OMSI aufzuräumen und mit dem messihaftem sammeln von Content von vorne anzufangen. Und auf einmal läuft OMSI dann auch wie ein Ferrari und wundert sich

Genau, darum geht's. Vielen Dank, ich werde das mal ausprobieren. Der Frame-Teil muss ins Hauptscript des Busses, oder reicht es da wenns dann beispielsweise im Cockpit-Script ist wo dann der Trigger kommt?

Moin!
Ich würde gerne in gewisse Tastatur-Trigger im Script eine Verzögerung einbauen. Der Trigger soll nachdem er ausgelöst wurd eine kurze Zeit nicht auf weiteres Drücken der Taste reagieren. Der Hintergrund wäre der, dass ich einige Funktionen gerne auf das Rädchen beim G29-Lenkrad lege (Scheibenwischer) oder bei meiner LaWi-Seitenkonsole auf das dortige Scrollrad (Lichtsteuerung oder Menü-Blättern). Beides ist leider so sensibel, dass da beim Betätigen ganz leicht zwei mal der Trigger ausgelöst wird. Das würde ich gerne nun verhindern.. Ich dachte da an die Trigger in den Scripten, denn ich wüsste nicht wie ich das zum Beispiel in JoyToKey lösen könnte. Zumindest um es auszuprobieren würd ich gerne eine Scriptseitige Lösung mal austesten.