IRC logs for #openttd.dev on OFTC at 2013-10-19
⏴ go to previous day
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:43 *** Alberth has joined #openttd.dev
08:28:44 *** ChanServ sets mode: +v Alberth
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:32 <frosch123> i would thing gs just disable cdist
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: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:09 <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:28 <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:19:17 <fonsinchen> Then there is FS#5671
11:19:26 <fonsinchen> I have some code for that, too
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: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: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: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 :-)
12:25:46 *** zooks has joined #openttd.dev
12:43:32 <fonsinchen> Someone has broken the linkgraph overview on the main viewport :(
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:27 <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:46 <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.
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:14:36 <LordAro> that's always a good thing :)
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: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: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:58 <frosch123> i++ before push_back
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: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:30:05 *** Ristovski has joined #openttd.dev
18:38:26 *** andythenorth has joined #openttd.dev
18:38:26 *** ChanServ sets mode: +v andythenorth
19:08:01 *** Supercheese has joined #openttd.dev
19:08:04 *** andythenorth has left #openttd.dev
20:23:56 *** Alberth has left #openttd.dev
22:20:33 *** Supercheese has joined #openttd.dev
22:23:51 *** Supercheese has joined #openttd.dev
continue to next day ⏵