1. Dynamically allocate repair times depending on the number and severity of affected parts, but also based on additional context. Here's an outline:
Repairing damaged electrics and/or battery may take anywhere from 10 minutes to 8 hours.
Repairing or replacing the engine may take from 30 minutes to 2 days.
Repairing or replacing transmission may take from 30 minutes to 2 days.
When repairing light units within (complex, "multi-layer") cases, include the delay for opening up the casing and closing it afterwards. When multiple units share the same case, this additional "cost" should only apply once for all collocated units. Lastly, when units get defunct due to collision impact, their cases themselves might have to be replaced (charge accordingly).
Replacing light units takes 1~10 minutes per unit, depending on the installation difficulty, whether the source is fronted by a projector that first has to be removed, whether the unit it out of direct reach (i.e. a moving platform or ladder would be required to reach the marker lights at the head or tail in order to replace them), ...
It also takes time for the service crew to arrive, let alone transport the vehicle to/from the garage if necessary. It could take an hour on working days/hours, and several hours on weekends or after-hours. A .hof-specific variable could be provided for fine-tuning the baselines.
2. Give the user some sort of choice on what to repair. In its most simple form that might mean that whenever the user hits the native menu repair button, different parts get replaced, from most to least critical. A more sophisticated implementation might be to give the user a kind of "check-list" to actively choose what gets to be repaired when they next trigger the button.
Note: Both tasks are effectively blocked due to #7.
1. Dynamically allocate repair times depending on the number and severity of affected parts, but also based on additional context. Here's an outline:
2. Give the user some sort of choice on what to repair. In its most simple form that might mean that whenever the user hits the native menu repair button, different parts get replaced, from most to least critical. A more sophisticated implementation might be to give the user a kind of "check-list" to actively choose what gets to be repaired when they next trigger the button.
Note: Both tasks are effectively blocked due to #7.