Times are UTC Toggle Colours
02:32:29 *** Supercheese has joined #openttd.dev 02:32:29 *** 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:31:31 *** Supercheese has quit IRC 12:32:07 *** Supercheese has joined #openttd.dev 12:32:07 *** ChanServ sets mode: +v Supercheese 12:42:43 *** adf88 has quit IRC 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:37:54 *** adf88 has quit IRC 13:43:21 *** frosch123 has joined #openttd.dev 13:43:21 *** ChanServ sets mode: +v frosch123 14:34:06 <fonsinchen> Good idea 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:23 <fonsinchen> https://github.com/ulfhermann/openttd/commits/fixes2 15:37:34 <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:24 <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:18 <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:55 <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? 15:57:49 <fonsinchen> true 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:08 <fonsinchen> ^outcome 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:26:39 *** adf89 has quit IRC 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. 18:45:12 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26264 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 19:57:51 *** adf88 has joined #openttd.dev 19:57:51 *** ChanServ sets mode: +v adf88 22:35:11 *** Alberth has left #openttd.dev