widgetry, geom, and abstutil may wind up on crates.io in some form to
let other projects use widgetry. abstio has A/B Street-specific tricks
for reading data on native/web. Note widgetry still depends on abstio,
will figure out how to clean that up next.
If an intersection is short, and bike is spawned, another bike coming along will attempt to fit if force_entry is true. This results in a panic. To address this, if the reserved_length is >= the geom_len, false will be returned, even if forced_entry is true.
* Add a Variable phase
Variable provides a min duration, a delay duration, and an additional duration. The maximum cycle time is min + additional. Once min has been exhausted, if there is demand, the cycle is extended by delay until there isn't any demand or the additional duration has been consumed.
#295
saves lots of callers from cloning the request and separately plumbing
around the requested start/end distance. Also a step towards exposing
more granular distance crossed in a path for #392.
Still a few more places to simplify, but will do in a separate, smaller
change.
starting an uber-turn) the same as accepted turns, updating the
blocked-by graph and allowing a movement to start if a cycle is
detected.
No effect in montlake or lakeslice, and very slight progress at the
Krakow roundabout for #382 -- increasing a tiny 26 trips by 7:20 am.
1. Allow lane changing in an uber turn. Because of the way uber turns
work, we lock in and commit to all the lane changes just before
entering the uber turn.
2. Avoid overzealous lane changing by combining number-of-lanes-crossed
and numer-of-vehicles-in-lane into a single cost, rather than always
preferring the least number-of-vehicles-in-lane.
3. Don't lane-change unless the candidate lane's cost is strictly better
than the current lane cost.
optimizations avoided serializing Analytics and paths of to-be-created
agents, to reduce the file size. The logic to manage all of this isn't
worth the complexity anymore, because:
1) We don't queue up a bunch of spawn commands anymore; we defer
pathfinding until the last minute anyway.
2) We're not using savestates except for occasional manual debugging.
Previously, there was an idea to quickly preview prebaked traffic
mid-day. That idea was never fleshed out.
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.
