#gemrb@irc.freenode.net logs for 9 Aug 2009 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage

[00:09:50] <-- tombhadAC has left IRC ("Verlassend")
[00:14:18] --> tombhadAC has joined #gemrb
[00:23:18] <-- tombhadAC has left IRC (Remote closed the connection)
[01:55:55] --> pupnik has joined #gemrb
[02:12:12] <-- pupnik_ has left IRC (Read error: 101 (Network is unreachable))
[02:45:02] <-- xrogaan has left IRC ("Why ?")
[03:25:55] --> xrogaan has joined #gemrb
[05:45:04] --> Gekz_ has joined #GemRB
[06:02:08] <-- Gekz has left IRC (Read error: 110 (Connection timed out))
[06:27:07] --- Gekz_ is now known as Gekz
[06:35:01] <-- xrogaan has left IRC ("Why ?")
[08:36:18] --> tombhadAC has joined #gemrb
[09:02:15] <-- Gekz has left IRC (Read error: 104 (Connection reset by peer))
[09:05:31] --> Gekz has joined #GemRB
[09:34:30] --> lynxlynxlynx has joined #gemrb
[09:34:30] --- ChanServ gives channel operator status to lynxlynxlynx
[10:49:30] <-- Gekz has left IRC ("Lost terminal")
[10:49:42] --> Gekz has joined #GemRB
[11:53:55] --> barra_away has joined #gemrb
[11:58:05] --- barra_away is now known as barra_cooking
[12:08:12] <-- dawid has left IRC (Nick collision from services.)
[12:08:15] --> dawid1 has joined #GemRb
[12:08:35] --- dawid1 is now known as dawid
[12:11:27] <-- barraAway has left IRC (Read error: 110 (Connection timed out))
[12:13:23] <-- pupnik has left IRC (Read error: 110 (Connection timed out))
[12:52:04] --- barra_cooking is now known as barra_home
[14:36:31] --> xrogaan has joined #gemrb
[15:10:52] --> zear has joined #gemrb
[15:11:13] <zear> hello there
[15:11:26] <zear> i'm trying to crosscompile gemrb for freerunner
[15:11:36] <zear> and i'm stucked at the configure script
[15:11:48] <zear> checking if Python version >= 2.3.0... too old
[15:11:49] <zear> configure: error:
[15:11:49] <zear> *** You need Python (www.python.org) version 2.3.0 or greater to compile GemRB
[15:12:08] <zear> however python in my freerunner toolchain is:
[15:12:09] <zear> Package libpython2.5-1.0 (2.5.2-ml10) installed in root is up to date
[15:12:44] <fuzzie> hrm
[15:12:48] <zear> any way i can skip the python version detection?
[15:13:00] <zear> or maybe it doesn't see it for a reason and i'm doing something wrong? :D
[15:13:07] <lynxlynxlynx> i'll look into it
[15:13:19] <lynxlynxlynx> you can check your config.log why it failed
[15:13:36] <fuzzie> i imagine it will fail because it tries actually running the python install to get the version
[15:14:02] <zear> ah, then it won't be able to
[15:14:05] <fuzzie> just removing the version number from configure.in is probably enough to make it pass
[15:14:06] <zear> as it's arm binary
[15:14:21] <lynxlynxlynx> yes, it runs python
[15:14:57] <zear> hehe, exactly:
[15:14:58] <zear> configure:22076: checking if Python version >= 2.3.0
[15:14:58] <zear> ./configure: line 22093: /usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/usr/bin/python: cannot execute binary file
[15:15:42] <fuzzie> i was going to give you the standard warning about gemrb being useless on phones due to the resolution
[15:15:51] <fuzzie> but the freerunner is 640x480?
[15:16:21] <zear> yes, it's 640x480, is it not enough?
[15:16:25] <fuzzie> that is fine
[15:18:20] <zear> do i need to rebuild configure or something after i alter configure.in? because i commented out all the python detection lines and it's still bugging about it
[15:18:33] <fuzzie> if you just comment out the lines, i don't think gemrb will build
[15:18:37] <fuzzie> but yes, you have to re-run autogen.sh
[15:19:05] <fuzzie> that AM_PATH_PYTHON we ship really is a stupid one
[15:19:33] <zear> so i just need to comment out this only line?
[15:19:45] <fuzzie> if you don't pass it a version number then it still fails because it tries running the python install again to print sys.version
[15:20:32] <zear> sorry for asking for such a trivial things, but how can i do it the right way then?
[15:22:52] <fuzzie> if you edit configure.in to remove the '2.3.0,' bit from AM_PATH_PYTHON, that should get you past the version check
[15:23:33] <fuzzie> and then editing acinclude.m4 to change the PYTHON_VERSION setting (line 342) to be hard-coded (PYTHON_VERSION='2.5' should suffice) might work?
[15:23:38] <fuzzie> lynxlynxlynx might have better ideas
[15:23:57] <zear> ok, thank you very much for the help
[15:24:04] <fuzzie> i don't have a cross-compile environment setup with python so i can't try myself right now, sorry
[15:24:06] <zear> hope i'll manage to compile it this time ;)
[15:24:39] <fuzzie> but it should be okay once you get past that bit :-) there's a configure flag to disable the openal testing if you need it
[16:21:51] --> D_T_G has joined #gemrb
[16:22:02] <D_T_G> hi
[16:52:10] <-- D_T_G has left IRC ()
[16:53:59] <zear> fuzzie, nah, this doesn't work.. "./configure: line 26410: 2.5: command not found", and additionally it now botheres about python headers
[16:55:37] <zear> well, at least now i know what's wrong
[16:55:52] <fuzzie> odd.. you're sure you did '2.5' and not `2.5`?
[16:56:42] <zear> tried both
[16:56:43] <fuzzie> and, right, the includes/libs does a python execute too :/
[16:57:11] <fuzzie> i expect we can probably find some more sensible macros somewhere
[16:57:56] <zear> btw do gemrb games use right mouse button a lot?
[16:58:17] <fuzzie> you can play without, i think
[17:00:40] <fuzzie> the right button is used to get the information about items/dialogs, but you could have an alternative for that
[17:00:49] <zear> uh, sorry, with '2.5' it get's throught the version detection, but still crashes as headers detection
[17:01:14] <zear> *at
[17:02:50] <fuzzie> to get further, I think you have to manually define those PYTHON_INCLUDES and PYTHON_LIBS variables, commenting out the code which tries doing it using python
[17:03:43] <zear> in configure.in or acinclude.m4?
[17:04:18] <fuzzie> well, configure.in is maybe easiest :) but you'd need to look at acinclude.m4 to see what they're meant to be
[17:04:40] <zear> i think this can be done in acinclude.m4, let me see
[17:06:28] --> zefklop has joined #gemrb
[17:09:29] <zear> uh, i see i have a bigger problem now as i don't have {toolchain}/usr/include/python2.5/
[17:10:47] <fuzzie> and nothing similar? if you can't build against python then indeed it won't work :)
[17:11:08] <zear> nope, just /usr/lib/python2.5
[17:11:16] <lynxlynxlynx> if you know cmake, you could try crosscompiling with that as an alternative, but i'm not certain arm is supported
[17:11:45] <zear> i must check if there is python developement package in fr repo
[17:11:52] <lynxlynxlynx> but you definitely need the python headers
[17:12:32] <zear> can't i copy them from my x86 build? Or they need to be crosscompiled?
[17:13:17] <fuzzie> you can copy them from your x86 build, but if you don't have the includes you probably don't have the development libraries either
[17:13:42] <fuzzie> check for /usr/lib/libpython2.5.so
[17:14:13] <zear> oh i do
[17:15:05] <zear> so if i have {toolchain}/usr/lib/libpython2.5*, it should work with x86 includes?
[17:16:54] <zear> ok, nevermind, luckily i found a python-devel package in the repo
[17:17:11] <zear> installed it and now i have {toolchain}/usr/include/python2.5
[17:18:40] --> pupnik has joined #gemrb
[17:20:06] <zefklop> hi everyone
[17:21:09] <fuzzie> hi, zear
[17:21:11] <fuzzie> um, zefklop :)
[17:21:25] <zefklop> lol
[17:21:26] <zear> :P
[17:21:47] <zear> ok, it looks like the configure passed throught the python detection
[17:22:29] <fuzzie> gemrb does build on arm, but no-one's tried cross-compiling, as you can tell
[17:22:37] <zear> :D
[17:22:59] <zear> so it was build natively on that nokia phone or whatever that photo was of? ;)
[17:23:14] <zear> *built
[17:26:54] <fuzzie> yes
[17:26:59] <zefklop> build environment on a phone?
[17:27:08] <zefklop> woaw, one must be patient
[17:27:11] <fuzzie> i built it on android also
[17:27:31] <zear> android? but isn't it java-only?
[17:27:53] <fuzzie> no, you can build native code on it too
[17:28:58] <fuzzie> in order to work with the rest of the android GUI, your GUI has to be in java, though
[17:29:22] <fuzzie> i never got it working because i don't have an android device with 640x480 resolution :) but it built
[17:29:57] <zear> aren't there any scaling functions in sdl_gfx that could scale the video output down to 320x240?
[17:30:27] <zear> it would be great to be able to run gemrb on gp2x, wiz and dingoo handhelds ;)
[17:39:41] <fuzzie> i think it would be far too small
[17:39:46] <fuzzie> it should work on pandora, though
[17:40:02] <fuzzie> and someone could always make another GUI for the games which works at 480x320..
[17:45:35] <zear> hmm..
[17:45:35] <zear> config.status: creating config.h
[17:45:35] <zear> config.status: linking ././fnmatch_.h to ./fnmatch.h
[17:45:35] <zear> config.status: error: ././fnmatch_.h: file not found
[18:06:23] <fuzzie> strange
[18:07:50] <fuzzie> i wonder if that's some system-wide thing?
[18:09:12] <lynxlynxlynx> here one was provided by gcc and the main one is from glibc
[18:09:42] <lynxlynxlynx> (the gcc one is only there at build time)
[18:13:51] <-- pupnik has left IRC ("leaving")
[18:15:07] <-- zefklop has left IRC (Read error: 113 (No route to host))
[18:17:55] <-- xrogaan has left IRC ("Why ?")
[18:50:33] <Edheldil> ./fnmatch.h does not look right, does it?
[18:51:47] <fuzzie> it does seem to match the path in my config file for when there's no system-wide one
[18:51:53] <fuzzie> but i don't understand autoconf
[18:51:56] <fuzzie> also, hi, Edheldil!
[18:52:02] <fuzzie> i have some ie_shell problems, if you have time
[18:54:27] <Edheldil> yes, sure
[18:54:56] <Edheldil> hi, fuzzie et others
[18:55:02] <fuzzie> it fails to read some bg2 areas due to problems in the automap code - if i comment out the automap code, it works
[18:55:35] <Edheldil> what area?
[18:55:48] <fuzzie> and if i do iterate_objects_by_type(0x03f2, test) on a ToB install, it throws an exception when encountering the non-existant XR2400 and stops iterating :/
[18:56:38] <Edheldil> hehe. Is not there already possibility to specify error_fn?
[18:56:46] <Edheldil> to '
[18:56:46] <Edheldil> i
[18:56:46] <fuzzie> well, AR0202 is an example, but i think any area with automap_note entries fails
[18:57:08] <Edheldil> gnore' or+ s+t++.+ -li-k-e *th/aty/*-
[18:57:26] <fuzzie> well, i didn't work out how it all worked, it's just impossible to iterate over all areas without an error_fn, so i thought i'd say
[18:57:35] <Edheldil> oops, my little pixie is interfering with the kbd
[18:58:26] <Edheldil> ok, I will look into it.
[18:58:42] <fuzzie> the error thing is obviously not important though..
[18:58:55] <fuzzie> the automap_note thing is a bit more so, maybe :)
[18:58:59] <fuzzie> but both are simple to work around
[18:59:44] <Edheldil> I *think* you can call iterate_objects(... error_fn='ignore') to ignore errors outside your callback fn
[19:00:18] <zear> is that error of mine (fnmatch.h) an important one? Makefile has been created anyway
[19:00:32] <Edheldil> no idea :)
[19:00:48] <fuzzie> zear: do you have a system fnmatch.h file?
[19:00:50] <zear> now i have problems with malloc and realloc when i try to build it
[19:00:58] <zear> in /usr/include ?
[19:01:04] <fuzzie> you do need a fnmatch.h somewhere in order to build gemrb
[19:01:16] <-- dawid has left IRC ("Not leaving, quitting.")
[19:01:44] <Edheldil> zear, if you succeed (or get stuck), please write about the things you did etc. It would be a good stuff for our wiki
[19:01:46] <zear> yep, i have it in {toolchain}/usr/include
[19:01:56] <zear> sure, i will\
[19:02:01] <fuzzie> then i think it's fine
[19:02:24] <zear> oh, and just to know: am i bothering you guys too much with my problems? :)
[19:02:29] <fuzzie> malloc/realloc problems sound strange, you would think that would be one of the simplest things
[19:02:35] <zear> i hope i'm not, but just to know if i should ask about every single error ;)
[19:02:41] <fuzzie> well, i am glad to see someone trying
[19:02:50] <fuzzie> Edheldil: setting error_fn doesn't help i'm afraid
[19:03:01] <zear> i remember there was some workaround for mallocs problems with exporting some variables
[19:03:04] <zear> must google for it
[19:04:05] <fuzzie> Edheldil: it dies on stream.py:333, where self.filename is None, if that helps..
[19:04:41] --> dawid has joined #GemRb
[19:04:53] <zear> the exact problem with malloc is:
[19:04:54] <zear> /usr/local/openmoko/arm/arm-angstrom-linux-gnueabi//usr/include/c++/cstdlib:122: error: '::malloc' has not been declared
[19:04:54] <zear> /usr/local/openmoko/arm/arm-angstrom-linux-gnueabi//usr/include/c++/cstdlib:130: error: '::realloc' has not been declared
[19:05:16] <fuzzie> hm, that doesn't look like our bug
[19:05:32] <fuzzie> sounds more like a freerunner-specific one
[19:05:42] <zear> yeah, maybe i can configure it with no malloc or something
[19:06:05] <zear> (i don't really know what malloc is or what it does, but i remember disabling it once for gp2x crosscompilation)
[19:06:17] <-- tombhadAC has left IRC (Read error: 101 (Network is unreachable))
[19:06:26] <fuzzie> well, you need malloc for gemrb, but it is an essential function and must exist somewhere
[19:06:53] <fuzzie> the problem is presumably that those C++ include files are trying to use malloc without having included the malloc include files first
[19:07:29] --> tombhadAC has joined #gemrb
[19:08:06] <zear> uh, sounds complicated
[19:08:47] <fuzzie> malloc is the C 'memory allocation' function, so without it you do not get very far
[19:13:06] <fuzzie> that error is very strange though, it should only happen when you have bad include files
[19:14:35] <zear> export ac_cv_func_malloc_0_nonnull=yes eliminated the problem with malloc
[19:14:41] <zear> now the same for realloc
[19:20:03] <zear> hmm.. is there a way i can set configure to not put -Werror in the makefiles?
[19:20:08] <fuzzie> yes
[19:20:23] <zear> there are lots of warnings during the compilation and it stops every time :D
[19:20:24] <fuzzie> it's at the bottom of configure.in
[19:20:36] <fuzzie> remove both of them and it should be gone
[19:22:59] <wjp> huh, weird
[19:23:15] <wjp> especially since cstdlib _is_ the file to include for malloc
[19:23:18] <fuzzie> we already know gemrb is not warning-clean on platforms which care about alignment etc
[19:23:34] <fuzzie> wjp: supposedly there's some kind of problem with stdlib.h not providing it as a non-macro
[19:23:43] <fuzzie> and the g++ cstdlib #undefs the macro form
[19:24:12] <fuzzie> but i have no idea what ac_cv_func_malloc_0_nonnull does, it looks .. scary
[19:25:29] <wjp> it checks the return value of malloc(0)
[19:26:00] <wjp> I'm rather surprised it has any effect
[19:32:59] --> zefklop has joined #gemrb
[19:33:36] <zear> hmm.. i almost built it
[19:33:46] <zear> it seem to have problems with lib pathes
[19:33:55] <zear> grep: /usr/lib/libz.la: No such file or directory
[19:33:55] <zear> /bin/sed: can't read /usr/lib/libz.la: No such file or directory
[19:33:55] <zear> libtool: link: `/usr/lib/libz.la' is not a valid libtool archive
[19:34:04] <zear> i have no idea why it looks in /usr/lib
[19:34:19] <zear> my configure line is:
[19:34:19] <zear> ./configure --host=arm-angstrom-linux-gnueabi --target=arm-angstrom-linux-gnueabi --prefix=/usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/usr/ LDFLAGS=-L/usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/usr/lib LIBS=-L/usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/usr/lib
[19:34:50] <wjp> maybe a .la file has /usr/lib hardcoded in it?
[19:35:04] <zear> there's no such file ;)
[19:35:13] <wjp> ?
[19:35:16] <zear> but it shouldn't be looking in /usr/lib
[19:35:28] <zear> but rather in {toolchain}/usr/lib
[19:35:45] <wjp> which is why I asked if some .la file could have /usr/lib hardcoded in it
[19:35:51] <zear> ah
[19:35:58] <zear> could be
[19:36:12] <wjp> (they're text files)
[19:36:16] <zear> yeah, i know
[19:36:50] <zear> and it looks like you were right
[19:36:50] <zear> dependency_libs=' -L/usr/lib'
[19:36:53] <zear> i guess that's it
[19:39:23] <zear> nah, still the same error
[19:41:22] <fuzzie> what are the LDFLAGS, PYTHON_LIBS and SDL_LIBS variables in the Makefile set to?
[19:42:09] <zear> python_libs are set by me manually to {toolchain}/usr/lib/python2.5
[19:42:18] <zear> you can see the LDFLAGS in my message above
[19:42:35] <zear> and SDL_LIBS are brobably set by {toolchain}/bin/sdl-config
[19:42:53] <zear> there's no problem with them anyway
[19:44:22] <zear> i did an ugly workaround and copied my toolchain libz.la to /usr/lib
[19:44:26] <fuzzie> well, i just ask because that's where my library search path comes from
[19:44:29] <zear> make passed through it
[19:44:48] <zear> but now it looks in the same place for other .la file
[19:44:57] <zear> so i guess some path in the makefile is set incorrectly
[19:47:06] <fuzzie> if those three variables are fine, they should be the only paths there..
[19:47:23] <zear> hmm..
[19:47:23] <zear> SDL_CONFIG = /usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/usr//bin/sdl-config
[19:47:24] <zear> SDL_LIBS = -L/usr/lib -Wl,-rpath,/usr/lib -lSDL -lpthread
[19:47:35] <zear> looks like sdl-config sets the incorrect lib path
[19:49:56] <zear> ok, forced it with --with-sdl-prefix, hope now it will build
[19:50:40] <-- dawid has left IRC (Read error: 104 (Connection reset by peer))
[19:51:46] <zear> nope, same error (yeah, zlib isn't sdl related)
[19:52:07] <fuzzie> well, if
[19:52:18] <fuzzie> if SDL_LIBS is including /usr/lib, then it will look there for zlib
[19:53:00] <wjp> hm, doesn't it use with-sdl-prefix to locate sdl-config?
[19:53:07] <fuzzie> it looks like sdl-config has the prefix hard-coded (it is a shell script)
[19:53:08] <wjp> if your sdl-config returns the wrong parameters, you should just fix that
[19:53:14] <fuzzie> so you should be able to just change that prefix= line
[19:53:17] <fuzzie> also what wjp said :-)
[19:54:04] <zear> yeah
[19:54:22] <zear> but i haven't had any problems with sdl-config before
[19:54:34] <zear> and i've built few sdl apps for fr before
[19:55:15] <fuzzie> maybe the other apps didn't use sdl-config? it seems pretty hard-coded..
[19:55:37] <zear> hmm.. could be
[19:55:47] <zear> yeah, i can see the prefix in sdl-config is wrong
[19:57:14] <zear> heh, weird but i still have SDL_LIBS = -L/usr/lib in the makefile
[19:58:02] <-- lynxlynxlynx has left IRC (Remote closed the connection)
[20:00:34] <fuzzie> configure might be caching the result somewhere? SDL_LIBS comes directly from that SDL_CONFIG call .. do you get the right result if you call 'sdl-config --libs' yourself?
[20:00:44] <zear> ah, because the whole sdl-config is screwed up
[20:00:47] <zear> not only the prefix var ;)
[20:01:25] <fuzzie> ah. my sdl-config only uses the prefix var, but i guess everyone changes it
[20:02:27] <zear> ok, is set the right pathes this time
[20:02:31] <zear> let's hope it will compile
[20:03:26] <zear> same error again.. :P
[20:03:38] --> dawid has joined #GemRb
[20:04:10] <zear> but i can see in the makefile a line like this:
[20:04:12] <zear> LDFLAGS = -L/usr/local/openmoko/arm/arm-angstrom-linux-gnueabi/usr/lib -L/usr/lib
[20:04:19] <zear> that's the last /usr/lib i can find in makefile
[20:06:20] <fuzzie> that is due to LDFLAGS="$LDFLAGS -L${ZLIB_HOME}/lib"
[20:06:33] <fuzzie> do you pass --with-zlib to configure with the openmoko prefix?
[20:06:40] <zear> nope
[20:06:41] <zear> ah
[20:06:46] <fuzzie> apparently that is needed
[20:09:19] <zear> that doesn't help
[20:09:28] <zear> can i use --without-zlib flag?
[20:09:48] <fuzzie> i don't think any games will work without zlib
[20:10:16] <fuzzie> ok, acinclude.m4 has a ZLIB_HOME=/usr/local
[20:10:20] <fuzzie> that needs commenting out
[20:11:19] <zear> ah, thanks
[20:11:31] <fuzzie> well, i assume that is it .. i don't know m4 syntax
[20:14:27] <zear> nah, it is still looking for zlib in /usr/lib
[20:15:01] <zear> (and that's not only zlib error, remember i put a libz.la there before and it was looking for another .la files in that dir too)
[20:15:11] <fuzzie> well, you need to get rid of any mentions of /usr/lib in Makefile
[20:15:17] <fuzzie> 'grep /usr/lib Makefile' should make them all obvious
[20:15:36] <fuzzie> until they're gone, it will look there for everything
[20:15:42] <wjp> what was the .la file in which you found that dependency_libs=' -L/usr/lib'
[20:15:43] <wjp> ?
[20:16:04] <zear> libz from fr toolchain
[20:23:11] <zear> ok, i have to go, will try to port it yet tomorrow ;)
[20:23:39] <zear> thanks for your help people
[20:23:48] <-- zear has left #gemrb ("Leaving")
[20:36:44] <-- tombhadAC has left IRC ("Verlassend")
[20:37:57] --> tombhadAC has joined #gemrb
[20:48:30] --> pupnik has joined #gemrb
[21:12:15] <zefklop> uh
[21:12:27] <zefklop> when you call this in a script
[21:12:55] <zefklop> a cutscene one
[21:12:59] <zefklop> CutSceneId("tester2")
[21:13:01] <zefklop> Wait(5)
[21:13:02] <zefklop> DisplayString(Myself, ~Now I am going elsewhere~)
[21:13:04] <zefklop> MoveToPoint([1375.510])
[21:13:19] <zefklop> tester2 is myself right?
[21:16:48] <fuzzie> yes
[21:17:18] <zefklop> when calling this:
[21:17:41] <zefklop> IF
[21:17:43] <zefklop> True()
[21:17:45] <zefklop> THEN
[21:17:46] <zefklop> RESPONSE #100
[21:17:48] <zefklop> Wait(5)
[21:17:49] <zefklop> DisplayString("tester1", ~CutSceneId being called~)
[21:17:52] <zefklop> CutSceneId("tester2")
[21:17:52] <zefklop> Wait(5)
[21:17:54] <zefklop> DisplayString(Myself, ~Now I am going elsewhere~)
[21:17:56] <zefklop> MoveToPoint([1375.510])
[21:17:57] <zefklop> ActionOverride("Tester1", Dialogue(Player1))
[21:17:59] <zefklop> END
[21:18:00] <zefklop> Myself is player1...
[21:18:24] <zefklop> ok, nobody did that before, but it is quite surprising
[21:18:26] <fuzzie> are you calling that as a cutscene?
[21:18:30] <zefklop> yes!
[21:18:32] <fuzzie> if so, then "tester1" is the cutsceneid being used
[21:18:39] <fuzzie> this was documented in your thread on the forum
[21:18:50] <fuzzie> but i checked existing scripts and no-one uses that hack
[21:19:42] <fuzzie> so i hope we don't have to implement, it would be quite horrible
[21:19:48] <zefklop> what do you mean by "tester1" is the cutsceneid being used
[21:20:23] <fuzzie> the cutscene code in the original engine doesn't pay attention to the cutsceneid, it just uses the first named object
[21:20:28] <fuzzie> at least, this is what was said on the forum
[21:20:41] <zefklop> when I say i never named player1
[21:20:45] <zefklop> oops
[21:20:52] <zefklop> i never named player1
[21:21:19] <fuzzie> oh, you mean, it's interesting that it defaults to player1?
[21:21:23] <zefklop> and player1 says "I am going elsewhere" and then goes to the point
[21:21:44] <zefklop> i say that it is surprising
[21:21:49] <fuzzie> i mean, there is no named object in that first line, so it has to pick someone, i guess :)
[21:21:52] <fuzzie> but it is new information
[21:22:53] <zefklop> and then it completely ignores the cutsceneid call
[21:23:38] <fuzzie> but the cutsceneid implementation in gemrb is better, if there are no script incompatibilities
[21:23:50] <fuzzie> did you work out the action/queue behaviour at all, yet?
[21:24:26] <zefklop> that was the purpose of this script...
[21:24:41] <fuzzie> i know, i am just curious if you found it :)
[21:25:02] <zefklop> let me 5 minutes!!
[21:25:08] <fuzzie> hehe, ok
[21:25:29] <fuzzie> can i help? i can install bg1 now, i think
[21:33:18] <zefklop> I'll upload a new version of te test pack a moment
[21:36:37] <zefklop> wow, that is even better!
[21:36:43] <pupnik> :)
[21:37:04] <zefklop> I think I'll write it at g3 :-)
[21:37:27] <zefklop> first, upload the zip file!
[21:37:44] <fuzzie> the trouble with testing things like this is making sure the conclusions are right
[21:37:50] <-- barra_home has left IRC ("Verlassend")
[21:37:53] <fuzzie> often i test something and then it turns out that it's different when i change something..
[21:38:22] <fuzzie> bg2's AttackReevaluate was quite like that, it seems like it does nothing at first
[21:38:28] <zefklop> that's why I give you the zip :-)
[21:39:03] <fuzzie> does it come with instructions? :)
[21:39:44] <zefklop> no
[21:40:01] <zefklop> you'd have to read the scripts yourself
[21:40:05] <zefklop> it is a weidu mod
[21:40:14] <fuzzie> i can just apply it with weidu to normal bg1?
[21:40:28] <zefklop> weidu gem_test.tp2 --tlkout dialog.tlk should do it
[21:40:38] <fuzzie> thanks, that is what i was wonderig
[21:44:29] <zefklop> uploaded :-)
[21:45:26] <-- dawid has left IRC ("Not leaving, quitting.")
[21:46:13] <-- tombhadAC has left IRC ("Verlassend")
[21:47:04] --> tombhadAC has joined #gemrb
[21:49:04] <fuzzie> it still doesn't seem to test queued actions
[21:51:57] <fuzzie> which seemed like it was the problem with the ogre
[21:52:13] <zefklop> mmh?
[21:52:15] <fuzzie> i mean, that would not be hard to test since you already wrote this, and i'm sure i could add it
[21:52:49] <fuzzie> but you start the cutscene immediately after TestCutsceneRunning, so no other actors have scripts already running before the cutscene?
[21:53:32] <zefklop> there is this lot of actionoverride to test if cutsceneid'ed actions would cut them
[21:54:01] <fuzzie> well, i wonder if that works the same as normal scripts :)
[21:54:07] <zefklop> and no, no actor script running, and it does not seem to run either
[21:54:13] <fuzzie> but i didn't try running this yet, i will have to install bg1
[21:54:29] <zefklop> a variable like prepareyourselfbeforethecutscenestarts
[21:54:32] <zefklop> ??
[21:54:32] <fuzzie> gemrb already stops new scripts from running during a cutscene, so i hope that is correct
[21:54:38] <fuzzie> yes, that was my thought :)
[21:54:50] <fuzzie> but what happens to the MoveToPoint calls, are they cut?
[21:55:11] <zefklop> no
[21:55:19] <fuzzie> ok
[21:55:24] <fuzzie> well, this test framework is great, anyway
[21:55:34] <fuzzie> it has all the things needed for testing!
[21:55:59] <fuzzie> i'll have to start trying to make things myself
[21:56:23] <fuzzie> for example, i would like to test ActionOverride behaviour
[21:57:32] <fuzzie> in fact, maybe it would be best to try and test every action
[21:58:11] <fuzzie> simply starting with NoAction(), then ActionOverride, then AddWayPoint, and so forth
[21:58:19] <fuzzie> maybe you have an idea of how to organise the tests..
[21:59:00] <zefklop> wow, I'd prefer to add something ech time we have some doubts
[21:59:39] <fuzzie> well, i have doubts about all of those first ones :)
[21:59:42] <zefklop> testing _all_ actions in all possible circumstances can be as long as writing gemRb
[22:00:00] <zefklop> then I agree to test them :-)
[22:00:34] <fuzzie> but sometime it would be nice if the ogre didn't kill me
[22:00:44] <zefklop> just add some piece of dialog to tester1 and torture tester2 with actions :-)
[22:02:44] <zefklop> and I still don't know if this is startcutscenemode which freezes script or startcutscene
[22:07:16] <fuzzie> that is maybe important since that bg1 cutscene only calls startcutscene :)
[22:08:43] <zefklop> no, there is a startcutscenemode at the beginning
[22:08:57] <zefklop> at the end of the dialog with gorion
[22:09:28] <zefklop> I must admit that I don't understand a single word of what taimon said on the subject on G3
[22:09:29] <fuzzie> oh, interesting
[22:10:39] <fuzzie> what Taimon says is basically: it uses the first action of each block to work out the target, it ignores CutSceneId
[22:11:00] <fuzzie> and when it adds all of the actions of the block to the target, it adds SetInterrupt at the beginning and end to make sure it isn't interrupted
[22:11:32] <fuzzie> the 'InsertResponse' thing and etc is just IE engine internals which don't matter at all
[22:12:12] <fuzzie> we do not handle the SetInterrupt thing now, and our interrupt code doesn't work properly anyway
[22:12:37] <fuzzie> but i don't see how that would be the problem with the ogres
[22:12:39] <zefklop> oh... those disassembler people seem to forget that others don't have their tools handy
[22:12:59] <fuzzie> yes :)
[22:13:12] <fuzzie> i am much more interested in what happens than how it works in the original engine, anyway
[22:13:26] <fuzzie> and they usually seem more interested in how it works in the original engine than things which are helpful :)
[22:14:15] <zefklop> eh, that's what i think too, although their work is very useful to find how hardcoded things ork
[22:14:32] <fuzzie> Oh, I really want to know how Die() works, too. That is not so easy to test in bg1, the bg1 version is very buggy..
[22:14:32] <zefklop> look at projectiles for instance...
[22:15:00] <fuzzie> hehe, well, i don't mind projectiles because Avenger codes it all for gemrb at once anyway :)
[22:15:43] <zefklop> well, testing on BG2 is impossible for me until september
[22:18:00] <fuzzie> what i worked out about Die() is: it's only set when an actor is dead, and only blocks containing Die() execute on death, and you can have other triggers as well as Die() in a block and it works
[22:18:46] <zefklop> hmmm, yet another head banging script thing (tm)
[22:19:08] <zefklop> it's time for me to sleep
[22:19:12] <zefklop> see you later!
[22:19:16] <fuzzie> bye!
[22:19:23] <-- zefklop has left IRC ("ChatZilla 0.9.85 [Firefox 3.0.8/2009032609]")
[22:20:24] <fuzzie> kalah.baf in bg2 has multiple blocks testing first Die() and then HasItem()
[22:26:21] <fuzzie> 0600thgb.baf, 0607iann.baf, 0609vris.baf, 0610ravl.baf, 0900*.baf, 1101fhju, 1500mary all have multiple blocks involving Die() in pst
[22:27:18] <fuzzie> my iwd2 scripts have no Die() blocks whatsoever, mysterious, i wonder if i dumped them wrong
[22:35:52] <fuzzie> and http://www.gibberlings3.net/tools/iwd2_scripting_info.txt is full of horrible things that can't possibly be right
[22:35:55] <fuzzie> ninight all
[23:16:29] <-- tombhadAC has left IRC ("Verlassend")
[23:35:35] --> tombhadAC has joined #gemrb