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!

  • LOTUS Simulator

    Zitat von Kevantasy

    Ich wage stark zu bezweifeln, dass wenn du hier nach Hilfe fragen würdest, dir jeder 24/7 zur Seite steht, irgendwann geht es nämlich tatsächlich auf die Nerven wenn du nicht in der Lage bist dinge umzusetzen.


    Nun, auch wenn ich dir grundsätzlich recht gebe, muss man das in eurem Falle differenzierter sehen.
    Es handelt sich ja - wie auch immer kommuniziert wurde - um einen Early Access für die LOTUS-TOOLS und eine Möglichkeit, Entwickler frühzeitig einzubinden, damit zum Release des Spieles genug Inhalte verfügbar sind. Das ganze ist aber keinesfalls eine Einbahnstraße. Wenn ich dafür bezahlen soll, ein Spiel durch Feedback und eigene Leistung voran zu bringen, dann kann ich meiner Meinung nach auch verlangen, ordentlichen Support zu erhalten - speziell von den Entwicklern selbst, die nur in den seltensten Fällen helfen.


    In OMSI hatte man den Vorteil, dass man jegliche Scripts, sei es Free- oder Payware, sei es offizieller Inhalt oder Communityinhalt, einsehen und modifizieren konnte. Ich glaube keiner in der OMSI Szene hat den Code nach einmaligem durchlesen des Wikis fehlerfrei rausgeschissen. Oft beginnt man mit kleinen Änderungen, fügt mal hier nen Haltesummer hinzu, dort einen Türtaster für ne Automatiktür, wo anders eine automatische Haltestellenbremse - und so hangelt man sich Zug um Zug von Problem zu Problem und lernt dabei die Handhabung der Scriptsprache, Hat eine funktionierende Scriptbasis, kann sich anschauen wie etwas funktioniert und entsprechend im Handumdrehen mit dem Notepad adaptieren und modifizieren.
    Im Falle von LOTUS beschränkt sich diese Möglichkeit auf die Inhalte in OpenLOTUS und die paar opensource Scriptbeispiele im Lexikon sowie die Public Domain Inhalte, wo vom Entwickler festgelegt wird, ob es modifizierbar ist oder nicht.
    Das macht den Einstieg und das selbstständige "basteln" also um ein vielfaches! schwieriger, als das bei OMSI der Fall war.
    Zudem halte ich die Art, wie das Lexikon auf lotus-simulator.de integriert ist, für maximal unübersichtlich und schlecht benutzbar.

    Die einzige, übriggebliebene Möglichkeit, zu Lösungen zu kommen ohne viel Vorwissen angeeignet zu haben, ist also, sich helfen zu lassen oder erstmal Jahre Zeit zu investieren, um so fit in Scripts zu werden, dass man Sie aus dem Ärmel schüttelt.
    Und auch hier spiegelt sich wieder der Egoismus und die Überheblichkeit wieder, die bei LOTUS herrscht: "Kümmere dich selbst, geh uns nicht auf den Sack, bring mehr Eigenleistung ein, Denk dir was aus, nutz die Suche", anstatt einfach gemeinsam an einem Strick zu ziehen, um Inhalte und das Spiel selbst vorwärts zu bringen.
    Versteh mich nicht falsch, ich fühle mich auch manchmal von generischen PN's mit "Ich hab da mal ne Frage" genervt, wo ich eigentlich erwarten kann, dass man sich mit einer speziellen Frage an mich wendet. Aber nicht jeder hat jahrelange Erfahrung in dem, was er tut und irgendwann fängt jeder mal an. Ich kann und möchte nicht beurteilen, inwiefern die TigerChris Inhalte das Spiel voran gebracht hätten, aber so oder so hat man - mal wieder - einen potentiellen Entwickler vergrault, anstatt ihm die notwendige Hilfestellung zu geben. Alle haben mal klein angefangen und dumme Fragen gestellt. Ich weiß selbst noch, wie ich Busfanat in 2014 oder so genervt habe, weil ich ne Dresdner DFI umsetzen wollte - heute würde ich meine Fragen als "Cringe" abstempeln, damals wusste ich es einfach nicht besser.


    Hier mal nen Beispiel:
    Das minimal-script zum bewegen eines Fahrzeuges wurde korrekt im Anhang hinterlegt:

    und hier wird vom "im Anhang angehangen" gesprochen, ist aber als Hotlink implementiert, den man aufgrund der fehlenden optischen Unterscheibarkeit kaum erkennen kann:

    Einfach inkonsequent und schlampig aufgebaut das ganze. Da war das OMSI Wiki wesentlich angenehmer zu bedienen. Mit nem Kontrastarmen Bildschirm ist man da gegebenenfalls schon aufgeschmissen, falls man nicht zufällig mit der Maus über den Link fährt.

  • Add-on Thüringer Wald (fiktiv) + S31xUL (GT)

    kommt auf den Preis drauf an. Ich fühle mich auch verarscht, wenn die Franzosenbusse, die in 4 Monaten "rausgeschissen" werden, für den gleichen Preis erscheinen wie Projekte, in denen Jahrelange Arbeit steckt.
    Ich bin mir allerdings auch sicher, dass man bei diesem Projekt über Umfang und Qualität vermutlich nicht meckern können wird und die Preis/Leistung stimmt.
    Dreist finde ich die Aussage, dass nen SG321UL schön wäre, trotzdem keinesfalls. im Grunde zeigt das doch nur das Interesse der Community an diesen Fahrzeugen und wer weiß denn, ob nicht aus den mitgelieferten Fahrzeugen mal nen SG entsteht, eventuell auch als auskopplung und eigenes DLC oder als Mod?
    Das war ja von Petterson keinesfalls eine Forderung, sondern nur ein "ach wie schön doch ein SG gewesen wäre". Wie du dich da so getriggert fühlen kannst, ist mir ein Rätsel. :D

  • Wie kriege Blinklichter auf meine Objekte

    GIF geht nicht, nein.
    night-texturen funktionieren ähnlich dem Prinzip von Bamp. du nimmst dafür einfach die variable "licht1" und fügst folgenden Eintrag in die Model.cfg unter dem [mesh] eintrag deines Modells ein:


    Code
    [matl_change]
Dein_Texturname.jpg
0
light1

[matl_item]

[matl_nightmap]
Dein_Texturname_leuchtend.jpg

    besitzt dein Modell nun mehrere Texturen, fügst du den o.g. Code nochmals ein und änderst entsprechend die namen der Textur und der Leuchttextur.

  • The Bus

    Zitat von Swissletsplay

    Ich muss aber auch sagen, dass The Bus schon eine gute Tiefe hat, mittlerweile. Klar, nicht vergleichbar mit OMSI. Aber das ist auch teilweise der Engine geschuldet, denn einen eigenen Bus (samt allen Details) ist nunmal in der Unreal schon komplex...aber gewisse Punkte wie Sound dürften auch nochmals ein Stück besser sein...

    Ich hab das nie gelernt und bin mir zu 100% sicher, dass meine, in 2 Stunden zusammengeklöppelte Gelenkbusphysik, qualitativ die von TML bei weitem übersteigt.

    Die Busphysik in OMSI ist zudem auch eingekauft (Open Dynamics) und ist quasi eine simple Line-Trace Physik, bei der - quasi - ein "Strahl" an jedem Rad vom oberen Punkt der Aufhängung nach unten geschossen wird. Bei diesem Strahl wird die Entfernung gemessen, bis dieser ein Objekt/Spline/was auch immer mit Kollision trifft. Ist dieser Wert größer als das soll, wird das Fahrzeug abgesenkt, ist es kleiner als der Sollwert, wird es angehoben. Das führt auch zu dem "aufschaukeln" bei niedrigen Framerates, weil die Intervalle der Berechnung immer länger und damit ungenauer werden. Das ist übrigens auch der Weg, den Nvidia's PhysX geht und so auch nativ in der UE umsetzbar ist.

    Ich bin es leid, dass hier immer das Argument "Unreal Engine" vorgeschoben wird. Aber muss ja unrealistisch sein, weil sie ja schon "unreal" im Namen hat. :D
    Eine OMSI-like Physik ist in der UE innerhalb weniger Stunden umgesetzt. Das könnte jeder Dulli sogar in Blueprint mit ein wenig Youtube Tutorial und Recherche, wer C++ beherrscht braucht eventuell ein paar Stunden länger, aber es ist auch dort zügig Umsetzbar.

    Natürlich muss man, wenn die physikalische Grundlage steht, hier noch die Fahrzeuglogik (korrekt!) Scripten. Da scheitert es schlicht an Fachwissen und Interesse, nicht daran, das TML das nicht könnte. Die OMSI Physik wäre ohne die Pionierarbeit von Marcel und Rüdiger, die Getriebe und Motor in vielen Details umgesetzt haben, auch nicht so gut, wie sie von uns Empfunden wird.
    Es ist aber einfacher, das UE Wheeled-Vehicle Template zu nehmen, was man vermutlich schon seit dem Fernbus mitschleppt, auf C++-Ebene halbherzig anzupassen und dann nie wieder anzufassen.

    Eine Gewisse Spieltiefe bringt das Spiel mit, keine Frage - aber wenn es "Der BUS" heißt, und das Hauptaugenmerk des Spieles nicht überzeugt, wird hier am Thema Vorbei entwickelt und/oder der falsche Begriff für das Spiel verwendet.

  • Allgemeine Fahrzeugwünsche der Community

    Zitat von Omsifan62

    soweit ich weiß hat Chrizzly eig ein update mit dieser variante geplant nur halt ist besagtes update nie gekommen.


    So stimmt das nicht ganz. :D ich hatte mal in einer Nacht- und Nebelaktion das Außenmesh zusammengefriemelt, ja. Es wäre grundsätzlich auch schnell gemacht, das ganze als Update oder eigenes DLC zu veröffentlichen. Um meinem eigenen Qualitätsstandard zu entsprechen, würde das aber auch einen Rework der Stadtbusfamilie selbst bedeuten und zudem fehlen mir wichtige Referenzen, was den restlichen Aufbau angeht. abgesehen von der Fensterkante sind nämlich auch Innenraum, z.T. Podeste und Fahrerkanzel, womöglich Türen und weitere Dinge unterschiedlich. So einfach ist es also nicht, das ganze mal eben in einer vernünftigen Simulationstiefe und ordentlich aussehend umzusetzen.


    Zitat von Bottroper Repaints

    Als Zusammenfassung für das Thema des Threads habe ich eine übersichtliche Liste aller Busse erstellt, die (meiner Meinung nach) noch für OMSI 2 als AddOns wünschenswert wären (in der linken Spalte die Modelle, in der rechten ggf. die Varianten):

    um SL202, SG2x2, SÜ242 und eventuell SM1x2 kümmere ich mich aktuell.

  • TUT Daueranimation zum Wiki hinzufügen

    Eventuell sollte man dort noch nen kleinen Hinweis Verankern, wie sich die Achsenrotationen in OMSI Verhalten, um das Objekt entsprechend zu drehen.


    Es wird ja standardmäßig über die x-Achse rotiert, dreht man den Ursprung mittels origin_rot_z um 90°, also quasi um die Hochachse um 90° gedreht, wird das Objekt dann beispielsweise Standardmäßig über die längsachse animiert. Bei Daueranimationen vorallem in Verwendung mit anim_trans relevant, damit man es, je nach originaler Objektausrichtung, auch in die richtige Richtung verschiebt.
    Hab jetzt nicht in den Animationen-Eintrag geschaut ob dazu schon ein Hinweis existiert, aber im Rahmen der Daueranimationen sollte das meiner Meinung nach erwähnt werden.

  • Probleme mit Script für DFI

    erstell doch mal nen testscript mit
    "String123" (S.$.Dest1)

    "String123" (S.$.Dest2)

    "String123" (S.$.Dest3) etc.


    und PRÜFE, ob das funktioniert.
    Wenn man etwas debuggen will und hilfe im Forum suchst, solltest du das auch schrittweise sinnvoll durchführen, und nicht davon ausgehen dass es funktioniert, nur weil eine beschreibbare variante funktioniert.

  • Probleme mit Script für DFI

    Also Grundsätzlich finde ich die Art des Scriptens suboptimal (Textfelder einfach mehrfach überschreiben, wenn ein vorheriges Ergebnis nicht (mehr) valide ist) aber grundsätzlich kann ich da jetzt rein vom syntax nichts kritisches erkennen. Was sagt das Logfile? Hast du wirklich alle Textfelder mal geprüft, ob sie sich per Script beschreiben lassen? Ist der Font in Ordnung?