Log for on 14th January 2013:
Times are UTC Toggle Colours
02:55:42  *** Supercheese has quit IRC
02:57:35  *** Supercheese has joined
07:32:58  *** Supercheese has left
17:18:50  *** frosch123 has joined
17:18:50  *** ChanServ sets mode: +v frosch123
17:28:06  *** ntoskrnl has joined
18:44:26  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r24914 || Logs: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
20:17:30  *** Supercheese has joined
20:24:11  *** ntoskrnl has quit IRC
21:15:53  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r24915 || Logs: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
21:34:28  *** fonsinchen has joined
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

Powered by YARRSTE version: svn-trunk