IRC logs for #openttd.dev on OFTC at 2014-09-19
⏴ go to previous day
00:11:14 *** Supercheese has joined #openttd.dev
00:11:14 *** ChanServ sets mode: +v Supercheese
11:31:53 *** Supercheese is now known as Guest203
11:31:57 *** Supercheese has joined #openttd.dev
11:31:57 *** ChanServ sets mode: +v Supercheese
15:11:45 *** Alberth has joined #openttd.dev
15:11:45 *** ChanServ sets mode: +v Alberth
16:38:32 *** kalenz__ has joined #openttd.dev
16:46:38 *** frosch123 has joined #openttd.dev
16:46:38 *** ChanServ sets mode: +v frosch123
18:07:37 <fonsinchen> expensive, but what can we do ...
18:08:38 <fonsinchen> We have to try all cargoes to figure out what we can refit to and then we have to predict links for all refittable cargoes
18:08:46 <fonsinchen> At least I don't see an alternative.
18:19:38 <Rubidium> does autorefit require the vehicle to be empty?
18:20:07 <Rubidium> can that be used to predict that nothing is going to be changed?
18:24:25 <Rubidium> I'm not quite getting the reason to clear IN_AUTOREFIT at line 265
18:25:31 <Rubidium> besides that the comments of HandleRefit are not updated
18:25:56 <Rubidium> I've got no idea how to really test as I never used autorefit; I barely used refts ;)
18:48:52 <Supercheese> I believe wagons must be empty before they can be autorefitted
18:50:24 <Alberth> IN_AUTOREFIT <-- comma after the last enum value
19:25:16 *** Alberth has left #openttd.dev
20:42:13 *** Belugas has joined #openttd.dev
20:42:13 *** ChanServ sets mode: +v Belugas
20:59:35 <fonsinchen> Sure they have to be empty, but this is about predicting stuff
20:59:54 <fonsinchen> you don't know if they're empty when they arrive at that stop
21:01:36 <fonsinchen> Rubidium, clearing the bit in 265 makes it do the refit theater again if the next order is another CT_AUTO_REFIT. That's intended.
21:01:50 <fonsinchen> If I didn't clear it it would only do it once for the whole order list.
21:02:51 <fonsinchen> Of course there are certain corner cases where you know that the vehicle is not empty, like with "full load all"
21:03:20 <fonsinchen> However, as refit doesn't make much sense there, it's not worth it to especially check for those.
21:05:25 <frosch123> would it be horrible to just assume that an autorefittable consist carries all refittable cargos in equal amounts? capacity 100 / 10 cargos -> 10 per cargo ?
21:06:18 <fonsinchen> Could be done, but how would that be better
21:06:24 <frosch123> or is there some way to estimate the relative cargo amounts within a network?
21:07:00 <fonsinchen> What are "relative cargo amounts within a network"?
21:07:04 <frosch123> maybe it would need less iteration
21:07:45 <fonsinchen> We'd still have to iterate all the cargoes to see which one we can refit to and the current solution keeps a cache of seen hops already
21:08:02 <fonsinchen> So, yes, marginally less iteration but I don't think it would make a difference in practice
21:08:03 <frosch123> considering all cargo sources: 10% of cargo is grain, 40% is coal, 50% is pax -> autorefittable bulk vehicles carry 20% grain, 80% coal
21:08:45 <fonsinchen> That does not tell us anything about the link we're trying to refresh
21:08:57 <fonsinchen> There might not be any coal there
21:09:53 <fonsinchen> On the other hand the vehicle could refit to full coal or full grain, so refreshing with full capacity for either is probably best.
21:15:55 <fonsinchen> With the "all cargoes at once" idea we'd remove iterating over orders but we'd add some iteration over the capacities and refit_capacities maps instead
22:38:32 *** nickolai has joined #openttd.dev
continue to next day ⏵