Config
Log for #openttd.dev on 9th January 2013:
Times are UTC Toggle Colours
08:10:57  *** Supercheese has quit IRC
13:54:57  *** ntoskrnl has joined #openttd.dev
14:06:24  *** Jasperthecat1 has joined #openttd.dev
14:06:49  *** Jasperthecat1 has left #openttd.dev
18:06:29  *** frosch123 has joined #openttd.dev
18:06:29  *** ChanServ sets mode: +v frosch123
18:24:00  *** Alberth has joined #openttd.dev
18:24:00  *** ChanServ sets mode: +v Alberth
18:44:35  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r24901 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
18:54:56  *** ntoskrnl has quit IRC
19:28:22  *** andythenorth has joined #openttd.dev
19:28:22  *** ChanServ sets mode: +v andythenorth
20:20:04  *** fonsinchen has joined #openttd.dev
20:20:04  *** ChanServ sets mode: +v fonsinchen
20:25:48  *** Alberth has left #openttd.dev
21:17:28  <fonsinchen> Is there a reason why you don't get transfer credits for force-unloading cargo at its origin station?
21:17:51  <fonsinchen> I mean, the other legs of the journey already got transfer credits, too ...
21:19:22  <Rubidium> not really I'd reckon
21:19:31  <planetmaker> if you unload it where it started you didn't achieve anything, did you?
21:19:58  <Rubidium> planetmaker: but moving it from A -> B -> C yields transfer credits, just C -> A not
21:19:59  <fonsinchen> If you had set up the same thing with transfer instead of unload orders, you still don't achieve anything.
21:20:07  <fonsinchen> But you do get credits then.
21:20:13  <Rubidium> okay, the whole situation is stupid network design, but still
21:21:29  <Rubidium> for unloading never gets you credits
21:21:36  <Rubidium> +ce
21:23:07  <fonsinchen> I would like to drop that special case and always give transfer credits when cargo is effectively transferred. I hope that's not a big deal.
21:23:11  <Rubidium> you never get credits for force unloading if the station doesn't accept the cargo, probably to make the user somewhat aware that a force unload does not function anymore via the "vehicle making a loss"
21:23:46  <fonsinchen> ah, OK. I understand that.
21:24:07  <fonsinchen> I'll try to come up with something else then.
21:24:26  <Rubidium> but that is "simple" point-to-point logic, which might make sense. Force unloading in a network seems somewhat useless to me
21:25:02  <frosch123> isn't the only difference of 'unload' and 'transfer' about the credits?
21:25:35  <Rubidium> no, transfer also does never deliver cargo while unload does. But for the rest that's about right
21:36:11  <fonsinchen> I'll divide the CargoList::MoveTo thing into 4 logically named methods: VehicleCargoList::Reserve, VehicleCargoList::LoadReserved, VehicleCargoList::Unload, VehicleCargoList::Shift
21:36:22  <fonsinchen> Shift is for moving cargo between vehicles
21:36:34  <fonsinchen> Everything else should be self-explanatory.
21:37:10  <fonsinchen> All cargo has to be reserved before loading. However, LoadReserved only decrements the reserved_count as all packets are still kept in the same list.
21:37:39  <fonsinchen> (And an additional VehicleCargoList::Unreserve, for those special cases, of course)
21:42:21  <fonsinchen> All of those return the amount of cargo actually moved.
22:12:12  *** fonsinchen has quit IRC
22:16:19  *** frosch123 has quit IRC
22:17:15  *** andythenorth has quit IRC

Powered by YARRSTE version: svn-trunk