#gemrb@irc.freenode.net logs for 26 Mar 2011 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage


[00:03:12] <tomprince> New version of wild spell patch up on github (branch spell).
[00:08:11] <fuzzie> well
[00:08:29] <fuzzie> "Effect fx = features[i];" <- this is what i mean about references leading to hard-to-see magic
[00:16:47] <tomprince> ?
[00:17:33] <tomprince> You mean the copying?
[00:17:51] <fuzzie> yes
[00:18:38] <tomprince> Effect fx = new Effect(features[i]) ?
[00:18:49] <fuzzie> just Effect fx(features[i]) suffices, no?
[00:18:57] <tomprince> that too.
[00:19:01] <fuzzie> but i just mean, references just means extra confusion for people who don't know C++ well
[00:19:06] <fuzzie> and i'm not sure that's a good idea in game code.
[00:19:54] <tomprince> Well, I'm just curious, since I don't see references in that code, other than features, which is unrelated to the copying.
[00:20:33] <fuzzie> i'm confused
[00:21:25] <fuzzie> i mean, isn't *all* of this stuff references, in that branch?
[00:21:56] <tomprince> Only in SPLImporter, and one overload of AddEffect.
[00:22:43] <fuzzie> am i looking at wrong branch
[00:22:44] <fuzzie> ?
[00:22:46] <fuzzie> > std::vector<Effect> const& Spell::GetFeatureBlock(int block_index) const
[00:23:02] <fuzzie> oh, i guess that is all features
[00:23:28] <fuzzie> but this is because the whole commit is features
[00:24:39] <tomprince> I could do what I did in the gist, not factor out that if statement, and grab a pointer to the array, but that just seemed uglier to me.
[00:25:20] <fuzzie> well, imo it is clearer
[00:25:47] <fuzzie> but i'll look at it in the morning
[00:26:32] <fuzzie> well, imo it is a horrible ugly hack
[00:26:59] <fuzzie> but i imagine it is the only version which makes sense to the only people likely to work on that code.
[00:27:30] <fuzzie> which is not best definition of 'clearer'. will sleep on it. ninight.
[00:27:39] <fuzzie> btw is it possible for you to merge that AboutToDie commit?
[00:28:41] <fuzzie> i guess you want someone to check files-win32 before you start merging the files stuff, haven't found way to windows machine today
[00:29:01] <fuzzie> but, night.
[00:29:08] <tomprince> night.
[00:39:54] <CIA-48> GemRB: 03tom.prince * rb6bb97ed8433 10gemrb/gemrb/core/GameScript/ (GameScript.cpp GameScript.h):
[00:39:54] <CIA-48> GemRB: GameScript: Rename ReadyToDie to isNull, to make its purpose clearer.
[00:39:54] <CIA-48> GemRB: This also change it to not suicide.
[00:45:19] <tomprince> If I was smart, I would have written that commit message the other way around... :)
[01:02:43] <Drakkar> hmm thanks fuzzie and Maighstir, and night fuzzie
[02:18:56] <-- barra_away has left IRC (Read error: Connection reset by peer)
[02:21:29] <edheldil_> Good night all. The LoadConfig patch is at https://github.com/edheldil/gemrb/tree/loadconfig
[02:27:06] <pupnik> goodnight edheldil_
[02:40:29] <edheldil_> good night
[02:45:22] <tomprince> edheldil_: return false followed by break?
[02:46:19] <edheldil_> oops, that is left from debugging, to exit at end of load
[02:47:03] <tomprince> Which should it be?
[02:48:02] <edheldil_> break
[02:49:24] <edheldil_> pushed to github
[02:53:24] <edheldil_> good night, again :)
[02:57:39] <-- edheldil_ has left IRC (Ping timeout: 240 seconds)
[02:59:16] <tomprince> I've now merged it into my files-win32 branch.
[04:07:12] <-- Maighstir has left IRC (Quit: ~ Trillian Astra - www.trillian.im ~)
[05:24:12] --> PixelScum has joined #GemRb
[05:27:25] <-- Drakkar has left IRC (Ping timeout: 264 seconds)
[05:57:30] <-- PixelScum has left IRC (Read error: Connection reset by peer)
[05:57:59] --> PixelScum has joined #GemRb
[06:55:06] --> edheldil_ has joined #GemRb
[07:04:53] <-- edheldil_ has left IRC (Ping timeout: 246 seconds)
[07:43:47] --> barra_home has joined #GemRb
[09:13:23] <fuzzie> hm i shouldn't try reviewing code late at night :)
[09:14:21] --- barra_home is now known as barraAway
[10:34:53] <fuzzie> also that pickpocket code for making money items out of money is buggy
[10:35:19] <fuzzie> it is dropping gold at feet if inventory is done without a pickpocket success message, and then it is not removing the money when it does so
[10:35:31] <fuzzie> we should really not be doing that by default
[10:52:10] --> edheldil_ has joined #GemRb
[10:56:39] --> barra_home has joined #GemRb
[10:56:51] <-- barra_home has left IRC (Read error: Connection reset by peer)
[11:13:15] --- barraAway is now known as barra_home
[11:25:29] <-- edheldil_ has left IRC (Ping timeout: 240 seconds)
[12:24:23] --> edheldil_ has joined #GemRb
[12:41:41] --> Maighstir has joined #GemRb
[14:35:47] --> pupnik_ has joined #GemRb
[14:36:18] <-- pupnik has left IRC (Read error: Operation timed out)
[14:37:26] --- barra_home is now known as barraAway
[16:31:29] <-- edheldil_ has left IRC (Ping timeout: 240 seconds)
[17:24:37] --- barraAway is now known as barra_semiafk
[17:36:05] --> lynxlynxlynx has joined #GemRb
[17:36:05] <-- lynxlynxlynx has left IRC (Changing host)
[17:36:05] --> lynxlynxlynx has joined #GemRb
[17:36:05] --- ChanServ gives channel operator status to lynxlynxlynx
[17:43:02] <lynxlynxlynx> back early :)
[17:50:04] <lynxlynxlynx> should that isnull change also be backported?
[17:50:21] <tomprince> No reason for it to be.
[17:50:49] <tomprince> No visible changes.
[17:51:39] <lynxlynxlynx> ok
[17:52:26] <CIA-48> GemRB: 03tom.prince 070.6.4 * r3a7c0d880647 10gemrb/gemrb/core/GameScript/GSUtils.cpp:
[17:52:26] <CIA-48> GemRB: GSUtils: Don't segfault in MoveNearerTo targets an actor without an area.
[17:52:26] <CIA-48> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[19:00:07] <tomprince> is FXOpcodes.cpp:3730 endian correct?
[19:00:41] <fuzzie> ok, what on earth? :)
[19:01:47] <fuzzie> i don't think it is, and i don't know what the alignment promises would be there either?
[19:02:09] <tomprince> That is how I found it. (aligment warnings from clang)
[19:02:48] --> edheldil_ has joined #GemRb
[19:04:33] <fuzzie> i think it's all unused gemrb extension, but yes, horrible and broken
[19:08:05] <fuzzie> pity, i thought for a moment there you had found the mysterious ARM colour bug
[19:08:54] <tomprince> How about the endianness of ReadPixel and WritePixel in SDLVideo ~1673 (the 2 and 4 byte cases).
[19:09:14] <fuzzie> that is native endianism
[19:10:45] <tomprince> Can we change those to memcpys?
[19:10:56] <fuzzie> can we?
[19:11:52] <fuzzie> i'm not sure it'd be tidier
[19:12:17] <fuzzie> this kind of thing is exactly why i am pleased gcc 4.6 has this #pragma stuff working, so i can tell it to stop whining about non-existant endianism issues :/
[19:12:22] <fuzzie> erm, alignment issues
[19:12:48] <fuzzie> but i guess you could #ifdef the endianism there and memcpy, or do something tidier
[19:15:08] <tomprince> Just looking at the low hanging fruit. https://github.com/tomprince/gemrb/branches/align is what I have.
[19:16:22] <fuzzie> huh
[19:16:23] <fuzzie> oops
[19:16:34] <fuzzie> hadn't realised OpenAL hadn't had those short* issues fixed
[19:16:50] <fuzzie> i remember them being fixed, but apparently in SDLAudio
[19:17:15] <tomprince> Well, we get everything for malloc, so it doesnt matter. This just gets rid of the warnings.
[19:17:43] <fuzzie> yes, it's just that people like the warnings gone :)
[19:18:06] <tomprince> http://localhost:9010/builders/autotools%20clang%2B%2B/builds/40/steps/compile/logs/warnings%20%2824%29 is what I get after those two patches.
[19:18:33] <fuzzie> have a reachable hostname?
[19:18:53] <tomprince> gemrb.hocat.ca/buildbot
[19:18:54] <tomprince> :)
[19:18:54] <fuzzie> the patches look good to me
[19:18:57] <fuzzie> thanks
[19:19:46] <fuzzie> i would usually say that i'd prefer the BIKPlayer/GetBitContext stuff be left unchanged so we can merge with upstream
[19:20:03] <fuzzie> but i think wjp said that we deviated far too much already
[19:20:11] <CIA-48> GemRB: 03tom.prince * r0d0a967ebbdb 10gemrb/gemrb/plugins/OpenALAudio/ (OpenALAudio.cpp OpenALAudio.h): OpenAL: Fix alignment warnings.
[19:20:14] <CIA-48> GemRB: 03tom.prince * r8ae8d7db21c2 10gemrb/gemrb/plugins/WAVReader/WAVReader.cpp: WAVReader: Alignment warning fixes.
[19:20:20] <tomprince> I hadn't looked at BIKPlayer yet.
[19:20:49] <fuzzie> our copy is based on a preliminary patch for ffmpeg, before it got tidied up, i think
[19:21:00] <tomprince> And I want to refactor the Maze stuff out of GUIScript.
[19:21:29] <fuzzie> but if you do take a look, all this SET_INT_TYPE stuff is from the ARM porter
[19:21:48] <tomprince> re: bik, do you know if current ffmpeg works better/worse than ours?
[19:21:49] <fuzzie> who actually wrote alignment-safe versions
[19:21:50] <wjp> fuzzie: I did port a functions from a more recent ffmpeg
[19:22:02] <wjp> s/a /a few /
[19:22:16] <fuzzie> current ffmpeg works better than ours, i think, but i would not touch unless you want a fairly large project
[19:22:28] <fuzzie> unless i got the wrong impression from what wjp and Avenger have said
[19:22:46] <tomprince> Maybe I should write a ffmpeg importer instead ...
[19:22:56] <fuzzie> we can't depend on ffmpeg
[19:23:00] <wjp> hm, I didn't notice any more difference between us and ffmpeg
[19:23:15] <fuzzie> so it wouldn't help us get rid of anything we have
[19:24:03] <fuzzie> and if you are going to be doing straight refactoring out of GUIScript, the 'AddNewArea' function really shouldn't be in there either
[19:24:43] <fuzzie> i am still not convinced it is correct, but just moving it shouldn't make a difference to that. :P
[19:25:25] <fuzzie> i know nothing about the maze code, it looks like there isn't much to refactor at a glance..?
[19:26:21] <-- |Cable| has left IRC (Remote host closed the connection)
[19:26:58] <tomprince> Mostly I want to try and get rid of all the pointer arithmetic, at least the bit of it using char* arithmetic for structures.
[19:27:00] <fuzzie> i guess SetupMaze, SetMazeEntry and SetMazeData would mostly be nicer elsewhere, but not really much code there
[19:27:40] <tomprince> That is responsible for 10 of 24 alignment warnings. :)
[19:27:42] <fuzzie> well, i think Avenger said it is working now, so i suppose that is reasonabgly safe :)
[19:27:54] --> barra_away has joined #GemRb
[19:28:28] <fuzzie> but i am pretty tired and i am not going to make same mistake as i did last night of reviewing code when tired and just ending up saying complete nonsense
[19:28:35] <tomprince> :)
[19:30:55] <-- barra_semiafk has left IRC (Ping timeout: 246 seconds)
[19:41:48] <lynxlynxlynx> ugh, fireball scrolls are broken again
[19:42:08] <fuzzie> howso?
[19:42:11] <lynxlynxlynx> this time it is the same thing that bugs stone-to-flesh
[19:42:26] <lynxlynxlynx> wherever you cast it, it will end up centered on the caster
[19:44:51] <fuzzie> i am sitting here trying to work out what to do with GameTime etc
[19:44:53] <lynxlynxlynx> the alignment fixes from before are safe, right?
[19:45:24] <fuzzie> they seem safe, but they don't fix anything for end-users
[19:46:07] <lynxlynxlynx> -Werror friendliness
[19:50:05] <fuzzie> i'm pretty sure now that both combat and magic rounds in bg2 are 100 ticks, btw
[19:50:29] <fuzzie> this is not interesting because i need to rewrite all related code
[19:50:42] <fuzzie> but just for information
[19:51:37] <lynxlynxlynx> huh, that's not 90
[19:53:03] <fuzzie> i haven't looked for the effect round code.
[19:55:13] <fuzzie> and did we ever establish why gemrb aims for 60fps?
[19:57:38] <fuzzie> i guess from history it is just a random value
[20:02:57] <fuzzie> but anyway, you can see from rndbase that it only ends the round in column 101 (zero-indexed), and the actor code doesn't do anything except keep it <=100
[20:13:49] <fuzzie> ok, i'm not convinced about this RPD_ROUNDS stuff..
[20:14:07] <fuzzie> i don't see the opcode doing anything of the sort
[20:17:03] <fuzzie> for poison, RPD_ROUNDS is 1 damage every param1 seconds, RPD_TURNS is param3 damage every param1 seconds, RPD_SECONDS is 1 damage every second
[20:18:25] <fuzzie> no, this is just confusing me further
[20:20:16] <fuzzie> RPD_ROUNDS is 1 damage every param1 seconds, RPD_TURNS is assert(FALSE), RPD_SECONDS is 1 damage every param1 seconds, RPD_POINTS is param1 damage every second
[20:22:12] <fuzzie> and RPD_PERCENT and 0 make no sense
[20:23:07] <fuzzie> well, they both do 1 damage every tick as long as (param1*HP/100) or (param1) were above 0 respectively, but that's pretty crazy
[20:23:12] <fuzzie> erm, every second
[20:25:19] <fuzzie> and regen does pretty much the same
[20:31:07] <lynxlynxlynx> confusing indeed, but i think we currently have the most working version ever :)
[20:31:33] <edheldil_> good evening
[20:31:53] <tomprince> Any thoughts on rearranging the repo.
[20:31:54] <fuzzie> well, of course our code will always be completely different to madness of original
[20:32:09] <fuzzie> tomprince: maybe enumerate your suggested options :)
[20:32:22] <tomprince> gemrb -> src
[20:32:37] <edheldil_> for
[20:32:42] <edheldil_> aye
[20:32:55] <edheldil_> or whatever :)
[20:32:56] <tomprince> gemrb/core -> core, gemrb/plugins -> plugins, gemrb/includes -> include, ...
[20:32:56] <fuzzie> yes, i think it's clear we're all for gemrb->src
[20:33:23] <tomprince> Or at least gemrb/docs -> doc gemrb/includes -> src/include
[20:33:27] <fuzzie> i think renaming includes to include and docs to doc is silly, but i am not so bothered
[20:33:52] <fuzzie> and i am undecided on moving everything to the root
[20:34:19] <edheldil_> why move core from src?
[20:34:46] <fuzzie> i think it would just be more confusing, but if edheldil and lynxlynxlynx think it's a good idea..
[20:34:53] <fuzzie> wjp: poke, too
[20:34:59] <tomprince> conversely, why have everything under src?
[20:35:20] --> |Cable| has joined #GemRb
[20:35:38] <fuzzie> well, because it's the source, as opposed to the other stuff lying around the tree
[20:36:14] <lynxlynxlynx> i worry about the git history, because i need to use it a lot
[20:36:34] <edheldil_> e.g. override, / guiscripts *could* be moved to root, docs too
[20:36:39] <fuzzie> well, for individual files, 'git log --follow' works well
[20:36:47] <lynxlynxlynx> the moves out of src seem unneeded too
[20:36:49] <fuzzie> and for directories i think we are screwed if we do the gemrb->src change
[20:36:53] <tomprince> Then at least doc and tests should come out. And perhaps override + guiscript, perhaps to data or share?
[20:37:02] <tomprince> git gui blame is nice.
[20:37:17] <tomprince> And that grabs moving bits of code around, as well as entire files.
[20:37:29] <lynxlynxlynx> gui pfff
[20:37:36] <fuzzie> what is git gui?
[20:37:45] <wjp> I don't think I'd like moving include and plugins out of gemrb/src
[20:37:48] <fuzzie> i kept meaning to ask this, but it isn't present on any machine
[20:38:05] <wjp> moving override and guiscripts would be ok, I suppose
[20:38:29] <fuzzie> and i got the impression that it was useless for viewing history. manpage agrees..
[20:38:40] <edheldil_> th app, similar to gitk
[20:38:55] <edheldil_> tk
[20:39:01] <fuzzie> i mean, what i need is 'what changed in the last 2 years', often stuff which is completely gone from current version
[20:39:25] <tomprince> 'git gui blame filename' gives you a nice viewer, that allows you to browse through the history of lines of code.
[20:39:27] <fuzzie> and moving gemrb->src will make this rather more annoying, since --follow is known-broken
[20:39:45] <fuzzie> but i can suffer that if it's really helpful enough to others
[20:40:18] <tomprince> And it tracks lines of code across movement between files as well as moving files. And show both the move commit and original commit.
[20:40:22] <fuzzie> yes
[20:40:27] <fuzzie> but not any actual history?
[20:41:27] <tomprince> Well, it doesn't give you a pretty graph, but it can show you the local graph near the commit associated to any line.
[20:41:34] <fuzzie> sure
[20:42:14] <fuzzie> so, it doesn't show file history :P
[20:43:17] <fuzzie> i already read these threads about tracking lines being more important than tracking files/directories, but it doesn't really fit with chaotic codebases like gemrb where bugs cannot be localised to a few lines..
[20:43:18] <tomprince> You should try it out. It is probably in a git-gui package, on a binary distro.
[20:45:39] <fuzzie> i did
[20:46:15] <fuzzie> i should've picked a better example repos to try it on, though
[20:47:06] <fuzzie> but it just seems to launch gitk when i click on anything hopeful :)
[20:48:47] <tomprince> hmm ... I only get gitk when I ask to 'show history context'
[20:48:56] <fuzzie> yes
[20:49:08] <fuzzie> or 'visualize master's history' from menu
[20:49:46] <fuzzie> otherwise it seems like a slightly more convenient shortcut for 'git blame' and copy-and-pasting the revision ids into gitk command line, i think i am not understanding the utility :)
[20:52:21] <fuzzie> the commit view is nice though
[20:55:24] <tomprince> Well, the use case I am thinking of, is you are looking at a bit of code, and want to see why it is the way it is, so you launch git-gui-blame. You can see what commit it came from, and by clicking on the commit, you can see what the code looked like at that time (and incidentely where it was). And to look at the history around that commit, you can switch to gitk easily.
[20:55:30] <fuzzie> sure
[20:55:46] <fuzzie> it's just that my use case is mostly that i want to find a *bug*.
[20:55:59] <fuzzie> and it could be somewhere in a few thousand lines..
[20:57:50] <fuzzie> being able to say 'what changed on all these lines?' would be a vast improvement beyond poking at the logs for everything, but i can't find any way to do that, and everyone assumes that you can find some specific lines to look at, which is honestly not very helpful :)
[20:59:14] <fuzzie> and whenever i am looking at 'git blame' for existing lines, i find the diff far more helpful than just seeing how it used to work..
[21:00:14] <fuzzie> the prior is obviously only relevant to projects which are so annoyingly interconnected, but i find it strange that the latter isn't the standard thing people want it for..
[21:01:50] <wjp> it's not so clear what a good interface for such a function would be
[21:02:16] <tomprince> .... anyway, still no consensus on layout, so I will let people mull it over for a few days...
[21:02:28] <fuzzie> we are so delightfully hopeless
[21:02:53] <tomprince> emphasis on the delightful. :)
[21:02:55] <fuzzie> but i imagine consensus will end up being that gemrb->src is a necessary evil, and moving source out of src is a bad idea
[21:03:43] <tomprince> which leaves docs and override and potentially GUIScript.
[21:04:09] <tomprince> I'm somewhat inclined to move the later to data or share.
[21:04:33] <fuzzie> how do you mean?
[21:05:11] <tomprince> putting them in share/override and share/GUIScript, or s/share/datat there.
[21:05:36] <fuzzie> in the tree?
[21:06:03] <tomprince> yes.
[21:06:09] <fuzzie> i am confused as to why you'd want that
[21:07:32] <-- MikeChelen has left IRC (Ping timeout: 250 seconds)
[21:09:06] --> MikeChelen has joined #GemRb
[21:25:29] <tomprince> perhaps we don't. I just want to avoid break git log twice (now). And my idea is, to figure out how one would structure the files we have, ignoring that we have a layout for them already.
[21:28:28] <tomprince> nad proposing radical suggetions now, so that we don't end up wanting to reorganize thing again a few years down the road.
[21:37:54] <-- MikeChelen has left IRC (Ping timeout: 250 seconds)
[22:00:15] <edheldil_> was the release branch created already or do we still use master for that?
[22:00:33] <fuzzie> the branch was created already
[22:01:31] <CIA-48> GemRB: 03tom.prince 070.6.4 * r264d72d2d1f9 10gemrb/gemrb/plugins/OpenALAudio/ (OpenALAudio.cpp OpenALAudio.h): OpenAL: Fix alignment warnings.
[22:01:47] <CIA-48> GemRB: 03tom.prince 070.6.4 * ra759e11c871f 10gemrb/gemrb/plugins/WAVReader/WAVReader.cpp: WAVReader: Alignment warning fixes.
[22:02:43] <edheldil_> any objections against committing LoadConfig() patch?
[22:03:41] <fuzzie> what does it do?
[22:03:48] <fuzzie> oh, right, the parsing fix
[22:04:31] <fuzzie> ask tomprince, maybe
[22:04:31] <edheldil_> yep
[22:09:05] <tomprince> Reading it through, looks good to me. And if it was causing hangs, good to get it in. (And it looks like it can be merged, since it branched before 0.6.4
[22:09:21] <wjp> what's the 0.6.4 in those cia messages?
[22:10:50] <lynxlynxlynx> branch name
[22:11:08] <lynxlynxlynx> just hit a fpe while testing :(
[22:12:17] <fuzzie> huh
[22:13:11] <lynxlynxlynx> reproduced, trying with gdb now
[22:14:39] <fuzzie> Map::IsVisible?
[22:14:51] <lynxlynxlynx> useless
[22:15:03] <lynxlynxlynx> it happens when the battle music ends
[22:15:19] <lynxlynxlynx> or maybe when the radiant mephit's color spray finally fades out
[22:15:36] <fuzzie> the projectile stuff looks ok
[22:15:41] <tomprince> I seem vaguly to recall suggesting gemrb -> src, back when we split off core, but that was to radical at the time, where now everybody is in favor. Which I'd like to avoid hapening again... :/
[22:15:45] <fuzzie> you were testing on branch?
[22:15:47] <lynxlynxlynx> [OpenAL]: No Other Music to play <-- is the last thing in the log
[22:15:59] <fuzzie> tomprince: well, everything was rather in flux at the time
[22:16:20] <lynxlynxlynx> i don't remember participating in a src discussion before
[22:16:23] <fuzzie> i can see you liking the idea of just doing all changes at once, but from what i remembered, development was dead enough due to radical changes as it was
[22:17:28] <tomprince> Well, just changes happen seperatly just means more times the history gets disrupted.
[22:18:17] <fuzzie> lynxlynxlynx: is this on branch?
[22:18:55] <lynxlynxlynx> yes
[22:18:59] <fuzzie> the whole music system is known to be a possible cause of crashes, but not reproducibly
[22:19:31] <lynxlynxlynx> can i catch the sigfpe? "catch" doesn't look so helpful
[22:20:07] <fuzzie> it doesn't automatically break on the sigfpe?
[22:20:13] <lynxlynxlynx> the bt is too vague
[22:20:35] <fuzzie> i think it should automatically grab it at the earliest point it can
[22:20:41] <lynxlynxlynx> something - we start a new thread and it goes into openal
[22:20:58] <fuzzie> you looked at all the threads?
[22:21:31] <lynxlynxlynx> hmm, how do i do that?
[22:21:41] <fuzzie> 'thread <id>'
[22:22:08] <fuzzie> i assume you can 'thread apply bt' but i'm not sure off the top of my head :)
[22:23:11] <lynxlynxlynx> the other one is in the tile renderer
[22:23:58] <lynxlynxlynx> i doubt there's anything interesting there
[22:24:05] <fuzzie> me too
[22:25:37] <fuzzie> the responsible caller is presumably PlayNext()
[22:26:40] <fuzzie> do you have latest branch?
[22:27:27] <fuzzie> right, yes, it had alignment patch applied..
[22:27:38] <fuzzie> and it is broken
[22:28:09] <fuzzie> OpenALAudio.cpp:857 should be '+ cnt', not ' + (cnt * 2)'
[22:30:34] <wjp> hm, yes, that 0.6.4 was the branch name was my first guess but then I saw the amount of commit activity on it, and that made me wonder :-)
[22:31:35] <fuzzie> i found a bunch of bugs in SoA playthrough
[22:31:53] <fuzzie> mostly caused by things i complained about in here when committed :P
[22:32:02] <fuzzie> but hopeless to try and dig through now
[22:32:09] <fuzzie> and all need rewrite
[22:33:44] <fuzzie> lynxlynxlynx: i am going to assume you will test+commit unless you say otherwise
[22:34:04] <lynxlynxlynx> it is PlayNext, i just confirmed it
[22:34:30] <lynxlynxlynx> how come this causes a /floating point/ exception?
[22:35:01] <tomprince> wjp: There was a couple of crash/infinite loop fixes, and thw wild-magic stuff has a different, more invasive fix that will go into mainline.
[22:35:24] <fuzzie> lynxlynxlynx: if it's the thing i mentioned above, it will be randomly stomping over memory
[22:35:35] <fuzzie> tomprince: and unnecessary alignment fixes with bugs in them, is i think the point here :P
[22:36:15] <tomprince> don't blame me for those. at least not on the branch.
[22:36:21] <fuzzie> sure
[22:36:29] <fuzzie> i didn't realise you committed anything to branch?
[22:37:17] <tomprince> I didn't.
[22:37:53] <fuzzie> so, i don't mean to blame you for anything,
[22:38:00] <tomprince> :)
[22:38:01] <fuzzie> lynx asked, i said they looked safe
[22:38:28] <fuzzie> so i think if you want to pin blame label on someone, pin on me :P but it's just that gemrb isn't stable enough to be so careful about patches.
[22:39:28] <fuzzie> so the branch gets anything which looks useful, rather than things which are super strictly necessary and got reviewed by many eyes, and it is confusing at first sight to see that on a release branch after other projects!
[22:40:13] <wjp> as evidenced by my confusing :-)
[22:40:19] <wjp> s/ing/ion/
[22:41:51] <CIA-48> GemRB: 03lynxlupodian 070.6.4 * r7da4ddb8245f 10gemrb/gemrb/plugins/OpenALAudio/OpenALAudio.cpp: OpenALAudio: don't crash when music ends, fallout from 264d72d2d1f
[22:42:43] <lynxlynxlynx> it plays well with the other arm fixes, that's why it is interesting
[22:43:19] <fuzzie> sure
[22:43:37] <fuzzie> sorry, i seem to have caused seeming criticism when it was not intended
[22:44:10] <fuzzie> i oked that patch twice :)
[22:45:43] <lynxlynxlynx> no problem
[22:46:14] <lynxlynxlynx> just going through the chateau to check if everything usual still works
[22:46:34] <fuzzie> the jaheira trigger for seeing khalid wasn't working when i tried, i'm not sure why
[22:46:45] <lynxlynxlynx> i'm right there now, will check
[22:47:15] <lynxlynxlynx> the only obviously missing thing is the disarm/lockpick sounds, but that's not a regression afaik
[22:49:04] <fuzzie> i guess we already went through the pointer arithmetic bugfixing in SDLAudio, all looks ok still
[22:49:12] <lynxlynxlynx> no reaction from jaheira
[22:49:23] <lynxlynxlynx> yeah
[22:49:24] <fuzzie> was Avenger which found the equivalent bug there, heh :P
[22:50:48] <fuzzie> i guess Avenger broke the infopoints
[22:51:22] <fuzzie> might be worth reverting 3d1a54e9b on the branch
[22:52:25] <fuzzie> if it fixes that issue, that is
[22:54:54] <lynxlynxlynx> which script is this from btw? i don't see it in the main jaheira's or the area's
[22:56:29] <fuzzie> the region's script
[22:56:36] <fuzzie> dkhalid.baf
[22:58:03] <fuzzie> that commit from Avenger breaks it because he added a ip->Trapped requirement for some reason
[22:58:05] <lynxlynxlynx> IsOverMe doesn't get run at all
[22:58:13] <fuzzie> so it gets no scripts run, ever
[22:58:29] <lynxlynxlynx> it was the one also possibly breaking repeating traps?
[22:58:37] <fuzzie> no, that is another one
[22:59:07] <fuzzie> i guess reverting the commit is a bit intrusive
[22:59:25] <fuzzie> just remove the ip->Trapped check after "// (eg, TriggerActivation changes this, see lightning room from SoA)", maybe
[22:59:37] <fuzzie> the code there is all completely and utterly wrong anyway
[22:59:43] <lynxlynxlynx> reverting would be a pain due to the door move anyway
[23:00:30] <lynxlynxlynx> heh, nice comment
[23:00:41] <lynxlynxlynx> i forgot the lightning room didn't work at all
[23:02:26] <fuzzie> the reality is that scripts are only disabled if TRAP_DEACTIVATED, INFO_DOOR or <cases no-one cares about>
[23:02:53] <fuzzie> but we handle travel triggers there right now, so best not to fiddle
[23:03:53] <lynxlynxlynx> that was enough btw
[23:04:04] <fuzzie> :)
[23:04:18] <fuzzie> great
[23:05:02] <fuzzie> lightning room and jaheira?
[23:06:23] <fuzzie> i wonder why triggered traps run even if they have no script
[23:06:54] <fuzzie> i guess to allow for harmless traps
[23:07:51] <fuzzie> oh hey, TrapTriggered is actually used :)
[23:08:41] <fuzzie> one single script in the whole game
[23:09:48] <fuzzie> ah, for the trap in the Copper Coronet
[23:12:51] <lynxlynxlynx> will check the lightning room tommorow
[23:13:06] <lynxlynxlynx> as usual, later today
[23:14:16] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[23:16:57] --> raevol has joined #GemRb
[23:27:14] <fuzzie> so gemrb's RealTime is counted in milliseconds
[23:28:19] <fuzzie> and i'm confused by this - doesn't that make romances go about 66x faster than they should?
[23:36:40] <fuzzie> ah yes, i already complained about this in irc logs :/
[23:40:56] <-- edheldil_ has left IRC (Ping timeout: 250 seconds)
[23:43:54] <fuzzie> mm, completely wrong
[23:44:56] <tomprince> by the by, I'll be in paris for a few days next week.