Times are UTC Toggle Colours
00:01:50 *** tokai has joined #openttd 00:01:50 *** ChanServ sets mode: +v tokai 00:08:55 *** tokai|noir has quit IRC 00:24:54 *** supermop_work has joined #openttd 00:30:08 *** supermop_work_ has quit IRC 00:34:30 *** supermop_work_ has joined #openttd 00:39:13 *** supermop_work has quit IRC 01:03:54 *** Wormnest has joined #openttd 01:16:03 *** supermop_work_ has quit IRC 01:19:26 *** Thedarkb-X40 has joined #openttd 01:26:14 *** Thedarkb-T60 has quit IRC 02:01:30 *** supermop_Home has joined #openttd 02:02:56 *** Wormnest has quit IRC 02:28:44 *** Thedarkb-X40 has quit IRC 02:46:05 *** snail_UES_ has joined #openttd 03:11:48 *** samu has quit IRC 03:31:56 *** debdog has joined #openttd 03:35:19 *** D-HUND has quit IRC 03:41:13 *** glx has quit IRC 05:28:03 *** Gustavo6046 has quit IRC 05:31:51 *** snail_UES_ has quit IRC 06:49:30 <peter1138> morning 07:14:12 <Eddi|zuHause> weather even worse... 07:29:50 *** Gustavo6046 has joined #openttd 08:47:50 *** supermop_Home has quit IRC 09:37:43 <DorpsGek_II> [OpenTTD/OpenTTD] Gabda87 commented on pull request #7120: Codechange: Improve performance of closest town lookups with cache https://git.io/fhQrU 09:40:16 *** m3henry has joined #openttd 09:53:42 <DorpsGek_II> [OpenTTD/OpenTTD] Gabda87 commented on pull request #7120: Codechange: Improve performance of closest town lookups with cache https://git.io/fhQr4 10:13:13 *** Westie has joined #openttd 10:14:11 *** Westie has quit IRC 10:18:32 *** Westie has joined #openttd 10:22:00 *** Westie has quit IRC 10:22:45 *** Westie has joined #openttd 10:40:50 <DorpsGek_II> [OpenTTD/OpenTTD] ldpl commented on pull request #7120: Codechange: Improve performance of closest town lookups with cache https://git.io/fhQoj 10:46:09 *** Extrems has quit IRC 10:54:18 *** Extrems has joined #openttd 11:30:12 <DorpsGek_II> [OpenTTD/OpenTTD] Gabda87 commented on pull request #7120: Codechange: Improve performance of closest town lookups with cache https://git.io/fhQKQ 11:39:45 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on pull request #7120: Codechange: Improve performance of closest town lookups with cache https://git.io/fhQ6U 12:14:52 *** Flygon has quit IRC 12:26:33 <peter1138> 16k maps will use tons of ram. Well, no shit :p 12:31:34 <Eddi|zuHause> @calc 2**(6+15) 12:31:34 <DorpsGek> Eddi|zuHause: 2097152 12:35:54 <peter1138> 3.2GB 12:41:40 <Eddi|zuHause> hm... been digging through the internet, and found a "hpet=disable" boot option, gonna try that... 12:41:54 *** Eddi|zuHause has quit IRC 12:43:56 *** Eddi|zuHause has joined #openttd 12:59:57 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on pull request #7209: Fix: volume slider behavior in music gui https://git.io/fhQir 13:01:24 <FLHerne> What on earth does anyone need a 16k map for? 13:02:07 *** andythenorth has joined #openttd 13:02:31 <FLHerne> 2k is already big enough for all companies to build a large network without any significant overlaps or competition 13:02:48 <FLHerne> (which is normal, and a pity) 13:03:31 <peter1138> Competition seems to be frowned upon, as if 'cargo stealing' is a thing... 13:03:57 <FLHerne> I can see it from secondary industries 13:04:12 <peter1138> It's not! 13:05:04 <FLHerne> (all the cargo is produced through the supplier's efforts, and more practically there are usually space problems) 13:05:09 * andythenorth doesn't understand anything 13:05:31 <FLHerne> For primaries, sharing is a benefit if anything, because of the rating... 13:06:44 <Eddi|zuHause> hm... it's still using hpet for... something 13:09:03 <peter1138> But it's not the supplier's cargo. It's not the supplier's industry. 13:09:32 <peter1138> And sure, it hurts if someone takes from an industry you are serving, but that's the game. 13:09:42 <peter1138> And then servers come along and say it's against the rules... o_O 13:09:59 <FLHerne> Eh 13:10:37 <FLHerne> If you allowed that, later players would just come along and not build primary networks at all, because the secondary cargos are enormously more profitable 13:10:46 <FLHerne> And have more-concentrated sources 13:11:03 <FLHerne> Which doesn't seem at all fair on the early ones 13:11:22 <andythenorth> oh we're doing 16k maps? 13:11:33 <andythenorth> well MOAR IS BETTER 13:11:34 <FLHerne> I hope not :-/ 13:11:51 <FLHerne> I really don't get this 13:12:06 <andythenorth> means we can say no to more features, due to performance and RAM concerns 13:12:37 <FLHerne> If the map can be <n> times larger by area, there could equally be <n> times more data per tile in the map array 13:13:05 <FLHerne> And then all the constraints like bridge data, neighbouring railtypes etc. just vanish 13:13:51 <FLHerne> And those are far more of a limitation on gameplay than running out of space on a 4k map, which I doubt has ever happened to anyone 13:13:56 <andythenorth> err 13:14:06 <andythenorth> don't we need to shard to do 16k maps? 13:14:32 * andythenorth pretends TB said he wanted to do it 13:14:49 <peter1138> We're not doing 16k maps :p 13:14:54 <andythenorth> 4x4k 13:15:01 <andythenorth> and something to keep edge tiles in sync 13:15:11 <andythenorth> when we've done that, we can also arrange them vertically 13:15:17 <andythenorth> for underground 13:15:38 * andythenorth goes back to painting opening doors on pax coaches 13:18:38 <andythenorth> oof my last commit message is wrong 13:18:51 <andythenorth> googling how to fix that gets me nothing useful 13:18:59 <andythenorth> nvm 13:19:46 <andythenorth> 'install this random mercurial extension, then create a queue, then edit history, then replace history' 13:19:47 <andythenorth> wat? 13:19:55 <peter1138> git commit --amend 13:20:04 <andythenorth> yeah wrong vcs 13:20:11 <peter1138> Stop doing that :/ 13:20:29 <andythenorth> yeah that 13:20:33 <FLHerne> I think hg has comprehensively lost the vcs war by now :P 13:20:39 <andythenorth> it lost 5 years ago 13:20:49 <andythenorth> the lolz is that it's supposed to be 'easier' 13:21:15 <andythenorth> it's version control for people who don't understand version control 13:21:21 <andythenorth> but it lost that to Dropbox 13:22:28 <Eddi|zuHause> uhm... hg has a feature very similar to "amend" 13:22:43 <peter1138> https://stackoverflow.com/questions/17970341/migrating-from-mercurial-to-git 13:23:25 <andythenorth> oh I can just import a hg repo to github 13:23:30 <andythenorth> did that with nml already 13:23:47 <andythenorth> maybe I should do that, and let bundles die 13:23:49 <andythenorth> kind of sad though 13:35:45 <Eddi|zuHause> # cat /sys/devices/system/clocksource/clocksource0/current_clocksource 13:35:46 <Eddi|zuHause> hpet 13:35:58 <Eddi|zuHause> wtf is the "hpet=disable" boot option doing then?!? 13:37:26 <Eddi|zuHause> (mind you, i might be treating a symptom) 13:37:43 *** Extrems has quit IRC 13:38:44 *** Extrems has joined #openttd 13:40:17 <Eddi|zuHause> andythenorth: like i said, bundles should be able to compile from a git repo 13:41:08 *** snail_UES_ has joined #openttd 13:52:08 *** m3henry has quit IRC 13:58:21 *** snail_UES_ has quit IRC 14:07:59 *** samu has joined #openttd 14:08:02 <samu> hi 14:23:29 <samu> I've been comparing 2500 opcodes very fast versus 10000 opcodes medium 14:27:14 <samu> seems to be equal 14:27:22 <samu> but less spiky 14:27:26 <samu> with 2500 opcodes 14:36:35 <samu> so uhm... I'd like to suggest new defaults for #opcodes and competitor speed based on this 14:37:24 <samu> 2500 opcodes and very fast, which is very much equivalent to the current 10000/medium 14:37:42 <samu> except that fps spikes are less sensed 14:37:50 <samu> it's smooth 14:39:27 <samu> but I'm still testing several ais, just to make sure 14:41:02 *** supermop_work has joined #openttd 14:41:15 <DorpsGek_II> [OpenTTD/OpenTTD] ldpl commented on pull request #7120: Codechange: Improve performance of closest town lookups with cache https://git.io/fhQ1D 14:41:16 <samu> repetition 14:42:30 *** supermop_work_ has joined #openttd 14:43:24 *** nielsm has joined #openttd 14:46:20 *** andythenorth has left #openttd 14:49:05 *** supermop_work has quit IRC 14:49:12 *** octernion has joined #openttd 14:56:20 <DorpsGek_II> [OpenTTD/OpenTTD] Eddi-z updated pull request #7213: Feature: BFS-based river generator https://git.io/fhHN6 14:56:46 <Eddi|zuHause> i think i fixed the pathological DFS case now 14:57:17 <Eddi|zuHause> randomness in direction might need some bias to go away from the origin basin 14:57:49 <Eddi|zuHause> on smoother maps i get unfocused networks where you can't follow from where to where it's flowing 15:20:39 <samu> weird stuff 15:21:35 <samu> the average frame time for 10000/medium is less than the average frame time for 2500/veryfast and yet it's still 4 months behind 15:21:52 <samu> how's these averages calculated? they seem wrong 15:24:22 <DorpsGek_II> [OpenTTD/OpenTTD] Gabda87 commented on pull request #7120: Codechange: Improve performance of closest town lookups with cache https://git.io/fhQMh 15:28:17 <FLHerne> Eddi|zuHause: Idea: For river generation, give each corner a fractional height based on smoothing across a number of tiles 15:28:46 <FLHerne> (does that already exist at the terrain-generation stage, before rounding?) 15:29:35 <Eddi|zuHause> river generation currently happens when the terrain is already rounded to tileheights 15:30:25 <FLHerne> A lot of the river-generation problems seem to stem from the local gradient always being either 0 or 1, which doesn't allow them to follow the wider shape of the terrain 15:30:52 <FLHerne> Yes, I was just thinking it might be easier to preserve that than recalculate something similar 15:31:02 <nielsm> samu: if I want to test AI performance improvements (or lack of) with and without the voronoi patch, are there any particular AI's you think are better for that? 15:31:29 <Eddi|zuHause> i tried that approach a few years ago, but that generally fails because the generated rivers cannot be placed on the resulting terrain (invalid slopes) 15:31:34 *** sla_ro|master has joined #openttd 15:32:04 <Eddi|zuHause> and fixing the slopes afterwards is tricky 15:32:09 <FLHerne> Hm 15:32:52 <FLHerne> Could you mark unsuitably-sloped tiles as impassable for the river pathfinder? 15:33:19 <FLHerne> Only letting it consider tiles it can actually build on 15:33:21 <Eddi|zuHause> you can do that only after the sub-height information is already lost 15:33:41 <Eddi|zuHause> that's how my current approach works 15:33:52 <Eddi|zuHause> but the two approaches are mutually exclusive 15:34:20 <FLHerne> I don't see why both sets of information can't exist simultaneously... 15:35:02 <FLHerne> Even if it's replaced in-place in the map array, there are all the spare bits that aren't being used yet :P 15:35:14 <samu> well, you need mucho towns, so perhaps a 4k map to test that 15:35:22 <Eddi|zuHause> but i already use some of those :p 15:35:31 <samu> and ais,... hmm not sure, mine used to constantly calc closest town for airports 15:35:37 <samu> but not any more 15:35:45 <FLHerne> I mean, for road/rail/trees/blah, none of which exist at that stage 15:35:53 <FLHerne> (that might also be what you meant) 15:36:12 <Eddi|zuHause> but generally, the TGP noise heights aren't stored in the map array at all, they are discarded right after terrain generation 15:36:34 <FLHerne> OK, but why do they /have/ to be? 15:36:56 <FLHerne> Moving free()/delete calls isn't that hard :P 15:37:40 <Eddi|zuHause> i'm not sure how useful they would even be, because the actual terrain might be a lot different after the slope-fixing (tile height difference max 1) 15:38:05 <Eddi|zuHause> FLHerne: keep in mind that the terrain generator is isolated, as there can be different ones 15:38:19 <samu> i suspect simpleai? 15:38:29 <samu> dictator ai 15:38:40 <samu> not entirely sure, maybe terron? 15:38:44 <samu> have to recheck 15:39:03 <nielsm> https://0x0.st/zz_0.jpg <-- started at the same time, left with just the ai-framerate patch, right with ai-framerate and voronoi 15:39:17 <nielsm> the one with voronoi is significantly faster 15:39:21 <samu> oh, clueless 15:39:28 <samu> i think clueless does it 15:39:55 <nielsm> I started the game on jan 1st, then loaded the same save in both builds 15:40:23 <samu> perhaps borkai, it uses town cache 15:40:32 <samu> massively, not really sure what kind of cache though 15:41:50 <Eddi|zuHause> so 11 months vs 13 months in the same real time? 15:42:05 *** Gustavo6056 has joined #openttd 15:42:15 *** Gustavo6046 has quit IRC 15:42:23 *** Gustavo6056 is now known as Gustavo6046 15:44:07 <samu> oh, AIAI has quite irregular performance, might be worth trying 15:44:46 <samu> it's a mix of several AI parts together 15:45:20 *** Wormnest has joined #openttd 15:48:00 <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh commented on pull request #7120: Codechange: Improve performance of closest town lookups with cache https://git.io/fhQDX 15:50:28 <samu> i'd say, generally AIs that use towns, passengers, airports, bus stations and the like 15:50:55 <samu> those that use industries may not 15:51:36 <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh commented on pull request #7120: Codechange: Improve performance of closest town lookups with cache https://git.io/fhQDQ 15:52:59 <nielsm> 25% improvement is very much worth a 20% memory increase IMO 15:54:12 <samu> mogulai is industry only ai, you are testing it 15:54:17 <samu> does it make a difference? 15:54:33 <nielsm> especially when those 20% memory usage are of 160 MB at most, and not of say 1600 MB 15:55:33 <nielsm> I saw one period where MogulAI was pulling the left game down to something like 15-20 fps, with very long frame times 15:55:41 <nielsm> but it stopped doing that again after a little while 15:55:58 <samu> probably iterating over the list of industries 15:56:08 <samu> not sure if that uses calc closest town, i think not 15:57:01 <nielsm> now the right game is running faster, likely just because it's further ahead and has more to simulate as a result :P 15:57:16 <nielsm> uh right with voronoi is running slower now 15:57:34 <nielsm> or rather they're pretty much equal, occasionally one pulling ahead 15:57:53 <nielsm> and now AIAi crashed in voronoi version 15:58:35 <peter1138> Nice testing. 15:58:43 <peter1138> Sometimes they do just crash though. 15:58:48 <peter1138> Unless the game itself crashed. 15:58:59 <peter1138> And it's not actually 20% 15:59:21 <peter1138> 16.6% 15:59:57 <peter1138> 0.5MB on a decent size map. 16:01:42 <nielsm> there's a ~30 MB difference in memory usage (according to windows taskmgr) between the two versions here 16:01:53 <peter1138> Hmm. 16:01:59 <peter1138> 4MB for 2048x1024 16:02:15 <peter1138> Memory usage might be AIs themselves. 16:02:24 <peter1138> Or, indeed, sprite cache. 16:02:44 <nielsm> if that's going to kill your ability to run the game you need to find a better hosting provider, or buy a computer from this millenium 16:04:25 *** synchris has joined #openttd 16:04:55 <nielsm> my test game: https://0x0.st/zzL-.sav 16:06:49 <FLHerne> nielsm: I'm not at all convinced that's a representative test, though 16:08:30 <nielsm> let's try murdergame Wentbourne Transport too then 16:08:32 <nielsm> that's singleplayer 16:09:50 <FLHerne> 17% in the infrastructure-building phase of an AI-heavy game, without much vehicle pathfinding, newgrf-sprite rendering or other things that really end up killing performance 16:11:02 <FLHerne> I'd be surprised if it's more than even 5% or so in a more typical game 16:11:12 <FLHerne> (yes, I'll eat my words if your test says otherwise) 16:12:52 <nielsm> I'll let wentbourne run for a while longer and see if either pulls ahead 16:13:06 <nielsm> running at about 6.5fps 16:15:41 <DorpsGek_II> [OpenTTD/OpenTTD] ldpl commented on pull request #7120: Codechange: Improve performance of closest town lookups with cache https://git.io/fhQyV 16:18:59 <peter1138> Good ol' wentbourne :-) 16:20:37 <peter1138> Linking a research paper on the problem suggests it's not actually a simple problem. 16:26:37 <nielsm> still both at the exact same spot 16:26:49 <_dp_> peter1138, it's just a first overview page that I googled up, many of those structures aren't that hard to implement in 2d case 16:26:57 <nielsm> so probably no advantage for this case 16:27:18 <peter1138> Where did 25% come from? 16:27:22 <peter1138> Was that just a fluke? 16:27:57 <nielsm> AI's doing initial planning 16:28:28 <nielsm> it's mainly AI and GS getting a performance benefit from this 16:28:50 <nielsm> since they're more likely to query town distances all the time 16:38:40 <samu> usually when planning new routes 16:38:55 <samu> not "all the time" 16:39:43 <samu> it depends from ai to ai 16:41:17 <samu> i think a good way to test in trying not using fast forward, but experience the lag 16:41:21 <samu> input lag 16:42:02 <samu> also see which one gets ahead 16:42:05 <samu> in months 16:42:13 <samu> running at normal speed 16:47:21 <samu> the average seems misleading 16:47:48 <samu> it's the average of the last 512 ticks? 16:47:56 <samu> measures 16:48:37 <samu> I don't know how to explain - it doesn't feel right 16:49:06 <samu> I'm currently testing 2500 opcodes/veryfast vs 10000 opcodes/medium 16:49:28 <samu> and the 2500 is pulling ahead faster despite averaging higher frame rate 16:49:38 <samu> currently 8 months ahead 16:49:44 <samu> in 6 years 16:49:45 *** Lejving_ has joined #openttd 16:49:48 *** Lejving_ has quit IRC 16:55:30 <samu> averaging higher frame time* typo 16:56:46 <samu> https://imgur.com/QG0sY2E 16:59:14 *** Gja has joined #openttd 17:05:44 <DorpsGek_II> [OpenTTD/OpenTTD] Gabda87 commented on pull request #7120: Codechange: Improve performance of closest town lookups with cache https://git.io/fhQ9J 17:14:38 <samu> wow, 19 seconds stall 17:14:48 <samu> sometimes these occur 17:14:57 <samu> very hard to trigger them 17:16:23 <samu> I wish I had a reliable way to see what causes it 17:20:32 <samu> 21 second stall https://imgur.com/T57A4IK 17:20:36 <samu> on the right 17:26:21 *** HerzogDeXtEr has joined #openttd 17:32:19 *** Eddi|zuHause has quit IRC 17:34:53 *** Eddi|zuHause has joined #openttd 17:35:58 <DorpsGek_II> [OpenTTD/OpenTTD] nikolas commented on pull request #7209: Fix: volume slider behavior in music gui https://git.io/fhQ91 17:54:11 *** Gabda has joined #openttd 17:58:40 *** Progman has joined #openttd 18:07:32 <DorpsGek_II> [OpenTTD/OpenTTD] nikolas updated pull request #7086: Change #6173: Update SDL driver to use SDL 2.0 https://git.io/fhamZ 18:09:04 <DorpsGek_II> [OpenTTD/OpenTTD] Gabda87 updated pull request #7120: Codechange: Improve performance of closest town lookups with cache https://git.io/fh66E 18:12:12 <DorpsGek_II> [OpenTTD/OpenTTD] Gabda87 commented on pull request #7120: Codechange: Improve performance of closest town lookups with cache https://git.io/fhQHw 18:12:16 *** andythenorth has joined #openttd 18:13:23 <andythenorth> error 18:15:48 <peter1138> What sort? 18:16:21 <nnyby> PR #7086 can have the wip tag removed... as I'm currently waiting for further feedback, and don't really have anything TODO here myself yet 18:17:56 <samu> how do I measure garbage collector time? 18:18:23 <andythenorth> https://www.tt-forums.net/viewtopic.php?p=1218472#p1218472 18:18:25 <samu> I suspect it to be the cause of these 20 seconds stalls 18:19:09 <samu> I wanna chrono it 18:19:27 <samu> print the time in console, kinda like Gabda done for voronoi 18:22:08 <Gabda> maybe it is possible to make a macro for that chrono timing 18:23:04 <Gabda> like the TIC and TOC 18:25:12 <Eddi|zuHause> iirc the chrono thing works by object lifetime 18:25:37 <Eddi|zuHause> i.e. you create the object on the stack, and when it gets destroyed, it records the time 18:26:47 <peter1138> No, the chrono thing is just a C++ timer. 18:27:00 <peter1138> The framerate stuff that nielsm wrote does the stack lifetime stuff. 18:28:43 <nielsm> sq_state.cpp:248 is probably where you'd want to measure 18:38:45 <samu> how to do it? 18:41:35 *** glx has joined #openttd 18:41:35 *** ChanServ sets mode: +v glx 18:42:13 <nielsm> samu: https://github.com/OpenTTD/OpenTTD/blob/master/src/debug.h#L66-L86 18:44:55 *** Wolf01 has joined #openttd 18:45:26 <samu> alright let me try 18:45:31 <Wolf01> o/ 18:50:31 <Wolf01> https://www.microsoft.com/store/productId/9NLP712ZMN9Q wait, what? 50€ (now discounted at 10€) for a X server for windows? I do the same for free 18:52:09 *** Gabda has quit IRC 18:54:39 *** Wormnest has quit IRC 18:58:36 <Wolf01> Eddi|zuHause: I need your help https://www.stonewars.de/news/lego-10265-ford-mustang-creator-expert/ TL;DR :P 18:58:38 <samu> how to convert int to text? wanted to print company id 18:59:26 <peter1138> %d 18:59:27 <Eddi|zuHause> something about ebay hungary 18:59:44 <Eddi|zuHause> and should be available 1st march 19:00:02 <Wolf01> Nice 19:01:29 <samu> %d? how? 19:02:28 <samu> dbg: [misc] [Collect Garbage %dcid] 867 [avg: 867.0] 19:02:31 <samu> ugly 19:03:00 <peter1138> printf("%d", companyid) 19:03:43 <samu> where would I put TOC? 19:08:29 * peter1138 tests Eddi|zuHause's rivers. 19:08:58 <samu> are these milliseconds? picoseconds? something else? 19:09:09 <samu> not sure what number is this 19:09:25 <LordAro> probably not picoseconds 19:12:21 <nielsm> it's some not whole power of ten 19:14:56 <nielsm> the actual meaning probably depends on your cpu and chipset 19:17:31 <samu> oh :| 19:18:08 <peter1138> There's a number to use to average out a bit. 19:19:18 <peter1138> Hmm, very flat rivers. 19:19:23 *** gelignite has joined #openttd 19:19:52 <peter1138> Hmm, I've got river tiles at sealevel. 19:22:38 <samu> 1 - dbg: [misc] [Collect Garbage] 484677120 [avg: 484677120.0] how would I know how much time this is? 19:22:43 <samu> t.t 19:22:54 <planetmaker> hi 19:22:56 <Eddi|zuHause> yeah, i thought i fixed those, but i might have missed some cases 19:24:25 <peter1138> They meander on large plains nicely, but don't really start in nice places. 19:26:25 <DorpsGek_II> [OpenTTD/OpenTTD] LordAro merged pull request #7168: Fix: CompanyEconomy documentation https://git.io/fhSgg 19:32:16 * andythenorth tries rivers 19:39:04 <andythenorth> Eddi|zuHause: it's unquestionably better IMO 19:39:23 <Eddi|zuHause> yeah, but far from optimal 19:39:54 <nielsm> does it make wide rivers? 19:39:56 * andythenorth compares with 1.8.0 19:40:04 <Eddi|zuHause> not yet 19:40:08 <andythenorth> yeah not optimal on several fronts, but already better than 1.8.0 19:40:17 <andythenorth> biggest point: it makes river networks, not just rivers 19:40:24 <andythenorth> which makes them a lot more useful in-game 19:40:56 <andythenorth> it generates far too many currently though :) 19:42:54 <Eddi|zuHause> yes 19:43:18 *** frosch123 has joined #openttd 19:43:29 <Eddi|zuHause> it needs to be more aware of how much area it covered for one basin 19:43:50 <nielsm> many rivers through flat areas will look odd yeah, maybe try to have flat areas quickly gather rivers into fewer large ones? 19:43:59 <andythenorth> so half-width rivers? With limited navigability? o_O 19:44:14 <andythenorth> in the upper reaches 19:44:18 <Eddi|zuHause> non-shipable rivers, yes 19:44:35 <andythenorth> does it explicitly avoid slopes currently? 19:44:38 <Eddi|zuHause> yes 19:44:43 <andythenorth> probably good 19:44:55 <andythenorth> I don't like the default ones running up mountains 19:45:09 <Eddi|zuHause> it also avoids higher-level basins if it can reach a lower level one 19:45:40 <Eddi|zuHause> which sometimes causes odd "runs along a slope" situations 19:46:39 <nielsm> my ideal of how it'd handle small basins it "runs by", would be to actually fill it in, i.e. terraform the land up and then make a lake of it 19:46:49 <andythenorth> it's created some fantastic networks, with 20 or so tributaries 19:47:17 <samu> nielsm: explain me these times https://paste.openttdcoop.org/pasmwbwr2 19:47:24 <samu> how to convert to milliseconds or so 19:47:46 <Eddi|zuHause> yeah, but in large areas i tend to get lost on which direction is now to the sea :p 19:48:21 <andythenorth> is map gen still broken with MHL? 19:48:26 <andythenorth> or am I just getting weird random 19:48:33 <peter1138> Avoiding slopes? Hmm, maybe avoiding long slopes. 19:48:38 <andythenorth> can't get mountains in temperate, height level is 24 19:48:43 <andythenorth> 16 works 19:48:46 <peter1138> andythenorth, that's variety that's broken. 19:48:56 <andythenorth> oof I'll turn it off 19:49:06 <andythenorth> yeah way better now 19:49:23 <Eddi|zuHause> peter1138: avoiding "wrong slopes", mostly, and the long slopes are slightly more avoided as there are often not enough tributaries to trigger the initial river creation 19:49:49 <peter1138> Are you doing sea-inwards? 19:51:05 <Eddi|zuHause> peter1138: basically, it starts from the sea and assigns each tile a flowing direction, then it starts from the spring tiles (the last ones visited) and assigns a flow amount number, which increases when there are tributaries merging. after a threshold of flow, it starts making river tiles 19:52:11 <andythenorth> this was so nearly perfect :) https://dev.openttdcoop.org/attachments/download/9283/Unnamed,%2001-01-1948.png 19:52:13 <Eddi|zuHause> next plan is to make rivers wider with higher flow numbers 19:52:26 <andythenorth> ^ got caught on a few edge cases 19:52:34 <andythenorth> is it mis-detecting coast slopes? 19:52:49 *** synchris has quit IRC 19:53:03 <Eddi|zuHause> i thought i had tried to avoid those cases, but maybe i broke it 19:54:15 <andythenorth> pretty close though eh? 19:56:05 <andythenorth> is this PR getting built by CI? 19:58:05 *** octernion has quit IRC 20:07:31 <Eddi|zuHause> oh i found it, flipped a bool expression the wrong way around :p 20:08:59 <Eddi|zuHause> hm, still not 100% fixed 20:13:52 *** octernion has joined #openttd 20:20:19 <peter1138> Oh wow, I'd forgotten about pixeltool 20:21:31 <Eddi|zuHause> dangit, i fixed the size calculation, but that made it into DFS mode again... 20:31:10 <Eddi|zuHause> i can't fix one thing without breaking the other :/ 20:33:34 <samu> question, what happens if garbage collector is never run? 20:34:43 <samu> it appears to be the cause of some stalls, I can notice NoCAB stalls right before the measure comes with the result 20:36:59 *** sla_ro|master has quit IRC 20:41:59 <samu> the 20 second stalls haven't occured yet :( 20:42:08 <samu> i'm getting some of about 4 seconds 20:42:20 <samu> it's not caused by garbage collector :( 20:42:35 <peter1138> Didn't think it would be. 20:43:07 <peter1138> Mmm, artisan white chocolate. It's like normal white chocolate but less sweet and more expensive. 20:43:15 <samu> max i've noticed from garbage collector is about 180 ms 20:43:33 <samu> if the graph doesn't lie, that is 20:43:35 <peter1138> Do a TIC/TOC on the valuator stuff. 20:43:50 <samu> I tried, but no idea how to interpret the result 20:44:14 <samu> https://paste.openttdcoop.org/pasmwbwr2 20:44:32 <samu> 1, 9 and 14 are NoCAB 20:45:04 <peter1138> LordAro, around? 20:45:31 <samu> no, AroAI isn't running 20:46:14 <LordAro> peter1138: possibly 20:46:42 <peter1138> Wondering how to document the AI changes I've made, bearing in mind they're not set in stone yet. 20:46:46 <peter1138> For NRT, this is. 20:49:12 <LordAro> i presume you mean beyond the usual doxygen stuff? 20:49:26 <peter1138> Well, is that sufficient? 20:49:42 <LordAro> i don't see why not 20:49:44 <peter1138> Ok 20:49:50 <LordAro> a few sentences in the changelog as well, probably 20:50:00 <peter1138> enum AIRoad::RoadSubType 20:50:01 <peter1138> Types of rail known to the game. 20:50:03 <peter1138> Ooo... 20:50:07 <peter1138> Types of rail :D 20:50:10 <LordAro> haha 20:50:38 *** Thedarkb-T60 has joined #openttd 20:51:37 <peter1138> Which changelog? 20:51:53 <peter1138> I've not been writing changelogs :) 20:52:04 <peter1138> Maybe I should rebase and squash. 20:52:09 <LordAro> ai_changelog.hpp 20:52:15 <LordAro> and also game_changelog.hpp, i imagine 20:52:30 <peter1138> Oooh 20:52:40 *** Laedek has quit IRC 20:56:51 *** Laedek has joined #openttd 21:01:59 <peter1138> Hmm, not sure if all these functions apply to a GS 21:04:07 <peter1138> Well, seem to be there for existing stuff, so ok. 21:05:17 <Eddi|zuHause> i think it's now getting worse with every change i make :/ 21:05:21 <Eddi|zuHause> i need to stop.. 21:05:57 <Eddi|zuHause> i don't quite understand it, it's fine in one half of the map, but then there's that other half where it goes completely bonkers 21:15:02 *** nielsm has quit IRC 21:17:39 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN updated pull request #6811: Feature: Add NotRoadTypes (NRT) https://git.io/vhlfg 21:21:29 <peter1138> Hmm. 21:21:29 <peter1138> LordAro, well... http://fuzzle.org/~petern/wip-nrt-aidocs/ai__changelog_8hpp.html 21:21:29 <peter1138> So maybe that'll work, maybe it won't :p 21:26:19 <andythenorth> :) 21:26:30 *** gelignite has quit IRC 21:26:41 <andythenorth> Eddi|zuHause: let it rest a while :) 21:26:56 <andythenorth> the fundamental approach looks sound, details can wait 21:28:21 *** Progman has quit IRC 21:30:36 <peter1138> Like dough, it needs to rest? 21:30:56 <DorpsGek_II> [OpenTTD/OpenTTD] LordAro approved pull request #7214: Fix network revision for tagged versions https://git.io/fhQdx 21:31:17 <Eddi|zuHause> in other news, switching between amdgpu and radeon drivers, improves half of the performance issues, but makes the other half worse 21:31:45 <Eddi|zuHause> peter1138: i'm probably using the priority queue wrong :/ 21:32:46 <DorpsGek_II> [OpenTTD/OpenTTD] LordAro merged pull request #7214: Fix network revision for tagged versions https://git.io/fhHjs 21:34:50 *** m3henry has joined #openttd 21:36:00 <DorpsGek_II> [OpenTTD/OpenTTD] LordAro requested changes for pull request #7219: Change: Use SlErrorCorrupt() on pool index error when loading a savegame, instead of terminating. https://git.io/fhQFf 21:39:12 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on pull request #7219: Change: Use SlErrorCorrupt() on pool index error when loading a savegame, instead of terminating. https://git.io/fhQFJ 21:44:33 *** frosch123 has quit IRC 21:47:54 <DorpsGek_II> [OpenTTD/OpenTTD] LordAro approved pull request #7220: Change: Increase maximum number of orders from 64000 to ~16.7m. https://git.io/fhQFk 21:48:34 <peter1138> Not sure that one is really needed, just did it out of curiosity and Samu's savegames. 21:48:54 <LordAro> well you shouldn't have opened the PR then :p 21:49:07 <peter1138> Haha 21:49:08 <peter1138> True. 21:49:31 <LordAro> ideally speaking the limits should all be "unreachable" in all but the most extreme games 21:51:24 <DorpsGek_II> [OpenTTD/OpenTTD] M3Henry updated pull request #7165: [core] Implement SmallVector using std::vector https://git.io/fhSz0 21:51:30 <peter1138> Mmmhmm. 21:51:38 * m3henry Will want feedback on the last commit before continuing 21:51:40 <peter1138> Hmm, not sure about using externs. 21:51:56 <peter1138> But yeah, those includes can be a bit heavy. 21:53:16 <LordAro> yeah, mm, i doubt it's a huge issue, but it was nice that pool was as self-contained as it was before 21:55:48 <LordAro> m3henry: i've definitely run into the NetworkAddress weirdness before 21:55:53 <LordAro> it's not a nice class 21:56:05 <m3henry> It's something that needs attention in the future 21:56:28 <LordAro> also &*std::find is terribly ugly, but it'd need rather more refactoring to make it nicer 21:56:31 <LordAro> idk 21:56:34 <m3henry> const_cast should only really be needed for talking to C libraries 21:57:49 <m3henry> &* can probably be replaced with just storing the iterator 22:00:22 <LordAro> m3henry: and to save me actually making a review, i think it should be "operator==(foobar)" - no spaces 22:00:48 <LordAro> ...except that mirrors operator!= 22:00:50 <LordAro> fine. 22:01:29 <LordAro> in fact, it's weird that != was already defined and == was not, i'd prefer != be defined in terms of ==, rather than the other way around 22:02:00 <LordAro> but we're stepping into general refactoring lands now 22:02:14 <LordAro> maybe just keep a list of stuff to do for a follow up PR :) 22:03:51 <m3henry> I think keeping a note for later is best :3 22:07:56 <DorpsGek_II> [OpenTTD/OpenTTD] M3Henry updated pull request #7165: [core] Implement SmallVector using std::vector https://git.io/fhSz0 22:08:10 <m3henry> Just fixing the Win32/beos build 22:09:08 <LordAro> heh 22:09:54 <peter1138> beos lol 22:14:04 <LordAro> m3henry: but it looks fine, as far as i can tell 22:35:49 *** Gja has quit IRC 22:43:22 <andythenorth> well 22:43:24 <andythenorth> bed I guess 22:43:24 *** andythenorth has left #openttd 23:00:26 <DorpsGek_II> [OpenTTD/OpenTTD] M3Henry updated pull request #7165: [core] Implement SmallVector using std::vector https://git.io/fhSz0 23:09:42 *** m3henry has quit IRC 23:13:43 *** Flygon has joined #openttd 23:14:05 *** octernion has quit IRC 23:15:07 *** Wolf01 has quit IRC