Beiträge von ma7t3

Ich mache auch einfach mal spontan mit:

Moin,

ich müsste mir das heute Abend mal genau anschauen.

Grundsätzlich gilt aber natürlich, wenn ein anderer Eintrag nicht mehr gebraucht wird, kannst du den natürlich ersetzen bzw. einfach den vorhandenen anpassen.

Wie ist das überhaupt zu verstehen bei dir? Wolltest du die weiße Beleuchtung durch die Blaue ersetzen oder ist die zusätzlich zur weißen als neuer "Lichtmodus" quasi?

Genau, das ist möglich, du kannst einfach einen neuen Eintrag (am besten ganz am Ende hinter allen bestehenden) anlegen.

Ich zitiere aus dem Wiki:

Zitat von Tatra

[interiorlight]
Variable
Reichweite in Metern
Farbwert Rot
Farbwert Grün
Farbwert Blau
Position auf der X-Achse
Position auf der Y-Achse
Position auf der Z-Achse

Alles anzeigen

Das ist eigentlich alles wichtige.

Position und Farbwerte sollten eigentlich klar sein, genau so, wie die Reichweite.

Die Variable muss halt in einer Varlist vorhanden sein und vom Script des Busses auf 1 oder 0 gesetzt werden, je nach dem, ob das Licht eben ein- oder ausgeschaltet werden soll.

Damit die Lichtquelle andere Meshs auch korrekt anleuchtet, musst du noch unter jedes Mesh, dass von der Quelle beleuchtet werden soll, folgenden Befehl eintragen (bzw. anpassen, wenn er schon existiert:

[illumination_interior]
0
2
3
-1

Dort kannst du bis zu viert Lichtquellen definieren, die das Objekt anleuchten sollen, dabei werden einfach die Indexes der interiorlight-Befehle untereinander angegeben.

"-1" bedeutet quasi "nicht" verwendet. Wenn dein Objekt also bspw. nur von einer Lichtquelle mit Index 3 angeleuchtet werden soll, würdest du in der ersten Zeile eine 3 eintragen und die restlichen drei Werte auf "-1" setzen.

Im Beispiel oben wir das Objekt also von drei Quellen (Nr. 0, 2 und 3 angeleuchtet). Der vierte "Slot" ist noch frei.

Du müsstest also einfach den Index deines neuen interiorlight-Eintrags bei allen Objekten, die angeleuchtet werden sollen, in einem freien Slot eintragen.

Beachte aber, dass der Befehl immer nicht nur auf das aktuelle Mesh wirkt, sondern auch auf allen folgenden Meshs so übernommen wird, bis wieder ein neuer Eintrag folgt.

Sonst passiert es schnell, dass plötzlich Objekte, die garnicht angeleuchtet werden sollen, hell erscheinen. Dann musst du einmal einen neuen illumination_interior-Befehl mit nur leeren Slots (4x "-1") eintragen.

Das kann man - meiner Meinung nach - so pauschal nicht sagen.

Natürlich gibt es sicherlich auch Dinge, die im "alten" Blender teilweise besser oder einfacher gehen (gerade der DirectX-Export natürlich).

Aber im neuen Blender hat man eben auch extrem viele praktische Funktionen, die in den älteren Versionen so einfach noch nicht existierten, die ich ehrlich gesagt auch nicht mehr missen will. Insbesondere durch die neue Render-Engine und allgemein die Oberfläche und mehr Bake-Optionen ist es viel einfacher, beispielsweise auch Beleuchtung richtig schön direkt in Blender zu konfigurieren und somit direkt in Blender eine richtig saubere Lightmap zu erstellen (siehe Screenshots unten)

Abgesehen davon - die o.g. Plugins funktionieren bei mir (Blender 4.0 derzeit) wunderbar ohne jegliche Probleme, von daher sehe ich für mich derzeit garkeinen Grund, eine ältere Version mit Oberfläche, die wie Windows XP aussieht zu verwenden

Hm, irgendwoher muss OMSI diese Information ja haben.

Rein theoretisch könnte das noch über einen matl_change mit malt_allcolor laufen, das halte ich aber für äußerst unwarscheinlich...

Zitat von Lenn

Zitat von ma7t3

[...] im Prinzip kannst du da genau so vorgehen, wie bei Bussen mit Repaints.

Kurz gesagt - ja

Wenn du das Skript, was ma7t3 oben erklärt hat im {init}-Bereich einträgst, dann wird beim Laden des Busses eine zufällige der Texturen ausgewählt. Im {frame}-Bereich widerrum würde der Bus die Textur in jedem Frame des laufenden Spiels wechseln. Dabei kannst du z. B. einen Timer einbauen.

Grundsätzlich korrekt, allerdings sollte man natürlich beachten: Jeder Bus hat ja schon quasi ein "normales" Repaint, was man ganz regulär bei der Busauswahl mit auswählt.

Fügt man nun einfach neue Einträge hinzu, würde das dazu führen, dass alle Werbungen (z.B. in der Werbetafel im Bus oder wo auch immer) ebenfalls als reguläre Bus-Repaints angezeigt würden.

Ein Timer würde dann auch alle regulären Repaints zufällig mit umschalten, was vermutlich nicht gewollt ist.

Allerdings habe ich kürzlich herausgefunden, dass OMSI scheinbar kein Problem damit hat, wenn ein Objekt (bei Bussen gehe ich mal auch davon aus) mehrere Repaints gleichzeitig besitzt, indem man einfach mehrere [CTC]-Befehle verwendet.

Müsste man aber mal ausprobieren, wonach sich OMSI richtet, welches Repaint für die Auswahl im Bus-Menü verwendet wird, vielleicht einfach das erste?

Hier nochmal der Ausschnitt, bei mir handelt es sich hier um ein Wartehäuschen mit Werbung, jedoch besitzt es zwei Werbeflächen, die unabhängig voneinander "geschaltet" werden sollen. Daher gibt es zwei seperate Repaint-Einträge, welche jedoch in diesem Fall auf den gleichen Ordner und somit auf eine gemeinsame "Repaintsammlung" zugreifen. Könnte man aber natürlich auch anders machen. Aber so können beide Werbeflächen unabhängig voneinander verschiedene Werbungen zeigen.

(Objekt ist ursprünglich von IREgio612 - mit Erlaubnis von mir modifiziert)

[CTC]
WerbungIndex1
texture\Werbung_Flensburg_Unterstand
0

[CTCTexture]
Werbung
Flensburg_Unterstand_Werbevitrine_Werbung_1.png

[CTC]
WerbungIndex2
texture\Werbung_Flensburg_Unterstand
0

[CTCTexture]
Werbung
Flensburg_Unterstand_Werbevitrine_Werbung_2.png

[varnamelist]
1
script\Flensburg_Unterstand_Zufallswerbung.txt

[script]
1
script\Flensburg_Unterstand_Werbung_Zufallswerbung.osc

Hier im Script gibt es dann halt einfach zwei verschiedene Variablen für beide Repaints, die beide nacheinander mit verschiedenen Zufallswerten initialisiert werden.

{init}
    16 random (S.L.WerbungIndex1)
    16 random (S.L.WerbungIndex2)
{end}

Ich hoffe, das hilft weiter.

Zitat von EliLGP

wie baue ich so nen Timer ein?

Auch, wenn's schon etwas offtopic ist: Ein Timer im Script dient im Prinzip dazu, die ganze Zeit mitzuzählen, wie lange etwas dauert, um irgendetwas in einem bestimmten Interval (jedoch nicht in jedem Frame) auszuführen, wie bspw. den Wechsel einer Textur oder was auch immer. Dazu brauchst du eine "Zählvariable" hier "Timer" genannt, die du natürlich in einer Varlist zunächst definieren musst.

Dein Script sieht dann ungefähr so aus:

'Dieser ganze Abschnitt wird grundsätzlich in jedem einzelnen Frame, den OMSI rendert einmal ausgeführt
{frame}

'Hier wird der Timer immer erhöht und zwar genau um so viele Sekunden, wie der letzte Frame gedauert hat ("Timegap", normalerweise natürlich eine Dezimalzahl < 0)
'Das hat den Sinn, dass sich das Interval mit schwankender Framerate nicht verändert.
'Konkret gesagt, wird der aktuell Timer-Wert geladen, dann der aktuelle Timegap (letzte Framedauer) dazu addiert und der neue Wert wieder im Timer gespeichert.
(L.L.Timer) (L.S.Timegap) + (S.L.Timer)

'Jetzt prüfen wir, ob der Timer ein bestimmtes Limit überschritten hat (hier z.B. "3", damit wird der "innere" Abschnitt alle 3 Sekunden ausgeführt

(L.L.Timer) 3 >=
{if}
    'Hier kannst du jetzt das programmieren, was du machen willst, was in diesem Fall alle 3 Sekunden einmal ausgeführt werden soll

    'Danach noch den Timer durch eine Modulorechnung (Restrechtung) wieder zurücksetzten
    (L.L.Timer) 1 % (S.L.Timer)
    'Theoretisch könnte man ihn auch einfach direkt auf Null setzen, so ist es aber etwas cleaner, damit ein ggf. überschrittener "Rest" niübrig bleibt und nicht verschwindet, was den Timer etwas ungenau machen würde:
'Beispiel: 3.01 % 1 = 0.01
Da wir in diesem Durchgang statt 3 Sekunden schon bei 3.01 Sekunden waren, starten wir den Timer nicht wieder bei 0 sondern direkt bei 0.01.
{endif}
{end}

Damit ich es richtig verstehe:

Es geht darum, dass Teile des Innenraumes noch in der falschen Farbe angeleuchtet werden und du keinen passenden Eintrag dafür findest?

Je nach Bus kann es sein, dass es dafür tatsächlich keinen Eintrag gibt, weil der Ersteller des Busses die Beleuchtung in Blender konfiguriert und gebaked hat, sodass es eine Lightmap-Textur gibt.

Wie hier z.B. im HafenCity-Volvo:

///

In dem Fall wirst du natürlich keinen Eintrag finden, weil die Farbe der indirekten Beleuchtung einfach durch eine Textur bestimmt wird.

Dann müsstest du schauen, dass du die Textur anpasst, sofern dir die Blender-Datei nicht vorliegt (wovon ich mal ausgehe) indem du sie z.B. einfärbst.

So, wie ich das verstehe, geht es dir ja jetzt noch darum, dass die Lampen zwar blau leuchten aber der Innenraum trotzdem weiß erhellt wird.

Dazu sind jetzt die interiorlight-Befehle da, die du dort gerade schon gepostet hast, dort steht aktuell folgender Farbwert drinne: rgb(251, 247, 255).

Das ist quasi weiß.

Auch dort musst du jetzt also den rgb-Wert noch auf dein gewünschtes Blau ändern., dann sollte es funktionieren.

Moin,

die interiorlight-Einträge, die du dort gepostet hast, definieren nur die "indirekte Beleuchtung", also, wo sich Lichtquellen welcher Art befinden, damit andere "Gegenstände" und Fahrgäste richtig angeleuchtet werden, jedoch nicht den direkten Lichtschein selbst.

Das noch weiße, was du blau färben willst, sofern ich dein Problem richtig verstehe, dürfte ein Lichtpunkt sein. Siehe dazu auch hier im Wiki-Artikel.

Kurz zusammengefasst: Für dieses weiße Licht sollte irgendwo in deiner model.cfg ein [light_enh] oder [light_enh_2]-Eintrag existieren. Der 12. bis 14. Wert definieren dabei die RGB-Farbe deines Lichtpunktes, die müsstest du entsprechend einfach ändern.

Zusätzlich sollte noch erwähnt werden, dass das zu verbindende Stück immer so sein muss, dass es sich aus maximal einer geraden und einer Kurve zusammensetzen lässt.

Heißt also im Umkehrschluss: OMSI kann keine S-Kurve erstellen, es sei denn, beide Splines haben die exakt gleiche Rotation!

Das bedeutet, diese Situation funktioniert problemlos:

>>>

Dies klappt auch (beide Splines haben die exakt gleiche Rotation:

>>>

Dies funktioniert jedoch nicht, eine Spline hat die Rotation "0", die andere "-5" und es ist keine "nicht-S"-Verbindung möglich:

>>>

Zusätzlich gilt natürlich, wie bereits von Miner_Pro_1 richtig gesagt: OMSI kann immer noch von einem Spline-Ende ausgehend korrekt verbinden. Das bedeutet, folgende Verbindungen funktionieren:

• Splineende <-> Splineende
• Splineende <-> Splineanfang
• Splineende <-> Objekt

Nicht jedoch:

• Splineanfang <-> Splineanfang
• Objekt <-> Splineanfang
• Objekt <-> Objekt

Das Complete-To-Tool ist also in der Tat etwas fummelig, wenn man aber weiß, welche Tücken es hat und welche Fälle eben nicht funktionieren, kann man damit eigentlich ganz gut arbeiten.

Moin,

wie bekommst du deine Meshs denn aus Blender nach OMSI?

So wie es aussieht, scheinst du ja eine neuere Blender-Version (> 2.79) zu verwenden, womit ja der DirectX-Export nicht mehr funktioniert.

Verwendest du zufällig dieses Plugin dafür? Dann könnte das tatsächlich das Problem sein. Ich habe mit diesem Plugin auch immer wieder Probleme gehabt, o3d-Dateien mit korrektem Mapping zu exportieren.

Ich empfehle dir daher lieber diesesPlugin. Es hat nicht so viele Funktionen und kann nur exportieren, dafür tut es diesen Job wesentlich zufälliger und ohne solche Fehler.

Es wäre auf jeden Fall grundsätzlich mal lohnenswert, in der AI-List nur den Spandau-MAN einzutragen und zu prüfen, ob damit das Problem genau so besteht.

Zitat von Alex K.

Nur wollte ich kurz fragen, ob auf denen "Standard"- se (12+18 Meter) eingesetzt werden oder da so Midibusse bzw. Sprinter eingesetzt werden.

Das steht noch nicht so genau fest.

Zu einem sehr großen Teil wird der Fuhrpark aus 12m-Überlandfahrzeugen bestehen. Dazu einzelne Gelenkbusse - eigentlich nur für die Linien 200 und 280.

Für einige, kleinere Linien, wie die 279 oder die 294 - gerade in den Abendstunden - würden Sprinter bestimmt auch gut passen. Aber das ist, wie gesagt, noch nicht so genau geplant.

Zitat von Senator B

Zitat von ma7t3

Die Liniennetpzläne auch nochmal hier direkt.

Ich gebe nur zu Protokoll, dass es sich bei Zweiterem um einen „Liniennatzplan“ handelt und nehme nicht an dass das so gewollt ist.

Danke für den Hinweis.

Das Vorhandensein von Tippfehlern wird noch zum Markenzeichen dieses Projektes - Stichwort "Verkehsbetriebe".

Werde ich dann aber bei Gelegenheit mal ausbessern.

So, gleich nochmal eine kleine Info hinterher:

Ich habe mal den Startpost dieses Threads etwas aufgeräumt und aktualisiert, sodass ihr dort alle Infos, nach denen ihr sucht, sowie per Link schnell alle offiziellen Updates findet.

Auch seht ihr dort unseren bisher nur internen "Liniennetzplan" sowie eine Auflistung aller geplanten Linien. Vieles davon haben wir öffentlich glaube ich noch garnicht erwähnt, aber wir haben uns dazu entschieden das mal da mit reinzupacken. So ist das etwas transparenter und ihr könnt auch sehen, was wir bereits vor haben.

Die Liniennetpzläne auch nochmal hier direkt.

Ein kleiner Hinweis noch zum ersten Plan. Der Bereich, der dezent grün hinterlegt ist markiert den Abschnitt, welcher Bereits fertig gebaut ist, bzw. an den Rändern, wo aktuell so Baustelle ist.

Ansonsten wie gesagt alles weitere im Startpost.

Danke für dein positives Feedback, das freut uns sehr zu hören und motiviert ungemein, an der Karte fleißig weiterzuarbeiten.

Zum Thema Haltestellenschilder:

Ja ganz genau, da wollen wir eh nochmal ran, bzw. es sind bereits grundlegend neue Haltestellenschilder in Arbeit. Die bisher verbauten, die wir auch von der V1 kennen, fliegen mangels Qualität und Anpassbarkeit komplett raus. Das war tatsächlich von mir damals auch (kleine Background-Story) auch so einen 5-Min.-Blender-Aktion nach dem Motto "Ah scheiße, ich brauch ja noch ein Haltestellenschild für den Überlandbereich".

Nun haben wir uns dazu entschieden, alle Haltestellenschilder komplett zu ersetzen. Auch im Stadtbereich von Stein, wo bisher die Mabeg-Schilder standen, gibt es ab sofort eigene. Basis dafür dienen unsere (ebenfalls von mir selbst entwickelten) Haltestellenschilder für Region Südniedersachsen, allerdings natürlich auf Landkreis Stein und den Nah.SH-Bereich angepasst. Hier mal ein Bild aus dem Editor, was ich grade so auf die Schnelle auftreiben konnte.

(Das Bild war natürlich mal zum demonstrieren als Extrembeispiel, welche Kapazität das Schild hat, daher so "voll" )

Wie man sieht, sind diese Schilder wesentlich modularer mit Einschüben, Mülleimern, Fahrplänen usw. aufgebaut.

Für die Überlandabschnitte ist eigentlich genau das gleiche Schild geplant, nur mit dem unterschied, dass sich das Schild selbst (wie für Überlandbereiche typisch) oben auf dem Mast anstatt seitlich befinden wird. Das ist aktuell aber noch nicht entwickelt.

Die Modularbarkeit bleibt aber die gleiche, d.h. wir können das dann also auch so umsetzen, dass an kleineren Haltestellen teilweise wirklich nur das Schild mit Name (nicht mal Liniennummern drauf) steht, wie man es hier in der Realität oft sieht, können an größeren Haltestellen aber dennoch Liniennummern und sogar auch Fahrtziele mit "dranklatschen".

Dazu gibt's dann aber zeitnah auch nochmal ein "offizielles" Update.

Auf Krefrath (ebenfalls komplett Freeware) gibt es auch einige, ganz nette Überlandabschnitte, sowie Krummenaab 2019, wenn's etwas bayrisch werden soll.

Falls du eher was norddeutsches suchst, empfehle ich noch "meine" Map Landkreis Stein, da brauchst du auch keine DLCs für, allerdings auch bisher nur zwei Linien mit bis zu 25 Minuten Fahrtzeit ungefähr. Eine V2 ist aber in Arbeit.

Zitat von Schleswig-Holstein

Ach unsere gute alte B502, selbstverständlich völlig fiktiv 🤣

Na selbstverständlich, jegliche parallelen zur Realität sind rein zufällig entstanden!

Und die Linie 200 hat natürlich auch überhaupt kein Vorbild aus der Realität.

Ne also Spaß beiseite, damit ich auch noch mal wieder meinen Senf hier dazu geben kann:

Wir haben uns dazu entschieden, in der V2 die Map noch etwas konkreter an das reale Vorbild - den Kreis Plön - zu binden etc. Es ist und bleibt natürlich eine fiktive Map, aber wir wollen uns in gewissen Aspekten noch etwas mehr an der Realität orientieren.

Wenn die Objekte alle nacheinander erstellt worden sind, kannst du versuchen, die [object]-Einträge in der map-Datei zu löschen.

Zitat von Strange4high

Ich persönlich finde das Derzeitige Drucker Modell recht schön. Klar müsste man da noch paar details rein blendern, aber an sich ist es sehr schön

Das aktuelle Druckermodell war von mir eigentlich nur eine Art "Dummy", weil ich mich erstmal auf die Software konzentrieren wollte. Es hat daher überhaupt keine Konturen etc.

Ian.Häusler.26.02 das klingt doch gut. Darf ja gerne vom Prinzip her auch fiktiv sein - wie die Software ja auch.

Zitat von Ian.Häusler.26.02

Bezüglich eines Druckermodells, hast du da irgendwelche Vorstellungen?

Ich überlege nämlich auch mal einen Drucker zu modellieren.

Eigentlich nicht.

Du kannst mir ja gerne mal einen Vorschlag schicken/zeigen.