Log for on 5th January 2013:
Times are UTC Toggle Colours
00:35:15  *** Supercheese has quit IRC
00:35:47  *** Supercheese has joined
00:49:13  *** Supercheese has quit IRC
00:49:44  *** Supercheese has joined
00:53:07  *** Supercheese has quit IRC
00:53:36  *** Supercheese has joined
00:55:33  *** Supercheese has quit IRC
00:58:49  *** Supercheese has joined
01:43:15  *** Zuu has quit IRC
01:48:15  *** FLHerne has quit IRC
02:27:04  *** Supercheese has quit IRC
02:27:34  *** Supercheese has joined
02:34:00  *** Supercheese has quit IRC
02:34:29  *** Supercheese has joined
02:38:08  *** Supercheese has quit IRC
02:38:37  *** Supercheese has joined
03:06:11  *** Supercheese has quit IRC
03:06:40  *** Supercheese has joined
03:10:00  *** Supercheese has quit IRC
03:10:30  *** Supercheese has joined
03:30:58  *** Supercheese has quit IRC
03:31:29  *** Supercheese has joined
03:33:26  *** Supercheese has quit IRC
06:31:54  *** Supercheese has joined
09:46:46  *** Alberth has joined
09:46:46  *** ChanServ sets mode: +v Alberth
10:07:07  *** Zuu has joined
10:07:07  *** ChanServ sets mode: +v Zuu
10:26:04  *** FLHerne has joined
11:12:20  *** FLHerne has quit IRC
11:12:40  *** FLHerne has joined
11:51:28  *** frosch123 has joined
11:51:29  *** ChanServ sets mode: +v frosch123
12:31:01  *** Supercheese has quit IRC
12:31:31  *** Supercheese has joined
12:35:45  *** FLHerne has quit IRC
13:03:02  *** fonsinchen has joined
13:03:02  *** ChanServ sets mode: +v fonsinchen
13:05:38  <fonsinchen> Rubidium: What do you think about the cargodist loading problem?
13:06:12  <fonsinchen> I can either keep it as it is, which is slightly different than what trunk does or I can switch to the new "reserve" branch.
13:07:18  <fonsinchen> The new algorithm has some overhead, and is not as thoroughly tested, but there's hardly a difference to trunk in how cargo is assigned to wagons of a consist.
13:07:36  <fonsinchen> (except for #5435 being fixed)
13:08:58  <fonsinchen> see also and following for the full explanation.
13:11:10  <fonsinchen> Other than that I'm done with all the things you noted at Sorry for all the capitalization stuff. I didn't realize that was part of the coding standard.
13:16:23  <planetmaker> fonsinchen, can you describe briefly the difference and the reason to change?
13:16:34  <planetmaker> (sorry, I didn't read everything)
13:16:47  <planetmaker> ah, well, the link will tell?
13:16:58  * planetmaker first reads
13:21:14  <fonsinchen> The link has a very detailed description of the problem
13:22:18  <fonsinchen> Basically the question is if it's acceptable that cargo is loaded only onto the first X parts of a consist instead of all if there is not enough cargo for all of them and full load is switched on.
13:22:32  <fonsinchen> (first X will be completely filled then)
13:24:51  <planetmaker> Wagons should be filled one after the other. Otherwise autorefit fails which is ugly. It even "fails" in trunk for one setting of gradual loading.
13:31:18  <fonsinchen> That is the behaviour with "cd".
13:31:26  <fonsinchen> trunk's behaviour is different
13:31:32  <fonsinchen> it loads all wagons in parallel
13:32:12  <fonsinchen> I mimic that the balancing algorithm in "reserve", but autorefit of course gets an exception
13:32:55  <fonsinchen> ^with the balancing algorithm
13:33:30  <fonsinchen> Personally I also think the balancing algorithm is not worth it.
13:35:24  <fonsinchen> cd leaves #5435 unfixed, but I can probably port the fix and still disable the balancing.
13:41:49  <planetmaker> hm, thanks. I'll need to read more code there :-)
13:42:28  <fonsinchen> I think that statement about wagons being filled one after the other is too broad. You probably want to make a difference between full and non-full load, don't you?
13:43:12  <planetmaker> not really
13:43:23  <planetmaker> it could always start filling the first, 2nd, 3rd etc
13:43:30  <fonsinchen> Basically with cargodist I have the option to choose between no reservation, fill one by one and fill in parallel for any kind of setting/order combination. I'm awaiting your wish list ;)
13:43:38  <planetmaker> why would you want to differ? Just the (possible) amount of cargo loaded differs
13:43:48  <planetmaker> i.e. the waiting time
13:44:05  <fonsinchen> because parallel loading is a little bit faster than serial loading
13:44:23  <planetmaker> yes... that's what improved / gradual loading does, iirc
13:44:25  <fonsinchen> (not really serial, but I think you know what I mean)
13:44:29  <planetmaker> yes
13:45:09  <fonsinchen> improved loading will reserve cargo so that other vehicles/consists don't "steal" it.
13:45:31  <fonsinchen> gradual loading divides the cargo in chunks and loads them one by one instead of loading all possible cargo at once.
13:45:39  <planetmaker> ah, that's it. yes. It should always be on, imho. could be removed really
13:45:51  <planetmaker> and that could also be on :D
13:46:25  <fonsinchen> Removing those two options would make the code in LoadUnloadVehicle a lot simpler
13:46:39  <fonsinchen> That could be a great benefit to anyone trying to understand or change it.
13:48:00  <Rubidium> I fear removing the "improved loading" setting will be troublesome for quite a few
13:48:12  <Rubidium> mostly because it improves the throughput of a high throughput station
13:49:05  <Rubidium> where there is so many incoming cargo that trains, during gradual loading, will (almost) never see an empty platform
13:49:32  <Rubidium> reserving in this case will just make empty trains wait, and the amount of waiting cargo always remains higher than it could be
13:50:01  <fonsinchen> Do you mean removing it, fixing it to "on" or fixing it to "off"?
13:50:33  <Rubidium> turning it off improves the performance in the above case
13:50:50  <planetmaker> sorry, bbl :S
13:51:37  <fonsinchen> Then we should keep it.
13:52:07  <fonsinchen> That question is unrelated to the previous one anyway.
13:52:18  <Rubidium> but a lot will want it turned on because then the behaviour is much better with lower throughput stations
13:54:28  <Rubidium> the original question is somewhat related though... when spreading the cargo over the whole consist, loading and unloading can be faster... although with cargodist I could imagine this not being really true anymore since not all cargo will be offloaded anymore
13:55:11  <fonsinchen> Let's stick to "manual distribution" for now.
13:55:26  <Rubidium> however... the question is then... will you fill the wagons in the order they are in the consist or in the order they become "empty" (i.e. stopped unloading)
13:55:49  <fonsinchen> In the order they get empty.
13:56:10  <fonsinchen> Which is the same behaviour as in trunk (you cannot load and unload a wagon at the same time)
13:56:52  <fonsinchen> In trunk however, typically the wagons all unload the same amount so they all get ready for loading at the same time.
13:57:15  <fonsinchen> And you reserve cargo in those ticks you're not loading, even if the vehicle is only unloading
13:57:23  <fonsinchen> (which is inconsistent, btw)
13:59:13  <fonsinchen> I haven't actually changed anything about that. I though that it's acceptable to slightly change the inconsistent behaviour from trunk to different inconsistency. See the long comment in ReserveConsist about that.
14:03:10  <fonsinchen> Did you understand that or shall I elaborate some?
14:05:09  <Zuu> Just a question, can multiple cargo packets with different destinations co-exist in the same wagon?
14:05:24  <Rubidium> yes
14:07:10  <Rubidium> fonsinchen: it's clear to me
15:47:24  *** fonsinchen has quit IRC
17:19:41  *** fonsinchen has joined
17:19:41  *** ChanServ sets mode: +v fonsinchen
18:05:49  *** fonsinchen has quit IRC
18:45:19  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r24887 || Logs: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
18:51:11  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r24888 || Logs: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
19:18:20  *** dadymax has joined
19:32:04  *** dadymax has left
20:36:53  *** Alberth has left
22:01:48  *** Supercheese has quit IRC
22:02:19  *** Supercheese has joined
22:31:50  *** Supercheese has quit IRC
22:32:19  *** Supercheese has joined
22:35:16  *** Supercheese has quit IRC
22:35:45  *** Supercheese has joined
22:55:26  *** Supercheese has quit IRC
22:55:56  *** Supercheese has joined
22:57:23  *** frosch123 has quit IRC
23:05:38  *** Supercheese has quit IRC
23:06:08  *** Supercheese has joined
23:10:27  *** Supercheese has quit IRC
23:10:57  *** Supercheese has joined

Powered by YARRSTE version: svn-trunk