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

---Logopened Sun Feb 24 00:00:17 2019
00:09-!-Maarten [~maarten@2600:1700:7fd0:6e98:20c:29ff:fea0:abb6] has joined #openttd
00:09-!-Maarten is "maarten" on #openttd #oftc #moocows @#maarten
00:20-!-Maarten [~maarten@2600:1700:7fd0:6e98:20c:29ff:fea0:abb6] has quit [Ping timeout: 480 seconds]
01:23-!-snail_UES_ [] has quit [Quit: snail_UES_]
01:33-!-supermop_Home_ [] has quit [Ping timeout: 480 seconds]
02:23-!-Alberth [] has joined #openttd
02:23-!-mode/#openttd [+o Alberth] by ChanServ
02:23-!-Alberth is "purple" on @#openttd
02:23-!-andythenorth [] has joined #openttd
02:23-!-andythenorth is "andythenorth" on #openttd
02:23<andythenorth>wakey wakey
02:23<andythenorth>rise and shine
02:23<andythenorth>sun is out
02:24<@Alberth>moin, awake and sunny sunday andy :)
02:26<@Alberth>reading your mail, and the discrepancy between 'git rev-list --count HEAD' and hg revisions is easy; hg also counts commits in other branches
02:29<andythenorth>ok that makes sense
02:30<@peter1138>Ah, hg's way of pretending it's svn.
02:31<@Alberth>it all depends on how important you consider "branch"
02:31<andythenorth>ouch, how many industry tiles are there? Still 255?
02:31<@peter1138>That number is going to be different per repo clone.
02:31*andythenorth gonna run out
02:31<@Alberth>yes, hg documents that it's a per-repo numbers
02:32<@Alberth>still, it's one of things I quite miss with git
02:36<@Alberth>no way to derive a notion of age from a hash-number without having a command-line and the git repo nearby
02:53-!-keoz [~keikoz@2a01:e35:2fd5:51e0:d790:795d:2cc7:b53d] has joined #openttd
02:53-!-keoz is "Grmph" on #kernelnewbies #openttd
02:57<@peter1138>andythenorth, is there a test-case I can use for synchronized random introduction?
02:58*andythenorth checks
02:58<@peter1138>Or should I just fiddle with attributes on the default vehicles? :D
02:59<andythenorth>peter1138: there's Iron Horse 2 alpha 7 on Bananas
02:59<andythenorth>go to around 1987-ish
02:59<andythenorth>the Helm Wind has two parts: cab and middle
02:59<andythenorth>intro date on both is 1987-01-01
02:59*andythenorth hasn't tested it :P
03:08-!-nielsm [] has joined #openttd
03:08-!-nielsm is "Niels Martin Hansen" on #openttd
03:11<andythenorth>Alberth: python does not like ','.join(['foo'])
03:11<andythenorth>I'm sure I used to be able to do that in python 2 :P
03:12<nielsm>it should like that though
03:12<nielsm>how does it vomit?
03:12<andythenorth>not iterable
03:12<andythenorth>TypeError: can only join an iterable
03:13<LordAro>both a list and a string are iterable
03:13<andythenorth>it works in python prompt
03:14<@peter1138>dbg: [sl] Game Save Failed
03:14<@peter1138>Broken savegame - Invalid chunk size
03:14<@peter1138>That's an interesting one :-)
03:15-!-APTX [~APTX@2001:470:24:137f:2ff:ffff:fe00:1] has joined #openttd
03:15-!-APTX is "APTX" on #openttd #kernelnewbies
03:21<@Alberth>andy: you really have a [..] as argument?
03:21<andythenorth>in some cases yes
03:21<andythenorth>it's working now, I changed something
03:22<andythenorth>file it under 'no coffee yet'
03:22<@Alberth>yeah, works for me at least
03:23*andythenorth should remove the wall of warning messages from FIRS compile output :P
03:23<andythenorth>'no warnings' is much better
03:28-!-sla_ro|master [] has joined #openttd
03:28-!-sla_ro|master is "slamaster" on #sla #openttd
03:29<@Alberth>mostly, no new warnings :)
03:29<DorpsGek_II>[OpenTTD/OpenTTD] nielsmh commented on pull request #7271: Cleanup: Ships can always make 90° turns (it's even realistic)
03:31<DorpsGek_II>[OpenTTD/OpenTTD] nielsmh commented on pull request #7270: Introduce CMake (and removing all other project-related code)
03:33<DorpsGek_II>[OpenTTD/OpenTTD] andythenorth commented on pull request #7271: Cleanup: Ships can always make 90° turns (it's even realistic)
03:39<@peter1138>Oh right, I put the afterload stuff into the saving path, not the loading path. "lol"
03:39<@peter1138>Should I cycle or code?
03:41<DorpsGek_II>[OpenTTD/OpenTTD] EarthlingKira commented on pull request #6965: Add: Option for population-linear town cargo generation
03:50<DorpsGek_II>[OpenTTD/OpenTTD] PeterN commented on pull request #7261: Add: Road vehicle path cache.
03:51*andythenorth might have integer maths troubles soon
03:51<andythenorth>industry output cargo is currently split over 1 or 2 cargos
03:52<andythenorth>so it's multiplied on output by 8/8 or 4/8
03:52<andythenorth>with 9 output cargos, that gets interesting :P
03:52<andythenorth>also integers
03:56-!-gelignite [] has joined #openttd
03:56-!-gelignite is "gelignite" on #openttd
04:05<@Alberth>max(1, (v + 0.5) // 9) -ish ?
04:06<@Alberth>or perhaps just always add 1
04:14<andythenorth>something like that
04:14<andythenorth>it has to work for arbitrary numbers of output cargo 1-16
04:15<andythenorth>I can't remember what the integer maths problems were with cargo output, they were solved 10 years ago :P
04:16<@Alberth>programs are always willing to provide new variations on solved problems :p
04:22-!-andythenorth [] has quit [Quit: andythenorth]
04:25<Eddi|zuHause>i'd maybe try storing the remainder and adding it again in the next run
04:25<Eddi|zuHause>to avoid rounding issues
04:25-!-gnu_jj_ [] has joined #openttd
04:25-!-gnu_jj_ is "jj" on #openttd #ceph-devel #ceph
04:28-!-andythenorth [] has joined #openttd
04:28-!-andythenorth is "andythenorth" on #openttd
04:29-!-gnu_jj [] has quit [Ping timeout: 480 seconds]
04:30<andythenorth>something modified my hotkeys.cfg :P
04:30<andythenorth>and removed TAB
04:31<andythenorth>and again
04:32-!-Progman [] has joined #openttd
04:32-!-Progman is "Peter Henschel" on #openttd
04:33<andythenorth>what's the magic hotkeys code for tab?
04:33<andythenorth>it's not in hotkeys.cpp nor the wiki
04:34<@Alberth>eddi: that would work, I did something similar with the widgets in a window, repeatedly compute size of the biggest unsolved output, and subtract its result value from the available amount
04:34<DorpsGek_II>[OpenTTD/OpenTTD] nielsmh commented on pull request #6965: Add: Option for population-linear town cargo generation
04:35<andythenorth>anyone paste their equivalent of
04:35<@Alberth>andy: CTRL+I ?
04:35<andythenorth>fastforward =
04:35<@Alberth>empty here
04:36<@Alberth>tbh don't know if tab works :)
04:36<Eddi|zuHause>andythenorth: on debug builds, fast forward is on shift, i think
04:36<nielsm>andythenorth: blank for me
04:36<nielsm>and tab works for ffwd
04:36<DorpsGek_II>[OpenTTD/OpenTTD] EarthlingKira commented on pull request #6965: Add: Option for population-linear town cargo generation
04:37<andythenorth>it has been on tab for years
04:37<andythenorth>it broke yesterday evening
04:37<nielsm>remember in debug builds, fastforward is on Shift, in release builds on Tab
04:37<andythenorth>I have NFI why it's broken
04:37<nielsm>at least on windows
04:37<andythenorth>wat, that works here too :o
04:37<andythenorth>how did I switch to debug builds?
04:37<@Alberth>I also always use shift, but I don't run releases, typically
04:37<andythenorth>I set ./configure
04:37<andythenorth>with dbg
04:37<Eddi|zuHause>try ./configure --disable-debug
04:38<Eddi|zuHause>andythenorth: when you tried debugging the rivers
04:38<andythenorth>ok, so I reset all my mac keyboard settings, restarted it, and then took the keyboard apart and cleaned it
04:38<andythenorth>but ok, it was a configure option
04:38<Eddi|zuHause>honestly, i've never quite understood why that change is there
04:39<nielsm>Eddi|zuHause: maybe to do with alt+tab switching
04:39<nielsm>where ffwd gets stuck on if you switch away
04:39<Eddi|zuHause>nielsm: but shouldn't the game instead check for alt?
04:39<Eddi|zuHause>nielsm: surely people alt+tab with release builds as well
04:39<nielsm>yeah I'm not sure either...
04:40<andythenorth>says a lot about the state of Macs
04:40<andythenorth>first thing I try is disassembling the keyboard :P
04:41*andythenorth cannot recommend currently
04:41-!-Alberth [] has left #openttd []
04:44<andythenorth>so dividing by 16 instead of 8
04:44<andythenorth>might be one step towards avoiding integer maths problems
04:44<andythenorth>but I can't remember the quirks for industry distributing cargo to stations
04:48<andythenorth>all kinds of code :P
04:49-!-Wolf01 [] has joined #openttd
04:49-!-Wolf01 is "Wolf01" on #openttd
04:55<andythenorth>oof inputs will also need rescaling
04:55<andythenorth>'ratio max 8' isn't going to work
05:03<DorpsGek_II>[OpenTTD/OpenTTD] TrueBrain updated pull request #7270: Introduce CMake (and removing all other project-related code)
05:03<DorpsGek_II>[OpenTTD/OpenTTD] TrueBrain commented on pull request #7270: Introduce CMake (and removing all other project-related code)
05:04<TrueBrain>not with that attitude andythenorth!
05:05<TrueBrain>hi btw :)
05:12<andythenorth>possibly a 16 in, 16 out industry, the minimum cargo delivery amount might be 256
05:12<andythenorth>to get any output
05:13<andythenorth>or even more, I don't know the min. distributed amount
05:14<andythenorth>might be 8
05:14<andythenorth>so need to deliver 2048 units to get 8 units out
05:14<andythenorth>that's...quite a lot :P
05:16<andythenorth>but max station rating is usually around 0.67
05:16<andythenorth>so around 3056 units needed to get 8 units out
05:17<andythenorth>also time to go :P
05:17-!-andythenorth [] has quit [Quit: andythenorth]
05:27<TrueBrain>I forgot how annoying library detection could be ... lol
05:34-!-JacobD88 [] has joined #openttd
05:34-!-JacobD88 is "JacobD88" on #openttd.notice #openttd
05:51-!-Beerbelott [~Berbe@2a01:e0a:6:8070:2141:d1fd:fa74:b23a] has joined #openttd
05:51-!-Beerbelott is "purple" on #openttd
05:52<DorpsGek_II>[OpenTTD/OpenTTD] Berbe commented on issue #7268: Suggestion: Option not to disclose server information when password-protected
06:02<DorpsGek_II>[OpenTTD/OpenTTD] TrueBrain commented on issue #7268: Suggestion: Option not to disclose server information when password-protected
06:03<TrueBrain>ugh, it is Sunday, I should not be doing my day job :P
06:05-!-JacobD88 [] has quit []
06:05-!-HerzogDeXtEr [] has joined #openttd
06:05-!-HerzogDeXtEr is "purple" on #openttd
06:17<DorpsGek_II>[OpenTTD/OpenTTD] nielsmh commented on issue #7268: Suggestion: Option not to disclose server information when password-protected
06:19<DorpsGek_II>[OpenTTD/OpenTTD] Berbe commented on issue #7268: Suggestion: Option not to disclose server information when password-protected
06:21<TrueBrain>nielsm: I guess it is pretty easy to make the client-names and server-name unavailable, while still keeping most of the other data, not?
06:22<TrueBrain>sounds like a patch of ~20 lines of code, if approached like that
06:22<TrueBrain>bit dirty solution
06:22<TrueBrain>but a proper solution involves more rethinking of the protocol, I guess?
06:22<Beerbelott>It's merely a suggestion, does not induce any assumption about easiness of implementation ;)
06:23<TrueBrain>Beerbelott: yeah, I got that :)
06:23<Beerbelott>If at least it could be considered as an open suggestion, that's already a win
06:23<Beerbelott>(and it seems you do :p )
06:23<TrueBrain>the thing I am on the fence about: we tend not to leave suggestion open that won't be implemented in the next year; so either we can classify this as good-first-issue, or I am not sure someone will pick it up :) (this is not meant to be rude, just how we organize the issue tracker .. having 200+ suggestions open demotivates contributions)
06:26<Beerbelott>OK I get that
06:26<TrueBrain>hmm, are company names sent before you login? Hmmm
06:26<TrueBrain>that is not part of the UDP, so that is in the TCP stream I guess?
06:26<TrueBrain>my memory is fuzzy on this :D
06:27<Beerbelott>Lemme check though, you induced some doubt
06:27<Beerbelott>Yes it is
06:27<Beerbelott>Try to connect t oa password-protected game of the list
06:27<Beerbelott>You'll the small window where you can choose t ojoin a specific company or be a spectator
06:28<TrueBrain>ah, CLIENT_DETAIL_INFO does that
06:28<Beerbelott>You'll get*
06:28<Beerbelott>That's actually the box being the source of what I consider as trouble
06:29<Beerbelott>nielsm was joining the suggestion in the fact that making companies list disappear kinda naturally force people to join as spectators, as I believe was another suggestion he was pushing for
06:30<TrueBrain>this protocol was designed 15 years ago .. it is a bit dated :)
06:30<Beerbelott>'New company' option would still remain, though
06:30<TrueBrain>in many aspects .. but infosec not the least
06:30<Beerbelott>Well old stuff also sometimes are better designed
06:31<Beerbelott>and modern stuff definitely are sometimes even the worst in terms of infosec.......
06:31<Beerbelott>thus age is merely a concern for backwards compatibility
06:31<Beerbelott>(and refactoring difficulty)
06:33<DorpsGek_II>[OpenTTD/OpenTTD] TrueBrain commented on issue #7268: Suggestion: Option not to disclose server information when password-protected
06:33<TrueBrain>hmm, reopen should also be announced ... found another bug
06:34<Beerbelott>Well, server name was not part of my concern
06:34<DorpsGek_II>[OpenTTD/DorpsGek-github] TrueBrain opened issue #23: Reopening issues is not announced
06:34<Beerbelott>That information is meant to be public when you announce a server, isn't it its sole purpose?
06:34<TrueBrain>fair enough
06:35<TrueBrain>there you go, removed it :P
06:35<Beerbelott>I was calling for discussion though
06:35<Beerbelott>AS information is gathered the same way when you publish on a list or when you connect directly to IP/Port
06:37<Beerbelott>If you don't publish, maybe is it because you wanna keep the name private. But if anyone connects, (s)he will get it anyway.
06:38<Beerbelott>That's something I never give much thought
06:39<Beerbelott>and isn't the map named needed for conneciton purposes, just like NewGRFs?
06:39<TrueBrain>it is just a name :P
06:39<TrueBrain>okay, the protocol asks for a password just before you join
06:39<TrueBrain>so you either never see the company name
06:39<TrueBrain>or always
06:40<TrueBrain>in the current flow
06:41<Beerbelott>When you mean never... when you get in-game you get the list, right?
06:41<TrueBrain>15 years ago we used to track players over all multiplayer servers for a while .. we soon found out that is a bad idea to do :P So naive ... :D
06:41<TrueBrain>well, yes, once you are ingame :)
06:42<Beerbelott>Yes, that's good
06:42<TrueBrain>(as it is part of the savegame)
06:42<TrueBrain>well, the flow of joining companies would be a bit weird
06:42<Beerbelott>The 'never' option sounds good to me
06:42<TrueBrain>as you can still join a company, you just dont know which :P
06:42<TrueBrain>so it is kinda dirty, what I suggest
06:43<Beerbelott>Well... Modified clients could still require company #0 or #1 I suppose. That's a minor glitch that could be addressed later maybe?
06:43<Beerbelott>It'd supposed that modified client is allowed to join in the 1st place
06:43<TrueBrain>edited my comment .. I dont like my own suggestion anymore :D
06:44<Beerbelott>Take your time, there is no rush
06:44<TrueBrain>best fix would be to move the password check earlier, I guess
06:44<Beerbelott>The quick answer I got yday infuriated me, but I waited 'til today to make an answer ;)
06:44<Beerbelott>I guess time is a good advisor
06:44<TrueBrain>always a good call ;)
06:45<TrueBrain>meh; I was doing cmake shit :P *hides in a cave again*
06:46<Beerbelott>Mb not
06:47<Beerbelott>In games where not company exist, this window is showed empty, right?
06:47<Beerbelott>If you fake an empty company list, the window will just appear like it
06:47<TrueBrain>all a bit dirty solutions, don't you agree?
06:47<Beerbelott>as said earlier, it could technically still be possible to join a company w/ a forget request, but that's a minor glitch
06:48<Beerbelott>Well, it's hacky but the clean solution, would require so much work it will discard the whole thing
06:49<Beerbelott>redesigning the whole joining process and windows? Yes, please... but you are in for a hell of a ride, don't you think? ;)
06:49<Beerbelott>That's be too big
06:49<TrueBrain>and that is the downside of wanting to create a quality game.. hacky solutions rarely make it through
06:49<TrueBrain>but I am not sure moving the password place is such a huge amount of work, now I look at it
06:50<Beerbelott>Still, I suggested it would be an option
06:50<Beerbelott>So people activating it would *actively want* that list to be concealed
06:51<Beerbelott>Since it would also make impossible for a genuine member with password acess to see the list of companies either
06:51<Beerbelott>it'd need to join as spectator (or create a new company) before switching over
06:51<Beerbelott>Creating another step for password would be the thing to do, but I'm afraid the consequences code-wise are going to be monstruous
06:52<TrueBrain>but that cannot be the argument to dismiss it :)
06:52<Beerbelott>... except if it takes to much of a burden and won't be made before 1 year ;)
06:53<TrueBrain>but now you just want to push through your agenda ;) :)
06:53<TrueBrain>hmm .. so indeed, the moment the password is asked, is just weird
06:53<Beerbelott>Yes, but to be fair that's something that suprised me the 1st time I join a multiplayer game
06:54<Beerbelott>Seeing all that information before even getting on the server felt weird
06:55<Beerbelott>Yes I'm pushing for realizing. But I understand only too much you gonna hates hacky stuff finding their way into your clean codebase ;)
06:55<Beerbelott>Oh my so much typos. I stop correcting them :p
06:56<DorpsGek_II>[OpenTTD/OpenTTD] TrueBrain commented on issue #7268: Suggestion: Option not to disclose server information when password-protected
06:58<Beerbelott>Just read your comment over the TCP stuff
06:58<Beerbelott>I don't get how it robs you from joining your friends? You can still connect as spectator, can't u?
06:58<TrueBrain>yes; but that breaks the current flow the game has
06:58<TrueBrain>which is weird
06:59<Beerbelott>You'll get the companies list on (save?) game sync, and you'll be back in business, won't u?
06:59<TrueBrain>you join a protected server, and *poef*, no companies
06:59<TrueBrain>that is asking for bugreports :)
06:59<Beerbelott>Well that's why I mentioned an extra option
06:59<Beerbelott>which by default won't be activated
06:59<TrueBrain>still will lead to bug reports :)
06:59<TrueBrain>as it is not what someone would expect
06:59<Beerbelott>Well... yeah.
07:00<Beerbelott>OK. Rename the issue in 'Global game redesign' and close it down for good :D
07:00<Beerbelott>Clarkson's hammer-style
07:00<TrueBrain>don't be like that :P
07:00<Beerbelott>Issues are supposed to be atomic, aren't they?
07:01<Beerbelott>Went you slide down the path where UI and gae flow has to be refactored... not good, ain't it?
07:01<TrueBrain>hmm .. how to set a server password from the console .. eeeuuuuuhhhhhh
07:06<Beerbelott>You can't even modify the configuration from there
07:06<Beerbelott>could have been a hacky way to change something by changing/restart
07:06<TrueBrain>awh, my silly solution doesn't work ..
07:06<Beerbelott>Oh well 'restart' restarts the game, but does it realod conf?
07:06<TrueBrain>the client refuses the game password dialog
07:07<Beerbelott>Well yeah that'll require work server+client sides
07:07<Beerbelott>I hear the bomb dropping
07:07<TrueBrain>don't be like this :)
07:08<Beerbelott>I like the way you already got hacks being tested though
07:08<Beerbelott>I'd still be configuring my IDE
07:11<TrueBrain>euh .. now it is not asking me for a password at all .. should I worry :P
07:21<Beerbelott>Let's remove all that complicated authentication
07:22<Beerbelott>Back in the 80s: every piece of information freely available
07:22<Beerbelott>Tht's what the Internetz are about: sharing and benevolence, right?
07:22<Eddi|zuHause>well what we got now? article 13?
07:24<TrueBrain>I am pretty sure I can bypass server passwords ...
07:26<Eddi|zuHause>TrueBrain: must be a hidden government backdoor
07:26<TrueBrain>ah, no, I am wrong .. one line of code prevents it
07:26<TrueBrain>which is ... more luck, than anything else :P
07:27<TrueBrain>this part of the protocol is not of the best design :D
07:27<Eddi|zuHause>that heroic one line of defense!
07:27<TrueBrain>basically, it is a state machine without clear control of flow :)
07:28<TrueBrain>but no, I am wrong; it does work as intended
07:29<Eddi|zuHause>we should make a movie about that heroic last line
07:30<Eddi|zuHause>how it fends off all the password hacking attempts
07:30<Eddi|zuHause>(of course the movie diverges from what actually happens, for dramatic effect)
07:30<TrueBrain>the main issue I have with the current code: the state machine is not in order of functions .. so it is a constant jumping around
07:30<TrueBrain>no clue why we didn't make it into a proper state machine
07:38-!-Samu [] has joined #openttd
07:38-!-Samu is "realname" on #openttd
07:45<Beerbelott>TrueBrain 'cause refactoring takes time, which people lack? ;)
07:54<Samu>I finally understand the pattern behind TrackToTrackdir
07:57<Samu>instead of rotating clock-wise/anti-clock-wise, it mirrors perpendicular to the track
07:58<Samu>and it's the only thing that matters
07:59-!-andythenorth [] has joined #openttd
07:59-!-andythenorth is "andythenorth" on #openttd
07:59<Samu>the mirrored dir_1 and dir_2 are in the same relative positions
07:59<andythenorth>time for lunch?
07:59<andythenorth>peter1138: ^
07:59<TrueBrain>weird, password popup is not showing up where I expect it to .. hmm
08:00<Samu>east and west: dir_1 is to the south, dir_2 is to the north
08:00<Samu>upper and lower: dir_1 is to the east, dir_2 is to the west
08:01*andythenorth has purchased 50% of a garden centre
08:01<andythenorth>because the sun is out, briefly, in the UK
08:02<Samu>the opposite track of track_right is track_left
08:02<Samu>the dir_1 of them both will still point to the same tile
08:03<Samu>it even makes things easier!
08:03<Samu>too much magic-math involved!
08:11<Samu>I can finally do this without resorting to any (extra) table
08:11<Samu>corner_to_direction[] = { DIR_W, DIR_S, DIR_E, DIR_N };
08:11<DorpsGek_II>[OpenTTD/OpenTTD] andythenorth commented on issue #7268: Suggestion: Option not to disclose server information when password-protected
08:12<Samu>is there a way to convert corner to dir?
08:12<@peter1138>andythenorth, I am back, yes.
08:12<Samu>peter1138, halp
08:12<Samu>without resorting to table
08:12<@peter1138>My opinion is: my version works fine :p
08:13<andythenorth>eggs for lunch?
08:13*andythenorth asks the big questions
08:13<Samu>it does not
08:13<@peter1138>It works for the purposes of prevent towns from blocking rivers.
08:13<@peter1138>It dones't prevent players from blocking rivers.
08:14<@peter1138>Both of which are placed by players.
08:15<Samu>i have a corner, i wanna get the direction out of its position, how to do it without resorting to corner_to_direction[] = { DIR_W, DIR_S, DIR_E, DIR_N };
08:15<Samu>or maybe, I have a track_left, track_right, track_upper_track_lower, how to extract the tileoffset by dir?
08:16<andythenorth>I reckon
08:16<andythenorth>that if I cap to 8 cargos in / 8 out
08:16<andythenorth>I don't have to change much production code :P
08:16<andythenorth>and > 8 is bonkers also
08:17<Samu> static const Direction corner_to_direction[] = { DIR_W, DIR_S, DIR_E, DIR_N };
08:17<Samu> TileIndex oppposite_tile = AddTileIndexDiffCWrap(tile, TileIndexDiffCByDir(corner_to_direction[opposite_corner]));
08:17<Samu>well, it's just two lines, i guess it doesn't hurt much
08:20<Samu>but it's still a table :|
08:23<@peter1138>Thanks andythenorth, I have an egg :D
08:24-!-Flygon [] has quit [Quit: A toaster's basically a soldering iron designed to toast bread]
08:25<andythenorth>I think I only have one
08:25<andythenorth>oof my wife ate it :(
08:27<@peter1138>I can put a couple on for you.
08:27<@peter1138>Might get cold in the post.
08:28<Samu>which code is prettier?
08:28<Samu>if (HasTrack(opposite_track, TrackToOppositeTrack(tile_trackk))) {
08:28<Samu>if (CornerToTrackBits(corner) & opposite_track) {
08:28<Samu>they do the same thing, but in different words
08:31<nielsm>you're not getting a PR that depends on player owned objects approved
08:32<nielsm>and rejecting anything that uses lookup tables because ??reasons?? is bad, when the table-driven code is shorter and clearer
08:33<Samu>i thought tables were to be avoided
08:34<_dp_>does compiler optimize small tables btw?
08:34<nielsm>it may do that
08:34<nielsm>optimize it
08:35<nielsm>and tables are never good or bad without context
08:35<nielsm>a good table-driven approach makes the code shorter and the table readable, and makes it easy to enumerate all the cases handled
08:36<nielsm>a bad table-driven approach has the code almost as long as it would be without tables
08:37<nielsm>the big advantage of trables is the ability to avoid large chains or pyramids of conditionals, replacing it with a single, linear control flow
08:37*andythenorth achieved buying eggs
08:37<andythenorth>shop is round the corner
08:38<andythenorth>ok when dividing n/8, where n is 1..8
08:38<andythenorth>what's the most trivial way to find out if the result is an integer?
08:38<@peter1138>Hmm, maybe I should use std::vector<bool> instead of a custom bitmap class.
08:38<nielsm>three lower bits are zero
08:39<andythenorth>1,2,4,8 are allowed, 3,5,6,7 are not
08:39<nielsm>(x&7==0) == (x % 8 == 0)
08:39<nielsm>oh hm
08:40<nielsm>peter1138: if it actually stays performant with vector<bool> it may be the first case I've seen of that specialisation being useful
08:41<andythenorth>n % 2 == 0?
08:41<nielsm>no then you will reject 1 and accept 6
08:41<andythenorth>if n in [3, 5, 6, 7] :P
08:41<andythenorth>is lame, but easy
08:42<nielsm>if this is during compile time be lazy :)
08:45<@peter1138>Well, is it worth not using it?
08:46<nielsm>eh try using vector<bool> and see if it works for the case
08:46<@peter1138>I don't see why it wouldn't work.
08:46<@peter1138>It's probably going to perform miles better than the old old std::unordered_set, anyway
08:46<nielsm>it's just very rare you actually want the compact representation over the regularity of behaving like any other vector
08:47<nielsm>but this may be the unusual case
08:48<@peter1138>My bitmap class works fine (somewhat simplified from what I had originally)
08:48<@peter1138>So I'm not sure if there's much benefit other than not using a custom class.
08:49<@peter1138>Hmm, 70 less lines
08:50<andythenorth>ok so I should be testing 'is n a factor of 8'
08:51<andythenorth>in python :P
08:51<andythenorth>can't find a one line solution for that on SO
08:51-!-Thedarkb1-T60 [] has joined #openttd
08:51-!-Thedarkb1-T60 is "realname" on #openttd #oolite
08:52<Eddi|zuHause>or the way you wrote it, 8%n==0, but i don't think you meant that :p
08:52<Eddi|zuHause>or, maybe you did
08:53<andythenorth>I did
08:53<andythenorth>8%n is what I wanted
08:53<andythenorth>I always forget how to use modulo
08:54<DorpsGek_II>[OpenTTD/OpenTTD] nikolas updated pull request #7254: Codechange: introduce a few unit tests
08:56<@peter1138>8%n definitely seems wrong.
08:56-!-Thedarkb-T60 [] has quit [Ping timeout: 480 seconds]
08:57<@peter1138>andythenorth, please explain why using CC_SPECIAL and cargo named LVPT is bad :/
08:57<nielsm>peter1138 no it's actually right
08:57<nielsm>when n is a factor of 8 it gives zero
08:57<andythenorth>peter1138: currently I can't, so I didn't
08:57<andythenorth>in the current state, it's as valid as any other solution
08:57<andythenorth>it's mad of course
08:58<Eddi|zuHause>nielsm: well, it's technically correct, but i agree with peter1138 that it's probably not "the right way" to approach the original problem, if you need a calculation like that
08:58<andythenorth>it looks appealing because people think IDs are very very precious
08:59<andythenorth>they think an ID costs more than clicking through the (crappy) refit menu choosing (crappy) options
08:59*andythenorth will be glad when the refit menu is dead
08:59<Eddi|zuHause><peter1138> andythenorth, please explain why using CC_SPECIAL and cargo named LVPT is bad :/ <-- if CC_SPECIAL would always have capacity 0 and be hidden from any GUI?
09:00-!-supermop_Home [] has joined #openttd
09:00-!-supermop_Home is "Guest" on #openttd
09:00*andythenorth needs teddy-bear channel now
09:00<andythenorth>with samu in the channel, I can't just speak-my-brains :P
09:00<andythenorth>no room
09:01-!-Thedarkb1-T60 [] has quit [Ping timeout: 480 seconds]
09:02<Samu>gonna use var names that peter use
09:03<DorpsGek_II>[OpenTTD/OpenTTD] PeterN updated pull request #7235: Change: Non-rectangular sparse station catchment area
09:04<Samu>dir_1 dir_2 or dir_a, dir_b ?
09:04<Samu>which name is more acceptable?
09:04<@peter1138>Neither really.
09:05<_dp_>peter1138, imo you should just choose whichever is faster for bitmap
09:06<@peter1138>_dp_, I haven't bothered benchmarking it :/
09:06-!-glx [] has joined #openttd
09:06-!-mode/#openttd [+v glx] by ChanServ
09:06-!-glx is "Loïc GUILLOUX" on #openttd.noai #openttd.notice +#openttd
09:06<Samu> TrackBits trackbits_mask_a = DiagdirReachesTracks(dir_a);
09:06<Samu> TrackBits trackbits_mask_b = DiagdirReachesTracks(dir_b);
09:06<Samu> TrackBits trackbits_mask_o_a = DiagdirReachesTracks(dir_a);
09:06<Samu> TrackBits trackbits_mask_o_b = DiagdirReachesTracks(dir_b);
09:07<Samu>good names?
09:07<LordAro>can googletest do benchmarking as well? :p
09:07<Samu>o stands for opposite
09:07<LordAro>Samu: no
09:07<LordAro>"a" "b" "1" "2" are not descriptive
09:07<LordAro>and needlessly abbreviating "o" is silly as well
09:08<@peter1138>Yeah, I didn't chose good names ;p
09:08<LordAro>say what they are - source, destination, whatever
09:08<@peter1138>Maybe I should fix it and do a separate PR.
09:08<@peter1138>Although depends if preventing towns from blocking rivers is desirable.
09:09<@peter1138>Hmm, azure did something odd with 7235 :/
09:09<nielsm>so there was talk of beta3 or even rc1 today, is it happening?
09:10<@peter1138>That's the change from custom Bitmap class to std::vector<bool>, though.
09:10<LordAro>Samu: but, abbreviating is fine - source -> src, destination -> dest, opposite -> opp, etc. but single letters don't help anyone reading the code
09:11<LordAro>this isn't javascript, the code does not slow down if you use longer variables :p
09:11<andythenorth>not even sure JS does much :P
09:11<andythenorth>the things I used to see in some_game_we_made.fla
09:11<_dp_>peter1138, just coz you made a bunch of single-use functions :p
09:11<@peter1138>BBC Basic had variables that were much faster.
09:12<@peter1138>_dp_, quite.
09:12<andythenorth>sm.x = a * d * sm.x
09:12<andythenorth>"definitely" made the .swf faster
09:12<Samu>dir_1 dir_2 are pointing towards the tile
09:12<Samu>that i'm working with
09:12<milek7>maybe std::bitset?
09:12<andythenorth>oh and the file would be called some_game_we_made_delivery_A_final_unfucked_final_final_2.fla
09:12<@peter1138>milek7, no.
09:13<@peter1138>std::bitset is fixed size at compile time. Everyone please stop suggesting it :-)
09:13<andythenorth>oof why did I add 83 industries to FIRS?
09:13<+glx>because you could ?
09:13<andythenorth>I am manually re-writing all their prod cargo type declarations
09:13<nielsm>andythenorth moar is better
09:13<andythenorth>and I can't be arsed to script it :P
09:14<andythenorth>I am up to 'd' so far
09:14<+glx>can't use a search&replace regexp ?
09:14<andythenorth>I could but the cases are fiddly
09:14<Eddi|zuHause>andythenorth: so why are we making one part of the code backwards compatible when the other part isn't?
09:15<andythenorth>by the time I debugged the replace, I might as well have done it by hand
09:15<andythenorth>Eddi|zuHause: not actually sure
09:15<andythenorth>planetmaker has proposed breaking compatibility
09:15<+glx>but could be useful for the next time ;)
09:15<andythenorth>breaking this much compatibility on industries is going to cause complaint
09:16<LordAro>nielsm: i think people decided on rc1
09:16<andythenorth>nml maintainer should decide though :D
09:16<andythenorth>and all I know is that's not me :P
09:16<LordAro>andythenorth: is the nml maintainer the same person as the translations manager?
09:17<andythenorth>shotgun not me definitely
09:17<andythenorth>in fact, who is the OpenTTD maintainer now?
09:17<andythenorth>it was rubi for a bit, but he...absolved himself of that
09:17<@peter1138>Nobody is maintaining it.
09:17<@peter1138>We are just adding random crap.
09:17<LordAro>tempted to say frosch, though TB has probably been more active than anyone
09:18<TrueBrain>LordAro: you are aware we have a translations manager, right? :P
09:18<LordAro>TrueBrain: are you sure?
09:18<TrueBrain>100% :)
09:18<LordAro>are they aware of their position?
09:18<andythenorth>if you don't know who the patsy're the patsy?
09:18<@peter1138>So who is the translations manager?
09:19<Eddi|zuHause>i could have sworn i've seen planetmaker doing some translations managing recently
09:19<TrueBrain>our translations manager can be reached on the email on the contact page :)
09:19<@peter1138>That old bullshit again.
09:19*andythenorth up to g
09:21<@peter1138>Urgh, must stop eating.
09:21<DorpsGek_II>[OpenTTD/OpenTTD] J0anJosep opened pull request #7272: Change: [NPF] Add path cache for ships.
09:21<@peter1138>NPF as well :/
09:21<@peter1138>That should be going the same way as OPF.
09:22<Eddi|zuHause>did we even allow NPF for ships?
09:23<LordAro>YAPF for ships wasn't available for the longest time
09:23<LordAro>until someone tweaked some constants and actually made it usable
09:23<LordAro>(this information is probably 5 years old)
09:23-!-Wormnest [~Wormnest@] has joined #openttd
09:23-!-Wormnest is "Wormnest" on #openttd
09:24<TrueBrain>hmm .. Windows Update downloading: 8% .. you have been saying that for 30 minutes now
09:25<Eddi|zuHause>LordAro: that's fine, apparently nothing happened in the past 5 years anyway
09:25*peter1138 TIC/TOCs std::vector<bool>
09:25*andythenorth made it to 'o' :P
09:26<Eddi|zuHause>peter1138: we have something more modern than TIC/TOC now
09:26<LordAro>peter1138: you're aware of the weirdness with vector<bool>, right?
09:26<TrueBrain>WSL sometimes report a file is not available, while it is ... oh-oh ...
09:26<@peter1138>LordAro, I'm using it for its intended purpose.
09:26<Eddi|zuHause>LordAro: by "weirdness" you mean "you can't have references on members"?
09:27<LordAro>Eddi|zuHause: yeah
09:28<@peter1138>Which is not necessary.
09:28<nielsm>and that's all the PR candidates I see
09:29<Eddi|zuHause>nielsm: on first glance in that order: ynn??n?n
09:31<LordAro>#6965 needs more testing (though it is an option, so perhaps), #7081 isn't ready, #7109 is waiting for a response from someone
09:31<LordAro>all the others are a "maybe" from me
09:32<nielsm>LordAro, how about for #6965 make the default the old algo?
09:32<nielsm>and then maybe for a 1.9.1 or whatever consider changing the default?
09:32<@peter1138>_dp_, pretty much nothing in it.
09:32<Eddi|zuHause>nielsm: that sounds a bit wrong
09:32<LordAro>mm, no changes like that in 1.9.x releases
09:33<@peter1138>Just release 1.9 now
09:34<@peter1138>Get it over with.
09:34<Eddi|zuHause>nielsm: if we're not convinced that the change is good like it is, then better postpone it after 1.9
09:35<DorpsGek_II>[OpenTTD/OpenTTD] TrueBrain updated pull request #7270: Introduce CMake (and removing all other project-related code)
09:37<@peter1138>Oh yes, path cache & multistop.
09:37<@peter1138>Probably works fine, just need to test.
09:37<DorpsGek_II>[OpenTTD/OpenTTD] nielsmh commented on pull request #7109: [OSX] Use high-precision scrolling properties for 2D scrolling
09:39<_dp_>peter1138, huh?
09:39<Samu>did it become simpler?
09:40<@peter1138>_dp_, performance of Bitmap vs std::vector<bool>, nothing in it.
09:40<Samu>maybe more consts?
09:41<+glx>managed to build using MS compiler from command line with cmake
09:41<_dp_>peter1138, ah
09:41<+glx>but needs vcvarsall.bat setup
09:41<_dp_>peter1138, and memory consumption?
09:41<DorpsGek_II>[OpenTTD/OpenTTD] PeterN commented on pull request #7261: Add: Road vehicle path cache.
09:41*_dp_ always suspicious of std structures xD
09:41<@peter1138>I... did not check that. std::vector<bool> should be pretty optimized, that is the point of it.
09:42<_dp_>well, that's the problem with generic structures, they should be optimized but you never know :p
09:43<nielsm>vector<bool> is supposed to be optimised for storage space (one bit per bool) and index lookup, but have worse iterator and modify performance
09:43<nielsm>and iterators do not support many algortihms
09:44<@peter1138>We don't need to iterate it, so that's not an issue.
09:44<_dp_>nielsm, yeah, it fits on paper
09:44<+glx>and it defaults to debug build it seems
09:46<TrueBrain>glx: cmake by default does a debug build, yes; but that is a setting :)
09:47<_dp_>um.. boost::dynamic_bitset
09:47-!-synchris [~synchris@] has joined #openttd
09:47-!-synchris is "Synesios Christou" on #openttd
09:47<_dp_>why does that thing exist
09:47<nielsm>maybe to have something that doesn't pretend to be a vector on the surface
09:47<Samu> versus
09:48<Samu>it didn't become that much simpler
09:48<Samu>it even has more lines now :(
09:48<@peter1138>So, uh, shall I stick with the custom Bitmap class or use std::vector<bool>
09:48<+glx>hmm strange compile works even with invalid PERSONAL_DIR (it's missing some quotes)
09:48<@peter1138>My bitmap class does not depend on SmallVector any more.
09:48<+michi_cc>I think we are trying to get away from custom whatever?
09:48<+glx>or maybe it's just intellisense doing weird things
09:49<nielsm>if vector<bool> has good enough performance I'd say use that
09:49<+glx> strecat(tmp, PERSONAL_DIR, lastof(tmp)); <-- says PERSONAL_DIR is OpenTTD without quotes
09:51<TrueBrain>I just segfaulted cl.exe :D w00p!
09:51<+glx>oh and openttd.exe is in build at the end
09:51<DorpsGek_II>[OpenTTD/OpenTTD] michicc approved pull request #7109: [OSX] Use high-precision scrolling properties for 2D scrolling
09:51<+glx>and not moved to bin
09:52<TrueBrain>glx: there is no need to move it, honestly
09:52<Samu>btw, locks can be created in scenario editor, does that mean they're still played made?
09:52<+michi_cc>andythenorth: Does it bother you if I just merge all of #7109?
09:53<_dp_>TrueBrain, that thing loves to crash
09:53<+glx>but it must be in bin to run correctly
09:53<_dp_>I never encountered a bug or crash in gcc but had plenty with cl that I hardly even use :(
09:53<TrueBrain>glx: no; the working directory has to be 'bin'
09:54<@peter1138>Samu, they're not made by towns.
09:54<+glx>I'm in command line, not in VS
09:54<TrueBrain>glx: so? :)
09:54<TrueBrain>you can still navigate to bin, and execute openttd.exe from another folder, not? :D
09:55<+glx>seems unintuitive to be in bin and run ..\build\openttd.exe
09:55<+glx>and worse if I want to run from explorer
09:57<Samu>so there is no way to convince you to do complete checks?
09:58-!-Wormnest [~Wormnest@] has quit [Ping timeout: 480 seconds]
09:59<Samu>it's gonna feel pointless if it's implemented that way
09:59<@peter1138>Hmm, I wonder if increasing the number of segments improves rv path cache much....
09:59<Samu>might as well not do anything
10:00<Samu>ship depots or locks will innevitably be built in those tight places
10:01<@peter1138>Oh yes, it does.
10:02<DorpsGek_II>[OpenTTD/OpenTTD] TrueBrain updated pull request #7270: Introduce CMake (and removing all other project-related code)
10:04<TrueBrain>wauw, OSX just pickedup the CMake without issues .. compilation failed most likely because I am a peanut, but that is not the point :)
10:05<+michi_cc>Ah, and BTW for those that want to to a RC and not beta3, you do realize the title game competition will run at least until March 17?
10:05<TrueBrain>don't we normally replace the title game just before stable? (honest question)
10:06<+glx>we used to have a competition for that yes
10:06-!-Thedarkb-T60 [] has joined #openttd
10:06-!-Thedarkb-T60 is "realname" on #openttd #oolite
10:06<+michi_cc>Yeah, but unless you want to anger some people, the release still has to wait until after then.
10:06<+michi_cc>glx: We do have a competition for that:
10:06<TrueBrain>michi_cc: the release itself didn't change date as far as I know :D
10:07<+michi_cc>So if we branch now and then merge all the new stuff, fixing bugs on the release branch gets more fun :)
10:07<TrueBrain>I am not sure I follow, sorry :(
10:07<TrueBrain>seems some words are getting lost in translation here :(
10:09<TrueBrain>I am a bit lost how RC vs beta3 would anger people, I guess
10:10<+michi_cc>There seemed to be some sentiment to branch now so stuff like NRT doesn't have to sit around for weeks/months. If I'm mistaken about that, well, branch whenever you want.
10:10<TrueBrain>after branching, I am sure some people go bananas on master
10:10<TrueBrain>but what is the exact issue there?
10:10<+michi_cc>That all bugfix PRs have to be done twice?
10:11<TrueBrain>well, second time not via a PR
10:11<TrueBrain>but yeah; we had the same 'issue' with subversion
10:11<TrueBrain>not the finest job, to backport stuff
10:11<TrueBrain>but .. that happens when you branch, I guss
10:11<TrueBrain>but okay, so there were 2 conversations :D
10:11<@peter1138>We should set a date to start the branch.
10:11<TrueBrain>1) don't release stable before title game is finished; makes sense. Date is still first of April as far as I know
10:12<TrueBrain>2) branching creates more work; I agree
10:12-!-supermop_Home [] has quit [Ping timeout: 480 seconds]
10:12<TrueBrain>(sorry, really trying to understand you here; hope I got it right :D)
10:12<@peter1138>If release is 1st April, then when is appropriate? 1st March? Middle?
10:12<TrueBrain>LordAro said this weekend
10:13<+michi_cc>Yeah, and at least in my opinion we don't really need a 5 week RC period.
10:13<+glx>but we can easily cherrypick PRs into the branch in case of bugfixes needing a backport
10:13<TrueBrain>glx: when creating a MSVC project, running 'strgen' fails (command not found) ... BOOOO
10:14<+glx>cmake -DVCPKG_TARGET_TRIPLET="x64-windows-static" -DCMAKE_TOOLCHAIN_FILE="d:\developpement\GitHub\vcpkg\scripts\buildsystems\vcpkg.cmake" -GNinja ..
10:14<+glx>that works for me :)
10:14<+glx>but you need to be in a vcvarsall.bat set environment
10:14<TrueBrain>glx: Ninja, yes :)
10:15<TrueBrain>try -G"Visual Studio 15 2017 Win64"
10:15<TrueBrain>I will have to check what exactly goes wrong there
10:15<+glx>cmake --build . failed for me with that ;)
10:16<+glx>on strgen, and other generated exe
10:16<+michi_cc>But then this is just my opinion, I can live with anything else as well.
10:16<TrueBrain>you want to branch when you have everything in there what you expect to do
10:16<TrueBrain>as than you only get bug fixes you have to backport
10:16<TrueBrain>which should be relative easy cherry-picks
10:17<TrueBrain>(so basically, finish the milestone ASAP, branch, and go go go)
10:17<+glx>indeed it should be easier than in svn time
10:18<TrueBrain>in general, I guess, you want people focused on the milestone now, and forget the rest for a bit of time :P
10:19<TrueBrain>fun, OSX also sets -DUNIX
10:19<TrueBrain>not confusing at all or anything
10:19<+glx>hmm I could try to convert findversion
10:19<TrueBrain>glx: LordAro already did most of it in his branch
10:20<TrueBrain>if you want to have a smooth start
10:20<TrueBrain>it is just an older version, so it needs a new look
10:21<DorpsGek_II>[OpenTTD/OpenTTD] TrueBrain updated pull request #7270: Introduce CMake (and removing all other project-related code)
10:24<DorpsGek_II>[OpenTTD/OpenTTD] nikolas updated pull request #7086: Change #6173: Update SDL driver to use SDL 2.0
10:25<@peter1138>sdl 2.0 for 1.9?
10:25<TrueBrain>what is the difference between SHARED_DIR and GLOBAL_DIR ...
10:26<@peter1138>Shared is in ~/.local/shared, IIRC.
10:26<TrueBrain>but we also have PERSONAL_DIR
10:27<+glx>probably for install packages
10:28<+glx>for windows I guess it would be the ALL_USERS location (or something like that)
10:28<DorpsGek_II>[OpenTTD/OpenTTD] TrueBrain updated pull request #7270: Introduce CMake (and removing all other project-related code)
10:29<TrueBrain>I asked what the difference was glx :) Not sure what to do with your answer :P
10:29<TrueBrain>I am confused how SHARED vs GLOBAL vs PERSONAL relates
10:29<TrueBrain>I can only understand 2 out of the 3 :P
10:30<@peter1138>Blame xdg.
10:30<TrueBrain>they define these 3 or something? (not sure what to do with that comment :P)
10:31<+glx>for windows build using Ninja should be faster
10:31<@peter1138>Although actually looking at the basedir stuff it doesn't meantion sahred or global. Hmm.
10:32<TrueBrain>glx: locally, Ninja really is faster
10:32<TrueBrain>MSVC is no longer terrible to compile with
10:33<+glx>you could use something similar to
10:33<+glx>before running cmake
10:33<TrueBrain>AzurePipelines has a CMake target
10:34<TrueBrain>which seems to work fine :)
10:34<TrueBrain>but I am currently more wondering why the project files fail
10:34<TrueBrain>as the idea is that you can create any project file with it
10:34<+glx>yes, you set then env, then the cmake
10:34<+glx>then cmake --build . in build
10:34<TrueBrain>okay, OSX fails on QuickDraw, that was to be expected
10:34<+glx>and it runs ninja
10:35<TrueBrain>no clue why you constantly add --build :P
10:35<+glx>to build
10:35<TrueBrain>but okay, I cannot debug the Project errors on Azure .. so I guess I have to do that locally
10:36<+glx>I run "cmake -D ... -GNinja .." to configure then "cmake --build ." to build
10:37<TrueBrain>ah; 'make' should also work, I guess with Ninja
10:37<+glx>no make doesn't exist :)
10:38<TrueBrain>euh, 'ninja'
10:38<TrueBrain>but okay ... project file generation .. why are you not doing what I want you to do ..
10:38<+glx>ha yes ninja works
10:40<+glx>hmm and for now I guess the CI ignores all vcpkg stuff
10:46-!-supermop_Home_ [] has joined #openttd
10:46-!-supermop_Home_ is "Guest" on #openttd
10:47<TrueBrain>seems it is ignoring CMAKE_CURRENT_BINARY_DIR
10:48<TrueBrain>the hate
10:50<+glx>but that works with ninja
10:52<Samu>i'm getting some long delays when generating world
10:53<Samu>I suspect I know what it could be
10:54<DorpsGek_II>[OpenTTD/OpenTTD] PeterN opened pull request #7273: Fix #7266: Reorder reinitialization of caches when changing font zoom level.
10:54<@peter1138>nielsm, ^^
10:55<DorpsGek_II>[OpenTTD/OpenTTD] michicc approved pull request #7273: Fix #7266: Reorder reinitialization of caches when changing font zoom level.
10:56<TrueBrain>ha, found a way to solve it; sweet, now it runs too as project :D \o/
11:00<Beerbelott>Btw, the openttd package for Debian has a dependency on libicu52, which belongs to Jessie. Wouldn't it be better to depend on the stable libicu57 (and maybe more recent versions aswell)?
11:01<+glx>ok I now have 3 build dirs :)
11:01<LordAro>Beerbelott: #6922
11:01<+glx>build_x86, build_x64 and build_m64
11:01<Beerbelott>libicu57 is supported in stable, testing & unstable releases so far, libicu63 is coming in testing & unstable
11:02<+glx>ICU is expected to be removed at some point
11:02<Beerbelott>LordAro: Reading
11:02<LordAro>(what will likely happen is that future debian versions will just be compiled without icu-layout (and so rtl lang) support
11:03<LordAro>(well, 1.9 versions anyway)
11:05<@peter1138>All the 1.9 title saves posted so far are very... flat.
11:06<DorpsGek_II>[OpenTTD/OpenTTD] TrueBrain updated pull request #7270: Introduce CMake (and removing all other project-related code)
11:06<TrueBrain>this was a forced push ^^; (including a rebase)
11:06<+glx>funny ninja builds faster than mingw
11:06<DorpsGek_II>[OpenTTD/OpenTTD] SamuXarick opened issue #7274: Very long stalls during town generation
11:06<TrueBrain>I mostly notice Ninja uses all my CPUs a lot better :)
11:06<+glx>Samu: not enough town names available ?
11:07<LordAro>istr ninja works around the slow file access that slows make down?
11:07<Samu>must be something else
11:07<TrueBrain>"+615 −24,814 " <- LOL!!
11:07<LordAro>or i might be making that up
11:07<LordAro>TrueBrain: nice
11:07<Samu>I'm still generating towns
11:07<Samu>15 minutes in
11:08<@peter1138>Map size: 4096 * 4096
11:08<Samu>and it's not a debug build
11:08<TrueBrain>still missing ICU, xdg, Quarts/QuickDraw, iconv, and nforenum/grfcodec
11:08<@peter1138>^^ that's the wrong it is slow.
11:08<TrueBrain>owh, and timidity
11:08<@peter1138>Ok, std::vector<bool> it is.
11:08<DorpsGek_II>[OpenTTD/OpenTTD] SamuXarick commented on issue #7274: Very long stalls during town generation
11:09<DorpsGek_II>[OpenTTD/OpenTTD] Eddi-z commented on issue #7274: Very long stalls during town generation
11:09<+glx>peter1138: a bitset clone using bools ?
11:09<+glx>ignore me ;)
11:10<@peter1138>We don't need the vector-portion of it, but it saves having to implement our own Bitmap class.
11:10<+glx>a kind of dynamic bitmap
11:11<TrueBrain>glx: I can let the CI use Ninja or VSBuild .. both seem to work fine now. Tempted to use VSBuild on the CI, as it possible creates better binaries
11:11<@peter1138>^ glx.
11:11<LordAro>peter1138: it's ok, vector<bool> doesn't have the vector-portion of it :p
11:12<@peter1138>glx, avoids a bit more NIH syndrome.
11:12<+glx>hmm why would it create better binaries ? it's the same compiler
11:12<TrueBrain>yeah, but VSBuild has a better concept of a full project
11:12<TrueBrain>Ninja might not
11:12<@peter1138>LordAro, pretty sure it does.
11:12<TrueBrain>I know in the past optimizations work differently
11:12-!-Thedarkb1-T60 [] has joined #openttd
11:12-!-Thedarkb1-T60 is "realname" on #openttd #oolite
11:12<@peter1138>You can resize it. We don't need that.
11:12<TrueBrain>glx: possibly you can compare binary sizes? :D
11:12<@peter1138>(Well, we resize it but a simple ReallocT suits us)
11:13<Beerbelott>LordAro: I notice on message #65 ( that a package seems to have been pushed into Debian repo, compatible w/ libicu57
11:13<+glx>TrueBrain: just need to add another build dir :)
11:13<_dp_>peter1138, isn't resize for vector a simple realloc anyway? ;)
11:13<LordAro>i would so very like to get rid of all the MallocT, ReallocT & free calls
11:13<Beerbelott>But on the website, the only package available t odownload depends on libicu52
11:13<LordAro>(alloca calls especially)
11:13<@peter1138>_dp_, sure.
11:13<+glx>but still waiting for mingw
11:13<+glx>it's slooooow
11:14<TrueBrain>but mingw also works via cmake?!
11:14<@peter1138>LordAro, yeah, I used ReallocT in my Bitmap class, which is now gone, replaced with std::vector<bool>, where I use resize().
11:14<+glx>-G"MSYS Makefiles"
11:14<TrueBrain>without modifications?
11:14<LordAro>Beerbelott: 1.8 builds on were built by the old compile farm, which was extremely dated. official debian packages are built... by debian
11:14<Eddi|zuHause>tbh, i don't see how the town generator can be fixed to notice it's running out of names and abort, while keeping the same functionality
11:14<TrueBrain>as I did zero work to keep it mingw compatible
11:14<@peter1138>Hmm actually
11:14<@peter1138>I probably need to zero it!
11:14-!-Thedarkb-T60 [] has quit [Ping timeout: 480 seconds]
11:14<LordAro>TrueBrain: as it should be :)
11:14<Eddi|zuHause>so i'd suggest closing the ticket as "WONTFIX"
11:15<Beerbelott>So by downloading the package fro mthe official source I'm making things worse, is that what you are saying? :D
11:15<+glx>by default cmake use most recent VS project but that's easily changed with -G :)
11:15<LordAro>comes under the heading of "4096x4096 is silly" ?
11:15<Eddi|zuHause>LordAro: well, you can easily run 4096^2 with low number of towns :p
11:15<LordAro>Beerbelott: i probably wouldn't put it quite like that, but more or less, yes :p
11:16<+glx>I just needed to "pacboy -S cmake"
11:16<@peter1138>Beerbelott, we don't provide the official Debian packages, obviously...
11:16<+glx>btw cmake-gui doesn't work in mingw
11:16<+glx>missing dll it seems
11:16<+glx>didn't check the issues on github yet
11:17<Beerbelott>peter1138: Is it because Debian chaps are taking over the special compilation against libicu57?
11:17<Beerbelott>Well, libicu57+
11:18<+glx>hmm strange still no warnings from mingw build, I know I should get some
11:19<LordAro>glx: wouldn't surprise me if warnings aren't turned on at all
11:19<TrueBrain>yeah, there are no warning flags etc yet
11:19<LordAro>you should be able to run make VERBOSE=1 to get the actual compiler calls
11:19<TrueBrain>not even -Wall
11:20<+glx>anyway these warnings are unfixable ,)
11:20<TrueBrain>okay, Windows build, w00p
11:20<@peter1138>Beerbelott, no, it's because the Debian people compile their own packages, regardless of what we provided.
11:22<@peter1138>Hmm, resetting a std::vector<bool> to 0 is a bit meh.
11:22<LordAro>glx: always disappoints me that they're unfixable
11:22<Beerbelott>Oh you provide them w/ sourcecode and they do their business?
11:22<@peter1138>It iterates each bit and sets to false.
11:22<nielsm>peter1138, clear() and resize()?
11:22<LordAro>a second cast wouldn't help, would it?
11:22<@peter1138>Beerbelott, we don't get involved with it at all.
11:22<Beerbelott>Sry I'm a noob at how Debian packaging works
11:22<nielsm>or does it do something dumb for that too?
11:23<LordAro>peter1138: well technically the packager is also a developer, but...
11:23<@peter1138>nielsm, yeah, I'm thinking that should do too.
11:23<LordAro>peter1138: is it not zeroed on construction?
11:23<+glx>ok mingw fails
11:24<+glx>xaudio stuff
11:24<Eddi|zuHause>Beerbelott: i don't know about debian specifically, but usually how it works is that each distribution assigns a manager to a package, and that manager monitors upstream development for new releases, and then packages that new release
11:25<Eddi|zuHause>Beerbelott: so "we" just tag a release in our own world, throw a notice out in the world, and then see what happens.
11:25<@peter1138>LordAro, yes but this is on construction.
11:25<Beerbelott>OK thx for that explanation
11:26<Beerbelott>Love the bottle-at-sea romantism
11:26<Samu>15 minutes
11:26<Samu>nearly 16
11:27<andythenorth>michi_cc: 7109 is potato / potato for me :P
11:27<andythenorth>I don't use the feature, so let people who do complain / fix it :)
11:27<DorpsGek_II>[OpenTTD/OpenTTD] PeterN merged pull request #7273: Fix #7266: Reorder reinitialization of caches when changing font zoom level.
11:27<DorpsGek_II>[OpenTTD/OpenTTD] PeterN closed issue #7266: News font size is bugged if font size was changed for a multiple times
11:29<andythenorth>wow I went outside to pot about 10 plants, and the irc readback since then is....large
11:30<DorpsGek_II>[OpenTTD/OpenTTD] nikolas commented on pull request #7254: Codechange: introduce a few unit tests
11:30<Beerbelott>Eddi|zuHause: Obiously, the package has its own version numbering system, then, hasn't it?
11:31<+glx>-- Detecting Global Data directory - C:/Program Files (x86)/OpenTTD/share/games/openttd <-- seems very wrong :)
11:32<Eddi|zuHause>Beerbelott: typically the distribution adds stuff at the end of the version number, so when we release "1.9.0" they call it "1.9.0-1" or something, and when they change something in their package before our next release they call that "1.9.0-2"
11:32<andythenorth>do we need 3500 towns?
11:32<andythenorth>like, what is the point?
11:32<TrueBrain>glx: yup; but that is what mingw always did :)
11:32<TrueBrain>let me check what MSVC did
11:32<Eddi|zuHause>andythenorth: some town name generators give up after like 70
11:32<TrueBrain>glx: it is not used on Windows
11:32<TrueBrain>that explains :P
11:32<Beerbelott>Eddi|zuHause: Version: 1.6.1-1+b1 Shall I be worried?
11:32<Beerbelott>Source: openttd (1.6.1-1)
11:33<+glx>that's a quite old version
11:33<Eddi|zuHause>Beerbelott: not exactly "current" :p
11:34<DorpsGek_II>[OpenTTD/OpenTTD] andythenorth commented on issue #7274: Very long stalls during town generation
11:34<DorpsGek_II>[OpenTTD/OpenTTD] andythenorth closed issue #7274: Very long stalls during town generation
11:34<+glx>nice project version builds now
11:34<Beerbelott>Container contents confirmed: # /usr/games/openttd -h
11:34<Beerbelott>OpenTTD 1.6.1
11:34<TrueBrain>GLOBAL_DATA_DIR indeed is only used for non-Windows builds
11:34<TrueBrain>makes them even more weird :P
11:34<Eddi|zuHause>Beerbelott: some distributions have particularly strict requirements on what version updates they include, so when they started with "1.6.0" they might say "we only update 1.6.x, but not 1.7.0"
11:34<Beerbelott>Thus, it would be nice to have up-to-date packages on the website :p
11:35<@peter1138>1.8.0 is our release, it is up to date.
11:35<Beerbelott>Bit AFAIU, ICU will be stripped before moving on
11:35<Beerbelott>Yes I got the package, but I had to import a package from oldstable to install
11:35<Beerbelott>I was condering why, now I got all the pieces
11:36<@peter1138>It's meant for old-stable, yeah.
11:36<+glx>and I'm building ninja x86, ninja x64 and msvc at the same time
11:36<Beerbelott>Well it behaves correctly on stable dependencies-wise, except for libicu
11:36<TrueBrain>glx: one of the reasons that out-of-source building is lovely :)
11:38<+glx>hmm no libs detected in cmake rerun
11:38<+glx>lol x64 ninja is in a loop
11:40<+glx>maybe because I renamed the build dir and started ninja without relaunching cmake manually
11:41<TrueBrain>cmake doesn't like these things, no :)
11:41<TrueBrain>basically they say: if you do crazy shit, we do random things :P
11:41<+glx>removing the cache seems to fix it
11:42<DorpsGek_II>[OpenTTD/OpenTTD] TrueBrain updated pull request #7270: Introduce CMake (and removing all other project-related code)
11:42<+glx>MSVC is very slow to build
11:43<DorpsGek_II>[OpenTTD/OpenTTD] Eddi-z commented on issue #7059: Town name language choice affects number of towns / world population
11:44<@peter1138>Eddi|zuHause, let's add numbers to town names :p
11:45<Eddi|zuHause>peter1138: "Paris #315" :p
11:45<@peter1138>Or even, allow duplicate names, like in real life...
11:45<TrueBrain>okay, enough fiddling with cmake. Pretty happy with what it turns out it can do, etc .. not too bad honestly :)
11:46<Eddi|zuHause>peter1138: american town names where the you get 20 Springfield and 15 Washington :p
11:46<+glx>TrueBrain: oh you trigger the weird CI failure
11:47<Samu>why did you close that? town names are english
11:49<supermop_Home_>Eddi|zuHause you also need 20 'Urbana' 5-6 'Columbus' maybe 10-20 'Lincoln' a few 'Albany'
11:49<andythenorth>Samu: have you put debugged it to find the issue?
11:49<+glx>oh now project defaulted to x86 and I specified x64 triplet, so build failed
11:49<Samu>im not trying debug, or I would have to wait a day
11:50<andythenorth>so you've proved it's not running out of town names?
11:51<Samu>it's something else, I suspect it to be deleting towns and recreating and redeleting
11:51<@peter1138>You suspect it's doing something that it never does?
11:51<Samu>currently trying to see where it gets stuck
11:51<andythenorth>there's code in worldgen to delete towns that have been founded? :o
11:51<andythenorth>fuck me
11:51<andythenorth>which idiot added that?
11:52<andythenorth>if that's the problem. just delete that code, it's clearly nonsense
11:52<@peter1138>git rebase fixup
11:52<@peter1138>Bye bye custom NIH class
11:53<Samu>if it creates towns with 0 population, it deletes it right away
11:54<Samu>but I'm not entirely sure if this is what's slowing it down so much
11:54<nnyby>Samu: out of curiousity, do you see the same stalls when town names are set to French?
11:54<DorpsGek_II>[OpenTTD/OpenTTD] michicc dismissed a review for pull request #7109: [OSX] Use high-precision scrolling properties for 2D scrolling
11:55<DorpsGek_II>[OpenTTD/OpenTTD] michicc closed issue #6800: [OSX] NSScrollWheel event handling for 2D scrolling should use scrollingDeltaX/Y
11:55<DorpsGek_II>[OpenTTD/OpenTTD] michicc merged pull request #7109: [OSX] Use high-precision scrolling properties for 2D scrolling
11:55<Samu>let me try french
11:55<DorpsGek_II>[OpenTTD/OpenTTD] Eddi-z commented on pull request #7081: Change: [Linkgraph] Pause the game when linkgraph jobs lag (#6470)
11:56<Samu>french was fast
11:56<Samu>no stalls, but it created a miserable number of towns...
11:57<nnyby>so it's not necessarily that the generator is running out of names.. french runs out of names very quickly
11:57<Eddi|zuHause>nnyby: well, it could also run out of locations
11:57<nnyby>yeah.. definitely
11:58<TrueBrain>glx: no clue what that weird CI failure is ... very odd
11:58<+glx>usually a force push in the middle of CI start
11:59<+glx>commit f32fa7a8855f8593d9bc2b05af69c2e01d96149c: Not Found
11:59<TrueBrain>this was a normal push
11:59<Samu>gonna try a smaller map
11:59<TrueBrain>I just retriggered
11:59<TrueBrain>fuck that shit :P
12:00<+glx>ok so cmake without -G is win32 most recent msvc
12:01<DorpsGek_II>[OpenTTD/OpenTTD] PeterN updated pull request #7235: Change: Non-rectangular sparse station catchment area
12:02<@peter1138>Hmm, maybe I replace the SmallVector usage.
12:02<@peter1138>^^ nielsm ;)
12:03<andythenorth>we are getting more sweary :P
12:03<andythenorth>even without V453000
12:03<andythenorth>I have to hide my irc window when my kids are trying to read it
12:03<@peter1138>Where did V453000 go? :(
12:04<Eddi|zuHause>why would you even do that? the kids will learn those words anyway...
12:04<andythenorth>they know them
12:04<andythenorth>but they're not allowed to use them
12:04<andythenorth>Samu: relevant?
12:05<@peter1138>Hmm, this company abuses station-spread quite alot...
12:05<@peter1138>*a lot
12:05<@peter1138>Turns out that company was me :(
12:05<Samu>hold on
12:05-!-snail_UES_ [] has joined #openttd
12:05-!-snail_UES_ is "Jacopo Coletto" on #openttd
12:06<Samu>trying a more manageable map size...
12:07<@peter1138>256x256, yes.
12:07<Samu>no, 4096x2048
12:07<Samu>can't seem to happen on lower than this, at least not as often
12:08<andythenorth>station spread is the best peter1138
12:08<andythenorth>turn it up to 64
12:09<@peter1138>Yeah but I was abusing it and with 7235 it doesn't "work" :)
12:09<@peter1138>Heh, I rebased but didn't rebase against master. Oh well.
12:09<Eddi|zuHause>i rebase against origin/master just to be sure
12:09<@peter1138>The commit list on github is a bit wonky, it's out of order.
12:10<@peter1138>Eddi|zuHause, I was squashing/fixuping rather than updating, but as I went back to the top, I might as well have used master.
12:10<andythenorth>I abuse station catchment a lot :(
12:10<andythenorth>are you going to ruin my playstyle :P
12:11<@peter1138>andythenorth, no, as long as you place station parts all over rather than just the corners, it'll be fine.
12:11<@peter1138>I'm not sure how to solve that.
12:11<andythenorth>let's make newgrf catchments
12:11<andythenorth>up to 256 tiles radius :P
12:12<andythenorth>circular catchments!!
12:12<@peter1138>Euclidean catchment?
12:12<@peter1138>I mean, that's possible...
12:13<Eddi|zuHause>Make the Game Euclidean Again
12:13<andythenorth>what about topographic catchments?
12:13<Samu>it's CalcClosestTownFromTile
12:13<@peter1138>DistanceSquare() ?
12:13<Samu>taking 93% of the time
12:13<andythenorth>catchment of a station on top of a hill
12:14<andythenorth>is smaller than one at the bottom of a hill
12:14<Samu>on a 6 minute creating
12:14<Eddi|zuHause>andythenorth: but that's asymmetric again?
12:14<andythenorth>it's weird
12:14<Samu>now where in the town gen is CalcClosestTownFromTile used?
12:14<andythenorth>but Railroad Tycoon 3 had something similar
12:14<Eddi|zuHause>andythenorth: people go to the station downhill, but won't go back to their house uphill?
12:15<andythenorth>I hate cycling home :P
12:15<andythenorth>it's uphill
12:15<andythenorth>I still have to do it though
12:15<andythenorth>railroad tycoon 3 had demand functions in the maap
12:15<@peter1138>Samu, try nielsm's patch
12:15<Eddi|zuHause>andythenorth: i mean, you can certainly make those catchment areas with a BFS :)
12:15<andythenorth>and cargo would move itself to the station based on the gradient of the demand function
12:15<@peter1138>Samu, #7250
12:15<andythenorth>RT3 was awesome
12:16<Eddi|zuHause>andythenorth: that's vaguely how cargodist works, except on a per-tile basis?
12:16<andythenorth>not really
12:16<@peter1138>Ok, euclidean catchments look weird :-)
12:16<andythenorth>well, vaguely
12:17<Samu>try_clear = IsTileOwner(tile, OWNER_TOWN) && ClosestTownFromTile(tile, UINT_MAX) == t;
12:17<Samu>line 2823 town_cmd.cpp
12:17<Eddi|zuHause>peter1138: euclidean needs a bit of rounding, otherwise you got pointy ends on the circles
12:17<Samu>this is what's taking most time
12:17<@peter1138>Yeah, I did <= r * r.
12:17<Samu>56% at least
12:17<@peter1138>Needs... a bit more, heh.
12:17<Eddi|zuHause><= (r+0.5)*(r+0.5)
12:17<Samu>there's another 37% coming from somewhere
12:18<@peter1138>I think putting non-integer maths in here is a bad idea :p
12:18<Eddi|zuHause>or r^2+r
12:18<Eddi|zuHause>discarding the 0.25 at the end
12:18<@peter1138>There won't be a 0.25
12:19<Eddi|zuHause>(r+0.5)^2 = r^2+r+0.25
12:19<@peter1138>r * (r+1) seems to be better
12:19<Eddi|zuHause>yeah, that's the same as what i said
12:20<@peter1138>Oh, true. heh
12:21<andythenorth>spiral catchments!
12:21<andythenorth>rainbow catchments!
12:21<@peter1138>Of course, doing this totally breaks existing games.
12:21<andythenorth>fractional catchments
12:21<andythenorth>outside a certain radius, station only collects 75% of the available cargo
12:21<@peter1138>Hmm, mind you, maybe non-rect already does :/
12:21<andythenorth>beyond that 50%, then 25%
12:22<andythenorth>so catchments have marginal zones
12:22<Eddi|zuHause>i'm fairly sure i mentioned that before :p
12:22<@peter1138>andythenorth, eh, well, currently it *has* to be in the catchment.
12:22<@peter1138>Eddi|zuHause, does that mean I need to scrap it? :(
12:23<Eddi|zuHause>peter1138: no, but if you do that, we have enough reasons to keep the old behaviour as a setting :)
12:23<Samu>testing nielsm kdtree, hope it builds
12:23<@peter1138>Anyway, I think non-euclidean is fine here :D
12:24<Eddi|zuHause>we should convert the game to Hexes :)
12:24<@peter1138>You could make a patch-option for it later.
12:24<@peter1138>Erm, I mean advanced setting.
12:24<Eddi|zuHause>i think we scrapped the "advanced"
12:25<Samu>FOR_ALL_TOWNS takes 93%
12:25<@peter1138>It's still there.
12:25<Samu>which is inside CalcClosestTownFromTile
12:25<@peter1138>I don't understand why "Expert" doesn't include *every* setting :/
12:26<@peter1138>Samu, with kdtree?
12:26<Samu>with 1.9.0-beta2
12:26<@peter1138>Then nobody cares.
12:26<@peter1138>We *know* CalcClosestTownFromTile is slow.
12:26<Samu>it builds!
12:26<Samu>ok let's generate towns
12:27<@peter1138>Samu, another one to try is #7120, but that uses brute force.
12:28<Samu>2 minutes, down from what... 16
12:29<@peter1138>Is that back on 4096^2?
12:29<Samu>let me check what took longer this time
12:30<@peter1138>Probably town names ;)
12:30<@peter1138>andythenorth, I guess you need to revise your closing on that one.
12:31<andythenorth>stick a rationale on it then
12:31<DorpsGek_II>[OpenTTD/OpenTTD] PeterN updated pull request #7235: Change: Non-rectangular sparse station catchment area
12:32<@peter1138>Right, StationList -> std::set?
12:33<nielsm>peter1138: I'd rather make an adapter for std::vector that lets it behave like a set :/
12:33<nielsm>well it's probably in the micro-optimizations department
12:35<LordAro>i did come across while checking std::set
12:35<@peter1138>StationList : std::vector?
12:35<Samu>next to some kdtree thing
12:35<Samu>ClosestTownFromTile was only 5,26%
12:36<Samu>cmddeletetown was 12%
12:36<Samu>Function Name Total CPU [unit, %] Self CPU [unit, %] Module
12:36<Samu>| - Kdtree<unsigned short,unsigned short (__cdecl*)(unsigned short,int),unsigned short,int>::FindNearestRecursive 6704 (15,75%) 4040 (9,49%)
12:36<Samu>this thing...
12:38<@peter1138>Yeah because it takes time to update the tree, but less time than it takes to call the original CalcClosets...
12:38<LordAro>peter1138: given you've made Include act like a set, is there a particular reason not to make it one?
12:38<@peter1138>LordAro, that wouldn't work.
12:39<@peter1138>Include sorts on st->index, not st.
12:40<LordAro>std::set can have a comparator function
12:40<Samu>total selected time was 1:21 min
12:40<Samu>took less than 2 to generate on a 4kx4k
12:40<@peter1138>LordAro, ok.
12:41<@peter1138>So I have nielsm suggesting to make it a std::vector and you saying a std::set :-)
12:41<Samu>gonna try 7120, brb
12:41<+glx>TrueBrain: msvc debug builds are smaller than ninja debug builds
12:42<nielsm>peter1138, it might not matter at all :P
12:42<LordAro>i'm just saying that a vector with uniqueness and an include ordering is the definition of a std::set :p
12:44<@peter1138>People seem to be concerned with the memory usage of set vs vector.
12:46<andythenorth>people are the worst :P
12:46<LordAro>hmm, might not be so good for storing pointers
12:46<@peter1138>for (auto x : y) { is rather nice, though.
12:46<LordAro>idk, how many elements are we talking here? <10k for the most part, right?
12:47<@peter1138>Somewhat less than that.
12:47<LordAro>well then
12:47<LordAro>hardly worth worrying about :p
12:47<@peter1138>We're talking 2 or 3 normally, I think.
12:47<Samu>building voronoi
12:48<@peter1138>Maybe dozens on some of the extreme games.
12:49-!-snail_UES_ [] has quit [Quit: snail_UES_]
12:49-!-snail_UES_ [] has joined #openttd
12:49-!-snail_UES_ is "Jacopo Coletto" on #openttd
12:50<Samu>generating towns
12:50-!-snail_UES_ [] has quit []
12:51<TrueBrain>glx: so yeah ... there is that :P
12:51<TrueBrain>so possibly best to do CI builds with VS
12:52<TrueBrain>developers can use Ninja :)
12:52<Samu>crap, rebuilding, some strings are missing for some reason
12:52<+glx>CI could use Ninja because it's fast, but VS for releases maybe
12:53<TrueBrain>glx: only leads to build issues during release
12:53<TrueBrain>which is annoying :D
12:53<+glx>btw I need to try a release ninja build to see how fast it is
12:56<@peter1138>Ok so... that works.
12:56<+glx>impressive ninja builds release as fast as debug
12:57<@peter1138>Now do see where to commit to merge it coherently.
12:57<@peter1138>s/merge/rebase fixup/
12:58<@peter1138>typedef StationList : std::set<Station *>
12:58<@peter1138>Oh, I need the comparator. Hmm.
12:58<Samu>1:38 for voronoi
12:58<Samu>CmdDeleteTown 15%
12:59<+michi_cc>glx: So which optimizations are missing?
13:00<Samu>BuildVoronoiDiagram at 8,86%
13:02<Samu>ClosestTownFromTile was only 1,72%
13:02<Samu>well, 1,80%
13:02<Samu>CalcClosestTownFromTile is 1,72%
13:02-!-supermop_Home_ [] has quit [Ping timeout: 480 seconds]
13:03<Samu>so... which one wins?
13:03<@peter1138>Samu, what's the question?
13:04<Samu>the fastest Town deleter
13:04<Samu>or the fastest calcclosesttown
13:04<Beerbelott>I compiled a Debian package w/ stable dependencies if you are interested? Might be worth testing, though
13:05<Beerbelott>Depends: libc6 (>= 2.15), libfontconfig1 (>= 2.11), libfreetype6 (>= 2.2.1), libgcc1 (>= 1:3.0), libicu57 (>= 57.1-1~), liblzma5 (>= 5.1.1alpha+20120614), liblzo2-2, libpng16-16 (>= 1.6.2-1), libsdl1.2debian (>= 1.2.11), libstdc++6 (>= 5.2), zlib1g (>= 1:1.1.4)
13:05<@peter1138>Beerbelott, thanks but our packages are built by a compile-farm. We are going to be updated an old already released version.
13:07<@peter1138>LordAro, nielsm, with 50k stations, the std::set version is...
13:07<@peter1138>94MB more memory usage.
13:07<Samu>kdtree was faster, slightly
13:07<@peter1138>Faster than?
13:08<Samu>1:21 vs 1:38
13:08<@peter1138>^^ nielsm
13:09<@peter1138>Hmm, wentbourne size is about the same.
13:12<LordAro>peter1138: how about a "normal" game? :p
13:12<LordAro>that is quite a lot though
13:13<Samu>gonna try with the same seed
13:14<@peter1138>1500KB? Maybe.
13:14<@peter1138>But that's just looking at top, could be anything causing a difference.
13:14-!-snail_UES_ [] has joined #openttd
13:14-!-snail_UES_ is "Jacopo Coletto" on #openttd
13:17<@peter1138>Ok, well, std::set is a winner then.
13:17<@peter1138>Or not?
13:18<@peter1138>Hmm, 200MB now.
13:19<@peter1138>Performance is slightly less as well, with 50k stations.
13:19<@peter1138>But 50k isn't realistic.
13:19<+glx>hmm even with -DCMAKE_BUILD_TYPE=Release, the msvc build is a debug one
13:20<nielsm>hah surprised that kdtree is actually faster than voronoi, when voronoi is supposed to be constant time lookup
13:20<@peter1138>nielsm, it's the rebuilds.
13:21<nielsm>must be
13:21<Beerbelott>peter1138: Just another package actually, which would sit next to the others, for Debian/Stretch
13:21<Samu>hmm they don't generate the towns in the same spots...
13:21<@peter1138>Beerbelott, we can't publish packages built by third-parties.
13:22<Samu>doesn't look like apples to apples comparison
13:22<nielsm>I wonder if it'd be worth putting a balancedness tag on each node in the kdtree and rebuild subtrees based on that
13:22<@peter1138>Samu, same seed?
13:22<nielsm>instead of a single global balancedness counter with a bad heuristic
13:22<@peter1138>If it's different then... maybe there's a bug.
13:22<Samu>will retry again
13:22<@peter1138>If one of them is the same as without (the 16 minute version) then that is the correct version.
13:24<Samu>do i have to rebase them all to the same version? what if i get a conflict?
13:24<@peter1138>Don't think so, don't think there's anything recent that would affect map generation apart from that.
13:30<+glx>ok for msvc no need to have multiple build dir, the project has release and debug stuff, only need to use the right config when building
13:31<Samu>looking at what 1.9.0-beta2 do
13:33<@peter1138>Samu, same as master in this particular area.
13:33<@peter1138>Same as 1.8.0
13:34<@peter1138>Hmm, backporting is a pain :/
13:34<@peter1138>Not quite the word I want.
13:35<Samu>1.9.0-beta2 did place the towns in the same spot as voronoi
13:35<Samu>testing 1.8.0 now
13:35<@peter1138>Samu, that's good enough.
13:35<@peter1138>nielsm, so your tree may be wrong :(
13:36<Samu>1.8.0 does different than 1.9.0-beta2
13:36<Samu>oh boy
13:41<@peter1138>Well that's ok.
13:41<@peter1138>There could be landscape changes from 1.8.0 -> 1.9.0beta2
13:41<Samu>building master
13:41<nielsm>peter1138: I suspected that when the regressions failed at seemingly random
13:41<Samu>latest master
13:46<@peter1138>Urgh. Ok, doing this change is a pita :/
13:46<+glx>lol ninja release is bigger than msvc debug
13:47<Samu>i have 3 openttds generating towns zzz
13:48<Samu>make it 4 now
13:48<Samu>generating for kdtree as well
13:49<Samu>kdtree does different than both 1.8.0 and 1.9.0-beta2
13:49<@peter1138>1.9.0-beta2 is different to 1.8.0 so ignore 1.8.0
13:49<@peter1138>kdtree should be the same as 1.9.0-beta2
13:50<@peter1138>however this is for nielsm to solve, not you.
13:50<Samu>master does the same as voronoi, and as 1.9.0-beta2
13:50<Samu>so it's kdtree failing
13:51<Samu>but hasn't finished yet
13:51<@peter1138>But, thanks for confirming that kdtree is faster than master.
13:51<Samu>it just placed the town
13:51<Samu>where I have the screen
13:51<Samu>and placed in the same manner
13:52<Samu>it (master)
13:53<nielsm>Samu: try in kdtree.hpp to insert a Rebuild(); call before each of the two calls to CheckInvariant();
13:53<Samu>waiting for master, 1.8.0 and 1.9.0-beta2 to finish zzzz
13:55<Samu>which lines?
13:55<nielsm>it will make everything much slower, but should keep the tree perfectly balanced all the time, which might (but really should not) affect results
13:55<nielsm>uhm it's in the Insert() and Remove() functions
13:56<Samu>line 335?
13:56<@peter1138>nielsm, unbalanced should just mean it doesn't perform quite as a well as it should, right?
13:57<nielsm>peter1138 yes
13:57<nielsm>it should....
13:57<Samu>hmm im not sure where to put this
13:57<nielsm>Samu line 388 and 406
13:58<Samu> CheckInvariant();
13:58<Samu> Rebuild();
13:58<Samu>ok let's test
13:59<Samu>oh you meant before
13:59<Samu>my bad brb
13:59<nielsm>doesn't matter
13:59<nielsm>CheckInvariant does nothing :)
13:59<Samu>ok ok
14:00<nielsm>is the test you're running to generate a 4096^2 map with large number of towns, and same seed?
14:02<Samu>nop, still in the wrong place
14:04<@peter1138>Right, rewritten to use std::set not SmallVector
14:06<@peter1138>Right, IndustryVector... to std::set?
14:06<@peter1138>Might as well.
14:06<@peter1138>And perhaps rename it :p
14:06<Samu>very strange stuff
14:09<@peter1138>Yeah, you already said that it's different.
14:09<nielsm>trying to add in the old calclosesttown code and make an assert of getting the same result as the kdtree lookup...
14:10<nielsm>during title game load
14:10<@peter1138>Good call.
14:11<nielsm>could also try to make a visualisation of tiles where the two give different results
14:12<nielsm>the debug build did not crash the same way as the release build
14:12<nielsm>it just loaded the title game
14:12<Samu>waiting for 1.9.0-beta2 and master to finish zzzz
14:12<nielsm>and generated a world
14:13<andythenorth>samu found a legit bug :D
14:14<Samu>i think voronoi also has problems, im still testing
14:16<Samu>i see a bridge in 1.9.0-beta2 that i don't see in voronoi, but it has yet to finish, i'll wait
14:17<DorpsGek_II>[OpenTTD/OpenTTD] nielsmh updated pull request #7250: K-d tree data structure for spatial lookups
14:17<nielsm>let's see what happens to the regressions now
14:20<Samu>master currently matches voronoi i think
14:20<Samu>taking so long bah :|
14:21<Samu>nop, bridge just popped up
14:21<Samu>so now master matches 1.9.0-beta2
14:21<Samu>voronoi is also wrong then
14:22<nielsm>woom, first regression fail yay
14:23<nielsm>and it's only the two gcc6 builds that fail
14:23<nielsm>this is seriously weird
14:23<Samu>added one more image
14:24<nielsm>am I depending on UB?
14:24<Samu>waiting for master now
14:24<LordAro>sounds like some undef- probably
14:24<@peter1138>Yeah, probably UB.
14:25<@peter1138>Right, let's see if THIS works.
14:25<@peter1138>std::set all-round.
14:25<@peter1138>(no Erase added to SmallVector!)
14:26<@peter1138>If it works...
14:26<@peter1138>It seems to.
14:26<DorpsGek_II>[OpenTTD/OpenTTD] PeterN updated pull request #7235: Change: Non-rectangular sparse station catchment area
14:27<@peter1138>Oh... need to retitle that Bitmap commit :/
14:28<nielsm>maybe I should try a different SelectSplitCoord
14:29<nielsm>like take every tenth element, put in a vector, sort, and take the median of those
14:29<nielsm>but that shouldn't matter, nth_element is supposed to be ideal for that
14:30<nielsm>but the tree should be correct, I think, at least I haven't been able to trigger CheckInvariant recently (when enabled)
14:34<Samu>sooo slow
14:34<Samu>can't believe 48 minutes already
14:34<Samu>still generating
14:34<nielsm>also seriously the title game is SLV_4? that absolutly exercises almost all of AfterLoadGame
14:35<LordAro>nielsm: there's a reason it's never been changed :p
14:39<Samu>all versions tested
14:39<Samu>voronoi is also bugged then
14:40<LordAro>i've not been paying attention, what is the bug?
14:41<LordAro>also, are we doing the branch today or not?
14:41<Samu>the bug, they dont generate the towns / industries in the same place with the same seed
14:42<nielsm>kdtree and possibly also voronoi reporting incorrect nearest town
14:42<LordAro>i see
14:42<nielsm>in the case of kdtree appears to depend on undefined behaviour
14:43<LordAro>nielsm: if you were on linux i'd suggest you compile with -fsanitize=undefined :>
14:46<nielsm>I could boot up my linux machine...
14:46<Samu>rebased voronoi, let's see if it makes a difference
14:49<Samu>how do i make the assert here?
14:50<+michi_cc>TrueBrain: Short Azure question: how can a build step set an environment variable (i.e. the equivalent to 'export FOO=bar')?
14:50<@peter1138>Raar, dinner is preparing.
14:50<@peter1138>Wait, no, dinner is prepared. Dinner is cooking.
14:50<@peter1138>Bit late, I was engrossed in rewriting non-rect-catchment
14:50<+michi_cc>And, the most important question of the day: beta3 or RC1?
14:50<Samu>rebase made no difference
14:51<Samu>how do I undo a rebase?
14:51<Samu>(without resorting to recycle bin)
14:52<@peter1138>If you didn't complete it, git rebase --abort
14:52<andythenorth>RC1 next weekend
14:52<@peter1138>If you did complete it, git reflog, then git reset to whatever reference.
14:53<@peter1138>Samu, tip: you can create branches just for rebasing, then if it goes tits up you've still got the original.
14:54<DorpsGek_II>[OpenTTD/OpenTTD] PeterN commented on pull request #7235: Change: Non-rectangular sparse station catchment area
14:54<DorpsGek_II>[OpenTTD/OpenTTD] PeterN commented on pull request #7235: Change: Non-rectangular sparse station catchment area
14:56<Samu>hmm will try git reflog next time
14:58<@peter1138>Prozone 13 has some interesting catchment areas
15:03<@peter1138>Would be nice if TileIterator could fit the standard pattern.
15:04<nielsm> that's a peculiar pattern
15:05<nielsm>tiles being town owned should not affect which town sign is physically closest
15:07<nielsm> <- interesting?
15:09<nielsm>oh, oops
15:09<nielsm>did a wrong
15:11<Samu>that assert would be awesome to test here on voronoi too
15:11<Samu>how to assert
15:11<@peter1138>Can't construct this industry type here... ... area is owned by owner company.
15:11<@peter1138>Hmm, strange newgrf :p
15:12<@peter1138>Can't construct industry, train in the way.
15:12<@peter1138>What? lol
15:12<@peter1138>Surely... track is in the way.
15:13-!-synchris [~synchris@] has quit [Quit: yeeha!]
15:17<nielsm>okay this one is correct:
15:17-!-sla_ro|master [] has quit []
15:17<nielsm>it determines that all the red tiles are not within 20 tiles of any town
15:18<nielsm>the highlight is correct in showing the wrongness :P
15:19<nielsm>okay well, some of the tiles near the oil wells are reported as belonging to the other nearby town
15:22<nielsm>this tile: reported as belonging to fledborough, is 18 tiles from fledborough and 11 tiles from prundstone :(
15:22<nielsm>so yeah kdtree is wrong
15:24<Samu>testing voronoi with an assert
15:25<Samu>didn't build, grr
15:27<Samu>wow the order of static stuff matters
15:28<nielsm>you can't use something before declaration
15:28<Samu>generating towns... waiting for an assert... afk
15:32<nielsm>another funky fail:
15:32<nielsm>it built those towns closer than should be permitted too
15:33<TrueBrain>michi_cc: example of what you want to do?
15:34<TrueBrain>set a variable in one buildstep for another to use later?
15:34<nielsm>someone misspelt one of those townnames :P
15:35<DorpsGek_II>[OpenTTD/OpenTTD] michicc opened pull request #7275: Change: [AzurePipelines] Use a minimum OSX version of 10.9 during building, as this is what the code supports.
15:35<+michi_cc>TrueBrain: Do ^^ the most elegant way :)
15:36-!-andythenorth [] has quit [Quit: andythenorth]
15:36<TrueBrain>haha; fair enough
15:37<TrueBrain>shouldn't we do this in the repo itself?
15:37<TrueBrain>so if Andy builds manually it also works?
15:38<TrueBrain>in config.lib or so?
15:39<Samu>bam, it asserted 720 towns in
15:39<Samu>I expected way later
15:39<DorpsGek_II>[OpenTTD/OpenTTD] michicc updated pull request #7275: Change: [AzurePipelines] Use a minimum OSX version of 10.9 during building, as this is what the code supports.
15:40<DorpsGek_II>[OpenTTD/OpenTTD] nielsmh commented on pull request #7250: K-d tree data structure for spatial lookups
15:40<+michi_cc>Yes and no, as I forgot to change a step.
15:40<DorpsGek_II>[OpenTTD/OpenTTD] TrueBrain commented on pull request #7275: Change: [AzurePipelines] Use a minimum OSX version of 10.9 during building, as this is what the code supports.
15:40<+michi_cc>For the dependencies, it needs to be done on Azure as well.
15:40<TrueBrain>hmm ... a few libraries come preinstalled via brew
15:40<TrueBrain>but that shouldn't be an issue
15:41<TrueBrain>I am fine with the dependency thingy
15:41<TrueBrain>as that indeed is CI specific
15:41<TrueBrain>possibly move the other two in config.lib?
15:41<TrueBrain>(I assume a 10.13 SDK can still target 10.9 too?)
15:43<+michi_cc>I'm not sure if a 10.13 SDK is totally backwards compatible, it depends on how the functions are marked. Maybe the result will only run on 10.10 or something :)
15:43<TrueBrain>meh; come to think of it, I dont really care how we do this :P
15:43<TrueBrain>more important, we said we only support what Apple supports
15:43<TrueBrain>10.9 is not
15:43<TrueBrain>why this change?
15:44<TrueBrain>just because we happen to support it? As we might break it, without knowing
15:44<TrueBrain>so do we really want this?
15:46<+michi_cc>10.9 is because of the C++11 libc. Other than that, our code has all needed version checks, so why needlessly exclude users?
15:46<+michi_cc>We don't have to declare 10.9 as supported, just not deny it immediately.
15:46<DorpsGek_II>[OpenTTD/OpenTTD] TrueBrain requested changes for pull request #7275: Change: [AzurePipelines] Use a minimum OSX version of 10.9 during building, as this is what the code supports.
15:47<TrueBrain>"because we can" hasn't been good to us in the past
15:47<TrueBrain>but as you are supporting OSX basically, I am all fine with it; just as long as you be a bit more descriptive in the commit message why you think this is a good idea :D
15:48<TrueBrain>(with for example what you just told me :))
15:48<TrueBrain>I do not know a better way to set an ENV variable btw; think this is the only sane-ish way
15:51<+michi_cc>Actually, let me try something, this is supposed to work :)
15:51<DorpsGek_II>[OpenTTD/OpenTTD] michicc updated pull request #7275: Change: [AzurePipelines] Use a minimum OSX version of 10.9 during building, as this is what the code supports.
15:52<TrueBrain>that might even work, yes
15:52<TrueBrain>few auto-magic shit going on .. so we will see :P
15:52<+michi_cc>"Because we can" applies/applied to a lot of stuff: DOS,
15:53<+michi_cc>Win95 and whatever else.
15:53<TrueBrain>today I almost removed DOS
15:53<TrueBrain>we no longer support win95/win98
15:53<+michi_cc>I had to put in an echo to see if it in fact arrives.
15:53<TrueBrain>I have been pruning a bit :P
15:54<TrueBrain>but okay, I didn't ask because I really care; I ask because your commit was lacking the answer :D
15:54<+michi_cc>But only because a lack of a matching C++11 compiler, if one would exists, it is probably still good.
15:55<TrueBrain>so that actually works .. good to know
15:55<TrueBrain>I like the part where the commit message would say: 10.9 is needed because we use C++11 :)
15:55<TrueBrain>exactly the details I would love to know :D
15:57<+michi_cc>More exactly: 10.9 is needed because going lower means actual work.
15:57<TrueBrain>what ever honesty you want to put in the commit message :P
16:00<DorpsGek_II>[OpenTTD/OpenTTD] michicc updated pull request #7275: Change: [AzurePipelines] Use a minimum OSX version of 10.9 during building, as this is what the code supports.
16:00<+michi_cc>TrueBrain: Changed the commit message and added some more details into the message itself.
16:00<TrueBrain>the initial commit message is still unreasonably long :)
16:00<TrueBrain>I would just put the "as this" on a new line tbh :P
16:01<TrueBrain>and there is some line limit :P
16:01<TrueBrain>yeah, that commit message is a lot better :)
16:01<DorpsGek_II>[OpenTTD/OpenTTD] glx22 commented on pull request #7270: Introduce CMake (and removing all other project-related code)
16:01<TrueBrain>tnx michi_cc :) That helps in the future, when someone goes: WTF HAPPENED HERE :P
16:02<TrueBrain>glx: tnx, good to know. All I could see in the current config.lib, that xaudio2 was done rather weirdly
16:02<TrueBrain>I was unsure if it really worked :P
16:02<+glx>source.list is weird too regarding headers
16:03<+glx>almost all windows only headers are not guarded
16:03<DorpsGek_II>[OpenTTD/OpenTTD] michicc updated pull request #7275: Change: [AzurePipelines] Use a minimum OSX version of 10.9 during building, as this is what the code supports.
16:03<+glx>oh and for now CI builds MSVC debug ;)
16:03<DorpsGek_II>[OpenTTD/OpenTTD] nielsmh updated pull request #7250: K-d tree data structure for spatial lookups
16:03<nielsm>this is weird but Samu can you try that?
16:04<DorpsGek_II>[OpenTTD/OpenTTD] TrueBrain approved pull request #7275: Change: [AzurePipelines] Use a minimum OSX version of 10.9 during building.
16:04<TrueBrain>nice michi_cc :) And tnx :)
16:04<+glx>and I exactly know why regression fails too
16:04<TrueBrain>because that part is far from done :P
16:04<TrueBrain>regression should be moved in CMake too
16:04<TrueBrain>as 'test'
16:04<+glx>the regression.bat expect openttd.exe in bin
16:05<TrueBrain>glx: xaudio2 just needs an HAVE_XAUDIO2 in source.list I guess
16:06<TrueBrain>but I might port the source.list to CMake first soon
16:06<TrueBrain>that would make it a bit easier to work with
16:06<+glx>indeed would be cleaner too
16:07<+glx>yes HAVE_XAUDIO2 should work, with detection for WIN32 but not for MSVC
16:09<TrueBrain>sorry, I don't follow?
16:10<+glx>no need to detect xaudio for VS builds, we know it's present, but mingw builds need the detection
16:10<TrueBrain>we need mingw on the CI btw ..
16:10<TrueBrain>glx: and how that works in CMake, that you detect it ;)
16:10<TrueBrain>no need to make exception code for MSVC and/or mingw
16:10<TrueBrain>just detect what you are looking for, and CMake does the rest
16:10<TrueBrain>(lot less code, less exceptions, etc)
16:11<TrueBrain>we even try to detect fluidsynth now on all targets :)
16:11<TrueBrain>and allegro! :P
16:12<TrueBrain>we still have OSX g5 code in config.lib :D
16:12<TrueBrain>cute :D
16:12<Samu>test what
16:13<TrueBrain>glx: updated the list of things to do; feel free to pick any up and commit to my branch
16:13<TrueBrain>you can freely push new commits there
16:13<DorpsGek_II>[OpenTTD/OpenTTD] TrueBrain commented on pull request #7270: Introduce CMake (and removing all other project-related code)
16:14<Samu>voronoi seems to be asserting on towns with 0 population
16:14<Samu>they don't exist on the voronoi database, they exist on the game
16:15<DorpsGek_II>[OpenTTD/OpenTTD] orudge commented on pull request #7270: Introduce CMake (and removing all other project-related code)
16:15<TrueBrain>glx: or when in doubt, you can even make a PR to my branch in my fork :D
16:15<Samu>generating kdtree towns
16:16<+michi_cc>Hmm, not sure if the homebrew stuff really works with earlier OSX versions, but I can't check without the binary artifacts from the CI, so I guess I just merge now and check later :p
16:16<TrueBrain>you can download the artifacts, not?
16:17<TrueBrain>ah, no, not for the CI
16:17<TrueBrain>just go for it michi_cc; it won't make it worse :)
16:18<+michi_cc>I'm not worried about that.
16:18<TrueBrain>LIBS="$LIBS -F/System/Library/Frameworks -framework Cocoa -framework Carbon -framework AudioUnit -framework AudioToolbox"
16:18<Samu>woah what have you done? it's slower now
16:18<DorpsGek_II>[OpenTTD/OpenTTD] michicc merged pull request #7275: Change: [AzurePipelines] Use a minimum OSX version of 10.9 during building.
16:18<TrueBrain>is that really needed, I wonder ..
16:18<@peter1138>Samu, what's better, faster and wrong, or slower and correct?
16:18<TrueBrain>at least found why OSX is failing with CMake :) We have some more hidden defines :D
16:19<+michi_cc>Cocoa might be some system default, but AudioUnit and AudioToolbox are not. And BTW, those two have to be included in this order, or you get a link error.
16:19<Samu>correct and faster
16:19<TrueBrain>we only build for 64bit now, right?
16:19<TrueBrain>so we can drop QuickDraw, right?
16:20<Samu>i hope this doesn't mean 51 minutes
16:20-!-gelignite [] has quit [Quit: Good fight, good night!]
16:21<DorpsGek_II>[OpenTTD/OpenTTD] michicc opened pull request #7276: Update: Changelog for 1.9.0-beta3 and prepare for release.
16:21<+michi_cc>In other news, please check ^^
16:22<TrueBrain>I would poke LordAro for that :D
16:22<+michi_cc>QuickDraw is more like pre 10.5/10.6 stuff, no modern version needs that for 32-bit either.
16:22<nielsm>yeah looks like that fixed the UB
16:22<TrueBrain>michi_cc: so can we just remove it from the code?
16:23<nielsm>and it may not quite have been UB but rather reference to stack data passed up
16:23<+michi_cc>Ask our OSX users...
16:23-!-snail_UES_ [] has quit [Quit: snail_UES_]
16:23<TrueBrain>michi_cc: so I only have to ask andy :P
16:23<Samu>found a typo Possiblity, michi_cc
16:24<TrueBrain>but okay, I will keep QuickDraw, and add detection for it in CMake .. not that much work, now I look at it
16:24<TrueBrain>funny, Cocoa Quartz is basically always enabled
16:24<TrueBrain>so many lines of code, so someone is able to disable it
16:25<TrueBrain>and .. for what reason, I wonder :P
16:25<Samu>nielsm, why is this slow? is it because it's asserting with the old method
16:25<@peter1138>10.8 removed QuickDraw.
16:25<Samu>so im gonna have to wait 51 minutes :(
16:25<@peter1138>Yeah, and it's 32 bit only.
16:25<@peter1138>And OS X does not support 32 bit any more.
16:25<+glx>hmm now I checkout TB branch I can remove the pr/7270 branch I think
16:26-!-Wolf01 [] has quit [Quit: Once again the world is quick to bury me.]
16:26<nielsm>Samu yes
16:26<nielsm>I'm reverting that assert thing later
16:26<+michi_cc>LordAro: You are wanted, see PR#7276
16:27<TrueBrain>lol ..we even have code for QuickTime
16:27<TrueBrain>even older :P
16:28<TrueBrain>with an #ifdef around the whole file guarding it from being used
16:28<DorpsGek_II>[OpenTTD/OpenTTD] michicc updated pull request #7276: Update: Changelog for 1.9.0-beta3 and prepare for release.
16:28<TrueBrain>that code hasn't been used in years :P
16:29<@peter1138>beta3 :D
16:29<TrueBrain>we really need to clean up stuff from time to time .. meh
16:30<TrueBrain>what-ever .. lets not make more work for now :D
16:31<@peter1138>Samu, is it actually 51 minutes? :p
16:31<DorpsGek_II>[OpenTTD/OpenTTD] TrueBrain requested changes for pull request #7276: Update: Changelog for 1.9.0-beta3 and prepare for release.
16:32<Samu>master took 51 minutes
16:32<+michi_cc>Having good support for some of the more obscure systems isn't a disadvantage, unless it is utterly broken.
16:32<Samu>and it wasn't a debug build
16:32<TrueBrain>michi_cc: the key is in "good support"
16:32<TrueBrain>which implies the code is at least compiled from time to time :)
16:33<@peter1138>Samu, I thought it was 16 minutes earlier?
16:33<TrueBrain>currently we have no visibility if things like DOS, BeOS, MorphOS, OSX 32bit, even compile or let alone link
16:33<Samu>it was for that specific case, it varies apparently
16:33<Samu>it's still all about randomness
16:33<+glx>TrueBrain: so something similar to autodetectSSE for xaudio2 is ok I guess
16:33<TrueBrain>glx: yup
16:33<@peter1138>Samu, ok, so what about with nielsm's kdtree?
16:34<TrueBrain>code is already in config.lib, so yeah, it is as easy as that looks :)
16:34<+michi_cc>Ahh, I looked at the beta1 update commit, and these files where done earlier it seems.
16:34<TrueBrain>michi_cc: yeah .. after a release, people already prepare for a 'beta1' for some files
16:34<Samu>it's asserting with the old method, so it's gonna take at least the same time
16:34<TrueBrain>it is a bit random, tbh
16:34<@peter1138>Ah, because it includes the test to see if it's correct. Right.
16:34<@peter1138>So you're complaining it's taking a long time even though that's just a debug test...
16:35<Samu>it's release x64
16:35<@peter1138>That's not what I mean.
16:35<@peter1138>The test to make sure it is correct is only there temporary. It is there for debugging.
16:35<Samu>9976/12544 towns generated so far
16:36<Samu>this in 20 minutes
16:36<TrueBrain>michi_cc: I have been thinking how to script it; mostly debian is a bit of an issue, but I think we should just have a changelog with a single entry in it: the current version
16:36<+michi_cc>TrueBrain: Who is making sure what download is behind: "${OPENGFX_BASE_VERSION}.7z" ?
16:36<TrueBrain>me, I guess
16:36<TrueBrain>part of the old infrastructure
16:36<+michi_cc>And of course there is no OpenGFX version with the group icons yet.
16:36<TrueBrain>so poke me if we have to add a new version
16:37<Samu>the closer it gets to finishing, the longer it takes
16:37<TrueBrain>if I remember correctly, that folder is a bit weird
16:37<@peter1138>Yes, that function takes long when there are more towns.
16:37<+michi_cc>The installer script links to "1.2.0", which doesn't match any OpenGFX release.
16:37<TrueBrain> vs
16:37<+michi_cc>planetmaker: You doing OpenGFX? :p
16:37-!-Beerbelott [~Berbe@2a01:e0a:6:8070:2141:d1fd:fa74:b23a] has left #openttd []
16:37<TrueBrain>michi_cc: yeah, the 1.2.0 is the OpenTTD version
16:37<TrueBrain>not the OpenGFX version
16:37<TrueBrain>it symlinks to the correct file
16:37<TrueBrain>had something to do with NSIS sillyness
16:39<TrueBrain>absolutely no idea why this was done btw
16:39<DorpsGek_II>[OpenTTD/OpenTTD] michicc updated pull request #7276: Update: Changelog for 1.9.0-beta3 and prepare for release.
16:39<DorpsGek_II>[OpenTTD/OpenTTD] TrueBrain dismissed a review for pull request #7276: Update: Changelog for 1.9.0-beta3 and prepare for release.
16:40<Samu>have u considered kdtree stuff or voronoi stuff for AI lists?
16:41<TrueBrain>I think it is to make a mapping between OpenTTD version and OpenGFX version that are compatible
16:41<Samu>or this makes no sense
16:41<TrueBrain>but it just looks weird .. and I cannot find a good reason to explain it
16:41<TrueBrain>possibly Rb remembers
16:42<TrueBrain>but in 7 years we hadn't have to touch this, so .. who knows
16:42-!-drac_boy [] has joined #openttd
16:42-!-drac_boy is "OFTC WebIRC Client" on #openttd
16:43<drac_boy>hi there
16:45<TrueBrain>either way: michi_cc, if you get that patch in, just tag via the GitHub page (just make a new release, select the commit, fill in the tag, and leave the rest empty)
16:45<TrueBrain>the CI / CD will take over, and ~40 minutes later it will be available
16:45<TrueBrain>if it breaks ... I will clean it up tomorrow :P
16:45<TrueBrain>off to bed; night
16:46<Samu>10840/12544 in ~30 minutes
16:47<drac_boy>just a bit curious about it but is it only tunnels and some bridges alone that have clipping issues when it comes to extra-tall vehicle sprites?
16:47<Samu>it appears to be doing well
16:48<Samu>i can see the bridge just popping in
16:48<Samu>gonna be matching master / 1.9.0-beta2
16:51<DorpsGek_II>[OpenTTD/OpenTTD] nielsmh updated pull request #7250: K-d tree data structure for spatial lookups
16:52<@planetmaker>michi_cc, I will, yes
16:53<@peter1138>21:40 < Samu> have u considered kdtree stuff or voronoi stuff for AI lists?
16:53<@peter1138>Samu, what does that even mean?
16:54<Samu>creating lists with tons of items slows down ais
16:54<@peter1138>Don't do it then.
16:55<Samu>11697/12544 ~40 mins
16:56<@planetmaker>michi_cc, it seems to me that some fixes are left-out from the changelog. On purpose?
16:56<@planetmaker> is what I get as changes
16:56<+michi_cc>I left out all CI stuff and anything that fixes unreleased commits. If I have missed something, please make a note.
16:57<@planetmaker>but... I didn't check for "fixes unreleased"
16:57<+michi_cc>And I combined some commits.
16:59<+michi_cc>And I dumped fixes to e.g. generate.vbs as well, no gameplay effect.
17:01<Samu>2.742.641 ms elapsed!
17:01<@planetmaker>Fix #7159, e934f09: Waiting time at red one-way signals was too short.
17:01<@planetmaker> is missing, iirc
17:01<DorpsGek_II>[OpenTTD/OpenTTD] michicc updated pull request #7276: Update: Changelog for 1.9.0-beta3 and prepare for release.
17:02<LordAro>michi_cc: TrueBrain: am reviewing
17:02<Samu>matches 1.9.0-beta2 and master
17:02<+michi_cc>It not ("Fix #7159: Waiting time at red one-way signals was too short"), and it wasn't either before :)
17:02<Samu>cg nielsm
17:03<@planetmaker>he. my search-foo fails. I should go to bed :P
17:03<Samu>last pic
17:04<@planetmaker>Fix: Do not mangle tagged revision strings for network revision strings
17:04<@planetmaker> <-- that?
17:04<@planetmaker>it has an impact on players of beta2
17:04<+michi_cc>Check the updated PR :)
17:05<+michi_cc>I promoted the max order change to feature BTW, better marketing :)
17:05<DorpsGek_II>[OpenTTD/OpenTTD] LordAro requested changes for pull request #7276: Update: Changelog for 1.9.0-beta3 and prepare for release.
17:06*glx likes .git/info/exclude
17:06<DorpsGek_II>[OpenTTD/OpenTTD] michicc commented on pull request #7276: Update: Changelog for 1.9.0-beta3 and prepare for release.
17:07<@planetmaker>yes, noticed that, fine with me
17:07<DorpsGek_II>[OpenTTD/OpenTTD] michicc commented on pull request #7276: Update: Changelog for 1.9.0-beta3 and prepare for release.
17:07<@planetmaker>I don't find anything further missing anymore which I consider essential.
17:08<DorpsGek_II>[OpenTTD/OpenTTD] michicc commented on pull request #7276: Update: Changelog for 1.9.0-beta3 and prepare for release.
17:08<DorpsGek_II>[OpenTTD/OpenTTD] michicc commented on pull request #7276: Update: Changelog for 1.9.0-beta3 and prepare for release.
17:09<DorpsGek_II>[OpenTTD/OpenTTD] michicc commented on pull request #7276: Update: Changelog for 1.9.0-beta3 and prepare for release.
17:09<@planetmaker>and I agree with michi_cc 's comments on LordAro's change requests
17:09<DorpsGek_II>[OpenTTD/OpenTTD] PeterN commented on pull request #7276: Update: Changelog for 1.9.0-beta3 and prepare for release.
17:10<DorpsGek_II>[OpenTTD/OpenTTD] michicc commented on pull request #7276: Update: Changelog for 1.9.0-beta3 and prepare for release.
17:11<Samu>less complex or not really?
17:11<Samu>the original:
17:12<@peter1138>I've given up caring.
17:13<DorpsGek_II>[OpenTTD/OpenTTD] LordAro commented on pull request #7276: Update: Changelog for 1.9.0-beta3 and prepare for release.
17:13<@peter1138>Anything that decides on town growth based on forbidding 90 degree turns is *wrong*.
17:13<DorpsGek_II>[OpenTTD/OpenTTD] michicc updated pull request #7276: Update: Changelog for 1.9.0-beta3 and prepare for release.
17:14<Samu>it can be easily removed now
17:15<LordAro>aaand the CI failed
17:15<DorpsGek_II>[OpenTTD/OpenTTD] LordAro approved pull request #7276: Update: Changelog for 1.9.0-beta3 and prepare for release.
---Logclosed Sun Feb 24 17:16:08 2019
---Logopened Sun Feb 24 17:42:03 2019
17:42-!-mikegrb [] has joined #openttd
17:42-!-Irssi: #openttd: Total of 105 nicks [5 ops, 0 halfops, 3 voices, 97 normal]
17:42<TrueBrain>things break in weird and unexpected ways for people if you try :P
17:42<TrueBrain>anyway, just Azure <-> GitHub issues; we can retrigger that
17:42<TrueBrain>for some reason it fired twice too
17:42<TrueBrain>GitHub is acting up today
17:42<+glx>hmm I can fix the tabs, new commit or force push ?
17:43<TrueBrain>new commit plz
17:43<TrueBrain>michi_cc: I queued a new build; it is running now
17:43<TrueBrain>it seems GitHub has a bit of a delay .. it sends out the webhook before the repo is really updated
17:43-!-Irssi: Join to #openttd was synced in 100 secs
17:43<@peter1138>I've removed tags. On my private repos...
17:43<TrueBrain>so refs don't exist yet, yet they do
17:43<@peter1138>Also, mainly test builds.
17:44<@peter1138>i.e. make test build, deploy to test environment, test, then retag it as production build.
17:44<@peter1138>Hmm, don't actually need to remove the test tag, but... tidiness.
17:45<TrueBrain>I see many more times GitHub <-> Azure did not really played nice
17:45<TrueBrain>in fact ... everything is triggered twice
17:46<TrueBrain>someone is being called into the office I guess :P
17:47<TrueBrain>hmm, no, only the things michi_cc touched triggered twice :P
17:47<DorpsGek_II>[OpenTTD/OpenTTD] glx22 updated pull request #7270: Introduce CMake (and removing all other project-related code)
17:48<TrueBrain>glx: this whole branch will be squashed in the end
17:48<TrueBrain>so more commits is better, or something
17:50<TrueBrain>been happening since the 22th, that GitHub triggers Azure twice for some PRs
17:50<TrueBrain>but not for all
17:50<TrueBrain>also the pushes to master from eints sometimes triggered 2 builds
17:51<+glx>hmm works for MinGW, still norev
17:51<TrueBrain>not really important glx; we are going to migrate it anyway :)
17:52<+glx>yes but that means detection is broken everywhere :)
17:53<TrueBrain>still, not really important :)
17:53<TrueBrain>if it is migrated, it is easier to debug etc
17:53<TrueBrain>debugging the shell version is a bit wasteful :P
17:53<+glx>shell version works, cmake call to shell doesn't ;)
17:54<+glx>but indeed fully conversion is better
17:55<TrueBrain>no clue why Azure is picking up builds twice, sometimes
17:55<TrueBrain>I hope it fixes itself soon
17:57<@peter1138>_dp_, replaced my FOR_ALL_STATIONS scan with the 'original' map-based scan.
17:57-!-snail_UES_ [] has joined #openttd
17:57-!-snail_UES_ is "Jacopo Coletto" on #openttd
17:57<@peter1138>maybe I should do a FOR_ALL_STATIONS scan when the number of stations is low...
17:58<nielsm>peter1138 I was about to suggest that :)
17:58<@peter1138>nielsm, 2 code paths though :/
17:58<nielsm>maybe even compare the size of the tile area to search with the station count
17:58<+glx>oh of course CMAKE_SOURCE_DIR is wrong, it's OPENTTD_SOURCE_DIR
17:58<@peter1138>nielsm, basically, yeah.
17:59<TrueBrain>glx: for?
17:59<TrueBrain>it is rare that you need to use <project>_SOURCE_DIR
17:59<nielsm>peter1138, tried merging in kdtree and using that for station search? :P
17:59<TrueBrain>CMAKE_SOURCE_DIR or CMAKE_CURRENT_SOURCE_DIR should both work in 99% of the cases
17:59<@peter1138>nielsm, nope.
18:00<+glx>ah no changing it doesn't solve so it should be correct
18:00<Samu> moved code around to just before they're needed
18:01<Samu>is it more readable?
18:01<TrueBrain>glx: still, in src/os/windows/, please use CMAKE_SOURCE_DIR if possible
18:01<Samu>bah :&
18:01<TrueBrain>the variable you have there now is not what you should be using in cmake :)
18:02<DorpsGek_II>[OpenTTD/OpenTTD] TrueBrain commented on pull request #7270: Introduce CMake (and removing all other project-related code)
18:02<TrueBrain>wrote it down so I don't forget :D
18:02<+glx>I used something I found in cache, I'm not a cmake specialist ;)
18:03<TrueBrain>the cmake tutorials are short and often easy to understand
18:03<TrueBrain>but in general, variables starting with 'openttd' are created because the project is called like that
18:03<+michi_cc>@topic set 1 1.9.0-beta3, 1.8.0
18:03-!-DorpsGek changed the topic of #openttd to: 1.9.0-beta3, 1.8.0 | Website: * (source: github, translator: translator, server list: servers, wiki: wiki) | Don't ask to ask, just ask | 'Latest' is not a valid version, 'Most recent' neither | English only
18:04<TrueBrain>means that if you rename the project, the variable changes
18:04<TrueBrain>so often it is better to avoid them
18:04<TrueBrain>(and in fact, in 99% of the cases you can :D)
18:04<drac_boy>mmm anyway need to broil some supper so ... have fun
18:04-!-drac_boy [] has left #openttd []
18:04<+michi_cc>Somebody else do forum/news post this time. I'm off.
18:05<TrueBrain>night michi_cc
18:05<@peter1138>Broil... such an Americanism.
18:05<TrueBrain>website is building as we speak, so I think Azure is doing fine .. it is GitHub that is acting up .. meh
18:07<DorpsGek_II>[OpenTTD/OpenTTD] glx22 updated pull request #7270: Introduce CMake (and removing all other project-related code)
18:07<TrueBrain> <- there we go :D
18:07<TrueBrain>so happy with this automation :D
18:08<TrueBrain>glx: don't bother too much with hashes; when we rebase to catch up with master, they will be invalid anyway :P (just as a FYI)
18:08<TrueBrain>but nice work :D happy someone is tackling mingw :D
18:08<TrueBrain>right, off to bed again; night :)
18:08<+glx>I have it installed, so not too hard to test
18:10<@peter1138>Hmm, how do I get the number of stations in a game?
18:12<Samu>now without 90 degrees
18:12<DorpsGek_II>[OpenTTD/OpenTTD] SamuXarick updated pull request #6931: Change: Prevent town growth from blocking ships
18:17<DorpsGek_II>[OpenTTD/OpenTTD] James103 commented on issue #7059: Town name language choice affects number of towns / world population
18:20<Samu>why not multi language names for towns?
18:20<Samu>it's a world, not a country
18:22<Samu>if it runs out of french names, then create towns from some other languague, and if that runs out of languagues, then pick yet another, and so on
18:22<Samu>out of names*
18:24<@peter1138>nielsm, hmm, don't think it's worth it.
18:25<@peter1138>nielsm, in the case when scanning all stations is faster, it's very likely that the performance different is not noticable, because it'll be a tiny game.
18:25<@peter1138>it'll be about twice as fast as a map scan.
18:26<@peter1138>However in a save like wentbourne, station scan is about 10x slower than map scan.
18:26<@peter1138>and in the 50k stations map, station scan is... welll
18:26<@peter1138>About 50x slower.
18:27<@peter1138>map scan is slow due to overlapping stations in that save.
18:27<@peter1138>but it's still faster than station scan, heh.
18:29<Samu>where is gabgad
18:30-!-nielsm [] has quit [Ping timeout: 480 seconds]
18:31<Samu>downloading beta3
18:31<Samu>glx, the nsis installer text is blurry
18:32<Samu>probably high dpi aware stuff
18:32<+glx>I don't know if we can do something about that
18:36<Samu>not sure what I'm reading
18:36<Samu>is it this?
18:37<+glx>yes that's what I'm reading
18:43-!-Progman [] has quit [Remote host closed the connection]
18:50<@peter1138>Ok, that resolves it.
18:52-!-snail_UES_ [] has quit [Quit: snail_UES_]
18:59<+glx>and of course my nsis install is too old
19:00<Samu>do be do
19:01-!-Flygon [] has joined #openttd
19:01-!-Flygon is "Flygon" on #openttd
19:02<@peter1138>Yellow plastic shoobedoobe?
19:02-!-Futurefail[m] [~futurefai@2001:470:1af1:101::316c] has joined #openttd
19:02-!-Futurefail[m] is "" on #openttd
19:02<Samu>testing voronoi again
19:03<Samu>will assert at 780 towns
19:04<Samu>gonna move ClearTownVoronoiHold(); to below CommandCost rc = DoCommand(t->xy, t->index, 0, DC_EXEC, CMD_DELETE_TOWN);
19:07<Samu>nop, still asserts
19:07<Samu>at 780
19:08<Samu>the town must exist
19:08<Samu>even if it's a 0 population town
19:08<Samu>so hmm..
19:09<Samu>or ... try_clear = IsTileOwner(tile, OWNER_TOWN) && ClosestTownFromTile(tile, UINT_MAX) == t;
19:09<Samu>this closesttownfromtile call
19:09<Samu>must call using the old method
19:12<DorpsGek_II>[OpenTTD/OpenTTD] PeterN updated pull request #7235: Change: Non-rectangular sparse station catchment area
19:14<LordAro>oh hey, beta3 happened
19:14<LordAro>gj people
19:14*LordAro has been busy writing mediawiki plugins
19:14<LordAro>shockingly, they now seem to work
19:17<Samu>i broke voronoi lol
19:18<Samu>ah no, nevermind
19:18<Samu>was looking at the wrong window
19:19<DorpsGek_II>[OpenTTD/OpenTTD] PeterN commented on pull request #7235: Change: Non-rectangular sparse station catchment area
19:19<@peter1138>That could've been an interesting desync to find :/
19:20<@peter1138>May not have done, mind.
19:20<Samu>better test release build or I'm not finished today
19:21<Samu>waiting 50 minutes
19:22<Samu>this time, for voronoi
19:22<@peter1138>Must remember to actually compile before committing.
19:22<@peter1138>It's not quite as bad as the SVN days :D
19:22<LordAro>peter1138: didn't you add `make regression` to your precommit hooks?
19:24<+glx>Samu: please test
19:24<Samu>the installer?
19:24<+glx>no need to click on install on the last page
19:25<Samu>still looks blurry
19:25<Samu>ah wait
19:26<Samu>this is the old one then?
19:26<Samu>redownloading, gotta try again
19:26<+glx>it's the same installer version, but not the right exe
19:27<+glx>so don't click on "install" ;)
19:28<Samu>no more blurr
19:29<Samu>i dont install?
19:29<Samu>why not?
19:29<+glx>because it's a build I made, not the same as the compile farm
19:29<@peter1138>Because it's just a test of the installer.
19:29<Samu>ok, but i uninstalled the real one :(
19:29<+glx>and I can't test dpi locally
19:29<@peter1138>Reinstall it then.
19:30<Samu>no more blurr, everything's looking neat now, albeit smaller
19:30<Samu>which is normal
19:30<+glx>well reinstall the real one, not mine
19:30<DorpsGek_II>[OpenTTD/OpenTTD] PeterN updated pull request #7235: Change: Non-rectangular sparse station catchment area
19:31<@peter1138>LordAro, I took it out cos it was slow ;(
19:31<@peter1138>LordAro, I should at least have it on pre-push hook.
19:33<DorpsGek_II>[OpenTTD/OpenTTD] glx22 opened pull request #7277: Fix: [windows] make the installer DPI aware
19:34<@peter1138>Oh look, Azure blew up again :/
19:35<+glx>I can't help
19:36<@peter1138>Nobody can ;(
19:36<@peter1138>It's just Azure.
19:36<LordAro>glx: windows -> Windows :>
19:36<Samu>looks like voronoi won't assert, 9000 towns without asserting yet
19:36<DorpsGek_II>[OpenTTD/OpenTTD] PeterN approved pull request #7277: Fix: [windows] make the installer DPI aware
19:36<@peter1138>Better wait for that one to build as well :-)
19:36<Samu>3500 more towns to go :(
19:37<DorpsGek_II>[OpenTTD/OpenTTD] glx22 dismissed a review for pull request #7277: Fix: [windows] make the installer DPI aware
19:37<DorpsGek_II>[OpenTTD/OpenTTD] glx22 updated pull request #7277: Fix: [windows] make the installer DPI aware
19:38<@peter1138>That's... quite mad :/
19:38-!-keoz [~keikoz@2a01:e35:2fd5:51e0:d790:795d:2cc7:b53d] has quit [Ping timeout: 480 seconds]
19:38<+glx>fixed the commit message
19:38<DorpsGek_II>[OpenTTD/OpenTTD] LordAro approved pull request #7277: Fix: [windows] make the installer DPI aware
19:38<@peter1138>glx, if you do a "squash and merge" you can edit the commit message (and it includes in the PR# in it)
19:39<+glx>ah right, I always forget this option
19:46<Samu>this is so slow ...
19:46<Samu>2200 towns to go
19:47<DorpsGek_II>[OpenTTD/OpenTTD] glx22 merged pull request #7277: Fix: [windows] make the installer DPI aware
19:53<Samu>10-15 more minutes
19:58-!-snail_UES_ [] has joined #openttd
19:58-!-snail_UES_ is "Jacopo Coletto" on #openttd
20:07<Samu>last pic
20:08<Samu>removing assert, to see the new real time
20:08<Samu>it takes
20:13<Samu>89.550 ms
20:13<@peter1138>89 seconds.
20:14<@peter1138>Compared to... 40 minutes?
20:14<Samu>46-50, depending on cpu usage
20:14<Samu>turbo or whatever
20:15<Samu>let me try kdtree without asserts
20:17<Samu>the assert is gone already?
20:18<Samu>nielsm works fast
20:18<@peter1138>nielsm's is the preferred solution at this point.
20:18<@peter1138>The voronoi one adds a huge chunk of data to the map array.
20:22<Samu>95.038 ms
20:22<Samu>6 more seconds... voronoi wins
20:23<@peter1138>4096^2 map?
20:24<@peter1138>Check the memory usage :-)
20:24<Samu>have to repeat...
20:24<@peter1138>Hm, voronoi will add 32MB for that. Not massive, but still.
20:24<+glx>6s diff is nothing on this scale
20:25<@peter1138>Yeah, both are way faster than without.
20:27<@peter1138>Ok, double click in ottd is a fail, cos the single click even already fired :S
20:28<@peter1138>Can't do ctrl-click, cos that is already taken.
20:28<@peter1138>It's new button time I think :/
20:28<Samu>874,8 MB for voronoi
20:29<Samu>841,0 MB for kdtree
20:29<@peter1138>Yeah that's about right, but again, doesn't matter much for that size.
20:29<@peter1138>Pretty close to 32MB :-)
20:30<Samu>@calc 874,8 - 841,0
20:30<@DorpsGek>Samu: Error: Something in there wasn't a valid number.
20:30<Samu>@calc 874.8 - 841.0
20:30<@DorpsGek>Samu: 33.8
20:36<Samu>2.742.641 ms for the master, a few hours ago
20:36<Samu>@calc 2742641 / 60
20:36<@DorpsGek>Samu: 45710.6833333
20:37<Samu>@calc 2742641 / 60000
20:37<@DorpsGek>Samu: 45.7106833333
20:37<Samu>45 minutes
20:37<+glx>so huge improvement
20:42-!-Wormnest [~Wormnest@] has joined #openttd
20:42-!-Wormnest is "Wormnest" on #openttd
20:43-!-Wormnest [~Wormnest@] has quit []
20:50<Samu>and all this because I was testing my branch
20:51<Samu>i was generating big fat towns with tight water passages
20:51<Samu>to investigate for possible problems
20:53<Samu>actually, the assert test is really useful, gonna try it for this
20:54<@peter1138>That test is only useful in the case of changing how calcclosesttown works.
20:54<@peter1138>Otherwise it's irrelevant and a waste of your time.
20:55<Samu>i changed GrowingBlocksblalbal
20:55<Samu>let me assert whether it does the same as before
20:55<@peter1138>That doesn't change how calcclosesttown works.
20:55<Samu>meh i dont get u
20:57<@peter1138>Evidently not.
21:07<Samu>eww asserted rather quickly
21:07<Samu>maybe 90 deg is enabled...
21:08<Samu>that was it
21:09<Samu>do u like the new code?
21:10<Samu>inb4 no
21:10<Samu>does the same as the old one, provided forbid 90 degrees is disabled
21:10<Samu>just asserted
21:10<Samu>i mean just assert tested
21:10<Samu>and passed
21:11<Samu>gonna test yours with an assert
21:12<Samu>since there's no ship depots during world generation, it should not fail, right?
21:13-!-HerzogDeXtEr [] has quit [Read error: Connection reset by peer]
21:17<Samu> bool old = OldGrowingBlocksWaterConnection(tile);
21:17<Samu> bool petern = PeterNGrowingBlocksWaterConnection(tile);
21:17<Samu> assert(old == petern);
21:20<Samu>yay cg, it passed
21:40<Samu>peter1138, yours done in another manner
21:42<Samu>corner is only used once
21:42<Samu>can be even less
21:42<Samu>TileIndex tile_o = AddTileIndexDiffCWrap(tile, TileIndexDiffCByDir(corner_to_direction[OppositeCorner(GetHighestSlopeCorner(slope))]));
21:45<Samu>you dont need to test if tile_a or tile_b are valid if you only test tile_o
21:45<Samu>let me try make it even simpler
21:50<Samu> :)
21:50-!-Thedarkb-X40 [] has joined #openttd
21:50-!-Thedarkb-X40 is "realname" on #openttd #/r/openttd #oolite
21:52<Samu>passed the assert tests! :)
21:57<Samu>well I'm off to bed
21:57-!-Samu [] has quit [Quit: Leaving]
22:14-!-Gustavo6046 [~Gustavo60@] has quit [Ping timeout: 480 seconds]
22:18-!-D-HUND [~debdog@2a00:79c0:645:8f00:7a24:afff:fe8a:d04d] has joined #openttd
22:18-!-D-HUND is "Wowbagger" on #bitlbee #openttd
22:21-!-debdog [~debdog@2a00:79c0:618:9c00:7a24:afff:fe8a:d04d] has quit [Ping timeout: 480 seconds]
22:52-!-tokai|noir [] has joined #openttd
22:52-!-tokai|noir is "Christian Rosentreter" on #openttd
22:52-!-mode/#openttd [+v tokai|noir] by ChanServ
22:59-!-tokai [] has quit [Ping timeout: 480 seconds]
23:17-!-Thedarkb-X40 [] has quit [Ping timeout: 480 seconds]
23:36-!-glx [] has quit []
---Logclosed Mon Feb 25 00:00:58 2019