GuidedPathTransportSystem

A guide path an entity drives itself over: the space layer, plus the passive protocol's own accounting.

Almost everything a modeller reaches for is inherited from GuidedPathSpace -- the zones, the fleet, the movement engine, the invariant checking, the congestion statistics and the five per-carry figures -- because almost all of it is about the guide path rather than about who decided to send a vehicle down it. What is added here is the one quantity that belongs to this way of modelling and to no other.

Why transportTime is the only thing this adds

The two subsystems both have something they call a transport time, and they do not mean the same thing by it. Here it runs from the entity's request to the entity being set down, because in this paradigm the request is the beginning of the story: the entity asks, waits for a transporter, rides it, and gets off. The active subsystem's runs from the load being aboard to being set down, because there the wait is decomposed into waiting for a decision and waiting for a vehicle, and rolling those back into one figure would throw away the decomposition that subsystem exists to provide.

Two rows that mean two things are better than one row that means either, so each paradigm publishes its own and neither inherits the other's. That is the whole of the difference, and the smallness of it is the point: the paradigms differ in how work is asked for, not in how a vehicle crosses a zone.

Compatibility

Nothing about this type's construction, name or reported rows changed when the space layer was lifted out of it. A model that said GuidedPathTransportSystem(this, network, name = "Sys") before says it now, and its report carries the same rows under the same names.

Parameters