K+/K++ Matrix für die MAN Stadtbusfamilie?

Welcome to the OMSI-WebDisk!
You might have certainly noticed that the most content of user postings is written in german. But you are not forced to translate your text in german (the translations are usually not understandable anyway; but if you have learned it and want to practice, of course feel free to try it). You can write your text in english language and you will see that the community will anwser in english, too. Take it easy, our community is flexible.
  • Hallo zusammen!

    Gibt es für die MAN Stadtbusfamilie einen Mod, damit diese auch die Sonderanzeigen für K+/K++ Matrizen lesen kann? (Also inversive Darstellung usw.).

    Ich habe mich schon an einen Selbsteinbau gewagt, allerdings zeigt die Matrix dann immer Vollbild (Mit einer Matrixtextur die in der Modelldatei garnicht zugewiesen ist??).

    MfG. Luis

  • Schade, muss ich wohl weitertüfteln.

    Ich habe mal ein Bild angehängt, wo man sehen kann wie es im Moment aussieht und wie es aussehen soll. Die volle Matrix ist immer da, egal ob eine Linie geschildert ist oder nicht

    Man kann es zwar auf dem Bild nicht sehr gut erkennen, aber die "Punkte" der Matrix beim NL263 haben auch eine andere Textur als die des NL202, obwohl ich die entsprechenden Einträge (Scripttexturen, [matl]-Einträge usw.) aus der Modelldatei des NL202 kopiert habe.


    @Admin: kann man das Thema ggf. zu "Fragen zur Erstellung von Modifikationen" verschieben? Ich denke da passt es jetzt besser hin

  • 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.

  • Ich habe das Script aus dem MAN NL202 aus dem Ordner "churaKrueger" verwendet und die entsprechenden Einträge in die Busdatei kopiert. Dadurch funktionieren zwar die Setvars der Matrix nichtmehr, darauf kann ich aber verzichten.

    In der Modelldateien habe ich die LED und LCD-Matrix sowei die breite Flipdot-Heckmatrix gelöscht und eben die Texturen der Flipdot angepasst.


    Durch herumprobieren habe ich herausgefunden, dass die Matrix komplett leer ist, wenn ich die Original verwendete Textur "vmatrix_voll_nue.dds" verwende. (Die Matrix funktioniert dennoch nicht). Ändere ich die Textur zur im NL202 mitgelieferten Textur ist die Matrix voll. Ich habe beide Texturen mal in Paint.Net verglichen, sie haben die gleichen Maße und sind sich sonst auch sehr ähnlich, ich kann mir das nicht erklären warum die Matrix bei der einen Textur voll ist und bei der anderen nichts anzeigt?

    Edited 3 times, last by Luis G: Neuigkeiten ().

  • So, habe die Modelldatei nun komplett neu angefangen und nur die Scripttextures vom NL202 übernommen, die Matrix-Einträge weiter unten sind unverändert.

    Siehe da, es funktioniert:


    bei der Matrix selbst ist unter [matl] die Datei "vmatrix_voll_nue.bmp" eingetragen, doch diese existiert im Textures-Ordner nicht?! Dort ist nur eine "vmatrix_voll_nue.dds" vorhanden. Dennoch funktioniert die Matrix nun, aber nur solange auch diese Textur eingetragen ist. Wird die Dateiendung auf dds geändert oder eine andere Textur zugewiesen, zeigt die Matrix wieder Vollbild.

    Hat hier jemand eine Lösung?

  • Ich könnte mir vorstellen, dass in der Modelldatei, also der entsprechenden .o3d ebenjene .bmp eingetragen ist. Sprich, Omsi kann mit deinen Einträgen in der model.cfg auch nur was anfangen, wenn du ebenjene Datei adressierst.

    Im Anschluss daran kommt ein weiteres, spannendes Omsi-Feature zum tragen, nämlich die tatsache, dass Omsi am Ende bei jeder textur, egal welchen Typs, noch mal nachsieht, ob in´m entsprechenden Texturordner auch eine gleichnamige .dds-Textur liegt. Wenn ja, nimmt Omsi einfach die, anstelle der eigentlich im Mesh verankerten, weil Omsi lieber .dds mag, als andere Texturtypen.


    Sprich, die eigentlich eingetragene .bmp ist nicht da, dafür eine gleichnamige .dds, die Omsi stattdessen nimmt, um aber in der model.cfg mit der entsprechenden Textur zu hantieren, musst du trotzdem weiterhin die eintragen, die auch in der .o3d drinne steht.


    Dass das in deinem Falle auch wirklich so ist, ist eine reine Vermutung. Klingt aber recht plausibel.

  • Ich habe mal versuchsweise der gewünschten Textur den Dateinamen der Originaltextur gegeben, und es hat funktioniert.

    Deine Vermutung hat sich wohl bewahrheitet.


    Jetzt stehe ich halt vor dem Problem, dass ich so keine K++ Matrix umsetzen kann, sondern nur die K+ Flipdot. Die K++ benötigt mehrere Materials eingetragen. Kann man Omsi irgendwie zwingen, die in der .cfg-Datei eingetragenen Materials zu verwenden?

  • 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.

  • Da die K++ mehrere Farben erlaubt, müssen auch mehrere Materials zugewiesen werden. Hier mal aus dem NL202:

    Hier hakt es, da die Matrix spinnt sobald ich das zugewiesene Material ändere.

  • 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.

  • Habe das mal umgesetzt, es hat aber nicht funktioniert. Die Matrix zeigt wieder Vollbild.

    Hier mal die Einträge aus der Modelldatei:

    (Die anderen Matrixeinträge sind rausgelöscht)

    Sobald ich die Textur unter [matl] ändere zeigt die Matrix Vollbild in Standarttextur

  • 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.

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

  • Habe jetzt endlich die Lösung gefunden: der benötigte Befehl war [matl_freetex].

    Jetzt funktioniert die K++ Matrix wie gewünscht.

    Vielen Dank für eure Hilfe!