IRC logs for #openttd on OFTC at 2023-08-18
⏴ go to previous day
02:19:06 *** Wormnest has quit IRC (Quit: Leaving)
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: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: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: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:23 <truebrain> problem .. problem solved!
08:05:01 *** NGC3982 has quit IRC (Ping timeout: 480 seconds)
08:25:03 <peter1138> You realise you are now our MacOS expert (again?)?
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: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:47:16 <peter1138> An M2 MacMini might be nice... use it as a remote for VS Code 😉
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: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: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:27 <peter1138> What could go wrong...
09:09:45 <truebrain> "An Iowa", somewhere around there 😛
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: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: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: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: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: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:51 <truebrain> paint me yellow and call me a banana
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:54 <truebrain> sounds like a solid PR to create; go for it!
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: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> 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: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: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: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:12 <alfagamma_0007> That's Bengali
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: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:29 <truebrain> okay .. yes, it is MacOS 🙂
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: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:19 <truebrain> but the symbol really doesn't exist for me
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: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:19:34 <_glx_> And as always the debugging has to be done by someone without a real mac
10:20:26 <truebrain> andythenorth: / Bouke : mind checking out #11207, if that doesn't change anything for you two?
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: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:37:19 <truebrain> ah, the Cocoa driver has hardcoded it needs 10.7
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: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: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: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:15 <truebrain> hence my sentences 🙂
11:50:09 <truebrain> but vcpkg is being lazy
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: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: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: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: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> `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> if I move the sprite, then layer 0 is clearly working
14:24:21 <_jgr_> Hmm, that looks like it would work
14:26:15 <_jgr_> Mind sending a copy of the GRF?
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> 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: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: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: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: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: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: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: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: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: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: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: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:38:27 <DorpsGek> - Update: Translations from eints (by translators)
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: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: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: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: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:25 <truebrain> can't imagine when, honestly 🙂
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: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: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:51:21 <truebrain> now to fix a bananas-server issue in production .. turns out, someone is trying their own code against the server 😄
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: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: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: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: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:28:16 <frosch123> ah, crap, it's not json
20:29:30 *** felix has quit IRC (Ping timeout: 480 seconds)
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: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: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: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: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: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:53:55 <truebrain> _glx_: btw, that MSVC var also works for MSVC 2019, so /MT is there too set correctly
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: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:38 <_glx_> so yeah removing the hack is the way to go too 🙂
22:42:53 <truebrain> Less cmake code is better 😄
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!
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)
continue to next day ⏵
