Beiträge von Chrizzly92

Wäre das von Anfang an klar kommuniziert worden, wären deutlich weniger Leute interessiert gewesen. Ich vermute - und es ist nur eine Vermutung - dass hier sogar mit Vorsatz gehandelt wurde, um den Gewinn zu maximieren. Das wäre bei erfolgreicher Entwicklung auch kein Problem gewesen, Aber nun hängen seit Jahren Spieler im EA fest, die ganz andere Erwartungen an die Software haben, weil es nicht wie geplant voran gegangen ist.
Auch ist der Fakt, dass für das Spiel die Tools-EA diverse DLC! auf dem Markt sind, komplett widersprüchlich zur (schlecht) kommunizierten Idee , dass es sich angeblich nur um Entwicklertools handelt.

Selbst wenn ich alle Aussagen vom Team Oriolus in Ihrem Interesse zugutehalte, fällt mir bei Aussagen wie die letzte von Marcel zur Anfrage von Mory auf, dass sie einfach nichts verstanden haben und weiterhin borniert und ohne Einsicht auf ihren Standpunkten beharren. Unter der Prämisse werden auch zukünftige Versuche scheitern.

Zitat von Theproloser

Objekte und Maps können engine übergreifend ohne weitere Bearbeitungsschritte verwendet werden. Sollten allerdings - wie bei München - irgendwelche Features dazu gepfuscht worden sein, dann funzt das natürlich nicht. Aber du kannst ja jetzt schon in LOTUS NG die ganzen Maps aus dem Workshop abfliegen, und zwar fehlerfrei.

wie willst du bitte dynamisch generierte Inhalte aus Lotus in CTS importieren? hast du überhaupt gelesen was die Fragestellung war?
Natürlich können die Inhalte von LOTUS in LOTUS geladen werden, aber darum geht es nicht. Die Frage war, ob die Inhalte nicht "einfach" in z.bsp. CTS oder ein anderes Spiel portiert werden können, und das wäre nur Möglich, wenn auch die Strecke in Objektbauweise gefertigt ist oder Oriolus ein Export-Tool bereitstellt.

Jain, die haben ja auch die "Leseroutine" der Modelldateien geschrieben und können die entsprechend portieren. Wenn Oriolus dafür ein Export-Tool Entwickelt, wie beim Terrain in omsi quasi, wäre das natürlich was anderes.

wenn es sich nicht um den Darius-Workflow handelt (95% Objekte) ist das auch technisch nur schwer Umsetzbar. Gebäude und Modelle ja, aber die komplette Karte müsste man erneut aufbauen.

Die Antwort des Übels heißt TAA. nicht nur Displays sind betroffen, generell alle Meshes/Texturen mit schnellen Bewegungen. Über Youtube werden die meisten Artefakte sogar wegkomprimiert, mit eigenen Augen ist TheBus imho nicht spielbar, außer man erzwingt ältere AA-Methoden wie FXAA, was dann aber zu Artefakten in Schatten oder Effekten wie SSR führt. Ghosting hinter Fahrzeugen, extreme Artefakte bei schnell bewegenden Bewegungen, unlesbare Displays während der Fahrt - all das liegt an TAA. im Stand ohne Bewegung hat man natürlich super Screenshots, die die Kunden imho irreführen, da das Spiel so nie "im Betrieb" aussieht.
Upscaling und co. tut dann seinen Rest.

Mag auf nem 1080p Fernseher in 5m Entfernung auf irgendeiner Konsole egal sein, am 4K PC-Display ist das allerdings unerträglich, vorallem wenn man die Artefaktshow einmal gesehen hat.

Man schaue sich beispielsweise mal das Rad im Radhaus an, und das ist als Einzelframe noch deutlich angenehmer, weil die ebenfalls verschwommen Frames davor und dannach nicht in einem Screenshot dargestellt werden können:

Mehr Infos zum Thema gibts hier:

https://www.reddit.com/r/FuckTAA/

https://www.reddit.com/r/MotionClarity/

Ist Zugegebenermaßen nicht nur in TheBus ein Problem, das stimmt - aber wer für Spiele mit schnellen Bewegungsabfolgen TAA erzwingt (was TML mit den "Voreinstellungen" faktisch macht), ist Teil des Problems.

Zitat von Hamburg

Es wird wie immer mit dem Detailgrad bzw der Simulationstiefe stehen und fallen. Ansgar sagte z.B, man könne im Bus 'einige' Knöpfe drücken. Der OMSI Spieler will aber wahrscheinlich alle Knöpfe drücken können, die Physik wird vielleicht auch nicht ganz so tiefgehend sein.

Ich bin aber auf die Umsetzung gespannt, schließlich wird es schon in Bälde soweit sein.

Aber schon witzig: Ein Addon Entwickler von Lotus steigt dort aus und entwickelt schnell mal seinen eigenen Simulator mit Tram und Bus und ist damit wesentlich früher fertig als Lotus.

hat dafür aber auch ne satte Fördersumme eingesteckt. Mit genug Budget ist man natürlich schneller, als die Entwicklung der Software irgendwo zwischen Busfahren und World of Warcraft zu schieben.

Zitat von IceTea2202

Zitat von Hamburg

Weißt du, wie man reale Karten baut?

Falls nicht, solltest du keine Addons entwickeln (lassen), wenn das dein Anspruch ist.

Und ja, ich kenne den Editor ausreichend gut. Kannst du dir vielleicht denken, warum ich schon vor vielen Jahren in Erfurt war... Also halt mich nicht für blöd, sondern erkläre, warum ihr lieber Pfusch liefert statt ein ordentliches und umfangreiches Produkt abzuliefern??

Fehlt Geld? Der eigene Anspruch? Das eigene Können?

Alles anzeigen

Bezweifle, dass du den Editor kennst. Was hast du mit TML zutun? „Vor vielen Jahren“ gab es maximal zwei Leute, die dort waren und du warst keiner davon.

Die Anmaßung, ob man sich denn auskennt mit realem Streckenbau, finde ich auch interessant. Was hast du nochmal so reales gebaut? Ach ja …

Alles anzeigen

Der Editor ist unbrauchbar, vorallem wenn man realistisch mit Überhöhungen arbeiten will, oder Kreuzungen, die in einem Gefälle liegen, oder allgemein Konstruktionen, die nicht flach auf der Erde liegen. Eine Teilkonstruktion in Blender (wie in OMSI) ist nicht umsetzbar, da die Exportmöglichkeiten für "splines" nicht existieren.
Deine Expertise in allen Ehren, aber wer behauptet, der Editor sei für realistische Umsetzungen brauchbar, der sollte nicht in der 3D Branche unterwegs sein.
Mag für Casual Gameplay auf einer Brandenburg-Karte reichen. Alles, was individualität bringt, kannste vergessen oder musst gleich mit Blender arbeiten.
Hamburg ist jetzt auch nicht mein best Buddy, aber der weiß denke ich, wovon er beim Straßenbau redet und unter der Prämisse des Realismus fällt das TML Tool nunmal mit 0 Punkten durch.

müsste morphi sein wenn ich mich recht entsinne. musst also ihn mal fragen.

volcurve zusätzlich hinzufügen, mit Throttle als referenz.

[pnt]
0
1

[pnt]
0.01
0

lars_0254 rechtliche Sicherheit, etablierte Vertriebswege, Lizenzierungen, Test-Hardware-Zugriff (development-kits für Konsolen), Finanzierung... Vorallem vor ein paar Jahren, wo physische Medien noch relevant waren. Pressen von CD's, Layouten von Inlays und Handbüchern, Entwicklung und Verkauf von Merchartikeln.

Natürlich kann man es auch selber bewerkstelligen, Aber die Wahl eines Publishers kann durchaus von Vorteil sein, wenn denn die Rollenverteilung entsprechend fair ist.

Auch muss man differenzieren, ob es sich um eine Auftragsarbeit handelt oder ein "eigenes Projekt".

Beispiel: Publisher Weltraumhart möchte ein neues Franchise Aufbauen - ASSI, der AlienSchiffSimulator. Der Publisher investiert in dich/deine Firma mit 250.000€ und beteiligt dich danach prozentual an den Verkäufen. Ohne den Zuschuss hättest du als Firma das Projekt gegebenenfalls gar nicht stemmen können, mit Publisher im Boot ist die Finanzierung des Projektes gesichert. sobald der Simulator 250k eingespielt hat, fließen die Erlöse des Verkaufs als Gewinn an Publisher und Entwicklerteam ab. Während der Entwicklung kann sich der Publisher dann auch um Werbung, Lizenzierung, Management und co. Kümmern und hält den Entwicklern den Rücken frei.

Entwickelst du jetzt nen Indie-game in deiner Freizeit und veröffentlichst das für 9,99€ auf Steam, brauchst du natürlich nicht zwingend einen Publisher.

Generell kann man vermutlich sagen: umso komplexer das Spiel und umso umfangreicher das Entwicklerteam wird, desto mehr Sinn macht das Auslagern von Aufgaben zu einem Publisher. Grundsätzlich stimme ich dir aber zu, die "notwendigkeit" eines Publishers nimmt zunehmend ab, wobei Platformen wie Steam, Epic oder GOG defacto einen Publishercharakter haben und an solchen Platformen kein Weg vorbei geht, wenn du eine gewisse Reichweite generieren möchtest.

Das ist kein offizielles Tool btw.

kannst du benutzen, da gibts keine unterschiede.

Zitat von w00dey1

Zitat von diebaer

Zitat von w00dey1

...

Leider nur in Englisch und vom 28.1.25

Euch kann man es auch gar nicht Recht machen, egal wie man es macht, macht man es falsch

1) Das Spiel ist ausschließlich auf Steam zum Kauf verfügbar. Bei Supportanfragen über Steam wird entweder gar nicht oder mit Verweis aus das eigene Forum reagiert. Das ist wie, wenn man bei Rewe an der Kasse ne Frage stellt und zum Geschäftsleiter in die Privatwohnung eingeladen wird, wo er natürlich Hausherr ist und die Spielregeln vorgibt.
Wer also als Käufer potentielle Antworten will, muss seine Daten Preisgeben und sich in ein Forum begeben, welches er ggf. gar nicht nutzen möchte. Auch wenn Support ohne Anmeldung möglich ist, ist das ein Stinkefinger an alle potentiellen Käufer, wenn ich mich als Entwickler aus irgendwelchen vorgeschobenen Gründen nicht um den Support auf der Verkaufsplattform kümmern will. Das Geld nimmt man gern mit, aber um die Verpflichtungen drückt man sich.

2) Das Spiel ist auf ausschließlich Steam zum Kauf verfügbar. Informationen über den Entwicklungsstand sind faktisch dort zu publizieren, wo man das Spiel bezieht. Bei einem Produktrückruf wird ja auch nicht auf irgendeinem Random-Discord informiert, sondern beim Einzelhändler, wo du das Produkt erworben hast.

3) Ein privat geführter Discord-Server ist keine Schnittstelle für Entwicklungsinformationen. Das kann man machen, wenn man irgendein Privatprojekt zeigt oder insights in Entwicklungen, die nicht zum verkauf stehen. Sobald ein Vertrag zustande kommt, befindet sich der Entwickler in einer - zumindest moralischen - Bringepflicht. Warum nicht in Lotus selbst eine Funktion implementieren, die Update-News anzeigt?
Ach, ich vergaß - das wird ja nicht mehr weiter entwickelt.
Du solltest dir Gedanken machen, wo dein Stellenwert als Spieler oder Käufer liegt, wenn - anstatt in die direkte Kommunikation zu gehen - ein Discord-Bot entwickelt wird, der interne Changelogs spiegelt. Das ist ein klassisches Minimalprinzip. Mit so wenig aufwand wie möglich die nötigsten Informationen bereit zu stellen, um behaupten zu können, man kümmere sich um die Communitybedürfnisse, spricht dabei aber nur eine Handvoll interessierte an, die am Rockzipfel hängen und sich aktiv informieren wollen.

Das Problem hier ist nicht die Community - sondern das Team hinter Lotus, welches nach mehreren Rückschlägen immernoch mit einer Überheblichkeit agiert, die Seinesgleichen sucht, immer alles besser weiß, sich keine Vorschläge oder Kritik zu herzen nimmt oder aktiv und wirksam auswertet.

Das ist wie im Straßenverkehr - hast du einmal nen Drängler hinter dir, ist vermutlich der Drängler das Problem. Hast du ständig Drängler hinter dir, sollte man sich mal Gedanken machen, ob man nicht selbst das Problem sein könnte.
Gibts mal Gegenwind aus der Community, was Entscheidungen betrifft, kann das als Einzelfall abgestempelt werden. Gibts aber ständig und zu fast allen Entscheidungen Gegenwind, MUSS man sich Fragen, ob die eigenen Entscheidungen in dieser Form denn zielführend und praktikabel sind.
Solange das nicht passiert, befindet sich Lotus in einer unausweichlichen Abwärtsspirale. Vielleicht wirst du als "Fanboy" das irgendwann auch mal mitbekommen - spätestens dann, wenn du wie viele andere einfach ausgetauscht wirst.


Aber in einem Stimme ich dir zu: Die Diskussion darum ist eigentlich ziemlich sinnlos. Macht zwar den meisten beteiligten Spaß, aber im Grunde ist es unnötig investierte Energie. Der Stellenwert von Kritik ist allen beteiligten klar:

In diesem Sinne: nutze deine Nähe um positiv einzuwirken, anstatt Position zu beziehen. Vielleicht erkennst du dann auch deinen richtigen Stellewert.

Zitat von w00dey1

Zitat von hans-johnson

Ich finde, dass Marcel den zahlenden Nutzern regelmäßig über den Entwicklungsfortschritt von LOTUS berichten sollte.

Das tut er, auf dem LOTUS-Discord

Letzter Marcel-Beitrag vom 14.09.24.



Ansonsten sind das Patchnotes für ein Produkt, was eventuell mal irgendwann erscheint. Discord als Kommunikationskanal zu wählen, ist zudem eine ziemlich idiotische Idee.

Zitat von wurstbrot

Bei OMSI damals gabs keine Informationen. OMSI war irgendwann da, und vorher gab es einfach nur 2 Videos. Das war's.

da hat man aber auch erst bezahlt, als es nahezu fertig war

gibts (noch) nicht. wurde nicht umgesetzt und im Betatest über Monate hinweg auch nicht angemerkt. Man kann leider nicht alles abdecken.
Kommt aber noch, versprochen!

Das Darius-DLC wird mit hoher Wahrscheinlichkeit nicht vor dem erfolgten Enginewechsel kommen. Zumindest ich als Entwickler würde nicht zwei mal Scripts entwickeln wollen, ohne genau zu wissen, wie das neue System funktionieren wird und welche Änderungen relevant sind.
Eher sehe ich eine Portierung der Inhalte nach OMSI, was zügig machbar sein sollte, sofern Darius weiterhin auf 3D-Modelle als Straßen setzt. dann könnte man optimalerweise sogar zweimal die Cashcow melken.

die Fahrzeuge unterscheiden sich grundsätzlich nur in der Motorleistung. 242 ist Saugdiesel, 292 Turbodiesel. Alles andere war Bestell- oder Baujahrabhängig.

Guten Abend!
wie einige vielleicht mitbekommen haben, spiele ich seit Jahren mit der Umsetzung einer "OMSI-Alternative" herum und habe mich seit nunmehr fast einem Jahr auf ebendiese Umsetzung fokussiert.
Ein wichtiger Punkt für mich ist, eine ähnliche Moddingfreundlichkeit zu erreichen, wie es sie auch in OMSI gab, ohne zwingend auf den Unreal Editor zurückgreifen zu müssen. Das wird nicht in allen Bereichen in identischer Form umsetzbar sein (der Kartenbau wird beispielsweise Editor-Only stattfinden), aber in denen, wo es technisch möglich ist, möchte ich das optimalerweise so wie in OMSI beibehalten. Warum sollte man das Rad in Bereichen neu erfinden, die grundsätzlich schon nicht schlecht sind?
Dementsprechend wird mein Simulator in vielen Bereichen "Daten-kompatibel" sein - Es müssen zum aktuellen Zeitpunkt beispielsweise keine Fonts erstellt werden, wenn es diese schon in OMSI gab. Das entlastest mich als Entwickler, da ich meine bereits umgesetzten Inhalte weiter verwenden kann und auch jeden potentiellen Modder. Eine solche Funktionalität ist für alle Inhalte (außer die Karten und Scripts) geplant, welche auch in OMSI auf einen Datenstruktur in lesbarer Textform setzen.
Genauso möchte ich das Beispielsweise mit der Sound-cfg von Fahrzeugen handhaben und bin da auf eine Ungereimtheit gestoßen, zu welcher ich keine Antwort finden konnte.





im speziellen geht es mir um diese Einträge in der Sound-cfg eines Fahrzeuges, welche 1:1 Standard M&R Content sind. Eine Volcurve wird i.d.R. mit einer Variable verknüpft, hier aber mit "-1". Weiß eventuell einer, ob es sich hier um eine Art "Fallback" Volcurve handelt oder wurde die entsprechende Volcurve durch M&R damit "auskommentiert"?
Sollte letzteres der Fall sein, hätte sich diese "unnötige" Implementierung seit über 10 Jahren immer wieder fortgepflanzt, denn solche Referenzen findet man i.d.R. in fast jeden Fahrzeug, auch heute noch - und das kann ich mir fast nicht vorstellen, vor allem unter der Prämisse, dass Auskommentierungen i.d.R. vor dem [tag] stattfinden und nicht innerhalb des angefangenen Datenblocks.
Im SDK habe ich dazu leider nichts gefunden, auch in etwaigen Referenzen innerhalb der Soundconfigs konnte ich keine Infos zu dieser Funktion finden. Vielleicht gibts hier nen Soundspezialisten, der helfen kann?
Im Zweifel fange ich solche Konstellationen ab und hinterlege sie im Logfile - dann ist ggf. ein Nacharbeiten der Sound-cfg nötig, um sie voll kompatibel zu machen, sollte sich dahinter doch eine Funktionalität verstecken. Besser fände ich es allerdings, wenn ich auch diese "Spezialform" implementieren kann, sofern denn jemand weiß, wofür das genau da ist.
LG
Christian

Zitat von lars_0254

Und am Ende muss das auch in einer akzeptablen Zeit möglich sein, wer weiss was da noch kommt also wegen Engine usw. Frage: Könnte man theoretisch eigentlich einen Omsi Bus für z.B. die Unrealengine (The Bus) konvertieren?

Ich baue ja ebenfalls einen eigenen Simulator und habe auch in anderen Projekten (BusSim16, BusSim18) damit Erfahrungen gesammelt. Ich sags mal so:
der etablierte Workflow, wie man ihn aus OMSI kennt, ist nicht applizierbar. Nein, man muss die Busse nicht neu bauen, aber man kann sie in der Regel auch nicht einfach so importieren. Animationen, Texturen, Mapping, Beleuchtung, vorallem im Hinblick auf loose geometry - all das muss man sich anschauen und entsprechend anpassen. Scripts sind nicht kompatibel. ich schätze, dass 50% der Entwicklungszeit des Fahrzeuges in die Portierung in eine anderen Spieleengine fließt, wenn man denn volles Potential ausschöpfen will.
Scheitern wird es allerdings eher an den Rechten, wie hier schonmal erwähnt. in manchen Fahrzeugen stecken so viele Leute, da die rechte einzuholen um rechtlich safe zu sein ist nicht so einfach.

Amazon Luna