[00:05:55] <tomprince> What happens if a gamescript has a ChangeCurrentScript action, and a single actor has that script at multiple levels?
[00:17:39] <tomprince> I am starting to try to refactor the gamescript code at or.cz/gamescript.
[01:01:34] <-- budlust has left IRC (Ping timeout: 264 seconds)
[01:02:50] --> budlust has joined #GemRb
[01:40:44] --> Gekz has joined #GemRb
[01:41:03] <-- tomprince_loki has left IRC (Quit: tomprince_loki)
[03:04:56] <-- Gekz_ has left IRC (Quit: This computer has gone to sleep)
[03:48:06] --> raevol has joined #GemRb
[06:00:24] <-- Edheldil_ has left IRC (Remote host closed the connection)
[06:00:41] <-- raevol has left IRC (Quit: Leaving.)
[06:09:11] --> Gekz_ has joined #GemRb
[08:27:05] <-- |Cable| has left IRC (Remote host closed the connection)
[09:16:17] <fuzzie> tomprince: i'm pretty sure we already discussed the "don't hard-code AI script locations" thing
[09:18:10] <fuzzie> and the hack commit is the mix of a move and other things, which is impossible to review..
[09:22:56] <fuzzie> but i don't see the problem with ChangeCurrentScript; doesn't it just work?
[09:24:17] <fuzzie> oh i see, you broke it in your hack
[09:25:45] <fuzzie> i'm not sure what you're asking, in that context
[09:27:35] <fuzzie> the existing code is replicating what the original engine does, i think, but i think it keeps multiple copies of scripts around, so
[09:31:45] <fuzzie> the actions don't seem to be shared in the original engine, though
[09:32:31] <fuzzie> but i don't have enough knowledge of iwd2 to know, it might well actually just stomp over at first-load, i wouldn't be surprised
[09:33:08] <fuzzie> nor of iwd1
[09:36:26] <fuzzie> and that seems to be it
[09:38:53] <fuzzie> so, </incoherency>
[12:58:14] <-- budlust has left IRC (Remote host closed the connection)
[12:58:32] --> budlust has joined #GemRb
[12:59:52] <-- budlust has left #GemRb
[13:27:18] --> lynxlynxlynx has joined #GemRb
[13:27:18] --- ChanServ gives channel operator status to lynxlynxlynx
[13:38:28] <tomprince> Well, since we cache scripts, changecurrentscript will only be handled right for the first sciptlevel it is loaded for. Which probably isn't an issue in the original games.
[13:39:09] <tomprince> Mostly, I was wondering if anybody had any ideas on how else changecurrentscript could be implemented.
[13:42:28] <tomprince> fuzzie: We did discuss it. I am not convinced that how we handle it isn't just an artifact of having had one file loading path, and expediency. But, I am not wedded to that change. I just thing it is more logical (although I do know how logical the original engines are). :)
[13:44:13] <tomprince> The hack commit is just a move + me pondering chnagecurrentscript.
[13:45:41] --> tomprince_loki has joined #GemRb
[14:04:11] <fuzzie> well, again, it seems like you wanting to remove useful functionality :)
[14:04:41] <fuzzie> but i'm not sure about changecurrentscript.
[14:04:57] <fuzzie> please add a warning about the action differing from the original if you don't use int0Parameter, though.
[14:05:08] <tomprince_loki> Okay.
[14:06:59] <fuzzie> (but it *is* a seperate action in the original)
[14:24:28] <tomprince_loki> I'm just not convinced that is functionality. :) But that is an argument for another time.
[14:24:47] <fuzzie> well, the ability to package AI scripts in .bif files is surely functionality
[14:25:03] <fuzzie> even if the current code is broken
[14:25:52] <fuzzie> no idea about the rest, which i still haven't had time to test
[14:26:38] <tomprince_loki> The rest doesn't compile, due to the changescript thing. :)
[14:27:37] <fuzzie> but as with the savegame strref code, you just seem, well, very much wanting to remove code instead of fixing it :)
[14:28:22] <fuzzie> while the whole point of gemrb is to add flexibility everywhere we can; otherwise you can remove a whole bunch of code and hard-code the original engine behaviour
[14:29:51] <fuzzie> (which would obviously be a lot easier to do; that modal stuff could all be done by now, were it just a hard-coded switch statement)
[14:30:15] <tomprince_loki> I agree that adding flexibility is a good thing.
[14:31:23] <tomprince_loki> And I don't plan to remove the savegame strref code. It just seemed like random unused code. Now that I know it is used, I just need to figure out how to refactor it.
[14:32:42] <tomprince_loki> And I don't know about adding flexibility *everywhere*. Just everywhere it make sense.
[14:33:14] <tomprince_loki> It seems to me, since AI scripts are entirely player provided, that it makes sense to keep them seperate from the game data.
[14:34:29] <fuzzie> but then, all the mod data is entirely player provided.
[14:35:07] <tomprince_loki> I wouldn't say that.
[14:35:08] <fuzzie> and, yes, i can see that a seperate setup would make sense, but hard-coded to a single directory?
[14:35:44] <tomprince_loki> Well, relatively easy to make it not hard-coded.
[14:37:54] <tomprince_loki> It is hard-coded now in GemRB, unless you throw it in overrides or sounds, or portraits or ...
[14:38:42] <fuzzie> or anything else you add to the immediately-obvious search path :)
[14:41:09] <tomprince_loki> What I mean about the mods, is that once you have picked the mods you are going to play, then it is reasonable to treat that as the game-data, that isn't player viewable/modifiable, but that AI scripts remain so.
[15:56:17] <-- Gekz has left IRC (Quit: Leaving)
[16:16:46] --> kettuz has joined #GemRb
[17:54:41] --> cubathy has joined #GemRb
[18:23:48] --> budlust has joined #GemRb
[18:47:48] --> tombhadAC has joined #GemRb
[19:04:26] <-- tomprince_loki has left IRC (Ping timeout: 240 seconds)
[19:20:58] <Lightkey> fuzzie: are you bored with GemRB? ;-)
[19:22:31] <Lightkey> watching commits to ScummVM go by referencing patches from you
[19:58:45] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[20:25:29] --> |Cable| has joined #GemRb
[20:35:28] <-- tombhadAC has left IRC (Quit: Verlassend)
[20:42:05] <-- budlust has left IRC (Remote host closed the connection)
[20:42:22] --> budlust has joined #GemRb
[21:02:25] <-- kettuz has left IRC (Quit: Leaving)
[21:27:00] <fuzzie> Lightkey: just a bit annoyed at the lack of progress on BRA, so i filed a few of my local patches :)
[21:35:17] <-- cubathy has left IRC (Ping timeout: 258 seconds)
[21:36:55] <fuzzie> i'm always encouraged by how well people respond to such things, i should run more open source projects under gdb
[22:05:43] <tomprince> fuzzie: Would it be reasonable to key using strref save game names off a gemrb.ini key, rather than the default value of savegame.2da?
[22:06:12] <fuzzie> well, it sounds like a much better idea to me
[22:06:19] <fuzzie> but i don't know why it is like it is :)
[22:07:29] <fuzzie> for easier modding, maybe, but i think the long-term solution there is really to allow key overrides somehow
[22:08:52] <fuzzie> i really like the GameFeatures flags idea though, i am going to steal it for a different engine where checking game types is driving me mad
[22:09:32] <tomprince> Well, I think the real trick to easier modding is getting some of the modders interested in GemRB, so support can be driven by things they actually need. :)
[22:10:38] <fuzzie> well, for that, i look at it the other way: how to implement support for some of the existing engine mods into gemrb
[22:12:43] <fuzzie> although i should insert the disclaimer here that i really don't care very much about bg2 mods, as you can probably tell by my general cluelessness about bg2 mods
[22:22:19] <tomprince> or.cz/python has the GF implementation. Untesetd, since I don't know eneough about IWD2.
[22:27:43] --> barra_library has joined #GemRb
[22:27:51] --- barra_library is now known as barra_home
[22:30:53] --> mvbarracuda_libr has joined #GemRb
[22:31:19] --- mvbarracuda_libr is now known as barra_alt
[22:34:54] <-- barra_home has left IRC (Ping timeout: 276 seconds)
[22:46:11] --> mvbarracuda_libr has joined #GemRb
[22:49:40] <-- barra_alt has left IRC (Ping timeout: 252 seconds)
[23:01:56] <-- mvbarracuda_libr has left IRC (Read error: Connection reset by peer)
[23:02:04] --> mvbarracuda has joined #GemRb
[23:22:18] <-- mvbarracuda has left IRC (Quit: Verlassend)