Willkommen in der OMSI-WebDisk!
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:

= Englisch [EN],

= Deutsch [DE],

= Französisch [FR]. Wenn du die angegebene Sprache
nicht beherrschst, schreibe auf Englisch!
-
Naja bloß dann fährst du daran vorbei, dann ist der Haufen einmal da, nach einer Runde ist der weg, dann wäre er wieder da, …
Zufall ist zwar ne gute Idee, aber das kannst du schlecht auf einen Tag festsetzen. Das wird immer, wenn die Kachel erneut geladen wird, wieder ausgeführt.
Außer man nagelt den "Zufall" auf bestimmtes Datum fest, sodass das z.B. am 14.12 immer sichtbar ist, wann anders nicht. Wäre aber eine hochkomplexe Formel und auch nur ein Kompromiss. Fürs erste würde ich die Haufen so lassen.
-
Könnte man da vielleicht mit einer Zufallsvariable das Erscheinen der Schneehaufen steuern, die sich steigert Richtung Jahreswechsel und ab Februar/März dann wieder reduziert? An sich sind die Dinger ja gut, auch ohne Schneefall, aber vielleicht nicht jeden Tag und jede Minute.
-
Da wirds mit einer "einfachen" Anleitung nicht getan sein. Aufgrund der polnischen Bezeichnungen musst Du den Bus auch in Blender laden um zu schauen was überhaupt was ist. Vor allem bei sowas wie dem Dashboard hat man Spaß. Und dann das ganze in jeder Variante die Du haben willst. Deswegen ist das ein riesen Maniko dass da nichts out of the box geboten wird und man selber basteln muss damit die Kiste halbwegs im KI Verkehr brauchbar ist.
-
Ja, es funktioniert.
Allerdings ist der durch die ganzen Setvars so umfangreich, das sOmsi da recht schnell an die grenzen kommt.
Ich hab mir eigene Ki-Versionen erstellt, wo alles rausgeflogen ist was die KI nicht braucht, damit läufts ganz gut.
Hatte ich beim Vorgänger auch gemacht, Allerdings war die Kiste immer noch damit schwer, da hätte man viel tiefer mit dem ausmisten rein müssen (z.B. die ganzen Türvarianten). Habe auch KJ mehrfach angeboten diese Versionen zur Verfügung zu stellen oder rauszubringen, die Antwort war aber jeweisl großes Schweigen
. Nun, dann halt nicht. Bei dem hier hab ich mir dann die Mühe nicht mehr gemacht.
Neben Modell würden auch die Scripte Reduktionspotential haben, damit hab ich mich aber nicht beschäftigt. Viel könnte da aber sicher raus.
Ich finde es sollte standard sein dass man KI-Versionen anbietet. Der O530 ist bestes Beispiel dafür wie dringend das nötig ist.
-
Zu 32 Bit Zeiten (OMSI 1...) hatte ich OMSi in eine RAM DIsk gepackt und das flutschte wie Eis
Deutlich besser als von SSD. Mit OMSI 2 wurde das Loading schlechter, RAM DIsk hat da nicht mehr gelohnt...
Ich würde aber wieder mal probieren und mit den Werten rumspielen für den Texturspeicher. Oft genug hab ich da Probleme mit der 3GB-Grenze der exe, vor allem bei AI Listen mit viel Variation und Repaints. Meinen Trick mit dem zerschneiden von Umläufen wende ich auch nur ungern an.
-
Ich schätze mal man müsste die gesamte Bahninfraktuktur inkl Bahnübergängen als eine Kreuzung bauen und dann improvisieren damit realistische Signalbilder rauskommen... Und auch entsprechend mit dem Fahrplan tricksen. Ist wahrscheinlich zu viel Erwartung an Tante OMSI. Ich bin ja schon verzweifelt am Richtungswechsel von KI-Straßenbahnen und bin immer froh wenn Züge aus einer Seite reinfahren auf die Karte, dann halten, und dann weiter fahren;-D
Ums mal auf den Punkt zu bringen: viel mehr oder viel besser als der Bahnverkehr in TH umgesetzt wurde geht kaum. Und auch damit sind diverse "Phänomene" und Bugs nicht ausgeschlossen.
-
Signaltechnisch simuliert OMSI glaub ich auch nicht ansatzweise korrekt den Eisenbahnbetrieb. Ich weiss nicht wie das im konkreten Fall ist, aber ich nehme mal an das ist genau wie bei Ampeln und Kreuzungen, und nicht nach Fahrstraßen mit Freimeldung.
-
Ja, ist möglich dass das so läuft. So genau weiss ich das auch nicht;-D Auf jeden Fall knallt OMSI knapp über 3 GB Größe der exe durch, und meiner Beobachtung nach liegt das zu 99% an den Texturen. Nach einer dds-Kur bei wirklich schlecht texturierten Assets bessert sich das ja signifikant, und bekannterweise werden dds Texturen auch komprimiert im Video RAM gehalten. Und dennoch hilft es um die exe am Aufblähen zu hindern. Mir scheint es fast als würde da immer was im System RAM vorgehalten werden an Texturkram. Und OMSI vergisst schlecht: ein einmal erschienener Bus bleibt im Speicher samt Texturen bis sein Umlauf (!) beendet ist.
-
0 ist unlimitiert ja. Nur ob das sInnvoll ist stelle ich mal in Frage. OMSI ist ein 32 Bit Programm, wenn man das also nicht limitiert könnte das bei Karten und Bussen die texturfressend sind schneller zum Problem werden als einem lieb ist. Der Gesamtspeicherverbrauch darf bei OMSI auf keinen Fall 2 GB ohne und 4 GB mit dem 4GB überschreiten. In der Praxis heisst es dass es knallen wird knapp über 3 GB Größe der OMSI.exe. Daher würde ich empfehlen da 2048 einzutragen wenn man an der kritischen Grenze ist. Sonst aber gerne 0.
-
Hat eigentlich jemand schon das Mapping der Regen-Textur gefixt? Ich finds jedes Mal furchtbar wie gekachelt das aussieht. Die Textur kachelt eigentlich nicht, man kann sie wunderbar x-fach aneinander kleben und es sieht top aus. Nicht so auf der Scheibe.

-
Kann gut sein;-D Aber auch seltsam dass ich das nicht mehr so beobachte. Ich hatte viel mit verschiedenen Arten der Begrenzung experimentiert um zu schauen wie sich da die Frametimes verhalten und dabei ist mir eben das nicht mehr aufgefallen. In OMSI ist es tatsächlich so dass mal in Stein gemeiselte Gesetze nicht ewig und vor allem nicht überall gelten, und man immer wieder alles hinterfragen muss. So hält sich bis heute die Mär man müsse als Texturspeicher 2/3 des Video-RAMs eintragen... Nun ja, 2012 machte es vielleicht Sinn, heute wäre das Unsinn 
-
Scheint dieses Phänomen von OMSI zu sein. Begrenze mal deine FPS auf 120, dann sollten es wieder 60 sein.
Das ist aber in der Tat ein Phänomen. Ich hab (mittlerweile vor Jahren?) hier gelesen dass wenn man in OMSi die Framerate sagen wir mal auf 60 begrenzt, dann hat man generell niedrigere Durchnitts-fps als wenn man es auf ;Maximum belässt. Wohlgemerkt selbst wenn man die Grenze nicht erreicht. Konnte da snicht glauben, habs ausprobiert, und konnte das bestätigen. Mittlerweile, aber auch schon auf anderem System, sehe ich dieses Phänom nicht mehr. Also keine Ahnung wovon das abhängt...
Grundsätzlich rate ich in OMSI die Begrenzung auf dem Maximum zu lassen und dann im Treiber oder RivaTuner auf was brauchbares zu begrenzen, und zwar auf das was man im Schnitt so auf seinem System und bei seinen Einstellungen in den meisten Situationen erreicht. 60 ist hier dann sicher ein guter Wert. RivaTuner glättet dann besser die Frametimes als der Treiber. Das fps Limit von OMSI ist grausam schlecht was das betrifft.
Henry würd ich raten zunächst eben die fps-Begrenzung in OMSi hoch zu setzen und dann wieder in Grundorf zu schauen.
-
Aber apropo Betriebshof:
Ich finde es gut, dass man da den Halleffekt mit eingearbeitet hat. Mir war bislang kein Objekt bekannt, was diesen nutzte. 
Es gibt Brücken die haben das. Zum Beispiel in Spandau. Ich habe es allerdings irgendwann abgeschaltet da mir der Effekt zu künstlich erschien. An und für sich ist das aber eine gute Idee.
-
Was sollen die erwähnten Threads mir sagen? In dem einen geht es darum dass jemand die Box nicht eingebaut kriegt und Hilfe braucht. Im anderen funktioniert die Matrix garnicht. Bei mir ist die Box eingebaut, funktioniert im O530, O530G, den Ü-Varianten und im O530 FL Solo ebenso. Und beim FL G gibnts die erwähntze Thematik, die mir unlogiosch erscheint.
-
-
Ich hab das nicht geprüft, da ich den 4-Türer (und GL, und GÜ...) noch nicht verwendet habe, hab nur in der Datei des 4-Türers gesehen dass die Werte so sind wie beim 3-Türer. Und Dich hatte ich so verstanden dass das nur den 3-Türer betrifft.
-
Wunderbar, hat funktioniert. Danke!
Ich hab gesehen im 4-Türer sind die Einträge ebenfalls so konfiguriert, warum da nicht?
-
So weit ich weiss wurde das im Vorgänger auch nicht von der Community gefixt. Scheibe ist "szyba".
-
Da haben wir's wieder, wie beim "alten" O530 G, das Leuchten der ganzen Verkleidung hinten beim Nachläufer wenn das Innenlicht an ist. Genau wie bei alten Addon.

-
Dann gibts das erst ab Version 1.5, diese ist scheinbar noch in der Beta. Kannst Du beim Entwickler auf seinem Discord beziehen.
Auto Sync / Logging ist für LS nicht relevant. Natürlich ist Abschalten des Loggens leicht positiv für die Performance.