IRC logs for #openttd.dev on OFTC at 2013-01-14
⏴ go to previous day
02:58:38 *** Supercheese has joined #openttd.dev
07:34:02 *** Supercheese has left #openttd.dev
17:19:54 *** frosch123 has joined #openttd.dev
17:19:54 *** ChanServ sets mode: +v frosch123
17:29:09 *** ntoskrnl has joined #openttd.dev
20:18:34 *** Supercheese has joined #openttd.dev
21:35:32 *** fonsinchen has joined #openttd.dev
21:35:32 *** ChanServ sets mode: +v fonsinchen
21:37:09 <fonsinchen> One more time about the loading algorithm. I've found a way to cleanly implement reservation ...
21:37:21 <fonsinchen> However, there's that issue of balancing.
21:38:04 <fonsinchen> If you have a consist that full loads with improved loading but without autorefit, it will load "balanced".
21:38:27 <fonsinchen> That means each vehicle in the consist will get roughly the same amount of cargo in each round.
21:39:38 <fonsinchen> With reservation I prefer a "greedy" behaviour where each vehicle in the consist is filled before the next one gets cargo.
21:40:00 <fonsinchen> (of course vehicles will still be loaded in parallel if there is enough cargo)
21:40:23 <frosch123> didn't we already settle for that?
21:40:50 <frosch123> i thought the conclusion was to always load like autorefit does now
21:41:04 <fonsinchen> That would indeed be nice
21:41:13 <frosch123> didn't you even post a patch at fs? :p
21:41:30 <frosch123> sorry, i was not able to look at them in detail
21:41:31 <fonsinchen> No, those two patches of last week were about other things.
21:43:18 <fonsinchen> I actually have an algorithm that does artificial balancing efficiently, but that's such a big chunk of code for so little effect ...
21:43:34 <fonsinchen> I'd like to kick it out.
21:44:22 <fonsinchen> If I have to keep it though, I'd actually implement normal loading with that algorithm, too, to reduce code duplication.
21:44:43 <fonsinchen> That should be decided upon.
22:04:35 <fonsinchen> We didn't really decide on that in the discussion of 5th January.
22:05:36 <fonsinchen> Rubidium mentioned the problem with loading speed.
22:05:59 <fonsinchen> My answer to that was somewhat incorrect, though.
22:06:19 <fonsinchen> With the new reservation algorithm I can _reserve_ cargo before unloading finishes.
22:06:30 <fonsinchen> I still cannot _load_ it, though.
22:08:16 <fonsinchen> This is indeed the same as with trunk then. The behaviour in trunk isn't really inconsistent, except for #5436 and #5438.
22:08:50 <fonsinchen> And all of that is not related to the original question.
22:09:14 <fonsinchen> The question can be phrased in very short words:
22:10:05 <fonsinchen> Is it OK to not load all vehicles of a full loading consist (with improved loading) in parallel to reduce code complexity and keep cargo packets together?
22:13:29 <frosch123> i do not understand that question
22:13:54 <frosch123> i know the loading algorithm only from memory
22:14:15 <frosch123> but what i remember from the discussion was, that it is ok to "virtually move" packets on the consist
22:14:30 <frosch123> and only splitting them when loading is aborted
22:14:43 <fonsinchen> Yes, that's the basic precondition of any persistent reservation.
22:14:49 <fonsinchen> The problem now is as follows:
22:15:30 <fonsinchen> Normally if you have a full load order and improved loading and there is not enough cargo in the station the cargo will still be split over all parts of the consist.
22:16:01 <fonsinchen> I'd like to change that so that the first vehicles will be filled and the last ones will be empty.
22:16:08 <frosch123> you mean the "always load like autorefit" part again?
22:16:22 <fonsinchen> all the time actually.
22:16:43 <fonsinchen> Do you have a link to the discussion where you think we decided upon that?
22:17:00 <frosch123> well, as I said; from my POV that is ok. rb might have had another opinion
22:17:30 <frosch123> but I think the loading time is not a good argument, since it only matters if there is no cargo waiting at all
22:17:39 <frosch123> while it goes to normal once there is a bit cargo waiting
22:18:12 <fonsinchen> once there is enough to fill all the consist, actually
continue to next day ⏵