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