Posts by Florito


    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.


    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.


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

    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).


    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 :

    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 :

    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 )

    Yes I did the same, just multiplying the value and it works fine !

    Thank you ! I take realism very seriously, I reproduce all the features as in real, even the less visible. That's why I like your work too on improving the realism (AI, air-conditioning).

    I don't use the electric mode becauses my doors aren't electric, and especially because the electric doors doesn't operate in relation with the avaible air.
    It is the pneumatic branch, here is the electric branch for comparision, it is similar but it has some additions like the speed definited by curves :

    EDIT : I think I found the problem, the code can't works.
    Here you have the line responsible of the variation of the maxspeed in acordance to the disponible air :

    1. (L.L.doorMaxSpeed_0_norm) (L.L.bremse_p_Tank04) 100000 - 850000 / (S.L.doorMaxSpeed_0)

    But if you read what the script does, the script never considers doorMaxSpeed_0_norm, the script simply does :

    1. ((L.L.bremse_p_Tank04) - 100000) / 850000

    I think its because it's a copy of the original M&R script :

    1. ' in s6 ist die verfügbare Druckmenge:
    2. (L.L.bremse_p_Tank04) 100000 - 850000 / s6

    And the man responsible of this part of code in the Citaro made an error, so the constant fdoor_maxspeed (and bdoor_maxspeed) does strictly nothing !!