Times are UTC Toggle Colours
00:28:11 *** Supercheese has quit IRC 00:28:42 *** Supercheese has joined #openttd.dev 00:32:09 *** Supercheese has quit IRC 00:32:38 *** Supercheese has joined #openttd.dev 00:54:06 *** Supercheese has quit IRC 00:54:35 *** Supercheese has joined #openttd.dev 00:56:15 *** Supercheese has quit IRC 00:56:44 *** Supercheese has joined #openttd.dev 01:00:17 *** Supercheese has quit IRC 01:00:47 *** Supercheese has joined #openttd.dev 01:14:25 *** Supercheese has quit IRC 01:14:55 *** Supercheese has joined #openttd.dev 01:33:11 *** Zuu has quit IRC 02:50:08 *** Supercheese has quit IRC 02:50:39 *** Supercheese has joined #openttd.dev 02:58:15 *** Supercheese has quit IRC 02:58:45 *** Supercheese has joined #openttd.dev 03:03:26 *** Supercheese has left #openttd.dev 05:26:27 *** Supercheese has joined #openttd.dev 09:28:37 *** Supercheese has quit IRC 09:46:31 *** Alberth has joined #openttd.dev 09:46:31 *** ChanServ sets mode: +v Alberth 10:52:18 *** ntoskrnl has joined #openttd.dev 10:53:23 *** Zuu has joined #openttd.dev 10:53:23 *** ChanServ sets mode: +v Zuu 11:34:29 *** frosch123 has joined #openttd.dev 11:34:29 *** ChanServ sets mode: +v frosch123 12:54:00 *** fonsinchen has joined #openttd.dev 12:54:00 *** ChanServ sets mode: +v fonsinchen 13:00:50 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r24889 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 14:15:38 *** fonsinchen has quit IRC 16:09:36 *** fonsinchen has joined #openttd.dev 16:09:36 *** ChanServ sets mode: +v fonsinchen 16:18:32 <Zuu> It appears that the compat_[version].nut files for Game Scripts are never included in bundles. This patch aim to fix that: 16:18:33 <Zuu> http://devs.openttd.org/~zuu/game-compat.patch 16:24:48 <frosch123> makes sense to me 16:26:40 <frosch123> os/rpm/openttd.spec might also need updating 16:27:13 <Zuu> IIRC there was a commit some time ago to change all GS references from "game" to "game script". However, the directory itself is called just "game" which we hardly can change at this point. Therefore I named the variable just GAME_DIR, but GS_DIR might be better? 16:27:40 <frosch123> imo keep it GAME_DIR 16:31:34 <Zuu> I've greped through all os related files now and also updated debian and windows. 16:32:29 <Zuu> patch updated 16:34:37 <frosch123> looks fine, i cannot find more places either :) 16:35:54 <Zuu> Ok. I'll commit then. If any more 1.2 release is made, I guess this should be backported there. 16:36:48 <frosch123> isn't the gs compat stuff only 1.3 anyway? 16:38:52 <Zuu> Oh yes 16:39:23 <Zuu> It may stop the warning that there is no compatibility script in 1.2, but it would be a empty compatibility script in 1.2, so the use there is quite low. 16:39:53 <frosch123> are you sure that compat stuff was backported? 16:40:00 <frosch123> i would think it does not even check for it 16:41:07 <Zuu> It might be that 1.2 doesn't even check for the compat_1.2.nut file as there is no use for it do do that other than for concistency with other versions. 16:41:30 <frosch123> the compatibility stuff was added later 16:41:35 <frosch123> it was for sure not in 1.2.0 16:42:23 <Zuu> Ok. I though that it might have existed from the beginning as GS is a copy of AI. 16:42:32 <Zuu> And AI have been having it since before. 16:43:20 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r24890 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 17:22:21 <fonsinchen> I get the impression that gradual loading is mostly there for the visual effect of the loading indicators. 17:22:54 <frosch123> it also gives a more detailed game mechanics 17:22:58 <frosch123> the time to load varies 17:23:01 <fonsinchen> Would it make a difference if we just loaded all the cargo at once and then waited for as long as it would have taken to load it gradually, displaying some fance numbers in the mean time. 17:23:03 <frosch123> and is controllable by newgrf 17:23:23 <frosch123> fonsinchen: yes, it would make a very big difference when skipping order while unloading 17:23:36 <fonsinchen> then it would have to be returned, of course 17:23:40 <fonsinchen> Other than that= 17:23:42 <fonsinchen> ? 17:24:04 <frosch123> "other than that" :p what does that mean? 17:24:28 <fonsinchen> Skipping while loading happens once a year. We can afford to run some extra code then. 17:24:49 <fonsinchen> Loading happens all the time and dividing the cargo packets into smaller chunks has a performance cost. 17:24:51 <frosch123> well, the station should also display it corrctly 17:24:58 <frosch123> and the vehicle details and everything 17:25:16 <frosch123> faking it makes no sense to me 17:25:24 <fonsinchen> we can keep a virtual cargo packet there to show "reserved" cargo. 17:25:36 <fonsinchen> I'd like to unify all the loading and reserving business 17:25:46 <fonsinchen> LoadUnloadVehicle is a mess. 17:26:06 <Alberth> pressing 'stop' while (un)loading? 17:26:17 <fonsinchen> same thing as skipping while unloading 17:26:22 <fonsinchen> cargo has to be reserved 17:26:22 <frosch123> i think the "load wagons at a time" (as for autorefit) you suggested is the right thing 17:26:29 <fonsinchen> s/reserved/returned/ 17:26:29 <frosch123> but loading all at once does not sound correct 17:29:49 <fonsinchen> cargodist as it is now, removes the cargo from the station when it's reserved, not when it's loaded. 17:30:08 <fonsinchen> No one has ever complained about the numbers not being correct. 17:30:11 <frosch123> is there a reason for that? 17:30:49 <frosch123> this reservation business seems to be the hardest part of cdist :) 17:30:50 <fonsinchen> Yes. Iterating over all the packets all the time to find out if they need to be loaded is expensive. 17:31:12 <fonsinchen> So I assign packets to vehicles up front and remove them from the list to be iterated. 17:32:06 <frosch123> can't the packets still stay at the station? 17:32:12 <frosch123> but with some hint which vehicle they belong to? 17:32:21 <fonsinchen> then I'd need #vehicles cargo lists there 17:32:44 <frosch123> a map packetid->vehicleid? 17:33:04 <fonsinchen> That would mean tons of map lookups 17:33:45 <fonsinchen> And those map lookups are exactly what I want to avoid. The flows which determine next hop are also maps. 17:34:35 <fonsinchen> And it doesn't decrease the packets to be iterated either 17:34:38 <frosch123> doesn't the station already have a list of vehicles loading at it? 17:34:55 <fonsinchen> That's a list 17:35:30 <fonsinchen> In trunk we don't need to iterate the packets for reserving. 17:35:37 <fonsinchen> That's the big difference. 17:36:00 <frosch123> yeah, so can't that list get another member to also hold a list of reserve cargopackets? (std::list< std::pair<Vehicle*, CargoPacket*> >) or something ilke that? 17:36:29 <frosch123> so, yeah, a list per waiting vehicle 17:36:29 <fonsinchen> That's about the same as just adding the list to the vehicle, isn't it? 17:36:37 <fonsinchen> I added the list to the vehicle. 17:36:52 <frosch123> ok, yeah, but the station should still count that cargo 17:37:37 <fonsinchen> We could also have the vehicle count that cargo and display it greyed out as "being loaded" somewhere. 17:37:43 <fonsinchen> That would be way easier. 17:38:55 <fonsinchen> In trunk's station gui we could actually count the reserved cargo, too. Sure 17:39:15 <frosch123> you mean something like "cargo being loaded" in the station gui? 17:39:21 <fonsinchen> In cargodist's that would be slightly complicated. 17:39:32 <frosch123> why? 17:39:57 <frosch123> you have the list of vehicles, and the vehicle have to know what they loaded or did not load in any case 17:40:03 <fonsinchen> Have you ever seen the station GUI in cargodist? It shows all kinds of details about where cargo is coming from and where it's going. 17:40:19 <frosch123> ah, you mean gui-wise 17:40:45 <fonsinchen> Yes, assembling all that data from N cargo lists instead of 1 would be a pain. 17:40:52 <fonsinchen> Probably doable, though. 17:41:48 <fonsinchen> I was actually thinking to radically simplify the whole thing by just loading the cargo into the real cargo list of the vehicle and keeping a simple reserved_count around somewhere. 17:42:27 <fonsinchen> On top of that we could say gradual loading is just reserving for all of the vehicle and then loading it bit by bit. 17:43:10 <fonsinchen> While non-gradual loading is loading the same thing all at once. We wouldn't need to split the packets anymore as it would just be about incrementing and decrementing some cargo counters. 17:45:07 <fonsinchen> The station gui in cargodist could just show one "special" source/destination/via which says "reserved" 17:45:53 <fonsinchen> no need to give any details about that as it will be gone soon, anyway. 17:45:57 <Zuu> Would there be any implications for NewGRFs? 17:46:01 <fonsinchen> no 17:46:59 <frosch123> well, in the past there were issues like vehicles not paying or paying for stuff when crashing mid-unloading 17:47:23 <frosch123> that stuff would all need special handling if cargo is virtually moved at different points in time than the real unloading/loading 17:48:55 <frosch123> what happens when unloading in cdist? 17:49:00 <frosch123> when is cargo payed for? 17:49:10 <fonsinchen> the same as in trunk 17:49:33 <frosch123> in trunk it accounts for every single packet being unloaded, and display the sum when leaving 17:49:37 <fonsinchen> I just catch all the places where a vehicle can abort the loading process and return the cargo then. 17:50:12 <fonsinchen> Cargo is payed for when it's moved from the reserved to the real list. 17:50:14 <frosch123> well, when does the cargo leave the vehicle and appear at the station? 17:50:21 <frosch123> when can it be loaded on the next vehicle? 17:50:27 <fonsinchen> Uh, wait 17:50:41 <fonsinchen> cargo is payed when _unloading_, not when loading 17:50:44 <fonsinchen> ?? 17:50:59 <frosch123> yeah, i changed the topic to unloading :) 17:51:10 <fonsinchen> there's no reservation for unloading. 17:51:14 <frosch123> or are you not changing anything there? 17:51:19 <frosch123> ah, ok 17:51:51 <fonsinchen> It would be interesting to change that, too, though. 17:52:07 <frosch123> i think that would even more troublesome than changing the other :) 17:52:26 <frosch123> hmm, why am i words all day 17:52:34 <frosch123> s/word/verbs/ 17:53:31 <fonsinchen> probably 17:53:46 <frosch123> anyway, ok, i think changing the loading to put all reserver cargo on the train should be fine, if the loading indicator shows the correct state, and cargo is moved back correctly in all weird cases, like skipping or crashing 17:54:08 *** ntoskrnl has quit IRC 17:56:02 <fonsinchen> If I'm not touching gradual unloading I probably should leave the semantics of gradual loading alone, too. 17:56:22 <fonsinchen> Still the reservation can be changed. 18:44:38 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r24891 || 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:14:05 *** Supercheese has joined #openttd.dev 19:33:18 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r24892 || 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:48:52 <fonsinchen> That was easy: https://github.com/fonsinchen/openttd-cargodist/tree/reservation3 19:49:02 <fonsinchen> Needs some testing, though. 19:51:48 *** fonsinchen has quit IRC 20:29:05 *** Alberth has left #openttd.dev 22:12:31 *** frosch123 has quit IRC 22:37:13 *** Zuu has quit IRC