Times are UTC Toggle Colours
00:35:15 *** Supercheese has quit IRC 00:35:47 *** Supercheese has joined #openttd.dev 00:49:13 *** Supercheese has quit IRC 00:49:44 *** Supercheese has joined #openttd.dev 00:53:07 *** Supercheese has quit IRC 00:53:36 *** Supercheese has joined #openttd.dev 00:55:33 *** Supercheese has quit IRC 00:58:49 *** Supercheese has joined #openttd.dev 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 #openttd.dev 02:34:00 *** Supercheese has quit IRC 02:34:29 *** Supercheese has joined #openttd.dev 02:38:08 *** Supercheese has quit IRC 02:38:37 *** Supercheese has joined #openttd.dev 03:06:11 *** Supercheese has quit IRC 03:06:40 *** Supercheese has joined #openttd.dev 03:10:00 *** Supercheese has quit IRC 03:10:30 *** Supercheese has joined #openttd.dev 03:30:58 *** Supercheese has quit IRC 03:31:29 *** Supercheese has joined #openttd.dev 03:33:26 *** Supercheese has quit IRC 06:31:54 *** Supercheese has joined #openttd.dev 09:46:46 *** Alberth has joined #openttd.dev 09:46:46 *** ChanServ sets mode: +v Alberth 10:07:07 *** Zuu has joined #openttd.dev 10:07:07 *** ChanServ sets mode: +v Zuu 10:26:04 *** FLHerne has joined #openttd.dev 11:12:20 *** FLHerne has quit IRC 11:12:40 *** FLHerne has joined #openttd.dev 11:51:28 *** frosch123 has joined #openttd.dev 11:51:29 *** ChanServ sets mode: +v frosch123 12:31:01 *** Supercheese has quit IRC 12:31:31 *** Supercheese has joined #openttd.dev 12:35:45 *** FLHerne has quit IRC 13:03:02 *** fonsinchen has joined #openttd.dev 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 http://www.tt-forums.net/viewtopic.php?f=33&t=63796&sid=bb09f3cf0a40db70e25c74204276958d#p1059910 and following for the full explanation. 13:11:10 <fonsinchen> Other than that I'm done with all the things you noted at http://rbijker.net/openttd/cd/. 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 #openttd.dev 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: http://webster.openttdcoop.org/?channel=openttd.dev || 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: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 19:18:20 *** dadymax has joined #openttd.dev 19:32:04 *** dadymax has left #openttd.dev 20:36:53 *** Alberth has left #openttd.dev 22:01:48 *** Supercheese has quit IRC 22:02:19 *** Supercheese has joined #openttd.dev 22:31:50 *** Supercheese has quit IRC 22:32:19 *** Supercheese has joined #openttd.dev 22:35:16 *** Supercheese has quit IRC 22:35:45 *** Supercheese has joined #openttd.dev 22:55:26 *** Supercheese has quit IRC 22:55:56 *** Supercheese has joined #openttd.dev 22:57:23 *** frosch123 has quit IRC 23:05:38 *** Supercheese has quit IRC 23:06:08 *** Supercheese has joined #openttd.dev 23:10:27 *** Supercheese has quit IRC 23:10:57 *** Supercheese has joined #openttd.dev