= Englisch [EN], 
= Deutsch [DE], 
= Französisch [FR]. Wenn du die angegebene Sprache nicht beherrschst, schreibe auf Englisch! "Emit" ist bei allen Materials schon auf 0..
wie exportierst du das ganze in richtung o3d? erst zu *.x und dann regulär mit dem Converter oder nutzt du einen anderen Weg? Wenn du den regulären Weg über eine *.x-Datei gehst, kannst du die Materialwerte auch in der Datei selbst anpassen.
die "Emit" Werte musst du ebenfalls auf 0 setzen.
In den OMSI EInstellungen im Reiter Grafik(Erweitert) bitte unten Links die Effekte aktivieren.
Kann natürlich sein, dass ich mich täusche, aber es weckt nicht viel Hoffnung, dass ein System mit der betrieblichen Komplexität - vor allem was die Fahrzeugbewegungen angeht - von Karlsruhe dort umsetzbar sein wird. Vergleichbar wäre z.B. der Y-Verkehr in Hannover mit ständigem Kuppeln und Flügeln. Es wirkt auf mich von der Gesamtstimmung nicht "sandboxig" genug. Vielleicht kommt das aber noch, wer weiss, der Editor ist ja noch nicht draußen.
Was ist denn dann mit Spurbussen in OMSI, mehreren Entwertern in OMSI, genügend Ein/Ausstiege für 5-Türige Lions City G, Support für Bus-Züge oder der nicht ausreichend ausgeprägten Physikmöglichkeiten für Fahrzeuge wie Kartoffelphantoms KT4D in LOTUS? Es ist leicht, die Vorteile hervorzuheben und dabei die Nachteile auszublenden. Es gibt in OMSI keinen Support für mehrere Entwerter, weil es so damals in Berlin nicht benötigt wurde. Warum steigen die Fahrgäste nur im ersten Wagenteil ein? In Berlin ist einstieg nur vorn, war damals also gar nicht relevant dass das auch hinten geht. In Tramsim kann man nicht Rückwärtsfahren, weils halt nicht benötigt wird. Marcel hat also auch da nur das umgesetzt, was Grundsätzlich nötig war und dabei nur bedingt andere Situationen bedacht. die GT6N Physik in LOTUS mag ja ganz nett sein, aber was ist dann mit dem KT4D? dessen Schub/Zugstangenlenkung ist so nicht umsetzbar. Hier erkennt man also auch wieder klar, dass der Fokus auf die Funktionalität des Hauptcontents gesetzt wird und nur bedingt andere Systeme beachtet werden. Soll ich deswegen jetzt sagen: "LOTUS erweckt nicht viel Hoffnung was vernünftige Fahrzeugphysik betrifft" ?
In Tramsim ist das bisher nicht nötig gewesen und wird nachgereicht, wenn der passende Content erscheint. So wie der Doppelgelenkbuspatch mit Darius' AGG in OMSI.
bezogen auf das gebotene Szenario, das nunmal "Straßenbahn im laufenden Betrieb übernehmen und fahren" lautet.
und genau das ist der Punkt und hier nimmt sich weder LOTUS, OMSI oder Tramsim etwas. es wird vordergründig das Umgesetzt, was für den Content notwendig ist und nicht dass, was eventuell irgendwann mal notwendig sein könnte, vorallem wenn man bedenkt, dass zum aktuellen Zeitpunkt Modding sowieso noch kein Thema ist.
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.
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:
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.
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.
