Allowing door self-service

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 fellow OMSI drivers ^^

    I've heard about self-service door opening by climbing passengers was possible in OMSI 2. Nevertheless, I didn't find anything about it, neither on the forum, neither on the Net.

    More precisely, I would like that passengers could open and climb/go out in/from the bus using external bus door buttons.

    My questions are :

    1- It is possible to implement such self-serviceness ?

    2- It is possible to have multiple stampers in a bus ?


    Thanks a lot for your answers and have a good ride ^^


    Myyrä 55


    PS : I don't really know in which section this thread is belonging so don't hesitate to ask me to move the thread ;)

  • 1. external door openers are possible, the door script and passenger cabin has to be right scripted. Im a script-noob, i don't know much about it

    2. you can have multiple stamper objects in your bus, but in the passenger cabin you can only define one stamper.

  • Hello,


    Implementing self-service doors boils down to 2 tasks:


    1. Telling OMSI that AI passengers can board from certain doors at will.

    2. Enabling the door script to handle AI passenger entry and/or exit requests.


    The first task is optional but usually desired. The {withbutton} label may be appended below all or a subset of [entry] declarations in passengercabin.cfg. Doing so causes OMSI to alter its AI boarding-specific passenger flow logic. The default AI passenger behavior (no {withbutton} anywhere) is for them to walk to the first (in declaration order) [entry] when intending to board. With {withbutton}-labeled [entry]s included, on the other hand, passengers will always walk to the nearest {withbutton}-labeled [entry]. For example, if only the second [entry] is labeled {withbutton}, passengers will always walk to it by default, unless another [entry] gets opened first. Disembarking remains unaffected -- passengers always choose the nearest [exit].


    Notes:

    • [entry]s and [exit]s are indexed in declaration order, from 0 up to 7. Thus a maximum of 8 doors or door wings is supported.
    • [entry] and [exit] declaration order need not match physical door (wing) order. It can simply be thought of as kind of a priority list. It is for example perfectly legal to designate the second physical door (wing) first -- which would then mean that, in the absence of {withbutton}, passengers would always attempt to board from that door by default.
    • OMSI has 4x8 predefined variables related to [entry] and [exit] declarations:
      • PAX_EntryN_Req : Set by OMSI to 1 whenever an AI passenger stands right in front of (from the outside) [entry] at index N, intending to board when it gets opened; otherwise set to 0.
      • PAX_ExitN_Req : Set by OMSI to 1 whenever an AI passenger stands right in front of (from the inside) [exit] at index N, intending to disembark when it gets opened; otherwise set to 0.
      • PAX_EntryN_Open : Set by the vehicle's scripts to 1 whenever the "physical" door (however it is actually modeled) corresponding to the logical [entry] at index N has indeed opened. When 1, AI passengers will board by "walking through" the path-point referenced by the [entry]; when 0, AI passengers will wait.
      • PAX_ExitN_Open : Set by the vehicle's scripts to 1 whenever the "physical" door (however it is actually modeled) corresponding to the logical [exit] at index N has indeed opened. When 1, AI passengers will disembark by "walking through" the path point referenced by the [exit]; when 0, AI passengers will wait.
    • Scripts leverage the information encoded by these variables as they please in order to coordinate opening and closing of "physical" doors, and calling back to OMSI with updated door status (open / closed) information.
    • {withbutton} suffers from a couple of limitations:
      • (Articulated vehicles only) : AI passengers already spawned at a stop at the time of a vehicle's arrival will never attempt to board from any [entry]s defined for the trailer of that vehicle.
      • The fact that AI passengers will always walk to a self-service [entry] labeled {withbutton} may be annoying in certain cases when the user intends to manually open up a different door for them to board from; e.g. in simulated parts of the world where people are expected to only board from the front door at night / at after-hours; or for vehicles simulating self-service door malfunctions.

    The second step tends to involve some script editing -- typically portions of door.osc, sometimes also cockpit.osc, perhaps even VDV.osc, when modding Morphi's work -- unless the vehicle's scripts are inherently of great flexibility. Generally, if the vehicle does not already have functioning self-service buttons, their logic will first have to be implemented and bound to model.cfg-declared [mouseevent]s -- otherwise they won't work when the user "pushes" / clicks on them. Secondarily, but most importantly, the script will somehow have to translate the PAX_(Entry|Exit)N_Req information given by OMSI to that very same "button-pushing" logic -- otherwise self-service will only work for the user, but not for AI passengers requesting it.


    There isn't really a definitively correct or incorrect strategy for attaining the above, for it all depends on the peculiarities of the vehicle being modded, the complexity of the requirements, and how much time one is willing to invest into producing a "clean" solution (depending of course on one's subjective definition of "clean").


    I would recommend starting with the wiki entries on scripting and predefined / system variables (the latter only being available in German, unfortunately). Armed with that knowledge, you can then proceed to study the quasi-standard MAN NL/NG door script. That script already implements self-service doors, hence all you have to do is adapt the passengercabin.cfg, adding two new pairs of [entry]s and labeling them {withbutton}. Ai passengers should then use the rear doors for boarding as well.


    If you'd like clarification on something purely code-related, be it in those wiki articles or the script, feel free to ask.