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> https://github.com/OpenTTD/OpenTTD/commit/ebbbf0bdfb4abd849bb1f91254b60687a9660bfc 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 https://git.io/fhbOO 00:11:11 <DorpsGek_II> [OpenTTD/OpenTTD] TrueBrain merged pull request #7269: Fix c3dbe836b4: also compile without ENABLE_NETWORK defined again https://git.io/fhbqt 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 findversion.sh 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) https://git.io/fhbqc 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) https://git.io/fhbqc 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> https://imgur.com/Q4SH76j 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) https://git.io/fhbsY 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: https://devs.openttd.org/~alberth/Screenshot_20190224_082702.png 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) https://git.io/fhbn4 08:31:55 <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh commented on pull request #7270: Introduce CMake (and removing all other project-related code) https://git.io/fhbnB 08:33:33 <DorpsGek_II> [OpenTTD/OpenTTD] andythenorth commented on pull request #7271: Cleanup: Ships can always make 90° turns (it's even realistic) https://git.io/fhbn0 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 https://git.io/fhbnw 08:50:27 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on pull request #7261: Add: Road vehicle path cache. https://git.io/fhbni 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 https://git.io/fhbcO 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 https://git.io/fhbcG 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 https://github.com/andythenorth/firs/blob/master/src/templates/produce_secondary.pynml 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) https://git.io/fhbqc 10:03:50 <DorpsGek_II> [OpenTTD/OpenTTD] TrueBrain commented on pull request #7270: Introduce CMake (and removing all other project-related code) https://git.io/fhbcP 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 https://git.io/fhbCL 11:02:37 <DorpsGek_II> [OpenTTD/OpenTTD] TrueBrain commented on issue #7268: Suggestion: Option not to disclose server information when password-protected https://git.io/fhbCZ 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 https://git.io/fhbC4 11:19:18 <DorpsGek_II> [OpenTTD/OpenTTD] Berbe commented on issue #7268: Suggestion: Option not to disclose server information when password-protected https://git.io/fhbC0 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 https://git.io/fhbCi 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 https://git.io/fhbCP 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 https://git.io/fhbCx 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 https://git.io/fhblL 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 https://git.io/fhdMU 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 https://git.io/fh5s1 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> https://github.com/OpenTTD/OpenTTD/commit/e5914fce24118b44f1037ccbe7b28c6595faa1a3 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> https://imgur.com/aMQpmRv 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 is....you'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. https://git.io/fhb8v 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? https://github.com/OpenTTD/OpenTTD/pull/6965 14:26:32 <nielsm> 1.9? https://github.com/OpenTTD/OpenTTD/pull/7081 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? https://github.com/OpenTTD/OpenTTD/pull/7100 14:26:54 <nielsm> 1.9? https://github.com/OpenTTD/OpenTTD/pull/7104 14:26:59 <nielsm> 1.9? https://github.com/OpenTTD/OpenTTD/pull/7109 14:27:14 <nielsm> 1.9? https://github.com/OpenTTD/OpenTTD/pull/7147 14:27:27 <nielsm> 1.9? https://github.com/OpenTTD/OpenTTD/pull/7176 14:27:43 <nielsm> 1.9? https://github.com/OpenTTD/OpenTTD/pull/7225 14:27:55 <LordAro> Eddi|zuHause: yeah 14:28:14 <nielsm> 1.9? https://github.com/OpenTTD/OpenTTD/pull/7261 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) https://git.io/fhbqc 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 https://git.io/fhb8g 14:39:39 <_dp_> peter1138, huh? 14:39:43 <Samu> did it become simpler? https://paste.openttdcoop.org/pee8qlkwu 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. https://git.io/fhb82 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> https://paste.openttdcoop.org/pthkwwqir versus https://paste.openttdcoop.org/pee8qlkwu 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 https://git.io/fhb8M 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) https://git.io/fhbqc 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: https://www.tt-forums.net/viewtopic.php?f=29&t=84827 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) https://git.io/fhbqc 15:21:28 <TrueBrain> glx: https://github.com/LordAro/OpenTTD/commit/1ea407bfa16025fd29edbedc8c50fc27dd93d9eb 15:24:51 <DorpsGek_II> [OpenTTD/OpenTTD] nikolas updated pull request #7086: Change #6173: Update SDL driver to use SDL 2.0 https://git.io/fhamZ 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) https://git.io/fhbqc 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 https://github.com/OpenTTD/OpenTTD/blob/6216c8349a53ab036c100dd88007b142c2f26133/azure-pipelines-ci.yml#L27 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. https://git.io/fhb41 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. https://git.io/fhb4D 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) https://git.io/fhbqc 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 https://git.io/fhb4F 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 https://git.io/fhb4N 16:09:04 <DorpsGek_II> [OpenTTD/OpenTTD] Eddi-z commented on issue #7274: Very long stalls during town generation https://git.io/fhb4A 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> https://github.com/OpenTTD/OpenTTD/pull/7235/commits/e5914fce24118b44f1037ccbe7b28c6595faa1a3 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 (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894159#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 openttd.org 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. https://git.io/fhb41 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 https://git.io/fhbvM 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 https://git.io/fhbBW 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> https://github.com/OpenTTD/OpenTTD/issues/5864 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 https://git.io/fhbBB 16:34:18 <DorpsGek_II> [OpenTTD/OpenTTD] andythenorth closed issue #7274: Very long stalls during town generation https://git.io/fhb4F 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) https://git.io/fhbqc 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 https://git.io/fhbBV 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 https://git.io/fhSYn 16:55:02 <DorpsGek_II> [OpenTTD/OpenTTD] michicc closed issue #6800: [OSX] NSScrollWheel event handling for 2D scrolling should use scrollingDeltaX/Y https://git.io/fhbBX 16:55:04 <DorpsGek_II> [OpenTTD/OpenTTD] michicc merged pull request #7109: [OSX] Use high-precision scrolling properties for 2D scrolling https://git.io/fhKFD 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) https://git.io/fhbB1 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 https://git.io/fh5s1 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? https://www.tt-forums.net/viewtopic.php?p=1193624#p1193624 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 https://github.com/OpenTTD/OpenTTD/issues/7274 17:31:46 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN updated pull request #7235: Change: Non-rectangular sparse station catchment area https://git.io/fh5s1 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 https://stackoverflow.com/a/49106535 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 https://lemire.me/blog/2016/09/15/the-memory-usage-of-stl-containers-can-be-surprising/ 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 https://wiki.openttd.org/Compiling_on_(GNU/)Linux_and_*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> https://imgur.com/a/Sz2sfQV 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! https://0x0.st/z-ce.png 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 https://git.io/fhd4b 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 https://git.io/fh5s1 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> https://imgur.com/a/Sz2sfQV 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 https://git.io/fhbEv 19:54:28 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on pull request #7235: Change: Non-rectangular sparse station catchment area https://git.io/fhbEf 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 https://0x0.st/z-Tz.jpg 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> https://0x0.st/z-To.png <- 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: https://0x0.st/z-T_.jpg 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: https://0x0.st/z-TW.jpg 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: https://0x0.st/z-T3.png 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> https://0x0.st/z-TY.jpg 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. https://git.io/fhbEd 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. https://git.io/fhbEd 20:40:01 <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh commented on pull request #7250: K-d tree data structure for spatial lookups https://git.io/fhbEx 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. https://git.io/fhbEp 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. https://git.io/fhbuk 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. https://git.io/fhbEd 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. https://git.io/fhbEd 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) https://git.io/fhbuE 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. https://git.io/fhbEd 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 https://git.io/fhd4b 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. https://git.io/fhbuz 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) https://git.io/fhbuM 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) https://git.io/fhbuS 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. https://git.io/fhbEd 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. https://git.io/fhbu7 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. https://git.io/fhbu7 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. https://git.io/fhbup 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: "http://binaries.openttd.org/installer/opengfx-${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> http://ftp.snt.utwente.nl/pub/games/openttd/binaries/installer/ vs http://ftp.snt.utwente.nl/pub/games/openttd/binaries/installer/real/ 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: http://ftp.snt.utwente.nl/pub/games/openttd/binaries/installer/readme.txt 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. https://git.io/fhbu7 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. https://git.io/fhbup 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 https://git.io/fhd4b 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> https://paste.openttdcoop.org/ptefugd4c 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. https://git.io/fhbu7 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> https://imgur.com/a/Sz2sfQV 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. https://git.io/fhbzR 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. https://git.io/fhbzw 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. https://git.io/fhbzr 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. https://git.io/fhbzK 22:08:41 <DorpsGek_II> [OpenTTD/OpenTTD] michicc commented on pull request #7276: Update: Changelog for 1.9.0-beta3 and prepare for release. https://git.io/fhbz6 22:09:06 <DorpsGek_II> [OpenTTD/OpenTTD] michicc commented on pull request #7276: Update: Changelog for 1.9.0-beta3 and prepare for release. https://git.io/fhbzi 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. https://git.io/fhbzP 22:10:14 <peter1138> :/ 22:10:34 <Samu> meanwhile... 22:10:40 <Samu> https://paste.openttdcoop.org/pee8qlkwu 22:10:58 <DorpsGek_II> [OpenTTD/OpenTTD] michicc commented on pull request #7276: Update: Changelog for 1.9.0-beta3 and prepare for release. https://git.io/fhbz1 22:11:20 <Samu> less complex or not really? 22:11:49 <Samu> the original: https://paste.openttdcoop.org/pthkwwqir 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. https://git.io/fhbzS 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. https://git.io/fhbu7 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. https://git.io/fhbz9 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? :) https://www.railexpress.com.au/wp-content/uploads/2015/08/cane-train-drawbridge-825x400.jpg (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. https://git.io/fhbz9 22:21:48 <DorpsGek_II> [OpenTTD/OpenTTD] michicc updated pull request #7276: Update: Changelog for 1.9.0-beta3 and prepare for release. https://git.io/fhbu7 22:21:54 <Samu> what is that drac_boy 22:22:12 <drac_boy> heres another angle that shows it better samu https://lh3.googleusercontent.com/-hwzFFECLIUE/V572hTu5c_I/AAAAAAABPNU/3NpkgTqsEDI/queensland-sugarcane-railway-crossin.jpg?imgmax=1600 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> https://paste.openttdcoop.org/pye2z1acs 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. https://git.io/fhbge 22:30:31 <DorpsGek_II> [OpenTTD/OpenTTD] michicc merged pull request #7276: Update: Changelog for 1.9.0-beta3 and prepare for release. https://git.io/fhbu7 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) https://git.io/fhbqc 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) https://git.io/fhbqc 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 findversion.sh 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> https://paste.openttdcoop.org/ph2ugbbgr 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/ottdres.rc.in, 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) https://git.io/fhbgX 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: *.openttd.org (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) https://git.io/fhbqc 23:07:34 <TrueBrain> https://www.openttd.org/downloads/openttd-releases/testing.html <- 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 https://git.io/fhsRY 23:17:44 <DorpsGek_II> [OpenTTD/OpenTTD] James103 commented on issue #7059: Town name language choice affects number of towns / world population https://git.io/fhbgp 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> https://nsis.sourceforge.io/Reference/ManifestDPIAware 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