Beiträge von wurstbrot

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.

Das mit dem "try placing..." ist nichts ungewöhnliches. Ich habe das schon auch auf vielen Karten gesehen mit Bussen die eindeutig nicht kaputt waren. Es ist leider nicht gut dokumentiert was dabei passiert, ich schätze mal wenn es gehäuft kommt dann kann es zu verstärktem Stottern beim Nachladen kommen. Allerdings: wenn es davon in der log wimmelt ist es ein Hinweis dass durchaus was nicht stimmt.

Folgende Zeile hätte ich eher im Verdacht:

262 14:10:03 - - Error: Es wurde versucht, einen Sitz zu verlassen, der nicht existiert!

Ich habe bis heute keine Ahnung was sie genau bedeutet, aber wenn sie auftauchte war immer irgendwas mit irgendeinem Bus nicht in Ordnung. Würde also auf jeden Fall versuchen durch Reduktion der Busse in der AI Liste auf den Übeltäter zu kommen.

Moin!
Leider krieg ich beim NLC meine Türsteuerung noch nicht so hin wie ich sie gerne hätte. Als erstes hätte ich gerne Tastatur-Events für die beiden Varianten der Stadion-Schaltung, also für vis_Tuersteuerung_Stadionschalter = 1 und vis_Tuersteuerung_Stadionschalter = 2. Beim ersten gibt es getrennte Events für einschalten und ausschalten, die hätte ich gerne aber als Toggle auf einer Taste. Gleiches dann auch für die zweite Variante mit dem blauen Taster, hier finde ich aber so garnix an Triggern. Habt Ihr da Ideen?

Zweite Sache:

Ich hatte mir die Entrys und Exits bei der Cabine so bearbeitet dass EInstieg auch an Tür 2 bis 4 möglich ist und AUsstieg auch beim zweiten Flügel der ersten Tür. Doch irgendwas bringt hier das Türscript durcheinander , ich hatte dann jeweils einen Haltewunsch nach zurücknehmen der Türfreigabe. Müsste ich da die Haltewunsch-Requests irgendwie bearbeiten oder Zoordnungen verschieben? Wahrscheinlich macht der Ausstieg an Tür 1 das Problem?

Hat eigentlich jemand auf die Schnelle die Tastatur-Trigger für diese beiden Display-Tasten? Die würde ich mir dann doch wohl belegen wollen weil es mit der Maus etwas nervig ist.

Man muss das im Vergleich sehen. Wenn es sich vergleichbar mit anderen Karten verhält dann passt das. Weicht es stark ab dann ist irgendwas faul.

Ich kann Dir nicht genau sagen was da beschädigt ist im Falle der 55er Meldungen. Sowas in der Art hatte ich mal auf Spandau, ist aber ewig her.

Ob ein Fahrplan aktiv ist oder nicht spielt erstmal keine Rolle. Die ganze Simulation läuft ja unabhängig davon trotzdem.

Fahr mal einfach eine kleine Runde und schau mal, und dann vielleicht eine andere Karte zum Vergleich.

Die Litfassäulen sind tatsächlich (leider) schwarz. hat auch anscheinend keiner bis jetzt repainted.

Wie es scheint fährt die KI aber wie sie soll, und auch die Linie 55 scheint zu funktionieren obwohl die Logdatei sie als fehlerhaft anzeigt.

Stottern beim Kachel laden ist bei OMSI normal. Wichtig ist wie sich das beim Spielen auswirkt. Du meintest anfangs dass alles vor sich hin ruckelt. An und für sich sollte sich das Nachladen der Kacheln in den Aussenbereichen der Karte wenig spürbar anfühlen, in der Innenstadt dann schon merkbarer aber weiterhin gut spielbar. Vergleichbar mit Spandau oder Hamburg.

Ändert mal einem x-beliebigen Spiel auf Steam irgendeine Datei. Ihr wertet sehen dass sie früher oder später gegen das Original ausgetauscht wird. Ich kann mich gut erinnern wie damals bei CIM2 bestimmte Mods regelmässig überschrieben wurden, aber auch ei City Skylines wenn gewisse Mods über den Workshop hinaus Eingriffe erforderten. Die Problematik ist systembedingt, war schon immer da und wird sich vermutlich nicht ändern solange Steam so funktioniert wie es eben funktioniert. Lebt damit, macht Backups, oder spielt eben ungemoddet.

Zitat von some1

Das funktioniert aber nicht mehr so einfach. Der NLC hat seit dem Update standartmäßig schon ~70 texttexturen. Und der Tempomat liegt irhendwo in dem Bereich, die wirst du anpassen müssen.

Irgendwer muss da den Anfang machen und bei dem IVU Modell-Eintrag eben alle Indezes um 10 oder 20 erhöhen;-) Oder könnte man das mit einem Notepad++ Plugin automatisch machen?

Und wie läuft die Karte jetzt, stottert da was wenn Du sie lädst? Fahren Busse rum? Irgendwas komisches?

Wenn Du in OMSI auf der Karte bist (bitte am Hauptbahnhof) geh mal auch bitte ins Debug-Fenster. Ich weiss jetzt nicht welche Tastenkombination das bei DIr ist, bei mir SHIFT-ESC. Schau ggf nach wie man das bei Dir öffnet bei den Tastaturbelegungen. Dort auf "Stations". Und dann den ganzen Text mit den Haltestellen mal hier reinkopieren. Das würde ich mir gerne mal anschauen.