#exult@irc.freenode.net logs for 23 Oct 2013 (GMT)

Archive Today Yesterday Tomorrow
Exult homepage

[06:38:49] <-- Dominus has left IRC (Ping timeout: 240 seconds)
[08:20:00] --> Dominus has joined #exult
[08:20:00] --- ChanServ gives channel operator status to Dominus
[08:56:15] <Dominus> grrr, why are people finding all these regressions...
[08:56:16] <Dominus> :)
[08:56:35] <Dominus> and another one that is going to take some tracking
[08:57:38] <Dominus> in the cube generator you shouldn't be able to use magic, but since at least July 2010 you are able to. Exult 1.2 still worked correct...
[08:57:48] <Dominus> now go find that regression...
[09:06:24] <Dominus> it's not triggered by an egg, so it's more likely that the grey-black tiles or the space tile hinder magic...
[10:22:22] <Dominus> Marzo: I can't find anything suspicious, do you have any idea what made magic fizzle in the cube generator and what change could have broken that?
[12:09:23] --> TheCycoONE has joined #exult
[12:25:20] <Dominus> hmm, in BGKeyring you use INSIDE_GENERATOR as a gflag. is that somehow broken in non-mod?
[12:55:50] <Dominus> too bad compile on OS X is broken for old versions. I really can't do a regression test...
[13:00:11] <sh4rm4> using wine maybe ?
[13:00:38] <sh4rm4> (no idea if that's available for mac tho)
[13:00:43] <Dominus> sh4rm4: problem is that I'd need to build up a toolchain for compiling the Windows version
[13:00:51] <sh4rm4> oh
[13:00:53] <Dominus> wine does exist for OS X
[13:01:29] <sh4rm4> well then the easiest would be to do the regression tests from within a linux vm
[13:02:06] <sh4rm4> i guess the linux build works flawlessly with the provided toolchain
[13:02:39] <Dominus> hmm, yeah...
[13:02:48] <Dominus> thinking about that as well
[13:03:24] <Dominus> is there a git repository of exult somewhere? :)
[13:05:48] <Dominus> ah https://github.com/rofl0r/exult
[13:07:05] <sh4rm4> let me update that quickly...
[13:08:16] <Dominus> ah that's yours. I dimly remembered that
[13:08:26] <wjp> maybe we should do a poll of "active" devs to see who would want to switch to git
[13:08:43] <Dominus> update doesn't matter, the bug occured somewhere between 2004 and 2010 :)
[13:08:53] <Dominus> wjp: maybe
[13:09:22] <Dominus> wjp: back then http://exult.sourceforge.net/forum/read.php?f=1&i=366920&t=366920 jeff and Colourless didn't like git that much
[13:09:32] <Dominus> where has colourless gone to?
[13:09:37] <Dominus> ?seen colourless
[13:09:37] <exultbot> colourless left IRC around Fri Sep 27 14:06:43 2013 (GMT) (Ping timeout: 264 seconds)
[13:09:50] <Dominus> ?seen colour1ess
[13:09:50] <exultbot> I haven't seen colour1ess lately
[13:10:25] <Dominus> ?seen Colourle1s
[13:10:25] <exultbot> colourle1s left IRC around Sun Oct 6 01:51:23 2013 (GMT) (Ping timeout: 245 seconds)
[13:13:20] <sh4rm4> ok git is updated
[13:49:38] <Dominus> any pointers how to navifate revisions? git revision numbers are a bit long winded...
[13:49:55] <Dominus> especially since I need to go way back in time ...
[13:54:45] <wjp> since it's all linear here, you can do master~1000 for '1000 revisions before master'
[14:25:39] <Dominus> thanks wjp, that should work :)
[14:29:26] <sh4rm4> btw, there's git bisect
[14:29:35] <sh4rm4> and gitk is nice to "browse"
[14:30:11] <Dominus> sh4rm4: git bisect is waht I'm aiming at to use :)
[14:30:21] <sh4rm4> ah :)
[14:30:24] <Dominus> the one feature that I really like about git
[14:30:44] <Dominus> all other things are over my normal usage so I have no real opinion
[14:31:02] <Dominus> 2399 revisions since Exult 1.2
[14:40:19] <Dominus> yeah this is so much fun
[14:41:06] <Dominus> because the autotools are no longer supporting the old style it is getting frustrating to bisect this before it even started...
[14:44:05] <Dominus> he he back then we even had configure.in
[14:46:22] <Dominus> aaaarrrgghhhh
[14:46:38] <wjp> deep breaths :-)
[14:46:51] <Dominus> why is 9 years old code not compilable instantly?
[14:47:29] <wjp> maybe first try to bisect the oldest version that still compiles easily and hope it was still working in that?
[14:47:49] <Dominus> I have no clue which that is :)
[14:47:57] <wjp> use bisect :-)
[14:48:29] <Dominus> it's the little things like libpng which is no longer compatible with our code and that changed much too recently
[14:50:42] <wjp> I should be back home again around 9 pm; I'll be able to help a bit then if necessary
[14:52:42] <Dominus> that would be nice
[15:00:40] <Dominus> pffff vector gamewin.h...
[15:00:52] <Dominus> ok, I give in, higher revision please :)
[15:08:40] <Dominus> Me sighs
[15:09:52] <Dominus> so I checked out master~2399 but that proved to troublesome. getting a higher checkout seems impossible since I get trapped in untracked and local changes to files....
[15:10:12] * Dominus needs to learn more git
[15:15:51] <TheCycoONE> trapped in local changes? Are you checking out the remote master?
[15:31:33] <Dominus> I don't know :)
[15:33:07] <wjp> just do a 'git reset --hard' to get rid of anything local
[15:33:28] <wjp> git bisect doesn't like it if you make changes between bisect steps without resetting them
[15:34:39] <Dominus> ah, good to know
[15:36:09] <Dominus> this is proving hard, master~1600 I almost got to link (after undefining fmopl and in the midi drivers undefining macosx :))
[15:38:27] <Dominus> Undefined symbols:
[15:38:29] <Dominus> "___strlcpy_chk", referenced from:
[15:38:29] <Dominus> -[SDLMain application:openFile:] in libSDLmain.a(SDLMain.o)
[16:01:26] <Dominus> hmm, I give up. I can't figure these things out...
[16:43:36] <sh4rm4> where is libSDLmain.a coming from ?
[16:43:56] <sh4rm4> ___strlcpy_chk is some glibc internal symbol
[16:44:07] <sh4rm4> should be provided by glibc's libc.so
[16:44:28] <sh4rm4> however it may need -fstack-protector related CFLAGS
[17:21:27] <Dominus> thanks, I'll not try on OS X any further. I hope a linux will prove more stable to bisect :)
[17:28:01] <Dominus> got a Fedora 14 VM that hasn't been in use since december 2010 :)
[17:40:46] <sh4rm4> that's probably better for bisecting anyway
[17:40:57] <sh4rm4> no new autoconf and other stuff getting in the way
[18:39:34] <wjp> Dominus: I'm home now if there's anything I can do
[18:50:45] --> ShamblerDK has joined #exult
[18:53:49] <Dominus> wjp: the issue is that in the cube generator (or any other generator afaik) you shouldn't be able to cast magic
[18:54:23] <Dominus> in exult 1.2 that was correct and in april 2010 it isn't
[18:54:37] <Dominus> so sometime in between it broke
[18:54:54] <Dominus> exult 1.2 is master~2399
[18:56:01] <Dominus> in my fedora vm I tried master~1600 but had problems with flex.h and memcpy and then had to leave the machine ;)
[18:59:50] <wjp> savegame?
[19:04:23] <Dominus> sorry distracted... ;)
[19:04:41] <Dominus> I attached a savegame to the bug tracker
[19:05:32] <Dominus> best look there where the generator is and then load another because it's right in the generator
[19:41:02] <wjp> nothing like fixing ancient compile errors
[19:41:56] <Dominus> he
[19:42:09] <Dominus> welcome to the club ;)
[19:43:44] <wjp> went back to march 2010 and it seems ok there
[19:47:22] <Dominus> magic fizzles in the generator?
[19:47:36] <wjp> yes
[19:48:14] <Dominus> hmm, my first snapshot is from around april 27th
[19:50:48] <Dominus> that makes it easier to pinpoint (another thirty minutes and I can take a look as well)
[19:55:07] <wjp> mid Dec 2010 is ok too
[19:58:57] <Dominus> ok that makes no sense
[19:59:47] <wjp> without knowing how magic should be disabled, this way of testing may be pointless
[20:00:27] * Dominus nods
[20:00:34] <Dominus> seems so
[20:01:51] <Dominus> how do you test? with the savegame from the tracker or differently
[20:02:40] <wjp> just teleport into the generator
[20:03:34] <Dominus> yeah so no eggs interfering
[20:05:20] <Dominus> but is it broken for you with current svn?
[20:06:06] <wjp> yes
[20:06:39] <wjp> that was of course the first thing I tried :-)
[20:11:12] <wjp> down to a range of 4...
[20:12:48] <wjp> ok, it's either one of your scaling commits or one that touches weather effects
[20:12:54] <wjp> any bets? ;-)
[20:14:30] <wjp> bisect points at r7095
[20:15:02] <wjp> which unfortunately is another one of those let's-change-5-unrelated-things-at-once commits
[20:24:51] <wjp> it's the initialization of Sparkle_effect::start to true in effects.cc
[20:26:28] <wjp> can't say I directly understand why
[20:30:04] <Dominus> curiosly I stumbled over this or similar and wondered if it is invisible weather that affects magic in there
[20:30:31] <Dominus> similar to ambrosia with its anti magic rain
[20:31:19] <Dominus> i'm glad it's not my scaler things ;)
[20:34:10] <wjp> it's likely a weather egg, yes
[20:35:42] <wjp> no idea how it affects magic though
[20:37:02] <Dominus> and I don't see any wheather egg there
[20:40:09] <wjp> the lightning bolt in the center
[20:40:58] <Dominus> yeah but that just seems to give you a jolt
[20:42:35] <wjp> it's the right one though
[20:42:41] <wjp> egg type 8, data1 == 3
[20:42:45] <wjp> (weather, sparkle)
[20:43:30] <Dominus> ah, the usecode egg gives you a jolt
[20:43:37] <Dominus> the weather egg it is thenn
[20:45:09] <wjp> that commit made the same change for snowstorms
[20:45:16] <wjp> I wonder if those are broken too
[20:48:18] <Dominus> I don't exactly know where those snowstorms are
[20:48:27] <Dominus> SI probably
[20:49:07] <Dominus> do you get what the start(true) does?
[20:52:37] <Dominus> hmm Ambrosia is also not working
[20:53:34] <wjp> well
[20:54:30] <Dominus> but curiosly it isn't working for me before that as well
[20:54:39] <Dominus> before rev 7095
[20:55:40] <Dominus> I wonder why it works for you before that
[20:55:58] <Dominus> wait, wrong snapshot. need to test again
[20:56:25] <wjp> start was undefined before, so somewhat random
[20:57:25] <Dominus> ok, the snapshot before that change is indeed working correctly
[20:57:58] <Dominus> so, the start true *should* make it no random but always start the eather effect
[20:58:15] <Dominus> but in fact it makes it never start
[21:01:41] <wjp> start(false) is the opposite non-random effect, by the way
[21:02:32] <Dominus> I was wondering, in the following void Sparkle_effect::handle_event
[21:03:29] <Dominus> doesn't "if (start) {start = false; ...." make this the opposite?
[21:03:59] <Dominus> are they related? because further up start is true?
[21:04:10] <wjp> the idea is probably that if start is true, it does that tqueue->add and sets start to false, so that the next time handle_event is called it'll go into the other branch
[21:07:00] <Dominus> but somehow this ends up nulling it completely at least for the sparkle effect
[21:07:22] <Dominus> and very likely snow storms
[21:07:54] <wjp> aha
[21:08:21] <wjp> ok, this was quite subtle
[21:08:38] * Dominus sits down and listens
[21:08:47] <wjp> it was _not_ the start
[21:08:50] <wjp> that just exposed another bug
[21:09:08] <Dominus> classic
[21:09:26] <wjp> the problem is the 1 earlier in that line
[21:09:52] <wjp> to see which "weather type" there is, we look through all current effects to find the weather effects and get the number
[21:10:07] <wjp> this Sparkle_effect has type set to 1
[21:10:22] <wjp> but the anti-magic weather is 3
[21:10:56] <wjp> if start is false this Sparkle_effect immediately gets aborted, but what's left is the graphical Rain_effect that it starts in Sparkle_effect::Sparkle_effect
[21:11:13] <wjp> and that one _is_ created with type 3
[21:11:43] <wjp> so because of the accidentally disappearing Sparkle_effect, it doesn't find the wrong weather type...
[21:12:16] <wjp> I can't commit here right now, but feel free to change Weather_effect(duration, delay, 1, egg) to Weather_effect(duration, delay, 3, egg) in Sparkle_effect::Sparkle_effect
[21:12:40] <Dominus> yes!
[21:13:20] <Dominus> (and change the description from (start a snowstorm :))
[21:15:29] <-- TheCycoONE has left IRC (Quit: And then there were n-1)
[21:24:18] <Dominus> wjp, can you explain to me why ambrosia has visible sparkling rain and the generator has invisible one?
[21:25:15] <Dominus> mountain roof, probably...
[21:27:48] <Dominus> hmm, when I finished the generator and step outside the dungeon, still no magic...
[21:30:16] <wjp> I wonder how it's supposed to reset
[21:34:27] <Dominus> interesting, in the original you *DO* see the sparkling rain
[21:37:35] <Dominus> even more interesting, in the original, I cast light in that cave, then reloaded to a save in britain, cheat teleported back to the cave and the light spell still worked :)
[21:40:04] <Dominus> wjp, from a little testing, once you are out of the egg range, that weather should stop gradually in about 5-10 seconds
[21:40:14] <Dominus> in the original at least
[21:41:56] <Dominus> and another bug
[21:42:26] <wjp> we do seem to remove weather effects when walking away
[21:42:35] <wjp> but no idea how well the distance is chosen
[21:42:48] <Dominus> and you don't walk away :)
[21:43:01] <wjp> well, walking was just a random word
[21:43:13] <Dominus> one of the eggs outside of the generator should make the time lord speak once you destroyed the generator, doesn't in Exult
[21:43:23] <wjp> it's when moving between chunks
[21:43:23] <Dominus> :(
[21:43:42] <Dominus> is a chunk small enough in this case?
[21:43:58] <wjp> no idea
[21:49:00] <wjp> bed time... good night
[21:49:11] <Dominus> good night
[21:49:22] <Dominus> will comitt now and record the other bugs
[21:49:28] <Dominus> thanks a lot for debugging
[22:04:19] <-- ShamblerDK has left IRC (Remote host closed the connection)
[22:50:12] <Dominus> interestingly, when the generator gets destroyed there is a terminal message "Can't create script for NULL object" - perhaps the time lord speach should get scripted or something....