Beiträge von DerGrafikfehler

Zitat von Noah2508

Hatte ich auch schon vermutet, allerdings heißt der Ordner bei mir schon "Tablet-Display".

Dann bitte ich mal um eine Logfile.

Da sind keine Fehler vorhanden? Flasche Logfile? Da steht jedenfalls nichts auffälliges drin, mit dieser (hierfür irrelevanten) Ausnahme:

212 23:26:02 -  -     Warning:       Error while loading file vehicles\CSB_J_MB_O530\\script\LAWO\Vmatrix_varlist.txt
213 23:26:02 -  -     Warning:       Error while loading file vehicles\CSB_J_MB_O530\\script\LAWO\Vmatrix_stringvarlist.txt

Zitat von Noah2508

Die beiden Buttons leuchten nun auch, aber das Display zeigt weiterhin nichts an.

In der v1.0.0 hat sich ein Fehler in der Ordner-Benennung eingeschlichen. Der Ordner "RBL-Tablet" im Texture-Ordner muss "Tablet-Display" heißen. Liegt vermutlich daran.

Du hast ganz offensichtlich nicht die varlists mit in die Busdatei eingetragen oder die Anzahl der varlists nicht angepasst. Dadurch entsteht dieser Fehler.

Viel wirst du da nicht machen können. Omsi ist nicht wirklich Multicore-optimiert, und das lässt sich auch nicht ändern. Die Engine ist mittlerweile über 10 Jahre alt und war damals auch nicht optimiert, was sie heute ebenfalls nicht ist. Mit steigender Leistung der Hardware über die Jahre ist es zwar mittlerweile durchaus möglich, Omsi halbwegs flüssig zu spielen, aber an die Performance von anderen Spielen kommt man da einfach nicht ran. Da muss man die Einstellungen schon sehr weit herunter schrauben.

Du kannst aber vermutlich noch bisschen was rausholen, wenn du dich mit den KI-Einstellungen herum spielst. Sonst bleibt dir eigentlich nichts übrig.

Ja, und nein. Jeder Bus ist anders positioniert (in Blender), anhand dieser Positionen werden weitere Fahrzeugdaten berechnet. Omsi ist in diesem Thema etwas eigen, da unter anderem Midibusse wie normale Busse mittig positioniert sein müssen. Sind sie aber oft nicht, weil diese in einem Paket enthalten sind oder auf einem anderen Bus basieren (eben CFL K oder A47). Das macht die Arbeit einfacher, allerdings die Fahrphysik unrealistischer. Mit einigen Tricks kann man dem entgegen wirken (unsichtbare dritte Achse z.B.). Ich hab mir den mal so zurecht gebastelt, dass die Physik vom Bus besser stimmt:

    ////////////////////////////////////////////////////////
        Physikalische und geometrische Grunddaten
    ////////////////////////////////////////////////////////

[mass]
10

[momentofintertia]
300
80
300

[boundingbox]
2.52
10.5
2.4
0
0
1.7

[schwerpunkt]
1.1265

[rollwiderstand]
1350

[rot_pnt_long]
-1.29472

[inv_min_turnradius]
0.126789

[ai_deltaheight]
-0.10

    Front axle :

[newachse]
achse_long
3.18772
achse_maxwidth
2.339
achse_minwidth
1.765
achse_raddurchmesser
0.953
achse_feder
283.878000
achse_maxforce
42.75
achse_daempfer
40
achse_antrieb
0


    Rear axle:

[newachse]
achse_long
-1.29472
achse_maxwidth
2.36
achse_minwidth
1.086
achse_raddurchmesser
0.953
achse_feder
317.94336
achse_maxforce
150
achse_daempfer
40
achse_antrieb
1

    virtual axle:
    
[newachse]
achse_long
-3
achse_maxwidth
2.36
achse_minwidth
1.83
achse_raddurchmesser
0.953
achse_feder
170
achse_maxforce
300
achse_daempfer
40
achse_antrieb
0

Alles ab "Physikalische und geometrische Daten" müssen mit dem hier ersetzt werden. (um Zeile 380)

Ein Krefrather Leihbus bei der AVG Ahlheim.

Bus: MB O530G CNG Viertürer (privat von Sonderwagen , einige kleinere Mods von mir)

Map: Ahlheim v3.1

Texttexturen. Das Ding, das dafür sorgt, dass das Display auch was anzeigt.

Im Wiki da, ganz unten: Lè Klick

Schon mal dran gedacht, da ne Texttextur einzubauen?

Zitat von tempo1

Man verzeihe mir die Leitplanke, ich hasse [toSpline].

Setze den Haken bei "Tangential to Spline", dann löst sich das Problem von selbst.

Zitat von IREgio612

Das ganze als Objekt dort einfügen ist auch nicht die beste Lösung...

Das ist die Performance-freundlichste Lösung, die du hast. Du kannst sonst wirklich nur mit Bordsteinen und Terrains Splines arbeiten, mehr gibt Omsi in der Hinsicht nicht her.

Möglicherweise ist auf der Kachel ein Spline mit Länge 0? Da gibts im Editor einen Knopf, mit dem man das überprüfen kann. Sowas hat bei mir schon öfter solche Probleme ausgelöst.

Inwiefern sehr dick?

Die Tiroler Post hilft in Baumgarten aus.

Protestanten in der Schippergasse. Fahrtbehinderung....

...Zu guter Letzt aber dann doch noch zum Ikea geschafft und in die Mittagspause gegangen.

Bus: MB O530FL 2t OM457 Voith mit Mobitec

Map: Baumgarten

Repaint: Postbus Regiobus Tirol

Kurze Testfahrt mit dem Conecto in Ahlheim.

Am Hauptbahnhof wurde der Solo durch einen Gelenkwagen getauscht. Grund war das besonders hohe Fahrgastaufkommen. Stellt sich heraus, dass die Werkstatt bei dem Bus die Frontmatrix falsch konfiguriert hat. Naja, kann man nichts machen.

Bus: MB Conecto G E6 Voith/Conecto E6 ZF mit Mobitec 16/24px

Map: Ahlheim v3.1

Repaint: AVG Ahlheim

Siehe hier: Klick

Probier mal, in der Constfile der Matrix den Wert unter Matrix_PageDuration zu verändern. Klingt jedenfalls so, wie als würde der Wert die Anzeigedauer bei Wechselzielen beeinflussen.

Btw: Ein Thread im falschen Bereich kann verschoben werden, es müssen nicht zwei Threads sein.

Zitat von dari19

CD_LineTerminus

Macht Sinn, dass der Fehler kommt. Die Variable kommt vom Faremaster, dementsprechend ist die auch bei den varlists der IBox nicht drinnen. Trag in der .bus die Stringvarlist vom Faremaster dazu, dann ist das Problem behoben.

Zitat von IREgio612

Das würde aber vieles unbrauchbar machen. Die Texttexturen sind halt einfach so viel, damit der Drucker vieles individuell darstellen kann... Gerade was den Fahrscheinverkauf angeht! Da ist ja fast jede Zeile auf das TicketPack bzw. die Map angepasst... Da kann ich nicht einfach sagen, ich fasse das mal zusammen Aber ich verstehe was du meinst...

Gerade DAS geht eben mit Scripttexturen. Eine Scripttextur ist im Prinzip eine Texttextur, nur halt mit ein paar mehr zusätzlichen Funktionen, wie eben der Zeichnen-Funktion (STDrawRect) oder der Bitmap-Ladefunktion (STLoadTex) bzw. der auf der Textur genau platzierbaren Texte (STTextOut erfordert absolute x- und y-Koordinaten auf der Scripttextur für den zu schreibenden Text). Du kannst mit einer Scripttextur alles machen, was du mit einer Texttextur auch machen kannst. Manche Dinge (Textzentrierung bei unterschiedlicher Textlänge, Bsp. Vollmatrix) benötigen eine scriptseitige Umsetzung, die allerdings nicht besonders kompliziert ist. Und auch das Fahrschein-Auswahl-Menü lässt sich deutlich einfacher umsetzen, da du auf der Scripttextur einfach nur einen bestimmten Bereich invertieren musst.

Ich nehme mal an, dass die meisten Nutzer Probleme mit dem Einbau in der Model.cfg haben? Würde mich bei der riesigen Menge an Texttexturen jedenfalls nicht wundern. 50 Stück sind dann doch ein bisschen sehr viel, so mancher Bus hat insgesamt weniger. Das kannst du deutlich vereinfachen, wenn du statt Texttexturen eine Scripttextur nutzt. Bei deinem Modell würde das nebst einer ordentlichen Reduktion der Texttexturen auch die Menge an .o3ds deutlich reduzieren, da du hier nur ein einziges Plane für das gesamte Display brauchst.

Das ist zwar scriptseitig mit etwas Arbeit verbunden (Du kannst u.a. nicht "@" als Zeilenumbruch verwenden), dürfte bei der Umsetzung aber wohl weniger ein Problem darstellen. Zudem kannst du einen großen Teil der User Interface-Texturen(=im Prinzip alle außer display_mode_8) im Script lösen, die bestehen ja eigentlich nur aus Linien, weißen, invertierten Boxen und Text. Das Krauth-Logo und das Schloss kannst du als eigene Zeichen einbauen und dann ebenfalls direkt auf die Scripttextur drauf schreiben.

Solltest du dazu noch weitere Fragen haben, schreibe mir bitte eine PN.

        (L.L.IBIS_mode) s0 0 = l0 8 =

müsste

        (L.L.IBIS_mode) s0 0 = l0 8 = &&

sein. Sonst fällt mir nichts auf.