Struct sim::mechanics::driving::DrivingSimState [−][src]
pub(crate) struct DrivingSimState { cars: FixedMap<CarID, Car>, queues: HashMap<Traversable, Queue>, events: Vec<Event>, waiting_to_spawn: BTreeMap<CarID, (Position, Option<PersonID>)>, recalc_lanechanging: bool, handle_uber_turns: bool, time_to_unpark_onstreet: Duration, time_to_park_onstreet: Duration, time_to_unpark_offstreet: Duration, time_to_park_offstreet: Duration, }
Expand description
Simulates vehicles!
Fields
cars: FixedMap<CarID, Car>
queues: HashMap<Traversable, Queue>
events: Vec<Event>
waiting_to_spawn: BTreeMap<CarID, (Position, Option<PersonID>)>
recalc_lanechanging: bool
handle_uber_turns: bool
time_to_unpark_onstreet: Duration
time_to_park_onstreet: Duration
time_to_unpark_offstreet: Duration
time_to_park_offstreet: Duration
Implementations
None if it worked, otherwise returns the CreateCar unmodified for possible retry.
If start_car_on_lane fails and a retry is scheduled, this is an idempotent way to mark the vehicle as active, but waiting to spawn.
pub fn update_car(
&mut self,
id: CarID,
now: Time,
ctx: &mut Ctx<'_>,
trips: &mut TripManager,
transit: &mut TransitSimState,
walking: &mut WalkingSimState
)
pub fn update_car(
&mut self,
id: CarID,
now: Time,
ctx: &mut Ctx<'_>,
trips: &mut TripManager,
transit: &mut TransitSimState,
walking: &mut WalkingSimState
)
State transitions for this car:
Crossing -> Queued or WaitingToAdvance Unparking -> Crossing IdlingAtStop -> Crossing Queued -> last step handling (Parking or done) WaitingToAdvance -> try to advance to the next step of the path Parking -> done
State transitions for other cars:
Crossing -> Crossing (recalculate dist/time) Queued -> Crossing
Why is it safe to process cars in any order, rather than making sure to follow the order of queues? Because of the invariant that distances should never suddenly jump when a car has entered/exiting a queue. This car might have reached the router’s end distance, but maybe not – might actually be stuck behind other cars. We have to calculate the distances right now to be sure.
fn update_car_without_distances(
&mut self,
car: &mut Car,
now: Time,
ctx: &mut Ctx<'_>,
transit: &mut TransitSimState
) -> bool
fn update_car_with_distances(
&mut self,
car: &mut Car,
dists: &[QueueEntry],
idx: usize,
now: Time,
ctx: &mut Ctx<'_>,
trips: &mut TripManager,
transit: &mut TransitSimState,
walking: &mut WalkingSimState
) -> bool
Abruptly remove a vehicle from the simulation. They may be in any arbitrary state, like in the middle of a turn or parking.
fn delete_car_internal(
&mut self,
car: &mut Car,
dists: Vec<QueueEntry>,
idx: usize,
now: Time,
ctx: &mut Ctx<'_>
)
fn update_follower(
&mut self,
idx_leader: usize,
dists: &[QueueEntry],
now: Time,
ctx: &mut Ctx<'_>
)
fn update_follower(
&mut self,
idx_leader: usize,
dists: &[QueueEntry],
now: Time,
ctx: &mut Ctx<'_>
)
After a leader (maybe an active vehicle, maybe a static blockage) gets out of the way, update the follower so that they don’t suddenly jump forwards.
If the car wants to over-take somebody, what adjacent lane should they use?
- The lane must be in the same direction as the current; no support for crossing the road’s yellow line yet.
- Prefer passing on the left (for DrivingSide::Right) For now, just pick one candidate lane, even if both might be usable.
Note the ordering of results is non-deterministic!
pub fn get_all_draw_cars(
&self,
now: Time,
map: &Map,
transit: &TransitSimState
) -> Vec<DrawCarInput>
pub fn get_all_draw_cars(
&self,
now: Time,
map: &Map,
transit: &TransitSimState
) -> Vec<DrawCarInput>
Note the ordering of results is non-deterministic!
pub fn get_single_draw_car(
&self,
id: CarID,
now: Time,
map: &Map,
transit: &TransitSimState
) -> Option<DrawCarInput>
pub fn get_single_draw_car(
&self,
id: CarID,
now: Time,
map: &Map,
transit: &TransitSimState
) -> Option<DrawCarInput>
This is about as expensive as get_draw_cars_on.
pub fn get_draw_cars_on(
&self,
now: Time,
on: Traversable,
map: &Map,
transit: &TransitSimState
) -> Vec<DrawCarInput>
pub fn find_trips_to_edited_parking(
&self,
spots: BTreeSet<ParkingSpot>
) -> Vec<(AgentID, TripID)>
Finds vehicles that’re laggy heads on affected parts of the map.
pub fn get_blocked_by_graph(
&self,
now: Time,
map: &Map,
intersections: &IntersectionSimState
) -> BTreeMap<AgentID, (Duration, DelayCause)>
Does the given car want to over-take the vehicle in front of it?
Trait Implementations
fn deserialize<__D>(__deserializer: __D) -> Result<Self, __D::Error> where
__D: Deserializer<'de>,
fn deserialize<__D>(__deserializer: __D) -> Result<Self, __D::Error> where
__D: Deserializer<'de>,
Deserialize this value from the given Serde deserializer. Read more
Auto Trait Implementations
impl RefUnwindSafe for DrivingSimState
impl Send for DrivingSimState
impl Sync for DrivingSimState
impl Unpin for DrivingSimState
impl UnwindSafe for DrivingSimState
Blanket Implementations
Mutably borrows from an owned value. Read more
impl<T> Downcast for T where
T: Any,
impl<T> Downcast for T where
T: Any,
Convert Box<dyn Trait>
(where Trait: Downcast
) to Box<dyn Any>
. Box<dyn Any>
can
then be further downcast
into Box<ConcreteType>
where ConcreteType
implements Trait
. Read more
pub fn into_any_rc(self: Rc<T>) -> Rc<dyn Any + 'static>
pub fn into_any_rc(self: Rc<T>) -> Rc<dyn Any + 'static>
Convert Rc<Trait>
(where Trait: Downcast
) to Rc<Any>
. Rc<Any>
can then be
further downcast
into Rc<ConcreteType>
where ConcreteType
implements Trait
. Read more
Convert &Trait
(where Trait: Downcast
) to &Any
. This is needed since Rust cannot
generate &Any
’s vtable from &Trait
’s. Read more
pub fn as_any_mut(&mut self) -> &mut (dyn Any + 'static)
pub fn as_any_mut(&mut self) -> &mut (dyn Any + 'static)
Convert &mut Trait
(where Trait: Downcast
) to &Any
. This is needed since Rust cannot
generate &mut Any
’s vtable from &mut Trait
’s. Read more
Instruments this type with the provided Span
, returning an
Instrumented
wrapper. Read more
type Output = T
type Output = T
Should always be Self