The schedule validation changes slightly. No-op trips between the same
origin/destination are now an error and get filtered out.
huge_seattle scenario goes from 129MB to 110MB with the redundant
endpoints removed.
TripEndpoints from TripLegs. #258
NOW regenerate scenarios. I'm confident this sweeping refactor didn't
break behavior, because prebaked data didn't budge. huge_seattle
scenario went from 147MB to 129MB. Not bad!
in favor of Option<TripEndpoint>. The bike/car contention tutorial stage
has to be tweaked manually, since there's no longer a nice way to spawn
vehicles at a non-border intersection and force them to use a certain
DirectedRoad. #258
remote trip goes between two locations off-map, specified just by a GPS
coordinate. The trips aren't simulated at all. They were originally
added to support Orestis's pandemic model, to handle transmission
off-map in shared buildings. This work has died off, there are no other
anticipated use cases for remote trips, and they complicate bigger
refactorings. #258
This also has the nice side effect of substantially reducing scenario
size -- huge_seattle from 177MB to 147MB. That unused metadata was
expensive!
biking_connection, which does a slow graph floodfill.
Prolet robot in Krakow: from 22.6s to 10.1s
Because Krakow now uses separate sidewalks and they're not properly
connected to the road graph yet, biking_connection has to search very
far. The speedup isn't noticeable in other cases.
struct. Whatever choices we make next about naming cities hierarchially
or not can be managed in just one place. #326
This is a pretty huge change, but the compiler gives reasonable
confidence it's correct. More bugs are likely to crop up in the next
step, when filenames start being namespaced by the city too.
order of vehicle deletion, we try to ask about stop sign and traffic
signal movements that may be deleted and would be irrelevant anyway if a
different deletion order happened. #312
We should really defer wakeup_waiting until after all cleanup is done,
but for now, willing to risk some stuckness at a stop sign...
1) A car tries to spawn, but fails because there's something in the way
2) The player makes live edits
3) The retry occurs, but the path has become invalid due to edits
Need to make the detection of this more efficient later.
Originally, all trips in the entire scenario had their paths calculated
at the beginning of a simulation. The sum time is faster than
calculating them individually, because we could use multiple threads.
But a while ago, this was disabled by default to improve the startup
latency. Especially if a player isn't making it through an entire day
anyway, calculating all of the paths upfront is a waste and slows down
their initial experience.
Now I'm hitting all sorts of bugs with live map edits, because the map
change between initial planning and when a trip starts. Previously, the
PathRequest was calculated up-front and resolved when a trip starts. But
even this PathRequest can become stale. So now always calculate it when
a trip actually starts, looking at the current map. To do this sanely,
totally rip out support for --pathfinding_upfront.
If we really want it later for performance, we could add it back in, and
be very careful about detecting stale PathRequests and recomputing. But
for now, there's no use case for this, so it'd needlessly complicate the
code.
