Beiträge von Perotinus

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!

    Geht mir weniger um die Verständlichkeit, sondern mehr um die ziemlich flapsige Form der Frage, die er hier gewählt hat. Ich meine das als guten Rat, auch für andere Momente im Leben: Wenn man von Anderen etwas will, sollte man sich erkennbare Mühe beim Verfassend er Anfrage geben. Hat auch was mit Respekt zu tun.


    Aber ich lese den Post gerade auch nochmal und stelle fest, dass mich das "???/" beim Lesen aus dem Satz geworfen hat, sodass da ein zusammenhangsloses "Welches Template???" bei mir ankam.

    Du suchst Hilfe? Dann folgender Vorschlag: Schreib deinen Post nochmal neu, beschreib genau dein Problem und das in Hochdeutsch und in einer vernünftigen Form. Ich denke, dann könnte sich eher jemand finden, der bereit ist, dir zu helfen.

    Hallo zusammen,


    es gebührt mal wieder mir das Sonntagsupdate zu bestücken. Deshalb quäle ich euch nicht lange mit Worten und Bildern, sondern lasse Klänge sprechen. Heute stelle ich Euch den aktuellen Stand der Sounds des S315UL vor. Wer mich kennt weiß, dass ich gerne am Motorsound optimiere bis die Polizei kommt, deswegen stellt das hier jetzt auch nur eine Momentaufnahme und nicht zwingend den finalen Zustand dar.

    Der Klick auf das Bild führt zum entsprechenden Track auf Soundcloud.


    1. S315UL '94 mit OM447hLA Euro 2 und ZF S6-85 Schaltgetriebe, samt dem dafür charakteristischen Singen des Getriebes: https://on.soundcloud.com/jnfKn


    2. S315UL-GT '99, mit OM447hLA Euro 2 und MB GO190-Schaltgetriebe, ohne Singsang, dafür mit etwas mehr Bass in den höheren Drehzahlen: https://on.soundcloud.com/Stvq7


    3. S315UL '2003, mit OM457hLA Euro 3 und ebenfalls MB GO190-Schaltgetriebe: https://on.soundcloud.com/kx2v1


    Die anderen Getriebevarianten, Halbautomatik und ZF-Automatik sind noch in Entwicklung bzw. Überarbeitung. Deswegen möchte ich die an dieser Stelle noch nicht vorstellen. Aber jede Woche hat einen Sonntag, vielleicht bietet sich dafür dann ein anderer an :-)

    Features, die fehlen, sind in einer Early Access-Version völlig legitim, aber wenn man stolz berichtet, dass es das Ziel war, die Grafikabstimmung in der UE5 genauso zu haben, wie sie in der UE4 war, dann klingt das für mich nach einem deutlichen "wir haben nicht vor, die Grafikabstimmung zu ändern". Ich find' sie halt echt nicht schön und total unrealistisch. Da gefällt mir OMSI in seiner veralteten Schlichtheit, aber auch charmanten unaufdringlichkeit, deutlich besser. Und ja, mir ist bewusst, dass Grafik-Nerds natürlich nen anderen Schwerpunkt haben. Aber im Vergleich zu TramSim wirkt TheBus einfach total überzogen.

    Oh mann, auch hier wieder keine Stereo-Fahrzeug-Sounds, von der sonstigen Qualität des Sounds will ich erst garnicht sprechen. Und die Grafik ist für meine Augen auch immer noch viel zu überzogen und unrealistisch. So langsam komme ich an den Punkt, wo mir egal ist, ob und wie Modding in TheBus möglich sein wird, weil ich eh keine Lust haben werde, etwas dafür zu entwickeln.

    Schleswig-Holstein Ich habe hauptsächlich IREgio612 gemeint, der tatsächlich von einer fest installierten LZA schrieb. Nichtsdestotrotz ist die Diskussion, so konstruktiv sie auch sein mag, an dieser Stelle etwas überflüssig, weil überhaupt nicht zur Debatte steht, die Engstelle anders umzusetzen.

    Versteht mich nicht falsch, die Hinweise und Tipps zu mancherlei Problemlösungen sind wertvoll und hilfreich, aber man bekommt als Entwickler manchmal das Gefühl, dass plötzlich erwartet wird, dass wir alle, in diesem Fall KI-Probleme, die Omsi nunmal hat, durch alle bestmöglichen Workarounds lösen, auch wenn die Probleme bisher auf der Map kaum Relevanz haben. Und dann geht es plötzlich um Stopschilderproblematiken, über die man selber noch nie gestolpert ist, und dass davon ausgegangen wird, dass wir dafür sicher schon Lösungen haben. Das macht ein bisschen Angst, dass am Ende manch einer überhöhte Erwartungen hat und enttäuscht ist, wenn sich die KI in vielen Punkten doch so verhält, wie auf allen anderen Omsi -Maps auch.

    So ein Projekt ist erheblich umfangreicher, als ein Fahplanupdate oder eine Innenanzeigenmod. An Ideen, was man an Features und Workarounds umsetzen KÖNNTE, mangelt es uns nicht. Aber das braucht alles Zeit für Überlegungen, Probieren, Tests, Korrekturen usw., sodass einfach nicht alles umsetzbar ist, was einem als Idee im Kopf schwirrt. Zumindest nicht, wenn man irgendwann fertig werden will.


    Sorry für den kurzen Einblick in die Seele eines Entwicklers, aber vielleicht hilft es bim Verständnis, wenn wir manchmal etwas genervt reagieren :)

    Verstehe gerade (mal wieder) die Diskussion nicht. Die ganze Geschichte ist nach einem realen Motiv gebaut, warum sollte man da in einem thüringischen Dorf im Jahre 2005 irgendeine hochintelligente Anforderungsampelschaltung vorfinden? Zudem ist die Stelle auch für sich begegnende PKW sehr eng.

    Glaubt uns einfach, dass wir uns auch Gedanken machen beim Bau und solche Dinge, wie hier, bewusst und überlegt eingebaut werden. Das ganze Projekt dauert doch so lange, weil wir eben nicht alles irgendwie hinklatschen.


    Zum Ampelbeispiel mal ein paar Hintergrundgedanken: Wie man sieht hat das Dorf noch nicht das "Aufbau Ost"-Dorferneuerungsprogramm durchlaufen, was aber sicher in ein paar Jahren passieren wird. Dann wird man sich auch um eine elegante Lösung für die Engstelle kümmern. Vorerst hat aber das Straßenbauamt die provisorischen Ampeln aufgestellt, um die Situation zu entschärfen.

    mal ein paar kleine Worte des Friedens willens:

    Danke, schön geschrieben! Und lasst mich noch ergänzen: Wir geben uns wirklich Mühe, sowohl beim Bus, als auch bei der Map möglichst viel aus OMSI herauszuholen. Das heißt aber nicht, dass wir die Grenzen, die OMSI nunmal, wie jedes Programm, hat, überwinden können (Stichwort KI auf schmalen Straßen). Und das heißt auch nicht, dass wir in allen Diszipinen die Kompetenz haben, alles bisher Dagewesene zu überbieten (Sichwort Matrixscript). Wir versuchen es, aber gebt uns die Chance, unsere Grenzen selber auszuloten.


    Und was die Fragen zu den ganzen Details angeht: Lasst euch überraschen! Es wird sicher in den nächsten Wochen und Monaten noch ein paar Sonntagsupdates und zu Release das ein oder andere Video geben, mit deren Hilfe man entscheiden kann, ob einen Map und Bus ansprechen. Und wenn ja, dann heißt es: Selber entdecken!

    Also, hab mal nachgeguckt:

    1. Die Matrix hat die übliche Initialisierung

    2. Sie nutzt die selben Ziel-Suffixe, wie die Busfanat-Matrix: *K für Kleinschrift (einzeilig), *M für Mittelschrift (einzeilig), *B für Fettschrift (zweizeilige Ziele), *I für Invertierung und *N zum Ausblenden der Liniennummer.

    3. Bitmaps werden unterstützt

    4. Linien mit Buchstaben können über die Hofdatei definiert werden. Das steht dann im Handbuch genauer.

    5. Natürlich wird die universelle Hofdatei unterstützt. Die Strings 11 und 12 (busfanat) werden für die 1. und 2. Zeile ausgelesen. Wenn diese nicht vorhanden sind, werden die Strings 1 und 2 ausgelesen.

    Unterschiedliche Schilderungen an Front und Seite sind nicht möglich.


    Ich denke, das ist ein ordentlicher, weitgehend praxisgerechter Umfang. Und für die Matrix-Freaks ist das Thema ja sowieso kein Problem, weil sie sich das Script auf Cooper-Strings umbauen oder sowas.

    Wie gesagt, da sind wir ein bisschen beschränkt, weil wir nicht auf Coopers über Jahre entwickelte System zurückgreifen können. Da unser Matrix-Scripter aber momentan keine Zeit hat und ich persönlich weder die Kompetenz, noch das Interesse habe, ein ausgeklügeltes System aufzuziehen, bitte ich darum, nicht den allergrößten Funktionsumfang zu erwarten. Ich würde die Zeit, die ich bräuchte, um mich in diesen Themenkomplex einzufuchsen, doch lieber in die ein oder andere Ausstattungs- oder Längenvariante des Setras stecken. Nach Release stelle ich, wenn Interesse besteht, auch gerne die Modell-Dateien der Matrix-Planes für Mods zur Verfügung.

    Nein, die Cooper-Lawo darf nicht mehr veröffentlicht werden, schon gar nicht in Payware. Wir haben eine eigene Lösung. Fragt mich aber nicht nach den Funktionen, da muss ich mich erst selber wieder einarbeiten, da Matritzen so gar nicht mein Thema sind. Es sind weniger, aber sie sind ausreichend für den Thüringer Wald.

    Mir wäre neu, dass es ein Problem ist, M&R-Content zu verwenden. Frühe Busse, wie der NL202 oder der S215UL habe auch fleißig M&R-Texturen verwendet. Illegal war der MAN SL202, weil da eine Front eines v-Bus-Modells von Rostock4Ever verwendet wurde, oder irgendsowas in der Art.

    Nur mal am Rande: Nachtbeleuchtung ist generell ein alter Hut. Es mag überraschen, aber man konnte die u. a. schon in Setra S 300er NF/UL vorfinden.

    Ich würde da sogar noch weiter zurückgehen in die O303-Reihe.


    In OMSI kannst du einem Objekt maximal vier künstliche Lichtquellen zuweisen. Diese Lichtquellen können zudem nur punktuell Licht absondern.

    Und wenn man sich den normalen Citaro anschaut, gibt es vorn beim Fahrer einen Punkt und die restlichen drei sind auf den Innenraum verteilt.

    Und da man meist viele Objekte verbindet (alle Sitze in einem Objekt, alle Haltestangen in einem Objekt) ist die Kapazität der Lichtpunkte zu 100% ausgeschöpft.

    Das ist im Prinzip richtig, in der Praxis aber nicht und außerdem, wenn man will, durch einen einfachen Workaround zu lösen.

    In der Praxis ist es tatsächlich so, dass Innenräume gern in mehrere Teile aufgeteilt werden, u.a. um genau diese Lichtproblematik zu lösen, aber auch, um z.B. eine Modulbauweise mit verschiedenen Varianten umzusetzen. Sitze müssen sogar in der Regel aufgeteilt werden, da diese, wenn man versucht die originale Form einigermaßen genau zu treffen, doch eine stattliche Anzahl an Polygonen bekommen, an denen dann der o3d-Converter scheitert.

    Der einfach Workaround besteht darin, dass man das Innenmesh (oder die Teile) mehrfach in die model.cfg eingrägt und mit einer visible-Variable an die Innenbeleuchtung knüpft. So kann z.B. wenn die Nachtbeleuchtung eingeschaltet wird ein neues Mesh geladen werden, bei dem andere Lichtpunkte wirken, als bei dem Standardmesh für Normalbeleuchtung. Ob dieser Aufwand sinnvoll ist für eine Sparbeleuchtung, die im Linienverkehr, auf den es in OMSI nunmal ankommt, selten bis nie genutzt wird, ist eine andere Frage.