Bremsquietsch-Formel im Script

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!

    Moin!

    Ich hab mir gedacht es wäre schön die Bremsquietsch-Formel im Bremsscript abzuwandeln. Mir scheint es dass die das rein nach Wagennummern macht damit jedes Fahrzeug eine eigene Charakteristik hat. Das finde ich im Prinzip auch gut, ich würde gerne aber zwei Dinge dran ändern:


    - ein gewisses Mindestquietschniveau einstellen, dass immer zumindest ganz Minimal was zu hören ist, das Ergebnis also nie 0 Lautstärke ist sondern zum Beispiel 0.05 als unterste Grenze.

    - Alter des Fahrzeuges soll die Lautstärke beeinflussen damit alte Fahrzeuge grundsätzlich mehr quietschen als neue.


    Nur leider verstehe ich die angewandte Formel so gar nicht. Wagennummer mal Sinus und weiss der Geier... Hätte da jemand eine Idee die Formel anzupassen?

    Hello,


    I assume that this is the formula/block you speak of:


    Code
        (L.L.bremse_quietsch_volume) -1.5 <
    {if}
        (L.$.number) $StrToFloat 1000 * sin (S.L.bremse_quietsch_volume)
    {endif}


    As far as I can tell, its logic goes as follows:

    1. Check whether bremse_quietsch_volume is currently less than -1.5. During {init}, the variable gets initialized to -2, so this test guarantees that the assignment following will only be undertaken once -- given that, as we will see below, the value generated and assigned is always at least -1 (or greater). Why not just compare the variable to -2 then? Because floating point arithmetic is generally imprecise and OMSI is no exception, which in particular tends to become evident when reloading saved situations (if you peak inside *.osn files, the values stored are typically not exact integers even when so intended by the script assignments responsible). Why not just handle this in the {init} block? Because a) not all system and predefined variables (e.g., the vehicle's number) are available at that time, plus potentially because, if I recall correctly, b) {init} doesn't get re-executed upon stored situation reload, which sometimes leads to problems in code taking it for granted (in this particular case it probably wouldn't make a difference though). Anyhow, if bremse_quietsch_volume is less than -1.5, then:
    2. Take the vehicle number string, number, and convert it to numeric form. Doing so yields -1, when the vehicle happens to have no valid number (e.g. empty string ("") or string otherwise non-convertible to float), or otherwise the equivalent floating point representation of the string, essentially a random quantity as far as the script is concerned.
    3. Multiply that value by 1000. This means that the default of -1 becomes -1000, which is of significance when it comes to the next step.
    4. Now treat the previous value as an angle and compute its sine, resulting in a value between -1 (when angle = -90° or 270°, ± any multiple of 360°) and 1 (when angle = -270° or 90°, likewise). So, in the default case, sin(-1000) = sin(-280) = sin(80) ≈ 0.98.
    5. Lastly, map bremse_quietsch_volume according to the apposite volcurve defined in the sound.cfg:


    Now let's try to revise this to take vehicle age into account, as well as to always "spit out" a value no less than 0.05.

    (Also, maybe you'd like to additionally consult the game's maintenance setting, wearlifespan; note that in the case of AI vehicles, they always get assigned a wearlifespan to be interpreted as "infinite" / "perfect" by default.)



    Const-file additions (feel free to customize):



    Note that I haven't got OMSI installed at the moment and thus can't provide any assurance that the above is bug-free.

    A couple more thoughts on the original formula: There are more angles with a sine closer to ±1 than there are angles with a sine closer to 0; ±0.5 is already being reached at ±30 degrees, therefore ~66% of all angles, and by extension vehicle number inputs, produce an output that's at risk of being interpreted as either abnormally silent or abnormally loud.

    With real-world objects, by contrast, we generally expect kind of a bell-shaped distribution, with more observations gravitating toward the middle of the interval of previous observations than toward the edges.


    In this particular instance, a simple change in pursuit of such an effect might be the use of (for lack of a better

    term) "sine's complement": 1 - sine, when sine ≥ 0; -1 - sine, otherwise.


    Code-wise1:

    This in a sense "flips" the distribution of outputs. The output pattern will still be repeating with every 10th value (because (9 * 1000) mod 360 = 0), but now ~66% of outputs should fall under the normal range and only ~34% outside of it. The same effect could of course have been accomplished by adjusting the volcurve so as to produce outlier outputs for normal inputs and normal outputs for outlier inputs (but since bremse_quietsch_volume now also accounts for vehicle age and maintenance state, doing so wouldn't have the desired effect overall).