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!

    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]".

    Les dir nochmal den Kommentar von Kartoffelphantom durch. wenn du versuchst, mit

    [matl]
    vmatrix_voll_led_h030s1.dds

    0

    den Materialkanal zu adressieren, wird dir das nichts bringen, da die Textur "vmatrix_voll_led_h030s1.dds" im Modell nicht hinterlegt ist. Du musst also den Texturindex mit "vmatrix_voll_nue.bmp" adressieren, damit OMSI auch weiß, welcher Textur er die Transmap zuweisen muss.

    wie oben schonmal erwähnt: Du kannst in EINEM Objekt MEHRERE Kanäle haben. Die Matrix muss dafür aber auch entsprechend gebaut werden. Da dies beim Stadtbus nicht der Fall ist, kannst du auch MEHRMALS das Objekt eintragen mit jeweils EINEM Kanal. die Funktion ist dann quasi die selbe.

    Aus deinem Script müsste man also entsprechend folgendes machen:


    Der Stadtbus hat getrennte Matrixmodelle. Einmal das Trägermesh und einmal die Flipdots selbst. die Krüger ++ nutzt 5 Kanäle, du musst also das Modell 5 mal aufrufen, mit jeweils der nächsten transmap.

    du kannst die textfelder auch mehrfach addressieren. einfach die modelldatei nochmal eintragen, mit der selben referenzierten textur, aber mit einem anderen Scripttexturkanal. Ob du nun ein Modell hast, in dem ein Mesh 3 mal mit 3 verschiedenen materialien existiert oder 3 meshes mit je einem kanal, ist egal. musst du nur entsprechend in der modelldatei umsetzen.

    hast du, abgesehen von den scripttexture einträgen, auch das script selbst auf die Krüger ++ angepasst?
    die Volle Matrix ist übrigens der Ausgangspunkt einer jeden Matrix. die Texture zu dieser findest du im Texturordner des Busses. Durch einen Transparenzkanal werden dann die Bereiche ausgeschnitten, welche keine Pixel enhalten. Irgendwas ist bei dir da vermutlich im Script oder in der Texturzuweisung schiefgelaufen.