IRC logs for #openttd.dev on OFTC at 2014-01-18
⏴ go to previous day
02:32:28 *** Supercheese has joined #openttd.dev
02:32:28 *** ChanServ sets mode: +v Supercheese
08:00:09 *** adf88 has joined #openttd.dev
08:00:09 *** ChanServ sets mode: +v adf88
09:52:31 *** Alberth has joined #openttd.dev
09:52:31 *** ChanServ sets mode: +v Alberth
12:32:07 *** Supercheese has joined #openttd.dev
12:32:07 *** ChanServ sets mode: +v Supercheese
12:42:56 *** adf88 has joined #openttd.dev
12:42:56 *** ChanServ sets mode: +v adf88
13:37:18 *** adf89 has joined #openttd.dev
13:43:21 *** frosch123 has joined #openttd.dev
13:43:21 *** ChanServ sets mode: +v frosch123
15:11:44 <fonsinchen> I tend to leaving out the whole else clause in the OT_CONDITIONAL part of GetNextStoppingStation
15:12:04 <fonsinchen> We can just return both options in that case, too
15:13:13 <fonsinchen> Prediction based on current situation is flaky at best anyway
15:13:59 <fonsinchen> It's much easier to understand that a vehicle will always load cargo for all possibilities when facing a conditional order.
15:37:35 <fonsinchen> This time around it's actually correct.
15:42:10 <frosch123> why is "hops" not incremented when considering both skip_to and advance?
15:45:36 <fonsinchen> because then it returns directly
15:45:52 <fonsinchen> it is already incremented before the second loop
15:46:25 <fonsinchen> Most of the time next == first there
15:46:31 <fonsinchen> no need to waste another hop
15:46:42 <frosch123> oh, that '++hops' is quite hidden
15:47:05 <fonsinchen> technically we allow up to #orders * 2 hops like this, but that's tolerable
15:47:17 <fonsinchen> There's another thing that just came to my mind
15:47:32 <fonsinchen> I have to always consider both options when unloading, too.
15:47:44 <fonsinchen> Otherwise we'll get unbalanced unload/load
15:48:45 <fonsinchen> Which behaviour do you think is better?
15:49:08 <fonsinchen> Only load for both options if condition is based on load percentage or always load for both options?
15:49:19 <fonsinchen> (and unload accordingly)
15:50:49 <fonsinchen> People might use maximum speed for dividing cargo between destinations. It would be somewhat bad to always load for both options then
15:53:28 <frosch123> i would think people use speed and stuff only for waypoints to separate tracks, but not real destinations
15:54:39 <frosch123> load percentage would traditionally have been used to skip stations when already full or almost full; but that does not make sense if the skipped stations are potential unload stations
15:56:13 <frosch123> maybe consider "load percentage > constant" only for loading, and "load percentage < constant" for unloading?
15:56:36 <frosch123> skipping stations because load percentage is high makes sense if the vehicle won't be able to load much
15:56:53 <frosch123> skipping stations because load percentage is low makes sense if the vehicle won't be able to unload much
15:56:56 <fonsinchen> We don't want different conditions for loading and unloading because then vehicles will load the same cargo they've just unloaded
15:57:11 <fonsinchen> We had that with the coop cargodist test game.
15:57:30 <frosch123> hmm, so loading must be superset of unloading?
16:00:00 <fonsinchen> Actually as I use GetNextStoppingStation() in both cases I don't have to do anything to make sure the results are equal.
16:00:46 <fonsinchen> But if you have a better idea on how to deal with it I'll be happy to change the algorithm.
16:06:45 <fonsinchen> It's bad to ignore the > constant conditions for unloading because the load percentage might actually not be determined by the current load cycle at all.
16:07:13 <fonsinchen> There could be a train with 10 coal wagons and 2 engineering supply wagons.
16:07:52 <fonsinchen> When loading engineering supplies the output will be totally determined by the coal that was loaded before.
16:08:22 <frosch123> yeah, you can only blame that on whoever made those orders :p
16:09:23 <fonsinchen> I can easily imagine such a situation. They just want the supplies to be delivered as supplement to the coal to increase the steel production or sth.
16:35:44 <fonsinchen> So I guess I'll stick with the new behaviour after all. The predictability is more important than the fact that you get unexpected behaviour when selecting cargo destinations by vehicle speed.
19:57:51 *** adf88 has joined #openttd.dev
19:57:51 *** ChanServ sets mode: +v adf88
22:35:11 *** Alberth has left #openttd.dev
continue to next day ⏵