Beiträge von Chrizzly92

beim MAN in Bremen wurden die Hauptscheinwerfer auch nicht mit dem Rest verbunden - zumindest nicht abblend und fernlicht. das ist bei bhd scheinbar anders.

Zitat von Perotinus

Gibt es eigentlich die Möglichkeit, die dds mit weniger Artefakten zu erzeugen? Ich bin momentan etwas unglücklich mit meiner 4K-tga im Innenraum, als dds ist das ganze aber so schaurig anzusehen, dass ich momentan keine Alternative sehe.

DDS verstehen alle Grafikkarten nativ, die auch DirectX unterstützen, das ist der große Vorteil. Keine Dekomprimierung, hohe Kompatibilität, schnelle Verarbeitung, Mipmapsupport und mehr. Das spart Rechenleistung und OMSI kämpft weniger mit Texturfehlern/Mipmapfehlern (typische, schwarze Busse bei Entfernung) oder nicht geladenen Alphakanälen (Scheiben nicht durchsichtig o.ä.) Die Nachteile sind aber auch offensichtlich - die Artefakte sind hier wohl das größte Problem. Ich habe bisher immer den Spagat gewählt und eine Mischform genutzt - so sind die VDV Displayanzeigen stets TGA, damit diese schön scharf sind und pixelgenau gearbeitet werden kann - an anderen Stellen nutze ich DDS, erstelle diese aber erst in einer hohen Auflösung und verkleinere Sie dann im Nachhinein. Das macht die Texturkanten etwas weicher, man hat aber weniger mit den Artefakten zu kämpfen. Es gibt zwar modernere und bessere Kompressionsverfahren, mir ist aber - zumindest mit den Tools die ich nutze - noch kein Weg bekannt, diese für OMSI nutzbar zu machen.

Ich hab BHD nicht, Grundsätzlich fällt mir aber schonmal einwas auf:
jedes Mesh kann nur mit einem [visible] befehl angesteuert werden. Die model.cfg wird von oben nach unten abgefrühstückt, der visible befehl engine_on sollte dementsprechend keine Funktion haben.

du musst also eine neue variable bauen und ins script hängen, die irgendwie so aussehen muss:

(L.L.engine_on)

(L.L.lights_stand) ! &&

{if}
1 (S.L.tagfahrlicht_visible)

{else}

0 (S.L.tagfahrlicht_visible)

{endif}

das nutzt du dann, um zwischen den zwei meshes in der model.cfg hin und herzuschalten.
die anderen einträge in der model.cfg müssen im übrigen bestehen bleiben, sonst funktioniert das nicht. in dem modell wurden verschiedene Lampen zu einem Mesh zusammengefast, die mit den verschiedenen [matl] befehlen addressiert werden. blinker und co. würden also nicht mehr funktionieren, wenn du das gleiche mesh ohne diese einträge einfach drüber legst. alternativ das modell convertieren und alles rausnehmen außer die scheinwerfer, dann würde deine herangehensweise funktionieren.

Die Performance ist halt echt unterirdisch, vorallem auf den größeren Multiplayerkarten. Im Mulitplayer hatte ich bisher aber tatsächlich am meisten Spaß - aber nicht, weil man sinnvoll Fährt sondern weil man auf Diorama super Unfug treiben kann.

selbstverständlich. aktueller Changelog meinerseits sieht folgendermaßen aus:

- VDV Dash zeigt nun korrekt Rückwärtsgang an

- VDV Startroutine überarbeitet

- ASR Meldung im Dash funktioniert nun korrekt bei Solo und Gelenk und löst nichtmehr aus

- Diverse Texturverkleinerungen

- neuer Innensound (Danke Perotinus! <3)

- Lücke zwischen Sitz und Podest ganz hinten im Bus im Solowagen entfernt

- Innenspiegel zeigen nun korrekt gedrehtes Spiegelbild an; Mesh überarbeitet

- Türtasterbeleuchtung im Fahrzeug nun korrekt

- Türsteuerungslogik überarbeitet - Türsounds werden nun auch bei der Nutzung von "Zentrales öffnen" Korrekt abgespielt

- Wagennummern nun über "vis_wagennummer" ausblendbar, wenn diese Setvar per Repaint auf "1" gesetzt wird

- Material von Lenksäule überarbeitet

- fehlender Fahrzeugschlüssel hinzugefügt

- Warnblinkerlicht im Schalter geht nun korrekt aus, wenn dieser deaktivier wird

- Rollos haben nun Sound

- Neue Exteriorsounds

- Copilot: Nachtmodus hinzugefügt

- Copilot: Manuelle Weiterschaltung hinzugefügt

- Copilot: Stummschalten der Ansagen hinzugefügt

- Türtasterbeleuchtung außen hinzugefügt (Gelenkwagen)

- Türbeleuchtung innen gefixed (Gelenkwagen)

- Haltewunschtaster im Gelenkwagen hinten besitzen nun Klickspots

- Fahrzeuge haben nun dedizierte KI-Sound configs

- Nothähne hinzugefügt

- Scheibenflimmern der hinteren Anhängertüren behoben

da kommt dann noch ein bisschen was zum init dazu (wie die nachttexturen) und generelle fixes wie die in den Türen stehenden leute.

Nachtmodus? Check!

*Klugscheißmodus an*

Das geht aber nur mit dem Numpad!

*Klugscheißmodus aus*

Ist bereits behoben, ich liefere die Tage eine Version an Olgu aus - wann diese allerdings hochgeladen wird, kann ich noch nicht sagen.

Meine Argumentation soll jetzt nicht in einer Diskussion enden, welche Objekte besser oder schlechter sind. Ich wollte damit nur klarstellen, dass die Objekte, die ich in DUS Verwende, auch aus meiner eigenen Hand stammen.

Ich bin nicht Hauptverantwortlicher vom Projekt, liefere nur den Bus für München. Meine Entwicklerversion hat zum Beispiel keine Repaints und diese wäre selbstständig lauffähig, dementsprechend kann ich diese nicht bereitstellen. Ich werde aber dafür Sorge tragen, dass beim nächsten Content Patch vom Bus dieser auch wie vorgesehen veröffentlicht wird.

ist mir eigentlich wurst wie ihr das macht. Ich bekomme halt nur per PN an mich herangetragen, dass einige Dinge nicht funktionieren und ich mich halt Frage: warum? kann ich nicht nachvollziehen. Dann schaue ich mir die Steamversion an und stelle fest, das tatsächlich Fehler existieren, die so in meiner Version nicht enthalten sind. und das ist halt blöd, vorallem dann, wenn sowas nicht kommuniziert wird.
Das verursacht unnötigen Support, wenn Leute an mich herantreten und Fehler behoben haben wollen, die "dritte" Verursacht haben.
Bestes Beispiel dafür ist das weiße Repaint. Funktioniert in meiner Entwicklerversion einwandfrei, bei der Steamversion war das Wochenlang defekt.
Ich würde einfach bitten, mir mit ner PN mitzuteilen:
"Hey Christian, hier sind die Außenspiegel von uns, die werden wir im nächsten Patch mitliefern" - dann weiß ich bescheid, kann die in meiner Entwicklerversion - ggf. sogar mit Funktionalität - einpflegen und weiß über die Existenz. Alles andere ist einfach mist, solange ich für mein Fahrzeug support geben soll/kann/will.
Wenn zu viele Hände an einem Projekt rumspielen und die linke nicht weiß was die rechte macht, führt das zu vermeidbaren Komplikationen.

Zitat von onur58

Einige Fans hatten sich die zwei langen Außenspiegel gewünscht, die bei einigen Subunternehmern in München zum Einsatz kommen.

Als Basis zum Skripten haben wir den langen Spiegel vom Düsseldorfer Solaris genommen, um es intern zu testen und soweit möglich zu lernen.

Bedenke, dass auch viele München-eigene Dateien/Modelle z.Z. im Düsseldorfer Bus eingebaut sind (Automat, IBIS etc.), wie zwischen uns abgesprochen.

Auch die Innen-Bildschirmtextur der MANs findet sich im Texturordner des Solaris-Busses wieder. Work in Progress...

Legitimierst du die Verwendung meiner DUS-Spiegel damit, dass ich Content aus München für DUS Verwendet habe?

Du solltest dabei nicht vergessen, dass ein Großteil der Objekte, die von Olgu vorbereitet wurden, gar keine Verwendung fanden und zu 100% aus meiner Hand stammen. Das sieht man beispielsweise am Automaten sehr gut:

links Olgu, rechts Chrizzly92.

oder aber auch am Copiloten, unten Chrizzly92, oben Olgu:

Wenn ein Objekt aus meiner eigenen Hand stammt, kann ich damit auch anstellen was ich möchte. Die spiegel stammen aber nicht aus eurer Hand, das ist nen kleiner aber feiner Unterschied. Das ist bei allen Objekten, die in DUS Verwendet wurden, der Fall. Viele Texturen, so zum Beispiel die Bootsequenzen des Automaten oder der Innenanzeige, aber auch die Displaytexturen des Copiloten habe ich eigenhändig gezeichnet. Natürlich auf Basis der Vorlagen - aber in den Bordcomputern steckt zu 100% Chrizzly92.

Aber ist auch egal, mir gehts da gar nicht um den Content selbst und woher die Spiegel stammen sondern darum, dass diese enthalten sind und ich davon nichts weiß. Wenn ihr das Fahrzeug eigenhändig mit Funktionen füttern wollt, hab ich da auch absolut nichts gegen, auch wenn dieser aus dem DUS-Urbino stammt. Stell dir aber mal vor, mir schreibt jemand sowas wie:

"Hey Chrizzly, ich hab mir den langen Spiegel eingebaut und jetzt geht der Bus nicht mehr." Da stehste halt selbst erstmal auf dem Schlauch und weißt gar nicht, von was der Spieler spricht.

Schickt mir doch einfach mal die Steamversion vor Veröffentlichung und ich schau drüber, bevor das offizielle Okay gegeben wird. Eine Vorabinformation drüber, was ihr am Fahrzeug macht, wäre auch nicht schlecht. Dann würden hier Projektpartner nicht einfach im Regen stehen gelassen und es gäbe nicht bei jedem Steam-Update Probleme.

Zitat von der_Nik_

Jetzt, wo einige Spieler den Spiegel nutzen, hätte das fatale Folgen, da nach einem Entfernen bei vielen der Bus nur noch halb laden würde...

Ich würde aber spontan vorschlagen, dass ihr sowas nicht öffentlich klärt

Und jetzt stell dir mal vor, man hätte irgendwann einfach meine Dev-Version, wenn neuer Sound und Nachtmodus für den Copiloten kommt, eingespielt. Hätte wieder zu Problemen bei einigen geführt und genau darum finde ich das nicht gut.

Warum soll man sowas Intern klären? Grundsätzlich habe ich die Community schon beim MAN Stadtbus stark in die Entwicklung involviert. Hinzu kommt, dass Ich für Probleme verantwortlich gemacht werde, die gar nicht von mir Verursacht wurden und im Interesse der eigenen Reputation finde ich es schon wichtig auch öffentlich sagen zu können, dass ich an vielen Problem nicht schuld bin. Die Leute kommen nämlich oftmals direkt zum Fahrzeugentwickler und laden dort ihren Frust ab, obwohl ich gar nicht dafür kann. Ich will aber nicht der Mülleimer für die Fehler von anderen sein.

interessant. wie kommen die Spiegel da rein? ich hab sie nicht implementiert.

Tatsächlich funktioniert ein separat eingetragenes Script im Trailer nicht in Kombination mit Scriptshare. Interessant.
Jetzt gibts zwei Möglichkeiten: Den Vorderwagen und den Nachläufer via Steuerleitungen verbinden (sofern das geht) oder

die Koordinate der GetHeightAbovePoint Abfragen über den Nick- und Gierwinkel des Gelenkes berechnen.

Edit: alternativ gäbe es noch eine dritte möglichkeit:

Zitat

This command shares the script system. That means that THIS vehicle

will use the entire script system of the previous created vehicle

(it is not important, if this is coupled in front or in the back,

this only depends on which vehicle was create before THIS one)

eventuell könnte man Probieren, den Nachläufer eines Busses als "erstes" Fahrzeug zu definieren und den rest vorn dran zu hängen. das wäre aber recht viel Aufwand.

Edit: geht nicht.

Nun, einen Vorteil haben diese eigentlich nicht, da stimme ich dir zu. Ist aber einfach sauberer Meiner Meinung nach. Dazu kommt, dass - wenn er die Oberleitungs"mitte" mal verliert, dann trotzdem in der Nähe bleibt und die Werte auch nicht durch die Decke schnellen. Kann man natürlich auch mit nem script abfangen. Es führen ja viele Wege nach Rom und dein Ansatz funktioniert natürlich genauso.

Wenn du das script im Trailer aufrufst, musst du natürlich die {init} und {frame} schleifen nutzen. wenn du da nen script einträgst, welches andere macronamen hat, musst du diese in den haupt init und frame abschnitt eintragen. Fast jeder Bus in OMSI hat ja ein "main" script, in welchem alle unterscripts und deren macro definiert werden.
also entweder ein basisscript bauen, dass so aussieht:

{init}
    (M.L.trolley_Init)
{end}

{frame}
    (M.L.trolley_Frame)
{end}

welche dann die macros in deinem "sub-script" aufrufen - oder einfach in dein trolley script entsprechend {init} und {frame} verwenden. würde ich zumindest tippen, da ich das script nicht kenne.

Zitat von DerGrafikfehler

Für das Problem wäre glaub ich tempo1 der beste Ansprechpartner, der hat mWn die NF6D gebaut/war an der beteiligt, und bei der sind ebenfalls verschiedene Scripte in verschiedenen Fahrzeugteilen eingetragen.

Dann wohl eher Feindflug oder ich. Unabhängig davon funktioniert die NF6D nicht mit Scriptshare sondern mit Steuerleitungen.

Zitat von GAMINGONK

Vermute mal, dass Omsi herumzickt, da zwar Scriptshare genutzt werden soll, jedoch der Nachläufer nicht die selbe Anzahl an zu ladenden Scripts hat, als der Vorderwagen.

Die [script] und [constfile]-Einträge müssen die selbe Anzahl im Nachläufer haben, wie der Vorderwagen.

wäre ja kein Problem. man kann die variablen für den nachläufer ja in eine x-beliebige constfile oder varlist eintragen.

ahh, ich verstehe. Das ist wirklich eine berechtigte Frage und diese kann ich ohne eigene Tests auch nur spekulativ beantworten.
Die GetHeightAbovePoint Variable erwartet die koordinaten an einem absoluten Punkt, abhängig vom Nullpunkt Des Fahrzeuges aus. Das Impliziert, dass das in einem Nachläufer rein technisch gar nicht gehen würde - denn dieser bewegt sich ja. Ich würde also die Logik für einen O-Bus in ein eigenes script werfen, dass du nur im Nachläufer implementierst. Das sollte trotz scriptshare gehen. eventuell könnte man sogar Steuerleitungen eines Zuges zwischen die Wagen hängen - dann wäre auch eine Kommunikation ohne Scriptshare möglich - ob das geht weiß ich aber nicht.

Halt mich gern auf dem laufenden, was deine Tests angeht!

Ich lass dir hier auch nochmal meine Idee da, wie so etwas umsetzbar wäre.

Ich würde eine Spline bauen, die über dem Fahrdraht eine "einbuchtung" hat, die von GetHeightAbovePoint erkannt wird. links und rechts in unterschiedlichen höhen, damit du per Script die beiden abnehmer unterscheiden kannst. das würde auch unterschiedliche breiten des Fahrdrahtes ermöglichen. Einfacher wäre natürlich eine Einbuchtung zwischen den Fahrdrähten und damit würde ich auch erstmal an deiner stelle beginnen.

Hast du so eine Spline fertig, setzt du am besten die Abfrage der GetHeightabovePoint in Sollhöhe des Stromabnehmers. davon brauchst du allerdings eine ganze menge, damit der Stromabnehmer der Leitung auch entsprechend realistisch folgt. Diese vergleichst du miteinander und kannst so den Punkt finden, der aktuell von den anderen Abweicht - also den, wo der Panthograf hin soll.

Für eine Weichensteuerung könntest du beispielsweise auf Höhe der Fahrerposition links und rechts unter dem boden wieder mehrere GetHeightAbovePoint Abfragen positionieren. Dann setzt du, wenn du dich zum Beispiel auf einer Linksabbiegerspur befindest, einen Dummycube unter die karte, die dann von GetHeightAbovePoint erkannt wird. hast du links eins, merkst du dir vor dass, sobald deine GetHeightAbovePoint abfragen zeigen dass sich die Fahrbahn trennt, der Panthograf eher linksseitig geführt werden soll. Wie du das bei einem Gelenkbus allerdings durch das Fahrzeug schleifst, weiß ich noch nicht.

Bedenken musst du allerdings, dass es sich nur um Annäherungswerte handelt - ändert sich zum Beispiel die Höhe des Fahrdrahtes, würde sich ja auch die Position der GetHeightAbovePoint Abfragen ändern. Theoretisch könnte man diese Punkte aber auch mimt einer "Höhenerkennung" kombinieren und dann entsprechend die Punkte zum Auslesen verschieben.
Das Script dafür wird dann aber auch entsprechend komplex und ich weiß nicht, ob das einen großen EInfluss auf die Performance hätte. War meinerseits bisher ja auch nur trockene Theorie.

welche koordianten willst du denn auslesen, bzw. was hast du denn vor?

Zitat von Bananafood21

Wäre es möglich, die Wagennummern der Fahrzeuge per Setvar ein-, bzw. auszublenden? Also dies mit einzubauen, wenn der Bus schon einmal gepatched wird..

iirc sollten die wagennummern ein eigenes mesh sein. Eine setvar dafür hinzuzufügen ist kein Problem und wird für den nächsten Patch vorgemerkt.

Naja, fast perfekt ist der nun nicht. Gerade im Bereich Sounddesign ist da noch viel Luft nach oben. Gut Ding will weile haben und mein Tag hat auch nur 24h. Entweder man wartet bis ich die Sounds erledigt habe oder sucht sich jemanden, der das für einen macht - alles andere ist nix halbes und nix ganzes.

das reine löschen vom Material reicht nicht aus - solang die Texturen je nach Modi mal aufs Mesh geladen wurden, bleiben diese auch referenziert.
Um Texturen aus Blender dauerhaft zu entfernen, mit Shift+Klick im UV Editor auf das "X" drücken.

die Textur wird dann im Auswahlmenü mit einer "0" vor dem Namen gekennzeichnet:

Dannach speichern und das Projekt neu öffnen. fertig.

Zitat von PingPong

Zitat von Chaoslokführer

Das weiße Repaint existiert sogesehen wirklich, nur liegt es in einem extra Order (weiss) und nicht im Werbe Hauptordner.

Jo, die CTI ist nicht angepasst. Aber ich sags nochmals: Sowas darf bei einem Payware-DLC nicht passieren!

ich frage mich sowieso, warum man nicht einfach meine Entwicklerversion des Busses hochlädt sondern immer daran herummanipuliert. die CTI's der Repaints funktionieren einwandfrei. Vermutlich kopiert Olgu einfach den Repaintordner in meine Entwicklerversion und dabei geht die hälfte kaputt.

bei den Sounds kann ich leider nicht helfen. diese wurden zum wiederholtenmale von Olgu_M nach der Abgabe meiner Arbeit verändert, für Bugs diesbezüglich ist er verantwortlich.