Beiträge von Crashdump

Zitat

The busstop shelters and busstop signs are from this map.....

Thanks for the feedback.

In the meantime, I have used a temp. solution, which can bee seen as a very dirty hack:
I created the needed UK-folder and copied an east-german(standard install stuff) into this folder an renamed it to the UK-object-name.
Again, that's dirty hack, but using this workaround, I was able to drive the map from start to end....which took a "while"...

For the strange textures, I have used standard-ones.

However, I see that you have updatd the map, so I will download it and again and will report how things are going.

Wenn Du gar nicht mehr in das Hauptmenu kommst, gibt es da eine rabiate Methode die vieleicht helfen kann:

-im OMSI Hauptordner die "options.cfg" umbennen in z.B. "options.cfg.bak"
-OMSI starten=
Es erscheint beim Start eine Zugrifsverletzung...egal..einfach mit "OK" weg klicken
-danach sollte OMSI mit default Settings in Englisch starten.
-danach alle Einstellung erstmal grob wieder anpassen (Options)
-am Ende OMSI beenden

Danach hast Du ene neue "saubere" "options.cfg"

Alternativ:

In der bestehendenden "options.cfg" den Eintarg bei :

[last_map]
....

in z.B.:

[last_map]
maps\Grunddorf\global.cfg

ändern....vieleicht reicht das schon.

Zitat

....Winsenburg HBF, Goetheplatz, Stadtbad , Ahlheim 3.1.1 HBF und auch auf
AH-Laurenzbach an den HBF,Mainz HBF , auf ganz Berlin X10 & Aachen...

...Sind genau die Orte, die man mit einem "schwachen System" meiden sollte vor allem mit einem Gelenkbus.
Beipiel Winsenburg-HBF oder Laurenzbach-HBF:
Hier werden extrem "grosse" Objekte und den Speicher geladen. (Wäre schn wenn man diese Objelte irgendwie optimieren könnte)
Auf einem "nicht optimalen" System dauern solche Objekt-Loads eben länger als die üblichen Standard-Objekte.
Es muss mehr Speicher reserviert werden, und dieser grosse Speicherbereich wird ständig neu beschrieben und abgefragt.(Man bewegt sich ja)
Das dauert bei einer langsamen CPU UND langsamen Speicher-Bänken länger als "geplant".
Darunter leiden dann andere kritische Threads...z.B. die Echtzeitberechnung von deinem Bus....der dann evtl. anfängt zu hüpfen.
Oder schlimmer noch, OMSI hängt sich auf (Freeze), weil ThreadA die Antwort von ThreadB verpasst hat (=Deadlock...jeder wartet auf jeden

).

Ist wie mit einem Lieferanten, er hat seine Tour und kommt klar.
Aufeinmal soll er das doppelte in der gleichen Zeit abliefern=
Viele Packete landen and der falschen Adresse(Speicherzugriffsfehler) oder kommen erst gar nicht an(Deadlock).

@VOLLG"S

Ich mache mir mal ein paar Gedanken zu meiner Performance-Geschichte, und wie ich sie halbwegs im Griff bekommen habe.
Dann schicke ich Dir das ganze als PN, und Du kannst damit machen was Du willst.
Die Sache mit den Hamburgern packe ich auch ich mit rein...ist eigentlich nur ein einfaches Anpassen der AI-List.
Bin eben kein OMSI-Crack. Aber vieleicht hilft es ja jemanden oder jemande.

Meinst Du die Sache mit den Hamburger-AI-Busssen oder allgemein

"Allgemein" heisst also, "wie kriege ich OMSI halbwegs gut zum laufen, selbst wenn mein System extrem unter den Mindest-Vorraussetzungen ist".

Zitat

Doch, der MAN NL_NG ist ein Standard Bus. Also ich meine den Ordner. Im Ordner heißt der dann EN92 und GN92.

Ok, ein "Standard" Bus, aber mit allen rum und dran, auch wenn es sich bei den Standard Bussen mit Extras in Grenzen hält, ziehen die mehr Performance als reine KI-Buse.
Beim Hamburg Addon gibt es die ja, mit einigen Einschränkungen:
-low Poly
-kein Dashboard, nur eine low statische Textur...daher kaum Scripte involviert
-abgespeckte Sound Features
-man kann nicht zu einem "reinen" KI-Bus wechslen via ALT-Menu.
=
Diese Art von KI-Only-Bussen sparen Unmengen an CPU und Video-Memory und laufen selbst auf meinem System im Städtedreieck ohne extrem die Performance zu drücken.
Die standard ENs/GNs hingegen sind bei meinem Setting auf solch einer grossen Karte nicht einsetzbar (Ohne das OMSI eine Slide-Show wird).

Zitat

... Außerhalb von Omsi funktioniert die Tastatur ganz normal,....

Bin jetzt kein Experte, aber einfach mal ne Idee:

Benutzt Du eine USB-HUB ? Die sorgen manchmal für derartige Probleme.
Ok, dieTastatur funzt ausserhalb von OMSI, wo evtl. nicht soviele USB-Komponenten konkurieren.
Wärend OMSI läuft ist die CPU am Max-Anschlag (also weniger Cycles frei für z.B. Interrupt-Handling (z.B. der USB-Schnittstellen).

Also würde ich es so probieren:

"If" USB-HUB "then" versuche es mal direkt am USB Port des Rechners
"If" ist schon direkt am Rechner "then" versuche einen anderen Port...evtl mal die Ports durchtauschen.

Zitat

Ich vermute mal das noch mehr KI Busse im Internet zu finden sind.

Danke für die LIste. Ich werde mich dann mal auf die Suche nach diesen reinen KI-Bussen machen.
Vor allem "GS" als Old-School'er kling interessant. Nicht immer nur KI-Schuhkartons auf der Map.

Also gibt es per OMSI-Default keine reinen KI-Busse...hätte mich sonst gewundert.

Zitat

...mit den Standard NG KI Bussen in der Ailist.

Ich hatte diesbezüglich im SDK-Thread mal eine Anfrage gemacht. Es ging um "reine/dedizierte" KI-Busse.
Also Low-Poly und nix Dasboard.
Bisher scheint es doch so zu sein, dass nur das Hamburg-Addon dedizierte KI-Busse bereitstellt. (?)
Welche sollen denn das für die NG's sein ?
Gib't die irgendwo zum Download ? Habe ich was verpasst ?
Gerade auf meinem Low-End-System, wäre dieses eine schöne Alternative zu "überhaupt keine KI-Busse"(wie ich es im Moment auf den meissten Maps gesetzt habe).

>Mit diversen Tools die CPU und Thread Auslastung auslesen können.
Thread-"Auslastung" könnte schwierig werden, evtl. ein Tool zum messen des CPU-Core-Cache bzw. Cache-Fill-Rate könnte die Antwort bringen.
Zur Thread(s)-Auslastung müsste man OMSI wohl durch einen Debugger laufen lassen....wäre ein bischen viel Akt und irgendwie auch Reverse-Engineering.
Zumal ein Real-Time-Debugger auch noch mal die Code-Execution voll ausbremmst und damit die Werte verfälscht.

Ich wollte eigentlich nur den Tip mit dem FPS-Regler geben.
Soll heissen, solte OMSI trotz sämtlichen Vesuchen/Tweaks immer noch zu hakelig laufen, einfach mal the FPS-Regler RUNTER drehen...
Hat bei mir Wunder gebracht, wird aber wohl nur auf Systemen helfen, wo die CPU und/oder CPU-Cache der Flaschenhals ist.

>Zielwiederhohlungsrate kannst du auf 200 stellen. Wirst du nie erreichen.

Mal etwas hierzu aus eigener Erfahrung:
Mein (Ersatz-)System ist völlig unter-dimensioniert, 1.8 Ghz AMD auf einem Laptop mit Umschaltbarer AMD-GPU.
Also...worst case....

Wie auch immer, ich kann OMSI2 locker auf dem Teil zocken, muss aber natürlich extreme Abstriche in Kauf nehmen.

Ok...das war die Vorgeschichte, nun zu den "Ziehlwiederholungsraten":
Beim meinen verzweifelten Tests auf der Suche nach einem Kompromiss, habe ich festgestellt ,dass die Option "Zielwiederhohlungsrate" mehr
zu sein scheint, als ein simpler Frame-Rate-Limiter.
Ich habe ihn momentan auf "30" stehen (Ich habe Max-Frames ca. 20-25...wenn's gut läuft).
Sobald ich diesen Regler hoch drehe (80+), fängt OMSI an in Zeitlupe zu laufen (5 FPS max....Tastatur reagiert erst nach einigen Sekunden).
Drehe ich wieder runter auf 30-35 FPS, läuft wieder alles flüssig...naja...wie gewohnt halt.

Kann es evtl. sein, dass dieser Regler die FPS begrentzt UND evtl. die Anzahl der parallelen Threads erhöht ?
Das würde das 5-FPS Problem erklären, da meine CPU ja extrem unter den Mindest-Vorraussetzungen ist.

Heisst also Regler rauf = OMSI "denkt": Starkes System = mehr Threads in den CPU-Cache.
Regler runter = OMSI "denkt : System ist low-end, da will ich mal nicht die CPU mit zu vielen Threads zumüllen.

Also meine Vermutung in Kurzform: Der FPS-Limiter kontrolliert auch das Anzahl der Threads per Core.

Anders kann ich mir dieses Verhalten nicht erklären.

Dir fehlen die BMO Objekte, wie man im Log sehen kann.
Fehler gegoogelt und .....http://www.mediafire.com/file/…objects+-+BMO+Objekte.rar

4GB patch hast Du ja drauf. (Warum auch immer OMSI2 immer nocht nicht mit LAA-Option compiliert wird, werde ich wohl nie verstehen...egal...)
Evtl. mal "Maximalen Speicherplatz für hochaulösende Texturen vergrössern" (Grafik/erweitert-Tab) ?
Ich glaube 2/3 vom gesammt Video-Memory ist ein guter Richtwert bei Omsi2.
Sichtweite reduzieren spart auch eine Menge Ram.

Nach langen probieren, komme ich mot denen ganz gut klar:

Damit die Spiegel auch in der Standard Sicht funktionieren, habe ich alle "[add_camera_reflexion]" nach "[add_camera_reflexion_2]" geändert.
Wahrscheinlich müsste man nur die des linken Spiegels ändern...ich hab aber alle genommen...funzt...kaum impact auf meiner lahmen Kiste.

I am just a OMSI-internals beginner...so...a rookie

.

But I might have one idea, why all went fine for a while, until black/fall-back-to-default-repaint.
Could it be a video-memory-size issue ?

I mean, all has been loaded up fine in memory....repaints are working.
The you are driving around the map, and during driving...more and more textures+repaints are loaded in video-memory.
I don't know how OMSI reacts, when it comes to low-video-memory issue.
Maybe using "memory-cheap" default-repaints are some kind of a OMSI-internal pre-caution-logic.

Another idea...but this does not explain, why it works for a while, and then stops:
There are some "special...non-pure-ASCII" characters within you AI-list...I don't know if this might lead to problems.
Again...I am an OMSI rookie...just sharing my thoughts...

Works great

Beside that it looks much better than default, it's now so much easier to check the current speed....esp on smaller screens, like on my notebook.

Ich konnte mit der Sufu und hier im Thread nichts darüber finden, daher mal eine Frage.

Ist es gewollt, dass die Scheiben in den Solo-Bussen niemals beschlagen ?

Ich habe es am 99-Gelenk vs. 98-Solo im selben Spielstand getested.
Bei dem G99 beschlagen die Scheiben, wenn die Witterung+Innentemperatur passen.
Beim 98/97er...Scheiben bleiben alle klar.

Das gleich gilt auch für den C2, Gelenk=Scheiben beschlagen....Solo=immer klare Sicht+der übliche Sabber auf der Scheibe nach längeren Fahrten.

Bin kein Script-Profi, aber in den Solo-cfg's scheint die entsprechende "Beschlag-Textur" definiert zu sein.
Also scheint das Beschlag-Script/Macro in den Solo-Bussen nicht zu laufen.

Gibt's da einen Trick wie man das bei den Solo-Bussen aktivieren könnte ?
Oder ist das gewollt (z.B. Beschlag-Texture passt nicht zum Solo-Modell o.ä.)

Ich meine, das hat mal funktioniert....bin mir aber nicht sicher.

Fehlt eigentlich nur noch ein "Eiskratz-Mod"

Edit:

Ok...ich habe die Lösung selbst gefunden.
Bin zwar kein Script-Mensch, aber mit ein bisschen Logik, kann man sich durchaus durch die ganzen (relevanten)Scripte+Abängigkeiten durchwuseln.

Also, die Beschlag-Logik ist im Heizunsscript definiert.
Die Solobusse benutzen eigene (abgespeckte ?) Heizungsscripte, wo keinerlei "Beschlag-Logik" implementiert ist.
Ich habe dann mal ein bisschen rumgebastelt und die Logik in den Solobussen (Heizunsscripte) reingeprügelt.

Ok, wie ich es mir gedacht habe, funktioniert das ganzen nur teilweise.
-Frontscheibe und Türflügel beschlagen, der Rest behält die klare Sicht (alles was wohl zum Passagier-Bereich zählt...ausser die Türen eben)

Ich gehe mal davon aus, das dieses gewollt ist, und quasi ein Nebeneffekt des nachträglichen Implentierens der Solo-Busse in das 3Gen-Addon ist.
(Solo-Bus = kostenloses Bonus-Fahrzeug mit Einschränkungen)
Es wäre wahrscheinlich ein hoher zu Aufwand gewesen die Solo-Passier-Bereiche auch der Beschlag-Logic anzupassen...oder ?

Wie auch immer, ich kann mit dem Schönheitsfehler leben, und habe eben nur die Frontscheibe+Türen vernebelt.

Geniale Sache der Mod.

Ich habe es mal im 3gen-99er getested, un alles funzt.

Nur 3gen-C2, fehlt ein "endif" im Spoiler:
So, hat es bei mir geklappt:

Ok...ok...Ich sollte mir erst einmal die Basics anschauen.
Ich war ja schon glücklich im Editor eine Betriebstanke zu plazieren.
Habe wie wild herumgeklickt, bis "KEYBOARD-N" mal ein neues Objekt erzeugt hatte.
"N" sprang immer in der Objekt-Liste auf Folders beginnend mit "N".

Naja langsam komme ich da schon rein(lesen...lesen...lesen...probieren....nicht klappen wollen...noch mehr lesen...wieder probieren).
Immerhin habe ich mir gestern, dank einiger hilfreicher Leute im Forum, eine eigene AI-list mit Hamburger-Spar-AI-only Bussen für diese Map zusammen gedengelt.
Spart enorm Performance auf meinem lahmen System.

Aber das wird jetzt zu Off-Topic, es geht ja um die Map....und die ist immr noch genial.

Zitat

"Hier und da mal" geht bei den dynamischen Pfeilen nicht. Da gibt es nur
ganz oder gar nicht. Du kannst sie dir selbst einschalten, indem du den
Eintrag [dynhelperactive] in die global.cfg einfügst. Fraglich ist
jedoch, ob der Baustil der Map passt, denn die Pfeile sind abhängig von
den Blinkereinstellungen der Pfade.

Ok, ich wusste nicht dass man nur zwischen "alles oder nix" hin- und herschalten kann.
Die Idee kam mir beim Fahren der Bottrop-Fiktiv-Map. Dort sah es so aus, als ob nur einige dynamische Hilfpeile an "zweifelhaften" Stellen vorkommen.
Also viel "gelb" und nur wenig "orange".
Ok, wenn es aber ein global Map-Flag ist, dann ist er Baustil natürlich entscheident.

Mitlerweile geht es aber auch. Man muss die Routen eben ein- zweimal abfahren und gut is.

Trotzdem, danke für den Tip

, evtl. spiele ich mal auf anderen (kleineren) Maps damit rum.

Zitat

Problem mit Map

Readme lesen und verstehen.

Warning: Szenerieobjekt wurde nicht gefunden: Sceneryobjects\backgroundsounds\nature_cube.sco
(http://aussiex.org/forum/index.php?/file…kground-sounds/

Link ist übrigens auch auf Seite 12 in der Readme.pdf zu finden(...und noch vieles mehr).