[02:49:26] --> tomprince has joined #GemRb
[03:27:09] --> MikeChelen has joined #GemRb
[03:38:33] <MikeChelen> is cmake/make supposed to be run as sudo?
[03:42:08] <pupnik> normally no
[03:42:19] <pupnik> "make install" may require root/su
[03:42:39] <pupnik> @ MikeChelen
[03:44:16] <tomprince> If you have previously run them as root, you may need to clean up the files, before they will run properly as a regular user.
[04:34:35] <MikeChelen> pupnik: hehe, the install guide never mentions "make install"
[04:35:31] <MikeChelen> in http://gemrb.sourceforge.net/wiki/doku.php?id=getting_started#gemrb
[04:45:07] <tomprince> That is probably because most of the developers run from the build directory.
[05:11:42] * pupnik is pretty impressed with daimonin atm
[05:18:43] <MikeChelen> tomprince: that sounds find too, what is the command then?
[05:19:37] <tomprince> What do you mean?
[05:21:16] <MikeChelen> where is the gemrb executable?
[05:22:19] <tomprince> in the build directory.
[05:23:18] <MikeChelen> ah ok will check there
[05:23:39] <MikeChelen> is that after running "make"?
[05:23:43] <tomprince> yes.
[05:23:53] <MikeChelen> ok, but not "make install" right?
[05:23:57] <tomprince> yes.
[05:24:02] <MikeChelen> ok cool
[05:27:13] <tomprince> promised hacks to (start) to implement AI in python: https://github.com/tomprince/gemrb/tree/gs-hack
[05:29:45] <MikeChelen> yay ai!
[05:30:17] <tomprince> About the only semi useful thing you can do is something like: self.AddAction(GemRB.GetPCs().GetCurrentAction())
[05:30:22] <tomprince> Which is useless, but a start.
[05:32:38] <tomprince> What I need now, is some sort of information on paramaters that various action need, so I can create them.
[05:32:59] <tomprince> And a better way to represent object paramaters.
[05:33:54] <tomprince> Since python scripts probably want to do the object resolution themselves.
[05:34:17] <tomprince> Perhaps just virtual dispatch in an Object::Evalute method.
[06:01:08] <MikeChelen> sure that sounds cool
[06:04:56] <tomprince> Looking at Matching.cpp and Objects.cpp, IEScrip objects are really baroque and strange. It'd be nice if there was a clean abstraction of the,
[06:06:12] <tomprince> m. Something so that python scripts can create simple object references, and IEScripts can use the baroque multiply overloaded inefficent object stuff there is now.
[06:09:40] <-- MikeChelen has left IRC (Remote host closed the connection)
[06:15:17] <tomprince> Except sometimes it seems that the object paramater is actually used as string paramater.
[06:15:20] <tomprince> :(
[06:16:16] <tomprince> (ignore the GS.h split, that was me trying to find/minimize dependencies)
[06:28:27] --> edheldil_ has joined #GemRb
[06:32:02] <-- pupnik_ has left IRC (Quit: leaving)
[07:08:53] <-- edheldil_ has left IRC (Ping timeout: 255 seconds)
[07:23:08] --> raevol has joined #GemRb
[07:26:23] <-- raevol has left IRC (Client Quit)
[07:43:51] --> Bo_Thomsen has joined #GemRb
[08:08:59] --> edheldil_ has joined #GemRb
[08:15:23] <-- edheldil_ has left IRC (Ping timeout: 248 seconds)
[08:18:31] --> edheldil_ has joined #GemRb
[08:19:37] --> adominguez has joined #GemRb
[08:56:05] <-- Bo_Thomsen has left IRC (Quit: Leaving.)
[09:08:47] --> lubos has joined #GemRb
[09:23:35] <fuzzie> tomprince: the action parameter info is exactly what action.ids is, right?
[09:24:44] <fuzzie> but this is very invasive patch
[09:27:53] <fuzzie> i'd want to see that adding Holder<> everywhere doesn't cause slower/larger code
[09:29:27] <fuzzie> well, it is inevitable that it will cause slower/larger code, but i mean outside of the array manip
[09:31:10] <fuzzie> but some of this is plain broken
[09:31:58] <fuzzie> that "Code simplification" commit Response::Execute completely, surely
[09:32:05] <fuzzie> breaks it, i mean
[09:34:33] <fuzzie> and i've NACKed that bs/bcs patch before, i forget why
[09:37:22] <edheldil> which one?
[09:37:33] <fuzzie> and obviously NACK on the GameScript->resource thing for now because it is setting STATIC_LINK
[09:38:01] <fuzzie> edheldil: https://github.com/tomprince/gemrb/commit/3a674b10a02be8dd57ab488aeb603b7ea49f396b
[09:40:52] <edheldil> is not it dependent on the resource patch anyway?
[09:41:21] <fuzzie> yes, but none of this is going to be merged right now anyway
[09:42:25] <fuzzie> i'm not quite sure i understand the Action thing
[09:42:59] <fuzzie> i am wondering what we *can* merge quickly, without me reverting it out of frustration a few hours later
[09:43:12] <edheldil> also I believe it should not be mucking with paths, but it might be just my pov :)
[09:43:41] <fuzzie> well, yes, that too
[09:44:17] <edheldil> looks like TP did an awful lot of work, though
[09:44:20] <fuzzie> yes
[09:44:24] --> MikeChelen has joined #GemRb
[09:44:27] <fuzzie> which is a bit annoying, i warned i was about to rewrite some of this :)
[09:44:42] <fuzzie> but i guess it is mergable
[09:44:48] <MikeChelen> getting and error during compilation: gemrb/plugins/GUIScript/GUIScript.h:31:20: fatal error: Python.h: No such file or directory
[09:45:08] <fuzzie> huh. did you change something in your environment?
[09:45:21] <MikeChelen> oh maybe it is my terminal
[09:45:49] <MikeChelen> hmm nope
[09:45:49] <fuzzie> usually that means you don't have the python 2.x headers installed
[09:46:07] <MikeChelen> what debian/ubuntu package would that be, python-dev?
[09:46:08] <fuzzie> but if you built it before, presumably you'd know if you removed them since
[09:46:25] <fuzzie> yes, i think python-dev in debian/ubuntu
[09:46:30] <MikeChelen> well something might have changed, its been a while
[09:46:39] <MikeChelen> that package is definitely installed
[09:46:57] <MikeChelen> and there are a few copies of Python.h on the system
[09:47:08] <MikeChelen> maybe try reinstalling package?
[09:47:45] <edheldil> nah ... is it debian or ubuntu?
[09:48:02] <MikeChelen> ubuntu
[09:48:16] <edheldil> on lucid, you should have /usr/include/python2.6/Python.h
[09:48:35] <MikeChelen> yup that exists
[09:48:53] <edheldil> then maybe try cmake ...... again
[09:49:10] <MikeChelen> just did, same thing
[09:49:21] <MikeChelen> does build dir have to be deleted?
[09:49:36] <edheldil> dunno, try it :)
[09:49:56] <edheldil> usually not necessaru, but won't hurt
[09:50:12] <MikeChelen> we'll see :)
[09:51:40] <edheldil> also look if there's PYTHON_INCLUDE_DIR:PATH=/usr/include/python2.6 in the CMakeCache.txt file
[09:52:22] <MikeChelen> yay make worked this time :)
[09:52:38] <edheldil> good, problem solved ;-)
[09:53:02] <MikeChelen> now to figure out the config paths
[09:53:47] <edheldil> if you do not install, just copy the noinstall one to the build dir, it's mostly set-up already
[09:54:28] <MikeChelen> it would be nice to use my existing config
[09:55:00] <MikeChelen> it should check ~/.gemrb/gemrb.cfg right?
[09:56:21] <MikeChelen> hmm [Config]: Trying to open GemRB.cfg [NOT FOUND]
[09:57:37] <MikeChelen> ahh is it case sensitive?
[09:57:49] <edheldil> does ~/.gemrb/gemrb.cfg exist?
[09:59:19] <MikeChelen> yeah
[09:59:28] <fuzzie> tomprince: NACK on the DisplayMessage removal too
[09:59:37] <MikeChelen> for some reason it was not being read
[09:59:45] <MikeChelen> until it was symlinked as GemRB.cfg
[09:59:54] <fuzzie> at least until we work out what to do there
[09:59:55] <MikeChelen> in the build dir
[10:00:10] <fuzzie> tomprince: a thousand points for removing the stupid canaries though
[10:00:43] <fuzzie> but i think i have to wait until tomprince is here and discuss individual patches
[10:02:31] <-- |Cable| has left IRC (Remote host closed the connection)
[10:03:53] <MikeChelen> should GUIScriptsPath point to the build dir or the root git dir?
[10:04:24] <edheldil> MikeChelen: actually, it should be enough to have ~/.gemrb/gemrb.cfg
[10:04:47] <fuzzie> not case-sensitive?
[10:04:51] <edheldil> certainly not build dir
[10:05:45] <edheldil> it tries UserDir + (basename(argv) | PACKAGE) + .cfg
[10:07:49] <edheldil> and yes, it still works :)
[10:11:14] * fuzzie wobbles.
[10:11:35] <fuzzie> i'm not sure what to do about that whole patch series
[10:12:10] <fuzzie> it makes it difficult to change the mechanisms to be closer to the original, if that becomes a problem
[10:12:42] <fuzzie> it turns out that the 'script update' bits in the original are where the triggers get cleared, which solves that mystery
[10:24:15] <MikeChelen> thought it should find ~/.gemrb/gemrb.cfg ok but it doesn't seem to
[10:25:12] <MikeChelen> its weird
[10:25:40] <MikeChelen> edheldil: why might it not be finding ~/.gemrb/gemrb.cfg?
[10:36:41] <edheldil> what is the log?
[10:42:57] <MikeChelen> what log?
[10:43:38] <MikeChelen> edheldil: this is console output: http://pastebin.com/ZNnUh0Ub
[11:00:37] <wjp> I haven't looked at the code at all, but GemRB.cfg != gemrb.cfg ?
[11:06:14] <edheldil> but it should then continue to other filename variants ... what does the ^C mean? That it just sit there, doing nothing?
[11:07:04] <edheldil> wjp: it's lowercase except in the current dir
[11:10:53] <-- MikeChelen has left IRC (Remote host closed the connection)
[11:12:07] <wjp> edheldil: that's rather confusing
[11:15:50] <edheldil> I used to think that eventually cwd will not be tried and all of them will be lowercase
[11:17:28] <edheldil> but it might have been too naive
[12:36:53] <fuzzie> well at least it is simple to fix?
[12:44:50] <edheldil> fix which way? :)
[12:47:12] <fuzzie> i have no idea
[14:29:31] <tomprince> fuzzie: I don't mind rewriting all of the branch.
[14:29:54] <tomprince> Some of it I do anyway. :)
[14:32:00] <tomprince> What should really happen is STATIC_LINK get defined in plugindef if GEMRB_BUILD_DLL is defined (which means we are build core not a plugin).
[14:33:20] --> pupnik_ has joined #GemRb
[14:36:04] <-- pupnik has left IRC (Ping timeout: 246 seconds)
[14:47:14] <tomprince> Does the trigger clearing happen at every script *slot* update, or just every script update of the scriptable?
[15:00:18] --> dossantos has joined #GemRb
[15:01:41] <fuzzie> every script update of the scriptable, not a problem in your branch
[15:02:25] <fuzzie> well, i guess maybe python scripts have to deal with it
[15:02:43] <fuzzie> but it's really quite difficult to tell if the refactoring is acceptable without rewriting the code to work
[15:02:55] <fuzzie> i should do that, and push it to github for now
[15:03:06] <fuzzie> the same with Object
[15:03:38] <fuzzie> it is difficult to tell whether we need it all over the core, or whether it can be IEScript-specific.
[15:07:26] <fuzzie> and we should get the correct gcc 4.6 fixes merged if you are using 4.6 :)
[15:07:46] <tomprince> Yes. :)
[15:07:55] <fuzzie> but your patch is broken atm, as discussed deep in backscroll
[15:10:10] <fuzzie> maybe just take some for now
[15:10:41] <fuzzie> it's no problem if i cherry-pick stuff into trunk?
[15:10:55] <tomprince> Go ahead.
[15:12:03] <tomprince> Are you sure the gcc patch is broken? I tried to be careful not to change behavior, so if the resulting code is broken, I would expect the current code is as well.
[15:12:15] <fuzzie> you changed resref+8 code to be the field after resref
[15:12:32] <fuzzie> but sizeof(resref)==9
[15:13:01] <fuzzie> it should be a union, but i don't want to open that can of worms just before a release
[15:13:38] <tomprince> Ah. yes and yes.
[15:20:40] <fuzzie> Our effect code is reasonably complete at this point I think.
[15:26:52] <fuzzie> are you able to test this stuff with msvc, tomprince?
[15:27:35] <fuzzie> i remember that it isn't very happy with forward declarations of classes used in some circumstances (templates?)
[15:27:56] <edheldil> union of what? char and (int, int) ?
[15:28:17] <fuzzie> edheldil: char and char
[15:28:28] <fuzzie> or rather, char and char
[15:29:00] <edheldil> ah, sorry, I thought you wanted to redefine ieResRef
[15:29:04] <fuzzie> no :)
[15:32:04] <CIA-48> GemRB: 03tom.prince * r57aeacd6f938 10gemrb/gemrb/ (4 files in 2 dirs):
[15:32:04] <CIA-48> GemRB: Dialog: Don't include GameScript.h from header.
[15:32:04] <CIA-48> GemRB: Signed-off-by: Tom Prince <firstname.lastname@example.org>
[15:32:08] <CIA-48> GemRB: 03tom.prince * rfeb1774bd7b7 10gemrb/gemrb/ (3 files in 2 dirs): TileMap: Remove GameScript.h from header.
[15:33:49] <fuzzie> reminds me, we should really split ActorBlock.h
[15:55:02] <CIA-48> GemRB: 03fuzzie * reb85caab80b2 10gemrb/gemrb/ (11 files in 3 dirs): rename ActorBlock.cpp/.h to Scriptable.cpp/.h
[15:58:10] --> lynxlynxlynx has joined #GemRb
[15:58:10] --- ChanServ gives channel operator status to lynxlynxlynx
[15:58:29] <fuzzie> afternoon, lynx
[15:59:42] <lynxlynxlynx> oj
[16:15:29] <fuzzie> it is tricky to work out whether we can get away with the global ids in triggers
[16:15:59] <fuzzie> the problem (apart from efficiency, i guess) is that it won't work for stuff that gets deleted, e.g. after DestroySelf()
[16:17:14] <fuzzie> but perhaps if i hope really hard then that won't be a problem
[16:20:57] <lynxlynxlynx> how come? wouldn't (dangling) references be checked on use?
[16:21:26] <fuzzie> yes, but they don't exist any more, so they can't be matched
[16:21:38] <fuzzie> the original stores the Object, so you can still match on attributes (like EA)
[16:22:47] <tomprince> I would hope that dangling targeting wouldn't be an issue.
[16:23:01] <fuzzie> it's not the targetting, just the matching
[16:23:44] <fuzzie> like if something attacks and then does DestroySelf() or destructively leaves area..
[16:25:00] <lynxlynxlynx> why would you still need to match that?
[16:25:20] <fuzzie> because AttackedBy([ENEMY], ...) should still match, for example
[16:26:11] <fuzzie> or, more realistically, checks on things like LastAttacker which last quite a while
[16:36:10] <tomprince> What did you want to test agains msvc6?
[16:36:30] <-- dossantos has left IRC (Quit: Page closed)
[16:41:09] <fuzzie> tomprince: stuff where headers are pulled out of other ones, but i don't see any problems with what i committed, so i wouldn't worry about it
[16:41:21] <fuzzie> (i am bit busy right now)
[16:42:05] <-- lubos has left IRC (Quit: Leaving.)
[17:00:11] <-- edheldil_ has left IRC (Ping timeout: 248 seconds)
[17:11:31] --> Maighstir has joined #GemRb
[17:49:48] <fuzzie> > Resurrected party member's portrait filled by gray color, not a red. But in all other windows (inventory, record, etc) it looks properly and filled by red color.
[17:49:51] <fuzzie> ^- that sounds odd
[17:50:39] <fuzzie> i guess failure to update UI?
[17:52:16] <fuzzie> lynxlynxlynx: are you still intending to look at the identify thing, or would you prefer somone else do it?
[17:53:11] <lynxlynxlynx> i do intend, but if someone beats me to the punch, that much better
[17:54:18] <lynxlynxlynx> tommorow my work goes back to normal, so i'll have both more energy and time
[17:54:39] <fuzzie> well, we are not in a rush anyway
[17:55:15] <fuzzie> i just thought i'd ask while i was reminded by looking at Beholder's list
[18:00:42] <lynxlynxlynx> it's on my list too ;)
[18:03:00] <lynxlynxlynx> i'll have the friday free, so hopefully i can take care of everything then
[18:04:10] <fuzzie> well, i don't have a list :)
[18:05:36] <lynxlynxlynx> did you disable that immobile check?
[18:05:48] <fuzzie> i did not
[18:07:15] <lynxlynxlynx> any particular reason?
[18:09:21] <fuzzie> just because i changed too much in my tree to 'git add -i' it
[18:09:55] <fuzzie> and i figured there's not much rush while you're busy
[18:10:06] <fuzzie> and things like infinitely-looping worldmap code is more important :)
[18:15:22] <-- adominguez has left IRC (Quit: Saliendo)
[18:15:35] <fuzzie> i completely misunderstood AttackReevaluate i think, too
[18:20:01] --> edheldil_ has joined #GemRb
[18:23:45] <fuzzie> the target is only reevaluated once the target moved beyond attack range, and then it picks a new target every int0Param ticks until it gets in range again or it tried more than 4 times without being in range, in which case it gives up
[18:26:27] <fuzzie> ankheg stuff in here too :/
[18:26:50] <fuzzie> lynxlynxlynx: anyway do you mind that waiting? it is a pain for me to test, i assume
[18:27:33] <-- Maighstir has left #GemRb
[18:27:36] <lynxlynxlynx> i don't mind, but i can also just commit
[18:27:49] <fuzzie> also good
[18:27:59] <lynxlynxlynx> it's been in my tree since the weekend
[18:28:11] <fuzzie> i am testing quite a bit, so ought to notice if it has unexpected effect
[18:28:40] --> Maighstir has joined #GemRb
[18:28:44] <fuzzie> i am half-tempted to push all this new attack code, but it is a bit much :)
[18:29:42] <fuzzie> works a lot better though, subtle stuff
[18:30:04] <fuzzie> also making walking starts slightly out-of-sync, so all your PCs don't look creepy walking identically
[18:31:36] <lynxlynxlynx> nice
[18:32:07] <lynxlynxlynx> i don't know if it was just chance, but on friday all attacks were synced at one point
[18:33:12] --> |Cable| has joined #GemRb
[18:34:25] --> kettuz has joined #GemRb
[18:34:40] <fuzzie> i think that is sort-of chance, but we don't try randomising it
[18:35:00] <-- kettuz has left IRC (Client Quit)
[18:51:05] --> Beh0lder has joined #GemRb
[18:51:17] <Beh0lder> hello all
[18:53:13] <fuzzie> heya
[18:53:31] <fuzzie> i guess we just forgot to update the UI somewhere, for the gray portrait bug
[18:54:15] <fuzzie> i have no idea what original engine does for charmed..
[18:54:20] <Beh0lder> yes, I understand
[18:54:58] <fuzzie> i am busy rewriting all attack code
[18:55:39] <fuzzie> and stupid ankhegs. :P which i suppose are only attack-related bug on your list
[18:57:40] <fuzzie> lynxlynxlynx: btw, casting anim height seems to be per-anim
[18:58:02] <lynxlynxlynx> atleast per avatar anim
[18:58:15] <lynxlynxlynx> something in the vvc unknowns?
[18:58:30] <fuzzie> no, as in, per-avatar-anim
[18:58:56] <lynxlynxlynx> yes, that's pretty obvious - just compare a gnome and a half-ogre
[18:59:11] <fuzzie> there is CGameAnimationType::GetCastHeight and GetCastingOffset
[18:59:15] <fuzzie> we'll have to come up with something
[18:59:21] <lynxlynxlynx> mhm
[18:59:29] <fuzzie> that is not from RE, i just noticed
[19:01:38] <lynxlynxlynx> we have a single hardcoded list now, so there's plenty room for improvement
[19:02:13] <Beh0lder> I found a strange bug with the monster attacks on travel between locations.
[19:02:13] <Beh0lder> Sometimes the monsters appear endless. I can not kill them, have run away. And sometimes I can't attack these monsters, cursor still as hand, when I point on them. This is same as ankheg-attack bug from my list.
[19:02:47] <Beh0lder> sorry for my bad English
[19:12:59] <fuzzie> by endless, you mean there are hundreds of them?
[19:13:09] <fuzzie> i thought we fixed that. :-(
[19:13:23] <-- Maighstir has left IRC (Ping timeout: 255 seconds)
[19:19:31] <Beh0lder> No, after killing some monsters, others appear out of nowhere. No-attack bug appears only for this monsters.
[19:19:45] <Beh0lder> for these)
[19:20:22] <fuzzie> hm, i will look
[19:21:28] <Beh0lder> This bug does not always appear. I think there are difficulties with debugging.
[19:25:30] <fuzzie> aha, i worked out how they do all the fake swing anims, also
[19:27:20] <Beh0lder> I also changed p.14 in my list. Lightning spell has no animation generally, not only spell from wand.
[19:31:15] --> Maighstir has joined #GemRb
[19:32:11] <-- Maighstir has left IRC (Client Quit)
[19:32:39] --> Maighstir has joined #GemRb
[19:49:08] <lynxlynxlynx> fuzzie: do they use the same procedure for ranged attacks?
[19:49:32] <lynxlynxlynx> Beh0lder: yes, that is known; it is a hardcoded graphical effect in the originals
[19:49:33] <fuzzie> yep
[19:49:42] <lynxlynxlynx> cool
[19:49:48] <fuzzie> one single function which calls some PerformAttack type function
[19:50:01] <fuzzie> i'm a bit confused about it
[19:50:09] <fuzzie> maybe you know how attacktype works?
[19:50:26] <fuzzie> it avoids doing the fake swings for ITEM_AT_PROJECTILE
[19:50:51] <fuzzie> but it looks like ITEM_AT_BOW gets you an instant fail before the attack even starts - that is a launcher which you can't attack with?
[19:58:50] <-- edheldil_ has left IRC (Read error: Operation timed out)
[20:09:17] <Beh0lder> bye
[20:10:10] <-- Beh0lder has left IRC (Quit: Beh0lder)
[20:26:10] <CIA-48> GemRB: 03tom.prince * r44570c6ddeaf 10gemrb/gemrb/core/Interface.h: Remove useless trailing ; at class scope.
[20:30:07] <-- Drakkar has left IRC (Quit: The beer is meal.)
[20:31:47] --> Drakkar has joined #GemRb
[20:31:59] <tomprince> clang also complaine about https://gist.github.com/881988
[20:38:27] --> edheldil_ has joined #GemRb
[20:46:45] <fuzzie> well, clang complains about the stupidest things, please do not go on a 'satisfy stupid things clang whines about' hunt :P but those seem fine to fix
[20:53:40] <tomprince> I don't know if I would call them stupid things ... it just has options to check against some simple coding conventions.
[20:53:57] <fuzzie> some of the stuff reported against scummvm has been crazy
[20:54:10] <fuzzie> i mean, the (( stuff makes perfect sense, not talking about that :-)
[20:55:05] <fuzzie> i have not considered the possibility that people have something like -Wreally-dumb-things turned on, though
[20:56:08] <fuzzie> and should maybe try clang-analyzer
[20:56:14] <fuzzie> i mean, on scummvm
[20:56:31] <fuzzie> don't have it built here though
[20:56:35] <fuzzie> erm, on gemrb, dammit
[21:00:24] <tomprince> I'm not sure the analyzer is production quality yet for C++.
[21:00:58] <fuzzie> the results i have seen from the trunk analyzer have been fairly good
[21:19:18] <CIA-48> GemRB: 03lynxlupodian * r6927c404d5a8 10gemrb/gemrb/core/Map.cpp:
[21:19:18] <CIA-48> GemRB: Map::UpdateScripts: don't not-run actor scripts if they are immobile
[21:19:18] <CIA-48> GemRB: the check is too broad and broke at least the start of the ending tob cutscenes
[21:22:29] <tomprince> Should there be a break at Actions.cpp:1755?
[21:22:52] <fuzzie> that line number is out of sync
[21:23:07] <fuzzie> but you mean in StartMusic?
[21:23:16] <tomprince> Yes, case 3
[21:25:52] <fuzzie> ugh
[21:26:01] <fuzzie> well, i mean, obviously that is broken
[21:26:16] <lynxlynxlynx> doh, that identify thing is dead obvious
[21:26:37] <fuzzie> but predictably enough that action is not good :-P
[21:26:43] <fuzzie> feel free to put the break in for now
[21:28:45] <fuzzie> i will get nowhere if i start rewriting at random
[21:41:48] <CIA-48> GemRB: 03lynxlupodian * r970007877c27 10gemrb/gemrb/GUIScripts/GUISTORE.py: GUISTORE: fixed identifying regression from f95b2129ba39
[21:41:58] <fuzzie> :)
[22:05:35] --> Bo_Thomsen has joined #GemRb
[22:16:42] --> SiENcE has joined #GemRb
[22:22:26] <-- Maighstir has left IRC (Quit: ~ Trillian Astra - www.trillian.im ~)
[22:31:04] <CIA-48> GemRB: 03tom.prince * r08d5aca13dcd 10gemrb/gemrb/core/ (GameScript/Actions.cpp Map.cpp):
[22:31:04] <CIA-48> GemRB: clang: Fix things reported by scan-build.
[22:31:04] <CIA-48> GemRB: Everything else is either caught by gcc 4.6 or is due to C++ not being
[22:36:43] <fuzzie> :)
[22:38:43] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[22:48:56] <-- Bo_Thomsen has left IRC (Quit: Leaving.)
[23:19:57] <-- SiENcE has left IRC (Quit: bye)
[23:41:32] <tomprince> Can someone with win32 test https://github.com/downloads/tomprince/gemrb/GemRB-v0.6.2-899-g78568f1.zip
[23:42:08] <tomprince> That should test both my FileStream changes, and my mingw build procdeure.
[23:45:22] <tomprince> (It assumes it is unzip in 'Program Files', you should be able to set paths to convince it otherwise.)