#gemrb@irc.freenode.net logs for 22 May 2010 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage

[00:07:21] --> cubathy has joined #GemRb
[00:26:26] <tomprince> http://github.com/tomprince/gemrb/branches/savegame has the finished? savegame changes.
[00:28:53] <-- cubathy has left IRC (Quit: Leaving)
[02:54:56] --> raevol has joined #GemRb
[03:11:36] <CIA-24> GemRB: 03tom.prince * rcac3740d12c2 10gemrb/gemrb/core/ (GSUtils.cpp GSUtils.h GameScript.cpp):
[03:11:36] <CIA-24> GemRB: Make GUI 'Character Subtitles' option work.
[03:11:36] <CIA-24> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[03:31:01] --> cubathy has joined #GemRb
[03:33:05] <-- cubathy has left IRC (Remote host closed the connection)
[03:40:33] <CIA-24> GemRB: 03tom.prince * ra6ebf8b174b2 10gemrb/gemrb/core/ (5 files):
[03:40:33] <CIA-24> GemRB: GameScript: Move initialization out of constructor.
[03:40:33] <CIA-24> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[03:51:42] <CIA-24> GemRB: 03tom.prince * rbedd0357b656 10gemrb/gemrb/core/ (GameScript.cpp GameScript.h):
[03:51:42] <CIA-24> GemRB: GameScript: Let cache script handle choosing SClass_ID.
[03:51:42] <CIA-24> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[04:16:04] <CIA-24> GemRB: 03tom.prince * rfb0a08bb00de 10gemrb/gemrb/ (7 files in 3 dirs):
[04:16:04] <CIA-24> GemRB: GameScript: Pass MySelf to constructor, rather than setting it after.
[04:16:04] <CIA-24> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[07:47:31] --> cubathy has joined #GemRb
[08:05:21] <-- cubathy has left IRC (Remote host closed the connection)
[09:45:01] <-- raevol has left IRC (Quit: Leaving.)
[11:12:15] --> Gekz has joined #GemRb
[12:37:24] --> Gekz_ has joined #GemRb
[13:59:11] <-- Gekz_ has left IRC (Remote host closed the connection)
[14:05:24] <-- budlust has left IRC (Remote host closed the connection)
[14:05:43] --> budlust has joined #GemRb
[14:42:16] --> Gekz_ has joined #GemRb
[14:50:47] <-- Gekz has left IRC (Quit: Leaving)
[15:33:11] --> cubathy has joined #GemRb
[15:51:10] <-- cubathy has left IRC (Quit: Leaving)
[16:28:47] <tomprince> It doesn't seem like anything at all uses scriptType or Locals in GameScript.
[16:29:28] <tomprince> Unless scriptType should be used, instead of the scriptType of the sender, in which case things are broken.
[16:31:35] <fuzzie> i can't think of a reason why you'd have locals for a GameScript
[16:33:31] <fuzzie> seems obvious old junk, given 4bd48cc0..
[16:34:28] <fuzzie> i mean, dating back to the days where there was actually a new GameScript for everything
[16:34:43] <tomprince> How about scriptType?
[16:34:52] <fuzzie> is that used at all, anywhere? i don't see
[16:35:24] <fuzzie> but it doesn't seem like it
[16:35:26] <tomprince> No, it isn't. But it seems that the scriptType doesn't always match that of the sender...
[16:35:41] <fuzzie> but if it's completely unused for any purpose ever, does it matter?
[16:35:55] <fuzzie> i mean, if i 'grep -i scripttype' on all the source files, i see nothing
[16:36:22] <tomprince> Well, I was just wondering if it should is all. Before I remove it, and lose that information.
[16:36:37] <fuzzie> ah
[16:36:43] <fuzzie> no, i'm pretty sure that's irrelevant
[16:37:04] <fuzzie> this junk lends credence to your theory about the script change thing, too
[16:37:10] <tomprince> One example, is cutscenes are set at ST_GLOBAL, regardless of the sender.
[16:37:36] <fuzzie> you can ignore that
[16:37:41] <fuzzie> cutscenes are handled incorrectly atm anyway
[16:37:55] <fuzzie> i think i explained this: they shouldn't be executed at all
[16:38:41] <fuzzie> you have to look at the first entry in every block, pick the object out, and then dump the rest of the actions directly onto the queue of that object
[16:39:54] <fuzzie> and i think doing that would get rid of our remaining hacks for cutscenes entirely
[16:39:55] <CIA-24> GemRB: 03tom.prince * rd8e26b4da9fd 10gemrb/gemrb/ (7 files in 3 dirs):
[16:39:55] <CIA-24> GemRB: GameScript: Cleanup obsolete cruft.
[16:39:55] <CIA-24> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[16:42:43] <tomprince> So we need a completely different execute path for cutscenes?
[16:43:47] <fuzzie> well, 'execute' is not really what it's doing :) but yes
[16:45:33] <tomprince> Well, that makes things easier for me. Sort of. :)
[16:46:02] <tomprince> I am planning on adding support for python game scripts.
[16:46:06] <fuzzie> fortunately all the cutscene logic is firmly on the "BGScript-specific" side of the divide
[16:46:38] <fuzzie> since the action queue is entirely BGScript-specific anyway, it doesn't matter if it's messing with it..
[16:47:48] <fuzzie> and, yes, we discussed this before, a viable idea right up until the point where you want to use it in an existing game, imo :)
[16:48:17] <tomprince> What is the issue with using it in an existing game?
[16:48:29] <fuzzie> it doesn't map onto the existing scripting model at all.
[16:48:55] <fuzzie> so something calls ActionOverride on something running a python script, what do you do?
[16:49:48] <fuzzie> or any of the other actions which have complicated interactions with the scripting system
[16:50:42] <fuzzie> if you just throw the old scripting system out, then it's easy, you just don't worry about any of it, and use a set of effects which doesn't interfere, etc..
[16:51:53] <fuzzie> as it is, it seems you'll either end up with a very buggy system, or some complex interface layer which will make it difficult to implement all the subtle BGScript interactions which break half the quests atm
[16:52:51] <tomprince> Well, I am not entirely convinced that ActionQueue is IE specific. Although, I must admit, that I not familiar with all the intracacies of the scripting language.
[16:54:12] <tomprince> My first step was to figure out a way to expose all the bits of GameScript to python, and write a converter.
[16:54:48] <fuzzie> well, it might be possible to write something
[16:54:56] <fuzzie> but just things like the blocking actions sound painful to do
[16:55:23] <tomprince> Basically, allowing you to write gamescript, but in a structured language
[16:56:41] <fuzzie> but i guess it's more viable if you're willing to stick with basically all the limitations of BGScript, except for the fact you can have python logic messing with the queue
[16:58:06] <tomprince> That is where I was going to start, anyway.
[17:01:05] <tomprince> Then, long term, my idea was to try to factor the actions into the bits that are specific to the limitation of the BGScript language, and the bits that aren't.
[17:01:36] <tomprince> In particular, the whole LastSeenBy seems to me to really be a hack around the lack of local variables, for example.
[17:04:31] <tomprince> Unrelated, when you have some time, could you review the savegame branch. I think that it is ready to go.
[17:05:38] <fuzzie> well, if i were doing it, i imagine i wouldn't touch the actions at all
[17:06:08] <fuzzie> because they're *all* hacks around the limitations of the language, really :)
[17:07:16] <fuzzie> but i would warn you against trying to learn too much from gemrb's implementation, i only patched it up enough to make the games completable, it's nowhere near correct..
[17:07:53] <tomprince> I'll keep that in mind.
[17:08:13] <fuzzie> and i already had to de-sabotage it from Avenger's attempts over the years, so i am a bit protective :)
[17:10:09] <fuzzie> re savegame branch: please do some serious testing if you're going to explore Holder<> across library boundaries
[17:11:11] <tomprince> Well, i think my thouight is that the queue is useful, so I'd like to seperate out the bits that go on the queue from the bits that don't.
[17:11:31] <tomprince> Although, right now, I am just playing around, and figuring out how things work and how they are related.
[17:11:53] <fuzzie> the GUIScript Sprite2D commit could maybe do with the Sprite2D changes being another commit?
[17:12:51] <fuzzie> and 'Auto-Save' doesn't seem like a spectacularly good idea for a default for savegame.2da
[17:14:42] <-- Gekz_ has left IRC (Read error: Connection reset by peer)
[17:14:44] <tomprince> I am open to suggestions for that. I think it is appropriate for iwd2, since that is the prefix that is used for the strref save game names.
[17:14:44] <fuzzie> can't try building it right now, though.
[17:15:05] --> Gekz has joined #GemRb
[17:20:44] --> raevol has joined #GemRb
[18:36:20] --> cubathy has joined #GemRb
[18:41:15] <-- cubathy has left IRC (Ping timeout: 248 seconds)
[18:54:24] --> Avenger has joined #GemRb
[18:54:29] --- ChanServ gives channel operator status to Avenger
[18:54:31] <Avenger> hi
[18:54:38] <Avenger> some recent change screwed my cache path config
[18:54:53] <Avenger> i see this --> [Core]: Cache path /./Cache doesn't exist, not a folder or contains alien files!
[18:55:09] <Avenger> for some reason gemrb puts a / before ./Cache/
[18:55:42] <fuzzie> how recent?
[18:55:44] <tomprince> Let me have a look at that.
[18:55:56] <tomprince> I know where that is.
[18:56:15] <fuzzie> ok, i will leave you in tomprince's hands and go finish baking :)
[18:56:41] <Avenger> :)
[19:04:17] <tomprince> Does changing core/VFS.cpp:415 to PathJoin(FilePath, TempFilePath[0]==PathDelimiter?SPathDelimiter:"", TempFilePath, NULL);
[19:04:20] <tomprince> fix it?
[19:05:49] <Avenger> will look
[19:07:49] <Avenger> mine had filepath,"/",tempfilepath
[19:08:04] <Avenger> i wonder why it had "/" in it
[19:08:23] <Avenger> just removing "/" fixed
[19:08:39] <Avenger> shouldn't that be enough?
[19:08:46] <tomprince> But that will break if you have any absolute file paths.
[19:09:04] <tomprince> because PathJoin strip leading slashes.
[19:10:56] <Avenger> not for me
[19:11:17] <Avenger> it works for me with absolute path
[19:11:30] <tomprince> They get added back in PathAppend, unless target is empty, which it is coming from ResolveFilePath.
[19:12:34] <Avenger> so?
[19:13:10] <Avenger> is there any case where this breaks?
[19:13:21] <tomprince> Well, if it works for you, then I am not sure what is going on.
[19:13:42] <tomprince> I know that absolute paths didn't work for me without the "/"
[19:14:02] <Avenger> odd, i have casesensitive turned off
[19:14:55] <tomprince> ?
[19:15:15] <Avenger> well i thought that's the difference between our configs
[19:16:18] <tomprince> Is your casesensitve setting after the cache setting?
[19:17:24] <tomprince> And then your absolute paths are after the CaseSensitive ... right?
[19:18:18] <fuzzie> ouch, the ResolveFilePath calls being there is a bug i hadn't thought about
[19:19:47] <Avenger> hmm
[19:20:45] <Avenger> ok, i don't know what's wrong now
[19:21:14] <tomprince> Did
[19:21:22] <tomprince> I correctly describe your config?
[19:21:41] <Avenger> CaseSensitive = 1 was the last line
[19:22:11] --> kettuz has joined #GemRb
[19:22:35] <Avenger> but now it doesn't even run
[19:23:32] <fuzzie> missing a newline at the end?
[19:23:44] <Avenger> no
[19:23:59] <Avenger> there are some comments after it
[19:24:13] <Avenger> [Core]: Initializing KEY Importer...[KEYImporter]: Opening /dosd/bg1/chitin.key...[ERROR]
[19:24:15] <Avenger> [KEYImporter]: Cannot open Chitin.key
[19:24:16] <Avenger> [ERROR]
[19:24:18] <Avenger> Segmentation fault
[19:24:19] <Avenger> i see this
[19:24:28] <Avenger> bg1 is upper case in my ntfs file system
[19:25:08] <fuzzie> that printed path should be case-corrected
[19:25:59] <Avenger> it is not correct at all
[19:26:07] <Avenger> i have BG1/Chitin.key
[19:26:57] <CIA-24> GemRB: 03tom.prince * r1bf73457b924 10gemrb/gemrb/core/VFS.cpp:
[19:26:57] <CIA-24> GemRB: VFS: Allow relative paths in ResolveFilePath.
[19:26:57] <CIA-24> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[19:27:13] <Avenger> i wonder why this doesn't work now
[19:27:14] <fuzzie> and you put the CaseSensitive=1 in there, before the paths?
[19:27:19] <tomprince> That is certainly a fix, but it seems there might be more going on.
[19:27:40] <fuzzie> well, someone has to move those ResolveFilePath calls
[19:27:47] <Avenger> no, i have it after the paths
[19:27:49] <Avenger> hmm
[19:28:00] <fuzzie> until then, the CaseSensitive=1 has to be before the paths.
[19:28:21] <Avenger> i have moved it before them
[19:28:23] <Avenger> same
[19:29:10] <Avenger> so tom made several changes it seems :D
[19:29:13] <fuzzie> that is weirder
[19:29:24] <Avenger> the first pathjoin may have been around for longer
[19:29:29] <Avenger> that's what i found first
[19:29:37] <Avenger> now i made recompile, and this second problem came out
[19:29:42] <fuzzie> hm
[19:29:47] <fuzzie> you used tom's fix, and not yours?
[19:30:06] <fuzzie> because removing the "/" could maybe lead to your bug, because it gives up on resolving the absolute path
[19:30:35] <Avenger> i see
[19:30:40] <Avenger> i used my fix
[19:31:14] <Avenger> will try his
[19:31:35] <fuzzie> it is annoying how we swapped one set of bugs for another, here
[19:32:13] <fuzzie> but i guess these are fixable
[19:32:16] <Avenger> yeah, i tried to set my configs different ways but none had absolute cache paths
[19:32:27] <Avenger> on the other hand, my game paths are absolutes
[19:32:40] <Avenger> so i don't quite see why we needed these new things
[19:33:07] <fuzzie> they stop the code from trying to resolve all the paths repeatedly every time it wants to load a file
[19:33:11] <Avenger> anyway, now i will have one config with absolute path
[19:33:18] <fuzzie> which can be pretty slow, on some filesystems
[19:33:58] <Avenger> ok, now it seems works
[19:34:09] <tomprince> Have a look at or.cz/resolvefilepath. I think it handles the config loading properly wrt casesensitive.
[19:34:48] <fuzzie> are those paths always initialised? i remember they used not to be
[19:35:00] <fuzzie> it looks like exactly what i'd suggest, otherwise
[19:35:44] <Avenger> http://or.cz/resolvefilepath ?
[19:36:23] <tomprince> http://repo.or.cz/w/gemrb.git/shortlog/refs/heads/resolvefilepath
[19:37:28] <Avenger> hmm calling the resolves only after settling casesensitive makes sense
[19:37:56] <Avenger> if that's what you wanted to do
[19:38:04] <fuzzie> yeah, that's basically what it's doing
[19:38:11] <fuzzie> i would just commit it and see :)
[19:39:10] <tomprince> After fixing the bug in it, of course. :)
[19:39:26] <Avenger> well, i just wanted to check if antidotes really don't work as San reported on the forum
[19:39:53] <Avenger> they should be a very simple effect removal opcode
[19:40:00] <CIA-24> GemRB: 03tom.prince * r37deec9717a5 10gemrb/gemrb/core/Interface.cpp:
[19:40:00] <CIA-24> GemRB: LoadConfig: Don't call ResolveFilePath until after loading Config.
[19:40:00] <CIA-24> GemRB: Otherwise, the setting of CaseSensitive is handled properly.
[19:40:00] <CIA-24> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[19:40:42] <fuzzie> for some reason (maybe my fault), the effect removal stuff is in Draw or somewhere equally silly
[19:41:09] <fuzzie> so effect removal gets lagged a bit, and of course doesn't work when paused etc, which leads to weird bugs
[19:42:20] <fuzzie> similar problem with lots of people reporting they're unable to learn spells: trying to learn from a scroll fires a projectile, so the learn doesn't work until the game is unpaused
[19:42:26] <Avenger> drinking potions is fine when they don't work during pause
[19:42:54] <Avenger> even if some of the game versions allow it
[19:43:05] <fuzzie> sure, but people get confused by it :) i think it actually works fine
[19:43:16] <Avenger> ok
[19:43:22] <fuzzie> or it did last time i checked, anyway
[19:43:51] <Avenger> the graphical effect (projectile) is misplaced, a bit
[19:44:00] <Avenger> but otherwise it seemed to work
[19:45:35] <fuzzie> i'm more worried about the crash thing which was mentioned
[19:47:34] <-- raevol has left IRC (Quit: Leaving.)
[19:53:24] <CIA-24> GemRB: 03tom.prince * r09eb31183bda 10gemrb/gemrb/core/Interface.cpp:
[19:53:24] <CIA-24> GemRB: LoadConfig: Add sensible default for CD?.
[19:53:24] <CIA-24> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[19:53:43] <Avenger> more than one crash thing
[19:53:52] <Avenger> one is some spellbook corruption
[19:53:57] <Avenger> the other is an actor problem
[19:54:03] <Avenger> could be connected somehow
[19:54:13] <Avenger> tried to use his savegames_
[19:54:24] <Avenger> tried to use his savegames?
[19:55:25] <Avenger> it could be that there is a simple bug in the creature importer :)
[19:55:27] <fuzzie> i think the actor thing is just an old gemrb version
[19:55:36] <-- budlust has left IRC (Ping timeout: 272 seconds)
[19:55:38] <Avenger> oh you mean it was already fixed?
[19:55:45] <fuzzie> we fixed something there, i forget what
[19:55:59] <Avenger> i hope his savegame is not corrupted
[19:56:27] <Avenger> though, even if it is corrupted, we should never crash on it :)
[19:56:35] <fuzzie> and the spellbook thing is probably some path that i didn't protect..
[19:56:56] <Avenger> at import?
[19:57:02] <fuzzie> yes
[19:57:10] <Avenger> because the crashy code itself seems to be extra careful
[19:57:39] <fuzzie> it used to create bad data at chargen, but we fixed that, at least
[19:57:53] <fuzzie> i forget exactly what, and i don't have the code here..
[19:58:57] <Avenger> CREKnownSpell* CREImporter::GetKnownSpell()
[19:59:03] <Avenger> this one could be more careful
[19:59:11] <Avenger> it could check level
[20:00:37] <Avenger> actually, the code that processes known_spells list seems to be safe
[20:00:51] <Avenger> it checks the level and adds only valid spells
[20:03:06] <Avenger> i'll be back tomorrow, see you!
[20:03:07] <-- Avenger has left IRC (Quit: bye!)
[20:04:32] <fuzzie> the problem is, of course, that the array has gaps in it
[20:04:50] <fuzzie> see my comment "this code previously added NULLs, leading to crashes"
[20:04:55] <fuzzie> but i guess that didn't cover all cases
[20:19:24] --> Maighstir_laptop has joined #GemRb
[21:02:30] <-- kettuz has left IRC (Quit: Leaving)
[21:48:56] --> cubathy has joined #GemRb
[22:03:02] --> budlust has joined #GemRb
[22:04:35] <-- cubathy has left IRC (Ping timeout: 258 seconds)
[23:01:47] <tomprince> gemrb running in kvm with gamefiles on samba is slow...
[23:05:48] <fuzzie> just because of all the re-opens?
[23:06:41] <fuzzie> it seemed reasonably fast for me over samba, after stopping all the repeated path resolving
[23:07:06] <fuzzie> wasn't using kvm, though, stuck with vmware for sane DirectDraw support :|
[23:09:13] <tomprince> It may be a case sensitiviy issue, with samba checking case on every access. I am recompiling now with case-sensitive support.
[23:10:23] <fuzzie> although, hey, the relevant virtualbox bugs got closed last week
[23:13:47] <fuzzie> well, for my part, any filesystem access fixes on the gemrb side appreciated, although i am pretty sure samba is not a realistic situation :) ninight
[23:14:27] <tomprince> Night.
[23:14:54] <tomprince> Well, I don't want to *play* over samba. :)
[23:19:05] <fuzzie> well, people do such things -- can be a lot easier to get a network connection to a console/etc than a disk :)