Once again the point settings/seat is grey out and I can't open the seat-window, as well I can't lean and zoom via hotkey any more, even after deleting the files in buses directory and resetting the config.
Beiträge von wurstbrot
Als Gast kannst du nur Inhalte in deiner ausgewählten Sprache sehen. Registrierte Nutzer können die Sichtbarkeit anderer Sprachen in ihrem Kontrollzentrum aktivieren, weitere Infos hier.
Alle Themen sind in den Foren mit einer Sprachflagge gekennzeichnet:
-
-
Moin!
Ich hab nun einige Werte für Achsen verschiedener Busse verglichen um mir einen Reim drauf zu bilden wie man die Stoßdämpfer konfigurieren kann, komme aber auf keinen grünen Zweig. Sehe da für mein Verständnis willkürliche achse_feder und achse_dämpfer Werte, die dann aber dem Verhalten des Busses nicht entsprechen. Konkret wollte ich beim Mainzer Lion City die Stoßdämpfer verbessern, da im Vergleich zu anderen Bussen die Kiste sich schon bei einem Kaugummi auf dem Asphalt verhält als wäre es ein riesiges Schlagloch. ALs Vergleich habe ich insbesondere dann den KJ O530 rangezogen, der was das betrifft für meine Begriffe sich adequat verhält und ich meine auch dass es da zum Lion CIty nicht zu anders sein sollte.
Also, was genau bewirken achse_feder und achse_dämpfer? Oder versuche ich das tatsächlich and er völlig falschen Stelle?
-
1809 ist Windows 10. Hier geht es um Windows 11 24H2, welches erst seit ganz kurzem per Update aufgespielt wird.
-
Also könnte theoretisch irgendein Windows 11 Update in letzter Zeit das verursacht haben? Würde mich aber wundern wenn die plötzlich einen gefühlt jahrhunderte alten Standardfont abändern würden.
Ich weiss aber dass bei mir kürzlich irgendwas bei der Skalierung durcheinander war und ich erneut Dinge wie Skalierung und Schriftgröße in Windows angepasst habe. Aber dass sowas sich auf OMSI "in game" auswirken würde?
Gelöst.
Tatsächlich war es die Windows-Skalierung. Da hatte ich 110% statt 100%. Total seltsam, denn in OMSI selbst sind das Auswahlfenster, Optionsfenster etc immer unskaliert. Außerdem habe ich bei der .exe die Skalierung ebenfalls aus.
Wäre jetzt mal interessant wie also Leute mit einem 4K Screen bei OMSI verfahren.
-
-
1. Mit welchem Programm hast Du ein Problem? (Hauptprogramm, Editor, SDK Tools, etc.)
>OMSI 2
2. Bitte beschreibe das Problem so ausführlich wie möglich. Was ist passiert oder was hat vielleicht zu dem Fehler geführt?
>Wie auf dem Bild aus dem MAN NL202 zu erkenne ist scheint irgendwas mit dem Font nicht mehr zu stimmen, der für den Fahrplantext zuständig ist. Die Formatierung haut nicht mehr hin, obwohl sie das tat. Hab es auch mit meiner alten Photoshop-Vorlage verglichen, wo die Textur auch wunderbar hinhaut und die ich mal an den Text angepasst habe. Also vermute ich mal dass da was mit dem Font nicht mehr stimmt. Aber welcher Font ist das überhaupt? Vielleicht wurde er durch irgendeinen neuen Bus überschrieben?
3. Bitte füge Deinem Beitrag eine Log-Datei hinzu, entweder im Spoiler, Code-Block oder als Dateianhang.
4. Falls es einen hilfreichen Screenshot des Problems gibt, kannst du ihn als Beitragsanhang mit hochladen und einfügen.
5. Gib Deine Systeminformationen an, falls es sich um ein Performance-Problem handelt. (Betriebssystem, Prozessor, Grafikkarte, Festplattentyp, Arbeitsspeicher, etc.)
>
-
Das stimmt, dann bin ich ja mal gespannt;-D
-
OMSI dürfte das Ergebnis beider/aller Volume-Curves (humans_count und Time) multiplizieren.
Genau das dachte ich wäre das Problem. Wenn er tatsächlich beide Kurven berücksichtigt, wäre genau das erreicht was ich will. Probiere ich auf jeden Fall mal aus morgen. Wäre mal gespannt was er daraus macht. Angenommen der Bus ist 50% voll und das ergäbe 0.5er Lautstärke, und wenn dann aus der anderen Kurve auch 0.5 rauskäme. Halt ob er ddas dann addiert? Addieren wäre garnicht schlecht, man müsste dann eben auch die Humans-Kurve entsprechend anpassen, sodass man im schlimmsten Fall nicht über 1.0 wäre.
-
Moin!
Ich frage mich ob es möglich wäre die Fahrgastsounds auch von der Uhrzeit abhängig zu machen. Die Idee dahinter wäre dass morgens die Leute noch viel müder sind als Nachmittags oder Abends, sodass ein voller Bus am Morgen innen weniger laut sein sollte als ein genauso voller Bus am Nachmittag.
Als Beispiel nehmen wir mal den MX-C2. Die Soundconfig hat ja einer vol-Kurve die die Lautstärke regelt über die Anzahl der Menschen. Wie könnte man das nun mit einer zweiten Lautstärkekurve koppeln, die eben die Tageszeit widerspiegelt? Ginge das einzig über die Sound.cfg oder müsste ein extra Script her?
-
Spontaner Gedankengang: Könnte auch sein, dass die nur Splines erkennen aber keine Pfade auf Objekten "finden".
Dafür gäbe es dann aber zu viele Beispiele wo eben das funktioniert. Ich denke Hamburg wäre da ein Paradebeispiel.
Man sieht dass sie teilweise recht weite Strecken hinnehmen bis sie auf einen Pfad treffen. Vielleicht sollte man sich genau diese Stelle genauer anschauen. Also da wo sie wieder auf einem Pfad sind.
Irgendwo gab es ja mal mit Pfadindexen wo sie immer den niedrigsten wählten. Vielleicht wäre das ein Ansatz.
-
Moin!
Ich hab ein paar Stellen wo ich mich darüber sehr wundere dass aussteigende Fahrgäste nicht zum nächsten Fußgängerpfad laufen sondern irgendwo ganz woanders hin, zum Beispiel über die Straße, durch des Bus oder wo auch immer, nur nicht zum Fußgängerpfad an der Haltestelle. Ich seh aber auch keine Regel nach der das läuft. Es passiert auf großen Kreuzungsobjekten genauso wie auf Spines oder Invis-Splines. Prominente Beispiele wären dafür die Haltestellen Stadtrandstraße/Falkenseer Chaussee in Spandau oder U St.Pauli Richtung City in Hamburg, Klein-Winternheim Bahnhof in Mainz. Wenn man wüsste woran es liegt dann könnte man es ja vermeiden...
-
JoyToKey ist eh quasi ein must have Tool wenn man viel in OMSI mit Buttons macht. Es ist halt leichter in OMSI ein Tastatur-Event festzulegen und es dann zu mappen, weil man sonst für jeden Bus fast ein eigenes Profil bräuchte, da jeder Bus so seine eigenen Trigger nutzt.
Dass das Force Feedback nur eingeschränkt geht fänd ich persönlich schon störend und wäre für mich ein Ausschlussgrund beim Kauf. Ich habe aber eh so die befürchtung dass im Gegensatz zum (teureren) Moza Wheel dieses hier deutlich schlechter verarbeitet ist. Habe bezüglich der Pedale zumindest schon schlechtes gehört.
-
So, nach langer Zeit gibt es eine Zwischenlösung. Ich hab ins init folgendes rein gemacht:
DFI_Timer in die Varlist nachgetragen und dann den ganzen Code im Frame in die Bedingung eingebaut:
(L.L.DFI_Timer) (L.S.Timegap) + (S.L.DFI_Timer) 10 >
{if}
****ursprünglicher Frame-Code hier****
{endif}
Idee ist aus dem X10-Daisy-Script und die Frametimes werden nun etwas weniger beansprucht. Ich sehe Ausschläge bei den Frametimes im Graphen, merke sie aber nicht mehr so stark wie vorher wo die Simulation immer kurz angehalten wurde. Es summiert sich aber dennoch, vor alloem wenn mehrere DFIs in der Nähe sind und verschiedene Zeilen blinken. Falls es einer performanter hinbekommt, jede Idee ist willkommen;-)
Durch die verzögerte Aktualisierung des Displays ist nun vermutlich auch der Bug weg dass manchmal sich mehrere Zeilen wild austauschen wenn die Abfahrtzeit gleich ist. Lösung bisher war in den entsprechenden Fahrplänen Sekundenbruchteile zur Abfahrtsminute zu addieren. Habs aber dahingehend nicht geprüft.
-
Das klingt nicht gerade danach als hätte das der Mitarbeiter ernsthaft geprüft. Eher in die Liste geschaut und als "Featurewunsch" weitergeleitet. Es ist immer noch nicht klar was da genau nun nicht gehen soll. OMSI schluckt im Prinzip ja alles was auch Windows schluckt und Rest lässt sich wunderbar umleiten , vor allem wenn es um Buttons geht. Da müsste das Ding ja ziemlich exotische Kommunikation haben um gänzlich nicht funktionieren, und es müsste explizit in den Spielen so einprogrammiert werden. Bezweifele ich ganz stark dass man das in den teils veralteten Spielen aus der Liste auch gemacht hat.
Irgendwer wird das wohl kaufen und dann wissen wir es. Ist an sich ja auch kein Ding das teil zurückzuschicken wenn es eben tatsächlich nicht geht. Es bedarf ja auch keine großen Begründung. Gefällt nicht, weg damit. So geschehen bei mir mit dem Landwirtschaftssimulator-Pack bestehend aus Lenkrad und Seitenkonsole. Das Lenkrad funktionierte technisch, was aber übel, genau wie die Pedale. Ging also alles zurück und die Seitenkonsole kaufte ich dann einzeln da sie prima auch für OMSI ist.
-
After a long time of using AUXI I'd like to suggest a few things AUXI could do:
1.
I think it would be a fantastic option if the traffic factor could be adjusted on the fly by AUXI depending on the current framerate. So let's say you have bad weather and OMSI struggles with fps were you normally would have no problem AUXI could reduce the traffic. But the user should be able to set the values at which fps it should be done and by which factor. Of course bad wheather could also be condition.
2.
As we all know OMSI is 32 Bit and gets into trouble when the exe gets around 3GB (WITH the 4GB Patch...) AUXI could monitor this and as an option reduce maximum timetable vehicles or/and traffic to prevent an overflow and white/black textures. A massive help would be if AUXI would be able to detect despawned busses to kick them off out of the memory just like their tour would have ended. If it is technicaly possible, AND if the vehicles would respawn again when it's time then it would bee a really massive help.
3.
I would appreciate if AUXI would detect if there are holidays on current date, so it could load another traffic profile. Also map detection woudl be cool in order to have seperate plans for different maps.
4.
I think we need the possiility to set up half-hourly profiles. I always get into the sitiation that I want a spike in the amount of passengers at 07:30, but I would have to take 07:00 or 08:00. 7 is too early, 8 too late and both would be too much.
5.
I think that is an easy one: on some maps there is no depot and as you know are the gas stations mostly bumpy and not really usable. It would be great if you just could refuel a fresh spawned new bus by AUXI. Or maybe even wash it;-)
-
Moin!
Ich versuche mir die Tastatur-Trigger beim NLC auf meinen Standard unmzubauen, indem ich den Trigger kw_wipermode_up fürs raufschalten des Wischer-Modus nutze und den Trigger cp_wischer_intervall_toggle zum runterschalten.
Die Modi sind:
0: aus
1: Automatik
2: Wischen langsam
3: Wischen schnell
Standardmäßig schaltet der Trigger kw_wipermode_up das ganze im Loop: bei der 3 angekommen geht es dann wieder auf 0. Das einzige was ich hier ändern will ist dass er den Loop nicht macht sondern dass bei 3 für den Trigger Schluss ist. Hier irritiert mich aber der allererste Absatz im Code und ich weiss ehrlich gesagt nicht wie ich ihn abändern muss um diesen loop zu vermeiden. Ich denke der Hund ist in diesen ersten Zeilen begraben. Jemand ne Idee:
Code
Alles anzeigen{trigger:kw_wipermode_up} (L.L.cp_wischer_einaus_sw) 3 + (S.L.cp_wischer_einaus_sw) 3 > {if} 0 (S.L.cp_wischer_einaus_sw) {endif} (L.L.cp_wischer_einaus_sw) 0 = {if} 0 (S.L.cockpit_wischer_drehschalter) {else} (L.L.cp_wischer_einaus_sw) 1 = {if} 1 (S.L.wiper_Automatik) 1 (S.L.cockpit_wischer_drehschalter) {else} 0 (S.L.wiper_Automatik) (L.L.cp_wischer_einaus_sw) 2 = {if} 2 (S.L.cockpit_wischer_drehschalter) 2 (S.L.wiper_speed) {else} 3 (S.L.cockpit_wischer_drehschalter) 3.5 (S.L.wiper_speed) {endif} {endif} {endif} (T.L.ev_Wischerdrehschalter) {end}
Wenn das ganze läuft dann geht es an den zweiten Trigger der das ganze in umgekehrter Richtung macht, also von 3 bis 0, ebenfalls ohne Loop.
-
Kommt auch vor dass sie an der zweiten Haltestelle Pause machen... Das hatte ich aber auch schon bei Tracks and Trips, und ich weiss nicht mehr wie ich das gelöst habe.
-
Das mit der Kachel ist wohl das was ich auch beobachte. Ich kann mir zig Anschlüsse anschauen und alle funktionieren. Komme ich aber selbst mit einem Bus da an ist die Chance da dass einer der Busse vorher los fährt.
Übrigens: das "wait until" ohne "always" hat den Haken dass wenn mal keiner aussteigen oder einsteigen will der Bus dann NICHT abwartet. Er wartet nur wenn er eh anhalten muss.
Geisterbusse kann man auch schön auf Vanilla-Spandau beobachten. Nachts am Depot tummeln sich zig Busse rum, aber auch sonst sieht man sie gerne auf der 92 / 137. Hinzu kommt dass die StnLinks derart unzuverlässig sind, dass man oft an der Stadtgrenze keinen Kollegen sieht, obwohl im 10min Takt da immer wer stehen müsste. Und pausiert man am Reimerweg sieht man gerne eine 92 / 137 aus Richtung Stadtgrenze kommen und an der Kreuzung verschwinden. Der Wagen kriegt es nicht von vom Hin- auf den Rücktrip zu wechseln. All das löst man mit klassischen Trips & Tracks.
-
Ich würd Dir trotzdem einen Umbau auf klassische T&T empfehlen. Allein schon wegen den Geisterbussen bei StationLinks die völlig außerfahrplanmäßig rumfahren und man sich fragt wo sie denn her kommen.... Und anderer Bugs.
-
Moin!
Ich beobachte auf Splines mit zwei oder mehr Spuren in die gleiche Richtung dass die KI manchmal beim Spurwechsel erst in die andere Richtung blinkt und dann erst in die Richtung des Spurwechsels. Das ist doch unschön und nervig und ich würde das gerne beseitigen. Meine Vermutung ist dass dies bei gemirrorten Splines passiert, aber zu 100 Prozent bin ich mir da noch nicht sicher. Kann dies jemand bestätigen?
Wie könnte man sich da behelfen? Leider kann man den Spurwechsel selten verbieten, da die Funktion "Überholen verboten" meistens nicht funktioniert.
Das Häkchen bei "mirrored" wegmachen würde die Richtung der Pfade umdrehen. Wie könnte ich ohne den Splinezug neu zu verlegen mir da behelfen?