IRC logs for #openttd.dev on OFTC at 2013-01-05
⏴ go to previous day
00:36:42 *** Supercheese has joined #openttd.dev
00:50:39 *** Supercheese has joined #openttd.dev
00:54:31 *** Supercheese has joined #openttd.dev
00:59:44 *** Supercheese has joined #openttd.dev
02:28:29 *** Supercheese has joined #openttd.dev
02:35:24 *** Supercheese has joined #openttd.dev
02:39:32 *** Supercheese has joined #openttd.dev
03:07:35 *** Supercheese has joined #openttd.dev
03:11:25 *** Supercheese has joined #openttd.dev
03:32:24 *** Supercheese has joined #openttd.dev
06:32:49 *** Supercheese has joined #openttd.dev
09:47:41 *** Alberth has joined #openttd.dev
09:47:41 *** ChanServ sets mode: +v Alberth
10:08:02 *** Zuu has joined #openttd.dev
10:26:59 *** FLHerne has joined #openttd.dev
11:13:35 *** FLHerne has joined #openttd.dev
11:52:24 *** frosch123 has joined #openttd.dev
11:52:24 *** ChanServ sets mode: +v frosch123
12:32:27 *** Supercheese has joined #openttd.dev
13:03:57 *** fonsinchen has joined #openttd.dev
13:03:57 *** ChanServ sets mode: +v fonsinchen
13:06:33 <fonsinchen> Rubidium: What do you think about the cargodist loading problem?
13:07:07 <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:08:13 <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:08:31 <fonsinchen> (except for #5435 being fixed)
13:12:05 <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:17:18 <planetmaker> fonsinchen, can you describe briefly the difference and the reason to change?
13:17:30 <planetmaker> (sorry, I didn't read everything)
13:17:43 <planetmaker> ah, well, the link will tell?
13:22:10 <fonsinchen> The link has a very detailed description of the problem
13:23:13 <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:23:27 <fonsinchen> (first X will be completely filled then)
13:25:47 <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:32:14 <fonsinchen> That is the behaviour with "cd".
13:32:22 <fonsinchen> trunk's behaviour is different
13:32:28 <fonsinchen> it loads all wagons in parallel
13:33:08 <fonsinchen> I mimic that the balancing algorithm in "reserve", but autorefit of course gets an exception
13:33:51 <fonsinchen> ^with the balancing algorithm
13:34:25 <fonsinchen> Personally I also think the balancing algorithm is not worth it.
13:36:19 <fonsinchen> cd leaves #5435 unfixed, but I can probably port the fix and still disable the balancing.
13:42:45 <planetmaker> hm, thanks. I'll need to read more code there :-)
13:43:23 <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:44:19 <planetmaker> it could always start filling the first, 2nd, 3rd etc
13:44:26 <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:44:33 <planetmaker> why would you want to differ? Just the (possible) amount of cargo loaded differs
13:44:44 <planetmaker> i.e. the waiting time
13:45:00 <fonsinchen> because parallel loading is a little bit faster than serial loading
13:45:18 <planetmaker> yes... that's what improved / gradual loading does, iirc
13:45:21 <fonsinchen> (not really serial, but I think you know what I mean)
13:46:05 <fonsinchen> improved loading will reserve cargo so that other vehicles/consists don't "steal" it.
13:46:26 <fonsinchen> gradual loading divides the cargo in chunks and loads them one by one instead of loading all possible cargo at once.
13:46:34 <planetmaker> ah, that's it. yes. It should always be on, imho. could be removed really
13:46:46 <planetmaker> and that could also be on :D
13:47:21 <fonsinchen> Removing those two options would make the code in LoadUnloadVehicle a lot simpler
13:47:35 <fonsinchen> That could be a great benefit to anyone trying to understand or change it.
13:48:55 <Rubidium> I fear removing the "improved loading" setting will be troublesome for quite a few
13:49:08 <Rubidium> mostly because it improves the throughput of a high throughput station
13:50:01 <Rubidium> where there is so many incoming cargo that trains, during gradual loading, will (almost) never see an empty platform
13:50:27 <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:57 <fonsinchen> Do you mean removing it, fixing it to "on" or fixing it to "off"?
13:51:29 <Rubidium> turning it off improves the performance in the above case
13:52:33 <fonsinchen> Then we should keep it.
13:53:02 <fonsinchen> That question is unrelated to the previous one anyway.
13:53:13 <Rubidium> but a lot will want it turned on because then the behaviour is much better with lower throughput stations
13:55:23 <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:56:07 <fonsinchen> Let's stick to "manual distribution" for now.
13:56:21 <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:56:44 <fonsinchen> In the order they get empty.
13:57:05 <fonsinchen> Which is the same behaviour as in trunk (you cannot load and unload a wagon at the same time)
13:57:47 <fonsinchen> In trunk however, typically the wagons all unload the same amount so they all get ready for loading at the same time.
13:58:10 <fonsinchen> And you reserve cargo in those ticks you're not loading, even if the vehicle is only unloading
13:58:18 <fonsinchen> (which is inconsistent, btw)
14:00:09 <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:04:06 <fonsinchen> Did you understand that or shall I elaborate some?
14:06:04 <Zuu> Just a question, can multiple cargo packets with different destinations co-exist in the same wagon?
14:08:05 <Rubidium> fonsinchen: it's clear to me
17:20:36 *** fonsinchen has joined #openttd.dev
17:20:36 *** ChanServ sets mode: +v fonsinchen
19:19:16 *** dadymax has joined #openttd.dev
19:33:00 *** dadymax has left #openttd.dev
20:37:49 *** Alberth has left #openttd.dev
22:03:15 *** Supercheese has joined #openttd.dev
22:33:15 *** Supercheese has joined #openttd.dev
22:36:41 *** Supercheese has joined #openttd.dev
22:56:51 *** Supercheese has joined #openttd.dev
23:07:04 *** Supercheese has joined #openttd.dev
23:11:52 *** Supercheese has joined #openttd.dev
continue to next day ⏵