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

Archive Today Yesterday Tomorrow
GemRB homepage

[00:00:05] <fuzzie> i also have no patience for packagers who go ahead and package the last release after i tell them the new one is out.. :P
[00:01:05] <fuzzie> i see that someone has uploaded a maemo 0.6.3 recently, just in time for us to release 0.6.4 on the weekend
[00:02:15] <pupnik_> well if they are set up to do it, they can be nudged
[00:04:15] <pupnik_> well back to work
[00:27:16] --> Bo_Thomsen has joined #GemRb
[00:43:05] <edheldil_> fuzzie: I have put some wmap improvements to https://github.com/edheldil/gemrb/commits/fontcolortag
[00:45:27] <edheldil_> I believe lubos's packages are promising, he's still actively working on themand pushing them to debian
[00:48:58] <MikeChelen> playdeb is what i use
[00:49:12] <MikeChelen> tomprince: happy to set up a debian vm if that would be helpful
[00:49:35] <-- Bo_Thomsen has left IRC (Quit: Leaving.)
[00:49:41] <MikeChelen> maybe it would be best to try and help playdeb people build more often?
[00:50:22] <edheldil_> brb
[00:53:08] <-- edheldil_ has left IRC (Read error: Connection reset by peer)
[00:54:02] --> edheldil_ has joined #GemRb
[01:26:53] <-- edheldil_ has left IRC (Ping timeout: 255 seconds)
[01:41:21] <tomprince> MikeChelen: I don't really care about packaging, but I have computer cycles I can spare, and I already build gemrb against every commit. So if somebody wants to do the work, I can set my computer to building packages.
[02:34:10] <MikeChelen> tomprince: yeah, it is the packaging part that is more difficult
[02:39:07] <MikeChelen> or at least someone still needs to do it
[02:54:44] <-- wjp has left IRC (*.net *.split)
[03:00:44] --> wjp has joined #GemRb
[03:09:03] <-- mysticX has left IRC (Remote host closed the connection)
[04:45:17] --> PixelScum has joined #GemRb
[04:48:25] <-- BaldimerBrandybo has left IRC (Ping timeout: 240 seconds)
[05:29:31] <-- |Cable| has left IRC (Ping timeout: 248 seconds)
[06:41:57] --> edheldil_ has joined #GemRb
[06:50:35] <CIA-48> GemRB: 03edheldil * rc6a608ca1907 10gemrb/gemrb/core/ (Font.cpp Interface.cpp Palette.h): Hack to make journal headers in bg2 pretty
[06:50:52] <CIA-48> GemRB: 03edheldil * re7f876f97fcb 10gemrb/gemrb/ (7 files in 6 dirs): (log message trimmed)
[06:50:52] <CIA-48> GemRB: Better rendered text on WorldMap
[06:50:52] <CIA-48> GemRB: Create WMap text palettes with background color
[07:27:54] --> Demitar has joined #GemRb
[07:38:33] --> Bo_Thomsen has joined #GemRb
[07:52:47] --> adominguez has joined #GemRb
[07:55:43] --> lynxlynxlynx has joined #GemRb
[07:55:43] --- ChanServ gives channel operator status to lynxlynxlynx
[07:55:49] * adominguez Yep!!
[08:05:08] <-- edheldil_ has left IRC (Ping timeout: 255 seconds)
[08:19:56] --> edheldil_ has joined #GemRb
[08:21:47] <MikeChelen> yay!
[08:24:42] --> lubos has joined #GemRb
[08:27:43] <pupnik_> :)
[08:30:19] <-- edheldil_ has left IRC (Ping timeout: 248 seconds)
[08:32:22] <-- spike411 has left IRC (Quit: Manga & anime pokec na Jabberu: manga.cz@conf.netlab.cz)
[08:38:24] <-- devurandom has left IRC (Remote host closed the connection)
[08:38:44] --> devurandom has joined #GemRb
[09:21:55] --> edheldil_ has joined #GemRb
[09:24:28] <-- Bo_Thomsen has left IRC (Quit: Leaving.)
[09:25:48] <edheldil> good morning
[09:26:02] <-- edheldil_ has left IRC (Client Quit)
[09:26:04] <fuzzie> morning
[09:26:21] <MikeChelen> hullos
[09:27:42] <MikeChelen> anyone know if capitalization matters for the gemrb.cfg file name?
[09:28:08] <fuzzie> it does, on a case-sensitive fs
[09:28:35] <MikeChelen> ah ok, thanks
[09:28:55] <fuzzie> edheldil: are you sure that colour stuff works in all games, btw?
[09:30:16] <edheldil> I have cursorily tried bg1, pst, bg2, how. Either looked better or not worse. Do you see any regression
[09:30:19] <edheldil> ?
[09:30:22] <fuzzie> no
[09:30:38] <fuzzie> just wondering, since we're in freeze and you pushed to trunk ;)
[09:30:51] <edheldil> eh :)
[09:31:11] <fuzzie> and i know before that 'obvious good fixes' made us release with stupid crashes
[09:32:19] * edheldil blushes. I thought the sources were not frozen yet
[09:32:36] <fuzzie> well, we should really branch
[09:32:41] <lynxlynxlynx> they're not, just be careful
[09:32:45] <fuzzie> but i just pushing to github for now
[09:33:02] <fuzzie> just i know that we don't all have access to all the games, so stuff doesn't get tested
[09:33:42] <lynxlynxlynx> i have the whole day for gemrb today, so maybe the release will happen in the afternoon alraedy
[09:33:51] <fuzzie> hehe
[09:34:21] <MikeChelen> hmm it is still not finding the config file, even though ~/.gemrb/GemRB.cfg exists
[09:34:27] <edheldil> grrr
[09:34:40] <edheldil> you just do not read what I write
[09:34:55] <edheldil> it's ~/.gemrb/gemrb.cfg
[09:35:03] <fuzzie> well, it is '~/.gemrb/<program name>.cfg', right?
[09:36:00] <fuzzie> so you can symlink stuff, i guess
[09:36:28] <edheldil> it searches for: ./GemRB.cfg ~/.gemrb/<progname>.cfg /etc/gemrb/progname.cfg ~/.gemrb/gemrb.cfg /etc/gemrb/gemrb.cfg
[09:36:49] <lynxlynxlynx> the bg2 worldmap stayed the same, while the journal lost the artifacts :)
[09:37:04] <edheldil> or maybe all ~/.gemrb stuff first and /etc later, I am not surre
[09:37:09] <fuzzie> i was more wondering about our rather delicate iwd2 worldmap
[09:37:13] <lynxlynxlynx> it just needs to be a darker shade of red, but that's me nitpicking
[09:37:17] <fuzzie> and pst, but i guess edheldil always checks pst :)
[09:37:32] <lynxlynxlynx> i'll go check iwd2 now
[09:37:35] <fuzzie> thankyou
[09:37:38] <edheldil> pst is ugly
[09:38:24] <lynxlynxlynx> looks fine, except for an unrelated bug
[09:38:32] <edheldil> the pixmaps are mapped to wrong palettes and I have not checked why. But it was so before the patch too
[09:39:15] <fuzzie> well the worldmap code has stupider issues
[09:39:35] <fuzzie> like the screen/map coordinate mapping meaning that you have to mouseover weird places
[09:39:40] <fuzzie> so if you are looking for more things to fix.. :P
[09:39:50] <edheldil> and in pst there are big differences in background brightness, so one text color simply does not work everywhere. I will have to check the original
[09:39:59] <edheldil> hehe
[09:40:31] <fuzzie> i have a large list of stupid bugs to fix now, but i try and concentrate on getting the hang of actions/triggers
[09:42:34] <fuzzie> oh, on the way i worked out how they do the area trap stuff
[09:42:36] <edheldil> I was thinking about merging all the <controltype>_SetSomeColor to Control_SetColor(), to support textarea and button colors
[09:43:03] <fuzzie> they don't go off if the pending action on an actor is 'remove traps', and they don't go off if the 'position of actor last time a trap was set off' is inside the trap
[09:43:17] <fuzzie> but this is part of my action rewrite so you can all forget that now ;p
[09:43:44] <edheldil> that sounds sensible, for a change :)
[09:45:51] <MikeChelen> edheldil: ~/.gemrb/gemrb.cfg already exists
[09:46:15] <MikeChelen> dunno why it isn't being found
[09:46:59] --> SiENcE has joined #GemRb
[09:49:20] <fuzzie> how do you run gemrb, just 'gemrb' at a prompt?
[09:51:44] <lynxlynxlynx> strace gemrb ... 2>&1 | grep -i cfg.*enoent
[09:55:27] <MikeChelen> fuzzie: by cd into the build/gemrb dir then running ./gemrb
[10:08:02] <edheldil> MikeChelen: can you again post the console output?
[10:24:03] <MikeChelen> edheldil: problem seems to be: [Config]: Trying to open GemRB.cfg [NOT FOUND]
[10:25:21] <fuzzie> well, lynx's suggestion is the obvious one
[10:25:25] <fuzzie> you *are* on linux, right?
[10:25:28] <edheldil> that's not (should not be) a problem - it just means it does not exist, but it should try the other options
[10:29:58] <MikeChelen> open("GemRB.cfg", O_RDONLY) = -1 ENOENT (No such file or directory)
[10:32:31] <fuzzie> it should try the home one right after the first one
[10:32:47] <fuzzie> it is possible that PathJoin is doing something dumb, but you'd still get console output
[10:36:30] <MikeChelen> that is the expected behavior
[10:36:51] <MikeChelen> it seems to find it ok only by putting a symlink in the same dir as the executable
[10:37:19] <edheldil> it should not matter that it can't find it as long as it finds another one
[10:38:01] <wjp> MikeChelen: just to be sure, is there an actual problem, or are you just concerned about this 'NOT FOUND' on the console?
[10:38:27] <edheldil> so the line " [Config]: Trying to open GemRB.cfg [NOT FOUND]" is the **last** line of console output, and after then it does what? crashes? Waits indefinitely, no window shown?
[10:38:37] <MikeChelen> wjp: it would be nice to have it load the file properly, instead of having to add this extra symlink
[10:38:57] <wjp> yes, but that doesn't answer my question.
[10:39:07] <wjp> Is there an actual problem when you don't have this extra symlink?
[10:39:27] <MikeChelen> edheldil: yeah that is the last line, and then nothing else happens
[10:39:29] <wjp> i.e., as Edheldil asks: what happens when you don't?
[10:39:36] <MikeChelen> wjp: this is without the extra symlink
[10:39:45] <MikeChelen> that this error is occurring
[10:40:02] <wjp> and that one line is the only output of the strace/grep ?
[10:40:23] <MikeChelen> yeah it is
[10:41:00] <edheldil> it is expected. So just run strace ./gemrb.cfg >out.1 2>out.2 and post the two files somewhere
[10:41:17] <wjp> minus the .cfg
[10:41:31] <edheldil> yeah, sorry
[10:43:35] <MikeChelen> out.1 is blank, here is out.2: http://paste.ubuntu.com/585312/
[10:44:02] <edheldil> lol
[10:44:21] <MikeChelen> :D
[10:45:21] <edheldil> once more, please, this time with strace ./gemrb >out.1 2>out.2
[10:46:10] <MikeChelen> oopsie
[10:47:54] <MikeChelen> hmm, out.2 has thousands of lines of this: lseek(3, 6042, SEEK_SET) = 6042
[10:49:11] <edheldil> do you mean that they all look the same and this is what gemrb does while it hangs?
[10:49:47] <MikeChelen> here is the full out.2 http://paste.ubuntu.com/585314/
[10:50:18] <MikeChelen> yeah it hangs on the command line and has to be killed, looks like it is writing that line endlessly
[10:54:07] * fuzzie -> out for the day
[10:58:44] <edheldil> LoadConfig() is ugly indeed, but it will be a moment before I can check
[10:59:24] <edheldil> is the ~/gemrb/gemrb.cfg the same as ./GemRB.cfg?
[11:00:56] <MikeChelen> there is no ./GemRB.cfg in the build directory
[11:01:59] <MikeChelen> or build/gemrb
[11:04:55] <edheldil> ah, sure. So if you symlink the ~/.gemrb/gemrb.cfg to ./GemRB.cfg it works, ----> ~/.gemrb/gemrb.cfg is a correct file ?
[11:05:44] <edheldil> I am just making sure ~/.gemrb/gemrb.cfg is not broken or whatever
[11:07:19] <edheldil> I am a bit confused by this:
[11:07:21] <edheldil> access("/home/mikechelen/.gemrb/gemrb", R_OK) = -1 ENOENT (No such file or directory)
[11:07:21] <edheldil> open("/home/mikechelen/.gemrb/", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
[11:08:30] <edheldil> especially the first line shows there's something fishy going on
[11:08:52] <wjp> isn't that just PathJoin?
[11:09:06] <MikeChelen> yeah ~/.gemrb/gemrb.cfg is the correct file
[11:09:26] <wjp> PathJoin does some checks on all parts of what it's constructing
[11:09:31] <wjp> hm, reading LoadConfig, could this infinite loop happen if a line starts with a = character?
[11:09:38] <MikeChelen> would it matter if the paths inside ~/.gemrb/gemrb.cfg are wrong?
[11:09:41] <wjp> or whitespace, for that matter
[11:10:30] <MikeChelen> actually it looks like all the paths are correct
[11:10:41] <MikeChelen> in the actual gemrb.cfg
[11:11:18] <wjp> it doesn't actually do anything with the config values yet at this point; just storing the values
[11:12:09] <wjp> what does this return? grep '^ ' ~/.gemrb/gemrb.cfg | wc -l
[11:12:14] <edheldil> hmm, the first try would be to get rid of PathJoin, as it got improved to do too much stuff behind the scenes
[11:12:28] <MikeChelen> wjp: 2
[11:12:31] <MikeChelen> err 3
[11:12:41] <wjp> and this? grep '^=' ~/.gemrb/gemrb.cfg | wc -l
[11:12:52] <MikeChelen> 0
[11:13:37] <wjp> I haven't really properly looked at this, but see if it helps if you remove lines in gemrb.cfg that contain only whitespace
[11:13:54] <wjp> (those 3 lines that start with a space)
[11:14:53] <MikeChelen> any way to find them?
[11:15:07] <wjp> depends on the editor
[11:15:26] <MikeChelen> currently using vi
[11:15:36] <MikeChelen> probably could replace with sed
[11:15:39] <wjp> in vi you can do '/^ ' to search for them, or ':set list' to make them visible
[11:15:48] <lynxlynxlynx> nice, seems the sunray crash is not related to wild magic
[11:16:01] <lynxlynxlynx> MikeChelen: just add -n to grep and it will show the line numbers
[11:16:38] <MikeChelen> that fixed it!
[11:16:51] <wjp> parser bug; hurray
[11:17:03] <wjp> so when you added a symlink you were actually adding a symlink to a different file?
[11:17:14] <MikeChelen> those lines didnt have only whitespace, but they started with spaces
[11:17:38] <MikeChelen> no the symlink was just in the same dir as executable
[11:18:10] <MikeChelen> let me check if the symlink was actually working now
[11:18:25] <wjp> because this bug would hit you no matter if it accessed the file via a symlink or not...
[11:19:41] <MikeChelen> with the symlink it still hangs, but there is no error about GemRB.cfg
[11:20:03] <MikeChelen> when there are spaces at the start of lines in the file
[11:20:20] <wjp> as Edheldil said a few times now, that error doesn't matter if it finds a different gemrb.cfg later in the search path :-)
[11:20:48] <MikeChelen> ok
[11:23:11] <wjp> and a request for next time: please start by reporting the actual symptoms you're seeing ('gemrb hangs') rather than what you think may be the cause :-)
[11:23:13] <edheldil> ok, create a tracker ticket for this bug. I will look at it tonight if nobody beats me to it
[11:23:39] <edheldil> s/create/I created/
[11:24:12] <edheldil> but it would be probably better to have it fixed for the release
[11:24:42] <wjp> hm, I'd rather not touch this code so close to a release :/
[11:24:47] <wjp> it looks rather unstable...
[11:26:11] <edheldil> indeed
[11:26:20] <edheldil> ok, tonight, then :)
[11:27:25] <MikeChelen> wjp: been asking about this issue for a while, hard to recall who heard what parts
[11:27:45] <MikeChelen> meaning several hours :)
[11:28:15] <edheldil> and for us to remember them anyway :). Ok, good that it got nailed at last
[11:29:30] <wjp> you never mentioned hanging though :-)
[11:30:09] <wjp> but anyway, thanks for the report; this bug has been in here for ages likely
[11:30:19] <MikeChelen> thanks for all the help!
[11:30:27] <MikeChelen> thought that was clear from saying it wouldn't load the config
[11:32:28] <MikeChelen> ok, now getting [GUIScript]: Check if /home/mikechelen/bin/gemrb/build/gemrb/GUIScripts/GUIDefines.py exists! [ERROR]
[11:33:11] <MikeChelen> weird thing is that in gemrb.cfg GUIScriptsPath=/home/mikechelen/bin/gemrb/gemrb/
[11:47:09] <-- devurandom has left IRC (Remote host closed the connection)
[11:47:25] --> devurandom has joined #GemRb
[12:00:16] --> Maighstir has joined #GemRb
[12:21:45] <lynxlynxlynx> why did you set it at all?
[12:22:00] <lynxlynxlynx> and clearly it is the wrong path
[12:34:03] <MikeChelen> the path mentioned in the error is different from the config file
[12:35:12] <lynxlynxlynx> yes, since it is constructed
[12:36:02] <MikeChelen> it seems to be using GemRBPath and ignoring GUIScriptsPath
[12:36:28] <lynxlynxlynx> no
[12:36:35] <edheldil> time to have that GUIScriptsPath in cfg commented out by default, it only confuses ppl :)
[12:36:36] <lynxlynxlynx> just leave it commented out
[12:36:57] <MikeChelen> same error
[12:37:11] <lynxlynxlynx> edheldil: it is already like that
[12:37:27] <edheldil> are you sure you are not using different cfg file than you think?
[12:37:34] <edheldil> ah
[12:38:30] <MikeChelen> edheldil: yeah because renaming the file causes gemrb.cfg not found errors
[12:39:50] <lynxlynxlynx> "errors"
[12:40:06] <lynxlynxlynx> does gemrb run without it or not?
[12:40:34] <edheldil> I will remove the separate errors as well, they are confusing
[12:46:52] <MikeChelen> it won't start successfully
[12:48:02] <MikeChelen> the last line is the error, then it says press enter to continue
[12:48:11] <MikeChelen> and then exits after hitting enter
[12:50:27] <lynxlynxlynx> ok
[12:51:09] <lynxlynxlynx> upload that config somewhere
[13:07:37] --- Maighstir is now known as MaighstirAway
[13:49:05] <-- lubos has left IRC (Remote host closed the connection)
[14:27:23] <-- Demitar has left IRC (Quit: Burn the land and boil the sea, you can't take the sky from me!)
[14:34:56] --> pupnik has joined #GemRb
[14:34:56] <-- pupnik has left IRC (Changing host)
[14:34:56] --> pupnik has joined #GemRb
[14:38:02] <-- pupnik_ has left IRC (Ping timeout: 250 seconds)
[14:49:42] <MikeChelen> lynxlynxlynx: http://paste.ubuntu.com/585423/
[14:49:59] <-- SiENcE has left IRC (Quit: @all: cya)
[14:52:34] <edheldil> why do you use // for comments???
[14:53:13] <wjp> heh, I'm guessing that also completely breaks the parser
[14:53:27] <wjp> this scanf approach is really stupid
[14:54:37] <lynxlynxlynx> GemRBPath is bad
[14:54:37] <edheldil> and I am not sure '~' is supported. Dunno
[14:54:42] <lynxlynxlynx> it is
[14:55:16] <lynxlynxlynx> for running from the build dir, GemRBPath=../gemrb should do it
[14:55:17] <MikeChelen> oh that is just habit, guess that isn't necessarily supported
[14:55:27] <lynxlynxlynx> or one level higher if you're cding to gemrb
[14:57:04] <MikeChelen> is there any downside to using full paths?
[14:58:28] --- MaighstirAway is now known as Maighstir
[14:59:41] <MikeChelen> ~ must be ok because this config has worked in the past
[15:03:30] --> BaldimerBrandybo has joined #GemRb
[15:06:14] <lynxlynxlynx> not really, i doubt you'll move your gemrb dir
[15:06:26] <wjp> ugh, this parser's failure handling is _really_ broken. It should really just switch to reading full lines and parsing those one at a time
[15:07:01] <-- PixelScum has left IRC (Ping timeout: 264 seconds)
[15:11:26] <edheldil> that's my plan for this evening
[15:11:38] <wjp> great :-)
[15:11:52] <edheldil> I do not like scanf(), never used it much
[15:12:52] <wjp> me neither
[15:16:27] --> PixelScum has joined #GemRb
[15:18:27] <-- BaldimerBrandybo has left IRC (Ping timeout: 240 seconds)
[15:29:20] --> BaldimerBrandybo has joined #GemRb
[15:32:49] <-- PixelScum has left IRC (Ping timeout: 264 seconds)
[15:36:16] <-- devurandom has left IRC (Ping timeout: 260 seconds)
[15:38:11] --> devurandom has joined #GemRb
[15:49:41] <-- devurandom has left IRC (Ping timeout: 260 seconds)
[15:51:24] --> devurandom has joined #GemRb
[15:54:25] <fuzzie> hi
[15:54:41] <wjp> hello
[15:54:44] <fuzzie> tomprince's tree reworks some of that LoadConfig code to read by line
[15:54:48] <fuzzie> if that is what was being discussed
[15:54:51] <fuzzie> it's still broken though :P
[15:54:57] <wjp> it was
[16:04:29] <fuzzie> i was complaining about it a few days ago but just thought it was ugly :)
[16:09:31] <-- devurandom has left IRC (Ping timeout: 260 seconds)
[16:11:07] --> devurandom has joined #GemRb
[16:29:34] <tomprince> If we figured out how to do static linking on windows, we could just use the INIImporter (although it uses a differ comment character.
[16:32:24] <tomprince> ... or maybe not.
[16:32:39] <fuzzie> the comment thing isn't an obstacle, anyway
[16:33:19] <fuzzie> but messing with static linking seems a bit trivial for that file format, which doesn't even have sections
[16:33:41] <fuzzie> anyway, i don't care as long as no-one breaks the existing functionality
[16:34:17] <fuzzie> just please don't break it while i am trying to fix this silly game stuff :P
[16:36:29] <edheldil> so does TP want to fix it? :)
[16:37:02] --> |Cable| has joined #GemRb
[16:57:45] <lynxlynxlynx> grrr, viconia is such a pain
[16:57:56] <fuzzie> Oh?
[16:58:00] <lynxlynxlynx> too aggressive default script
[16:58:24] <fuzzie> gemrb bug?
[16:58:26] <lynxlynxlynx> maybe we don't do the part ai toggling well enough yet
[16:58:31] <lynxlynxlynx> party ai
[16:58:44] <fuzzie> yes, i mean, is it a gemrb bug that it's too agressive
[16:59:26] <fuzzie> i know that we misimplement the party ai toggle compared to the original
[16:59:35] <fuzzie> i don't know if that is deliberate :)
[16:59:36] <lynxlynxlynx> that's probably it then
[17:00:08] <fuzzie> the original engine only runs override if party AI is off, which leads to bugs
[17:02:15] <fuzzie> would be nice to have a decision on what to do about that, actually
[17:02:22] <fuzzie> i guess doing what the original engine does is more sensible for now
[17:04:59] <fuzzie> > For example, the trip from Trademeet to the Forest of Tethir is 52 hours, despite a fairly close proximity on the map.
[17:05:08] <fuzzie> ^- oh *heh*, it isn't a gemrb bug
[17:07:03] <lynxlynxlynx> sounds reasonable
[17:08:28] <fuzzie> i guess our worldmap probably shouldn't give me -1 as a distance in tooltips though :)
[17:11:20] <edheldil> they are REALLY close ;-)
[17:11:52] <fuzzie> the searchmap square stuff is going to drive me mad
[17:36:01] <pupnik> viconia is a painindeed :)
[17:39:04] <-- devurandom has left IRC (Remote host closed the connection)
[17:42:10] --> devurandom has joined #GemRb
[17:56:52] <-- adominguez has left IRC (Quit: Saliendo)
[18:24:04] <lynxlynxlynx> gah, this is crazy
[18:24:22] <fuzzie> are you trying to debug something?
[18:24:25] <lynxlynxlynx> why did i pick sunray to test with :<
[18:24:42] <lynxlynxlynx> it's too late now
[18:25:07] <fuzzie> ok
[18:25:28] <fuzzie> well i am failing to fix anything because i'm getting distracted by "ooh, shiny" in the original engine
[18:25:38] <fuzzie> but i have this evening pencilled as 'poke at gemrb', if i can be helpful
[18:25:49] <fuzzie> although you have to compete with the "ooh, shiny"
[18:25:55] <lynxlynxlynx> hehe
[18:26:23] <lynxlynxlynx> i was going to tackle that spell data copying for wild magic, but then i noticed fx_cast_spell crashes
[18:26:44] <lynxlynxlynx> got that fixed, but then the debugging saga started
[18:27:03] <fuzzie> ah :)
[18:28:14] <tomprince> Well, so long as you are documenting all the "ooh, shiny", things are not a loss. :)
[18:33:47] <lynxlynxlynx> heh, something to soothe the exit - i found out why trap setting doesn't work
[18:33:54] <lynxlynxlynx> we simply didn't finish the casting
[18:34:27] <fuzzie> :)
[18:34:43] <fuzzie> well please don't spend much time on anything involving the start/finish casting split
[18:34:59] <fuzzie> i didn't look into it in detail, but i'm fairly sure it's wrong to have it
[18:39:02] <lynxlynxlynx> just hacked around it
[18:40:07] <fuzzie> ok, so our current GameExpansion() is missing the correct equipment code, the familiar replacing and the innate fixes
[18:40:51] <lynxlynxlynx> yeah, this is on the wiki
[18:41:47] <CIA-48> GemRB: 03lynxlupodian * rfb0d9df571be 10gemrb/gemrb/plugins/FXOpcodes/FXOpcodes.cpp:
[18:41:47] <CIA-48> GemRB: fixed the three casting effects to not get stuck in a loop when targeting
[18:41:47] <CIA-48> GemRB: the caster
[18:42:15] <fuzzie> well, the wiki doesn't document it well enough
[18:42:58] <fuzzie> which is not surprising, it is complicated :/
[18:43:25] <fuzzie> i think the bit Avenger missed is that there's a param which tells it whether it's starting a new game or not
[18:44:26] <lynxlynxlynx> you probably get a different bag (if anything) when transitioning directly
[18:44:41] <fuzzie> you get no bag
[18:46:48] <fuzzie> you do get AMUL27 always
[18:47:16] <fuzzie> the function is 'UpdatePartyToExpansionPack'
[18:48:32] <fuzzie> called for the expansion action, in LoadGame if needed, in UIControlButtonCharGenAccept if needed, in CScreenCreateChar::StartDebugParty (hah) and in multiplayer start
[18:48:37] <fuzzie> should not be hard to work that out.
[18:54:33] <lynxlynxlynx> oh right, the seldarine one
[19:10:39] <lynxlynxlynx> is it safe to memset one spell over another (a fresh one)?
[19:11:39] <fuzzie> memcpy? yes, but you have to be very careful where it came from
[19:13:36] <fuzzie> because you're not actually copying everything
[19:14:15] <lynxlynxlynx> i was worried about the headers
[19:14:54] <lynxlynxlynx> i need to copy those too, not just their location in the spell, since the headers is what gets modified
[19:14:55] <fuzzie> i guess the sane answer is 'no, it is not safe'
[19:15:04] <lynxlynxlynx> copy constructor?
[19:15:14] <lynxlynxlynx> brb
[19:15:57] <fuzzie> you could just make a fresh copy of the spell without going through gamedata
[19:16:09] <tomprince> Perhaps use something like a smart pointer with deep-copy semantics?
[19:16:21] <tomprince> Lots of things should have copying disabled otherwise, in gemrb.
[19:16:47] <fuzzie> or a copy constructor :P
[19:17:13] --> barra_home has joined #GemRb
[19:17:14] <lynxlynxlynx> ok, i'll just fetch it manually
[19:18:19] <fuzzie> i think that is by far the simplest solution for now
[19:19:01] <fuzzie> and yes, disabling copying on most of these objects is probably sensible, and making them const beyond a certain point
[19:19:24] <fuzzie> triggers/actions being a good example, maybe
[19:20:27] <tomprince> Well, actions already have a copy constructor (sort of). It is just called ParamCopy. :)
[19:21:00] <fuzzie> oh, right, the actionoverride thing
[19:21:17] <fuzzie> ugh
[19:21:35] <fuzzie> i rather hope nothing is using ParamCopy
[19:22:08] <tomprince> Doesn't look like it.
[19:22:22] <fuzzie> all of the action uses of ParamCopyNoOverride are broken bad uses
[19:22:50] <fuzzie> the one in MoveToObjectCore, too
[19:24:02] <fuzzie> i mean, it's not any problem using them, it just shouldn't be necessary
[19:24:11] <tomprince> I do somewhat wonder why bioware came up with the seemingly insane scripting language they did.
[19:24:28] <fuzzie> well, it isn't atypical
[19:25:14] <tomprince> then it is typically insane? ;)
[19:25:27] <fuzzie> i think that would be a pretty good description :)
[19:26:13] <fuzzie> the Creatures engines use scripting where every keyword is 4 chars so it can be cast to/from integers, to give you an idea of how much worse it can get
[19:26:28] * tomprince boggles
[19:27:25] <fuzzie> http://twinsen.warpedgames.com/~fuzzie/seedscript.cos <- it is quite delightful
[19:27:40] --> barra_away has joined #GemRb
[19:28:57] <fuzzie> but for these era of games, everyone wanted low-memory simple scripting languages which didn't make the scripter care about the yielding, and then just sort of added features on top as scripters needed them
[19:30:35] <-- barra_home has left IRC (Ping timeout: 248 seconds)
[19:31:00] <tomprince> Well, I don't know that scripting language, but just looking at the structure, in someways it seems nice than iescript. It looks, anyway, like a somewhat normal language with a silly obscure syntax.
[19:31:37] <fuzzie> hehe, in reality it is far worse of course, with the standard yielding mess for example :)
[19:32:26] <fuzzie> but it's really difficult to do it right, i think
[19:36:51] <fuzzie> now i am off looking at NWScript
[19:39:09] <fuzzie> which is what happened when Bioware decided to rewrite, I suppose
[19:39:12] <fuzzie> and is nicely VM-ish
[19:42:28] <fuzzie> not very clear how it works though.
[19:42:40] <fuzzie> i guess DrMcCoy etc would know better.
[19:43:31] <DrMcCoy> Bleh, NWScript :P
[19:45:25] <fuzzie> it's really so delightfully what you'd get if you took IEScript and removed the stupid
[19:45:46] <DrMcCoy> NWScript has plenty of stupid
[19:46:10] <fuzzie> well, i am assuming you are stuck with the rest-of-the-engine stupid
[19:46:32] <DrMcCoy> En masse constants in the script headers that should never be changed since the game engine has the same values hardcoded, for example
[19:46:56] <fuzzie> like all the hardcoded constants :)
[19:47:30] <DrMcCoy> Also, IIRC, NWScript NWN-era is missing arrays :P
[19:47:38] <fuzzie> you are spoiled :)
[19:47:47] <DrMcCoy> :P
[19:47:59] <fuzzie> although come to think of it, even Living Books has arrays
[19:49:27] <fuzzie> but it's difficult to tell how nwscript works internally, at a glance it looks like it does the sensible thing and doesn't run every action in the game via scripting language queues
[19:49:51] <DrMcCoy> o_O
[19:51:01] <fuzzie> in IE, everything is done on the basis of scripts: you might have a MoveToObject followed by a SpellCast, and the engine runs MoveToObject every frame until it says "ok, this script function is done", at which point it runs the SpellCast - no seperate action queueing, just blocking scripts
[19:52:16] <fuzzie> secretly it turns out that the actual MoveTo bit is done on the basis of the creature's animation being SEQ_WALK but let's not talk about that bit, i will cry.
[19:52:33] <DrMcCoy> Yeah, I don't think NWN does it that way
[19:52:46] <fuzzie> but it's so much easier for newbies to write scripts that way
[19:52:54] <DrMcCoy> In NWN, scripts are semi-concurrent. No idea how it's handled internally, though :P
[19:53:28] <fuzzie> yes, well, i'm sure you'll find out
[19:53:36] <DrMcCoy> Eventually :P
[19:53:37] <fuzzie> is KotOR much different?
[19:53:55] <DrMcCoy> From what I've read, not that much
[19:54:30] <DrMcCoy> There's a NWN script compiler out there (with sources), IIRC people have adapted it for KotOR's scripts too
[19:54:41] <fuzzie> yes, i have the nwntools stuff open atm
[19:54:46] <fuzzie> it is .. not spectacularly readable
[19:54:52] <DrMcCoy> :P
[19:55:15] <fuzzie> although i guess it is decompiling too
[19:56:51] <fuzzie> anyway, must resist getting derailed
[19:56:57] <DrMcCoy> :D
[20:05:48] <lynxlynxlynx> http://sprunge.us/fePa?diff <-- how does this look? appears to work fine
[20:06:21] <fuzzie> why are you checking if spell is NULL?
[20:07:22] <fuzzie> and i assume sabotaging GameExpansion is not intentional
[20:08:33] <lynxlynxlynx> no, leave that chunk out of it
[20:09:02] <lynxlynxlynx> the null check is inherited from the original function
[20:09:03] <tomprince> It would seem to me to make more sense to just provide a proper copy constructor, or clone function to spell, rather than reading from disk again.
[20:09:06] <lynxlynxlynx> i can remove it
[20:09:52] <lynxlynxlynx> tomprince: can you do that?
[20:10:10] <fuzzie> well, can you do that and promise it is bug-free for a release in a very short time? :P
[20:10:15] <lynxlynxlynx> seems the release will have to happen on sunday, i'll be gone tommorow
[20:10:29] <fuzzie> lynxlynxlynx: on another note, 'we need to refetch the projectile' leaks the original projectile?
[20:11:15] <lynxlynxlynx> probably, i haven't grinded this yet
[20:11:33] <lynxlynxlynx> i just checked that projectiles aren't cached, so don't need a similar hack
[20:12:10] <fuzzie> as with ed's patch i would prefer to note a big 'HACK' in a comment somewhere, too
[20:12:56] <lynxlynxlynx> ok
[20:13:45] <fuzzie> as tomprince says, a CopySelf()-type thing on spell would be a lot more sensible, i am just dubious about our ability to test that this close to a release
[20:15:06] <tomprince> Perhaps put what you have in a branch for the release, and I will make Spell properly copyable after that release?
[20:15:39] <lynxlynxlynx> i was just about to say something along those lines
[20:15:53] <lynxlynxlynx> i'll commit this and branch off, then you can all go crazy with the rewrites
[20:15:58] <fuzzie> yay :p
[20:16:06] <tomprince> How about branch off and then commit?
[20:16:48] <fuzzie> no, then we lose the fix
[20:17:05] <fuzzie> oh, i guess you think we can just copy *all* spells that go through there
[20:17:13] <tomprince> fuzzie: One reason for a deep-copying smart pointer is for something like Spell, where there are ~30 some instance variables, and only a couple of them need special handling.
[20:17:20] <fuzzie> sure
[20:18:22] <fuzzie> but it seems a bit artificial to say 'well, this would be nicer to copy' and then 'well, the nicest way to copy this is to add a bunch of complexity'
[20:18:45] <tomprince> Which is why I originally wrote Owner, so I wouldn't have make sure to copy everything else.
[20:19:08] <tomprince> Unfortunately, Owner conflicts with some variable names, and msvc6 chokes on it, so it would need a better name.
[20:19:30] <fuzzie> but from a personal point of view, templates worry me because they tend to make compiles slow
[20:23:16] <lynxlynxlynx> so ...
[20:23:32] <fuzzie> this is a somewhat irrelevant discussion, lynx :)
[20:23:55] <fuzzie> let me take aother look at that commit
[20:24:31] <lynxlynxlynx> the useless null check is out and a note that it is a hack was added
[20:25:38] <lynxlynxlynx> i'll have to go through all the hardcoded surges again to be sure though
[20:25:59] <fuzzie> it looks wrong as-is because the spltmp isn't used enough
[20:26:22] <fuzzie> but i thought this changed more fields than it does, so maybe it's fine
[20:27:44] <lynxlynxlynx> where more would you use it?
[20:28:57] <fuzzie> i was thinking of the change of target type, but you only change it on gthe feratures
[20:29:48] <fuzzie> but e.g. what happens if caster->wildSurgeMods.target_type is FX_TARGET_SELF? never happens?
[20:30:44] <fuzzie> but your changes look fine given how it works right now, i think
[20:32:31] <fuzzie> but other issues .. e.g. projectile_speed_mod is destroyed by the pro overwrites, if multiple wild surge mods happen at once, i don't know if they do
[20:32:56] <fuzzie> (i assume easy to fix by just moving that change to the bottom)
[20:33:08] <lynxlynxlynx> original data doesn't use target_type & FX_TARGET_SELF; i hope we get rid of geteffectblock by the time it is wanted
[20:33:46] <lynxlynxlynx> some mods could stack, yes, since they're time based
[20:34:38] <fuzzie> but i'm not sure whether to commit to trunk or not
[20:35:03] <fuzzie> i would, because the idea of copying spells every time for a special-case seems ridiculous :) but maybe that is not the sensible view
[20:35:34] <lynxlynxlynx> avenger didn't want to always copy either
[20:38:40] <tomprince> Well, no reason to always copy, even if using a copy constructor, rather than reloading.
[20:39:13] <fuzzie> i guess
[20:39:16] <fuzzie> you should speak up earlier :)
[20:39:25] <fuzzie> ok, so yes, i guess commit that spltmp thing to a branch
[20:40:04] <fuzzie> i need to sit down and work out the actual impact of more smart pointers to my willingness to work on gemrb as measured by compile times, but not going to do it now
[20:40:18] <lynxlynxlynx> what branch is the question :)
[20:40:34] <lynxlynxlynx> tomprince: will you do that copy constructor by sunday?
[20:40:46] <fuzzie> i mean, a release branch
[20:41:02] <fuzzie> well, i guess i don't care :P
[20:41:23] <fuzzie> but this seems like a 'safe' fix and putting it on a release branch doesn't seem like it can have bad consequences
[20:42:00] <tomprince> I can, but I was thinking that that change was too intrusive for just before a release.
[20:43:30] <lynxlynxlynx> ok
[20:44:01] <CIA-48> GemRB: 03lynxlupodian * rf70ad05915d9 10gemrb/gemrb/core/Scriptable/Scriptable.cpp: wild magic: check for the speed mod after possible projectile changes
[20:52:11] <-- |Cable| has left IRC (Read error: Connection reset by peer)
[21:01:14] <CIA-48> GemRB: 03lynxlupodian 070.6.4 * rf70ad05915d9 10gemrb/gemrb/core/Scriptable/Scriptable.cpp: wild magic: check for the speed mod after possible projectile changes
[21:01:16] <CIA-48> GemRB: 03lynxlupodian 070.6.4 * rff5b98d7370a 10gemrb/gemrb/override/bg1/damage.2da: bg1 also has the spfirimp bam
[21:01:20] <CIA-48> GemRB: 03lynxlupodian 070.6.4 * rb10cdc39bfbd 10gemrb/NEWS: NEWS: prerelease update
[21:01:22] <CIA-48> GemRB: 03lynxlupodian 070.6.4 * rd9c949613f9c 10gemrb/ (NEWS gemrb/override/bg1/damage.2da): Merge branch 'master' into 0.6.4
[21:01:38] <CIA-48> GemRB: 03lynxlupodian * rff5b98d7370a 10gemrb/gemrb/override/bg1/damage.2da: bg1 also has the spfirimp bam
[21:01:43] <CIA-48> GemRB: 03lynxlupodian * rb10cdc39bfbd 10gemrb/NEWS: NEWS: prerelease update
[21:04:12] <CIA-48> GemRB: 03lynxlupodian * r99c28c8e63e7 10gemrb/NEWS: NEWS: restarted the cycle
[21:06:34] <CIA-48> GemRB: 03fuzzie * r785ed4c4ce4a 10gemrb/gemrb/core/Scriptable/Actor.cpp: fix TryToHide so it checks for nearby enemies
[21:06:40] <CIA-48> GemRB: 03fuzzie * r7da1050ab2b7 10gemrb/gemrb/ (4 files in 3 dirs):
[21:06:40] <CIA-48> GemRB: remove Attackers array and move some round code around
[21:06:40] <CIA-48> GemRB: this is the first step of trying to rewrite the Attack code
[21:06:45] <CIA-48> GemRB: 03fuzzie * reb1c2c6e7d73 10gemrb/gemrb/core/Scriptable/Scriptable.h: add some spacing/comments to Scriptable.h
[21:09:34] <tomprince> Does Spell::GetEffectBlock deliberatly change the Effects in the Spell, or is that unintentional?
[21:10:23] <fuzzie> it is intentional, since that is the only way they're accessed
[21:12:04] <fuzzie> although it is of course broken
[21:12:44] <tomprince> Do you mean that it is broken, that it does that?
[21:13:06] <fuzzie> it is broken because it is changing fields which can't be changed in the Effects
[21:14:18] <fuzzie> specifically, the "apply the stat-based spell duration modifier" stuff
[21:15:12] <fuzzie> should probably make AddEffect return the new effect, and modify that
[21:15:46] <tomprince> Well, I am fixing it. I'll show you the code in a bit.
[21:16:21] <fuzzie> well, i *really* wouldn't want an unnecessary alloc there
[21:16:35] <tomprince> Do it on the stack.
[21:16:50] <fuzzie> yes, doing it on the stack would work
[21:16:56] <fuzzie> although, also inefficient
[21:17:01] <fuzzie> since there's a new pointer right there to modify..
[21:17:34] <fuzzie> but we don't call GetEffectBlock enough for it to be a big deal
[21:18:26] --> ar__ has joined #GemRb
[21:18:46] <CIA-48> GemRB: 03fuzzie * r840999507a2e 10gemrb/gemrb/core/ (Interface.cpp Interface.h): pull GSUpdate implementation out of header
[21:19:18] <fuzzie> so i am fine with anything there that doesn't make me go crazy due to aforementioned templates i think.
[21:19:24] <fuzzie> as lynx said we need to replace that code anyway.
[21:19:59] <-- ar has left IRC (Read error: Operation timed out)
[21:20:02] --- ar__ is now known as ar
[21:20:10] <-- ar has left IRC (Changing host)
[21:20:10] --> ar has joined #GemRb
[21:39:41] <tomprince> perhaps crazy inducing and certainly in need of some more testing: https://gist.github.com/887689
[21:40:40] <fuzzie> why change it to all be references?
[21:41:02] <tomprince> habit, mostly.
[21:41:25] <tomprince> certainly not necesary.
[21:41:35] <fuzzie> sure, it just makes the patch impossible to quickly view :/
[21:41:47] <fuzzie> since you have .. three changes in here?
[21:42:52] <fuzzie> four, i suppose
[21:42:55] <tomprince> yes ... I did them in the reverse order of how it would be necsesary to split them up. :/
[21:43:39] <fuzzie> ok, five. i give up counting :)
[21:44:40] <fuzzie> the vector thing is nice, especially removing the junk fields
[21:45:07] <fuzzie> and consting is always nice
[21:45:18] <fuzzie> and getting rid of GetSPLExt is nice
[21:46:28] <fuzzie> but i'd have to think whether the references thing is good or not.
[21:46:47] <fuzzie> i can always re-do these patches myself, i just don't want to interfere
[21:47:20] <fuzzie> atm i am despairing a bit at how much of the codebase needs rewriting/breaking to fix the scriptable updates
[21:47:36] <fuzzie> i think 'git reset --hard' is starting to become muscle memory
[21:47:53] <tomprince> Yes, which can be dangerous. :)
[21:52:04] <tomprince> There seems to be a bug, if you let imoen get killed in the first dungeon, causing a segfault in MoveNearerTo.
[21:52:22] <fuzzie> you can get imoen killed in the first dungeon?
[21:52:32] <fuzzie> but, well, that is on the rewritie list
[21:52:37] <tomprince> Well, not killed, but when she escapes.
[21:52:39] <fuzzie> oh, right
[21:52:44] <fuzzie> yes, she probably has no area
[21:53:01] <fuzzie> you are welcome to add a check there for now, if you want
[22:00:43] <CIA-48> GemRB: 03tom.prince * r24eafe4950d0 10gemrb/gemrb/core/GameScript/GSUtils.cpp:
[22:00:44] <CIA-48> GemRB: GSUtils: Don't segfault in MoveNearerTo targets an actor without an area.
[22:00:44] <CIA-48> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[22:01:59] <lynxlynxlynx> sounds like something that should be cherrypicked over
[22:02:04] <tomprince> yes.
[22:03:05] <fuzzie> yes.
[22:03:47] <lynxlynxlynx> go ahead then
[22:08:49] --> edheldil_ has joined #GemRb
[22:17:40] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[22:36:00] <tomprince> https://github.com/tomprince/gemrb/tree/src :) ??
[22:37:07] <fuzzie> is there a way to make git log do --follow automatically?
[22:37:10] <fuzzie> that would be my issue with that
[22:37:44] <fuzzie> (because i can't find anything in git --help config)
[22:38:41] <fuzzie> well, i guess my real problem is 'git log --follow is irritatingly stupid'
[22:42:05] <fuzzie> 'git log --follow gemrb/core/' shows my worry nicely
[22:42:09] <fuzzie> it terminates at the move
[22:42:37] <fuzzie> which is not a huge deal for the core, but would be v.annoying for the GUIScripts
[22:42:52] <fuzzie> so my question is, is there a way to make git do the equivalent of that, if all the paths get moved?
[22:45:00] <tomprince> Don't know.
[22:46:40] <fuzzie> i figured. :)
[22:47:11] <fuzzie> i guess it is a good idea anyway, it drives us all mad, i just hate the way it breaks easy history viewing
[22:47:34] <tomprince> I am actually preparing someting more radical. :)
[22:49:20] <tomprince> Branch src2. (not all references there, nor autotools are updated).
[22:52:51] <fuzzie> that i don't like
[22:54:31] <fuzzie> i can see it might be nice to move the data out
[22:55:10] <tomprince> I was thinking, if we are moving things about, might as well do everything we want to do, to limit the git-log pain.
[22:55:48] <fuzzie> yes
[22:56:00] <fuzzie> but you do quite a bit there
[22:56:19] <fuzzie> i guess you'd have to ask the others
[22:56:41] <tomprince> Well, I leave it there for people to think about. :)
[22:57:01] <fuzzie> well, you know what we're like with forgetting things
[22:57:02] <tomprince> I did say it was radical ;)
[22:57:38] <fuzzie> ok, that party AI thing was more broken than i thought
[23:00:00] <fuzzie> i'm not sure it's so radical, but a matter of personal taste, which is always difficult :)
[23:05:17] <tomprince> I think perhaps at least src/docs -> doc and src/includes -> src/include?
[23:05:35] <fuzzie> i'm not sure
[23:06:05] <fuzzie> it is past midnight here, it is a bad time to ask me, i am even grumpier than usual
[23:06:16] <tomprince> :)
[23:16:48] <CIA-48> GemRB: 03fuzzie * r6d145af0532d 10gemrb/gemrb/core/ (3 files in 3 dirs): run ClearTriggers at the right time, try fixing disabled party AI
[23:17:52] <fuzzie> and thus begins the 'breaking everything', i imagine
[23:41:05] <BaldimerBrandybo> i have a question
[23:41:08] --- BaldimerBrandybo is now known as Drakkar
[23:41:11] <Drakkar> er
[23:41:12] <Drakkar> brb
[23:41:13] <-- Drakkar has left IRC (Quit: The beer is meal.)
[23:41:30] --> Drakkar has joined #GemRb
[23:41:34] <Drakkar> k
[23:41:48] <Drakkar> say someone were to fuse the entirety of baldur's gate for example into a single map
[23:41:57] <Drakkar> are there any limitations they'd have to be aware of
[23:42:33] <fuzzie> other than it being a crazy impossible task to make the scripting work?
[23:42:52] <fuzzie> i think you'd probably hit a 32k width/height limit somewhere
[23:51:29] --> |Cable| has joined #GemRb
[23:51:36] <Maighstir> Baldur's Gate city becomes roughly a 12800x9500 px image... I don't know how much that would expand doing the same for the whole game the whole game, but more than 32000px height is a given, keeping in mind that some areas require some stitching between them
[23:53:40] <-- |Cable| has left IRC (Client Quit)
[23:54:15] --> |Cable| has joined #GemRb
[23:55:06] <-- |Cable| has left IRC (Remote host closed the connection)
[23:56:44] --> |Cable| has joined #GemRb