Back to Home / #openttd / 2019 / 02 / Prev Day | Next Day
#openttd IRC Logs for 2019-02-12

---Logopened Tue Feb 12 00:00:01 2019
00:28-!-Gustavo6046 [~Gustavo60@2804:14d:4cd8:81a4:e886:adf:66fc:f6b3] has quit [Ping timeout: 480 seconds]
00:31-!-snail_UES_ [~snail_UES@cpe-98-14-137-148.nyc.res.rr.com] has quit [Quit: snail_UES_]
01:49<@peter1138>morning
02:14<Eddi|zuHause>weather even worse...
02:29-!-Gustavo6046 [~Gustavo60@2804:14d:4cd8:81a4:e886:adf:66fc:f6b3] has joined #openttd
02:29-!-Gustavo6046 is "Non dico nomen." on #openttd #oftc #moocows
03:47-!-supermop_Home [~user@pool-71-105-225-37.nycmny.fios.verizon.net] has quit [Ping timeout: 480 seconds]
04:37<DorpsGek_II>[OpenTTD/OpenTTD] Gabda87 commented on pull request #7120: Codechange: Improve performance of closest town lookups with cache https://git.io/fhQrU
04:40-!-m3henry [~oftc-webi@62.232.243.6] has joined #openttd
04:40-!-m3henry is "OFTC WebIRC Client" on #openttd
04:53<DorpsGek_II>[OpenTTD/OpenTTD] Gabda87 commented on pull request #7120: Codechange: Improve performance of closest town lookups with cache https://git.io/fhQr4
05:13-!-Westie [~oftc@176.31.53.128] has joined #openttd
05:13-!-Westie is "oftc" on #openttd
05:14-!-Westie [~oftc@176.31.53.128] has quit []
05:18-!-Westie [~oftc@176.31.53.128] has joined #openttd
05:18-!-Westie is "oftc" on #openttd
05:22-!-Westie [~oftc@176.31.53.128] has quit []
05:22-!-Westie [~oftc@176.31.53.128] has joined #openttd
05:22-!-Westie is "oftc" on #openttd
05:40<DorpsGek_II>[OpenTTD/OpenTTD] ldpl commented on pull request #7120: Codechange: Improve performance of closest town lookups with cache https://git.io/fhQoj
05:46-!-Extrems [gamecube@expert.extremscorner.org] has quit [Ping timeout: 480 seconds]
05:54-!-Extrems [gamecube@expert.extremscorner.org] has joined #openttd
05:54-!-Extrems is "https://www.extremscorner.org/" on #openttd
06:30<DorpsGek_II>[OpenTTD/OpenTTD] Gabda87 commented on pull request #7120: Codechange: Improve performance of closest town lookups with cache https://git.io/fhQKQ
06:39<DorpsGek_II>[OpenTTD/OpenTTD] PeterN commented on pull request #7120: Codechange: Improve performance of closest town lookups with cache https://git.io/fhQ6U
07:14-!-Flygon [~Flygon@dsl-124-150-7-189.vic.westnet.com.au] has quit [Quit: A toaster's basically a soldering iron designed to toast bread]
07:26<@peter1138>16k maps will use tons of ram. Well, no shit :p
07:31<Eddi|zuHause>@calc 2**(6+15)
07:31<@DorpsGek>Eddi|zuHause: 2097152
07:35<@peter1138>3.2GB
07:41<Eddi|zuHause>hm... been digging through the internet, and found a "hpet=disable" boot option, gonna try that...
07:41-!-Eddi|zuHause [~johekr@p4FF894F7.dip0.t-ipconnect.de] has quit []
07:43-!-Eddi|zuHause [~johekr@p4FF894F7.dip0.t-ipconnect.de] has joined #openttd
07:43-!-Eddi|zuHause is "Johannes E. Krause" on #openttd
07:59<DorpsGek_II>[OpenTTD/OpenTTD] PeterN commented on pull request #7209: Fix: volume slider behavior in music gui https://git.io/fhQir
08:01<FLHerne>What on earth does anyone need a 16k map for?
08:02-!-andythenorth [~andytheno@cpc87219-aztw31-2-0-cust178.18-1.cable.virginm.net] has joined #openttd
08:02-!-andythenorth is "andythenorth" on #openttd
08:02<FLHerne>2k is already big enough for all companies to build a large network without any significant overlaps or competition
08:02<FLHerne>(which is normal, and a pity)
08:03<@peter1138>Competition seems to be frowned upon, as if 'cargo stealing' is a thing...
08:03<FLHerne>I can see it from secondary industries
08:04<@peter1138>It's not!
08:05<FLHerne>(all the cargo is produced through the supplier's efforts, and more practically there are usually space problems)
08:05*andythenorth doesn't understand anything
08:05<FLHerne>For primaries, sharing is a benefit if anything, because of the rating...
08:06<Eddi|zuHause>hm... it's still using hpet for... something
08:09<@peter1138>But it's not the supplier's cargo. It's not the supplier's industry.
08:09<@peter1138>And sure, it hurts if someone takes from an industry you are serving, but that's the game.
08:09<@peter1138>And then servers come along and say it's against the rules... o_O
08:09<FLHerne>Eh
08:10<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
08:10<FLHerne>And have more-concentrated sources
08:11<FLHerne>Which doesn't seem at all fair on the early ones
08:11<andythenorth>oh we're doing 16k maps?
08:11<andythenorth>well MOAR IS BETTER
08:11<FLHerne>I hope not :-/
08:11<FLHerne>I really don't get this
08:12<andythenorth>means we can say no to more features, due to performance and RAM concerns
08:12<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
08:13<FLHerne>And then all the constraints like bridge data, neighbouring railtypes etc. just vanish
08:13<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
08:13<andythenorth>err
08:14<andythenorth>don't we need to shard to do 16k maps?
08:14*andythenorth pretends TB said he wanted to do it
08:14<@peter1138>We're not doing 16k maps :p
08:14<andythenorth>4x4k
08:15<andythenorth>and something to keep edge tiles in sync
08:15<andythenorth>when we've done that, we can also arrange them vertically
08:15<andythenorth>for underground
08:15*andythenorth goes back to painting opening doors on pax coaches
08:18<andythenorth>oof my last commit message is wrong
08:18<andythenorth>googling how to fix that gets me nothing useful
08:18<andythenorth>nvm
08:19<andythenorth>'install this random mercurial extension, then create a queue, then edit history, then replace history'
08:19<andythenorth>wat?
08:19<@peter1138>git commit --amend
08:20<andythenorth>yeah wrong vcs
08:20<@peter1138>Stop doing that :/
08:20<andythenorth>yeah that
08:20<FLHerne>I think hg has comprehensively lost the vcs war by now :P
08:20<andythenorth>it lost 5 years ago
08:20<andythenorth>the lolz is that it's supposed to be 'easier'
08:21<andythenorth>it's version control for people who don't understand version control
08:21<andythenorth>but it lost that to Dropbox
08:22<Eddi|zuHause>uhm... hg has a feature very similar to "amend"
08:22<@peter1138>https://stackoverflow.com/questions/17970341/migrating-from-mercurial-to-git
08:23<andythenorth>oh I can just import a hg repo to github
08:23<andythenorth>did that with nml already
08:23<andythenorth>maybe I should do that, and let bundles die
08:23<andythenorth>kind of sad though
08:35<Eddi|zuHause># cat /sys/devices/system/clocksource/clocksource0/current_clocksource
08:35<Eddi|zuHause>hpet
08:35<Eddi|zuHause>wtf is the "hpet=disable" boot option doing then?!?
08:37<Eddi|zuHause>(mind you, i might be treating a symptom)
08:37-!-Extrems [gamecube@expert.extremscorner.org] has quit [Ping timeout: 480 seconds]
08:38-!-Extrems [gamecube@expert.extremscorner.org] has joined #openttd
08:38-!-Extrems is "https://www.extremscorner.org/" on #openttd
08:40<Eddi|zuHause>andythenorth: like i said, bundles should be able to compile from a git repo
08:41-!-snail_UES_ [~snail_UES@cpe-98-14-137-148.nyc.res.rr.com] has joined #openttd
08:41-!-snail_UES_ is "Jacopo Coletto" on #openttd
08:52-!-m3henry [~oftc-webi@62.232.243.6] has quit [Remote host closed the connection]
08:58-!-snail_UES_ [~snail_UES@cpe-98-14-137-148.nyc.res.rr.com] has quit [Quit: snail_UES_]
09:07-!-samu [~oftc-webi@pa4-84-91-142-34.netvisao.pt] has joined #openttd
09:07-!-samu is "OFTC WebIRC Client" on #openttd
09:08<samu>hi
09:23<samu>I've been comparing 2500 opcodes very fast versus 10000 opcodes medium
09:27<samu>seems to be equal
09:27<samu>but less spiky
09:27<samu>with 2500 opcodes
09:36<samu>so uhm... I'd like to suggest new defaults for #opcodes and competitor speed based on this
09:37<samu>2500 opcodes and very fast, which is very much equivalent to the current 10000/medium
09:37<samu>except that fps spikes are less sensed
09:37<samu>it's smooth
09:39<samu>but I'm still testing several ais, just to make sure
09:41-!-supermop_work [~supermopw@38.105.230.30] has joined #openttd
09:41-!-supermop_work is "A CIRC user" on #openttd
09:41<DorpsGek_II>[OpenTTD/OpenTTD] ldpl commented on pull request #7120: Codechange: Improve performance of closest town lookups with cache https://git.io/fhQ1D
09:41<samu>repetition
09:42-!-supermop_work_ [~supermopw@38.105.230.30] has joined #openttd
09:42-!-supermop_work_ is "A CIRC user" on #openttd
09:43-!-nielsm [~nielsm@176-23-103-56-cable.dk.customer.tdc.net] has joined #openttd
09:43-!-nielsm is "Niels Martin Hansen" on #openttd
09:46-!-andythenorth [~andytheno@cpc87219-aztw31-2-0-cust178.18-1.cable.virginm.net] has left #openttd []
09:49-!-supermop_work [~supermopw@38.105.230.30] has quit [Ping timeout: 480 seconds]
09:49-!-octernion [~octernion@206.223.172.50] has joined #openttd
09:49-!-octernion is "octernion" on #openttd
09:56<DorpsGek_II>[OpenTTD/OpenTTD] Eddi-z updated pull request #7213: Feature: BFS-based river generator https://git.io/fhHN6
09:56<Eddi|zuHause>i think i fixed the pathological DFS case now
09:57<Eddi|zuHause>randomness in direction might need some bias to go away from the origin basin
09:57<Eddi|zuHause>on smoother maps i get unfocused networks where you can't follow from where to where it's flowing
10:20<samu>weird stuff
10:21<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
10:21<samu>how's these averages calculated? they seem wrong
10:24<DorpsGek_II>[OpenTTD/OpenTTD] Gabda87 commented on pull request #7120: Codechange: Improve performance of closest town lookups with cache https://git.io/fhQMh
10:28<FLHerne>Eddi|zuHause: Idea: For river generation, give each corner a fractional height based on smoothing across a number of tiles
10:28<FLHerne>(does that already exist at the terrain-generation stage, before rounding?)
10:29<Eddi|zuHause>river generation currently happens when the terrain is already rounded to tileheights
10:30<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
10:30<FLHerne>Yes, I was just thinking it might be easier to preserve that than recalculate something similar
10:31<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?
10:31<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)
10:31-!-sla_ro|master [~sla.ro@84.117.88.126] has joined #openttd
10:31-!-sla_ro|master is "slamaster" on #sla #openttd
10:32<Eddi|zuHause>and fixing the slopes afterwards is tricky
10:32<FLHerne>Hm
10:32<FLHerne>Could you mark unsuitably-sloped tiles as impassable for the river pathfinder?
10:33<FLHerne>Only letting it consider tiles it can actually build on
10:33<Eddi|zuHause>you can do that only after the sub-height information is already lost
10:33<Eddi|zuHause>that's how my current approach works
10:33<Eddi|zuHause>but the two approaches are mutually exclusive
10:34<FLHerne>I don't see why both sets of information can't exist simultaneously...
10:35<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
10:35<samu>well, you need mucho towns, so perhaps a 4k map to test that
10:35<Eddi|zuHause>but i already use some of those :p
10:35<samu>and ais,... hmm not sure, mine used to constantly calc closest town for airports
10:35<samu>but not any more
10:35<FLHerne>I mean, for road/rail/trees/blah, none of which exist at that stage
10:35<FLHerne>(that might also be what you meant)
10:36<Eddi|zuHause>but generally, the TGP noise heights aren't stored in the map array at all, they are discarded right after terrain generation
10:36<FLHerne>OK, but why do they /have/ to be?
10:36<FLHerne>Moving free()/delete calls isn't that hard :P
10:37<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)
10:38<Eddi|zuHause>FLHerne: keep in mind that the terrain generator is isolated, as there can be different ones
10:38<samu>i suspect simpleai?
10:38<samu>dictator ai
10:38<samu>not entirely sure, maybe terron?
10:38<samu>have to recheck
10:39<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
10:39<nielsm>the one with voronoi is significantly faster
10:39<samu>oh, clueless
10:39<samu>i think clueless does it
10:39<nielsm>I started the game on jan 1st, then loaded the same save in both builds
10:40<samu>perhaps borkai, it uses town cache
10:40<samu>massively, not really sure what kind of cache though
10:41<Eddi|zuHause>so 11 months vs 13 months in the same real time?
10:42-!-Gustavo6056 [~Gustavo60@189.6.240.114] has joined #openttd
10:42-!-Gustavo6056 is "Non dico nomen." on #openttd #oftc #moocows
10:42-!-Gustavo6046 [~Gustavo60@2804:14d:4cd8:81a4:e886:adf:66fc:f6b3] has quit [Quit: Non video lux in futurum.]
10:42-!-Gustavo6056 is now known as Gustavo6046
10:44<samu>oh, AIAI has quite irregular performance, might be worth trying
10:44<samu>it's a mix of several AI parts together
10:45-!-Wormnest [~Wormnest@35.136.176.177] has joined #openttd
10:45-!-Wormnest is "Wormnest" on #openttd
10:48<DorpsGek_II>[OpenTTD/OpenTTD] nielsmh commented on pull request #7120: Codechange: Improve performance of closest town lookups with cache https://git.io/fhQDX
10:50<samu>i'd say, generally AIs that use towns, passengers, airports, bus stations and the like
10:50<samu>those that use industries may not
10:51<DorpsGek_II>[OpenTTD/OpenTTD] nielsmh commented on pull request #7120: Codechange: Improve performance of closest town lookups with cache https://git.io/fhQDQ
10:53<nielsm>25% improvement is very much worth a 20% memory increase IMO
10:54<samu>mogulai is industry only ai, you are testing it
10:54<samu>does it make a difference?
10:54<nielsm>especially when those 20% memory usage are of 160 MB at most, and not of say 1600 MB
10:55<nielsm>I saw one period where MogulAI was pulling the left game down to something like 15-20 fps, with very long frame times
10:55<nielsm>but it stopped doing that again after a little while
10:55<samu>probably iterating over the list of industries
10:56<samu>not sure if that uses calc closest town, i think not
10:57<nielsm>now the right game is running faster, likely just because it's further ahead and has more to simulate as a result :P
10:57<nielsm>uh right with voronoi is running slower now
10:57<nielsm>or rather they're pretty much equal, occasionally one pulling ahead
10:57<nielsm>and now AIAi crashed in voronoi version
10:58<@peter1138>Nice testing.
10:58<@peter1138>Sometimes they do just crash though.
10:58<@peter1138>Unless the game itself crashed.
10:58<@peter1138>And it's not actually 20%
10:59<@peter1138>16.6%
10:59<@peter1138>0.5MB on a decent size map.
11:01<nielsm>there's a ~30 MB difference in memory usage (according to windows taskmgr) between the two versions here
11:01<@peter1138>Hmm.
11:01<@peter1138>4MB for 2048x1024
11:02<@peter1138>Memory usage might be AIs themselves.
11:02<@peter1138>Or, indeed, sprite cache.
11:02<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
11:04-!-synchris [~synchris@139.138.202.72] has joined #openttd
11:04-!-synchris is "Synesios Christou" on #openttd
11:04<nielsm>my test game: https://0x0.st/zzL-.sav
11:06<FLHerne>nielsm: I'm not at all convinced that's a representative test, though
11:08<nielsm>let's try murdergame Wentbourne Transport too then
11:08<nielsm>that's singleplayer
11:09<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
11:11<FLHerne>I'd be surprised if it's more than even 5% or so in a more typical game
11:11<FLHerne>(yes, I'll eat my words if your test says otherwise)
11:12<nielsm>I'll let wentbourne run for a while longer and see if either pulls ahead
11:13<nielsm>running at about 6.5fps
11:15<DorpsGek_II>[OpenTTD/OpenTTD] ldpl commented on pull request #7120: Codechange: Improve performance of closest town lookups with cache https://git.io/fhQyV
11:18<@peter1138>Good ol' wentbourne :-)
11:20<@peter1138>Linking a research paper on the problem suggests it's not actually a simple problem.
11:26<nielsm>still both at the exact same spot
11:26<_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
11:26<nielsm>so probably no advantage for this case
11:27<@peter1138>Where did 25% come from?
11:27<@peter1138>Was that just a fluke?
11:27<nielsm>AI's doing initial planning
11:28<nielsm>it's mainly AI and GS getting a performance benefit from this
11:28<nielsm>since they're more likely to query town distances all the time
11:38<samu>usually when planning new routes
11:38<samu>not "all the time"
11:39<samu>it depends from ai to ai
11:41<samu>i think a good way to test in trying not using fast forward, but experience the lag
11:41<samu>input lag
11:42<samu>also see which one gets ahead
11:42<samu>in months
11:42<samu>running at normal speed
11:47<samu>the average seems misleading
11:47<samu>it's the average of the last 512 ticks?
11:47<samu>measures
11:48<samu>I don't know how to explain - it doesn't feel right
11:49<samu>I'm currently testing 2500 opcodes/veryfast vs 10000 opcodes/medium
11:49<samu>and the 2500 is pulling ahead faster despite averaging higher frame rate
11:49<samu>currently 8 months ahead
11:49<samu>in 6 years
11:49-!-Lejving_ [~Lejving@81-233-148-192-no524.tbcn.telia.com] has joined #openttd
11:49-!-Lejving_ is "realname" on #openttdcoop.pz #mashinky #factoriocoop #/r/openttd #openttd
11:49-!-Lejving_ [~Lejving@81-233-148-192-no524.tbcn.telia.com] has quit [Read error: Connection reset by peer]
11:55<samu>averaging higher frame time* typo
11:56<samu>https://imgur.com/QG0sY2E
11:59-!-Gja [~Martin@93-167-84-102-static.dk.customer.tdc.net] has joined #openttd
11:59-!-Gja is "Martin" on #ceph #bcache #openttd
12:05<DorpsGek_II>[OpenTTD/OpenTTD] Gabda87 commented on pull request #7120: Codechange: Improve performance of closest town lookups with cache https://git.io/fhQ9J
12:14<samu>wow, 19 seconds stall
12:14<samu>sometimes these occur
12:14<samu>very hard to trigger them
12:16<samu>I wish I had a reliable way to see what causes it
12:20<samu>21 second stall https://imgur.com/T57A4IK
12:20<samu>on the right
12:26-!-HerzogDeXtEr [~farci@dslb-188-106-213-038.188.106.pools.vodafone-ip.de] has joined #openttd
12:26-!-HerzogDeXtEr is "purple" on #openttd
12:32-!-Eddi|zuHause [~johekr@p4FF894F7.dip0.t-ipconnect.de] has quit []
12:34-!-Eddi|zuHause [~johekr@p4FF894F7.dip0.t-ipconnect.de] has joined #openttd
12:34-!-Eddi|zuHause is "Johannes E. Krause" on #openttd
12:35<DorpsGek_II>[OpenTTD/OpenTTD] nikolas commented on pull request #7209: Fix: volume slider behavior in music gui https://git.io/fhQ91
12:54-!-Gabda [~Gabda@catv-80-98-39-136.catv.broadband.hu] has joined #openttd
12:54-!-Gabda is "realname" on #openttd
12:58-!-Progman [~progman@p4FD664DE.dip0.t-ipconnect.de] has joined #openttd
12:58-!-Progman is "Peter Henschel" on #openttdcoop.dev #openttd
13:07<DorpsGek_II>[OpenTTD/OpenTTD] nikolas updated pull request #7086: Change #6173: Update SDL driver to use SDL 2.0 https://git.io/fhamZ
13:09<DorpsGek_II>[OpenTTD/OpenTTD] Gabda87 updated pull request #7120: Codechange: Improve performance of closest town lookups with cache https://git.io/fh66E
13:12<DorpsGek_II>[OpenTTD/OpenTTD] Gabda87 commented on pull request #7120: Codechange: Improve performance of closest town lookups with cache https://git.io/fhQHw
13:12-!-andythenorth [~andytheno@cpc87219-aztw31-2-0-cust178.18-1.cable.virginm.net] has joined #openttd
13:12-!-andythenorth is "andythenorth" on #openttd
13:13<andythenorth>error
13:15<@peter1138>What sort?
13:16<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
13:17<samu>how do I measure garbage collector time?
13:18<andythenorth>https://www.tt-forums.net/viewtopic.php?p=1218472#p1218472
13:18<samu>I suspect it to be the cause of these 20 seconds stalls
13:19<samu>I wanna chrono it
13:19<samu>print the time in console, kinda like Gabda done for voronoi
13:22<Gabda>maybe it is possible to make a macro for that chrono timing
13:23<Gabda>like the TIC and TOC
13:25<Eddi|zuHause>iirc the chrono thing works by object lifetime
13:25<Eddi|zuHause>i.e. you create the object on the stack, and when it gets destroyed, it records the time
13:26<@peter1138>No, the chrono thing is just a C++ timer.
13:27<@peter1138>The framerate stuff that nielsm wrote does the stack lifetime stuff.
13:28<nielsm>sq_state.cpp:248 is probably where you'd want to measure
13:38<samu>how to do it?
13:41-!-glx [kvirc@000128ec.user.oftc.net] has joined #openttd
13:41-!-mode/#openttd [+v glx] by ChanServ
13:41-!-glx is "Loïc GUILLOUX" on @#openttd.noai #openttd.notice +#openttd
13:42<nielsm>samu: https://github.com/OpenTTD/OpenTTD/blob/master/src/debug.h#L66-L86
13:44-!-Wolf01 [~wolf01@0001288e.user.oftc.net] has joined #openttd
13:44-!-Wolf01 is "Wolf01" on #openttd
13:45<samu>alright let me try
13:45<Wolf01>o/
13:50<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
13:52-!-Gabda [~Gabda@catv-80-98-39-136.catv.broadband.hu] has quit [Quit: Leaving]
13:54-!-Wormnest [~Wormnest@35.136.176.177] has quit [Ping timeout: 480 seconds]
13:58<Wolf01>Eddi|zuHause: I need your help https://www.stonewars.de/news/lego-10265-ford-mustang-creator-expert/ TL;DR :P
13:58<samu>how to convert int to text? wanted to print company id
13:59<@peter1138>%d
13:59<Eddi|zuHause>something about ebay hungary
13:59<Eddi|zuHause>and should be available 1st march
14:00<Wolf01>Nice
14:01<samu>%d? how?
14:02<samu>dbg: [misc] [Collect Garbage %dcid] 867 [avg: 867.0]
14:02<samu>ugly
14:03<@peter1138>printf("%d", companyid)
14:03<samu>where would I put TOC?
14:08*peter1138 tests Eddi|zuHause's rivers.
14:08<samu>are these milliseconds? picoseconds? something else?
14:09<samu>not sure what number is this
14:09<LordAro>probably not picoseconds
14:12<nielsm>it's some not whole power of ten
14:14<nielsm>the actual meaning probably depends on your cpu and chipset
14:17<samu>oh :|
14:18<@peter1138>There's a number to use to average out a bit.
14:19<@peter1138>Hmm, very flat rivers.
14:19-!-gelignite [~gelignite@55d46d5e.access.ecotel.net] has joined #openttd
14:19-!-gelignite is "gelignite" on #openttd
14:19<@peter1138>Hmm, I've got river tiles at sealevel.
14:22<samu>1 - dbg: [misc] [Collect Garbage] 484677120 [avg: 484677120.0] how would I know how much time this is?
14:22<samu>t.t
14:22<@planetmaker>hi
14:22<Eddi|zuHause>yeah, i thought i fixed those, but i might have missed some cases
14:24<@peter1138>They meander on large plains nicely, but don't really start in nice places.
14:26<DorpsGek_II>[OpenTTD/OpenTTD] LordAro merged pull request #7168: Fix: CompanyEconomy documentation https://git.io/fhSgg
14:32*andythenorth tries rivers
14:39<andythenorth>Eddi|zuHause: it's unquestionably better IMO
14:39<Eddi|zuHause>yeah, but far from optimal
14:39<nielsm>does it make wide rivers?
14:39*andythenorth compares with 1.8.0
14:40<Eddi|zuHause>not yet
14:40<andythenorth>yeah not optimal on several fronts, but already better than 1.8.0
14:40<andythenorth>biggest point: it makes river networks, not just rivers
14:40<andythenorth>which makes them a lot more useful in-game
14:40<andythenorth>it generates far too many currently though :)
14:42<Eddi|zuHause>yes
14:43-!-frosch123 [~frosch@00013ce7.user.oftc.net] has joined #openttd
14:43-!-frosch123 is "frosch" on +#openttd.dev #openttd
14:43<Eddi|zuHause>it needs to be more aware of how much area it covered for one basin
14:43<nielsm>many rivers through flat areas will look odd yeah, maybe try to have flat areas quickly gather rivers into fewer large ones?
14:43<andythenorth>so half-width rivers? With limited navigability? o_O
14:44<andythenorth>in the upper reaches
14:44<Eddi|zuHause>non-shipable rivers, yes
14:44<andythenorth>does it explicitly avoid slopes currently?
14:44<Eddi|zuHause>yes
14:44<andythenorth>probably good
14:44<andythenorth>I don't like the default ones running up mountains
14:45<Eddi|zuHause>it also avoids higher-level basins if it can reach a lower level one
14:45<Eddi|zuHause>which sometimes causes odd "runs along a slope" situations
14:46<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
14:46<andythenorth>it's created some fantastic networks, with 20 or so tributaries
14:47<samu>nielsm: explain me these times https://paste.openttdcoop.org/pasmwbwr2
14:47<samu>how to convert to milliseconds or so
14:47<Eddi|zuHause>yeah, but in large areas i tend to get lost on which direction is now to the sea :p
14:48<andythenorth>is map gen still broken with MHL?
14:48<andythenorth>or am I just getting weird random
14:48<@peter1138>Avoiding slopes? Hmm, maybe avoiding long slopes.
14:48<andythenorth>can't get mountains in temperate, height level is 24
14:48<andythenorth>16 works
14:48<@peter1138>andythenorth, that's variety that's broken.
14:48<andythenorth>oof I'll turn it off
14:49<andythenorth>yeah way better now
14:49<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
14:49<@peter1138>Are you doing sea-inwards?
14:51<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
14:52<andythenorth>this was so nearly perfect :) https://dev.openttdcoop.org/attachments/download/9283/Unnamed,%2001-01-1948.png
14:52<Eddi|zuHause>next plan is to make rivers wider with higher flow numbers
14:52<andythenorth>^ got caught on a few edge cases
14:52<andythenorth>is it mis-detecting coast slopes?
14:52-!-synchris [~synchris@139.138.202.72] has quit [Quit: yeeha!]
14:53<Eddi|zuHause>i thought i had tried to avoid those cases, but maybe i broke it
14:54<andythenorth>pretty close though eh?
14:56<andythenorth>is this PR getting built by CI?
14:58-!-octernion [~octernion@206.223.172.50] has quit [Quit: octernion]
15:07<Eddi|zuHause>oh i found it, flipped a bool expression the wrong way around :p
15:08<Eddi|zuHause>hm, still not 100% fixed
15:13-!-octernion [~octernion@206.223.172.50] has joined #openttd
15:13-!-octernion is "octernion" on #openttd
15:20<@peter1138>Oh wow, I'd forgotten about pixeltool
15:21<Eddi|zuHause>dangit, i fixed the size calculation, but that made it into DFS mode again...
15:31<Eddi|zuHause>i can't fix one thing without breaking the other :/
15:33<samu>question, what happens if garbage collector is never run?
15:34<samu>it appears to be the cause of some stalls, I can notice NoCAB stalls right before the measure comes with the result
15:36-!-sla_ro|master [~sla.ro@84.117.88.126] has quit []
15:41<samu>the 20 second stalls haven't occured yet :(
15:42<samu>i'm getting some of about 4 seconds
15:42<samu>it's not caused by garbage collector :(
15:42<@peter1138>Didn't think it would be.
15:43<@peter1138>Mmm, artisan white chocolate. It's like normal white chocolate but less sweet and more expensive.
15:43<samu>max i've noticed from garbage collector is about 180 ms
15:43<samu>if the graph doesn't lie, that is
15:43<@peter1138>Do a TIC/TOC on the valuator stuff.
15:43<samu>I tried, but no idea how to interpret the result
15:44<samu>https://paste.openttdcoop.org/pasmwbwr2
15:44<samu>1, 9 and 14 are NoCAB
15:45<@peter1138>LordAro, around?
15:45<samu>no, AroAI isn't running
15:46<LordAro>peter1138: possibly
15:46<@peter1138>Wondering how to document the AI changes I've made, bearing in mind they're not set in stone yet.
15:46<@peter1138>For NRT, this is.
15:49<LordAro>i presume you mean beyond the usual doxygen stuff?
15:49<@peter1138>Well, is that sufficient?
15:49<LordAro>i don't see why not
15:49<@peter1138>Ok
15:49<LordAro>a few sentences in the changelog as well, probably
15:50<@peter1138>enum AIRoad::RoadSubType
15:50<@peter1138>Types of rail known to the game.
15:50<@peter1138>Ooo...
15:50<@peter1138>Types of rail :D
15:50<LordAro>haha
15:50-!-Thedarkb-T60 [~Thedarkb-@86-40-231-4-dynamic.agg3.kny.prp-wtd.eircom.net] has joined #openttd
15:50-!-Thedarkb-T60 is "realname" on #oolite #openttd
15:51<@peter1138>Which changelog?
15:51<@peter1138>I've not been writing changelogs :)
15:52<@peter1138>Maybe I should rebase and squash.
15:52<LordAro>ai_changelog.hpp
15:52<LordAro>and also game_changelog.hpp, i imagine
15:52<@peter1138>Oooh
15:52-!-Laedek [~quassel@172.92.127.86] has quit [Quit: Laedek]
15:56-!-Laedek [~quassel@172.92.127.86] has joined #openttd
15:56-!-Laedek is "Laedek" on #openttd
16:01<@peter1138>Hmm, not sure if all these functions apply to a GS
16:04<@peter1138>Well, seem to be there for existing stuff, so ok.
16:05<Eddi|zuHause>i think it's now getting worse with every change i make :/
16:05<Eddi|zuHause>i need to stop..
16:05<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
16:15-!-nielsm [~nielsm@176-23-103-56-cable.dk.customer.tdc.net] has quit [Quit: wroom]
16:17<DorpsGek_II>[OpenTTD/OpenTTD] PeterN updated pull request #6811: Feature: Add NotRoadTypes (NRT) https://git.io/vhlfg
16:21<@peter1138>Hmm.
16:21<@peter1138>LordAro, well... http://fuzzle.org/~petern/wip-nrt-aidocs/ai__changelog_8hpp.html
16:21<@peter1138>So maybe that'll work, maybe it won't :p
16:26<andythenorth>:)
16:26-!-gelignite [~gelignite@55d46d5e.access.ecotel.net] has quit [Quit: Good fight, good night!]
16:26<andythenorth>Eddi|zuHause: let it rest a while :)
16:26<andythenorth>the fundamental approach looks sound, details can wait
16:28-!-Progman [~progman@p4FD664DE.dip0.t-ipconnect.de] has quit [Remote host closed the connection]
16:30<@peter1138>Like dough, it needs to rest?
16:30<DorpsGek_II>[OpenTTD/OpenTTD] LordAro approved pull request #7214: Fix network revision for tagged versions https://git.io/fhQdx
16:31<Eddi|zuHause>in other news, switching between amdgpu and radeon drivers, improves half of the performance issues, but makes the other half worse
16:31<Eddi|zuHause>peter1138: i'm probably using the priority queue wrong :/
16:32<DorpsGek_II>[OpenTTD/OpenTTD] LordAro merged pull request #7214: Fix network revision for tagged versions https://git.io/fhHjs
16:34-!-m3henry [~m3henry@host-212-139-212-35.static.as9105.net] has joined #openttd
16:34-!-m3henry is "realname" on #openttd
16:36<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
16:39<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
16:44-!-frosch123 [~frosch@00013ce7.user.oftc.net] has quit [Quit: be yourself, except: if you have the opportunity to be a unicorn, then be a unicorn]
16:47<DorpsGek_II>[OpenTTD/OpenTTD] LordAro approved pull request #7220: Change: Increase maximum number of orders from 64000 to ~16.7m. https://git.io/fhQFk
16:48<@peter1138>Not sure that one is really needed, just did it out of curiosity and Samu's savegames.
16:48<LordAro>well you shouldn't have opened the PR then :p
16:49<@peter1138>Haha
16:49<@peter1138>True.
16:49<LordAro>ideally speaking the limits should all be "unreachable" in all but the most extreme games
16:51<DorpsGek_II>[OpenTTD/OpenTTD] M3Henry updated pull request #7165: [core] Implement SmallVector using std::vector https://git.io/fhSz0
16:51<@peter1138>Mmmhmm.
16:51*m3henry Will want feedback on the last commit before continuing
16:51<@peter1138>Hmm, not sure about using externs.
16:51<@peter1138>But yeah, those includes can be a bit heavy.
16:53<LordAro>yeah, mm, i doubt it's a huge issue, but it was nice that pool was as self-contained as it was before
16:55<LordAro>m3henry: i've definitely run into the NetworkAddress weirdness before
16:55<LordAro>it's not a nice class
16:56<m3henry>It's something that needs attention in the future
16:56<LordAro>also &*std::find is terribly ugly, but it'd need rather more refactoring to make it nicer
16:56<LordAro>idk
16:56<m3henry>const_cast should only really be needed for talking to C libraries
16:57<m3henry>&* can probably be replaced with just storing the iterator
17:00<LordAro>m3henry: and to save me actually making a review, i think it should be "operator==(foobar)" - no spaces
17:00<LordAro>...except that mirrors operator!=
17:00<LordAro>fine.
17:01<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
17:02<LordAro>but we're stepping into general refactoring lands now
17:02<LordAro>maybe just keep a list of stuff to do for a follow up PR :)
17:03<m3henry>I think keeping a note for later is best :3
17:07<DorpsGek_II>[OpenTTD/OpenTTD] M3Henry updated pull request #7165: [core] Implement SmallVector using std::vector https://git.io/fhSz0
17:08<m3henry>Just fixing the Win32/beos build
17:09<LordAro>heh
17:09<@peter1138>beos lol
17:14<LordAro>m3henry: but it looks fine, as far as i can tell
17:35-!-Gja [~Martin@93-167-84-102-static.dk.customer.tdc.net] has quit []
17:43<andythenorth>well
17:43<andythenorth>bed I guess
17:43-!-andythenorth [~andytheno@cpc87219-aztw31-2-0-cust178.18-1.cable.virginm.net] has left #openttd []
18:00<DorpsGek_II>[OpenTTD/OpenTTD] M3Henry updated pull request #7165: [core] Implement SmallVector using std::vector https://git.io/fhSz0
18:09-!-m3henry [~m3henry@host-212-139-212-35.static.as9105.net] has quit [Quit: Leaving]
18:13-!-Flygon [~Flygon@dsl-124-150-7-189.vic.westnet.com.au] has joined #openttd
18:13-!-Flygon is "Flygon" on #openttd
18:14-!-octernion [~octernion@206.223.172.50] has quit [Ping timeout: 480 seconds]
18:15-!-Wolf01 [~wolf01@0001288e.user.oftc.net] has quit [Quit: Once again the world is quick to bury me.]
19:00<samu>how to make garbage collector less spiky?
19:01-!-tokai|noir [~tokai@00012860.user.oftc.net] has joined #openttd
19:01-!-mode/#openttd [+v tokai|noir] by ChanServ
19:01-!-tokai|noir is "Christian Rosentreter" on +#openttd
19:02<samu>https://imgur.com/zWmNCAD that AI number 5 caused that 400 ms stall
19:08-!-tokai [~tokai@00012860.user.oftc.net] has quit [Ping timeout: 480 seconds]
19:31<+glx>400ms is almost imperceptible
19:36<DorpsGek_II>[OpenTTD/OpenTTD] PeterN updated pull request #7219: Change: Use SlErrorCorrupt() on pool index error when loading a savegame, instead of terminating. https://git.io/fhQLM
19:43<samu>it's half a second
19:44<samu>but hmm
19:44<samu>ok
19:48-!-drac_boy [~oftc-webi@24-212-186-79.cable.teksavvy.com] has joined #openttd
19:48-!-drac_boy is "OFTC WebIRC Client" on #openttd
19:49<drac_boy>hi .. as usual have a few things on mind .. but anyway first one: could a single sprite come in two different colours depending on whether its before or after a particular date? I thought I remembered something about "reload the game to see the new sprites" but forgot who that came from grf-wise
19:49<@peter1138>No it would be a different sprite.
19:50<@peter1138>You're thinking of the old town set that loaded different road graphics depending on the date.
19:52<drac_boy>ah .. yeah that sounds more plausible to my possible memory mixup ty
19:53<drac_boy>hmm dates .. reminds me of ttrs
19:53*drac_boy wonders where that webpage perhaps went to now...
19:53<@peter1138>That's probably the one.
19:53<@peter1138>Total town renewal set :D
19:57<drac_boy>hmm ttrs site is gone no surprise ... but at least I did find a forum mention of ttrs and reloading it to get the newer roads to show up tho :)
19:58<drac_boy>anyway dunno about you but east canada is snowing quite a but now and blizzard expected tomorrow with many things closed for the morning (even gov offices too...!) too .. should be a fun day :-s
19:58<drac_boy>a but = a bit*
20:05-!-Thedarkb-X40 [~beno@86-40-231-4-dynamic.agg3.kny.prp-wtd.eircom.net] has joined #openttd
20:05-!-Thedarkb-X40 is "realname" on #openttd #/r/openttd #oolite
20:07-!-snail_UES_ [~snail_UES@cpe-98-14-137-148.nyc.res.rr.com] has joined #openttd
20:07-!-snail_UES_ is "Jacopo Coletto" on #openttd
20:10<drac_boy>next thing, I'm just curious in theory but is it only locomotives that can be railtypes-restricted or you could probably do the same for wagons by some crazy chance too?
20:10<samu>can I suggest changing defaults of opcode/competitor speed?
20:12-!-Thedarkb-T60 [~Thedarkb-@86-40-231-4-dynamic.agg3.kny.prp-wtd.eircom.net] has quit [Ping timeout: 480 seconds]
20:44-!-Wormnest [~Wormnest@35.136.176.177] has joined #openttd
20:44-!-Wormnest is "Wormnest" on #openttd
20:51-!-drac_boy [~oftc-webi@24-212-186-79.cable.teksavvy.com] has left #openttd []
21:04-!-Wormnest [~Wormnest@35.136.176.177] has quit [Quit: Leaving]
21:13-!-supermop_work_ [~supermopw@38.105.230.30] has quit [Read error: Connection reset by peer]
22:31-!-D-HUND [~debdog@2a00:79c0:61a:e900:7a24:afff:fe8a:d04d] has joined #openttd
22:31-!-D-HUND is "Wowbagger" on #bitlbee #openttd
22:34-!-debdog [~debdog@2a00:79c0:66c:9b00:7a24:afff:fe8a:d04d] has quit [Ping timeout: 480 seconds]
22:43-!-samu [~oftc-webi@pa4-84-91-142-34.netvisao.pt] has quit [Quit: Page closed]
22:52-!-glx [kvirc@000128ec.user.oftc.net] has quit []
22:56-!-snail_UES_ [~snail_UES@cpe-98-14-137-148.nyc.res.rr.com] has quit [Quit: snail_UES_]
23:19-!-HerzogDeXtEr1 [~farci@dslb-178-012-126-255.178.012.pools.vodafone-ip.de] has joined #openttd
23:19-!-HerzogDeXtEr1 is "purple" on #openttd
23:26-!-HerzogDeXtEr [~farci@dslb-188-106-213-038.188.106.pools.vodafone-ip.de] has quit [Ping timeout: 480 seconds]
---Logclosed Wed Feb 13 00:00:02 2019