[00:11:27] <Dominus> wjp, I have an old prefix that might be broken because of other things I did but it seems to me that our configure.ac is no longer compatible with older automake or autoconf
[00:20:16] <wjp> how old?
[00:20:57] <Dominus> automake 1.11.1 and autoconf 2.67
[00:21:45] <Dominus> problem is I had copied stuff over from another prefix and all the autotools and libtool had the wrong path in there and I'm not sure I have fixed everything :)
[00:21:57] <Dominus> so it could just be a broken prefix
[00:22:49] <wjp> hm, those versions should be fine
[00:26:55] <Dominus> ok, then let's chalk it up to broken prefix
[00:36:50] <Dominus> yeah, need to rebuilt that prefix from ground up :(
[00:54:51] <Dominus> and wjp if you are still awake, should we change the "CLEANFILES = *~" line in usecode/compiler/makefile.am to "CLEANFILES = *~ uclex.cc ucparse.cc ucparse.hh ucparse.h"?
[00:55:12] <Dominus> the MAINTAINERCLEANFILES = uclex.cc ucparse.cc seems to have no effect here on normal clean or distclean
[00:56:27] <Dominus> anyway, good night. talk to you tomorrow about those things. it's really late :)
[01:50:02] <-- ShamblerDK_ has left IRC (Remote host closed the connection)
[02:28:36] --> Rottingbeef has joined #exult
[02:30:48] <-- Marzo has left IRC (Ping timeout: 246 seconds)
[03:06:31] <-- ParuNexus has left IRC (Ping timeout: 252 seconds)
[03:13:58] --> ParuNexus has joined #exult
[03:59:09] --> Matt_O1 has joined #exult
[04:01:06] <-- Matt_O has left IRC (Ping timeout: 246 seconds)
[04:14:18] <-- Rottingbeef has left IRC (Ping timeout: 245 seconds)
[06:14:29] <-- ParuNexus has left IRC (Ping timeout: 248 seconds)
[09:12:01] <sh4rm4> hmm i'm playing SI with FMOpl and some tunes sound completely wrong - like noise
[09:14:04] <sh4rm4> i copied jmsfx.flx jmsisfx.flx sqsfxbg.flx sqsfxsi.flx into /share/exult from my old install
[09:15:35] <sh4rm4> the other .flx files were generated during make install
[09:16:15] <sh4rm4> -rw-r--r-- 1 root root 143339 Nov 22 22:13 exult_si.flx
[09:16:20] <sh4rm4> -rw-r--r-- 1 root root 25324 Nov 22 22:13 midisfx.flx
[09:16:25] <sh4rm4> stuff like that
[09:17:48] <sh4rm4> right now i'm standing in front of the crematory in monitor
[09:31:01] <sh4rm4> renfry stands around in the middle of the room, with his hand standing out like in the middle of walking o_0
[09:31:12] <sh4rm4> is there a way to test all midi tunes ?
[10:19:17] <Dominus> sh4rm4: you have to differ between tunes and sfx (toggle in the audiosettings to find out which are wrong)
[10:20:04] <Dominus> and there is a shortcut to an audio tester, try h and ctrl-h
[10:20:46] <Dominus> noise sounds like the old bug in OSS vs Alsa
[10:21:12] <Dominus> i think i3.... had some experience like this
[10:21:25] <Dominus> a couple of months ago
[12:12:26] --> Marzo has joined #exult
[13:26:41] <sh4rm4> hmm what's needed to make serpent isle work in dosbox ? it doesnt like the "expanded memory manager"
[13:30:47] <sh4rm4> ah, seems disabling "ems" in dosbox.conf does the job.
[16:33:42] <sh4rm4> hmm in SI, as soon as you enter monitor, cantra will follow you like a moth is attracted by the light
[16:33:55] <sh4rm4> however in exult, i didnt even meet her
[16:51:37] <sh4rm4> she walks around in the town hall park
[16:53:11] <sh4rm4> in SI, she walks around between the southwest town gate and the crematory
[17:09:53] <sh4rm4> --enable-mt32emu is missing the information whether it's enabled by default or not
[17:25:32] <sh4rm4> hmm after make is finished, when i do make install, exult starts compiling stuff again
[17:25:35] <sh4rm4> shapes/ etc
[17:26:15] <sh4rm4> that's a bit nasty because i need to run it as root
[17:33:33] <sh4rm4> according to debug info, cantra runs usecode like "art thou a hero" despite she's far away from the avatar
[17:35:38] <sh4rm4> Audio subsystem request: Music track # 67 in <STATIC>/mt32mus.dat
[17:35:51] <sh4rm4> ^ that's what makes the strange noise
[17:39:09] <sh4rm4> the data file is from "the ultimate collection", i guess
[18:22:51] <Dominus> so what are you using for music playback? fmopl, mt32emu, midi?
[18:24:00] <Dominus> as for make install compiling stuff again, it might be good to know why it does that. doesn't sound like good behavior
[20:28:29] <sh4rm4> fmopl
[20:28:55] <sh4rm4> ./configure --enable-debug --enable-compiler --enable-mods --disable-all-hq-scalers --disable-nxbr --disable-silent-rules --prefix=
[20:29:09] <sh4rm4> make -j9
[20:29:20] <sh4rm4> su -c "make install"
[20:32:01] <sh4rm4> the latter goes into shapes/ gamemgr/ usecode/ and links stuff, and compiles stuff in audio/ and gumps/
[20:53:10] <Marzo> sh4rm4: the problem you describe involves two things: (a) mutual dependencies between libraries; and (b) that automake is crap trying to handle these
[20:55:06] <Marzo> Basically, it goes like this: it enters dir "A", sees that its dependencies (dir "B") have changed, and compiles it; then it enters dir "B" and sees that "A" was changed (it was recompiled), so it needs to recompile dir "B"; then repeat
[20:55:16] <Marzo> It is not actually this bad, but it happens
[20:55:37] <sh4rm4> hmm but why do the dependencies change ?
[20:55:57] <Marzo> Usually, touching a header file is enough
[20:56:23] <sh4rm4> i didnt do anything else between make -j9 and make install
[20:56:27] <Marzo> If you run make -j9 twice before going for the "make install" it usually will fix everything
[20:56:51] <Marzo> Was the make -j9 done after a make clean?
[20:57:00] <sh4rm4> no
[20:57:06] <Marzo> There you go
[20:57:16] <sh4rm4> basically configure && make -j9
[20:57:19] <Marzo> As I said, automake is crap trying to handle these cases
[20:57:29] <Marzo> Clean tree?
[20:57:41] <sh4rm4> no
[20:58:01] <Marzo> This case usually only happens when recompiling
[20:58:43] <sh4rm4> right, i compiled before in the tree, then added --enable-debug to the configure run and recompiled
[21:33:32] <Dominus> muhaha! so you should have done what you told me last night. recheckout svn and do it again
[21:33:53] <Dominus> which wouldn't have helped me but you ;)
[21:34:16] <Dominus> karma! ;)
[22:06:03] --> ShamblerDK has joined #exult
[22:54:05] <Dominus> wjp, Paulo (i30817) didn't succeed on the forum with sh4rm4's ucparse.h/.hh patch (but without $(SHELL))
[22:54:08] <Dominus> updating ucparse.output
[22:54:08] <Dominus> updating ucparse.hh
[22:54:08] <Dominus> g++ -DHAVE_CONFIG_H -I. -I../.. -I./../../headers -I./.. -I./../../files -I./../.. -O2 -Wno-long-long -O2 -c -o ucparse.o ucparse.cc
[22:54:08] <Dominus> make: *** No rule to make target `ucparse.h', needed by `uclex.o'. Stop.
[23:02:51] <wjp> that sounds like either the patch was misapplied or automake and config.status didn't get re-run
[23:04:57] <Dominus> I'll try to get him to test it again
[23:06:31] <Dominus> wjp, also about cleaning up, I read up about maintainer-clean and bison generated stuff is supposed to be in there but shouldn't it be rather distclean since these files are not that hard to generate on the go
[23:22:06] <wjp> no, you're right, it should be maintainer-clean
[23:22:24] <wjp> since these files go into a tarball they shouldn't be deleted by distclean
[23:23:10] <Dominus> ah, right, didn't think about tarball
[23:23:50] <Dominus> so, should we add ucparse.h/.hh there? (when we do the cp ucparse.h patch)