IRC logs for #openttd on OFTC at 2019-02-12
⏴ go to previous day
00:00:12 *** Thedarkb-T60 has joined #openttd
00:05:52 <samu> hmm video scrolling is a bit slower than it used to be
00:15:11 <samu> looks like 500 opcodes is too little
00:26:59 <samu> trying with 1500 opcodes
00:28:35 <samu> 1500 opcodes is already below 33 fps
01:01:50 *** ChanServ sets mode: +v tokai
01:24:54 *** supermop_work has joined #openttd
01:30:08 *** supermop_work_ has quit IRC
01:34:30 *** supermop_work_ has joined #openttd
02:03:54 *** Wormnest has joined #openttd
02:16:03 *** supermop_work_ has quit IRC
02:19:26 *** Thedarkb-X40 has joined #openttd
03:01:30 *** supermop_Home has joined #openttd
03:46:05 *** snail_UES_ has joined #openttd
08:14:12 <Eddi|zuHause> weather even worse...
08:29:50 *** Gustavo6046 has joined #openttd
10: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
10:40:16 *** m3henry has joined #openttd
10: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
11: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
11:54:18 *** Extrems has joined #openttd
12: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
12: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
13:26:33 <peter1138> 16k maps will use tons of ram. Well, no shit :p
13:31:34 <DorpsGek> Eddi|zuHause: 2097152
13:41:40 <Eddi|zuHause> hm... been digging through the internet, and found a "hpet=disable" boot option, gonna try that...
13:43:56 *** Eddi|zuHause has joined #openttd
13:59:57 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on pull request #7209: Fix: volume slider behavior in music gui https://git.io/fhQir
14:01:24 <FLHerne> What on earth does anyone need a 16k map for?
14:02:07 *** andythenorth has joined #openttd
14:02:31 <FLHerne> 2k is already big enough for all companies to build a large network without any significant overlaps or competition
14:02:48 <FLHerne> (which is normal, and a pity)
14:03:31 <peter1138> Competition seems to be frowned upon, as if 'cargo stealing' is a thing...
14:03:57 <FLHerne> I can see it from secondary industries
14:05:04 <FLHerne> (all the cargo is produced through the supplier's efforts, and more practically there are usually space problems)
14:05:09 * andythenorth doesn't understand anything
14:05:31 <FLHerne> For primaries, sharing is a benefit if anything, because of the rating...
14:06:44 <Eddi|zuHause> hm... it's still using hpet for... something
14:09:03 <peter1138> But it's not the supplier's cargo. It's not the supplier's industry.
14:09:32 <peter1138> And sure, it hurts if someone takes from an industry you are serving, but that's the game.
14:09:42 <peter1138> And then servers come along and say it's against the rules... o_O
14: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
14:10:46 <FLHerne> And have more-concentrated sources
14:11:03 <FLHerne> Which doesn't seem at all fair on the early ones
14:11:22 <andythenorth> oh we're doing 16k maps?
14:11:33 <andythenorth> well MOAR IS BETTER
14:11:51 <FLHerne> I really don't get this
14:12:06 <andythenorth> means we can say no to more features, due to performance and RAM concerns
14: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
14:13:05 <FLHerne> And then all the constraints like bridge data, neighbouring railtypes etc. just vanish
14: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
14:14:06 <andythenorth> don't we need to shard to do 16k maps?
14:14:32 * andythenorth pretends TB said he wanted to do it
14:14:49 <peter1138> We're not doing 16k maps :p
14:15:01 <andythenorth> and something to keep edge tiles in sync
14:15:11 <andythenorth> when we've done that, we can also arrange them vertically
14:15:38 * andythenorth goes back to painting opening doors on pax coaches
14:18:38 <andythenorth> oof my last commit message is wrong
14:18:51 <andythenorth> googling how to fix that gets me nothing useful
14:19:46 <andythenorth> 'install this random mercurial extension, then create a queue, then edit history, then replace history'
14:20:33 <FLHerne> I think hg has comprehensively lost the vcs war by now :P
14:20:39 <andythenorth> it lost 5 years ago
14:20:49 <andythenorth> the lolz is that it's supposed to be 'easier'
14:21:15 <andythenorth> it's version control for people who don't understand version control
14:21:21 <andythenorth> but it lost that to Dropbox
14:22:28 <Eddi|zuHause> uhm... hg has a feature very similar to "amend"
14:23:25 <andythenorth> oh I can just import a hg repo to github
14:23:30 <andythenorth> did that with nml already
14:23:47 <andythenorth> maybe I should do that, and let bundles die
14:23:49 <andythenorth> kind of sad though
14:35:44 <Eddi|zuHause> # cat /sys/devices/system/clocksource/clocksource0/current_clocksource
14:35:58 <Eddi|zuHause> wtf is the "hpet=disable" boot option doing then?!?
14:37:26 <Eddi|zuHause> (mind you, i might be treating a symptom)
14:38:44 *** Extrems has joined #openttd
14:40:16 <Eddi|zuHause> andythenorth: like i said, bundles should be able to compile from a git repo
14:41:08 *** snail_UES_ has joined #openttd
15:23:29 <samu> I've been comparing 2500 opcodes very fast versus 10000 opcodes medium
15:36:36 <samu> so uhm... I'd like to suggest new defaults for #opcodes and competitor speed based on this
15:37:24 <samu> 2500 opcodes and very fast, which is very much equivalent to the current 10000/medium
15:37:42 <samu> except that fps spikes are less sensed
15:39:27 <samu> but I'm still testing several ais, just to make sure
15:41:02 *** supermop_work has joined #openttd
15: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
15:42:30 *** supermop_work_ has joined #openttd
15:46:20 *** andythenorth has left #openttd
15:49:12 *** octernion has joined #openttd
15:56:46 <Eddi|zuHause> i think i fixed the pathological DFS case now
15:57:17 <Eddi|zuHause> randomness in direction might need some bias to go away from the origin basin
15:57:49 <Eddi|zuHause> on smoother maps i get unfocused networks where you can't follow from where to where it's flowing
16: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
16:21:52 <samu> how's these averages calculated? they seem wrong
16: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
16:28:17 <FLHerne> Eddi|zuHause: Idea: For river generation, give each corner a fractional height based on smoothing across a number of tiles
16:28:46 <FLHerne> (does that already exist at the terrain-generation stage, before rounding?)
16:29:35 <Eddi|zuHause> river generation currently happens when the terrain is already rounded to tileheights
16: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
16:30:52 <FLHerne> Yes, I was just thinking it might be easier to preserve that than recalculate something similar
16: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?
16: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)
16:31:34 *** sla_ro|master has joined #openttd
16:32:04 <Eddi|zuHause> and fixing the slopes afterwards is tricky
16:32:52 <FLHerne> Could you mark unsuitably-sloped tiles as impassable for the river pathfinder?
16:33:19 <FLHerne> Only letting it consider tiles it can actually build on
16:33:21 <Eddi|zuHause> you can do that only after the sub-height information is already lost
16:33:41 <Eddi|zuHause> that's how my current approach works
16:33:52 <Eddi|zuHause> but the two approaches are mutually exclusive
16:34:20 <FLHerne> I don't see why both sets of information can't exist simultaneously...
16: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
16:35:14 <samu> well, you need mucho towns, so perhaps a 4k map to test that
16:35:22 <Eddi|zuHause> but i already use some of those :p
16:35:31 <samu> and ais,... hmm not sure, mine used to constantly calc closest town for airports
16:35:45 <FLHerne> I mean, for road/rail/trees/blah, none of which exist at that stage
16:35:53 <FLHerne> (that might also be what you meant)
16: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
16:36:34 <FLHerne> OK, but why do they /have/ to be?
16:36:56 <FLHerne> Moving free()/delete calls isn't that hard :P
16: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)
16:38:05 <Eddi|zuHause> FLHerne: keep in mind that the terrain generator is isolated, as there can be different ones
16:38:40 <samu> not entirely sure, maybe terron?
16:39:17 <nielsm> the one with voronoi is significantly faster
16:39:28 <samu> i think clueless does it
16:39:55 <nielsm> I started the game on jan 1st, then loaded the same save in both builds
16:40:23 <samu> perhaps borkai, it uses town cache
16:40:32 <samu> massively, not really sure what kind of cache though
16:41:50 <Eddi|zuHause> so 11 months vs 13 months in the same real time?
16:42:05 *** Gustavo6056 has joined #openttd
16:42:23 *** Gustavo6056 is now known as Gustavo6046
16:44:07 <samu> oh, AIAI has quite irregular performance, might be worth trying
16:44:46 <samu> it's a mix of several AI parts together
16:45:20 *** Wormnest has joined #openttd
16: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
16:50:28 <samu> i'd say, generally AIs that use towns, passengers, airports, bus stations and the like
16:50:55 <samu> those that use industries may not
16: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
16:53:00 <nielsm> 25% improvement is very much worth a 20% memory increase IMO
16:54:12 <samu> mogulai is industry only ai, you are testing it
16:54:18 <samu> does it make a difference?
16:54:33 <nielsm> especially when those 20% memory usage are of 160 MB at most, and not of say 1600 MB
16: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
16:55:41 <nielsm> but it stopped doing that again after a little while
16:55:58 <samu> probably iterating over the list of industries
16:56:08 <samu> not sure if that uses calc closest town, i think not
16: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
16:57:16 <nielsm> uh right with voronoi is running slower now
16:57:34 <nielsm> or rather they're pretty much equal, occasionally one pulling ahead
16:57:53 <nielsm> and now AIAi crashed in voronoi version
16:58:42 <peter1138> Sometimes they do just crash though.
16:58:48 <peter1138> Unless the game itself crashed.
16:58:59 <peter1138> And it's not actually 20%
16:59:57 <peter1138> 0.5MB on a decent size map.
17:01:42 <nielsm> there's a ~30 MB difference in memory usage (according to windows taskmgr) between the two versions here
17:02:15 <peter1138> Memory usage might be AIs themselves.
17:02:24 <peter1138> Or, indeed, sprite cache.
17: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
17:04:25 *** synchris has joined #openttd
17:06:49 <FLHerne> nielsm: I'm not at all convinced that's a representative test, though
17:08:30 <nielsm> let's try murdergame Wentbourne Transport too then
17: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
17:11:01 <FLHerne> I'd be surprised if it's more than even 5% or so in a more typical game
17:11:12 <FLHerne> (yes, I'll eat my words if your test says otherwise)
17:12:52 <nielsm> I'll let wentbourne run for a while longer and see if either pulls ahead
17:13:06 <nielsm> running at about 6.5fps
17: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
17:18:59 <peter1138> Good ol' wentbourne :-)
17:20:37 <peter1138> Linking a research paper on the problem suggests it's not actually a simple problem.
17:26:37 <nielsm> still both at the exact same spot
17: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
17:26:57 <nielsm> so probably no advantage for this case
17:27:17 <peter1138> Where did 25% come from?
17:27:22 <peter1138> Was that just a fluke?
17:27:57 <nielsm> AI's doing initial planning
17:28:28 <nielsm> it's mainly AI and GS getting a performance benefit from this
17:28:50 <nielsm> since they're more likely to query town distances all the time
17:38:40 <samu> usually when planning new routes
17:39:43 <samu> it depends from ai to ai
17:41:17 <samu> i think a good way to test in trying not using fast forward, but experience the lag
17:42:02 <samu> also see which one gets ahead
17:47:21 <samu> the average seems misleading
17:47:48 <samu> it's the average of the last 512 ticks?
17:48:37 <samu> I don't know how to explain - it doesn't feel right
17:49:06 <samu> I'm currently testing 2500 opcodes/veryfast vs 10000 opcodes/medium
17:49:28 <samu> and the 2500 is pulling ahead faster despite averaging higher frame rate
17:49:38 <samu> currently 8 months ahead
17:49:45 *** Lejving_ has joined #openttd
17:55:30 <samu> averaging higher frame time* typo
18: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
18:14:57 <samu> very hard to trigger them
18:16:23 <samu> I wish I had a reliable way to see what causes it
18:26:21 *** HerzogDeXtEr has joined #openttd
18:34:53 *** Eddi|zuHause has joined #openttd
18:35:58 <DorpsGek_II> [OpenTTD/OpenTTD] nikolas commented on pull request #7209: Fix: volume slider behavior in music gui https://git.io/fhQ91
18:58:40 *** Progman has joined #openttd
19: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
19:09:04 <DorpsGek_II> [OpenTTD/OpenTTD] Gabda87 updated pull request #7120: Codechange: Improve performance of closest town lookups with cache https://git.io/fh66E
19: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
19:12:16 *** andythenorth has joined #openttd
19: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
19:17:56 <samu> how do I measure garbage collector time?
19:18:25 <samu> I suspect it to be the cause of these 20 seconds stalls
19:19:27 <samu> print the time in console, kinda like Gabda done for voronoi
19:22:08 <Gabda> maybe it is possible to make a macro for that chrono timing
19:25:12 <Eddi|zuHause> iirc the chrono thing works by object lifetime
19:25:37 <Eddi|zuHause> i.e. you create the object on the stack, and when it gets destroyed, it records the time
19:26:47 <peter1138> No, the chrono thing is just a C++ timer.
19:27:00 <peter1138> The framerate stuff that nielsm wrote does the stack lifetime stuff.
19:28:43 <nielsm> sq_state.cpp:248 is probably where you'd want to measure
19:58:39 <samu> how to convert int to text? wanted to print company id
19:59:27 <Eddi|zuHause> something about ebay hungary
19:59:44 <Eddi|zuHause> and should be available 1st march
20:02:28 <samu> dbg: [misc] [Collect Garbage %dcid] 867 [avg: 867.0]
20:03:00 <peter1138> printf("%d", companyid)
20:08:29 * peter1138 tests Eddi|zuHause's rivers.
20:08:58 <samu> are these milliseconds? picoseconds? something else?
20:09:09 <samu> not sure what number is this
20:09:25 <LordAro> probably not picoseconds
20:12:21 <nielsm> it's some not whole power of ten
20:14:56 <nielsm> the actual meaning probably depends on your cpu and chipset
20:18:08 <peter1138> There's a number to use to average out a bit.
20:19:18 <peter1138> Hmm, very flat rivers.
20:19:23 *** gelignite has joined #openttd
20:19:52 <peter1138> Hmm, I've got river tiles at sealevel.
20:22:38 <samu> 1 - dbg: [misc] [Collect Garbage] 484677120 [avg: 484677120.0] how would I know how much time this is?
20:22:56 <Eddi|zuHause> yeah, i thought i fixed those, but i might have missed some cases
20:24:25 <peter1138> They meander on large plains nicely, but don't really start in nice places.
20:39:04 <andythenorth> Eddi|zuHause: it's unquestionably better IMO
20:39:23 <Eddi|zuHause> yeah, but far from optimal
20:39:54 <nielsm> does it make wide rivers?
20:39:56 * andythenorth compares with 1.8.0
20:40:07 <andythenorth> yeah not optimal on several fronts, but already better than 1.8.0
20:40:17 <andythenorth> biggest point: it makes river networks, not just rivers
20:40:24 <andythenorth> which makes them a lot more useful in-game
20:40:56 <andythenorth> it generates far too many currently though :)
20:43:18 *** frosch123 has joined #openttd
20:43:29 <Eddi|zuHause> it needs to be more aware of how much area it covered for one basin
20: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?
20:43:59 <andythenorth> so half-width rivers? With limited navigability? o_O
20:44:14 <andythenorth> in the upper reaches
20:44:18 <Eddi|zuHause> non-shipable rivers, yes
20:44:35 <andythenorth> does it explicitly avoid slopes currently?
20:44:55 <andythenorth> I don't like the default ones running up mountains
20:45:09 <Eddi|zuHause> it also avoids higher-level basins if it can reach a lower level one
20:45:40 <Eddi|zuHause> which sometimes causes odd "runs along a slope" situations
20: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
20:46:49 <andythenorth> it's created some fantastic networks, with 20 or so tributaries
20:47:24 <samu> how to convert to milliseconds or so
20:47:46 <Eddi|zuHause> yeah, but in large areas i tend to get lost on which direction is now to the sea :p
20:48:21 <andythenorth> is map gen still broken with MHL?
20:48:26 <andythenorth> or am I just getting weird random
20:48:32 <peter1138> Avoiding slopes? Hmm, maybe avoiding long slopes.
20:48:38 <andythenorth> can't get mountains in temperate, height level is 24
20:48:46 <peter1138> andythenorth, that's variety that's broken.
20:48:56 <andythenorth> oof I'll turn it off
20:49:06 <andythenorth> yeah way better now
20: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
20:49:49 <peter1138> Are you doing sea-inwards?
20: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
20:52:13 <Eddi|zuHause> next plan is to make rivers wider with higher flow numbers
20:52:26 <andythenorth> ^ got caught on a few edge cases
20:52:34 <andythenorth> is it mis-detecting coast slopes?
20:53:03 <Eddi|zuHause> i thought i had tried to avoid those cases, but maybe i broke it
20:54:15 <andythenorth> pretty close though eh?
20:56:05 <andythenorth> is this PR getting built by CI?
21:07:31 <Eddi|zuHause> oh i found it, flipped a bool expression the wrong way around :p
21:08:59 <Eddi|zuHause> hm, still not 100% fixed
21:13:52 *** octernion has joined #openttd
21:20:19 <peter1138> Oh wow, I'd forgotten about pixeltool
21:21:31 <Eddi|zuHause> dangit, i fixed the size calculation, but that made it into DFS mode again...
21:31:10 <Eddi|zuHause> i can't fix one thing without breaking the other :/
21:33:34 <samu> question, what happens if garbage collector is never run?
21: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
21:41:59 <samu> the 20 second stalls haven't occured yet :(
21:42:08 <samu> i'm getting some of about 4 seconds
21:42:20 <samu> it's not caused by garbage collector :(
21:42:35 <peter1138> Didn't think it would be.
21:43:07 <peter1138> Mmm, artisan white chocolate. It's like normal white chocolate but less sweet and more expensive.
21:43:15 <samu> max i've noticed from garbage collector is about 180 ms
21:43:33 <samu> if the graph doesn't lie, that is
21:43:35 <peter1138> Do a TIC/TOC on the valuator stuff.
21:43:50 <samu> I tried, but no idea how to interpret the result
21:46:42 <peter1138> Wondering how to document the AI changes I've made, bearing in mind they're not set in stone yet.
21:49:12 <LordAro> i presume you mean beyond the usual doxygen stuff?
21:49:26 <peter1138> Well, is that sufficient?
21:49:50 <LordAro> a few sentences in the changelog as well, probably
21:50:00 <peter1138> enum AIRoad::RoadSubType
21:50:01 <peter1138> Types of rail known to the game.
21:50:38 *** Thedarkb-T60 has joined #openttd
21:51:53 <peter1138> I've not been writing changelogs :)
21:52:04 <peter1138> Maybe I should rebase and squash.
21:52:15 <LordAro> and also game_changelog.hpp, i imagine
22:01:59 <peter1138> Hmm, not sure if all these functions apply to a GS
22:04:07 <peter1138> Well, seem to be there for existing stuff, so ok.
22:05:17 <Eddi|zuHause> i think it's now getting worse with every change i make :/
22:05:21 <Eddi|zuHause> i need to stop..
22: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
22:20:51 <peter1138> So maybe that'll work, maybe it won't :p
22:26:41 <andythenorth> Eddi|zuHause: let it rest a while :)
22:26:56 <andythenorth> the fundamental approach looks sound, details can wait
22:30:36 <peter1138> Like dough, it needs to rest?
22: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
22:31:45 <Eddi|zuHause> peter1138: i'm probably using the priority queue wrong :/
22:34:50 *** m3henry has joined #openttd
22: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
22: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
22: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
22:48:34 <peter1138> Not sure that one is really needed, just did it out of curiosity and Samu's savegames.
22:48:54 <LordAro> well you shouldn't have opened the PR then :p
22:49:31 <LordAro> ideally speaking the limits should all be "unreachable" in all but the most extreme games
22:51:24 <DorpsGek_II> [OpenTTD/OpenTTD] M3Henry updated pull request #7165: [core] Implement SmallVector using std::vector https://git.io/fhSz0
22:51:38 * m3henry Will want feedback on the last commit before continuing
22:51:40 <peter1138> Hmm, not sure about using externs.
22:51:56 <peter1138> But yeah, those includes can be a bit heavy.
22: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
22:55:48 <LordAro> m3henry: i've definitely run into the NetworkAddress weirdness before
22:55:53 <LordAro> it's not a nice class
22:56:05 <m3henry> It's something that needs attention in the future
22:56:28 <LordAro> also &*std::find is terribly ugly, but it'd need rather more refactoring to make it nicer
22:56:34 <m3henry> const_cast should only really be needed for talking to C libraries
22:57:49 <m3henry> &* can probably be replaced with just storing the iterator
23:00:22 <LordAro> m3henry: and to save me actually making a review, i think it should be "operator==(foobar)" - no spaces
23:00:48 <LordAro> ...except that mirrors operator!=
23: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
23:02:00 <LordAro> but we're stepping into general refactoring lands now
23:02:14 <LordAro> maybe just keep a list of stuff to do for a follow up PR :)
23:03:51 <m3henry> I think keeping a note for later is best :3
23:07:56 <DorpsGek_II> [OpenTTD/OpenTTD] M3Henry updated pull request #7165: [core] Implement SmallVector using std::vector https://git.io/fhSz0
23:08:10 <m3henry> Just fixing the Win32/beos build
23:14:04 <LordAro> m3henry: but it looks fine, as far as i can tell
23:43:24 *** andythenorth has left #openttd
continue to next day ⏵
