[01:34:08] --> DominusExult has joined #exult
[01:34:08] <-- DominusExult has left IRC (Changing host)
[01:34:08] --> DominusExult has joined #exult
[01:34:08] --- ChanServ gives channel operator status to DominusExult
[01:35:35] <-- BrainChild has left IRC (Remote host closed the connection)
[01:35:56] <-- Dominus has left IRC (Ping timeout: 260 seconds)
[01:35:57] --- DominusExult is now known as Dominus
[01:36:34] --> BrainChild has joined #exult
[01:41:35] <-- BrainChild has left IRC (Ping timeout: 240 seconds)
[02:13:32] --> BrainChild has joined #exult
[02:24:36] <-- BrainChild has left IRC (Ping timeout: 246 seconds)
[04:19:07] <-- Rottingbeef-2 has left IRC ()
[04:22:15] --> BrainChild has joined #exult
[04:39:48] <-- BrainChild has left IRC (Ping timeout: 260 seconds)
[06:37:03] --> BrainChild has joined #exult
[06:53:41] <-- BrainChild has left IRC (Ping timeout: 260 seconds)
[07:12:45] <azeem_> I noticed that exult disregards CXXFLAGS set by the user: http://paste.debian.net/1143054/ , I guess due to the loop after "# Lets clean up CFLAGS of -O[0-3gs]? and -g[0-3]?" in configura.ac and --with-optimization
[07:13:02] <azeem_> that's a bit (expert-)user unfriendly
[07:14:42] <azeem_> e.g. Debian/Ubuntu would like to build with "-g -O2", but --with-optimization=debug is "-g -O1" and =normal is just "-O2", so the detached debugging symbols that are automatically generated for the dbgsym package are useless:
[07:14:46] <azeem_> Reading symbols from /usr/games/exult...Reading symbols from /usr/lib/debug/.build-id/3e/2527238e85163e30cb0cf4b1cd25f8eb0519a8.debug...(no debugging symbols found)...done.
[07:15:31] <azeem_> (--with-optimization=debug is actually "-g -Og"
[07:15:33] <azeem_> )
[07:17:27] <azeem_> ok, I can hack it in by passing DEBUG_FLAGS='-g' to configure, but I think it would be nice to just accept what the user passes via the standard env vars
[07:31:04] --> Marzo has joined #exult
[07:31:35] <-- Lightkey has left IRC (Ping timeout: 240 seconds)
[07:32:07] <azeem_> I've filed https://github.com/exult/exult/issues/38 for that
[07:34:00] --- azeem_ is now known as azeem
[07:45:33] --> Lightkey has joined #exult
[07:47:30] <azeem> if I start the game, choose serpent isle, and the "Return to Main Menu", I hit a segfault: http://paste.debian.net/1143057/
[08:42:39] --> BrainChild has joined #exult
[08:58:43] <-- BrainChild has left IRC (Ping timeout: 246 seconds)
[09:18:42] <Dominus> of course, works for me :)
[09:49:52] <azeem> the other thing I notice is that the pallette changes for lightning(?) in Monitor are extremely slow - the changes take around 10 seconds each
[10:09:53] <Dominus> with git or the 1.6 version?
[10:10:41] <Dominus> (I haven't really played with the git version after the lighting update - because I need to catch that strange usecode bug)
[10:13:38] <azeem> 1.6
[10:14:10] <Dominus> Marzo did some other light math in the git version
[10:19:15] <azeem> when did v1.6.x got branched off btw? There's commits as far back as Nov 2018 not on the 1.6 branch
[10:20:12] <Dominus> a while ago. Actually it were the branches shared and unique pointers that branched off master and eventually got to be devel-merged
[10:20:24] <azeem> right ok
[10:20:45] <Dominus> close to the release we made devel-merge masgter and previous master became the 1.6 branch
[10:21:20] <azeem> so what's the strategy for the 1.6 branch going forward? Will game bugs be fixed on it or just master?
[10:22:30] <Dominus> unless we can find some big bug (like the usecode changing npc id that I'm trying to reproduce), things will remain in master only
[10:22:51] <Dominus> Well, that's my plan. Marzo, what do you think? :)
[10:23:15] <azeem> so only fix big bugs in 1.6.x?
[10:23:31] <Dominus> azeem: we haven't really talked about it, obviously :) but yes
[10:23:51] <Dominus> and only big bugs that show up soon
[10:24:17] <azeem> to be clear, I'm not complaining, devel resources are stretched very thin, but OTOH, having a clear stable branch which gets increasinlgy stable with bug fixes would be nice; the risk of regressions seem to be quite high with exult
[10:24:28] <azeem> IOW, does it even make sense to report bugs in 1.6?
[10:25:30] <Dominus> it makes sense so we can see if that bug is still in the snapshsots at least
[10:25:57] <Dominus> and the devel resources is the point, I guess
[10:26:56] <Dominus> 1.6 was mostly due to be able to make a nice cut with old OS and be able to move on with the more advanced branch, now master
[10:28:04] <Dominus> Also because the strange crashes due to pointers *should* be even less in current master (or hopefully gone). This is nnot going to make it into 1.6
[10:28:15] <azeem> *nod*
[10:28:21] <azeem> when is 1.8 coming out? :)
[10:28:27] <Dominus> :)
[10:28:37] <Dominus> I should have a goal for that :)
[10:29:27] <Dominus> I need to get Kirben to make snapshots again and hope people will be willing to test those
[10:29:45] <Dominus> and then actually play the games through myself and see how that goes
[10:30:10] <Dominus> Maybe if Marzo has worked through most of his Trello board :)
[10:30:25] <Dominus> but we need to clone him first a couple of times
[10:34:00] <Marzo> @azeem: Regarding the user supplied CXXFLAGS; what do you say about -g/-O flags being stripped only if --with-debug/--with-optimization is specified?
[10:35:40] <Marzo> A special default value could be given for these options, as you suggest, to prevent this stripping if they are not supplied
[10:35:40] <azeem> sounds good; I wasn't even aware of --with-debug, it's a bit strange then that --with-optimization also sets -g if debug is set, no?
[10:37:49] <Marzo> I guess I was thinking that it made no sense to have debug optimizations (-Og) without debug symbols (-g) when I wrote that
[10:38:00] <azeem> ack
[10:38:07] <Marzo> But yeah, since there are separate flags for this, I guess they should be orthogonal
[10:38:47] <Marzo> Hm
[10:38:58] <azeem> I wonder how much changes if you increase -O
[10:39:05] <Marzo> But it does not actually set -g with --optimization=debug
[10:39:12] <azeem> i.e. maybe it would suffice to have --enable-debug and just use -O2 unless already set
[10:39:16] <Marzo> So they are already orthogonal
[10:39:21] <azeem> Marzo: ah ok sorry
[10:39:44] <azeem> I misread that
[10:40:07] <Marzo> I think I made them orthogonal to be able to catch "optimization dependent bugs" aka undefined behavior
[10:40:27] <Marzo> So you could have a -O2 build with debug symbols
[10:40:43] <Marzo> I guess the sanitizers would be a better option nowadays
[10:52:50] --> BrainChild has joined #exult
[11:10:16] <-- BrainChild has left IRC (Ping timeout: 244 seconds)
[11:15:08] <Marzo> @azeem: issue #36 fixed
[11:29:46] <Marzo> @azeem: I also cannot reproduce that segfault; can you try to reproduce it with a build with debug symbols and, if the compiler you are using supports it, with "-fsanitize=address"?
[11:30:44] <Marzo> (-fsanitize=address can be added to CXXFLAGS or it can be enabled in ./configure with --with-sanitizers=address)
[11:50:41] <azeem> that backtrace is with debug symbols
[11:51:08] <azeem> but unfortunately, I can't reproduce it anymore either
[11:51:21] <azeem> so maybe settings-specific
[11:52:44] <azeem> yeah, if I throw away exult.cfg and start over, it segfaults again
[11:59:04] <azeem> first I thought it might have something to do with music playing or not, but it's not very consistent
[11:59:48] <azeem> if I switch between the exult and the si menu often enough, I get a different crash: "free(): invalid next size (fast), Thread 5 "SDLAudioP1" received signal SIGABRT, Aborted."
[12:03:40] <azeem> http://paste.debian.net/1143080/
[12:12:59] <azeem> another: http://paste.debian.net/1143081/
[12:19:26] <azeem> and another: http://paste.debian.net/1143083/
[12:19:44] <azeem> they only hapoen when I enable Music it seems, if I disable it, I couldn't hit theme
[12:24:02] <azeem> filed it as https://github.com/exult/exult/issues/39
[12:38:54] <azeem> Marzo: does -fsanitze=address take a steep performance penalty?
[12:59:06] --> BrainChild has joined #exult
[13:03:59] <Dominus> hmm, still can't reproduce it. is midi also the default driver on your system or is it fmopl? Maybe some problem with Exult and your midi system?
[13:05:52] <azeem> how can I see the default driver?
[13:06:01] <Dominus> in .exult.cfg
[13:06:03] <azeem> it says
[13:06:04] <azeem> Midi Output: Enabled
[13:06:58] <Dominus> in .exult.cfg the <driver> or in Exult itself in the audio settings
[13:07:55] <azeem> Marzo: I'm getting an immediate asan error when I switch from main menu to si menu if music is enabled: http://paste.debian.net/1143096/
[13:08:37] <azeem> Dominus: midi driver is set to default
[13:09:31] <Dominus> from that link it seems as if fmopl is default for you.
[13:09:34] <azeem> yeah
[13:10:11] <azeem> Trying config specified Midi driver: `Timidity'
[13:10:11] <azeem> timidity.cfg: No such file or directory
[13:10:38] <Dominus> ah, ok, so timidity is default but fmopl is our trusted fallback
[13:10:58] <Dominus> still can't reproduce with fmopl driver... *sighs*
[13:14:06] <azeem> well, I can work-around it by disabling music; the music is a bit annoying anyway TBH
[13:14:59] <Dominus> I only find the Exult intro very annoying by now. But then I must have started Exult countless of times in the last twenty years :)
[13:15:10] <azeem> heh
[13:15:24] <-- BrainChild has left IRC (Ping timeout: 260 seconds)
[13:38:24] <Marzo> @Dominus: Unless I am actively going for the menu, I almost always start Exult through "./exult --(bg|fov|si|ss|sib) --nomenu" or something
[13:38:40] <Dominus> :)
[13:38:40] <Marzo> And unless I want the intro, I set it to skip on exult.cfg
[13:39:23] <Dominus> yes, I do that, too, still often enough have heard the intro now :)
[13:40:01] <Dominus> also have turned sound off on my computer most of the times because I can hear my wife rolling with her eyes when the intro music comes on :)
[14:04:50] <Marzo> @azeem: Out of random curiosity, what architecture and OS are you using? I am assuming x86/ia64 and some variant of Debian?
[14:05:58] <Lightkey> You must have good ears..
[14:07:00] <azeem> Marzo: yeah, amd64 on Debian stable
[14:07:19] <Marzo> That shoots down one theory
[14:07:29] <azeem> which was?
[14:08:36] <Marzo> Some implementation defined behavior if you were using a different architecture
[14:09:53] <Lightkey> Marzo: Fiy, ia64 is Intel's sunken Itanic.
[14:10:23] <Marzo> Yeah, I keep misremembering amd64 for ia64 for some reason
[14:11:23] <Lightkey> Intel has been very inconsistent with their nomenclatures TBH. x86 was not their name in the first place, they had three/four names for x86-64 by now.
[14:13:16] <Marzo> But one thing is certain: I think all those different segfaults may be because something is corrupting the heap
[14:15:39] <Marzo> Hm, and I think I may know what
[14:20:44] <Marzo> FMOplMidiDriver::loadTimbreLibrary (this=0x117b0070, ds=0x0, type=MidiDriver::TIMBRE_LIBRARY_FMOPL_SETGM)
[14:20:52] <Marzo> See anything wrong with that?
[14:22:09] <azeem> ds doesn't look healthy
[14:22:33] <Marzo> Bingo
[14:23:24] <Marzo> I will look a bit more, just in case
[14:23:32] <Marzo> But I think I am on the right track
[14:30:28] <Marzo> Hm, that one is actually harmless
[14:40:00] <Marzo> Lets see: asan is flagging this line:
[14:40:01] <Marzo> ins[INDEX_AVEKM_M] = xmidi_ins.mod_avekm;
[14:40:10] <Marzo> This line is set to unsigned char* ins = xmidibanks[bank]->insbank[patch];
[14:40:34] <Marzo> xmidibanks is created a few lines above if it does not exist
[14:41:40] <Marzo> So there are only 3 options: either bank is out of range, or patch is out of range, or both
[14:42:20] <Marzo> If any of those are out of range, then invalid/incorrect data is being read
[14:43:42] <Marzo> But if bank were out of range, asan would have flagged the out-of-bounds write on the line "xmidibanks[bank] = new xmidibank;"
[14:43:50] <Marzo> So patch must be somehow out of range
[14:44:26] <Marzo> Hm, no, it is not true that bank is not out of bounds here
[14:48:10] <Marzo> I guess I will have to try setting up and running Exult in a VM so I can try to reproduce the error and use asan myself
[15:00:03] <Dominus> Marzo, with fmopl, I get a lot of Invalid Patch 63:30 len was 242 f2 (and similar) when I get to the SI menu
[15:00:19] <Dominus> but only with the 1.6 branch
[15:01:19] <Dominus> actually, no, these are produced by the intro
[15:03:38] <Dominus> hmm, I probably only see that in the 1.6 branch because that binary has been compiled with debug
[15:06:11] <Marzo> It appears in master as well
[15:06:21] <Dominus> yes, --with-debug=full they also appear there...
[15:06:29] <Marzo> But all of these have bank and patch in range (0-127)
[15:06:58] <Dominus> yes
[15:08:11] <Marzo> The issue with these is actually the length of the timbre in question
[15:08:26] <Marzo> Which leads me to think that there is something wrong with that code
[15:08:44] <Marzo> But wrong in a different sense
[15:10:52] --> Rottingbeef-2 has joined #exult
[15:11:16] <Marzo> @azeem: out o curiosity, what happens if you put "assert(bank < 128); assert(patch < 128);" on audio/midi_drivers/FMOplMidiDriver.cpp line 840, rebuild Exult and try to reproduce the issue?
[15:11:33] <Marzo> You may need to add #include <cassert> at the top
[15:11:39] <azeem> lemme try
[15:13:21] --> BrainChild has joined #exult
[15:29:52] <-- BrainChild has left IRC (Ping timeout: 260 seconds)
[16:01:56] --> BrainChild has joined #exult
[16:07:37] <azeem> Marzo: exult: FMOplMidiDriver.cpp:840: void FMOplMidiDriver::loadXMIDITimbres(IDataSource*): Assertion `patch < 128' failed.
[16:10:10] <Marzo> There is our heap corruption then
[16:11:28] <Marzo> Can you check md5 of static/xmidi.ad file?
[16:12:27] <azeem> a165573ca0bf87fa339160da2122fdc3
[16:12:32] <Marzo> In my copies of SI and SS, it is 1a3fdae4c160109441c4d523b925a6f1
[16:13:18] <azeem> fb655478bd188d424b31a640eac9a2e5 /home/mba/privat/serpent/static/xmidi.mt
[16:13:22] <azeem> does that one fit?
[16:13:43] <Marzo> That one is correct, yes
[16:14:05] <Marzo> Guess something corrupted your xmidi.at
[16:14:17] <azeem> I wonder how many else are broken then, I think I carried those files over from the floppies I bought back in the early 90s
[16:14:38] <Marzo> Anyway, I can add a check there to print an error message instead of corrupting the heap
[16:14:56] <Marzo> I can give a list of files and md5 sums so you can check
[16:15:03] <azeem> that'd be handy, thanks
[16:15:07] <Marzo> But in about half an hour, going to eat something
[16:15:09] <-- BrainChild has left IRC (Ping timeout: 246 seconds)
[16:16:34] <azeem> sure
[16:24:24] <Dominus> feature request command line "--validate gamename" which checks the checksums of the known games :)
[16:37:27] <Marzo> @azeem: here you go: https://pastebin.com/xPf5yZ8K
[16:40:41] <Marzo> I am thinking
[16:40:57] <Marzo> Adding a check to FMOplMidiDriver::loadXMIDITimbres would be insufficient
[16:41:11] <Marzo> It would be fixing a single issue
[16:41:40] <Marzo> And with file corruption in mind, there is a lot more places where these things could pop up
[16:42:38] <Marzo> And although the idea behind adding --validate is good, I think that perhaps it should be a separate binary bundled with Exult
[16:45:37] <azeem> other than xmidi.ad only static/usecode differs
[16:46:36] <Marzo> Usecode is the one most likely to have been patched manually to fix a few bugs
[16:46:39] <azeem> that file is from 2009, maybe I patched it at some point?
[16:46:44] <azeem> nod
[16:46:49] <Marzo> But it is important to know for sure
[16:47:09] <azeem> all the others are from 1993
[16:47:13] <Marzo> If you send me your usecode, I can compare with mine to see if this is what happened
[16:48:33] <Marzo> And by the way, this kind of patching is why maybe a validator will not be very useful
[16:48:37] <azeem> https://people.debian.org/~mbanck/usecode.bz2
[16:49:08] <Marzo> This is SI with Silver Seed?
[16:49:18] <azeem> apparently without
[16:51:03] <Dominus> A validator would still be nice. At least you can tell whether it was altered. for usecode one could add "not valid - did you patch it?" ;)
[16:51:29] <azeem> yeah
[16:53:40] <Dominus> I remember one other case that had an altered intro.dat quite some time ago
[16:53:58] <Marzo> This is a stock Silver Seed usecode file
[16:54:28] <azeem> huh
[16:54:39] <azeem> ok, then maybe I got that from somewhere
[16:55:06] <azeem> can you just drop that in? I compared a few of the other files and thought they were non-SS
[16:56:28] <Marzo> I *think* it can be dropped in
[16:56:53] <Marzo> All hard-coded function calls in the originals are the same between SI and SS
[16:57:44] <Marzo> And I think that the things that would cause problems (such as the keyring) would not make a difference anyway
[16:58:37] <Marzo> But it is worth noting that most files are identical between original SI and SS
[16:59:20] <Marzo> Check shapes.vga, it is one that differs
[17:00:42] <Marzo> For reference: both SI and SS have 214 files in static; of those, 37 files are different between the games
[17:01:24] <azeem> I checked against your pastebin, and after seeing that e.g. ammo.dat was the serpentisle version, I compared the md5s against that, and only usecode differed
[17:01:36] <azeem> shapes.vga is a42f0eeba81121645c9637150175bbe4, i.e. serpentisle
[17:01:47] <azeem> I wonder whether I'll get weird bugs if I play now
[17:01:58] <Marzo> Hm. ammo.dat is one of those that differs between the two
[17:02:14] <azeem> right that's what I mean - that's how I figured out I must have serpentisle
[17:03:01] <Marzo> It should show up on the title screen anyway
[17:07:30] <Marzo> @azeem: https://i.imgur.com/IQxTEVl.png https://i.imgur.com/2AjyAQt.png
[17:08:05] <azeem> ah right
[17:08:58] <azeem> as I mentioned, I bought SI way back when (still have the floppies somewhere), but as the monk gave me that amulet that gets you to SS, I wasn't sure
[17:09:52] <azeem> anyway, if somebody could provide me with the correct xmidi.ad and usecode files for SI, I could do some more playtesting of the Debian 1.6 package
[17:10:00] <azeem> mbanck@debian.org
[17:30:50] <azeem> thx!
[17:41:50] <Marzo> Dominus: I have a few variants of U7 and SI in various languages, and I think at least one of them may not be one of the original translations. Do you know if there is a list of the original translations?
[17:45:34] <Marzo> The ones I have are: La Porte Noire, La Puerta Negra, Die Schwarze Pforte, Schmiede der Tugend, La Isla Serpiente
[18:13:03] --> BrainChild has joined #exult
[18:30:15] <-- BrainChild has left IRC (Ping timeout: 246 seconds)
[18:43:12] <-- Rottingbeef-2 has left IRC (Ping timeout: 246 seconds)
[18:53:40] --> Rottingbeef-2 has joined #exult
[18:54:43] <Dominus> Marzo: Schmiede der Tugend is the recent translation of FoV by "Sir John"
[18:55:16] <Dominus> I think I listed all official versions in the FAQ in which work
[18:56:54] <Marzo> I guess I have them all then
[18:57:33] <Marzo> I will be making the validator
[18:58:12] <Marzo> Depending on how fast it runs, maybe we can have it run the first time you play a game and save a flag
[18:58:39] <Marzo> At least the sha1sums binary runs very fast for me
[19:00:47] <Marzo> 1.5s for checking all files in all of these versions
[19:01:13] <Dominus> That's good.
[19:01:29] <Marzo> Might even be able to check every time you start each game :)
[19:02:17] <Dominus> He he that might be overkill ;)
[19:03:05] <Marzo> But just to be sure, can you check the files in your games against the md5sums I posted above?
[19:03:30] <Marzo> There *is* the possibility that mine might have been corrupted or patched, after all...
[19:03:33] <Dominus> But what about a failed scan? Just a message in stdout or a visible message?
[19:04:05] <Marzo> I was thinking maybe both
[19:04:57] <Marzo> Detailed description in stdout (sha1 of every file that failed), and a message saying that one or more files are corrupt
[19:04:58] <azeem> I would advise to at least check on first run, maybe everytime - seeing how people need 30 year old data files, a lot can apparently go wrong and a lot of unneeded debugging time can be sunk into it
[19:04:58] <Dominus> Will check later. I'm bound to have messed up files ;)
[19:05:38] <Dominus> Qed earlier today ;)
[19:06:56] --> BrainChild has joined #exult
[19:11:13] <Dominus> Marzo: a manual check would be great. And if it's decided to run everytime, it might be good to have a <validate> tag in <gamename>...
[19:12:13] <azeem> Marzo: how fast is md5sums btw? It should be good enough to catch bit flips
[19:12:46] <Marzo> I am going with sha1 solely because we already have an implementation of it on Exult
[19:12:58] <azeem> ah fair enough
[19:13:06] <Marzo> It is used by mt32emu to verify its ROMs
[19:13:36] <Marzo> We also have a crc32 implementation, which I am thinking of replacing by sha1 as well
[19:14:51] <Marzo> But for reference, sha1sum averages to 0.9s and md5sum averages to 0.8s
[19:17:41] <Marzo> Half that if I pipe the output to /dev/null
[19:20:24] <-- BrainChild has left IRC (Ping timeout: 260 seconds)
[19:29:37] --> BrainChild has joined #exult
[19:32:57] <azeem> is there a way to tell exult where to find the ogg files?
[19:35:29] <Marzo> Exult looks for music in data/music; data can e changed by config/disk/data_path setting in exult.cfg
[19:36:06] <Marzo> But there is no way to change music independently, it is always based on data
[19:36:30] <Marzo> Hm, wait
[19:36:33] <azeem> right, but from a packgaging stand-point, the exult data is installed by the .deb - and users usually can't write to /usr/share/exult
[19:36:37] <Marzo> There is, I was wrong
[19:36:50] <Marzo> http://exult.sourceforge.net/docs.php#digital_music_install
[19:37:04] <azeem> thanks
[19:38:30] <azeem> yeah works, cool
[19:38:43] <azeem> Dominus: that makes the music much less annoying
[19:38:56] <azeem> now I wonder whether Debian could distribute that
[19:45:55] <Dominus> if you come up with a solution, there is enough space to add a all-in-one audio package for debian on our download page :)
[19:50:10] <azeem> at least inside the zip files, there doesn't seem to be any licensing information
[19:51:14] <Marzo> It is a bit of a gray area
[19:51:34] <Marzo> They are recordings of the original games playing on an mt32
[19:52:20] <Marzo> And although we do require the original data files to play the games, the music can be downloaded and used independently of the games
[19:54:09] <azeem> right, but I wonder whether it can be legally distributed
[19:54:24] <Dominus> since it's recordings and the game only issues commands we are likely safe
[19:54:27] <azeem> the person who generated the audio files needs to put it under some license for that, CC or so
[19:54:33] <Dominus> otoh we cannot slap a license on these
[19:56:05] <Dominus> why doesn't shasum *.* give me all of the checksums of the static folder? I need to investigate...
[19:56:47] <Marzo> I got mine just by using sha1sum *
[19:56:56] <Dominus> yes, I just realized
[19:57:06] <Marzo> And the ones I gave earlier are actually md5, not sha1
[19:57:12] <Dominus> *.* only gives the checksum of files that have a file suffix
[19:57:20] <Marzo> Yep
[20:05:22] <azeem> I think for that audio pack on Unix it would be nice if exult alternatively looked in ~/.exult/data for files as well, so users could just install it in their home directory without needing admin rights
[20:11:13] <-- Marzo has left IRC (Ping timeout: 244 seconds)
[20:12:25] <azeem> hrm, maybe easiest (for the user) would be an in-app installer that downloads the combined audio pack
[20:18:34] <Dominus> Marzo, the english games md5's are the same
[20:18:45] <azeem> (he timed out)
[20:26:03] <-- BrainChild has left IRC ()
[21:01:19] <Dominus> phew... bisecting wine is annyoing... my main machine is on macOS 10.15 and it no longer can rrun Wine (only Crossover through their magic becauseo fth e64bit only thing). And my buildbot is sloooooow....