Beiträge von Florito

Das Forum befindet sich im reduzierten Betrieb. Die Addon- und Supportforen bleiben weiterhin verfügbar.
Bitte beachte, dass OMSI nicht mehr weiterentwickelt wird. Ein Teil der Entwickler widmet sich inzwischen der Entwicklung eines neuen Simulators. Weitere Informationen zum LOTUS-Simulator findest Du hier.

    It is possible to do RPM * (130/2700) or RPM / (2700/130), but multiplication is better for performance than division, so I changed it but I made a mistake because I forgot to inverse 130 and 2700. I edited it, it should be :

    Code
    1. (L.L.engine_n) 130 2700 / * (S.L.cockpit_drehzahlwinkel)

    Where :

    2700 = max RPM

    130 = max needle angle

    Hello,


    The cockpit_tacholinie curve is responsible of the speedometer, it takes the velocity as input, see in cockpit.osc :

    Code
    1. {macro:tacho_frame}
    2. (L.L.Velocity) (F.L.cockpit_tacholinie) (S.L.cockpit_tachowinkel)
    3. {end}

    Rev counter is this macro :

    Code
    1. {macro:drehzahlmesser_frame}
    2. (L.L.engine_n) 3000 270 / / (S.L.cockpit_drehzahlwinkel)
    3. {end}

    So the needle should be cockpit_drezahlwinkel. It takes the actual RPM (engine_n) as input, and the division is for the angle of the needle, you can always modify this behavior. There is no rev counter on the original MAN NL but this macro is present.


    For example, I would do something like that. Let's say when the RPM is at 2700, your needle needs to be at 150° and when the RPM is at 0, your needle needs to be at 20°. I would rotate the model of the needle to 20° by default, so the max angle of the needle would be 130° for 2700 RPM.


    If you want to keep it a bit like the original, you could do something like :

    Code
    1. (L.L.engine_n) 130 2700 / * (S.L.cockpit_drehzahlwinkel)

    Or you could optimize it a bit :

    Code
    1. (L.L.engine_n) 0.048 * (S.L.cockpit_drehzahlwinkel)

    Or even in the animation :

    Code
    1. [newanim]
    2. ...
    3. engine_n
    4. 0.048
    5. ...

    Hello,


    The [volcurve] is responsible of this. So, for the Sound1, you have :

    It means the sound is at 0% at 0kmh and 100% at 30kmh. It is basically the points of this "curve" :

    We can change the first point so the sound will starts later :



    Or even add a point so the sound starts later and more brutally :


    You can do whatever you want with these curves, you can add as many points as you want. Feel free to adjust it according to your needs.

    Hello,


    Something like that should work, feel free to modify the 3d section :

    Thank you very much for pointing this bug ! In fact, I don't know why, but the v0.2 on Mediafire is not the v0.2 but it points to the same .zip as the v0.1, in fact renamed. I don't know how all of this happened, and how no one found the problem since 2017, maybe nobody is playing the LE Ü.


    So here is the REAL v0.2, the version that should have been online for 2 years : v0.2 fix 2019

    If you need a sound only when the bus is moving, you can do something like :

    It will play your sound when the velocity is greater than 0. It will work only when your battery switch is on.

    Hello,


    Yes you can use a transparent texture, in the .sli you need to have something like

    Code
    1. [texture]
    2. your_texture.png/tga
    3. [matl]
    4. your_texture.png/tga
    5. 0
    6. [matl_alpha]
    7. 2

    And you need to add the transparent spline to the map after you added the spline behind it (in your case, the road need to be added before the transparent marking).

    Hello,


    I was testing shadows, and I noticed that only few objects had shadows. I looked on the forum and I saw that it was "normal" in OMSI 2. None of my objects have it, except my traffic lights. So I tested everything that was in the .sco, and it appears that the element responsible of this is the [script].


    Only a .sco with a [script] and a [shadow] will have shadows. I saw that original street lights had shadows, so I think another tag can trigger it.


    So, if I want shadow on an object, I put at the end of the .sco :

    Code
    1. [shadow]
    2. [script]
    3. 1
    4. script\nothing.osc


    And the script "nothing.osc" must have a frame and something inside, if not the shadow will not appears. Here is the nothing.osc :

    Code
    1. {frame}
    2. 0
    3. {if}
    4. {endif}
    5. {end}


    I don't think it's really good in term of performance. Did anyone else find another solution?

    Etrusan Of course, I'm doing tests, but I have some issues with the approach method : when the bus leaves the path (and even the crossing), it remains detected. I never experienced this, and I did many complicated crossings with many bus detection.

    I have never tested but I also already thought of a logic of this type, with the traffic lights. It would be possible to use the stop / jumps that are inside the traffic light : I think of two tracks, on a straight road, that changes the state of the traffic light.


    For example the light is always 6:Green, and when a car is detected on track 1, the status of the light changes (via a jump or a stop if no approach)(example : 7:Green). When the car has passed the distance of track 1, the car is detected on track 2 and the status of the light changes (example : returning to 6:Green).


    After that it would be easy to parent an object to this "crossing", script it and to display the speed or a flash after a bit of calculation.


    So by default the light is 6, when a car arrives the light becomes 7 : we start the "counter", when the light becomes 6 we stop the "counter" and we calculate the speed and display it.


    The shorter the tracks, the better the cars will be detected during heavy traffic, but the less the speed will be accurate (because of the shorter length).


    I always wanted to try, so I think I will do it soon.


    Almost anything is possible, like the bikes (that I already did 6 months ago but never published

    :P

    )