Beiträge von Chrizzly92

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!

    An der UE4 ist nichts auszusetzen, die ermöglicht sehr viel und hat eben schon viele Basis-Features.

    Was man draus macht ist die Frage!

    Die Belichtung gefällt mir auch nicht. aber beim FBS z.B. kann man das sich selbst einstellen

    Ich habe mal irgendwo irgendwann gelesen dass die UE eigentlich nicht für Simulationen geeignet ist, zumindest was die Simulation von Fahrzeugen angeht.

    Wo? Wenn ich das im Netz irgendwo schreibe, hat das noch lange keinen Bestand. ;) Setz dich mal beim Bus Sim 18 - der ja wirklich auf casual ausgelegt ist - in den Nachläufer eines Busses und lass im Multiplayer einen Kollegen fahren. wirkt nicht weniger authentischer als in OMSI. Richtig ist, dass die Funktionen und Blueprints, die von der UE bereit gestellt werden, nicht für eine komplexe Simulation eines Busses geeignet sind - es ist aber keine Pflicht, diese (unverändert) zu nutzen.

    Viel sieht man nicht, hoffentlich nicht noch nen Straßenbahnsimulator... Die Bäume sehen deutlich besser aus als in Lotus, was auch keine Kunst ist. Diese Überstrahlung durch das Licht und Lensflare gefällt mich nicht. Bumpmapping auf der Straße sieht gut aus. So, jetzt habe ich alles kommentiert, was man da kommentieren kann :-)

    gegen noch einen Straßenbahnsimulator hätte ich nichts einzuwenden. Konkurrenz belebt bekanntlich das Geschäft und eventuell führt das ja auch dazu, dass sich die LOTUS Entwickler nicht auf ihrem Alleinstellungsmerkmal ausruhen können. Vorallem optisch könnte man LOTUS mMn. deutlich aufwerten. Auf Anhieb fallen mir da Kernschatten und Halbschatten ein, die aktuell nicht unterstützt werden - auch eine dynamische Tiefenverdeckung würde Gebäudefronten wesentlich plastischer wirken lassen.

    Ja, schon wieder Unreal EngineX/

    Ich finde, die Zeit von UE ist schon fast wieder vorbei. Aber das kommt natürlich auch auf das Portemonnaie der Entwickler drauf an, wie dick das ist.


    Quatsch.


    Diese Überstrahlung durch das Licht und Lensflare gefällt mich nicht

    Definitiv. Ich weiß nicht, was sich Entwickler immer dabei denken, wenn sie solche Effekte einbauen. Sehen die die Welt selbst so? Dann sollten sie vielleicht mal zum Augenarzt gehen.


    eine derart Starke Überstrahlung und Lensflare hat in einem Simulator auch nix zu suchen. Das wäre was für einen "Kameramodus" - aber nichts für den normalen Fahrbetrieb. Im Fernbus hatte man damals beispielsweise automatisch chromatic aberration aktiviert - wofür? Damit sehen höchstens ein paar Standbilder gut aus.

    Allerdings sind die Grafikeffekte bei z.Bsp. TML's Simulation hier und da durchaus richtig gewählt, anderswo aber nicht optimal - wir sind es nur nicht so gewöhnt. Auf Facebook wurde damals zum Beispiel über die Reflexionen an den Gebäuden gemeckert. Ich habe mit eigenen Augen Teile der Strecke dokumentiert und kann so manche Kritik nicht nachvollziehen.

    Wenn man sich dann Gebäudefronten auf zum Beispiel der Budapester Straße anschaut:


    ZFtsGKb.jpg

    Das Hauptproblem ist, dass die Leute aus der OMSI-Szene diese - ich nenne Sie mal "emotionslose", flache OMSI-Grafik gewöhnt sind. Alles andere wirkt dann Grundsätzlich nicht authentisch. Die UE ist eine PBR Engine (physically based rendering) - es ist daher immens wichtig, Die physikalischen Grundsätzlichkeiten für jede einzelne Textur oder jedes Material zu definieren - vorallem dann, wenn sich auf einer Textur verschiedene Materialien (z.Bsp. Stein+Metall) befinden. Das wird oft vergessen und dann wirken Screenshots aus den Spielen einfach nicht authentisch, weil sie irgendwie "falsch" aussehen. Auch müsste man sich für die Beleuchtung mehr Mühe geben. Dafür gibts Post Processing Volumes, bei denen man in einem definierten Bereich die Beleuchtung und Effekte anpassen kann. Bei einem Spiel wie Fernbus ist das aufgrund der Kartengröße nicht machbar, ich hoffe TheBus gibt sich da mehr Mühe. Eine Gasse mit Häusern links und rechts muss dann anders behandelt werden als eine Hauptstraße - da kann man sich nicht einfach auf die Engine verlassen.

    Das Gleiche mit Temporal Anti Aliasing, was typische Ghostingeffekte verursacht. Klar, das Standbild hat wesentlich weichere Kanten, Screenshots sehen sehr scharf und sauber aus. Aber in Bewegung - wie bei einer Simulation - absolut unpassend. Da sollte man auf FXAA setzen, auch wenn das nicht so genau ist.


    Grundsätzlich lassen sich die Grafikeffekte der Engine per Config auch von "außerhalb" einstellen. selbst wenn ein bestimmter Grafikeffekt im Spiel selbst nicht zu deaktivieren ist, kann man das trotzdem ändern - und man könnte auch so viel Effekt rausnehmen, dass man quasi bei einer OMSI Grafik landet. :P


    Zitat

    UE4 ist echt ne gute Sache, allerdings in der Rohform sehr schlecht optimiert... Ich möchte da nur an Ark erinnern;)


    Man muss halt daran denken, dass ne Engine ja für bestimmte Richtungen entwickelt werden, in Unreal ist es z.B. sehr leicht möglich nen Shooter zu machen, gleiches gilt für Unity... Über Anpassungen lässt sich da natürlich viel rausholen (Asetto Corsa Competitione), aber man sollte die negativbeispiele auch nicht verdrängen... Die neueren Need for Speed teile sind meiner ansicht nach Katastrophe, und da trägt die Frostbyte-Engine ihren Teil bei... liegt aber vermutlich auch einfach an der Geschäftspolitik von EA, immerhin wird das ja fast allen Studios da aufgezwängt.


    Ich glaube Lotus fährt mit ner "Eigenentwicklung" ne recht gut Wahl... Ich denke nur, dass da der eine oder andere Programmierer mehr nicht schaden würde für die Entwicklung, aber über die Geschäftspolitik von Lotus wurde eh schon genug geschrieben, da will ich garnicht mit anfangen. Das Spiel hat potential ist aber schlicht unfertig und als "Endverbracher" wie mich einfach noch nicht geeignet.


    Das stimmt so nicht. Ich habe auf Basis der UE4 eine komplette Tramphysik gebaut, inkl. Ein-/Ausstieg, An-/Abkuppeln, funktionierende Weichen u.v.m. Die UE wird eben NICHT in eine Bestimmte Richtung entwickelt. Es ist eine Sandbox, die quasi alles ermöglicht. Und das OHNE die Einschränkungen, die LOTUS bietet. Schau dir die KT4D von Kartoffelphantom an. Die ist zum jetzigen Zeitpunkt mit ihrer Komplexen Physik nicht umsetzbar. In der Unreal würdest du da einfach Gelenke definieren und könntest sogar das Schub/Zugstangensystem unter den beiden Fahrzeugteilen simulieren. Es ist dann eventuell nicht soo optimiert (wobei man da in LOTUS auch drüber streiten kann), dafür aber wesentlich offener und freier.

    Normalerweise werden Scheiben für OMSI aus verschiedenen Layern zusammengesetzt, welche deckungsgleich sind. In der Regel ist das die folgende Anordnung:

    Innen

    01 - Dreck
    02 - Regen

    03 - Beklebung

    04 - Glas

    Außen

    05 - Glas

    06 - Beklebung

    07 - Regen

    08 - Dreck


    eine Fahrzeugscheibe besteht also aus 8 deckungsgleichen Flächen, von denen 4 nach innen gedreht sind und 4 nach außen.
    Je nach Bauweise kann man hier die Scheiben innen und außen in ein Modell packen, innen und außen getrennt oder jede der o.g. layer als einzelne *.o3d exportieren. Im letzteren Falle ließen sich diese Modelle problemlos importieren, da Pro Modell nur eine Fläche und ein Material definiert wurde. Sind die Scheiben aber zusammengefasst, werden diese auch gemeinsam in ein Modell importiert. Nutzt man nun die Remove Doubles Funktion, werden Doubletten - also die deckungsgleich übereinanderliegenden Flächen - zu einer Fläche reduziert. Es entsteht also ein Mischmasch aus den o.g. Layern.

    Sofern der Importer nicht schon beim Umwandeln der Dateien Die Doubletten schluckt, kann man mit folgendem Ansatz die Scheiben wiederherstellen:


    Zuerst eine Fläche der Wahl auswählen:

    vdhvAEe.jpg

    Mit der Tastenkombi Shift+G das folgende Fenster öffnen:


    62KxoN2.jpg


    Und mit der Auswahl "Material" alle Flächen auswählen, die zu dem Layer gehören. Sollte Material nicht funktionieren, kann auch die "Texture" funktion genutzt werden.


    niH2mBb.jpg


    Die Auswahl kann dann mit "STRG+P" vom Rest getrennt werden. Das macht man so lange, bis alle layer sauber getrennt sind.

    Das ruckelige verstellen der Ansicht hat mich in OMSI schon gestört. da könnte man ruhig zwischen zwei Kamerapositionen sauber interpolieren - so wie bei der "Weichen Fahrersicht" , nur halt auch in der Außenkamera.

    Ich hab die sauberen Übergänge der Fahrersicht aktiviert, d.h. es geht sanft rüber, wenn ich z.B. in den Spiegel schaue. Oder was genau meinst du?

    Bewege dich in OMSI mal in der Außenansicht nah ans Modell und bewege die Kamera nach links und rechts. Dann stellst du fest, dass du halt nicht "pixelweise" verschieben kannst, sondern z.T. die Ansicht direkt um 1-2 Meter verschiebst. Oder anders gesagt: stell dir vor, du drehst dich um einen Punkt. Du kannst dich halt nur um "ganze" grad verdrehen, hast also nur 360 Kamerapositionen , bis du einmal ums Objekt drumrum gegangen bist. aus Entfernung fällt das nicht auf, wenn du an das Fahrzeug ranzoomst allerdings schon. Hier hätte ich für LOTUS eine genauere Abstufung und interpolation gewünscht - dort ist das "Verhalten" der Kamera aber identisch mit dieser aus OMSI.

    Kevin? Könntest du oder Chrizzly eventuell mal Fotos vom kommenden NG 313 zeigen?

    da die Dinger nichmehr eben so per Besuch in DUS zu dokumentieren sind, ist auch die Umsetzung nicht mal eben aus dem Ärmel zu schütteln. Aktuell befinden wir uns noch in der Dokumentationsphase und sobald das Modell der Fahrzeuge nahezu fertiggestellt ist, werden auch offizielle Fotos folgen. ;)


    Zitat

    Die Resteverwertung nen 2001er NG313 aus der MAN Familie, indem die ne andere Kasse und so einbauen


    "Resteverwertung" - lol. Meine "Philosophie" ist stets einen Anreiz zu erschaffen, das aktuelle Projekt zu kaufen. So hat sich der Dus Urbino - auch wenn das Grundmodell identisch ist - nahezu überall verändert. neue bzw. aktualisierte Texturen und Modelle, neue Scripts, neue Features und Funktionen, besseres Mapping und Repainttemplate, die nutzung von komplexen Bump- und Envmapping - Wenn du der Meinung bist, dabei handelt es sich um eine Resteverwertung, solltest du dich - bevor du solche behauptungen Aufstellst - mit der Materie vertraut machen. Genau so ein Update wirds dann auch für den NG313 geben.
    Aber klar - nen DLC Entwickler verdient natürlich Millionen, Wohnt auf Zypern in einer Villa und setzt sich so 2-3 Stunden an ein Fahrzeug ran, um es für ein neues DLC fertig zu machen. Wir sind halt einfach nur abzocker.

    So etwas wie Kamerasteuerung (Finde ich übrigens deutlich besser als in anderen Spielen, da man aus jeder Position Tasten bedienen kann und die Sicht "einrastet") kann man ruhig übernehmen.


    Ich bin ja mal auf das "I" in KI gespannt. :D

    Das ruckelige verstellen der Ansicht hat mich in OMSI schon gestört. da könnte man ruhig zwischen zwei Kamerapositionen sauber interpolieren - so wie bei der "Weichen Fahrersicht" , nur halt auch in der Außenkamera.


    Grundsätzlich finde ich das allerdings nicht schlimm, denn warum soll man das Rad neu erfinden. ;)

    Naja, wenn das Rad Teilweise eckig ist sollte man schon überlegen es Rund zu machen...

    das stimmt wohl, ein gutes System kann man i.d.R. immernoch verbessern. ;) Ich meinte aber eher, dass nichts dagegen Spricht, gut funktionierende Bestandteile beizubehalten. hätte beispielsweise auch gar nix dagegen, wenn solche Fahrzeuge wie der SD202 wieder in LOTUS ihren Platz finden. Wurde schon einmal gut gebaut also warum nicht erneut verwenden, wenn das Fahrzeug natürlich ein wenig an den moderneren Standard angepasst wird.

    Ich frage mich langsam ob LOTUS tatsächlich eine Neuentwicklung ist oder ob da nicht einiges von OMSI drin steckt. Oder man hat einfach mal wieder fahrlässig gearbeitet und deswegen blinken die Autos in die Falsche Fahrtrichtung. xD

    Auch wenn das schwer nachweisbar ist und offiziell anders Kommuniziert wird, glaube ich schon dass zumindest Teile des OMSI-Codes wiederverwendet wurden. So gibts in OMSI Das Problem, dass Fahrzeugteile von Tramfahrzeugen in ungünstigen Situationen anfangen zu "zucken" - und das gleiche Phänomen lässt sich auch in LOTUS feststellen. Geht weiter mit der Art und Weise der Kamerasteuerung. Diese Vehält sich genauso wie in OMSI, es sind bei hohen "Zoomstufen" keine genauen Ausrichtungen mehr möglich, es wird nicht weich zwischen 2 punkten interpoliert.
    Grundsätzlich finde ich das allerdings nicht schlimm, denn warum soll man das Rad neu erfinden. ;)

    Grundsätzlich könnte man ja aber bei zukünftigen Add-ons wirklich mal darüber Nachdenken, ob man diese in "XYZ-Karte" und "XYZ-Bus" aufzwirbelt. Die Fahrzeuge könnten ja trotzdem auf die Karte abgestimmt sein aber wer nicht beides kaufen möchte, kann dann entsprechend entscheiden.

    Genau so meine ich das. Beim Einzelkauf der Karte fahren dann eben nur die Standard-NL/NG herum, wenn man es sich nicht anpasst.

    Passender wäre es hier aber wahrscheinlich, wenn beim Kauf der Karte automatisch der Bus dabei ist, wie es auch bei Lotus mit dem Rails-Modul der Fall ist. Den Bus selbst kannst du dann aber problemlos auch einzeln kaufen.

    dann gibts aber Leute, die eben nur die karte oder den Bus haben wollen, was dann für den jeweiligen Geschäftspartner nicht Sinn der Sache ist - außerdem wäre das bürokratisch ein nicht zu verachtender Mehraufwand. Wenn also eine Unterscheidung, dann Bus und Karte getrennt, aber aufeinander Aufbauend. Hinzu kommt ja auch die Möglichkeit, per Steam "Pakete" zu schnüren, ggf. sogar mit Rabatt. Da kauft man sich halt das "Düsseldorf-Pack" wo Karte und Bus enthalten sind - und dann ggf. auch die Mini-DLC von Kevin.

    rein objektiv würde ich dann ja meinen eigenen Produkten - auch wenn diese mit anderen Entwicklern entstanden sind - Konkurrenz machen. Mir selbst würde das vermutlich sogar einen Vorteil bringen, andere Projektpartner wären dann aber benachteiligt und auch wenn einige hier die Entscheidungen, Entwickler, den Preis oder die Add-on Inhalte nicht mögen, falle ich meinen Partnern nicht in den Rücken. ;)

    Grundsätzlich könnte man ja aber bei zukünftigen Add-ons wirklich mal darüber Nachdenken, ob man diese in "XYZ-Karte" und "XYZ-Bus" aufzwirbelt. Die Fahrzeuge könnten ja trotzdem auf die Karte abgestimmt sein aber wer nicht beides kaufen möchte, kann dann entsprechend entscheiden.



    ---- Illegaler Link entfernt ----


    Ich weiß nicht ob der Legitim ist, aber die OmsiMods Seite ist eigentlich ne normale Mod Seite ohen Cracks etc.

    Korrigiert mich wenn dad falsch ist...

    Grunsätzlich sind alle selbstständig funktionierenden Fahrzeuge aus jeglichen Payware Add-ons nicht legal.

    Moin,

    ich erlaube mir mal zum Produkt "Urbino Stadtbusfamilie" einen "Support"-Thread zu erstellen - der auch mir als Schnittstelle zur Community dienen soll. Nachdem ich den MVG Lions City Patch fertiggestellt habe, kümmere ich mich um den überfälligen Urbino-Patch, welcher beispielsweise das Bremsruckeln behebt.

    Sollten euch noch Bugs im Hinterkopf rumfliegen, welche nicht die Radkappen oder das Bremsruckeln betreffen, könnt ihr diese gern hier rein schreiben und ich versuche diese im kommenden Patch einzupflegen. :-)


    Add-On bei Steam kaufen

    Add-On bei Aerosoft kaufen

    Die Fahrzeuge werden stets auf Berlin und Grundorf getestet. Das Hofdatei-System ist Standard M&R, erweitert um weitere Strings, um Sonderfunktionen (wie z.bsp. die Innenanzeige aus DUS) umzusetzen. Folgt die Hofdatei von Städtedreieck nicht dem OMSI Grundsystem, kann es hier natürlich zu Inkompatibilitäten führen. Es handelt sich da vermutlich nicht um einen Scriptfehler, sondern um ein falsches Hofdateiformat. Der Urbino II als auch der MVG Lions City nutzen keine Speziellen funktionen innerhalb der Hofdatei - dementsprechend tritt dort der "Fehler auch nicht auf.
    Lösung ist hier: Hofdatei auf Kompatibilität prüfen. Diese enthält bestimmt für andere Fahrzeuge Strings, die mein Script durcheinander bringen.

    nicht "die Datei" sondern den kompletten Ordner.
    Wenn du OMSI über Steam löschst, bleiben ALLE Inhalte, die du per Hand installiert hast, bestehen. Freeware-Busse oder Karten, um zwei Beispiele zu nennen. Es macht dann also keinen Unterschied, wie oft du OMSI löschst und wieder installierst, da eventuell beschädigte Dateien bestehen bleiben.

    sieht soweit i.o. aus. Dein Speicher läuft voll, deshalb wird das Fahrzeug nicht geladen. Geh mal in folgende Ordnerstruktur und entferne/verschiebe OMSI per Hand:

    "C:\Program Files (x86)\Steam\steamapps\common\OMSI 2"

    entferne den "OMSI 2" Ordner bitte komplett oder verschiebe ihn vorrübergehend in einen anderen Ordner. Wenn du per Steam oder per DVD de-/neuinstallierst, bleibt fehlerhafter Fremdcontent oft erhalten.

    Das ist weder übersichtlich noch wirklich intelligent. Jede Daueranimation frisst vollkommen sinnlos, etwas Performance, sogar etwas mehr als eine einstellbare Aniamtion.

    das würde ich nicht unterschreiben. Im Endeffekt zeichnet die Grafikkarte ein Mesh an Position XYZ, welches pro Frame und damit neuer Position im 3-Dimensionalen Raum gezeichnet wird. Fügt man dieser relativen Animation ein offset hinzu, um sie an eine bestimmte Stelle zu verschieben, sollte das grundsätzlich keinen Einfluss auf die Performance haben, da das Mesh im gleichen Frame ja nicht neu gezeichnet wird, sondern nur einmalig pro Frame. Rein technisch hast du vermutlich recht, weil die routine, welche die Position des Meshes definiert etwas komplexer ist - das sollte sich aber selbst bei hunderten daueranimationen nicht bemerkbar machen.
    Die Daueranimation ist im übrigen eine ganz normale Animation, nur dass diese vom Script auf einem festen Wert gehalten wird.
    Was allerdings keinen Sinn macht, sind verschiedene variablen für die Animation - das verschwendet nur sinnlos Ressourcen.

    Naja, man sollte bei solchen Komplexen Paywareaddons nicht vergessen, wie viel Zeit und damit auch Geld die Entwicklung - vorallem bei Neuentwicklungen - doch eigentlich kostet. Das gleiche Gilt für den Kartenbau. Dann kommen verhältnismäßig geringe Verkaufszahlen in der kleinen OMSI Nische dazu und dann darf ein Add-on ja auch nicht zu teuer sein.
    Dementsprechend hat man ein bestimmtes Budget, mit dem man wirtschaftlich Arbeiten kann - und dies lässt ein sehr komplexes Fahrzeug eben nicht zu.
    die MAN Stadtbusfamilie war ein eigenständiges Add-on und konnte dadurch mit vielen Funktionen erscheinen, die nur Umsetzbar waren, weil eben keine Karte dazu gehört. Der Urbino II hat abgesehen von den Türen(dafür aber mit zwei Dashboardvarianten) eigentlich einen ähnlichen Funktionsumfang, erschien aber beim Release mit mehr Fahrzeugen als Ursprünglich der MAN Stadtbus.
    Die einzige Ausnahme ist hier der Lions City aus Bremen, welcher von mir einige Funktionen erhalten hat, was aber auch nur daran lag, dass das Grundmodell eingekauft wurde und so ein Großteil des Modellbaus und der Texturierung bereits erledigt wurde.
    Rein wirtschaftlich ist die Wahrscheinlichkeit, dass ein Fahrzeug a la MAN Stadtbusfamilie mitgeliefert wird, verdammt gering. Es heißt zwar immer, dass die Entwickler wohl in Geld schwimmen müssen und neben ihrer Villa mit Swimmingpool wohl schon 2 Sportwagen in der Garage stehen haben, tatsächlich ist das Entwickeln von Add-ons eher ein mittelständiges Gehalt, vorallem nach allen Abzügen - und keiner wird beruflich so viel Zeit in ein Projekt investieren, dass unterm Strich eine rote Ziffer steht. Natürlich ist es klar, dass die Qualität und der Umfang immer besser werden sollte, um ein Spiel attraktiv zu halten - aber irgendwann ist auch eine Schwelle erreicht, wo der Entwicklungsaufwand so hoch ist, dass dieser nichtmehr durch die Einnahmen finanziert werden kann.
    Dementsprechend müsst ihr euch wohl alle von der Vorstellung lösen, dass das Fahrzeug in Bad Hügelsdorf super krass wird - viel wahrscheinlicher ist, dass es ein auf die Karte angepasstes Modell ohne viel Schnickschnack sein wird, ggf. sogar aufgewärmtes Altmaterial ist. mehr gibt das Budget einfach nicht her, vorallem dann nicht, wenn man nicht bereit ist, mehr als 25 € für ein Add-on zu bezahlen. Günstig geht nur über die Menge, und diese ist in der Simulationsbranche und vorallem bei OMSI stark begrenzt.
    Übrigens: kein "Remake" eines bereits verkaufen Busses bedeutet nicht unbedingt, dass es ihn nicht mehrmals geben wird. Mir fällt da Spontan das C2 Paket von Halycon ein, welches dafür genutzt werden könnte - und ggf. gibts ja auch andere Entwicklungen, von denen wir nichts wissen. Ich kann mir aber kaum Vorstellen, dass hier speziell für Bad Hügelsdorf ein neues Fahrzeug entwickelt wird, welches auch nur dem Zweck der Karte dient.

    der Texturindex muss der gleiche bleiben. du kannst doch auch einfach die Texturen im Fahrzeugverzeichnis anpassen - zumindest für einfarbige Matrixen.

    Wenn du RGB funktionen willst, kannst du versuchen, mit einer Scripttextur eine andere Textur zuzuweisen - ob das allerdings in Kombination mit der Transmap für Matrixen funktioniert, weiß ich nicht, müsste man mal probieren. Schau dir dazu das OMSI SDK an - das Stichwort ist "[matl_change]".