Log for on 6th January 2013:
Times are UTC Toggle Colours
00:28:11  *** Supercheese has quit IRC
00:28:42  *** Supercheese has joined
00:32:09  *** Supercheese has quit IRC
00:32:38  *** Supercheese has joined
00:54:06  *** Supercheese has quit IRC
00:54:35  *** Supercheese has joined
00:56:15  *** Supercheese has quit IRC
00:56:44  *** Supercheese has joined
01:00:17  *** Supercheese has quit IRC
01:00:47  *** Supercheese has joined
01:14:25  *** Supercheese has quit IRC
01:14:55  *** Supercheese has joined
01:33:11  *** Zuu has quit IRC
02:50:08  *** Supercheese has quit IRC
02:50:39  *** Supercheese has joined
02:58:15  *** Supercheese has quit IRC
02:58:45  *** Supercheese has joined
03:03:26  *** Supercheese has left
05:26:27  *** Supercheese has joined
09:28:37  *** Supercheese has quit IRC
09:46:31  *** Alberth has joined
09:46:31  *** ChanServ sets mode: +v Alberth
10:52:18  *** ntoskrnl has joined
10:53:23  *** Zuu has joined
10:53:23  *** ChanServ sets mode: +v Zuu
11:34:29  *** frosch123 has joined
11:34:29  *** ChanServ sets mode: +v frosch123
12:54:00  *** fonsinchen has joined
12:54:00  *** ChanServ sets mode: +v fonsinchen
13:00:50  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r24889 || Logs: || 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
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>
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: || 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: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
19:14:05  *** Supercheese has joined
19:33:18  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r24892 || Logs: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
19:48:52  <fonsinchen> That was easy:
19:49:02  <fonsinchen> Needs some testing, though.
19:51:48  *** fonsinchen has quit IRC
20:29:05  *** Alberth has left
22:12:31  *** frosch123 has quit IRC
22:37:13  *** Zuu has quit IRC

Powered by YARRSTE version: svn-trunk