#gemrb@irc.freenode.net logs for 11 Dec 2009 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage

[01:11:08] <-- Maighstir has left #gemrb ()
[01:39:52] --> Maighstir has joined #gemrb
[02:09:42] <-- Maighstir has left #gemrb ()
[08:28:45] --> lynxlynxlynx has joined #gemrb
[08:28:45] --- ChanServ gives channel operator status to lynxlynxlynx
[08:44:17] <-- |Cable| has left IRC (Remote closed the connection)
[10:00:09] --> barra_desktop has joined #gemrb
[12:15:55] --> Maighstir has joined #gemrb
[12:44:00] <-- Maighstir has left IRC (kornbluth.freenode.net irc.freenode.net)
[13:20:59] --> Maighstir has joined #gemrb
[13:36:12] <-- barra_desktop has left IRC (Read error: 104 (Connection reset by peer))
[14:34:36] <-- Maighstir has left #gemrb ()
[16:26:28] <CIA-28> gemrb: 03avenger_teambg * r7448 10/gemrb/trunk/gemrb/plugins/BIKPlayer/ (8 files): bink video code (totally buggy yet)
[19:24:21] --> |Cable| has joined #gemrb
[19:49:04] <-- tombhadAC has left IRC (kornbluth.freenode.net irc.freenode.net)
[19:52:50] --> tombhadAC has joined #GemRb
[19:53:50] <-- tombhadAC has left IRC (SendQ exceeded)
[19:54:44] --> tombhadAC has joined #gemrb
[19:57:43] <-- lynxlynxlynx has left IRC (kornbluth.freenode.net irc.freenode.net)
[19:58:22] --> lynxlynxlynx has joined #gemrb
[19:58:22] --- ChanServ gives channel operator status to lynxlynxlynx
[20:18:07] --> Avenger has joined #gemrb
[20:18:10] --- ChanServ gives channel operator status to Avenger
[20:18:15] <Avenger> wjp are you here?
[20:20:17] <Avenger> the bink video get_bit stuff is most likely correct, i don't know about the transformations, and displaying the yuv planes via SDL is definitely not done.
[20:21:37] <Avenger> i realized i couldn't use the original rgb stuff here, as this is a different bitmap format. SDL has some yuv support, so it is probably simple for someone who knows it
[20:21:53] <fuzzie> it is easy enough to make the SDL Driver display yuv, but that makes it difficult to add any different graphics driver
[20:22:24] <Avenger> at this moment, i don't really care about another display driver. when we are there, we will make a converter, i guess
[20:22:32] <Avenger> hello fuzzie, btw ;)
[20:22:46] <fuzzie> well, i have opengl in the back of my mind, because i think about it for other projects too
[20:22:57] <fuzzie> but yes, i don't think it's worth worrying about, i just mention it
[20:23:24] <Avenger> ffmpeg uses sdl, i was just burn out again while taming the bit scrambler
[20:23:42] <Avenger> i hope someone lends me some hand :)
[20:24:20] <fuzzie> it really is easy to do, sdl just has a SDL_CreateYUVOverlay function
[20:24:53] <Avenger> well, i have some unfinished issues
[20:25:03] <Avenger> 1. the output planes are probably not allocated correctly
[20:25:06] <fuzzie> you just run that, copy the bits into the returned struct, blit the bits using the normal SDL call
[20:25:20] <Avenger> 2. the double buffering code is probably random :)
[20:25:22] <fuzzie> making the bink video have the right bits is maybe harder :)
[20:25:40] <Avenger> the only thing i probably did right is the bit reader
[20:25:55] <Avenger> i know it is right, because it apparently read through the file
[20:26:11] <Avenger> it has some sanity checks which blocked reading through earlier
[20:26:45] <Avenger> until i noticed that get_vlc uses a different get_bits thing, i named it peek_bits
[20:26:55] <Avenger> reads the bits without advancing the bit index
[20:28:52] <Avenger> but if you don't want to mess with the video, try the audio part :) it is much better, i dare to say it has 4 out of 5 score :)
[20:30:20] <Avenger> the cracking artifacts are my fault, if i use the avi converted by ffmpeg, it has no such problem
[20:32:57] <fuzzie> hm
[20:32:59] <fuzzie> how bad are they?
[20:35:34] <wjp> h
[20:35:35] <wjp> i
[20:35:38] <Avenger> it happens when it is loud enough
[20:35:38] <wjp> (oops)
[20:35:43] <Avenger> hi :)
[20:35:44] <fuzzie> i looked at ffmpeg's float->int16 conversion and casting seems like it'd be off by a factor of 100
[20:35:54] <fuzzie> so i'm a bit confused but let me build it and see what it's like
[20:36:14] <Avenger> well, when i debugged it, it seemed to simply convert a float to int
[20:36:25] <wjp> it does an integer math based float->int conversion?
[20:36:28] <fuzzie> does the original *only* support SSE?
[20:36:37] <fuzzie> because the sse function does a different conversion
[20:36:49] <fuzzie> just to be confusing
[20:37:37] <wjp> hm? so maybe the SSE processing code produces different results?
[20:37:45] <fuzzie> the SSE code does a straight cast, in SSE
[20:38:06] <wjp> I believe that's what gcc will typically produce too with a regular cast
[20:38:22] <fuzzie> but the C variant uses a different input range, so it can do some nasty (but fast) logic on the float representation
[20:39:15] <fuzzie> hm, someone on ffmpeg mailing list says it should work fine for the same representation.
[20:39:25] <fuzzie> well, let me try find my iwd2 disc
[20:43:57] <Avenger> the original c code didn't work for me
[20:44:14] <fuzzie> Avenger: what does the original ffmpeg patch use, sse or C?
[20:44:17] <Avenger> the one with the magic cookie f430ffff
[20:44:24] <Avenger> it used sse for me
[20:44:30] <fuzzie> they are different functions which do different things
[20:44:46] <Avenger> the sse code resulted in straight float to int16 conversion
[20:44:50] <Avenger> maybe rounded it
[20:44:59] <Avenger> that's what i debugged
[20:45:04] <fuzzie> sure, that is correct
[20:45:16] <Avenger> i simply printed the float and the int16 values besides each other
[20:45:49] <fuzzie> apparently there is 'simd' (which does cast) and 'c' (which modifies value)
[20:45:50] <Avenger> the original C code caused the badly tuned radio effect
[20:45:58] <fuzzie> and you have to make sure to choose the right one, they don't do te same thing
[20:46:09] <fuzzie> so i wondered if your problem was that you should be using 'c', but i guess not :)
[20:46:25] <Avenger> simd?
[20:46:34] <Avenger> is that an asm instruction?
[20:46:36] <fuzzie> simd is things like SSE, Altivec and MMX
[20:46:50] <fuzzie> 'Single Instruction Multiple Data', i think
[20:47:06] <fuzzie> ok, how i test this, i just point gemrb at iwd2?
[20:47:22] <Avenger> the easiest way is to go to options/play movie
[20:47:30] <Avenger> i use the wotc.mve for testing
[20:47:49] <Avenger> but you can also create a guiscript that plays the movie
[20:48:25] <Avenger> of course, you set up gemrb to iwd2, ahh and add SkipPlugin=libMVEplayer.so
[20:48:41] <Avenger> otherwise it will try to play the bink video with the external binkplayer :)
[20:50:04] <Avenger> probably we will need a more user-friendly code to select (or even autodetect) the movie format
[20:51:44] <tomprince> Easy enough to support with the plugin code that I posted.
[20:51:58] <fuzzie> tomprince: it can check headers?
[20:52:12] <tomprince> Yes.
[20:53:42] <fuzzie> huh. i obviously didn't look close enough :/
[20:54:56] <-- lynxlynxlynx has left IRC (kornbluth.freenode.net irc.freenode.net)
[20:54:57] <-- tomprince has left IRC (kornbluth.freenode.net irc.freenode.net)
[20:54:57] <-- fuzzie has left IRC (kornbluth.freenode.net irc.freenode.net)
[20:54:57] <-- Avenger has left IRC (kornbluth.freenode.net irc.freenode.net)
[20:54:57] <-- tombhadAC has left IRC (kornbluth.freenode.net irc.freenode.net)
[20:54:57] <-- |Cable| has left IRC (kornbluth.freenode.net irc.freenode.net)
[20:54:57] <-- CIA-28 has left IRC (kornbluth.freenode.net irc.freenode.net)
[20:54:57] <-- anji has left IRC (kornbluth.freenode.net irc.freenode.net)
[20:56:34] --> Avenger has joined #GemRb
[20:56:34] --> lynxlynxlynx has joined #GemRb
[20:56:34] --> tombhadAC has joined #GemRb
[20:56:34] --> |Cable| has joined #GemRb
[20:56:34] --> CIA-28 has joined #GemRb
[20:56:34] --> tomprince has joined #GemRb
[20:56:34] --> fuzzie has joined #GemRb
[20:56:34] --> anji has joined #GemRb
[20:58:56] <tomprince> Each plugin registers the extensions that it supports for a given type, and KeyImporter looks through it's search path, and returns first file with a supported extension, or nothing if the header check fails.
[20:58:58] <tomprince> Actually, looking at the code, it reports an error, but keeps looking.
[20:59:54] <tomprince> Although, if it finds a file in a given directory, with the right extension, but that file fails the header check, then it looks in the next directory in its search path, ignoring any files with different extensions in the first directory.
[21:02:12] <-- tombhadAC has left IRC (Network is unreachable)
[21:03:02] <fuzzie> py++ looks like it would be really nice if it didn't come with what amounts to a small pile of dependencies
[21:06:23] <tomprince> That is part of the reason I posted both wrapper generators.
[21:06:34] <tomprince> I know personally I would much rather code against py++.
[21:07:13] <tomprince> It means that you don't need to maintain separate interface definition files.
[21:07:32] <fuzzie> well, you seem to be doing that anyway in the posted patch
[21:08:43] <tomprince> Well, for sip, you need all the .sip files. So far just Table.sip
[21:09:01] <fuzzie> yes. not much fun to keep in sync :/
[21:09:21] <tomprince> For py++, you do need a python program to call py++.
[21:09:55] <tomprince> And if the defaults aren't what you want, you need to change them.
[21:10:04] <tomprince> But you can do that algorithmically.
[21:10:27] <tomprince> I am working on code to wrap Window and Control.
[21:10:51] <tomprince> And I need to specify how to handle the Control* returns from Window.
[21:11:17] <tomprince> And I can just say, for every member function of Window that returns Control*, handle it this way.
[21:11:40] <tomprince> for fn in Window.mem_funs( return_type = pointer_t(declarated_t(Control)) ):
[21:11:52] <tomprince> fn.call_policies = return_value_policy(reference_existing_object)
[21:12:00] <fuzzie> it is kind of depressing how "i wish boost were less miserable to build" goes up on my wishlist every day
[21:15:37] <CIA-28> gemrb: 03avenger_teambg * r7449 10/gemrb/trunk/gemrb/plugins/BIKPlayer/BIKPlay.cpp: some code formatting
[21:15:58] <fuzzie> also "i wish svn would disappear"
[21:16:20] <Avenger> hehe
[21:16:26] <fuzzie> although the world just gave me a project in CVS, so that was a silly wish. :(
[21:16:58] <Avenger> some still use cvs?
[21:18:03] <Avenger> which one do you like?
[21:18:11] <tomprince> git
[21:18:13] <fuzzie> i think everyone except you is using git :-)
[21:18:21] <Avenger> git???
[21:18:30] <Avenger> but it is extremely complicated, no?
[21:18:42] <tomprince> I noticed, when looking at boost, that it now has a cmake based build system.
[21:18:49] <tomprince> No. Not complicated at all.
[21:18:59] <fuzzie> unfortunately cmake's cross-compile support is even worse than bjam's
[21:19:31] <fuzzie> which reminds me that another thing on the todo list is to integrate those automake cross-compile fixes we worked out..
[21:20:05] <fuzzie> Avenger: well, it is more complicated than svn :) but it is worth the half-hour of working it out
[21:20:51] <Avenger> is git available on all the target platforms?
[21:21:16] <fuzzie> sure, but we all just use git on our local machines and the git-svn tool to work with the svn repository, anyway
[21:21:24] <Avenger> well, i wouldn't call haiku, syllable and the other one user OS's target, but...
[21:21:53] <fuzzie> i wouldn't worry about it while development is so quiet..
[21:22:19] <Avenger> well, i remember when wjp moved us to svn
[21:23:04] <Avenger> it was not too complicated, but i was scared before it
[21:23:13] <Avenger> i don't like moving :)
[21:23:52] <fuzzie> i am surprised the bink code compiles on weird platforms, i guess it does nothing special
[21:24:15] <Avenger> what bink code you talk about
[21:24:26] <fuzzie> BIKPlayer
[21:24:32] <Avenger> the one i use is without the processor specific optimisations
[21:24:45] <Avenger> that is pure bit scrambling
[21:25:00] <Avenger> surely it works :) but it is probably slow
[21:25:13] <Avenger> there is no sse/mmx whatever
[21:26:26] <Avenger> btw, i think i have an idea why my version has the cracking sound artifacts
[21:26:44] <Avenger> before converting float to int16, it should check for ceil
[21:26:59] <Avenger> if the value is <-32767, it should be -32768
[21:27:11] <Avenger> likewise with the max value
[21:27:16] <fuzzie> hm
[21:27:19] <tomprince> When I googled the hex constant in the float to int routine, I found this http://archives.free.net.ph/message/20080731.182739.fbc0e654.fr.html , which might be relevant. I don't really know, since I haven't looked at the code in any kind of detail.
[21:27:31] <fuzzie> Avenger, how do I fix the var definitions in 'for' loops thing?
[21:27:35] <fuzzie> do I just move the definition outside the loop?
[21:28:55] <fuzzie> or i leave it alone and let you fix it later?
[21:29:20] <Avenger> tomprince: yes, that's relevant
[21:29:23] <fuzzie> oh, i guess it's not a problem here anyway
[21:29:47] <Avenger> the code i cut out is exactly the weird stuff
[21:30:08] <-- lynxlynxlynx has left IRC (kornbluth.freenode.net irc.freenode.net)
[21:30:17] <Avenger> i don't quite see wtf is that 43c0ffff
[21:30:34] <fuzzie> it's fiddling with the IEEE representation of the float
[21:30:44] <tomprince> If you go further up in the thread, it seems to indicate that before that code is called, you are suppose to scale it and then and 385?
[21:30:47] <Avenger> oh they use another magic number
[21:30:56] <Avenger> and my code used the one they replaced!
[21:30:57] --> lynxlynxlynx has joined #gemrb
[21:30:57] --- ChanServ gives channel operator status to lynxlynxlynx
[21:31:20] <Avenger> how come they didn't apply that change?
[21:31:22] <fuzzie> none of this is relevant, the cast is really the most sensible method for gemrb
[21:31:33] <Avenger> fuzzie: clipping
[21:31:33] <fuzzie> and they'd have to change all the other ffmpeg callers if they applied that change.
[21:32:07] <Avenger> what if the float is <-32768
[21:32:13] <fuzzie> and the bink code assumes you're using the simd variant, which casts anyway, no?
[21:32:13] <Avenger> what happens when i convert it to int16
[21:32:25] <fuzzie> the documentation says the simd one casts, anyhow
[21:32:32] <tomprince> Also http://www.df.lth.se/~john_e/gems/gem0042.html
[21:32:37] <tomprince> from the thread.
[21:33:15] <CIA-28> gemrb: 03fuzzie * r7450 10/gemrb/trunk/gemrb/plugins/KEYImporter/ (KeyImp.cpp KeyImp.h): apply 0001-Create-searchPath-for-KEYImporter-rather-than-a-hard.patch (from tomprince)
[21:34:47] <Avenger> that's not as relevant, we need code that works on all cpu's
[21:34:58] <Avenger> i don't want to steep as low as _asm :)
[21:35:21] <wjp> I vote for just sticking with normal casts :-)
[21:35:30] <Avenger> i just want to get rid of the noise
[21:35:39] <fuzzie> did you try fixing the timing?
[21:35:41] <Avenger> wjp what if the float is <-32768
[21:35:41] <wjp> is there any prescaling going on?
[21:35:43] <Avenger> no
[21:35:57] <Avenger> there is a multiplication by some value, yes
[21:36:03] <tomprince> fuzzie: There are slightly better formated commit messages in the patch header (created with git format-patch). :)
[21:36:08] <Avenger> s_root = 0.0765 or something like that
[21:36:18] <fuzzie> tomprince: heh, a fair point
[21:36:40] <fuzzie> sorry, i am so used to applying patches from cvs/svn recently, i didn't even merge that as a commit, i just used patch..
[21:36:45] <Avenger> i still think it can over and/or underflow
[21:37:15] <Avenger> you could listen to it yourself
[21:38:05] <fuzzie> the over/underflow doesn't seem to happening when it's loud/quiet, though
[21:38:55] <fuzzie> so i would be far more suspicious of the overlapping code..
[21:38:55] <Avenger> there are 2 artifacts
[21:39:06] <Avenger> one is a simple timing of output buffers
[21:39:13] <Avenger> that causes a wobbly sound
[21:39:13] <tomprince> Also, as written, the sound plugin patch depends on the memory allocation patch I posted. Not that there is anything special, just that I didn't add a release function to CSoundReader in readers.h
[21:39:30] <Avenger> the other artifact is when there is a loud sound
[21:39:33] <Avenger> it cracks then
[21:39:47] <Avenger> the wobbly sound is most noticeable with intro.mve
[21:40:27] <Avenger> the cracking sound is noticeable with wotc.mve
[21:42:21] <wjp> I just point gemrb at IWD2, remove the MVEplayer and play the movie from the movies window?
[21:42:31] <Avenger> yes
[21:43:03] <Avenger> if it didn't work, check the plugin loading messages
[21:43:20] <fuzzie> tomprince: i guess someone has to check the exact behaviour of that patch first..
[21:43:42] <fuzzie> and hope that no-one is silly enough to call them in the initialisation, i guewss
[21:44:01] <fuzzie> and hope nothing is doing memory releases in destructors..
[21:44:06] <fuzzie> i suspect that is too much hoping
[21:44:17] <Avenger> no memory release in destructor?
[21:44:18] <wjp> Avenger: ok, it runs here, and I get crackling followed by a crash
[21:44:37] <Avenger> the crash is due to the video code :)
[21:44:47] <Avenger> probably comment out the DecodeVideoFrame call
[21:44:48] <fuzzie> Avenger: nm, i am just pondering possible issues
[21:45:28] <fuzzie> i guess any weird allocation problems would be in gemrb already.
[21:45:49] <tomprince> From what I have read on the net, the problem with allocation is that if the C library is statically linked malloc (and new?) in each module refer to a different free store, so everything needs to released in the same module that allocated it.
[21:46:00] <tomprince> One solution is to dynamically link the C runtime.
[21:46:02] <Avenger> if there is any weird allocation, it is in this new ffmpeg code ;)
[21:46:19] <Avenger> av_malloc is doing 16 byte align allocations
[21:46:28] <Avenger> to support the 'simd' stuff
[21:46:41] <tomprince> Or another, do all the allocations in one module, which is what my patch does, by adding functions in Core that do the allocations.
[21:47:13] <Avenger> tomprince: that is a good idea
[21:47:43] <fuzzie> yes, if you have vc++, Avenger, you should try the patch
[21:47:48] <fuzzie> it is a much simpler way of doing it than any way we came up with befor
[21:47:48] <fuzzie> e
[21:47:49] <Avenger> it screws only vc++ 7
[21:47:49] <Avenger> not msvc6
[21:48:27] <Avenger> i think
[21:52:03] <-- tomprince has left IRC (kornbluth.freenode.net irc.freenode.net)
[21:52:03] <-- fuzzie has left IRC (kornbluth.freenode.net irc.freenode.net)
[21:52:03] <-- lynxlynxlynx has left IRC (kornbluth.freenode.net irc.freenode.net)
[21:52:03] <-- Avenger has left IRC (kornbluth.freenode.net irc.freenode.net)
[21:52:03] <-- |Cable| has left IRC (kornbluth.freenode.net irc.freenode.net)
[21:52:03] <-- CIA-28 has left IRC (kornbluth.freenode.net irc.freenode.net)
[21:52:03] <-- anji has left IRC (kornbluth.freenode.net irc.freenode.net)
[21:54:40] <wjp> that crackling does look like it's caused by int16 overflow
[21:58:43] --> lynxlynxlynx has joined #GemRb
[21:58:43] --> Avenger has joined #GemRb
[21:58:43] --> |Cable| has joined #GemRb
[21:58:43] --> CIA-28 has joined #GemRb
[21:58:43] --> tomprince has joined #GemRb
[21:58:43] --> fuzzie has joined #GemRb
[21:58:43] --> anji has joined #GemRb
[22:00:55] <fuzzie> i hate to use it anywhere where someone is inevitably going to forget the delete[] and it all crashes and burns at random
[22:00:59] <fuzzie> but i guess malloc doesn't really act as a substitute for any of that anyway
[22:01:02] <Avenger> we got valgrind
[22:01:03] <fuzzie> yes, we all love valgrind
[22:01:04] <Avenger> yeah
[22:01:19] <Avenger> note to self: don't forget to use it with this bikplayer...
[22:01:20] <fuzzie> the fact that sip doesn't even come with a windows pre-bulilt binary is not particularly promising for how much of a pain it will be
[22:01:26] <Avenger> i don't know what is sip
[22:01:26] <fuzzie> i will have to try putting together something pre-built and see if it'll work out
[22:01:30] <fuzzie> sip is a tool for writing python APIs
[22:01:33] <fuzzie> it means you don't have to mess around writing every API function individually, it is great
[22:01:37] <fuzzie> but you have to run sip.exe to update the bindings, i am wondering if it will be annoying to do
[22:01:38] <fuzzie> again, i guess i will try making it work
[22:01:41] <Avenger> i hope it isn't gemrb related :D
[22:01:43] <fuzzie> tomprince was looking at fixing our crappy guiscript bindings
[22:01:44] <fuzzie> i am thinking it is too much work, but i'll have to try it
[22:01:45] <tomprince> It will take some time, but it can also be done incrementally.
[22:01:46] <tomprince> And I think the largest part is sepatating the code that is simply python interface, from all the code that deals with game logic.
[22:01:46] <tomprince> Which I think should be done anyway.
[22:01:47] <fuzzie> mmhm
[22:01:47] <fuzzie> moving the logic out of the guiscript entirely as much as possible would be nice
[22:02:04] <fuzzie> trying to pull apart all the magical action bar stuff is a pain, but i keep havingto do it
[22:02:06] <Avenger> well, the best would be if there is NO noticeable python interface :>
[22:02:17] <fuzzie> Avenger: well, that would be the idea :)
[22:02:58] <fuzzie> so you just run some tool, and it updates your .cpp files to provide a python binding directly to the C++ classes
[22:03:28] <Avenger> that will fail, no?
[22:03:34] <fuzzie> tomprince: 0003-Change-core-CDn-to-an-array.patch doesn't work due to your updated KeyImp patch?
[22:03:36] <Avenger> you will need a new dependency in the toolchain
[22:03:45] <fuzzie> Avenger: yes, but maybe a single .exe file to run is worth it
[22:03:49] <tomprince> The first issue I noticed, is that some of the python wrappers call some function and then set a variable, or something similiar. I have a couple patches in my tree that pull that back into core.
[22:04:31] <Avenger> only if it outputs c code that is compiling everywhere where our native c++code does
[22:04:49] <Avenger> so we could simply put that output up in the svn as supplementary code
[22:04:52] <fuzzie> i think sip does that fine
[22:04:56] <fuzzie> yes, that would be the idea
[22:05:14] <fuzzie> we'd have to plonk the sip module code into svn too, but that seems as no problem
[22:05:56] <tomprince> I thought i posted an updated 0003 as well.
[22:06:02] <Avenger> well, i would be happier with a working bink player :P
[22:06:15] <Avenger> the gui stuff is working
[22:06:20] <fuzzie> tomprince: maybe i am using the wrong one.
[22:06:32] <fuzzie> let me re-pull it from sf
[22:07:12] <fuzzie> ah, yes :|
[22:07:34] <fuzzie> Avenger: well, the gui code is kind of a bug-filled mess
[22:07:52] <fuzzie> although mostly because we have everything copied into each game and whenever someone fixes a bug in one game, it doesn't get fixed in the others..
[22:08:32] <Avenger> it has issues, yes, but it mostly affects new code. it is difficult to create bug free guiscript code, but we are mostly through that
[22:08:43] <Avenger> it is definitely not modder friendly
[22:08:47] <fuzzie> well, bg2 is mostly through that :/
[22:08:50] <Avenger> but how Sip would help that???
[22:08:52] <fuzzie> pst is just .. broken
[22:09:06] <fuzzie> but sip would help on the other side, where the interface has bugs
[22:09:17] <Avenger> if the modders need to use sip then recompile the .exe it is a failure
[22:09:51] <Avenger> yep, pst didn't receive enough love
[22:10:02] <fuzzie> well, we have to move some code out of the C and into the python
[22:10:16] <fuzzie> and this means more bindings needed into the core
[22:10:17] <Avenger> eww, i hoped the other way :)
[22:10:26] <fuzzie> but no, you surely don't want to make modders recompile :)
[22:11:00] <Avenger> i don't mind adding new functions. even breaking up the action bar code in C
[22:11:17] <Avenger> but i made it in C especially to make it somewhat stable :)
[22:11:33] <fuzzie> well, we have to rewrite some of it
[22:11:41] <fuzzie> or, well, i'm not sure what on earth to do about InParty yet :(
[22:11:42] <Avenger> pst doesn't even use it
[22:12:22] <fuzzie> but you try doing something with a random actor, with our current GUI code..
[22:12:35] <Avenger> what's wrong about inparty
[22:12:53] <Avenger> what do you want to do with random actors?
[22:13:08] <Avenger> normally you don't :)
[22:13:14] <fuzzie> well, for instance, action bars for controlled/etc actors :)
[22:13:18] <Avenger> hmmm
[22:13:28] <fuzzie> maybe the solution is to put everyone into the party, but that seems very silly.
[22:13:44] <Avenger> no, it should work like the original
[22:14:00] <Avenger> otherwise we will have more problems than we solved
[22:14:51] <Avenger> so we need to address actors whose inparty=0
[22:15:15] <Avenger> we need to access their stats and display action bar
[22:15:18] <Avenger> hmm
[22:15:58] <Avenger> maybe we need a new function
[22:16:03] <fuzzie> so one fix is just to refer to everyone by actor id
[22:16:03] <CIA-28> gemrb: 03fuzzie * r7452 10/gemrb/trunk/gemrb/plugins/ (Core/Interface.cpp Core/Interface.h KEYImporter/KeyImp.cpp): Change core->CDn to an array. (patch by tomprince)
[22:16:06] <Avenger> GetSelectedNPCSingle :)
[22:16:14] <Avenger> returns the actor's global ID
[22:16:43] <Avenger> then you could use the global ID to address actors outside/inside the party
[22:17:00] <Avenger> if it could be done with polymorph functions it would be better
[22:17:24] <Avenger> or, we could always use the global ID, and have a converter function
[22:17:32] --> Maighstir has joined #gemrb
[22:17:34] <tomprince> Or, just return the actor itself, and then the python code could do most anything that C++ code could.
[22:17:43] <Avenger> if we really need InParty it could be converted from the global ID
[22:17:49] <tomprince> Which is the idea behind redoing the python interface.
[22:17:52] <Avenger> tom: you cannot return the actor itself to python
[22:18:04] <fuzzie> well, that is what sip does :-)
[22:18:14] <Avenger> that would be 1. impossible. or if you do it, it would be overblown
[22:18:24] <fuzzie> it just automatically binds everything of the C++ class
[22:18:24] <tomprince> Why?
[22:18:27] <fuzzie> but i am a bit dubious about it
[22:18:28] <Avenger> i guess the global id is what is needed
[22:18:37] <fuzzie> for instance, you'd have to do *so* much error checking somewhere
[22:18:47] <fuzzie> and also, it would be such a huge amount of work to rewrite all the code
[22:19:00] <Avenger> we use the global id internally too, otherwise it would be crashing all the time
[22:19:36] <tomprince> What kind of error checking?
[22:19:50] <Avenger> you cannot pass the whole actor, it is too much data
[22:19:55] <Avenger> so you pass a reference to it
[22:19:57] <fuzzie> Avenger: it just wraps the C++ pointer
[22:20:04] <Avenger> if it is a C pointer, it is crash prone
[22:20:11] <Avenger> so, there comes the global ID
[22:20:13] <fuzzie> in a python class
[22:20:31] <Avenger> that is just a reimplementation of a safe reference (the global ID)
[22:20:39] <Avenger> why have 2
[22:20:39] <fuzzie> that is a good question though, what happens when the underlying C++ object disappears, with sip?
[22:22:01] <tomprince> I think it will probably crash. I am not sure, I havn't done as much research into sip, as compared to py++/boost::python.
[22:22:30] <fuzzie> i think you will never get the py++ dependencies installed even for the core devs
[22:22:30] <tomprince> So you need to be careful about lifetimes.
[22:24:00] <Avenger> you will need to use the queued messages too
[22:24:12] <Avenger> which also use global id in the original engine
[22:24:19] <fuzzie> yes
[22:24:28] <Avenger> otherwise, imagine the case when you equip an item which kills the actor
[22:24:41] <fuzzie> i haven't committed the messages precisely because they use global ids and scriptables don't have them yet..
[22:24:52] <fuzzie> hopefully i can find time before you make bink work :p
[22:24:55] <Avenger> it will crash if the effect is applied without the queued delay
[22:26:21] <Avenger> i hope wjp will help fixing it :)
[22:26:29] <Avenger> but i will try again tomorrow
[22:27:09] <Avenger> actually, i feel i progress nicely with it, considering i don't understand half of that code
[22:32:17] <fuzzie> yes :)
[22:33:29] <fuzzie> hm
[22:33:35] <fuzzie> did someone change the start area code recently?
[22:34:31] <fuzzie> which is to say, arg, who broke the start area code? :_)
[22:35:17] <Avenger> i applied a patch by tom
[22:35:31] <Avenger> so it is broken?
[22:35:33] <fuzzie> it doesn't work for iwd2
[22:35:36] <Avenger> meh
[22:35:43] <fuzzie> i will fix it, i guess, let me work out what goes wrong
[22:36:11] <fuzzie> ah
[22:36:17] <fuzzie> the new code doesn't cope with iwd2 having playmode=2
[22:36:24] <Avenger> hmm
[22:36:34] <fuzzie> it ignores the iwd2 special-casing and tries using the expansion rows of start.2da.
[22:36:47] <Avenger> i think it could be changed back to 1 or 0
[22:37:01] <tomprince> PlayMode means two different things, one is the save dir, and the other is which line in start.2da.
[22:37:03] <fuzzie> changing it in the guiscript to 0 doesn't break anything?
[22:37:05] <Avenger> 0 normal 1 expansion
[22:37:17] <tomprince> I didn't realise that when I posted the patch to create start.2da.
[22:37:26] <fuzzie> we do seem to set playmode specifically for the save dir
[22:37:40] <tomprince> It should really be split into to variables.
[22:37:42] <fuzzie> but we could also just change override/iwd2/start.2da to 'fake' the expansion
[22:38:04] <fuzzie> i was just a bit worried that it was tomprince's other patches, since i started iwd2 and it crashed due to an invalid start area..
[22:38:38] <Avenger> yep, feel free to add a new variable
[22:39:05] <Avenger> fuzzie, change, start.2da is in gemrb override
[22:39:21] <Avenger> actually, playmode=2 should work
[22:39:47] <Avenger> const char *mode[3] = { "NORMAL", "TUTORIAL", "EXPANSION" }
[22:39:55] <Avenger> so playmode 2 means 'expansion'
[22:39:56] <fuzzie> yes, but then it looks at the EXPANSION row in start.2da
[22:40:01] <Avenger> and start.2da has expansion row
[22:40:05] <Avenger> oh
[22:40:07] <fuzzie> and that looks at START_AREA_EXPANSION
[22:40:10] <Avenger> and you want normal
[22:40:12] <fuzzie> and that crashes, since that is a made-up area.
[22:40:25] <fuzzie> so i just propose changing start.2da to point at START_AREA in the EXPANSION row?
[22:40:44] <Avenger> aah iwd2 has no expansion
[22:40:48] <Avenger> hehe
[22:40:56] <fuzzie> it seems harmless to change it, and it works fine
[22:41:05] <fuzzie> and maybe tomprince volunteers to split the variables in another patch :)
[22:41:15] <Avenger> well, it is an ugly hack but you can get away with it
[22:42:03] <fuzzie> ok.
[22:42:19] <Avenger> it is not uglier than i did before the start.2da patch
[22:42:41] <CIA-28> gemrb: 03fuzzie * r7453 10/gemrb/trunk/gemrb/override/iwd2/start.2da: add an ugly hack for now to iwd2's start.2da to avoid using the (invalid) expansion rows
[22:43:26] <Avenger> i blame the bioware/blackisle people. they couldn't settle what mpsave means. It could be mission pack, or multi player
[22:43:56] <Avenger> mission pack=expansion
[22:44:09] <Avenger> bg1 uses it in the mission pack sense
[22:44:34] <Maighstir> also multiplayer, no?
[22:45:25] <Avenger> i dont know
[22:46:00] <fuzzie> it's been too long since bg1 multiplayer for me :)
[22:46:23] <fuzzie> i am not wanting to apply this allocation patch unless i know it works in vc6
[22:46:43] <Avenger> fuzzie, you just break it for me
[22:46:57] <Avenger> so, if it works in vc7, then kill me ;)
[22:47:09] <fuzzie> ok. will try and find time to test that.
[22:47:11] <Avenger> i will see it soon anyway
[22:50:38] <Maighstir> saving a game in singleplayer bg1 saves in \save, saving in multiplayer saves in \mpsave
[22:50:55] <fuzzie> Maighstir: what about totsc?
[22:51:06] <Maighstir> yes, totsc
[22:51:18] <Maighstir> I don't have vanilla installed
[22:51:36] <fuzzie> oh, right, there's no expansion mode in bg1
[22:52:17] <Maighstir> though the mission pack save added with the totsc install sits in \mpsave
[22:53:40] <Maighstir> it can of course be copied to \save and loaded in singleplayer
[22:55:20] <fuzzie> tomprince: 0004-Refactor-KeyImp.patch is missing a 'break;' after the CBF check?
[22:55:25] <fuzzie> erm, a 'return;', even
[22:57:12] <Avenger> so it is more like multiplayer?
[22:57:39] <fuzzie> and you removed the GameOnCD check in that function, i guess
[22:57:48] <Avenger> well i gotta go, see you tomorrow
[22:57:51] <fuzzie> bye!
[22:57:52] <-- Avenger has left IRC ("bye!")
[22:58:08] <Maighstir> seemingly so, I'm testing in bg2 at the moment, which can be started as only expansion
[22:59:30] <tomprince> Yes.
[23:00:01] <tomprince> It is missing a return. Must not have tested against cbf.
[23:00:22] <tomprince> The GameOnCD check is still done inf GetResource.
[23:01:32] <tomprince> Although it wouldn't hurt to move it to FindBIFOnCD.
[23:01:45] <fuzzie> well, if you pick a preference :)
[23:02:07] <fuzzie> you also removed the word masking without removing the comment, which is a little confusing
[23:03:36] --> tombhadAC has joined #gemrb
[23:03:49] <fuzzie> so my proposal is that i put the mask back (i guess it gets removed momentarily anyway?), i add the 'return;', and i commit that
[23:05:53] <tomprince> Yes.
[23:08:11] <CIA-28> gemrb: 03fuzzie * r7454 10/gemrb/trunk/gemrb/plugins/KEYImporter/ (KeyImp.cpp KeyImp.h):
[23:08:11] <CIA-28> gemrb: patch by tomprince:
[23:08:11] <CIA-28> gemrb: - Split out checking for biffs into separate functions.
[23:08:11] <CIA-28> gemrb: - Only look for biffs once, unless GameOnCD == 1.
[23:08:11] <CIA-28> gemrb: - Run everything through ResolveFilePath.
[23:11:47] <Maighstir> so... testing in bg2, I get the same results in expansion-only, and starting from the beginning in irenicus' dungeon: multiplayer saves sits in mpsave, and singleplayer in save
[23:11:59] <Maighstir> I have not tried on an install without the expansion at all, but I'm pretty sure the results would be the same there as well
[23:12:18] <fuzzie> yes
[23:12:51] <fuzzie> but i think the mpsave thing is more of a bioware/blackisle disagreement, so you'd hope bioware are internally consistent. nice to have it confirmed ,though
[23:17:27] <-- lynxlynxlynx has left IRC (Remote closed the connection)
[23:21:43] <tomprince> https://sourceforge.net/tracker/?func=detail&aid=2906455&group_id=10122&atid=110122
[23:22:03] <tomprince> The C++ code works. I have *no* idea if the GUIScript code is anything close to correct.
[23:22:15] <tomprince> It *seems* to work for bg2.
[23:30:42] <Maighstir> Icewind Dale treats everything as multiplayer, and puts all saves in mpsave, no matter whether they're started as single or multiplayer, or whether it's "full game" or "expansion only" - since the game is much more multiplayer centered than the baldur's gate series, I still think mpsave stands for multiplayer
[23:36:46] <Maighstir> Same for iwd2 - multi and singleplayer sits in the same directory: mpsave
[23:42:11] <Maighstir> planescape torment, not having a multiplayer component (or an expansion, for that matter) saves in "save"