Guten Abend!
wie einige vielleicht mitbekommen haben, spiele ich seit Jahren mit der Umsetzung einer "OMSI-Alternative" herum und habe mich seit nunmehr fast einem Jahr auf ebendiese Umsetzung fokussiert.
Ein wichtiger Punkt für mich ist, eine ähnliche Moddingfreundlichkeit zu erreichen, wie es sie auch in OMSI gab, ohne zwingend auf den Unreal Editor zurückgreifen zu müssen. Das wird nicht in allen Bereichen in identischer Form umsetzbar sein (der Kartenbau wird beispielsweise Editor-Only stattfinden), aber in denen, wo es technisch möglich ist, möchte ich das optimalerweise so wie in OMSI beibehalten. Warum sollte man das Rad in Bereichen neu erfinden, die grundsätzlich schon nicht schlecht sind?
Dementsprechend wird mein Simulator in vielen Bereichen "Daten-kompatibel" sein - Es müssen zum aktuellen Zeitpunkt beispielsweise keine Fonts erstellt werden, wenn es diese schon in OMSI gab. Das entlastest mich als Entwickler, da ich meine bereits umgesetzten Inhalte weiter verwenden kann und auch jeden potentiellen Modder. Eine solche Funktionalität ist für alle Inhalte (außer die Karten und Scripts) geplant, welche auch in OMSI auf einen Datenstruktur in lesbarer Textform setzen.
Genauso möchte ich das Beispielsweise mit der Sound-cfg von Fahrzeugen handhaben und bin da auf eine Ungereimtheit gestoßen, zu welcher ich keine Antwort finden konnte.
im speziellen geht es mir um diese Einträge in der Sound-cfg eines Fahrzeuges, welche 1:1 Standard M&R Content sind. Eine Volcurve wird i.d.R. mit einer Variable verknüpft, hier aber mit "-1". Weiß eventuell einer, ob es sich hier um eine Art "Fallback" Volcurve handelt oder wurde die entsprechende Volcurve durch M&R damit "auskommentiert"?
Sollte letzteres der Fall sein, hätte sich diese "unnötige" Implementierung seit über 10 Jahren immer wieder fortgepflanzt, denn solche Referenzen findet man i.d.R. in fast jeden Fahrzeug, auch heute noch - und das kann ich mir fast nicht vorstellen, vor allem unter der Prämisse, dass Auskommentierungen i.d.R. vor dem [tag] stattfinden und nicht innerhalb des angefangenen Datenblocks.
Im SDK habe ich dazu leider nichts gefunden, auch in etwaigen Referenzen innerhalb der Soundconfigs konnte ich keine Infos zu dieser Funktion finden. Vielleicht gibts hier nen Soundspezialisten, der helfen kann?
Im Zweifel fange ich solche Konstellationen ab und hinterlege sie im Logfile - dann ist ggf. ein Nacharbeiten der Sound-cfg nötig, um sie voll kompatibel zu machen, sollte sich dahinter doch eine Funktionalität verstecken. Besser fände ich es allerdings, wenn ich auch diese "Spezialform" implementieren kann, sofern denn jemand weiß, wofür das genau da ist. 
LG
Christian
Soundkonfiguration - unplausible Bestandteile?
- Chrizzly92
- Unerledigt
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! -
-
Also, sollte der Eintrag hier: https://fellowsfilm.com/thread…he-bus-sound-config.2423/ im Spoiler "Example #2, loop sound" richtig sein, wird mit "-1" der sound nur einge-"fadet".
-
Interessant, ich habe das gerade einfach mal mit Bamp mit einem einfachen Test-Soundwürfel ausprobiert. Hier die zugehörige Sound-cfg:
(NightLightA nur als Testvariable, weil ich kein Bock hatte, eine Varlist anzulegen und diese Variable vordefiniert ist)
Strassenmusiker1.wav habe ich auf die schnelle durch einen Sinuston ersetzt, damit man optimal das Verhalten beobachten kann.
Code
Alles anzeigen[loopsound] Strassenmusiker1.wav 44100 NightLightA 1 0.90 [3d] 0 0 0 2 [volcurve] -1 [pnt] 0 0 [pnt] 1 1Die Erwartung wäre jetzt gewesen, dass der Sound beim Spawnen (?) über eine Sekunde einfadet. (siehe Beitrag von Theproloser) Das war hier jedoch nicht der Fall. Ich habe auch testweise die ganze Volcurve auskommentiert. Dabei war kein Unterschied zu hören.
Allerdings erzeugt das auch keinen Fehler im Logfile. Omsi scheint es also schon irgendwie zu "verstehen".
Eine normale, vordefinierte Variable scheint "-1" jedoch auch nicht zu sein: Versucht man nämlich, im Rahmen eines Scriptes diese mit (L.L.-1) aufzurufen und zuverwenden, kriegt man im Logfile den üblichen "unbekannter Variablenname"-Fehler.
Vielleicht ist es also doch einfach nur eine Art "Ersatzauskommentierung". Jedenfalls scheint OMSI bzgl. dessen, was man tatsächlich hören kann, die Volcurve einfach zu ignorieren ohne dabei einen Fehler zu schmeißen.
Mir fiel noch ein, dass es ja bei einigen Fehlern auch (ganz bewusst dokumentiert) die Möglichkeit gibt, einen Variablennamen wegzulassen bzw. einen ungültigen zu hinterlegen. Bei [matl_light gibt man ja auch z.B. eine Variable an, um die Lichttextur ein- und auszuschalten. Allerdings kann man sie auch weglassen oder etwas ungültiges dort eintragen um sie dauerhaft zu aktivieren.
Das scheint hier bei der volcurve nicht so zu sein. "Einmal auf die Tastatur hauen" führt in diesem Fall zu Zugriffsverletzungen. Andere Integer-Werte gehen aber. "-2" interessanterweise führt dazu, dass der Sound garnicht hörbar ist, wirft aber auch keinen Fehler.
Also alles sehr merkwürdig.
Ich konnte das Geheimnis jetzt leider nicht lüften, aber vielleicht ein paar interessante "Versuchsergebnisse" präsentieren.
-
Hello folks! I believe the "-1" volcurve is indeed a fade-in function for the sound. I have just successfully scripted it, as I was curious myself to see if this "-1" actually does something or not, and it looks like it behaved exactly as I wanted it to. I attach a preliminary (WIP) script below.
Code
Alles anzeigen[sound] Doors\RDS_door_2_opn.wav 1.5 [3d] 1.15 -1.21 2 1 [volcurve] door_pressure_factor_23 [pnt] 0 0 [pnt] 1 1 [trigger] ev_doortriggeropen_2 -------------------------------- [sound] Doors\RDS_door_2_hiss.wav 1.5 [3d] 1.15 -1.21 2 1 [volcurve] door_pressure_factor_23 [pnt] 0 0 [pnt] 1 1 [volcurve] -1 [pnt] 0 0 [pnt] 0.2 0 [pnt] 0.4 1 [pnt] 1 1 [volcurve] door_2 [pnt] 0 1 [pnt] 0.1 1 [pnt] 0.75 1 [pnt] 0.9 0 [pnt] 1 0 [conditionSingle] doorTarget_23 1 1So the door sound-script that I am working on is made up of 2 distinct sounds. First you have the "puff" that is heard when the door starts opening, and then you have the continuous "hiss" sound that is heard based on the door position, which is the pressure valve adjusting the air pressure based on door position. The "puff" has ~0.5s so I want the hiss to gradually take over the puff for a smooth sound transition. This "-1" solved my issue, based on my initial observations. Hope this helps!
-
This is a curve that determines the loudness of a sound from the time it starts playing.
Example:Code
Alles anzeigen[loopsound] test.wav 44100 cp_retarder_sw_direkt 1 1 [3d] -0.8 5.289 1.519 10 [conditionSingle] cp_retarder_sw_direkt 1 1 [volcurve] -1 [pnt] 0 0 [pnt] 1 1 [pnt] 2 0 [pnt] 3 0.5 [pnt] 4 0 [pnt] 6 1The homework will be to test the above mentioned code on a MAN SD20x vehicle.