Beiträge von Chrizzly92

Kraft kommt von Kraftstoff. Ich glaube im Testzyklus schaffen es die karren auf unter 25l/100km, je nach Fahrzeug, Motorisierung und Topographie. ich denke so 30-35l sollten realistisch sein bei so einer modernen kiste, wenn man Sie nicht ständig im Kickdown bewegt. Der Verbrauch ist aber auch in OMSI von vielen Faktoren abhängig und schwer zu berechnen. 50l ist aber schon recht viel.

Bin so eine kiste allerdings noch nicht gefahren, massive Ersparnisse hast du aber trotz moderner Technik nicht. Da werden beispielsweise die Vorteile der Leichtbauweise von Kurbelwellenstarter, Batteriepacks und Abgasnachbehandlung schnell wieder zu Nichte gemacht.

Zitat von Luki3004

So, ich schäme mich ein wenig hier nun kleinlaut zugeben zu müssen, dass meine Grafiktreiber seit über einem Vierteljahr keine Lust mehr hatten sich abzudaten.
Das fahr das ganze Problem. Nun läuft alles wunderbar.

Ich danke euch allen sehr für die tatkräftige Hilfe!

Einen schönen Abend noch allerseits.

Der Grafiktreiber ist hier ggf. die Lösung gewesen, aber nicht die Ursache. OMSI Läuft auch auf Hardware von vor 15 Jahren. Da hat wohl irgendeine Anwendung Ressourcen wie Grafikspeicher reserviert, auf die OMSI dann nicht zugreifen konnte. Dumme Frage aber: Hattest du deinen Rechner einfach mal neugestartet?

hmn. Also Grundsätzlich bedeutet der Fehler, dass nicht genügend Speicher verfügbar ist um alle Texturen der Fahrzeuge zu laden. Dass kann mehrere Ursachen haben:

-Du nutzt sehr große Repaints aus der Community
-Du hast eine aufgeblähte OMSI-Installation

-Du hast den 4GB Patch nicht korrekt installiert

-Deine Systemressorourcen werden anderweitig genutzt

Fonts werden beispielsweise beim OMSI-Start geladen und bereitgehalten, der 4GB Patch benötigt ggf. Administratorrechte. Die Ursache kann man hier nicht wirklich genau nennen. Sofern du eine saubere OMSI Installation nutzt, würde ich ggf. den 4GB Patch erneut installieren und darauf achten, diesen als Administrator auszuführen.

schau nochmal im Bereich Komponenten -> Anzeige nach, welche Grafikardware du nutzt.

Auch wenn ich hier einen Beitrag zitiere, der schon ein paar Seiten zurückliegt, muss ich hier aber was klarstellen:

Zitat von James O'Neill

Der Vorgänger ist vor 16 Jahren entwickelt worden und hatte Starrachsen, der C2 ist mittlerweile auch fast 10 Jahre alt. Dann kannste auch sagen, ein O405 hatte aber..., und das dann mit einem C2 vergleichen. Sorry, aber einen Bus von 2018/19, der zu der Zeit eine komplette Neuentwicklung von MAN war, kann man nur schlecht mit anderen Modellen, die älter sind vergleichen. Sonst könnte ich auch sagen, 9 Meter Wendekreis bei nem Twingo? Never, der erste Twingo hatte doch einen riesengroßen Wendekreis. Merkste selbst, oder?

Grundsätzlich stimmt das schon - aber meinen Honda Accord Accord gabs vor 30 Jahren auch schon mit 4-Rad Lenkung, viele "moderne" Fahrzeuge nutzen die nichtmehr - Kann ich jetzt sagen dass 30 jahre später die Fahrzeugentwickler nix mehr können? Das man die Fahrzeuge nichtmehr vergleichen kann? So einfach ist das nicht und nur an einem Baujahr kann man keine technischen Grundlagen festmachen. Ja, man kann auch nur gleiche Techniken vergleichen - aber das hat nix mit nem Baujahr zu tun.

Zitat von James O'Neill

Nope, da steht tatsächlich Wendekreis.

Das ist dann aber auch tatsächlich Falsch. schon rein Physikalisch geht das nicht, denn der Wendekreis beschreibt die Kreisbahn, die Das Fahrzeug an seinem äußeren Punkt bei maximaler Einlenkung bildet. Angegeben wird dabei IMMER der Durchmesser. Ein Fahrzeug mit 12m länge rotiert im optimalsten Falle um seinen Mittelpunkt (was unrealistisch ist) und würde selbst dann nur einen Wendekreis von ca. 12m haben. Weiterhin gibts dann noch den Spurkreis, welcher den Kreis beschreibt, den das Kurvenäußere Rad bei vollem Einschlag bildet. Dieser ist oftmals etwas kleiner als der Wendekreis.

Die Angabe ist also grundsätzlich falsch, selbst wenn das bei MAN so steht. Ein Wenderadius von um die 11 Meter ergibt also einen Wendekreis von 22 Metern, beim Gelenkwagen von 23 Metern. das sind übrigens keine besonders hervorzuhebenden Werte, ein aktueller C2 schafft reichliche 21 Meter als Solobus und knappe 23 als Schlenki.

Ich weiß, du bist MAN Fan aber so besonders sind die Kisten nun auch nicht, Neuentwicklung hin oder her. 11 Meter Wendekreis übersteigen die Fahrzeuglänge und damit ist das schon grundsätzlich nicht möglich. Beim Invradius muss man also allerhöchstens für nen anderen Radstand kompensieren, sonst fährt und lenkt sich die Kiste wie jeder andere Bus auch.

Edit: Der Schritt zu wirklich kleinen Wendekreisen wird im übrigen kommen - und zwar dann, wenn die Busse nichtmehr geschoben werden. Ein großer Lenkwinkel würde sich beispielsweise über Radnabenmotoren an der Vorderachse realisieren lassen.

exakt. dein script würde um 14 uhr nochmal die hauptglocke läuten. wenn diese 10 MINUTEN läuften soll, musst du auch 10 minuten aufschlagen. in deinem fall würde sie nur 6 minuten läuten.

Auch zum Sound und dessen Funktion findest du hier in der Webdisk oder im OMSI Wiki Antworten auf deine Frage.

du solltest dir eventuell mal das OMSI Wiki anschauen und dich zu den Scripts belesen. Im Endeffekt stehen alle diene Fragen doch oben in dem 10-Zeiler drin. Ja, das ist auf den ersten Blick erstmal unverständlich, es wird sich hier aber keine die Mühe machen um jedesmal die kleinsten Scriptfragen zu beantworten.
OMSI nutzt die polnische Rückwärtsnotation als Syntax, der Operator kommt also nach den Werten - anstatt "2 + 3" erwartet das Script "2 3 +" Das hat den Vorteil, dass sich das Script wie ein Buch lesen lässt.
(L.S.Time) liest die Uhrzeit in Sekunden aus, gerechnet ab Mitternacht des aktuellen Tages: Klick

die sekunden werden dann durch 60 geteilt, um auf Minuten zu kommen - das ganze wird dann im Register 0 gespeichert.

dann wird dieser Wert überprüft: Wenn größer als 725 und kleiner als 735 als auch wenn größer als 1085 und kleiner als 1095, dann läute die Hauptglocke.

Die Werte 725,735,1085 und 1095 sind quasi die Minuten, in denen die Hauptglocke läutet. Teilst du die durch 60, kommst du auf die Urzeit - 12 und 18 Uhr.

Alles, was mit einem Hochkomma beginnt ( ' ) ist ein Kommentar und wird von OMSI übersprungen. Zeile 8 Ist nur ein Kommentar.

Na mit sicherheit. brauchst im zweifel ein kleines script, was im INIT oder - wenn das nicht richtig klappen sollte - im Frame einfach den Sollwert schreibt. Direkt eine Constfile auslesen geht nicht - du kannst aber per script sowas machen wie (C.L.Sichtbar) (S.L.Object_Visible) - und dann in der sco Object_Visible als Triggervariable für [visible] nehmen.

EIn Textfeld ohne Beschriftung wird normalerweise Transparent dargestellt. Bei dir scheint die Zuordnung der Materialien in der SCO nicht zu stimmen.

zeile 17. der sound wird alle 37 sekunden wiederholt. Die Zahl kannst du entsprechend verkleinern.

naja was heißt auskennen - ich hab abgesehen von ein paar Arduino-Sachen und nen kleines Plugin für OMSI keine Ahnung von C++ und arbeite eigentlich nur mit Blueprints. aber ja, beschäftige mich seit Jahren nebenher mit der Unreal Engine und so ein paar Grundlagen sind mir durchaus bekannt.
So sachen wie Eye Adaption sind ja durchaus praktisch wenn man in einem Shooter in eine Höhle läuft und sich die Augen erst dran gewöhnen müssen - aber in einer Simulation ist sowas nicht unbedingt vorteilhaft, da sind wir uns hier wohl alle einig. Aber krasse Effekte sind heute ja Kaufargument.Manchmal ist weniger halt mehr, je nach Genre und Setting.
Edit: und manche Einstellungen sind auch nicht wirklich Sinnvoll. Man kann ja beispielsweise die Überstrahlung generell deaktivieren - aber damit entfernt man diese ja auch bei Sachen, wo eine Überstrahlung wichtig ist, wie bei einer LED Matrix oder Lichtquellen. Die Grafiksettings und Einstellungen wirken halt so "gewollt und nicht gekonnt", irgendwie ohne System - hauptsache man kann etwas Einstellen, auch wenns ggf. gar nicht Sinnvoll ist. An stellen, wo man aber Ansetzen können sollte, fehlen die Entsprechenden Settings.
Ich hoffe ja, TML arbeitet hier im laufe des Early Access an solchen Sachen, damit dann in Phase 2 und 3 auch Modder von den entsprechenden Einstellungen profitieren können.

hab mein Feedback schon vor Jahren da gelassen. Letztendlich ist Grafik halt immer irgendwie subjektiv und man kanns nicht jedem recht machen. am besten wäre es , ein "Fortgeschritten" Tab bei den Grafik-Settings zu implementieren und einfach jeden Regler, den es im Post Processing gibt, verfügbar zu machen. Nehmen wir beispielsweise deinen Workaround mit der Eye Adaption - man könnte dann in Kombination "einfach" die Helligkeit des Skylights anpassen und dunkle bereiche so grundsätzlich etwas aufhellen. gibt viele Wege zum Ziel.

da kommt man aber als 0815 user leider nicht ran. Farbtemperaturen und co. kannst du in der Engine entsprechend einstellen, man müsste das aber explizit zugängig machen, damit man da über die settings selbst dran rumspielen kann.

Zitat von gt670dn

war denn jemand von hier da?

nein - ich habs mir aber in der selben Nacht nebenbei auf deinem Twitch-Kanal angehört/angeschaut. zu meckern hatte ich nix, wirkte alles recht durchdacht und gut strukturiert. ich hab aber auch in OMSI oder anderen Spielennoch nie Fahrpläne erstellt und bei CIM2 funktionieren meine Strecken auch eher schlecht als recht .Ich kann das also nicht wirklich objektiv bewerten. Mit dem Fahrplan-Editor würde ich allerdings tatsächlich eher warm werden als mit dem Editor selbst - das ist einfach grundsätzlich besser beschrieben, besser strukturiert, keine kryptischen Buttons mit 5x5px icon.

Zitat von Der Omsi 2-Zocker

Auf Facebook bräuchte man Leute wie Schleswig-Holstein oder Lµkas, die hart durchgreifen. Aber stimmt. Lieber wartet man noch ein paar Tage und bekommt ein Produkt mit weniger Fehlern als die Entwickler mit Releaseanfragen zu nerven.

oder einfach nen Pseudo Releasetermin so weit in der Zukunft, dass nicht jede Woche die gleiche Diskussion entsteht. Aber die Community ist ja schuld...

ist dann aber steuerungsunabhängig und das müsste man dann immer umstellen.

wichtig ist noch eine adaptive Änderung der Empfindlichkeit Anhand der Geschwindigkeit. Im Stand wäre von ganz links nach ganz rechts einmal das lenkrad von ganz links nach ganz rechts, bei 70 kmh darf aber nur noch ein Bruchteil des theoretisch möglichen Lenkwinkels möglich sein.

ja, das stimmt natürlich. Ich hab das jetzt nur aus einer rein technischen Sicht betrachtet - würde sogar mir selbst zutrauen, sowas in der UE4 umzusetzen, wenn ich mir die OMSI herangehensweise abschaue. Häufig hält sich ja die Behauptung, dass Gameengines wie die UE4 nicht für Simulationen geeignet sind, darum wars mir wichtig klarzustellen, dass selbst im Standardcontent nicht weniger Möglichkeiten bestehen als in OMSI. Ich glaube auch, es muss da gar nicht 100% korrekt sein, solang es authentisch wirkt. Und das bekommt man auch hin, selbst wenn man nicht alle Kennlinien kennt. Zusätzlich könnte man diese "unbekannten" auch als Variable "exportieren" und einstellbar machen - wie die Constfiles in OMSI.