Times are UTC Toggle Colours
02:55:42 *** Supercheese has quit IRC 02:57:35 *** Supercheese has joined #openttd.dev 07:32:58 *** Supercheese has left #openttd.dev 17:18:50 *** frosch123 has joined #openttd.dev 17:18:50 *** ChanServ sets mode: +v frosch123 17:28:06 *** ntoskrnl has joined #openttd.dev 18:44:26 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r24914 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 20:17:30 *** Supercheese has joined #openttd.dev 20:24:11 *** ntoskrnl has quit IRC 21:15:53 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r24915 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 21:34:28 *** fonsinchen has joined #openttd.dev 21:34:28 *** ChanServ sets mode: +v fonsinchen 21:34:46 <fonsinchen> Hi 21:36:05 <fonsinchen> One more time about the loading algorithm. I've found a way to cleanly implement reservation ... 21:36:17 <fonsinchen> However, there's that issue of balancing. 21:37:00 <fonsinchen> If you have a consist that full loads with improved loading but without autorefit, it will load "balanced". 21:37:23 <fonsinchen> That means each vehicle in the consist will get roughly the same amount of cargo in each round. 21:38:34 <fonsinchen> With reservation I prefer a "greedy" behaviour where each vehicle in the consist is filled before the next one gets cargo. 21:38:57 <fonsinchen> (of course vehicles will still be loaded in parallel if there is enough cargo) 21:39:19 <frosch123> didn't we already settle for that? 21:39:32 <fonsinchen> Did we? 21:39:47 <frosch123> i thought the conclusion was to always load like autorefit does now 21:40:00 <fonsinchen> That would indeed be nice 21:40:09 <frosch123> didn't you even post a patch at fs? :p 21:40:26 <frosch123> sorry, i was not able to look at them in detail 21:40:27 <fonsinchen> No, those two patches of last week were about other things. 21:42:14 <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:42:30 <fonsinchen> I'd like to kick it out. 21:43:18 <fonsinchen> If I have to keep it though, I'd actually implement normal loading with that algorithm, too, to reduce code duplication. 21:43:39 <fonsinchen> That should be decided upon. 22:03:31 <fonsinchen> We didn't really decide on that in the discussion of 5th January. 22:04:32 <fonsinchen> Rubidium mentioned the problem with loading speed. 22:04:55 <fonsinchen> My answer to that was somewhat incorrect, though. 22:05:16 <fonsinchen> With the new reservation algorithm I can _reserve_ cargo before unloading finishes. 22:05:26 <fonsinchen> I still cannot _load_ it, though. 22:07:12 <fonsinchen> This is indeed the same as with trunk then. The behaviour in trunk isn't really inconsistent, except for #5436 and #5438. 22:07:46 <fonsinchen> And all of that is not related to the original question. 22:08:10 <fonsinchen> The question can be phrased in very short words: 22:09:01 <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:12:26 <frosch123> i do not understand that question 22:12:50 <frosch123> i know the loading algorithm only from memory 22:13:12 <frosch123> but what i remember from the discussion was, that it is ok to "virtually move" packets on the consist 22:13:26 <frosch123> and only splitting them when loading is aborted 22:13:39 <fonsinchen> Yes, that's the basic precondition of any persistent reservation. 22:13:45 <fonsinchen> The problem now is as follows: 22:14:26 <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:14:57 <fonsinchen> I'd like to change that so that the first vehicles will be filled and the last ones will be empty. 22:15:04 <frosch123> you mean the "always load like autorefit" part again? 22:15:12 <fonsinchen> yes 22:15:18 <fonsinchen> all the time actually. 22:15:39 <fonsinchen> Do you have a link to the discussion where you think we decided upon that? 22:15:56 <frosch123> well, as I said; from my POV that is ok. rb might have had another opinion 22:16:27 <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:16:36 <frosch123> while it goes to normal once there is a bit cargo waiting 22:17:08 <fonsinchen> once there is enough to fill all the consist, actually 22:17:15 <fonsinchen> but I agree 22:27:09 <frosch123> night 22:27:13 *** frosch123 has quit IRC 22:54:04 *** fonsinchen has quit IRC