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

Powered by YARRSTE version: svn-trunk