Log for on 9th March 2014:
Times are UTC Toggle Colours
00:10:11  *** planetmaker is now known as planetmaker|Fjordmaking
00:10:53  *** planetmaker|Fjordmaking is now known as planetmaker
01:24:36  *** frosch_awake has quit IRC
08:54:36  *** Knogle has quit IRC
09:03:13  *** Knogle has joined
10:09:26  *** michi_cc has quit IRC
10:16:33  *** Zuu has joined
10:16:33  *** ChanServ sets mode: +v Zuu
10:17:03  *** michi_cc has joined
10:17:03  *** ChanServ sets mode: +v michi_cc
10:18:16  <Zuu> Does anyone know if there is an easy way to get the to/via/from cargo amounts for a specific station to/via/from another station? I started on some AI/GS APIs to get this information:
10:18:26  <Zuu> See script_station.cpp in this file
10:19:53  <Zuu> fonsinchen ?
10:24:28  <Zuu> From what I can see, the station window use some cache of destinations etc. so creating an API to just get little bits of data at each time may be bad design from performance perspective. Eg. it may be necessary to expose some object that represent the cache which AIs can create, make their queries and then dispose.
10:42:48  <Zuu> ACTION was trying to create a PAXLink update that omits the order feeder order flags  when cargodist is enabled. However, it needs some way to filter the waiting cargo at the inter city station for only passengers going to the remote town. Currently if an IC station has too many waiting passengers, it will first try to improve the aircraft service and if thats not possible, reduce the feeder service. With cargodist many pasengers waiting to use the feeder serv
11:20:48  *** Knogle has joined
11:25:15  *** Alberth has joined
11:25:15  *** ChanServ sets mode: +v Alberth
12:18:51  *** frosch123 has joined
12:18:51  *** ChanServ sets mode: +v frosch123
12:30:42  *** Supercheese has quit IRC
12:31:16  *** Supercheese has joined
12:31:16  *** ChanServ sets mode: +v Supercheese
12:52:41  <frosch123> Zuu: shouldn't there rather be some ai lists?
12:53:31  <frosch123> you give a station id, and you get a lists of (next-hop-station id, amount), (final-destination-station id, amount), (source-station id, amount), ...
12:56:05  <frosch123> maybe even let the script specify source and destination staiton id and cargo type, and return a list of all stations and amounts which have cargo for that route
12:56:28  <frosch123> that would allow some interesting cargo glow analysis for gamescripts
12:56:33  <frosch123> *flow
12:57:30  <frosch123> or return a list of vehicles operating cargo for a certain connection
13:24:59  <Zuu> Yes, some lists may be useful. I was just needing only this right now and went for what I thought a simple solution but didn't then find out how to quickly get the numbers displayed in the GUI.
13:26:31  <Zuu> However, with lists, if the AI need more information than just one item in the list, the performance is probably better than my patch idea, unless there is a cache somewhere with this information readily available.
13:45:40  <frosch123> i think you need to look at BuildCargoList
13:45:46  <frosch123> station_gui.cpp:1563
13:46:50  <frosch123> resp :1596
13:48:02  <frosch123> there is a cache per window, which is cleared via OnInvalidateData
13:48:19  <frosch123> so, i guess the only thing you can do for scripts is return the whole list
13:48:23  <frosch123> and let the script cache it itself
16:24:29  *** Alberth has left
16:38:08  *** Knogle has quit IRC
16:38:28  *** Knogle has joined
18:45:20  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26395 || Logs: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
19:21:37  *** Alberth has joined
19:21:37  *** ChanServ sets mode: +v Alberth
21:59:00  <fonsinchen> Zuu: You should interact with either the link graph itself or the flow stats
21:59:37  <fonsinchen> The flow stats tell you the planned monthly amount of cargo from and via stations at each station
22:00:17  <Zuu> The principle of the AI framework is to offer the same data as human get. So the answer to that question should in general be whatever the GUI is using.
22:00:42  <fonsinchen> The human gets only an estimation when it comes to waiting passengers "to"
22:00:59  <fonsinchen> You can read the via and from values from the cargo lists, though.
22:01:05  <Zuu> Am I right that "to" is final destination and "via" is next hop?
22:01:10  <fonsinchen> Yes
22:03:06  <fonsinchen> The whole caching in the station window is just because of the special way the data is displayed there.
22:03:18  <fonsinchen> You shouldn't base the AI API on that.
22:04:17  <Zuu> So, it is somewhat quick to get both from, via and to for a pair of two stations?
22:04:40  <fonsinchen> This is a more complcated question than you think.
22:04:48  <fonsinchen> there are actually 6 cases:
22:05:29  <fonsinchen> 1. planned flow "from", 2. planned flow "via", 3. planned flow "to", 4., 5., 6. the same for waiting cargo.
22:05:39  <fonsinchen> Do you understand the differences so far?
22:06:25  <Zuu> Hmm.. I think Waiting is what I was planing to expose.
22:06:55  <fonsinchen> You want to expose all of the "from" and "via" and none of the "to" I think.
22:06:57  <Zuu> Eg. those X, waiting at my station, how can I split them into sub groups.
22:07:30  <fonsinchen> The StationCargoList is actually a multimap
22:07:40  <fonsinchen> the keys are the "via" stations
22:07:46  <Zuu> Oh, yes there is also the none group that needs some care.
22:07:58  <fonsinchen> each cargo packet has a "from" field
22:08:05  *** Alberth has left
22:08:28  <fonsinchen> keys of FlowStatMap are the "from" entries for planned flow
22:09:16  <fonsinchen> "via" is more complicated for planned but you can get it via GetShare()
22:09:29  <fonsinchen> Plans are monthly
22:10:10  <fonsinchen> "To" is never accurate because the plan might be changed before the cargo arrives at the next station
22:10:25  <fonsinchen> That's why I wouldn't expose it.
22:10:38  <Zuu> For a first step I'll only focus on waiting. Though, I'm sure some AI authors will find planned to be useful too. But it needs a check with the GUI to not expose too detailed data to AIs.
22:11:56  <frosch123> i guess ais are interested in via for waiting
22:12:27  <frosch123> while gs would rather be interested in from
22:12:54  <Zuu> Via for waiting will be enough for my AI I think. Without it it is hard to support cargodist. Further data may be useful but not essential for AIs.
22:14:09  <frosch123> "from" as in both "waiting" and "planned"
22:14:55  <frosch123> a gs would also be mostly interested in a list
22:15:11  <frosch123> i guess your ai uses the individual queries because it iterator over your vehicle orders?
22:15:53  <Zuu> I have started with your list idea.
22:16:44  <fonsinchen> The CargoList interface is pretty barren in that regard. It could probably do with some handy accessors like "GetSumCargoVia" or similar.
22:18:06  <Zuu> My AI have a quite simple network structure. Actually many networks. Each network has at most one airport with bus stops and a local bus line that visit 1 or more stops in town and then the airport bus stop. So the PAXLink AI only need to get the count via the other airport to get waiting on aircraft vs waiting on local bus.
22:19:17  <Zuu> Ehrm, each network has at most 2 airports in two different towns. Each supplyed localy by bus.
22:21:18  <Zuu> ChooChoo uses buses the same way, but has trains connecting different stations in a more network fashon. It will still know the set of all train stations. So it can either iterate the list of train stations and make API calls or get the intersection of a list of via stations with an other AIList.
22:21:49  <frosch123> Zuu: maybe give the list thingie not such a high priority
22:22:28  <frosch123> there are definitely diferent goals for ais and gs here
22:23:10  <frosch123> i just wondered about extending the cargomonitor stuff to locate cargopackets on the map
22:23:29  <frosch123> like querying all stations and vehicles holding cargo from a specific source
22:23:41  <Zuu> I was just going to say that GS got cargomonitor. Maybe it is possible to extend it with respect to cargodist.
22:24:00  <frosch123> well, the info i am referring to does not even depend on cdist
22:24:18  <Zuu> That is even better (for GS authors)
22:24:37  <frosch123> my goal was rather to somehow get information about the route cargo takes, and which vehicles are involved
22:24:43  <frosch123> but that is not cdist specific
22:25:20  <frosch123> cdist only gets involved for planned stuff, but i see no relevance for gs about that
22:34:08  <Zuu> So if my API addition GetCargoWaitingVia(station_id, via_station_id, cargo_type) is only reading actually waiting cargo, it doesn't need to have non-manual distribution as @pre ?
22:34:41  <frosch123> huh?
22:35:21  <frosch123> "via" and "to" needs cdist and "planned from", "waiting from" does not
22:35:38  <Zuu> Then I was wrong
22:35:42  <frosch123> "via" and "to" and "planned from" needs cdist, "waiting from" does not
22:35:51  <frosch123> inserted at wrong position :p
22:45:40  *** frosch123 has quit IRC
23:07:43  *** Zuu has quit IRC

Powered by YARRSTE version: svn-trunk