[Support] Init EVENDpc

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!
  • Der Fehler liegt wirklich in der Model-Datei:

    Zitat

    2520 12:40:08 - - Warning: vehicles\Citybus 530 Facelift by Kajosoft\model\model_o530_e3_2.cfg, line 16780: Mesh with Ident Fahrertuer not found!

    Die mesh_ident "Fahrertuer", auf welche sich der EvendPC als "animparent" bezieht, gibt es nicht in deiner Model-Datei, deswegen kann er den Bus auch nicht laden. Du musst ein in der Datei vorhandenes "mesh" als "animparent" festlegen.
    Wenn ich das allerdings richtig in der Datei gesehen habe, ist die Fahrertür Teil des Fahrerkabine-Objekts (bzw. sie ist nicht als eigenes Teil in der Modeldatei geführt). Heißt du musst am Ende jeder verfügbaren Option der Fahrerkabine einzeln die Einträge des EvendPC einfügen, mit der jeweiligen Mesh-Variante als "animparent". DIe heißen irgendwas mit "drzwkmU" oder "wnetkLF"

    Alternativ - da weiß ich nicht wie gut das am Ende ausschaut - kannst du versuchen, den Zahltisch Mesh als Parent festzulegen und den EvendPC per Daueranimation zu verschieben. Dann wandert der mit jenem halt mit, wenn du ihn öffnest. Sind aber auch zwei Varianten in der Datei vorhanden, heißt auch hier für beide einzeln am Ende eintragen.

  • Der Fehler liegt wirklich in der Model-Datei:

    Zitat

    2520 12:40:08 - - Warning: vehicles\Citybus 530 Facelift by Kajosoft\model\model_o530_e3_2.cfg, line 16780: Mesh with Ident Fahrertuer not found!

    Die mesh_ident "Fahrertuer", auf welche sich der EvendPC als "animparent" bezieht, gibt es nicht in deiner Model-Datei, deswegen kann er den Bus auch nicht laden. Du musst ein in der Datei vorhandenes "mesh" als "animparent" festlegen.
    Wenn ich das allerdings richtig in der Datei gesehen habe, ist die Fahrertür Teil des Fahrerkabine-Objekts (bzw. sie ist nicht als eigenes Teil in der Modeldatei geführt). Heißt du musst am Ende jeder verfügbaren Option der Fahrerkabine einzeln die Einträge des EvendPC einfügen, mit der jeweiligen Mesh-Variante als "animparent". DIe heißen irgendwas mit "drzwkmU" oder "wnetkLF"

    Alternativ - da weiß ich nicht wie gut das am Ende ausschaut - kannst du versuchen, den Zahltisch Mesh als Parent festzulegen und den EvendPC per Daueranimation zu verschieben. Dann wandert der mit jenem halt mit, wenn du ihn öffnest. Sind aber auch zwei Varianten in der Datei vorhanden, heißt auch hier für beide einzeln am Ende eintragen.

    Das ist vollkommen irrelevant da es nur eine Warning ist. Der Bus mit Drucker sollten trotzdem Funktionieren. Habe das bei einigen Fahrzeuge auch weil ich bisher zu faul war das animparent zu entfernen.

    Aus seiner zu Letzt geposteten Logfil geht ja der Fehler AMUAV.CNAVO.MV.S was auf eine nicht vorhandenen Scripttextur hinweist. Warum dies passiert kann ich aber auch nicht nachvollziehen da alles richtig eingetragen ist

  • Die mesh_ident "Fahrertuer", auf welche sich der EvendPC als "animparent" bezieht, gibt es nicht in deiner Model-Datei, deswegen kann er den Bus auch nicht laden. Du musst ein in der Datei vorhandenes "mesh" als "animparent" festlegen.

    Komplett irrelevant.


    Wenn ich das allerdings richtig in der Datei gesehen habe, ist die Fahrertür Teil des Fahrerkabine-Objekts (bzw. sie ist nicht als eigenes Teil in der Modeldatei geführt).

    Ist so gar nicht möglich. Die Fahrertür ist eine eigene o3d (drzwkm*.o3d).



    Sind die Scripttextur-Indizes in der Constfile richtig gesetzt? Außerdem wäre es sinnvoll, die Scripts vom alten IBIS und Drucker auch zu entfernen (Stringvarlists drinnen lassen!)

  • Sind die Scripttextur-Indizes in der Constfile richtig gesetzt?

    Diese hab ich geändert, hatte ich vergessen auch umzuändern.

    Außerdem wäre es sinnvoll, die Scripts vom alten IBIS und Drucker auch zu entfernen (Stringvarlists drinnen lassen!)

    Diese habe ich gerade entfernt bis auf Stringvarlists, er schmieß mir eine Zugriffsverletzung.

    Dateien

    • logfile.txt

      (504,38 kB, 4 Mal heruntergeladen, zuletzt: )

    Fragen zu Modifizierten Bussen werden ignoriert!

  • auch die alten Varlisten muss man drinlassen

  • auch die alten Varlisten muss man drinlassen

    Wieso sagt er dann dass ich bis auf Stringvarlist alles rausnehmen soll?


    Gut diese hab ich wieder eingefügt, jetzt zeigt das Setvar Display keine Zeichen mehr an

  • Wieso sagt er dann dass ich bis auf Stringvarlist alles rausnehmen soll?

    Ich habe bis gestern Abend selber nicht gewusst, was bei den Kajott-Bussen alles notwendig ist, weil ich den Drucker bis dato nicht in einem solchen Bus verbaut hatte. Inzwischen kann ich mehr sagen:

    • die originalen Varlists und Stringvarlists müssen in der Busdatei bleiben.
    • Für die originale Matrix, Entwerter und Innenanzeige ist ein Brückenscript notwendig (habe ich bereits geschrieben), idealerweise müssten die Komponenten aber auch getauscht werden.
    • In der main.osc muss unter {frame} noch die Zeile 1 (S.L.Refresh_Strings) hinzugefügt werden, damit die Textfelder aktualisiert werden.

    Müsste alles fürs Erste sein, eine Anleitung kommt bei Zeiten mal.

  • Für die originale Matrix, Entwerter und Innenanzeige ist ein Brückenscript notwendig (habe ich bereits geschrieben), idealerweise müssten die Komponenten aber auch getauscht werden.

    In wie fern ein Brückenscript? Bzw. was genau müsste idealerweise getauscht werden?

    Fragen zu Modifizierten Bussen werden ignoriert!

  • der Kajott Citaro ist so weit fern ab von OMSI's IBIS und Krüger / Annax Matrix Standard und verwendet vermutlich andere Variablen.


    wie ein Brückenscript in Etwa aussieht, kann man hier nachschauen:

    https://forum.omnibussimulator…ei-generationen/&pageNo=1


    hier wurde den 3 Generationen Bussen eine Krüger+ Matrix verpasst, wo aber auch ein Brückenscript nötig ist, dass die von den HH-Druckern ausgesendeten Variablen als Aufforderung zum Schildern an der Matrix ankommen.


    Stell dir das Brückenscript vor, wie einen Dolmetscher oder einen Adapterstecker. Wie man das in diesem speziellen Fall schreibt, keine Ahnung.




    was natürlich auch geht, andere Matrix, z. B. Krüger+(+) oder Lawo oder so einbauen, die deutlich näher am OMSI Standard liegen, wo IVU und EvendPC besser mit arbeiten können. Ja, ich weiß, riesen Aufwand.