Door speed problem

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.
  • Hello,


    I'm animating a door and I need to adjust the speed and the acceleration in the constfile. The door takes aproximately 3 seconds to open at the maximum pressure, and the acceleration is quite fast. It's pneumatic.
    But I have some problems to specify the right speed, because it seems that whatever I put in fdoor_maxspeed, it changes nothing. I can only change the speed by changing the acceleration, but it's not what I want, because I want an high acceleration with a little speed.


    Here is a part of my constfile (I work on the front door) :


    After each change I respawn my vehicle because I know that theses constants are in the init of the door script.


    Greetings,
    Flo

  • Hi,


    I assume the vehicle you are working on uses the standard M+R door script--if not, please clarify, or better yet attach the complete script here. Judging from the door script alone (using that of the SD 200 as reference), those max-speed constants appear to be ignored altogether (perhaps they are used indirectly through some other script, but certainly not in this one). For pneumatic doors the speed is calculated (e.g. in the opening case) as follows:

    Code
    1. (L.L.doorSpeed_0) (L.L.doorAcc_0) (L.L.door_pressure_open_0) * (L.L.doorDragAcc_0) + (L.S.Timegap) * +
    2. (L.L.doorDamper_0) (L.L.doorDamper_0_kennwert) (L.S.Timegap) * * -
    3. (S.L.doorSpeed_0)

    Thus, artificially increasing any of the factors contributing to the first addend (or altering the logic responsible for their respective calculation) should increase the maximum speed. On the other hand, increasing the second one would reduce it. Note that the acceleration factor (doorAcc_x) itself depends on a per-vehicle-randomized variation factor (see init).


    An alternative approach for more fine-grained control would be to revert to use of (pseudo-)electric doors and customize the door_x_(opn|close)_speed curves instead.


    As an aside, when testing scripts, do yourself a favor and reload the map (or even the game just to be certain). Plenty of times I've banged my head against the keyboard due to OMSI not reloading scripts upon modification at the filesystem level...

  • Hi,


    Thank you for your answer ! My bus is in project since one year now and the script was from the Citaro, I'm sorry I should have specified it. The constant is not directly used but some variables are calculated with it in the init, that's why you don't see it in the part you attached. Here are the part of the script where the constant fdoor_maxspeed is used :
    {macro:Door_Init}

    Code
    1. 1000 random 500 / 1 - (C.L.door_maxspeed_var) * (C.L.fdoor_maxspeed) + (S.L.doorMaxSpeed_0_norm)


    {macro:Door_Frame}

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


    {macro:Door0_Calc} (the part that calculates the movement)


    Yes I reload each time the map and the bus (I have a map with just one tile so I lost less time at the load), because thoses parameters are definited in the init. It appears that if you just remove the bus and respawn it, it doesn't reload the scripts...

  • Indeed, things are different in the Citaro's script. Can't say for sure (I'm on a Linux machine and thus cannot test any of this), but if I recall correctly, that's the branch specific to electric doors. Try switching electric door mode on (and pneumatic off) and adjusting the curves I recommended above.

  • 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 :

    Code
    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 :

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


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

    Code
    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 !!

  • Good catch--I must admit that I didn't notice that! I just tested this, and simply multiplying that value with doorMaxSpeed_x_norm (which is, I believe, what the original script does, more or less) works fine; i.e.:

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

    Kudos to you for both investigating and insisting on realism (even Morphi uses the electric door setting for vehicles having pneumatic doors).

    :)


    <humor>
    ...although technically I was nevertheless correct from the very beginning, having suggested that the constant is being disregarded

    :P


    </humor>


    Edited: Perhaps it would be better to gradually, rather than instantly, adjust doorMaxSpeed_x:

    Code
    1. ' adjust s2 (incrementation/frame, while doorMaxSpeed_0 < doorMaxSpeed_0_norm), s3 (decrementation/frame, while doorMaxSpeed_0 >= doorMaxSpeed_0_norm) as needed
    2. (L.L.doorMaxSpeed_0_norm) (L.L.bremse_p_Tank04) 100000 - 850000 / * s0 (L.L.doorMaxSpeed_0) s1 1 s2 s3 (M.L.door_traegheit) (S.L.doorMaxSpeed_0)

    Edited (1): No, thinking about this anew, it probably doesn't matter, as long as bremse_p_Tank04 does not change too rapidly.

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