Beiträge von wurstbrot

Es ist völlig egal wie gut oder schlecht Dein PC ist. Wenn die 4 GB Grenze erreicht wird ist Sense. Da hilft es nur einerseits seinen Content sauber halten und optimieren, KI reduzieren oder auf bestimm,te Busse oder Karten zu verzichten. Alles auf einmal geht einfach nicht.

Je ein Repaint für je einen Wagen... Da wird es dann ganz schnell voll. Nutze vor allem für Wagen ohne Werbung ein und das selbe Repaint um Speicher einzusparen. Dann aufpassen dass vor allem in der KI wie eben erwähnt keine TGA Texturen sondern dds verwendet werden. Alternativ oder ergänzend maximale Anzahl der fahrplanmässigen Busse deutlich niedriger stellen.

Hin zu kommen anscheinend kaputte Fonts:

75 12:47:58 -  -   Error:           The file "Fonts\ANX_M_SD - ?????.oft" could not be loaded!
76 12:47:58 -  -   Error:           In "Fonts\ANX_NS.oft" there was an error in line 146!
77 12:47:58 -  -   Error:           The file "Fonts\ANX_S - ?????.oft" could not be loaded!
78 12:48:14 -  -   Error:           In "Fonts\BKKFUTAR_BUSE_-1_8.oft" there was an error in line 197!
79 12:48:20 -  -   Error:           In "Fonts\Buse_15x6 (2).oft" there was an error in line 85!
80 12:48:56 -  -   Error:           In "Fonts\FGY_M.oft" there was an error in line 32!
81 12:48:59 -  -   Error:           The file "Fonts\Font_D?nn.oft" could not be loaded!
82 12:48:59 -  -   Error:           The file "Fonts\Font_D?nn_Seite.oft" could not be loaded!
83 12:49:06 -  -   Error:           In "Fonts\IBIS-CTB.oft" there was an error in line 110!
84 12:49:08 -  -   Error:           In "Fonts\InfotainmentNumber.oft" there was an error in line 1!
85 12:49:09 -  -   Error:           In "Fonts\ISA_26_0 F.oft" there was an error in line 3!

Zur Eingrenzung diese Fonts entfernen und Abhängigkeiten die diese nutzen, und dann sich um den C2 kümmern. Mir scheint da zumindest was mit der Kasse/Drucker kaputt zu sein. Am Besten einen ungemoddeten C2 ausprobieren.

Sippel macht mobil

Map. Mainz

Bus: Volvo 7700(A) Facelift

The licence plates have to be on the repaint? If so then good night OMSI when 50 volvos are on the map each with it's own repaint...

Also the licence plates have no light textures and no light sources, so they are totaly dark at night.

And could you please add

[CTCTexture]

aerateur

aerateur.dds

to the model files in order to be able to repaint this texture?

At least I would really appreciate AI-versions of the busses with reduced model files, textures and scripts. You just don't need e.g. a 4K floor texture in an AI bus. There is much room for improving performance and reduce memory usage for AI.

The font for the destination display does not have an "/" and dispalys an "!" instead. It seems that it's only missing in the oft-files, the bmps do contain the character.

German characters like Ü, ü, Ä, ä, Ö, ö, ß are also not displayed. Reason here is that the oft-files are coded in UTF-8 and not ANSI. You have to convert them all to ANSI in order to make it work. Character ß is I think missing anyway, the others should work after conversion. This is an important issue in OMSI and WIndows 11, you have to take care that you don't roll out UTF8 coded files. And I see this problem affects ANY file like scripts, model files, sound files etc.

Irgendeiner der Sounds aus dem bereich Heizung/Lüfter hört abrupt auf wenn die gewünschte Temperatur erreich ist, das klingt komisch. Mir ist es noch nicht gelungen zu identifizieren welcher Sound das genau ist, habe aber misc/klima_loop.wav in Verdacht. Es gibt ja ein "aus"-Sound, aber der scheint nicht getriggert zu werden.

Ich glaube das ist schon klar dass diese CPUs gerade in OMSi ihre Vorteile ausspielen können. Es wäre aber interessant zu wissen wie viel Plus an Leistung das wirklich ist. Aber nicht verglichen zwischen verschieden getakteten Prozessoren und dann auch noch verschiedener Generationen sondern wirklich eins zu eins eine non-X3D CPU mit einer X3D, aus gleicher Generation, mit gleicher Kernanzahl, bei gleichem Takt.

Zitat von IREgio612

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.

Zitat von some1

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

Zitat von PingPong

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.

Zitat von IREgio612

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.