Hello,
Concerning script-influenced AI lighting, you might want to take a look at that older post, as well as at the CSB pack which includes a more comprehensive implementation of the same basic idea.
What both of these accomplish, in a nutshell, is to:
- Assign, at initialization time, a random per-vehicle threshold for a) solar elevation angle (Sun_Alt), b) brightness (Envir_Brightness) and c) rain/snow rate (PrecipRate -- the system variable, not the local one, as the latter also depends on vehicle velocity, orientation and wind speed); and
- check, once per frame, whether these thresholds have been exceeded, and if so switch lights on or off (but with an asymmetrically timed delay -- shorter when lights are to be switched on, longer in the opposite case --, so as to avoid excessively frequent cycling when, say, the vehicle happens to have briefly entered the shadow of an isolated cloud, or, say, it has stopped raining but for merely half a minute).
The model.cfg then simply references custom variable(s) for lighting state, rather than built-in AI_(Interior)Light.
Note that, behind the scenes, AI_Light itself is still being taken into account as an additional factor, because it can serve as a heuristic for weather-/environment-related information which OMSI provides no explicit API for, such as visibility/fog, cloudiness and state of street lights. For instance, assuming the default <OMSI>\envir.cfg[1], under normal (clear and dry) weather conditions, OMSI instructs vehicles to turn their lights off/on at, IIRC, ~10 degrees solar elevation angle; thus, when Sun_Alt is greater than 10 and yet AI_Light is still equal to 1, a script can deduce that it's to some degree cloudy and/or rainy and/or foggy.
As for the CSB adaptation in particular, it goes a little further, also addressing aspects such as varying usage of cabin lighting during the day, as well varying usage of both interior and exterior lighting at prolonged stops (stops with a duration in excess of 1 minute, at which OMSI requests that the engine be turned off).
Likewise, when it comes to script-influenced AI acceleration, the premise is to define and reference custom Throttle and Brake variables instead of their native counterparts. For example, in that unfinished "mod-mod" for the CSB fleet (see cockpit_throttle_brake_frame macro), this very tactic is employed for simulating a more human-like driver's departure from a stop -- firstly just briefly tapping the throttle for the stop brake to disengage, waiting for a second or two (presumably for checking mirrors and ensuring no one intending to board got left behind), and only then proceeding to firmly depress the pedal to actually accelerate. Originally my intent had been broader and similarly ambitious to yours -- I was seeking to assign a distinct "aggressiveness factor" to each vehicle, based both on the driver's (random) personality as well as potential timetable deviation. Eventually I abandoned that goal, as it dawned on me that the game unfortunately doesn't expose the requisite contextual information for an acceptably realistic implementation, for instance bumper-to-bumper distances, whether an upcoming traffic light just turned yellow, or whether a pedestrian randomly decided to jaywalk Berlin-style. Surely some of these can be deduced by probing whether Brake suddenly spikes to 100% (normally OMSI likes to brake relatively gently, typically under 20%), but still, scripts just don't get a real chance to plan ahead like a regular old human would, by e.g. preemptively letting go of the accelerator so as to slow down say a hundred meters prior to reaching an obstacle, as opposed to slamming down the brake at the very last instant only to barely avoid a collision.
TL;DR: As IREgio612 wrote, you would use your own logic to emulate/augment AI_(Interior)Light, Throttle and Brake, store the results of your calculations in your own variables, and replace all references to the original variables (in scripts as well as in model.cfg and potentially sound.cfg files) with your own variants. For AI cars this tends to be relatively painless, since they typically reuse <OMSI>\Scripts\AI_Cars\main_AI_xxx.osc and ~AI_varlist_xxx.txt, thus leaving only their model.cfg (plus potentially *.ovh/bus, if scripts/varlists were renamed/added) in need of revision.
[1] As an aside, that file might be functioning as the "global switch" you mention. While I don't own the aforementioned DLC, I suspect that it alters the brightness (color transition by time of day) curves defined in that file, which in turn might be influencing the conditions under which OMSI sets AI_Light to 1.
(Edit) Another possibility to consider are the cloud type definitions (<OMSI>\Weather\clouds.cfg), and by extension the weather scenarios (*.owt) referencing them: Clouds defined as "overcast" (ovc) always trigger AI_Light, regardless the time of day and other weather settings in effect. Consequently, even a fully transparent cloud texture, not affecting insolation/brightness at all, could be forcing AI vehicles to permanently leave their lights on.
= Englisch [EN], 
= Deutsch [DE], 
= Französisch [FR]. Wenn du die angegebene Sprache nicht beherrschst, schreibe auf Englisch! 