Project type: Bus / script modification
Project name: AI enhancements for the standard M+R MAN NL/NG buses.
- Author: Unorthodox Paradox
- Accredited: MR Software and everyone who co-authored the original scripts.
Copyright / licensing: The portions of the scripts that I modified are copyleft. The remainder of the redistributed content is subject to the terms of its respective authors.
Pictures / videos: None available, for this is a scripting mod.
This modification provides two enhanced, AI-only versions of the standard M+R MAN NL/NG buses; the goal being, as usual, to render the AI a tiny bit more realistic / intelligent. A secondary goal is to discover just how complex AI scripts can get without bringing about major performance loss.
- The AI is now capable of adjusting the state of windows and hatches, taking the environmental conditions (time, insolation, precipitation), as well as the virtual driver's subjective perception of those conditions and personal preference into account.
- Likewise, AI usage of lighting and wipers is now dynamic, meaning that under the same environmental conditions, two vehicles' virtual drivers will configure lighting and wipers differently. Lighting and wiper usage is further differentiated based on whether the AI is in "break" (i.e., stopped at a terminal stop, or one that is mandatory and is of extended duration) or normal operational mode.
- The door workflow whilst at a (scheduled) stop has been enhanced. Specifically, the AI:
- Only opens the vehicle's front doors when either a) people actually wish to board the bus, or b) the environmental conditions are perceived by the driver as "too warm", and "break" mode applies (see above).
- May close front doors again, even prior to departure, if it is "too cold" outside.
- May either use solely the first, or both front door wings.
- May override the second door pair in "break" mode, if it is "too warm".
- May depart from a stop with open front doors, when it is, according to the driver, "too warm", and passenger safety isn't jeopardized.
- No longer departs instantly from a stop when OMSI tells it to, but instead delays its departure for a brief moment, both for practical reasons, as well as due to safety concerns.
- The AI uses the sun blind.
- Departure from terminal stops is further briefly delayed, as a workaround for the issue of passengers being unable to board due to destination display update occurring exactly before departure.
- The AI occasionally "forgets" to use its indicators.
- The AI occasionally engages the stop brake (via the "20-h switch") when at a standstill.
- Open windows and hatches, as well as rain and dirt textures, are now visible on out-of-focus vehicles as well.
- Windows and hatches now have memory. What this means, is that their states are not solely dependent on the environmental conditions and driver-specific preference anymore, but, additionally, on their previous respective states. For example, suppose that a driver chooses to open a window under cold conditions. If the weather subsequently gets warmer, then the driver may open additional windows, but will certainly not close the previously opened one (which was previously not the case).
- The driver's window, as well as the sun blind, are now being adjusted progressively, i.e., you can actually see the adjustment (sliding/pulling/retracting) occurring. Additionally, sounds are emitted during their adjustment, as would be the case were the player him- or herself to perform the adjustment instead of the AI.
- Adjustment of windows and hatches is now delayed. Furthermore, passenger windows and hatches are only adjusted when the vehicle is stopped.
- The driver window is now being opened maximally when the vehicle is at a scheduled stop under hot conditions, and its engine has, or is to be, turned off. That is because the vehicle is (assumed to be) air-conditioned under such conditions.
- Passenger windows and hatches emit sounds when adjusted.
- When the vehicle has departed from a stop with its front doors left open, if the weather changes en route (e.g., if it suddenly starts raining prior to the next stop having been reached), the driver will close the doors when the first opportunity to do so (e.g. stopping at a traffic light) arises.
- Improved unconditional front door opening evaluation, taking not only the environmental conditions, but also random choice, as well as the stop's duration into account.
- Improved terminus departure workflow: The driver no longer delays departure solely by a static time period, but waits (within reasonable limits) as long as it takes for all spawned passengers to actually board.
- Calculation of departure with open front doors probability and preconditions improved.
- Second door pair no longer gets overridden under rainy conditions.
- The following events occurring as part of a stop workflow are now randomly and individually delayed, hopefully resembling more human-like behavior than they used to:
- Stop brake setting and releasing (excluding 20-h switch release event during unscheduled stop, as yet to be addressed).
- Hand brake (dis-)engagement.
- Engine ignition and shut-down.
- Gear (dis-)engagement.
- Front door opening and closing.
- Back door overriding at extended stops.
- Dimming / switching off / resetting of exterior lights.
- Indicator (de-)activation at extended stops.
- Sound playback is now triggered by the following events:
- Hand brake (dis-)engagement.
- Engine ignition and shut-down.
- Gearbox "D" button pushing and release.
- Cockpit animations for door, engine ignition / shut-down, and gearbox "D" (forgot to also support the "N" button, unfortunately) buttons are now triggered by the AI in the appropriate contexts.
- Lights are now properly actualized even if the AI-controlled vehicle leaves the observer's tile.
- When lights are temporarily switched off (e.g. at an extended stop), and a turn-off transition (due to e.g. environmental brightness increasing) is pending, the transition timer is reset (and lights are just left off). Doing so results in seemingly more natural behavior.
- Better estimation of the actual environmental brightness (i.e., of insolation), leading to improvements in various areas, such as realistic sun blind usage.
- The minimum duration for a stop, for the latter to be considered an "extended" one, is now subjective, allowing different vehicles to exhibit different behavior while at the same stop; e.g., one driver might switch the engine off, while another one might not.
- The brake pedal is released when the stop brake (door release or 20-h switch) gets engaged.
- Vehicles may now spawn dirty (previously they could get dirty in the process, but would always be clean initially), particularly under rainy conditions.
- Incorporated <OMSI>\Scripts\up-utils directory and files therein. These should normally have been included since the initial version, but were, due to "some inexplicable reason" (a.k.a. Murphy's Law), erroneously left out.
- antrieb_getr_version changed to 1, as a workaround for vehicles spawning "stuck" in neutral (issue #1).
- Some first refactoring efforts were undertaken in order to reduce duplication and improve readability of the code base. The main scripts now act as mere delegates, and their functionality was split into several distinct subsystems. Additionally, variable declarations and constant definitions formerly residing in <OMSI>\Vehicles\MAN_NL_NG\Script\aipp\AI_(constfile|varlist).txt have been relocated to their respective subsystem-specific counterparts. Finally, clean-up of the atrociously "spaghetti-quality" door script began, with some time- and timetable-related utilities being moved to their own scripts.
- Some limited fault-tolerance has been introduced into the door-, and generally the stop-related workflow: When stopped vehicles respawn elsewhere (particularly in between stops), as a consequence of the user having adjusted the time, stop-specific parameters are reevaluated, and the vehicle returns to a normal operational state faster than it previously did (formerly, when the vehicle was in "break mode" prior to the occurrence of the time(table) change, the vehicle would sometimes remain "stuck" for up to a minute upon respawning).
- The AI now treats terminal stops consisting, timetable-wise, of two stops (the last stop of the previous trip and the first of the next one), as a single one. This improves realism, in the sense that the AI no longer acts as if it were to depart (i.e., by closing doors, etc.), only to act as if it were to arrive again the next instant.
- When departing from a stop, the AI only resets the door release switch (and consequently the stop brake) if it actually is able to drive on, i.e., when there is no "obstacle" (e.g. pedestrians) blocking its immediate path.
- The lighting subsystem is now experimentally extensible on a per-map basis. Refer to the discussion in post #5 for details.
- As a precautionary measure, vehicles now always spawn (and remain) fully tanked.
- Vehicles may now spawn with damaged/burnt out lights. Note that this differs from the feature of the original M+R lighting script, allowing for lights to burn out while the vehicle is in use (a feature which would hardly ever manifest in the case of AI-controlled vehicles). All primary light sources—in other words those destined to actually increase brightness—declared as [light_enh_2] entries in the model configuration files (markers, indicators, brake lights, and so forth) are affected. From the remainder of the light sources I would like to have covered, namely the passenger cabin's primary, as well as the exterior destination matrices' fluorescent tubes, only the articulated variant's rear matrix's tube, along with the front-most one of the latter kind, actually made it into this update, due to model/texturing limitations. Damage probabilities vary by the kind of light source and are calculated individually for each bulb/tube.
- Indicator usage improvements:
- The AI "forgetfulness" feature has been extended to affect all cases of indicator adjustment, i.e., both negation (off↔left; off↔right) and inversion (left↔right).
- Upon departure, the AI always indicates left, regardless of OMSI's opinion on the matter. The sole exception, besides forgetfulness, is when the path segment adjacent to that of the stop instructs right indicator usage.
- The transition from right to left indicator whilst at a stop may now occur before stop brake release, thus resembling real-world driver behavior more closely.
- Interior light improvements:
- Deactivation of passenger lights on service trips is now additionally dependent on the duration of the trip (the longer the trip, the more likely the AI is to switch cabin lights off). Moreover, state transition of cabin lights in the event of a service trip beginning or ending is no longer instantaneous.
- In the event of being stopped and exterior lights having been switched off, driver light usage now varies per vehicle (previously the driver's light would always be switched on based on a static environmental darkness threshold).
- Usage of the front-most light now (subjectively) depends on the solar elevation angle, besides the time of the day.
- Adjustment of the front-most and the rest of the passenger lights now takes place asynchronously, meaning that the driver will not "push" both switches at the exact same instant.
- Indicator usage improvements:
Door / stop workflow
- A fail-safe has been introduced into the heuristic used to evaluate whether a stop is extended (both in terms of duration and profile): When the stop in question is non-terminal, the evaluation is deferred until passenger exchange has completed, since it is only after that point in time possible to predict with reasonable confidence whether the game will dictate early departure or allow the vehicle to wait until its scheduled departure time has actually arrived. In previous versions the vehicle would instead—oftentimes erroneously—attempt to guess the answer in advance, solely deducing it off of the timetable data provided by the game, causing it to engage in "break mode" (switching its engine off, etc.) for mere seconds when proven wrong.
- The terminus/initial stop combining feature of the previous release has been extended to accommodate for an arbitrary number of consecutive stops. Generally, when the vehicle now arrives at a stop M being track-/timetable-wise—in terms of docking distances and departure/arrival times overlapping—adjacent to the next N stops, it will behave as if it is still at the Mth stop (and potentially enter "break mode") until the departure time of the (M+N)th stop arrives.
- Indicator/wiper lever, as well as interior light switch adjustments now trigger sounds.
- The engine scripts of the two variants have been merged into a single one, out of maintainability concerns. The transmission and braking scripts will likewise follow in a future release.
- Resolved issues #2, #3, #4, and #5.
(Reference ID / Version in which issue was identified / Resolution status (Version of last update))
- 6 / 1.0.2-alpha / Investigation pending (1.0.3-alpha)
When the user adjusts the time to the precise time of departure from a terminus stop, any vehicles whose timetables are affected, and which were already spawned before the time change, fail to update their destination displays.
Note - 1.0.3-alpha: Since the core of the matrix script's functionality has been left intact thus far, this might be an issue having been present all along. I have yet to confirm this, however. An underlying OMSI bug might as well be the cause.
- 7 / 1.0.2-alpha / Investigation pending (1.0.3-alpha)
Vehicles disappear without an apparent reason (e.g. due to a faulty path segment). Note that is not the same as #8. As a simple reproducible example, ride a bus from "Bauernhof" to "Krankenhaus" ("Grundorf"). On its return journey, the vehicle will typically (~ 3 out of 4 times) disappear upon arriving at "Nordspitze".
Note - 1.0.3-alpha: The cause probably lies somewhere in my modified files, as I found myself unable to reproduce the issue using the standard versions of the vehicles. A consistent occurrence pattern is yet to be discovered.
Partially resolved / In progress
- 1 / 1.0.1-alpha / Temp-fixed (1.0.2-alpha)
Vehicles' transmission sometimes appears to get "stuck" in neutral gear, only being able to engage a gear again after having slowed down to almost a standstill. While the concrete cause has not yet been identified, the issue seems to occur when the vehicle has exited the user's tile and then reenters it (due to the user switching map position in "F4-mode") at a high velocity. Assuming that OMSI unloads scripts when the vehicle is outside of user reach, the transmission script might not be capable of dealing with major discrepancies (e.g. different velocities) arising between the context before "hibernation" and post "revival".
The workaround introduced, as of 1.0.2-alpha, simply disables the automatic gear disengagement feature of the transmission script.
- 3 / 1.0.2-alpha / Assumed fixed, unconfirmed (1.0.3-alpha)
When the vehicle, while in "break mode", is to depart prematurely, due to a sudden user-induced time(table) change, gear re-engagement does not take place, and the vehicle is unable to drive on.
Note - 1.0.3-alpha: This cannot be reproduced any longer; it is thus assumed to have been resolved implicitly via the related changes addressing #2. Nonetheless, just in case, a check has been added to the stop workflow (door subsystem) so as to prevent attempted departure prior to the gear having properly been engaged.
- 2 / 1.0.2-alpha / Fixed (1.0.3-alpha)
When terminal stop combining occurs and the vehicle has entered "break mode", different subsystems (engine, wipers, etc.) are re-adjusted too early, as they still take the original, rather than the next stop's departure time into account.
As of 1.0.3-alpha, the departure re-adjustment logic of all affected subsystems has been corrected.
- 4 / 1.0.2-alpha / Fixed (1.0.3-alpha)
At a terminus stop, the vehicle may begin left-indicating long before departing.
Addressed indirectly via the fix for #2, combined with the revamped indicator AI usage logic introduced in the same version as the former.
- 5 / 1.0.2-alpha / Fixed (1.0.3-alpha)
Vehicles appear unwilling to adjust their parking position at extended stops, after any vehicles that were initially occupying the space have departed.
Cause: Due to the disagreement between the scheduled and actual departure times, the vehicle would never really exit "break mode" in such a scenario, consequently being unable to depart (i.e. to switch its engine back on, etc.).
Resolution: The departure routine of the stop workflow (door subsystem) is now aware of this possibility, and checks, when the vehicle is at an extended stop, for such temporal discrepancies.
- 8 / 1.0.2-alpha / Wontfix (1.0.3-alpha)
Vehicles may disappear when they have failed to arrive at their trip's terminus stop on time for their next trip. They then typically respawn en route to their next trip's target.
Resolution: This is apparently a limitation of the game, hence there is not much I can do about it. While these modified vehicles might be a tad more susceptible to it than the original ones, because of their tendency to accrue delay at an increased rate compared to vehicles employing the standard scripts, I am disinclined to sacrifice functionality to merely reduce the problem's occurrence likelihood.
To use this modification:
- Download its files from here.
- Extract the downloaded compressed archive's Vehicles and Scripts directories into your root OMSI 2 directory (no standard content will be modified). If updating from a previous release, or otherwise re-installing, always overwrite any files remaining from previous installations.
- Declare <OMSI>\Vehicles\MAN_NL_NG\MAN_EN92_aipp.bus and/or <OMSI>\Vehicles\MAN_NL_NG\MAN_GN92_aipp_main.bus in your map's ailists.cfg.
- Use at own risk.
- Expect a (non-severe) performance degradation.
- The current release is an alpha (and will probably remain one for a long time), so expect bugs and poorly-written code.
- I can neither guarantee support provision for, nor further development of this modification.