Config
Log for #openttd.dev on 19th October 2013:
Times are UTC Toggle Colours
01:12:09  *** LordAro has quit IRC
05:59:23  *** adf88 has joined #openttd.dev
05:59:23  *** ChanServ sets mode: +v adf88
08:11:20  *** zydeco has joined #openttd.dev
08:11:40  *** frosch123 has joined #openttd.dev
08:11:40  *** ChanServ sets mode: +v frosch123
08:24:00  *** LordAro has joined #openttd.dev
08:24:00  *** ChanServ sets mode: +v LordAro
08:28:44  *** Alberth has joined #openttd.dev
08:28:44  *** ChanServ sets mode: +v Alberth
08:59:07  *** adf88 has quit IRC
09:48:31  *** Supercheese has quit IRC
09:50:12  <fonsinchen> I'm pondering which bug to fix next ...
09:51:01  <LordAro> all of them, obviouly
09:51:03  <fonsinchen> FS#5766 is easy to fix the brutal way by just disabling subsidies for auto-distributed cargo
09:51:47  <fonsinchen> However, arguably in most cases you can make the subsidy trigger if you know some things about cargodist and e.g. build multiple stations in the target town
09:52:11  <Alberth> the issue is perhaps deeper in the sense that a GS might want to have control over what cargo goes where
09:52:18  <Alberth> eg sillicon valley
09:52:32  <frosch123> i would thing gs just disable cdist
09:52:35  <frosch123> *think
09:52:53  <fonsinchen> There could be another "scripted" distribution mode.
09:53:03  <fonsinchen> Someone should define how that should work
09:53:17  <frosch123> i am in favour of just disabling subsidies for routed cargos
09:53:30  <frosch123> though only the automatic generation of them
09:53:44  <frosch123> gs should still be able to spawn subsididies if they really want
09:53:47  <Alberth> yeah, that would be simplest sufficient solution for now
09:53:49  * fonsinchen has a patch for that
09:54:02  <Alberth> another peter!  :)
09:55:13  <fonsinchen> The subsidy code gets somewhat more hacky if we go with that solution but if we agree that non-scripted, autogenerated subsides don't have much of a future anyway we can accept that as a quick fix.
09:56:52  <frosch123> i think subsidies are more reasonable if there would be some production mechanism behind it
09:57:30  <Alberth> I would not go that far, it may become possible to unite subsidies and CD in some way, it's currently however an unsolved problem
09:57:36  <frosch123> e.g. if cdist gets an cdest-like addon which influences production depoending on available routes, it could give hints for useful connections via subsidies
09:57:58  <Alberth> the mechanisms are not compatible, so disabling one if you use the other, is fully defendable
09:58:03  <frosch123> but with only cdist (without cdest production), i see no point in messing it with subsidies
09:59:10  <frosch123> so, to me 9baa232beebeebf159b8f36d0259edf566669a47 looks fine
09:59:51  <fonsinchen> My point was rather that when touching the subsidy code I'm inclined to redesign it so that it doesn't do that awful "try 1000 times with random parameters" thing anymore.
10:00:29  <fonsinchen> What I've done there increases the awfulness some more by distributing the decision on if the subsidy is to be stopped by cargodist all over that mess.
10:01:56  <fonsinchen> But whatever, I'll test it some more and apply it if it works
10:04:10  <Alberth> randomly trying in a large search space has proven to be highly effective imho
10:04:41  <Alberth> but maybe CD has better information that could be used at some point
10:19:12  *** ntoskrnl has joined #openttd.dev
10:36:58  *** adf88 has joined #openttd.dev
10:36:58  *** ChanServ sets mode: +v adf88
11:17:30  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25882 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
11:17:39  <fonsinchen> There we go
11:19:17  <fonsinchen> Then there is FS#5671
11:19:26  <fonsinchen> I have some code for that, too
11:20:18  <fonsinchen> https://github.com/ulfhermann/openttd/commits/fixes2
11:20:28  <fonsinchen> There are two ways of doing it.
11:21:02  <fonsinchen> Either only the first 3 commits in that branch or all of them.
11:21:50  <fonsinchen> The extended version has the benefit of allocating all the SmallStack items in a vector which should be nice for locality
11:22:40  <fonsinchen> Considering the amount of code necessary for that and how rare the use case actually is, I don't think it's worth it, though
11:23:40  <fonsinchen> The "add index template to SmallVector" commit might be interesting in its own right, though.
11:24:02  <planetmaker> fonsinchen, that might be related to linkgraph: http://www.tt-forums.net/viewtopic.php?f=31&t=69000&p=1100770#p1100770
11:26:01  <fonsinchen> Looks like a bug in RefreshNextHops. I'll investigate
11:26:28  <planetmaker> shall I create an issue for it?
11:28:08  <fonsinchen> No, I can do that myself
11:30:12  *** ntoskrnl has quit IRC
11:38:17  <fonsinchen> This guy managed to create an order system where RefreshNextHopsStats has to process approximately 1 Million branches
11:38:30  <fonsinchen> I guess I should limit that a bit ...
11:40:45  <planetmaker> :D
11:47:36  <LordAro> it's been a week, am i allowed to ask if we can continue looking at cirdan's patch queue? :3
11:50:32  <planetmaker> for me after archery maybe :-)
11:51:50  <LordAro> :) have fun
12:25:46  *** zooks has joined #openttd.dev
12:43:32  <fonsinchen> Someone has broken the linkgraph overview on the main viewport :(
13:01:07  <fonsinchen> https://github.com/ulfhermann/openttd/commit/a6563f41d014d8e0fb788499983099f40c34adcb
13:01:48  <fonsinchen> This limits recursion in RefreshNextHopsStats by having all branches share their hop counts. It solves the problem at hand.
13:09:28  <Alberth> ... usedĀ up.   ->   ... used.       perhaps?
13:09:42  <Alberth> you seem to have an 80 character line limit :)
13:09:53  <Alberth> otherwise I see no obvious flaws
13:13:47  <fonsinchen> I'm not that strict about the 80 characters, but in general I try to stick to them, yes.
13:15:20  <fonsinchen> When changing the application window size the main Viewport size doesn't change, btw.
13:15:36  <fonsinchen> That leads to glitches in the link graph overlay.
13:17:07  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25883 || 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:29:51  *** dihedral has quit IRC
15:09:36  <frosch123> found the issue for the viewport glitching
15:10:03  <frosch123> but i guess i need to explore some "blame" for some weird code
15:11:56  <frosch123> hmm, it has been that way since r1 :)
15:12:34  <frosch123> http://paste.openttdcoop.org/show/2730/ <- more - than +
15:14:36  <LordAro> that's always a good thing :)
15:15:12  <Alberth> simple solution :)
15:21:09  *** dihedral has joined #openttd.dev
15:24:01  <fonsinchen> Are there limits on how much memory AIs can allocate?
15:24:32  <fonsinchen> I think I just had an experience of an AI allocating about 4GB of something
15:27:26  <frosch123> i am not aware of such limit
15:27:34  <frosch123> i only know about execution time limits
15:28:07  <fonsinchen> Unfortunately that was the random replacement for missing AI.
15:28:13  <fonsinchen> Probably rondje then ...
15:28:55  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25884 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
15:29:30  <LordAro> rondje explicitly stops itself from getting picked randomly, doesn't it?
15:31:01  <fonsinchen> Well, that was just rounding up the usual suspects. Don't take it too serious.
15:32:53  <LordAro> trains can get pretty complex, iirc
15:33:01  <LordAro> i don't really know about the newer ones
15:33:43  <fonsinchen> Well, memory consumption of openttd suddenly jumped from 8% to 80%
16:49:37  <fonsinchen> https://github.com/ulfhermann/openttd/commit/fa886c960be62afe27bdcfd5633ec9ff2ae0e6d2
16:50:04  <fonsinchen> Reduces time spent in EliminateCycles() by a factor of 4 in complicated link graphs
16:51:08  <fonsinchen> EliminateCycles takes up 80% of CPU time for this game: www.tt-forums.net/viewtopic.php?p=1100767
16:56:16  <frosch123> should the push_back go before the erase with i++ ?
16:56:33  <frosch123> either way, i think it should have a comment, wrt. new_Child being skipped in the loop, or not
16:57:07  <frosch123> actually, it's currently only skipped if "i" is the last element"
16:57:27  <frosch123> so, i guess that's not intended
16:58:46  <fonsinchen> You're probably talking about the end of the diff, mcf.cpp:382ff, right?
16:58:51  <frosch123> yes
16:58:58  <frosch123> i++ before push_back
16:59:14  <fonsinchen> it doesn't matter
16:59:14  <frosch123> if i++ results in end(), push_back will insert before it
16:59:25  <fonsinchen> if we hit end() with i++ we
16:59:35  <fonsinchen> 're not interested in the next element anyway
16:59:41  <fonsinchen> as its flow is 0
16:59:58  <fonsinchen> But yes, a comment would be good there.
17:01:09  <fonsinchen> How do you mean "it's currently only skipped if "i" is the last element"?
17:02:39  <frosch123> well, if the flow of the new child is zero, it's likely the same
17:03:18  <frosch123> when ignoring the "if (flow ==0) break" the loop iterates over all elements, including the new ones, except when already at the end
17:04:25  <fonsinchen> The break statement is the actual point of it
17:04:47  <fonsinchen> Without it it doesn't do anything interesting.
17:05:25  <frosch123> you assume that i would actually understand that code :)
17:06:30  <frosch123> i can only check for obvious issues, nothing which would require knowing the algorithms behind it
17:06:56  <fonsinchen> It simply makes sure the paths are always sorted so that the "empty" ones are in the back
17:07:17  <fonsinchen> as soon as we hit an empty one we can then skip the rest if we're only interested in the non-empty ones
17:10:01  <fonsinchen> In practice that means: Whenever a path is reduced to 0, move it to the back of the list and when creating a new path with flow > 0 push it to the front.
17:12:30  <frosch123> well, diff looks fine to me
17:15:20  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25885 || 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:30:05  *** Ristovski has joined #openttd.dev
17:45:10  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25886 || 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:16:31  *** zooks has quit IRC
18:38:26  *** andythenorth has joined #openttd.dev
18:38:26  *** ChanServ sets mode: +v andythenorth
18:42:24  *** adf88 has quit IRC
19:08:01  *** Supercheese has joined #openttd.dev
19:08:04  *** andythenorth has left #openttd.dev
20:23:56  *** Alberth has left #openttd.dev
21:40:13  *** frosch123 has quit IRC
21:43:00  *** Ristovski has quit IRC
22:14:48  *** Supercheese has quit IRC
22:20:33  *** Supercheese has joined #openttd.dev
22:23:21  *** Supercheese has quit IRC
22:23:51  *** Supercheese has joined #openttd.dev
23:34:17  *** zydeco has quit IRC

Powered by YARRSTE version: svn-trunk