frosch wrote:I discussed some things with Zuu last month:
Exposing cargo flows is not a problem, I just have to wrap the FlowStat thing into an API. Exposing link capacities isn't a problem either. They're right there in the link graph.
Generally AIs are interested in detecting overloaded/underloaded links. While GS are rather interested in the routes.
Both are interested in the vehicles involved.
For GS I am in particulary looking for a method to track what routes cargo takes, and which vehicles serve those routes.
- Planned flows from/to a station (next hop only). Something like:
- GSStationList_NextHop(StationID, CargoID) returning a list/map: station id -> planned flow
- GSStationList_PreviousHop(StationID, CargoID) returning a list/map: station id -> planned flow
Next hop is fairly cheap, previous hop requires looping over the nodes in the link graph to figure out which ones have a link to the requested station. Both aren't difficult to implement.
Wrt. multiple hops, I think scripts can traverse the graph themself.
[*]Vehicles involved in a route between two stations (distance = one hop). Something like:
- GSVehicleList_Link(StationID, StationID, CargoID) returning a list/map: vehicle id -> ???? (capacity? expected usage?)
[/list]
This is possible but pretty expensive. We have to loop over all order lists, examine each one for a pair of matching orders (with all the fun about conditionals and depot stops and whatnot), and if found add all the vehicles following that order list to the returned map. Capacity or expected usage doesn't make much sense for single vehicles. The capacity of a link has no direct connection to the capacity of a vehicle, so I'd explicitly not expose vehicle capacity there as that will only confuse people.
For AIs: Would it be possible to ask for the expected flow before a station is constructed? As in: If I build a connection from existing station X to tile Y, how many passengers are expected per month? (effectively evaluating demand and distance and putting them into relation to the existing link graph)
That requires the simulation of a link graph job with certain modifications. It's definitely an interesting idea, but I'd leave that for later. Running link graph jobs is too expensive to do inline in the script, so the script would need some way to asynchronously trigger it and then get callbacks at certain stages where it could examine or modify the state of the link graph job. That would be totally awesome, of course, but also quite a bit of work.
Wrt. your suggestions:
ID of the link graph a station is part of for a certain cargo
How permanent would such an ID be? Do they change meaning every calculation?
Since scripts do not exactly know when they are suspended, it may be easier to address connected graph components only indirectly via one of StationIDs of their members.
The IDs only change if two link graphs are merged. We could notify the script about that.
Should we define some events, too? E.g. "distribution updated" for a certain link graph.
I think events are quite useless. They are not saved in savegames, so are not usable for state updates. They can only be used to trigger some update while the script is idling otherwise. But IMHO scripts never idle.
So how do we do notifications? What happens if an AI's truck is overrun by a train? Does the AI get some callback for that? Or is it just constantly polling all vehicles?
In general, I'd provide the above methods and some additional ones that are computationally cheap and still make sense (for example capacity of a link, given two station IDs). Then I'd add some information on the complexity of those methods to the documentation.
The guy on the picture is not me, it's Alonso.