Log for #openttd on 12th February 2019:
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
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
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
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
11:39:45  <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on pull request #7120: Codechange: Improve performance of closest town lookups with cache
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
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>
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
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
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
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>  <-- 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
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
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:
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
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>
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
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
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
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
18:09:04  <DorpsGek_II> [OpenTTD/OpenTTD] Gabda87 updated pull request #7120: Codechange: Improve performance of closest town lookups with cache
18:12:12  <DorpsGek_II> [OpenTTD/OpenTTD] Gabda87 commented on pull request #7120: Codechange: Improve performance of closest town lookups with cache
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>
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:
18:44:55  *** Wolf01 has joined #openttd
18:45:26  <samu> alright let me try
18:45:31  <Wolf01> o/
18:50:31  <Wolf01> 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 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
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
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 :),%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>
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)
21:21:29  <peter1138> Hmm.
21:21:29  <peter1138> LordAro, well...
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
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
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.
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.
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.
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
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
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
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

Powered by YARRSTE version: svn-trunk