Warning lights when opening doors and different blinker timing

Hi,

Both are feasible. The specifics depend on the vehicle being modded.

Concerning your first question: This is not normally possible by configuration alone. You will have to figure out how scripts work, and edit the apposite logic within lights.osc and/or cockpit.osc. Given that these sort of little mod requests have been asked over and over, as well as, as stated above, different vehicles utilize different scripts (if only so slightly), I'm not inclined to spoon-feed you a concrete solution. What I can do, however, is provide you with some starting background with regards to the scripts used by the standard buses.

Script-wise, the direction indicator logic is governed by the lights_startblinkgeber and lights_runblinkgeber "routines" (coined macros in OMSI's scripting language), residing within lights.osc. The first routine is responsible for the initial activation of the director indicator lights, while the second one drives subsequent state inversions, i.e., the perceived blinking. Both are callbacks for other code. The former is called by the {trigger}s attached to the actual physical dashboard objects, in response to the user performing some action on them, such as toggling the hazard switch or flipping the direction indicator lever. The latter is called by the primary routine of the lighting subsystem, the lights_frame macro, to actualize, once per game frame, the timing of the on/off light alternations.

At the beginning of each of the two routines, logical conditions for (re-)activation of lights are formulated. These normally take power availability and apposite dashboard state into account: "If either the lever has been flipped, or the hazard mode button has been toggled, and power supply is adequate, then blink; otherwise reset". The lever/button state, on the other hand, is set at the "call site", and in particular the trigger originally having acknowledged the user's request.

Now, once you have taken the time to familiarize yourself with the scripting language (otherwise it will just sound nonsensical), the above should be sufficient to help you compile a rough plan of attack. When door opening gets triggered, you would emulate what the trigger for the direction indicator lever or hazard mode button already does, i.e., set a custom variable (and reset it once the door has closed) and call lights_startblinkgeber once to initiate blinking. Furthermore, you would have to adapt the aforementioned conditions within lights_startblinkgeber and lights_runblinkgeber so as to take that extra variable into account as a sufficient constraint, under which blinking shall indeed commence or resume.

Concerning your second question: If by "different blinker timing" you mean "a constant blinking interval that is different (faster or slower) than the default one", then there's a good change you can get away with merely changing the value of the lights_blinkertime_on and/or lights_blinkertime_off constants of lights_constfile.txt. If however you want different intervals under different conditions, then the answer is once again to be sought in the two macros referred to previously.

Yes, that would be correct, thus you would need to check the state of each door wing (pair), not merely the first one.

Above I was intentionally oversimplifying somewhat, to try get you in the mood to "dig" a bit yourself. Truth be told, triggers are not the most convenient place to implement such logic in. For one, they only get called once, at the very instant the corresponding dashboard door opener gets pushed; and because the actual opening / closing logic is not within the triggers themselves, one cannot know at that point whether the respective door will eventually open or not (maybe the vehicle is still moving faster than the maximum opening velocity constraint, thus the opening request will get discarded; or maybe there's a malfunction, thus opening is doomed to fail also). Secondly, for rear automatic doors, particularly the 3rd and 4th, where present, as is commonplace in Germany (and thus most door scripts), there usually is no dashboard button / switch for controlling them, and hence also no trigger. Lastly, when there are multiple triggers, it means that the logic in its entirety will have to be duplicated in each of them, which is plain ugly.

Therefore, for vehicles using a lighting and door script structurally close to those used by the standard MANs, I would instead choose to modify the door_frame macro, adding roughly the following to it (disclaimer: untested -- may be bugged):

Note that the variables door_indicator_lights_activator and door_post_closure_blinking_stop_delay are not used by the original script, hence they will have to be declared by the accompanying door_xxx_varlist.txt.

Last but not least, I would add the door_indicator_lights_activator variable into the constraint expressions used by the aforementioned macros of the lighting script, that control the blinking workflow (disclaimer: these macros are from the standard scripts -- yours may differ):

With those changes, any open or opening door should result in exactly the same blinking behavior as if the dashboard's hazard indicator mode switch / button had been toggled.

Indeed, if you just want the state of the station brake to influence blinking, you can skip the addition to the door_frame macro, and, rather than testing for

door_indicator_lights_activator in the lights_startblinkgeber and lights_runblinkgeber macros, test for bremse_halte (or whatever equivalent variable there is for the state of the stop brake in your targeted vehicle) instead. That being said, I personally wouldn't want the indicator lights to blink each time I toggled the stop brake switch at a red light, and other traffic participants -- both in OMSI and the real world -- would likely find this confusing. Then again, if in your corner of the world it's more commonplace to rely on the handbrake, as opposed to the station brake, in such instances, then that might pose a compromise.

There's of course a learning curve to coding, as there is to acquainting oneself with any craft really, be it 3D-modeling or sound editing or texturing. Yet it's not elementary particle physics either. At the end of the day it all boils down to being able to express, in accordance with the syntax rules of the programming language relied on, what shall happen under what circumstances. It's the same in C/Java/Python/..., and OMSI's scripting language is no different -- except, it does not require one to read a multi-hundred-page "Effective X for dummies" tome just to get started. Yes, there may be a lot of German-named variables involved, I can totally understand every non-German-speaking scripter's frustration with that. But, in all fairness, one only has to remember 10~20 among all the hundreds of them, to be able to implement most basic changes -- or, alternatively, just take the time to rename them. Personally I find the general trend, of a very empowering feature of the game being left relatively in the dark, for only a minority of users to explore and exploit, rather disheartening. I would like that imbalance to change, and that's why I respond to requests like yours, in the manner I do.