Beiträge von Chrizzly92

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

Ich nutze Arch-Linux. Habe ich schon erzählt, dass ich Arch nutze?

Zitat von Tristan98

Speziell für das Weihnachtsfeeling - ich bin ein großer Fan! - gibt es auf der Karte verschiedenste Dekorations-Objekte wie Leuchtsterne, die an den Laternen hängen oder Lichterketten, die sich in die Bäume schmiegen. Und wer weiß, vielleicht entdeckt man sogar auf der ein oder anderen Fensterbank ein ganz typisches Objekt für die Weihnachtszeit

habt noch 8 Tage, damit man davon profitieren kann.

Ich mische mich mal ein, weil ich hier zweimal getagged wurde und beziehe mich ausschließlich auf die in diesem Thread geposteten Inhalte:

Zitat von Tjark

Ist ja schön, wenn du der Meinung bist, das das Standart Dash von ihm das beste ist, ich darf anderer Meinung sein. Ja, ich mag das auch, dennoch wird es einem vielleicht irgendwann langweilig, schließlich haben wir das auch schon in diversen Bussen (Citaro V5, V5.1 und später V5.2, Facelift V2 und später V2.2, Solaris Urbino 12 II und Citaro LÜ) gesehen. Irgendwann will man eben mal etwas neues.

Nun, wenn es schon eine - und das sage ich jetzt nicht aus "meiner" Sicht - sinnvolle Lösung für dein selbstgemachtes Problem gibt, liegt es doch auch einfach nahe, dass du darauf hingewiesen wirst, dass es Mods gibt, die deine Wünsche umsetzen. Man muss das Rad auch einfach nicht neu erfinden.

Zitat von Tjark

darf ich ebenso Hilfe in der Webdisk verlangen.

Du darfst nach Hilfe Fragen, keinesfalls aber Verlangen. Das ist ein kleiner, aber feiner Unterschied!

Zitat von Tjark

Ich bin eben kein Blender und OMSI Profi, aber auch kein Anfänger, wie du es so gerne behauptest...

Dann müsstest du wissen, was es bedeutet, ein Kernelement in einem Fahrzeug mal eben auszutauschen. Die Komplexität scheint dir dabei gar nicht ganz klar zu sein, sonst würdest du nicht mit offensichtlichen Problemen um die Ecke kommen. Copy&Paste ist kein Modden!

Zitat von Tjark

Wenn hier etwas nicht funktioniert, dann darf ich Hilfe anfordern und wenn sich da keiner meldet, darf man auch mal etwas mehr nachfragen.

Nochmal: Du darfst nach Hilfe Fragen - wo aber kommt der Anspruch her, etwas anfordern oder verlangen zu dürfen? Den hätte ich auch gern!

Zitat von Tjark

Anstatt das du hier immer deinen Senf dazu gibst, könntest du mindestens mal genauso hilfsbereit sein wie der Rest der Community hier und einen Lösungsvorschlag äußern, bzw. dich mal mit meinem Thema befassen und hilfreiche Schritte zur Lösung des Problems anbieten, nicht sowas wie:

O3D Dateien tauschen, Scripts rein und Texturen tauschen.

Das kenne ich schon.

Sorry, aber deiner Vorstellung nach besteht das Modding doch nur aus copy und paste. Aber das scheint es ja - obviously - nicht zu sein und du solltest dankbar sein, dass sich überhaupt jemand die Zeit nimmt, zu helfen. Besonders Aufschlussreich sind deine Beiträge nämlich nicht und es ist doch nicht die Pflicht der Community, dich an die Hand zu nehmen und bis zum Erfolg deines Projektes zu begleiten.

Zitat von Tjark

Halt mal lieber den Ball flach, bevor du hier Leute als Anfänger und Nieten oder als solche, die nur nerven und die keiner braucht, abzustempeln. Das ist nicht nett.

Nett mag es nicht sein - objektiv betrachtet bist du allerdings genau das, so direkt muss man das leider festhalten.
Wärst du strukturiert vorgegangen und hättest das ruhig und Zug um Zug implementiert, wären viele Fehler vermeidbar gewesen und vor allem nachvollziehbar behebbar. Aber mit der Schrotflinte den Code, die Texturen und die Modelle in das Fahrzeug "reinzuschießen" kann nicht funktionieren. Das Dashboard greift, je nach Scriptstrukturierung, in so gut wie alle Systeme im Fahrzeug irgendwie ein - Türen, Motor, Getriebe, Elektronik, ggf. Matrix, Bremse usw. usf. - da muss man schon wissen, was man tut und das ist bei dir offensichtlich nicht der Fall.
Unter dieser Prämisse wäre es auch deutlich schneller, "einfach" das existierende Dash entsprechend anzupassen, die überflüssigen Türtaster zu entfernen und die Texturen ggf. entsprechend Anzupassen. Dabei kann man dir auch gezielt helfen.

Zitat von Tjark

Punkt.

Wenn alle über die Problematik bescheid wissen, warum macht ihr dann nicht selbst etwas dagegen?
ab der MAN Stadtbusfamilie kam, wenn ich mich recht entsinne, kein DLC mit Kopierschutz mehr, welches eine "aktivierung" benötigt. Das bedeutet im Umkehrschluss, dass alle folgeaddons im Steam Zusatzinhaltefenster abgewählt werden können.
Alle Inhalte Runterladen, OMSI-Ordner umbenennen, alle Zusatzinhalte abwählen (außer die mit Kopierschutz aber da kommen höchstwahrscheinlich eh keine Updates mehr), OMSI neu installieren und dann den umbenannten OMSI-Ordner wieder einfügen. Tada, aktueller Stand und nie mehr Überprüfungen, wenn ein Update oder neues DLC erscheint.
Alternativ kann man auch einfach nach Installation das OMSI Verzeichnis umbenennen. Dann ist ein Start zwar nichtmehr über das Steam Overlay möglich, sehr wohl aber über eine verknüpfung zur executable.
Weitere alternative: zwei Ordner nutzen, wenn man immer up2date sein will.
weitere alternative: mods duplizieren und in einem eigenen Ordner platzieren und/oder keine Originaldateien überschreiben, sondern nur referenzieren.

2-3 Handgriffe und die Überprüfung ist kein Problem mehr. In der Zeit, wo man meckert, kann man auch einfach schnell eine der o.g. Methoden umsetzen und hat seine Ruhe.

Zitat von IREgio612

Gab es das Thema nicht schon? Die Boundingbox ist völlig korrekt:

Irgendeiner meinte mal, dass die MAN's der neuen Generation generell etwas tiefer liegen, als andere Busse.

ich musste damals für den Ruhr-Urbino die Boundingbox ebenfalls verkleinern (bzw. höher legen), weil bei der Nitzschmännchen-Splinebauweise die Karre auch überall kollidiert ist. Realismus hin oder her, wenn die Fahrbarkeit drunter leidet, sollte man das gegebenenfalls etwas entschärfen. Nicht jede Karte hat millimetergenaue Kreuzungsobjekte mit perfekter Kollision.

Zitat von IREgio612

Was erwartest du da jetzt? Es ist nun mal auch in der Realität so.

Aber die Touren die ich damit gefahren bin, konnte ich (mit aktiver Kollision!) problemlos bewältigen. Bin da an keinem Bordstein hängen geblieben.

siehe oben. Du bist nicht Maß der Dinge, andere Leute spielen andere Karten und haben mit dem gleichen Fahrzeug nunmal unterschiedliche Probleme.
Ist wie wenn ich sage, Omsi läuft Ruckelfrei mit über 100FPS, spiele aber nur Grundorf.

w.i.p - gerade rollbänder sind nicht mal eben gebaut (zumindest so, wie ichs mir vorstelle) und so richtig motivieren konnte ich mich bisher auch nicht

fassen wir nochmal zusammen: ich habe dir nicht deine idee abgesprochen, sondern für jeden, der was ähnliches vorhat, die entsprechenden nachteile aus technischer sicht aufgezeigt.
dein system funktioniert nicht ordentlich in kurven und dein system funktioniert auch nur, wenn sie mindestens bis ins gelenk laufen (es sollte sich erschließen, dass damit nicht bis zur vordertür gemeint war) da ein pfadwechsel nur an pathpnt möglich ist und sie erst dort wieder nach hinten laufen können, wo die dummy-pfade auf die richtigen des nachläufers treffen.
wenn die "vorteile" die "nachteile" für dich überwiegen, ist das doch schön. nichtsdestotrotz behebst du damit nicht das problem, sondern nutzt einen workaround, der situationsbedingt ebenfalls probleme mit sich bringt, nur halt andere.

wenn ich mich recht entsinne - bin aber kein profi im kreuzungsobjektbau - musst du entweder das objekt mit einem height-mesh deformieren und/oder das objekt direkt in der entsprechenden Neigung bauen.

Zitat von JAROAN

Niemand hat gesagt, dass es nicht Modbar sein wird.

Es geht lediglich um die Freiheit des Moddings, da hat es noch kein Unreal Spiel Ansatzweise an OMSI ran geschafft.

das beantwortet meine Frage nicht. Warum sollte es nicht gehen? Nur, weil es bisher keiner gemacht hat?
Was tatsächlich schwieriger ist, ist das "mal eben" editieren von Assets, vorallem, was den Code betrifft. Aber auch dafür gibts implementierungen über Lua oder Python, auch lässt sich mittels C++ ein eigenes Framework implementieren.
Nur, weil es noch keiner gemacht hat, heißt es nicht, dass es nicht geht.
Oft, und vorallem bei Casual Games, ist das auch gar nicht gewünscht.
Der Alleinige Fakt, dass es auf der UE basiert, hat allerdings absolut nichts mit der potentiellen Modbarkeit zu tun.

woher hast du diese Information? Warum sollte es nicht modbar sein?

nothing wrong. you can only "modify" the vibration amplitude and frequency as a developer, not the overall behaviour. it is correct that the wheel (and/or controller) shakes when the engine is started, stalled or at a low rpm.

Zitat von besteap

Zitat von PingPong

Zitat von PingPong

Edit: oder es handelt sich um den bekannten OMSI "Bug", am Nachläufer steigen nur Fahrgäste ein, die neu Spawnen.

Das kann man beheben:

- in der passengengercabin des Vorderteils die Entries des Nachlaeufers eintragen

- in der passengercabin des Nachlaeufers die Entries loeschen

- die paths Datei des Vorderwagens um die Wege des Nachlaeufers erweitern

Alles anzeigen

das ist aber auch mehr pfusch als Verstand. Das funktioniert, solange man gerade in einer Haltestelle steht, aber sollte man wie in Grundorf am Krankenhaus in einer kurve stehen, steigen sie dann in der Luft ein. Außerdem würden sie auf den pfaden immer erst nach vorn laufen, selbst wenn sie hinten sitzen wollen.