IRC logs for #openttd on OFTC at 2023-08-18
00:09:52 *** iSoSySt has quit IRC ()
02:19:06 *** Wormnest has quit IRC (Quit: Leaving)
02:19:08 *** D-HUND has joined #openttd
02:22:31 *** debdog has quit IRC (Ping timeout: 480 seconds)
02:30:40 *** tokai|noir has joined #openttd
02:30:40 *** ChanServ sets mode: +v tokai|noir
02:37:38 *** tokai has quit IRC (Ping timeout: 480 seconds)
02:41:11 *** D-HUND is now known as debdog
05:04:19 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
06:21:29 <Bouke> truebrain: From my last crash (after I found the right log):
06:21:29 <Bouke> ` [11] openttd 4497896040 (NewsWindow::NewsWindow(WindowDesc*, NewsItem const*) + 1384)`
06:21:29 <Bouke> Which is where the crash occurred right?
07:09:41 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
07:21:00 <andythenorth> lunch?
07:21:13 <alfagamma_0007> Not yet
07:25:05 <andythenorth>
07:25:05 <andythenorth> is this stupid?
07:25:07 <andythenorth> goes it delete?
07:25:11 <andythenorth> variants maybe?
07:25:22 <alfagamma_0007> No
07:25:22 <alfagamma_0007> This is not stupid at all
07:25:37 <alfagamma_0007> Variants maybe yes
07:26:00 <andythenorth> there's no way to set the subtype across a whole group
07:26:10 <andythenorth> so it's a stupid UI for the player to have to use
07:26:34 <andythenorth> can't use subtypes in station refits
07:29:07 <truebrain> hmm, seems MacOS debug symbols really do not contain the sourcefile and linenumber
07:29:09 <truebrain> that is just a shame
07:30:11 <truebrain> let's try creating a dSYM, see if they are in there ...
07:35:59 <peter1138> Wireguard is supposed to be easy. Why am I struggling with it? :/
07:36:06 <truebrain> oof
07:45:33 <truebrain> manual: set this variable to create dsym files
07:45:37 <truebrain> me: sets those variables
07:45:42 <truebrain> cmake: naaaahhhh bro
07:51:03 <truebrain> `10 openttd!HandleKeypress(unsigned int, char32_t) [window.cpp : 2675 + 0x9]`
07:51:09 <truebrain> TADA! MacOS filename and linenumbers ๐Ÿ˜„
07:51:30 <andythenorth> WP
07:51:32 <andythenorth> GG
07:52:18 <truebrain> turns out, MacOS can convert an executable to poop out dsym symbols, which can be converted to filename + linenumber .. so odd .. information is in the binary, but breakpad can't see it or something
07:52:19 <truebrain> owh well ๐Ÿ™‚
07:52:23 <truebrain> problem .. problem solved!
08:05:01 *** NGC3982 has quit IRC (Ping timeout: 480 seconds)
08:24:46 <peter1138> Hm
08:25:03 <peter1138> You realise you are now our MacOS expert (again?)?
08:25:18 <truebrain> nah
08:25:28 <peter1138> !seen bjarni
08:25:32 <peter1138> ๐Ÿ˜„
08:26:07 <truebrain> I am trying to understand how color space is done in our code
08:26:12 <truebrain> but MacOS shit always confuses me
08:26:18 <truebrain> it calls a function I can't find any documentation on
08:27:19 <andythenorth> what's the function?
08:27:29 <andythenorth> not that I know anything about mac dev ๐Ÿ˜›
08:28:14 *** NGC3982 has joined #openttd
08:28:32 <truebrain> the problem is the documentation here
08:29:31 <truebrain> Apple's dev documentation is just .. shit
08:30:15 <truebrain> if I would be to guess, this function is deprecated, but .. how do I find out! NOBODY KNOWS! ๐Ÿ˜›
08:34:05 <truebrain> ah, no, set/get functions aren't documented
08:34:31 <truebrain> only the member is
08:34:53 <truebrain> these guys .... these guys ....
08:35:46 <andythenorth> only the world's most valuable company or something
08:36:36 <truebrain> I am pretty sure the blue-effect is due to color space
08:36:37 <truebrain> but .. hard to vrify
08:37:39 <truebrain> the RGB channels just aren't right .. I think it is GBR
08:46:05 * andythenorth crowdfunds TB a mac
08:46:24 <truebrain> pass
08:47:16 <peter1138> An M2 MacMini might be nice... use it as a remote for VS Code ๐Ÿ˜‰
08:49:11 <andythenorth>
08:50:01 <alfagamma_0007> andythenorth: Real
09:01:35 <truebrain> this blue tint stuff is really process of elimination ... and a slow one. Starting OpenTTD takes ~40s ...
09:01:43 <truebrain> I think disk-access is really slow
09:06:06 <peter1138>
09:06:06 <peter1138> andythenorth: Nope
09:06:16 <peter1138> Oof that came out a bit big :/
09:06:29 <truebrain> can't make it big enough to bring your point across ๐Ÿ˜„
09:06:40 <andythenorth> how much is a mac mini anyway?
09:07:03 <andythenorth> too much
09:07:27 <andythenorth> refurb M2 air is better
09:07:49 <truebrain> issue with those weird MacOS bugs, you don't need just one Mac
09:07:58 <truebrain> as some problems only happen on one, not on another, etc
09:09:24 <peter1138> <>
09:09:27 <peter1138> What could go wrong...
09:09:45 <truebrain> "An Iowa", somewhere around there ๐Ÿ˜›
09:09:54 <peter1138> QUite.
09:10:42 <andythenorth> free speech though
09:10:55 <peter1138> Damn, although my ride was "only" 36.5km/h average overall, there's an 11.67 km segment on which I averaged 38.7 km/h. No wonder my legs hurt.
09:11:11 <truebrain> lol
09:11:35 <truebrain> okay .. even 32bpp graphics is rendered with a blue-tint, so it isn't our code perse
09:11:48 <truebrain> let's render some basic colours, see what is actually going on here
09:12:08 <truebrain> I ruled out a various of things in our code, like brightness, alignment issues, etc
09:12:23 <truebrain> might still be related to something HDR, I dunno ..
09:12:53 <peter1138> Is it RGB vs BGR or is the effect more subtle than that?
09:13:07 <truebrain> I tried that, but that doesn't seem to tell the whole story
09:13:16 <truebrain> at least with BGR the green "New Game" button is green
09:13:19 <truebrain> (instead of red)
09:13:23 <truebrain> but there is still a blue wash
09:14:11 <truebrain> maybe the drawing buffer is off by one byte or something? Even that wouldn't really explain it ... going to change all sprites to a single solid colour, see what that tells me
09:14:42 <truebrain> The "R" channel is green for sure
09:15:30 <truebrain> now let's see what the "B" channel actually does
09:15:46 <peter1138> Hmm, maybe A in the wrong place...
09:15:58 <peter1138> ARGB vs BGRA etc...
09:16:17 <truebrain> tried that variant, still wrong, but couldn't see why ..
09:16:26 <truebrain> it is hard to tell what parts of the colours are wrong ๐Ÿ˜„
09:16:39 <truebrain>
09:16:40 <truebrain> B == R ๐Ÿ™‚
09:17:04 <truebrain> euh, no, wait ..
09:17:11 <truebrain> RGBA -> GR?? so far
09:17:23 <truebrain> so AB? Let's find out!
09:18:52 <truebrain> GRA .. let's check B to be sure ..
09:20:56 <truebrain> yup, RGBA -> GRAB
09:21:02 <peter1138> wtaf
09:21:09 <peter1138> ftaw
09:21:30 <truebrain> some endian bit flipping going on?
09:21:40 <truebrain> is MacOS like: this smells like a PPC game ๐Ÿ˜›
09:22:43 <peter1138> I've never heard of A not being at either end.
09:22:58 <truebrain> an off-by-2 somewhere? Dunno
09:23:16 <truebrain>
09:23:24 <truebrain> the blue wash is still there, but this is because of remapping and other stuff I didn't change
09:23:33 <truebrain> but the menu is now correct .. so it is actually GRAB
09:23:39 <peter1138> Huh
09:23:51 <truebrain> paint me yellow and call me a banana
09:24:18 <andythenorth>
09:24:18 <andythenorth> if we made ships dock alongside docks...I could make the side doors open on these
09:24:20 <andythenorth> definitely worth it?
09:24:40 <peter1138> Yes, do it.
09:24:54 <truebrain> sounds like a solid PR to create; go for it!
09:25:20 <alfagamma_0007> Loving this
09:26:14 <andythenorth> we'd just need state machines or something
09:26:50 <peter1138> Ship length. Require docking locations of minimum length....
09:27:06 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on issue #10251: [Bug]: blue tint with hardware acceleration on
09:31:53 <andythenorth> peter1138: might be super
09:32:11 <andythenorth> still infinite capacity
09:32:21 <andythenorth> but needs facilities
09:32:58 <peter1138> Also, the "articulated ship" stuff might be useful for allowing longer ships to be split into multiple sprites to 'fix' clipping, but obviously would require "a few" changes for that.
09:32:59 <alfagamma_0007> Uh
09:32:59 <alfagamma_0007> Andy
09:32:59 <alfagamma_0007> Do you mind I borrow some sprites from Iron Horse?
09:33:11 <andythenorth> alfagamma_0007: GPL v2 or v3
09:33:15 <alfagamma_0007> Credits would be given where warranted
09:33:21 <alfagamma_0007> GPL v2
09:33:27 <andythenorth> no need to ask ๐Ÿ™‚
09:33:30 <andythenorth> but thanks anyway
09:33:40 <andythenorth> do you have them to hand?
09:33:52 <alfagamma_0007> Wdym
09:33:54 <andythenorth> I can zip the current sprites folder if you want
09:34:15 <alfagamma_0007> I just need early 1900s steam loco sprites
09:34:53 <andythenorth>
09:34:59 <alfagamma_0007> It's a pain sourcing actual info about early steam locos
09:34:59 <alfagamma_0007> Thus I guess I will just keep British locos in India Set
09:35:19 <andythenorth> fair, there would have been many exports anyway
09:36:01 <alfagamma_0007> Plus Hugh Hughes book is very expensive for me to actually get my hands on
09:38:01 <andythenorth> my Hindi is almost non-existent, why _do_ Indian locos have ghetto bars on them?
09:38:12 <alfagamma_0007> That's Bengali
09:38:20 <alfagamma_0007> For safety
09:38:20 <andythenorth> that's how good my Hindi is
09:38:35 <andythenorth> I could hear 'apna'
09:39:25 <andythenorth> so in the US they were ghetto bars because people would throw objects at trains in the 70s
09:39:40 <andythenorth> UK locomotives have toughened windscreens for similar reasons
09:39:40 <alfagamma_0007> Also serves that purpose as well
09:40:11 <alfagamma_0007> Strikers tend to destroy public property a lot everywhere
09:56:30 <truebrain> okay, so instead of RGBA we have GRAB .. which is not just an offset in the buffer, but also a flip .. RG and BA are flipped .. that is so weird ..
09:56:44 <truebrain> still feels like BE vs LE issue, but that is odd too
09:56:53 <peter1138> Which blitter is in use, or does it not matteR?
09:57:01 <truebrain> I tried all; all the same result
09:57:10 <truebrain> (including SSE, OpenGL, etc)
09:57:32 <peter1138> And 8bpp (if that works at all)?
09:58:00 <truebrain> same
09:58:03 <truebrain> it really isn't in our code
09:58:35 <truebrain> I didn't check how the 8bpp actually works, as we always make an sRGB buffer
09:58:40 <truebrain> so not sure who does the translation to 32bpp
09:58:55 <truebrain> but I think this is MacOS doing something weird for us
09:59:15 <truebrain> let's try some things related to buffer options MacOS offers ...
09:59:26 <truebrain> hahahaha
09:59:29 <truebrain> okay .. yes, it is MacOS ๐Ÿ™‚
09:59:37 <truebrain>
09:59:38 <truebrain> TADA!
10:00:01 <truebrain> it is BE vs LE ๐Ÿ™‚
10:00:07 <truebrain> hahaha, okay, no, we are to blame ๐Ÿ˜›
10:00:17 <truebrain> then when you find the issue, it is laughable
10:00:30 <truebrain> the reason we don't have this issue with our own releases
10:00:34 <truebrain> is that we build against 10.13 or so
10:00:38 <truebrain> if we would go to 13.0, like I am
10:00:39 <truebrain> it will break ๐Ÿ™‚
10:01:24 <truebrain> so when we create a buffer, we say: this buffer is in kCGBitmapByteOrder32Host
10:01:37 <truebrain> but in the old days, kCGBitmapByteOrder32Host didn't exist
10:01:43 <truebrain> so we also say: if kCGBitmapByteOrder32Host doesn't exist, act like it is 0
10:01:49 <truebrain> now as it turns out .. it also no longer exists
10:01:55 <truebrain> and the default? BE!
10:02:24 <truebrain> (which was fine for the old MacOS versions, as that were in fact PPC machines)
10:02:45 <peter1138> I'm still not clear on why it's wrong on a 2-byte level, not 4-bytes.
10:04:02 <truebrain> that is a good question; but that is an academic question ๐Ÿ˜„
10:04:14 <truebrain> claims it should still exist on 13.0+ ..
10:04:19 <truebrain> but the symbol really doesn't exist for me
10:04:48 <peter1138> "Beta"
10:04:52 <peter1138> Is everything on MacOS beta?
10:07:10 <truebrain> owh, it is now an enumaration or something .. hmm .. how do I check the actual header files on this machine ..
10:09:11 <truebrain> seems `kCGBitmapByteOrderDefault` is the new way to go, and is supported by 10.0+, so that should be fine? I dunno ...
10:09:36 <peter1138> "Try it"
10:09:38 <truebrain> but yeah, it is a weird issue .. as the channels are each 8-bit
10:09:48 <truebrain> so it shouldn't actually matter .. but okay
10:10:21 <truebrain> yeah, okay, they are enums now, so I guess `#ifndef` doesn't understand that
10:13:04 <_glx_> Looks like typical MacOS stuff ๐Ÿ™‚
10:13:24 <peter1138> Trying to be compatible made it incompatible.
10:14:59 <truebrain> ah, found out why it does 16-bit BE
10:15:04 <truebrain> the default is 16Big
10:15:11 <truebrain> we need 32Little (or 32Host)
10:15:21 <truebrain> as we assume Colour is a 32bit integer ๐Ÿ™‚
10:15:28 <truebrain> so that is why it was twisted that weirdly
10:16:10 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on issue #10251: [Bug]: blue tint with hardware acceleration on
10:19:34 <_glx_> And as always the debugging has to be done by someone without a real mac
10:20:15 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain opened pull request #11207: Fix: [MacOS] screen looks blue-ish when using newer SDKs
10:20:26 <truebrain> andythenorth: / Bouke : mind checking out #11207, if that doesn't change anything for you two?
10:21:06 <truebrain> what a silly bug ๐Ÿ™‚
10:26:42 <truebrain> so next step is getting the crash.dmp reviewed, and then figure out a way to collect the symbols on a symbol server ๐Ÿ˜„
10:28:27 <truebrain>
10:28:27 <truebrain> tnx MSVC! Helpful
10:34:16 <peter1138> Does "we no longer support PPC" mean that we just don't build for it, or that even if someone tried it wouldn't build/run?
10:34:50 <truebrain> I think MacOS stopped supporting PPC in SDK 10.5 or so?
10:34:54 <truebrain> we need at least 10.13 I think?
10:35:06 <truebrain> not sure on the SDK versions, hence the questionmarks
10:35:12 <truebrain> made it sound sarcastic, wasn't the intend ๐Ÿ™‚
10:35:46 <truebrain> so yeah, as far as I am aware, it is no longer possible to build OpenTTD for PPC, and hasn't for years
10:35:51 <truebrain> I might be wrong ๐Ÿ™‚
10:37:19 <truebrain> ah, the Cocoa driver has hardcoded it needs 10.7
10:39:30 <DorpsGek> [OpenTTD/OpenTTD] PeterN approved pull request #11207: Fix: [MacOS] screen looks blue-ish when using newer SDKs
10:40:15 <peter1138> Works for me. No longer builds means no point in trying to accommodate. Otherwise it's "lazy" ๐Ÿ™‚
10:40:51 <truebrain> I updated the description, for future-reference ๐Ÿ™‚
10:41:31 <peter1138> Also do we need to test if the build from the CI works properly now?
10:41:52 <truebrain> that is why I pinged two people earlier
10:42:04 <truebrain> to make sure it still works for them, as clearly it has been working for them all this time ๐Ÿ˜„
10:42:27 <peter1138> "I fixed it in my VM, but now it's broken for all of you, muwahahahah!"
10:42:41 <truebrain> but really, looking at the code, I am actually not that worried. 16Big is clearly wrong in all cases, as at least it should be 32Big ..
10:42:56 <truebrain> so for sure they didn't redefine that const ๐Ÿ™‚
10:43:20 <truebrain> nevertheless, not merging till either of them confirms it is okay ๐Ÿ™‚
10:43:52 <truebrain> `The Microsoft symbol server provides compressed versions of the symbol files. The files have an underscore at the end of the filenameโ€™s extension to indicate that they're compressed. For example, the PDB for ntdll.dll is available as ntdll.pd_. `
10:43:55 <truebrain> what the actual fuck ....
10:44:04 <truebrain> `ntdll.pdb.gz` was too much effort?
10:44:12 <truebrain> 8.3 shit hitting us again?
10:44:54 <truebrain> also to figure out what compression is actually used ..
10:46:32 <peter1138> Hmm, using 'direct' sql in code always feels a bit painful, but doing a bulk insert or update from a view would require so many little queries doing it the "everything is an object" way...
10:48:52 <_glx_> Oh CAB compression
10:52:55 <orudge> Ah, that brings back memories, Microsoft ACME Setup Toolkit, .EX_ and .DL_ files, all that sort of fun
10:53:49 <_glx_> Windows API has methods for it
10:57:26 <peter1138> PostgresException: 23503: update or delete on table "xxx" violates foreign key constraint
10:57:37 <peter1138> Got to love foreign keys protecting your data ;D
11:05:57 <peter1138> (I know it's fairly basic database stuff, but I've seen so many database that barely have indices, let alone foreign keys.)
11:17:28 <andythenorth> 11207 builds and runs for me
11:21:50 <truebrain> thank you!
11:22:04 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain merged pull request #11207: Fix: [MacOS] screen looks blue-ish when using newer SDKs
11:22:11 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain closed issue #10251: [Bug]: blue tint with hardware acceleration on
11:29:18 <peter1138> Technically it ran for the people who were reporting the blue...
11:29:33 <truebrain> I assumed he would have told me if he started to see blue ๐Ÿ˜›
11:29:56 <truebrain> but yeah, it is fair, I assumed sanity on a Discord user .. that is a dangerous assumption ๐Ÿ˜„
11:34:09 <_glx_> Discord user and grf author
11:35:17 <peter1138> The worst sort!
11:44:07 <truebrain> hmm .. how to get the breakpad tooling for all OSes ... that is more tricky than I would like ๐Ÿ˜›
11:45:11 <truebrain> vcpkg only supports Linux for the tooling part .. and those can't read the MacOS nor Windows debug files ๐Ÿ˜›
11:48:28 <_glx_> There should exist a tool to convert exe/pdb into breakpad symbols
11:49:03 <truebrain> there does exist a tool!
11:49:04 <truebrain> shocker ๐Ÿ™‚
11:49:15 <truebrain> hence my sentences ๐Ÿ™‚
11:50:09 <truebrain> but vcpkg is being lazy
11:50:18 <truebrain> hmmmmmmmmmm
11:55:12 <truebrain> lol, so there is a project file in the source folder of breakpad to build tools .. which produces unresolved symbols ๐Ÿ˜„
11:58:12 <truebrain> `UnDecorateSymbolNameW` is missing .. lol .. guess the libraries are not configured correctly
12:02:40 <truebrain> `CoCreateInstance CLSID_DiaSource {E6756135-1E65-4D17-8576-610761398C3C} failed (msdia*.dll unregistered?)` ... eeuuhh .... sure? WHAT DOES IT MEAN ๐Ÿ˜›
12:05:40 <truebrain> ah ... it is a 32bit binary, which doesn't allow for dumping of 64bit pdb files ...
12:05:47 <truebrain> as that all makes sense and stuff /s
12:13:46 <truebrain> not the only project with that frustration ๐Ÿ˜„
12:17:46 <truebrain> finally got it compiling; w00p!
12:26:10 <truebrain> for some reason, the identifier of the breakpad symbols on Windows is not matching what the crash dump contains .. I guess that is what you get for using dbghelp instead of breakpad to generate the minidump?
12:27:01 <truebrain> still, weird .. hmm
12:28:58 <truebrain> euh, no .... I was looking at the wrong `openttd.pdb`
12:28:59 <truebrain> lol
12:30:05 <truebrain> cool, in the latest MSVC the `openttd.exe` is no longer in a `Debug` folder
12:30:19 <truebrain> but in `out/build/x64-Debug` is everything .. that is starting the game a lot easier on Windows, with custom parameters etc
12:30:32 <truebrain> no clue if that is something we did, but it is nice ๐Ÿ˜„
12:32:51 <peter1138> Wireguard eh... modern secure design, simple to use... requires manual IP configurations ๐Ÿ˜ฆ
12:33:07 <truebrain> you are expected too much ๐Ÿ˜›
12:34:01 <truebrain> so Linux and Mac worked without incident, but on Windows ... I am having a hard time .. so I now have symbol files, in the right format, in the right place .. it just isn't doing anything ๐Ÿ˜›
12:40:36 * andythenorth discovers per-spritelayer recolour sprites
12:49:16 <truebrain> `mismatch detected for 'RuntimeLibrary': value 'MTd_StaticDebug' doesn't match value 'MDd_DynamicDebug'`
12:49:29 <truebrain> this is the day of weird errors
13:09:29 <truebrain> hmm, the `/MD` -> `/MT` is not working for me .. there is no `/MD` ..
13:10:31 <peter1138> Might be why I had warnings about it ๐Ÿ™‚
13:10:40 <truebrain> I have many warnings about it ๐Ÿ˜›
13:10:50 <peter1138> I just assumed it's because I was lazy and hadn't set it up correctly.
13:10:54 <truebrain> but now when I try to compile in breakpad, things actually break
13:11:15 <truebrain> that might still be the case for me ๐Ÿ˜„ But I recreated the build folder, and that made the warning go away
13:11:19 <truebrain> but also no `/MT` ๐Ÿ˜›
13:12:41 <truebrain> for some reason `/MD` keeps winning
13:13:36 <andythenorth> hmm returning a palette from a stored procedure works afaik
13:13:38 <andythenorth> but now it's not
13:13:43 <andythenorth> wondering if 15 bit returns are clipping it
13:13:51 <andythenorth> but it used to work in a different context ๐Ÿ˜›
13:14:04 <truebrain> _glx_: you happen to know how to get it to compile with `/MT` with latest MSVC, or what I might be doing wrong here?
13:19:41 <truebrain> okay, if I finally forced it in some fucked up way, strgen fails to link ๐Ÿ˜„
13:20:29 <truebrain> ah, `/MTd` .. okay .. let's see if that works with breakpad ... still not sure how to fix that properly ๐Ÿ˜ฆ
13:27:35 <andythenorth> does using procedures thrash register 0x100?
13:31:30 <truebrain> right .. no difference between breakpad and dbghelp minidumps .. both fail to give me a stack trace ..
13:37:14 <andythenorth> hmm can't get the spritestack to accept recolour sprites in certain layers
13:41:58 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #11202: Add: use breakpad to create crash.dmp on MacOS / Linux too
13:44:02 <truebrain> so MSVC can read the crashdump just fine .... meh ๐Ÿ˜›
13:48:16 <Bouke> truebrain: Iโ€™ll have a look when I get home. No blueish screen for me. My MBP is on 12.6.5, so might have been an issue when building on 13?
13:48:35 <truebrain> Andy already checked, but tnx anyway ๐Ÿ™‚
13:50:28 <truebrain> lolz .... my issue with symbol files? Windows line ending ....
13:51:50 <truebrain> still not completely there, but at least it is giving me somewhat sane output now
13:55:18 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #11202: Add: use breakpad to create crash.dmp on MacOS / Linux too
13:59:35 <truebrain> right, only issue with Windows minidumps I have now is that it does a stack-scanning to find the next frame after kernelbase.dll, and fails at that .. so it creates a random stacktrace that makes no sense ๐Ÿ˜›
14:00:38 <truebrain> if I load the right symbols for those dlls, it does work fine ๐Ÿ™‚
14:00:46 <truebrain> `10 openttd.exe!MainWindow::OnHotkey(int) [main_gui.cpp : 330 + 0x9]`
14:01:12 <truebrain> or more consistently: `11 openttd.exe!HandleKeypress(unsigned int,char32_t) [window.cpp : 2675 + 0x39]`
14:01:22 <truebrain> but that is annoying, that Windows is that more picky about stack tracing .. meh
14:07:16 <andythenorth> meh I don't frigging understand ๐Ÿ™‚
14:07:22 <truebrain> I know right!
14:07:32 <andythenorth> I can successfully set a palette in first layer of spritestack
14:07:35 <andythenorth> but not second layer
14:14:49 <truebrain> okay, our CI also does the /MT and /MD wrong (for debug builds)
14:15:41 <_jgr_> andythenorth: What does your code look like?
14:16:58 <andythenorth> I've trimmed it a bit
14:16:58 <andythenorth> `reefer_gen_3C_switch_graphics_palette_cabbage_0` and `reefer_gen_3C_switch_graphics_palette_cabbage_1` are the puzzle
14:17:14 <andythenorth> the game renders me 3 layers (2 of ship, 1 of wake)
14:17:19 <andythenorth> the first layer takes the recolour sprite
14:17:23 <andythenorth> the second does not
14:18:02 <andythenorth> I get CC on the second layer, unless I force PALETTE_IDENTITY
14:18:08 <andythenorth> in which case I get no CC
14:18:40 <andythenorth> I've tried moving the calls around to see if something is overwriting 0x100
14:20:49 <andythenorth> when I do force the palette to PALETTE_IDENTITY, sometimes it's very slow to redraw
14:21:23 <andythenorth> but I don't think that's the cause
14:24:17 <andythenorth>
14:24:17 <andythenorth> if I move the sprite, then layer 0 is clearly working
14:24:21 <_jgr_> Hmm, that looks like it would work
14:24:46 <andythenorth> I couldn't see anything obviously wrong here
14:26:15 <_jgr_> Mind sending a copy of the GRF?
14:26:59 <andythenorth>
14:27:22 <andythenorth> the procedures to resolve a palette are pretty horrific, so I expected 15 bit value problem or similar
14:27:29 <andythenorth> but it does work for layer 1
14:28:53 <andythenorth> testing what happens in CB 2D
14:29:07 <andythenorth> palette resolution was working there in an older version without the spritestack
14:32:48 <andythenorth> hmm with CB 2D (layers using PALETTE_DEFAULT), they won't update if in a group
14:32:53 <andythenorth> until move out of the group
14:34:35 <_jgr_> I may be missing something here, but I can't work out which ship in the GRF corresponds to the gist?
14:37:20 <andythenorth>
14:37:20 <andythenorth> should be this one
14:37:32 <andythenorth> but all refrigerated ships use the same rule
14:43:21 <_jgr_> What is the implementation of switch_colour_mappingc
14:44:17 <_jgr_> It appears to be looking at variable 10/extra_callback_info1
14:49:07 <andythenorth> not sure if the version I sent has that on or off, can you see in the debug?
14:49:28 <andythenorth> I don't understand how it interacts with the palette used in sprite layers
14:51:09 <_jgr_> In the version I've got switch_colour_mapping first switches on getbits(extra_callback_info1, 8, 8), and the really complicated implementation is only done for the value 0
14:51:46 <andythenorth> ok thanks
14:52:03 <andythenorth> that's at least part of the strange results
14:52:06 <andythenorth> I'll remove that part
14:54:59 <andythenorth> _jgr_: thanks, I'd never have found that
14:55:02 <andythenorth> legacy code
14:55:39 <andythenorth> I had no idea that would be called if I wasn't using colour_mapping CB 2D
14:55:47 <andythenorth> maybe I made the call somewhere ๐Ÿ˜›
14:59:37 <_jgr_> Sometimes it's easier to understand the output than all the templating/etc on the input ๐Ÿ˜›
15:00:04 <andythenorth> is 2D called from the spritelayers?
15:00:35 <andythenorth> oh I see the entry point
15:00:37 <andythenorth> ok
15:01:05 <andythenorth> that was about 2 hours of not seeing for looking ๐Ÿ™‚
15:02:19 <peter1138> Silly C# telling me to use .Count instead of .Count(). The point of interfaces is I use the interface members, not the implementation's members...
15:13:26 *** esselfe has quit IRC (Remote host closed the connection)
15:18:01 *** esselfe has joined #openttd
15:40:45 *** HerzogDeXtEr has joined #openttd
16:26:40 *** Flygon has joined #openttd
16:41:03 <milek7> interfaces can have properties too
16:50:35 *** Wormnest has joined #openttd
17:03:23 <_glx_> truebrain: was always like that with "open folder" mode
17:05:22 <_glx_> and for the `/MT` / `/MD` stuff sometimes it yells and I just clear the cache to make it happy
17:19:15 <truebrain> yeah, but check the CI .. there is another issue there
17:19:20 <truebrain> as it doesn't actually use `/MT`
17:19:24 <truebrain> but it actually uses `/MD` ๐Ÿ™‚
17:22:14 <truebrain> ha, but I found it, I think
17:22:17 <truebrain> yeah, okay, I did ๐Ÿ™‚
17:31:16 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain opened pull request #11208: Fix: [MSVC] generate static libraries / executables correctly with vcpkg -static target
17:31:28 <truebrain> there .. that should fix that warning for good ๐Ÿ™‚
17:38:58 <truebrain> so first a Mac fix, now MSVC fix ... am I okay?
17:43:21 <truebrain> Mozilla made nice tools to deal with symbol-files for all OSes; nice .. ๐Ÿ˜„
17:43:31 <truebrain> they work 10000x better than the ones from Google
17:43:32 <truebrain> ironic?
17:44:49 <alfagamma_0007> No?
17:47:29 <_glx_> with #11208 the CompileFlags.cmake magic can be removed I guess
17:47:38 <truebrain> for older MSVC, I was thinking?
17:47:44 <truebrain> not sure, honestly
17:47:49 <truebrain> your call, want me to remove it?
17:48:57 <_glx_> older MSVC will still need cmake 3.15+ and it should just work
17:49:31 <_glx_> the hack was to work around cmake forcing /MD
17:50:20 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #11208: Fix: [MSVC] generate static libraries / executables correctly with vcpkg -static target
17:51:07 <truebrain> and ... it is gone ๐Ÿ˜›
17:51:19 <_glx_> "Note that with Visual Studio Generators the native build system may choose to add its own default runtime library selection flag." <-- I'm not sure how to understand this part
17:51:50 <truebrain> yeah ... it is all magic ๐Ÿ˜›
17:52:03 <truebrain> but with latest MSVC this works how I expect; I guess that is the important part? ๐Ÿ™‚
17:52:16 <truebrain> (please also test it on your machine, for good measure ๐Ÿ™‚ )
17:53:47 <truebrain> right, so my crashdump / symbols story is getting there. I can now export pdb (Windows), dSYM (MacOS) and .dbg (Linux) native symbol files, and export all three to breakpad symbol files. The latter I can store on a symbol server.
17:54:05 <truebrain> that makes me wonder if we should still distribute RelWithDebInfo binaries, or just Release binaries .. let's check
17:54:56 <_glx_> the only diff between RelWithDebInfo and Release (for windows at least) is the pdb
17:54:59 <truebrain> right, stracebacks in crash.log and useless .. we always need "the glx" to understand the crash ..
17:55:19 <truebrain> yeah, but on the other targets the symbols remain in the final binaries; I think we can just split them out of there
17:55:24 <truebrain> but checking that is tricky ๐Ÿ˜›
17:56:55 <_glx_> yeah crash.log without the pdb next to the exe doesn't decode function names
17:58:44 <_glx_> MSVC will still require pdb when loading the dmp, but a tool understanding breakpad symbols can also be used I guess
17:59:22 <peter1138> milek7: True but in this case it's not one.
17:59:23 <truebrain> yeah, I also plan to add the pdb to a symbol server, so you no longer have to do the manua labour for that
17:59:52 <truebrain> okay, the linux binaries also don't seem to have the debug symbols .. sortof .. lol. It is complicated, it seems
18:00:14 <_glx_> oh usually I download right openttd zip and the corresponding pdb to extract in the same location
18:00:59 <truebrain> still a lot of debug-related information, just not enough useful stuff .. funny
18:01:08 <truebrain> so where in the release-process is that information lost ๐Ÿ˜„
18:01:10 <_glx_> but symbol server should provide both exe and pdb
18:01:17 <_glx_> for a given dmp
18:01:42 <truebrain> everywhere I read it only stores pdb files; you don't actually need the .exe, only the minidump. But that information might be wrong
18:01:44 <truebrain> we have to test it out
18:01:59 <_glx_> I know it stores dll too
18:02:14 <_glx_> based on what is in my sumbol cache
18:02:14 <peter1138> What is "symbol server"? Who hosts it... etc...?
18:02:29 <peter1138> Or is it something in Windows?
18:02:34 <truebrain> just an object bucket with files in a certain folder structure
18:02:45 <truebrain> it contains all the symbol files of released OpenTTD versions, basically
18:02:56 <truebrain> so you can use most tools that analyze crash-dumps, and say: symbols are over there
18:03:01 <truebrain> and it will find the right symbols for you
18:04:20 <truebrain> (and that all means we can analyze crash-dumps automatically, and even have a "send report" in-game)
18:06:27 <truebrain> okay, seems that Linux has the debug-symbols when it rolls out of the build-step, and cpack removes them nice and cleanly
18:06:43 <truebrain> just .. it is 300+ MiB on Linux, the raw debug-symbols .. that is a bit expensive to store ๐Ÿ˜›
18:06:52 <truebrain> I might only store the breakpad symbols for Linux ๐Ÿ™‚
18:07:20 <truebrain> those are ~3MiB
18:08:00 <truebrain> and on Mac a similar story; cool
18:08:25 <_jgr_> You don't need all the debug information to get a reasonable stack trace
18:08:38 <_jgr_> Use e.g. -g1 instead of -g gives you a much smaller output
18:08:40 <truebrain> exactly; I just need 3 MiB out of that 300 MiB to get a stack trace that tells us everything we need ๐Ÿ™‚
18:09:55 <truebrain> okay, so the only really big question I have is: breakpad for Windows, or dbghelp .. there are pros and cons to both .. with the first, we know all minidumps are made by the same library .. but the second means 1 less dependency
18:10:44 <truebrain> also means we don't depend on the dbghelp.dll version on the host
18:16:45 <truebrain> so I think using breakpad for all OSes is best?
18:23:00 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain opened pull request #11209: Remove: stack-traces from crash.log on all OSes
18:23:07 <truebrain> curious about opinions on that one.
18:25:45 <truebrain> (mostly as I am not 100% sure myself; maybe it should just be in `#ifdef DEBUG` blocks? Guess it depends if any of the developers ever use this information .. I can't stress enough that this is only actually usuable for developers ๐Ÿ˜› )
18:36:55 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #11202: Add: use breakpad to create crash.dmp on MacOS / Linux too
18:38:26 <DorpsGek> [OpenTTD/OpenTTD] eints-sync[bot] pushed 1 commits to master
18:38:27 <DorpsGek> - Update: Translations from eints (by translators)
18:51:03 <andythenorth>
18:51:04 <andythenorth> oof took about a day to make this happen ๐Ÿ˜›
18:51:55 <andythenorth> if I was more adept at auto-generating recolour sprites I could have probably shortcut it ๐Ÿ˜›
18:51:59 <peter1138> Vehicle group colours?
18:52:09 <andythenorth> variants
18:52:13 <andythenorth> with layers
18:52:20 <andythenorth> and recolour sprites
18:52:37 *** ahyangyi has quit IRC (Quit: User went offline on Discord a while ago)
18:52:50 <andythenorth> flat docks though? ๐Ÿ˜›
18:54:55 <_jgr_> truebrain: I'm doing something else for my own builds, but when I'm doing vanilla PRs and stuff, I do use the crashlogs (on Linux)
18:55:48 <_jgr_> The amount of code (for Linux) is quite small and it nearly always produces something which is usable
18:56:52 <_jgr_> (Does that SUNOS stuff even work? Probably that should go no matter what is done with other implementations.)
19:12:14 <_jgr_> Also, users who local compile for dedicated servers almost certainly won't have vcpkg or breakpad on their systems
19:17:06 <truebrain> Yeah, the SunOS stuff was why I made that PR .. I wanted to remove all of SunOS traces ๐Ÿ˜›
19:17:30 <truebrain> also wanted to unify MingW and MSVC, and the windows crash handler is something special (for no reason by the looks)
19:17:41 <_glx_> truebrain: wrong ref in #11209, should be #11202 not #11208
19:17:45 <truebrain> so tnx _jgr_ , good enough argument to keep Linux around. Any opinion about the others?
19:20:57 <_jgr_> The MinGW implementation doesn't try to emit a stack trace at all, there isn't really anything to remove there
19:21:22 <_jgr_> Some of the specialness is for the dialog box, which is probably worth keeping as there's basically no way to get any info on Windows otherwise
19:21:25 <truebrain> The MingW could also just use the dbghelp.dll variant; I don't see why not
19:21:52 <_jgr_> dbghelp doesn't know anything about DWARF
19:22:20 <truebrain> MingW builds DWARF? Ugh .. did not realise that .. fair point
19:22:47 <truebrain> so okay, let's do this a bit different .. I am going to drop SunOS, and I am going to remove the bullshit implementation for mingw and just not print anything. And leave the rest, I guess.
19:23:06 <_jgr_> For my own Windows builds, I'm using MinGW with DWARF, but I'm linking with libbfd for the stacktraces
19:23:58 <_jgr_> libbfd is a surprisingly unhelpful and awkward to build and use, but the results are decent
19:24:13 <truebrain> I am still unsure why we build for MinGW ๐Ÿ˜›
19:24:41 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #11209: Remove: stack-traces from crash.log on all OSes
19:24:44 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain closed pull request #11209: Remove: stack-traces from crash.log on all OSes
19:24:50 <truebrain> anything else in your fork that is worth considering while I am fiddling with this code?
19:25:17 <_jgr_> For various reasons, my branch can be more crashy than vanilla
19:26:21 <_jgr_> So the crash logger implementations try to handle more types of crashes, tolerate crash logger failures, and output more information
19:26:49 <_jgr_> This does make them rather more complicated, which is possibly not what you're after
19:27:11 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain opened pull request #11210: Remove: last remnants of SunOS
19:27:49 <truebrain> if it is useful, I am fine with that. My current plan is to track if a crash happened, and on next start ask to send a report. This will also add a JSON file with what you currently see in the crash.log with various of extra information not in the minidump
19:28:12 <truebrain> so I will check out what extra stuff you do that would be nice to have too
19:28:28 <_jgr_> I will warn you that a lot of it is not pretty at all
19:28:34 <truebrain> btw, this send-report flow would also work for JGRPP; we would just need to setup another Sentry project to report them too, but otherwise that might be interesting to you too
19:28:49 <truebrain> that is okay; haven't worked with messy code in a while ๐Ÿ˜„
19:33:50 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain opened pull request #11211: Remove: MinGW stack trace in crash.log
19:35:43 <truebrain> it helps we don't use MinGW for any releases; you have quite a bit of code for that ๐Ÿ˜„
19:36:38 <truebrain> ah, yes, logging of registers; has that ever been useful? ๐Ÿ˜„
19:37:09 <_jgr_> Sometimes yes
19:37:19 <truebrain> really? Cool ๐Ÿ™‚
19:37:25 <truebrain> can't imagine when, honestly ๐Ÿ™‚
19:39:00 <_jgr_> Mainly for segfaults
19:39:42 <_jgr_> That said, the most recent crash I'm looking into, I've got the disassembly and can see the register value which is wrong, but I still can't work out why
19:39:54 <_jgr_> So there's a limit of how useful it is ๐Ÿ˜›
19:40:00 <truebrain> if you go that deep, isn't the miniedump more useful?
19:40:21 <truebrain> mainly why I ask, to make a JSON, I want the crashes between OSes to be unified .. and this is done only on Windows
19:40:30 <truebrain> so I am wondering .. should we just remove it? or add it to the other OSes?
19:40:55 <_jgr_> To be honest I don't have tooling at the moment to do anything with dump files
19:41:05 <truebrain> that I am going to help with ๐Ÿ™‚
19:41:13 <_jgr_> MSVC just nags me to sign up whenever I try to use it
19:42:08 <_jgr_> For the most part I do all my work on Linux and Windows-only stuff like that is a pain anyway
19:43:30 <truebrain> so if I remove it and make it easier to work with minidumps, you will also be fine with it?
19:44:25 <_jgr_> I've never managed to get anything more than a very basic stacktrace out of dump file, so making it easier to work with sounds good
19:44:30 <DorpsGek> [OpenTTD/py-protocol] TrueBrain opened pull request #26: Fix: content-type of zero is also invalid
19:44:55 <truebrain> yeah, the current form is really difficult to work with, especially if you can't use MSVC. But nothing a bit of scripting and stuff can't fix ๐Ÿ˜„
19:48:54 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain opened pull request #11212: Remove: [Win32] register values in crash.log
19:49:06 <truebrain> the rest of the stuff I can work with, I think ๐Ÿ™‚
19:49:27 <truebrain> Windows has a modules list, which the rest also seems to be lacking; but adding those to other platforms might be very insightful ๐Ÿ™‚
19:49:35 <truebrain> I know the Windows list can be (what GPU DLL is used? ๐Ÿ˜› )
19:50:25 <truebrain> tnx for allowing me to pick your brain on this _jgr_ , it is appreciated!
19:50:32 <_jgr_> No problem ๐Ÿ™‚
19:50:51 <DorpsGek> [OpenTTD/py-protocol] TrueBrain merged pull request #26: Fix: content-type of zero is also invalid
19:50:57 <DorpsGek> [OpenTTD/OpenTTD] romw314 commented on pull request #11012: fix #10995
19:51:21 <truebrain> now to fix a bananas-server issue in production .. turns out, someone is trying their own code against the server ๐Ÿ˜„
19:52:06 <DorpsGek> [OpenTTD/py-protocol] TrueBrain created new tag: 1.6.1
19:55:12 <truebrain> lol .. I either have to make the JSON library mandatory, or I have to create custom structs to collect information in, to write that to both the console and to the JSON (when available)
19:55:48 <truebrain> always annoying, to want to be able to compile (and have a properly functional) OpenTTD with as little mandatory dependencies as possible ๐Ÿ˜›
19:56:27 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #11202: Add: use breakpad to create crash.dmp on MacOS / Linux too
19:57:09 <truebrain> `PacketTooShort()`, `impossible length field of 0 in packet`
19:57:12 <truebrain> someone is having fun ๐Ÿ˜›
20:02:49 *** frosch123 has joined #openttd
20:02:49 <frosch123> how rude, don't they know they are spamming your mailbox?
20:02:57 <truebrain> they aren't
20:03:02 <truebrain> just the one mistake I made was ๐Ÿ˜›
20:11:35 <truebrain> hmm, yes, this JSON-library-is-not-mandatory is going to be a bit more code ๐Ÿ˜„
20:14:36 <frosch123> why do you want it to be optional? just for the challenge?
20:14:47 <truebrain> because people were bitching about it ๐Ÿ˜›
20:15:41 <frosch123> with good reasons or just for the sake of bitching? ๐Ÿ™‚
20:15:59 <truebrain> in the vibe: why make it mandatory if we don't have to ๐Ÿ™‚
20:16:48 <frosch123> i think there is some custom json implementation in gstext, so would removing that be a good enough reason to make it mandatory?
20:17:01 <truebrain> I like your thinking, tnx ๐Ÿ˜„
20:17:25 <truebrain> new bananas-server is being deployed to avoid this bug from existing ๐Ÿ˜„
20:17:46 <frosch123> though since it is "custom", there is ofc the risk of it being slightly different to real json :p
20:18:28 <truebrain> haha
20:18:51 <truebrain> talltyler: also wanted to use it for heightmap (things like towns) loading .. all-in-all, hopefully enough reason ๐Ÿ˜„
20:19:00 <truebrain> we can always 3rdparty vendor the library; it isn't really big
20:22:01 <frosch123> <- that's the parser, the writer is in script_text.cpp
20:22:25 *** felix_ has joined #openttd
20:22:36 <truebrain> ๐Ÿ˜ฎ
20:22:38 <truebrain> lol
20:22:39 <truebrain> yeah
20:22:39 <truebrain> no
20:23:38 <frosch123> but it is a streaming parser, it does not build a dom
20:23:57 <frosch123> do people use the terms SAX and DOM also in json context?
20:24:29 <truebrain> doubtful
20:28:16 <frosch123> ah, crap, it's not json
20:29:30 *** felix has quit IRC (Ping timeout: 480 seconds)
20:29:42 <truebrain> ๐Ÿ˜ฆ
20:30:12 <truebrain> how badly isnt it JSON?
20:32:51 <peter1138> truebrain: Why is it not mandatory?
20:33:13 <peter1138> It's even available on Debian, can't be that problematic ๐Ÿ˜„
20:34:03 <truebrain> so that is 3 votes to make it mandatory ๐Ÿ˜›
20:35:38 <frosch123> truebrain: i am just too old, i am probably mixing up things. it's not a tree structue at all, just a colon separated list
20:35:52 <truebrain> can it be parsed as JSON? ๐Ÿ˜„
20:36:26 <frosch123> anyway, wasn't bananas going to use json via https?
20:37:23 <frosch123> also, you can threaten with using boost::json :p maybe people will then rather get nlohmann :p
20:39:04 <frosch123> it's funny though, the decoder in strings.cpp knows how to do \" inside strings, but the encoder in script_text seems to just raw copy strings without escaping
20:45:42 <truebrain> and that is why you use libraries ๐Ÿ˜„
20:46:16 <michi_cc[d]> frosch123: You want to look at script_event_types.cpp for the JSON "parser" (big quotes)
20:46:35 <michi_cc[d]> ScriptEventAdminPort
20:47:03 <frosch123> oh, thanks
20:47:45 <frosch123> i was thinking of admin/gs stuff, but admin port uses a binary protocol. but then it is hidden there :p
20:48:28 *** felix_ has quit IRC (Read error: Connection reset by peer)
20:48:52 *** felix has joined #openttd
20:48:59 <michi_cc[d]> All the glory: <>
20:50:04 <frosch123> looks like it is a subset of json, accepting only string keys in dicts, and requiring strict comma usage
20:50:13 <frosch123> so replacing it with nlohmann should be safe
20:52:01 <frosch123> oh, it even rejects tab indentation, only space and linebreaks are fine
20:52:10 *** felix has quit IRC (Read error: No route to host)
20:52:21 *** felix has joined #openttd
20:52:28 <frosch123> how many reasons does tb need?
20:52:38 <michi_cc[d]> You can probably replace it with whatever you want, I doubt usage of this function is very high ๐Ÿ™‚
20:53:22 <frosch123> pretty sure zuu's admin/gs command lib is the only user
20:58:16 <peter1138> Who remembers the Renault 4...? So weird that the design lasted into the early 90s.
21:00:19 <andythenorth> was it like a Renault 2CV?
21:00:28 <peter1138> Basically, yeah.
21:00:28 <andythenorth> looks bouncy
21:00:34 <belajalilija> andythenorth: what
21:01:05 <andythenorth> ok goes it go something?
21:01:15 <andythenorth> I've made my ships work with lots of hard-coded temp values
21:01:21 <andythenorth> so obviously now I should commit and run away
21:02:31 <andythenorth> if we merged JGR's ship stuff, I could have 2 competing slightly broken branches
21:02:33 <andythenorth> that's ideal ๐Ÿ™‚
21:30:01 <_glx_> frosch123: that's not json, it's just inlining params
21:33:38 *** jinks has quit IRC (Remote host closed the connection)
21:34:35 *** jinks has joined #openttd
21:53:55 <truebrain> _glx_: btw, that MSVC var also works for MSVC 2019, so /MT is there too set correctly
21:53:57 <truebrain> so that is nice ๐Ÿ™‚
21:54:43 <_glx_> it's basically a cmake var to setup properly the build
21:55:13 <_glx_> MSVC itself has /MT since ages ago
21:56:07 <truebrain> yes, we know. But it is nice that the CMake integration with 2019 also works correctly.
22:25:52 <andythenorth> naptime eh
22:30:55 <truebrain> Btw, I guess MT stands for MultiThread and MD for MultithreadDLL .. no clue what that has to do with static vs dynamic, but I think it is funny ๐Ÿ™‚
22:36:22 <_glx_> DLL as loading library dynamically
22:39:49 <_glx_> anyway after checking locally, the hack was indeed not working
22:40:14 <_glx_> I can clearly see -MDd when MTd is expectect
22:40:48 <_glx_> my guess is MSVC or cmake changed /M to -M at some point
22:41:04 <truebrain> It isn't in the flags yet when that code runs
22:41:20 <truebrain> So even with -M replacing it doesn't work (I tried :D)
22:41:37 <DorpsGek> [OpenTTD/OpenTTD] JGRennison opened pull request #11213: Fix: Inaccurate waiting cargo total in station window when using cargodist
22:41:38 <_glx_> so yeah removing the hack is the way to go too ๐Ÿ™‚
22:41:57 <truebrain> Cool!
22:42:53 <truebrain> Less cmake code is better ๐Ÿ˜„
22:43:35 <DorpsGek> [OpenTTD/OpenTTD] glx22 approved pull request #11208: Fix: [MSVC] generate static libraries / executables correctly with vcpkg -static target
22:43:38 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain merged pull request #11208: Fix: [MSVC] generate static libraries / executables correctly with vcpkg -static target
22:45:05 <_glx_> it used to be in the flags at this point, but I guess the change in 3.15 removed it
22:46:27 <truebrain> Shit getting fixed yo!
22:46:30 <truebrain> ๐Ÿ˜„
22:53:01 <DorpsGek> [OpenTTD/OpenTTD] glx22 approved pull request #11210: Remove: last remnants of SunOS
22:53:04 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain merged pull request #11210: Remove: last remnants of SunOS
23:07:35 <_glx_> of course my VS install miss stuff to build breakpad
23:08:04 <_glx_> (because I didn't install every available package)
23:32:24 <DorpsGek> [OpenTTD/OpenTTD] JGRennison opened pull request #11214: Fix: Road stops should not draw a ground sprite of 0
23:43:33 <DorpsGek> [OpenTTD/OpenTTD] JGRennison opened issue #11215: [Crash]: When clicking a parameter line in the NewGRF parameter window in manual parameters mode