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