[00:09:47] <-- budlust has left IRC (Read error: Connection reset by peer)
[00:12:45] --> budlust has joined #GemRb
[03:02:11] <-- Maighstir_laptop has left IRC (Ping timeout: 264 seconds)
[03:50:06] --> raevol has joined #GemRb
[04:21:30] --> Gekz has joined #GemRb
[04:50:25] <-- budlust has left #GemRb
[04:58:00] <-- Gekz has left IRC (Quit: This computer has gone to sleep)
[05:18:10] --> Gekz has joined #GemRb
[05:29:37] --> cubathy has joined #GemRb
[05:40:31] <-- cubathy has left IRC (Ping timeout: 258 seconds)
[05:40:35] <CIA-24> GemRB: 03tom.prince * ra1a22cd9e605 10gemrb/gemrb/core/Interface.cpp: Interface: Don't crash on missing global palettes.
[05:50:35] <tomprince> or.cz/opcode: This probably makes EffectQueue easier to understand.
[06:19:46] <-- Gekz has left IRC (Quit: This computer has gone to sleep)
[06:57:28] <-- raevol has left IRC (Quit: Leaving.)
[07:03:59] <-- |Cable| has left IRC (Remote host closed the connection)
[07:32:44] --> Gekz has joined #GemRb
[07:45:36] <fuzzie> maybe 'effect_id' or something?
[07:46:01] <fuzzie> or maybe it's clear enough as opcode, i just always found that name confusing
[08:20:17] --> lynxlynxlynx has joined #GemRb
[08:20:18] --- ChanServ gives channel operator status to lynxlynxlynx
[08:27:17] <fuzzie> lynxlynxlynx: you need some help with the effect stuff?
[08:28:47] <lynxlynxlynx> maybe, i figured the last problem that bugged me
[08:29:09] <lynxlynxlynx> but i'm sure new will crop up
[09:49:04] <-- Gekz has left IRC (Quit: This computer has gone to sleep)
[09:53:55] <lynxlynxlynx> http://gcc.gnu.org/onlinedocs/libstdc++/manual/profile_mode.html <-- anyone tried this?
[10:28:41] <fuzzie> i doubt it
[11:06:08] --> Gekz has joined #GemRb
[11:41:57] --> Maighstir has joined #GemRb
[13:20:52] --> budlust has joined #GemRb
[13:21:08] <-- budlust has left #GemRb
[14:47:56] --> kingron has joined #GemRb
[14:49:50] --> budlust has joined #GemRb
[14:59:56] <tomprince> Don't we already use opcode everwhere, and that seems to be what the iedsp calls it. At least if I read the code correctly.
[15:14:27] <-- Maighstir has left IRC (Quit: Maighstir)
[15:23:01] <-- budlust has left #GemRb
[15:28:40] <fuzzie> well, i just mean, if your goal is "easier to understand" :)
[15:33:39] <tomprince> Well, part of that is consistent naming.
[15:33:56] <tomprince> I don't want to do a global replace on Opcode, and that doesn't take care of iedsp.
[15:34:31] <tomprince> Though, in isolation, effect_id might be easier to understand.
[15:34:58] <tomprince> My main concern was splitting EffText, since in most cases, it wasn't efftext at all.
[15:36:48] <fuzzie> nothing depends on that?
[15:37:49] --> Gekz_ has joined #GemRb
[15:37:49] <-- Gekz_ has left IRC (Client Quit)
[15:37:56] <tomprince> Well, I didn't change anything but the names.
[15:38:33] <tomprince> I just matched the names to what to what the code was actualling doing, and storing in there.
[15:39:27] <tomprince> So, unless I am reading the code wrong, the code depends on what is now called opcode being that, and same with strref.
[15:42:16] <fuzzie> well, i mean, did you rename, or split?
[15:42:50] <tomprince> Both.
[15:43:55] <fuzzie> so my question seems a good one, there are cases in the code where a field is shared because things depend on that, but it doesn't seem to be the case here
[15:44:13] <tomprince> I split off the single array that used EffText as strref.
[15:45:17] <tomprince> There is only a handleful of uses of it.
[15:45:37] <tomprince> And the opcode field in the other half is in fact and index into that array.
[15:49:49] <-- kingron has left IRC (Quit: Leaving)
[15:50:49] <CIA-24> GemRB: 03tom.prince * r7d54ad8ff53c 10gemrb/gemrb/ (3 files in 2 dirs):
[15:50:49] <CIA-24> GemRB: EffectQueue: Rename things so they make sense.
[15:50:49] <CIA-24> GemRB: s/EffText/opcode/ except for one array where it is s/EffText/Strref/.
[15:50:49] <CIA-24> GemRB: s/effect_refs/Opcodes/
[15:50:49] <CIA-24> GemRB: s/opcode_count/effectnames_count/
[15:50:50] <CIA-24> GemRB: Signed-off-by: Tom Prince <firstname.lastname@example.org>
[15:50:58] --> raevol has joined #GemRb
[16:09:47] <-- raevol has left IRC (Quit: Leaving.)
[16:43:29] <-- Gekz has left IRC (Quit: Leaving)
[16:44:02] --> Gekz has joined #GemRb
[17:00:42] --> barra_library has joined #GemRb
[17:01:21] --> Maighstir has joined #GemRb
[17:05:36] <-- Gekz has left IRC (Remote host closed the connection)
[17:06:03] --> Gekz has joined #GemRb
[17:08:01] <lynxlynxlynx> i'm stuck again :]
[17:09:05] <lynxlynxlynx> it's like the effect gets reapplied later and then the owner is the same as the target and basically the skeleton tries to turn itself or checks itself if it is evil or not, resetting the ea
[17:09:34] <lynxlynxlynx> turning works great if you're good, but this evil domination ...
[17:10:19] <lynxlynxlynx> i'll commit the last work i have, so it will be easier to inspect; there's a backlog already
[17:19:44] <CIA-24> GemRB: 03lynxlupodian * rb5801ced74ba 10gemrb/gemrb/ (8 files in 6 dirs): added another field to the modal.2da table so the aeo spells can be applied
[17:19:56] <CIA-24> GemRB: 03lynxlupodian * r822ce0bb5b70 10gemrb/gemrb/override/how/turn.spl: how: added undead turning spell
[17:19:57] <CIA-24> GemRB: 03lynxlupodian * rc65bc1a3941e 10gemrb/ (7 files in 2 dirs): added an artwork/ dir to store all the logos
[17:19:58] <CIA-24> GemRB: 03lynxlupodian * rddb8ee99bd00 10gemrb/gemrb/core/ (Actor.cpp Actor.h): added Actor::MatchesAlignmentMask and used it to properly check for evil-doers
[17:19:58] <CIA-24> GemRB: 03lynxlupodian * r3b61247c55fc 10gemrb/gemrb/core/Actor.cpp: evil clerics dominate the undead instead of destroying them
[17:19:59] <CIA-24> GemRB: 03lynxlupodian * r52f46321d26c 10gemrb/gemrb/ (core/Actor.cpp plugins/IWDOpcodes/IWDOpcodes.cpp): use defined constants where possible
[17:20:35] <CIA-24> GemRB: 03lynxlupodian * rb71aadc9911a 10gemrb/gemrb/core/Actor.cpp: make sure the undead are in visual range when turning
[17:20:36] <CIA-24> GemRB: 03lynxlupodian * r71be36d2606a 10gemrb/gemrb/plugins/ (3 files in 3 dirs):
[17:20:36] <CIA-24> GemRB: moved fx_retreat_from to PSTOpcodes (works only in PST) and reused
[17:20:36] <CIA-24> GemRB: it elsewhere for turning undead (effect only in how/iwd2)
[17:20:37] <CIA-24> GemRB: 03lynxlupodian * r98dbd2c77fe2 10gemrb/gemrb/override/ (iwd2/turn.spl shared/turn.spl): turn.spl: added for other games except pst
[17:20:37] <CIA-24> GemRB: 03lynxlupodian * racc0fcc0cefc 10gemrb/gemrb/core/EffectQueue.cpp: print the actor name when an effect is resisted
[17:20:39] <CIA-24> GemRB: 03lynxlupodian * rcdb2230b850d 10gemrb/gemrb/core/Interface.cpp: Init: fixed the table loading text for game script stuff
[17:20:40] <CIA-24> GemRB: 03lynxlupodian * r1d6857b89ebe 10gemrb/gemrb/core/Actor.cpp:
[17:20:40] <CIA-24> GemRB: Actor::Turn: fixed the targetting (somewhat) and added some temporary hacks
[17:20:40] <CIA-24> GemRB: due to problems in the evil path
[17:20:41] <CIA-24> GemRB: 03lynxlupodian * rda2aae79d4db 10gemrb/ (19 files in 5 dirs):
[17:20:41] <CIA-24> GemRB: Merge branch 'master' of ssh://gemrb.git.sourceforge.net/gitroot/gemrb/gemrb
[17:20:41] <CIA-24> GemRB: Conflicts:
[17:20:41] <CIA-24> GemRB: gemrb/core/EffectQueue.cpp
[17:20:41] <CIA-24> GemRB: (only a printf)
[17:21:07] <fuzzie> whee :)
[17:23:42] <lynxlynxlynx> a good cleric kicks ass in the tombs, especially with our buggy round timing
[17:24:17] <lynxlynxlynx> everything just explodes around him :)
[17:30:08] <lynxlynxlynx> ok, so let me explain a few of the tricks
[17:31:40] --> kingron has joined #GemRb
[17:32:01] <lynxlynxlynx> before i set the effect target to FX_TARGET_PRESET, the effect was added to the cleric instead, but now it is rightly applied on the target, but then it gets added to its fxqueue, so the next applications have the wrong owner
[17:32:27] <lynxlynxlynx> it's a bit odd that the effect is permanent too
[17:33:27] <lynxlynxlynx> without the this != cleric hack, the actors reexecuted the effect on themselves, so evil turning always resulted in panic
[17:33:43] <lynxlynxlynx> (skeletons have turnundead level of 0, of course)
[17:34:49] <lynxlynxlynx> now i think the control never happens, since they keep reexecuting the effect and resetting the ea to enemy (this is the effect of the first issue)
[17:37:42] <lynxlynxlynx> just copying the few relevant lines from the effect would work, but it wouldn't solve the issue that turning is permanent; a similar problem is with the current panic path, but that's for later
[17:39:12] <tomprince> Would it make sense to split the effect?
[17:39:32] <tomprince> So that the effect that get applied to the caster is different from the one applied to the undead?
[17:40:51] <lynxlynxlynx> not really
[17:41:24] <lynxlynxlynx> undead can't and probably shouldn't be able to cast it and the rest get caught in the ie_generic check
[17:41:40] <lynxlynxlynx> ie_general
[17:48:10] <lynxlynxlynx> the spell that uses that effect is from iwd2 and it has a duration, so i guess it shouldn't be permanent at all
[17:49:31] <tomprince> Looking further, I am wondering why we need an opcode for effects that we lookup by name ....
[17:49:41] <tomprince> (unrelated to the turning stuff)
[17:50:39] <lynxlynxlynx> yeah, it's a bit odd
[17:53:16] <tomprince> The proximate reason is obviously that struct Effect uses the opcode to get the function. But that looks like something that could (should?) be changed.
[17:53:58] <lynxlynxlynx> best to ask Avenger about it
[17:55:00] <lynxlynxlynx> bbl
[18:08:56] --> tomprince_loki has joined #GemRb
[18:21:54] <fuzzie> tomprince_loki: how would you store the effect otherwise?
[18:22:00] <fuzzie> perhaps i am misunderstanding
[18:23:35] <tomprince_loki> I am not entirely sure. The simplest thing would be to just store the function pointer. But then we loose data for logging and stuff.
[18:24:08] <fuzzie> i mean, are these just single-fire effects which are never stored?
[18:24:16] <tomprince_loki> I was just seeing the comment that ControlUndead2 only worked in iwd2/iwd, or some such.
[18:24:53] <fuzzie> oh, right. that is not such a crazy thing because most of the IWD/PST effects are pretty highly specific to a game.
[18:25:50] <tomprince_loki> And the only reason for that is that we haven't assigned an opcode for them. All the code is loaded, and everything...
[18:25:56] <fuzzie> well, no
[18:26:19] <fuzzie> i mean, we want to be careful before using any of them, because most of them rely on things which are not necessarily true in other games.
[18:26:27] <tomprince_loki> I hadn't considered that we might need to save them out at some point.
[18:26:28] <fuzzie> and on lookup tables which are only in iwd/post, etc.
[18:26:31] <fuzzie> erm, pst.
[18:26:48] <fuzzie> i'm not sure if we ever need to save out effects? i am mostly thinking multiplayer serialisation, again
[18:27:23] <fuzzie> (all effect applications should be going via the message queue anyway, otherwise there are sync issues - again, the cause of a lot of quest breakage atm)
[18:27:32] <tomprince_loki> Well, we could serialize them by name.
[18:28:47] <fuzzie> a fair point
[18:29:02] <tomprince_loki> Clearly, certain effect can only be used in certain games. But I don't see why we need to assign an opcode in an external file, when we only refer to them by name.
[18:29:40] <fuzzie> aren't the opcodes used by matching functions too?
[18:30:00] <fuzzie> eg, spells checking whether a certain effect is currently applied
[18:30:21] <tomprince_loki> Maybe? I just looked at the code for the first time yesterday.
[18:31:18] <fuzzie> I still don't understand it :| But it's one of those things where you change the order of two lines and suddenly a quest breaks.
[18:31:38] <fuzzie> (well, I understand most of it, but that is not so helpful when looking for bugs in the rest..)
[18:32:53] <tomprince_loki> Well, my question was prometed by this : // HACK: currently only works in how and iwd2
[18:33:20] <tomprince_loki> in Actor::Turn.
[18:33:49] <fuzzie> i guess the relevant bit would be HasOpcode*, which seems to have no calls which don't start with a name
[18:34:22] <fuzzie> oh, there are more
[18:37:46] <tomprince_loki> :q
[18:37:50] <fuzzie> so, i guess the answer is "because there are a couple of annoying functions lurking that require the opcode id"
[18:38:25] <fuzzie> there is a plea in the header file to use the effect_reference while you can, but there's not much you can do about original data files using the id, i guess
[18:40:48] <fuzzie> you could just allocate an unused id if the effect doesn't exist.. but maybe actually a bad idea if we only need two effects (i think we'll need something for Bard Song, too)
[18:41:24] <fuzzie> since it'd no longer be obvious when code is using a bad effect
[18:41:44] <fuzzie> although i guess a printf() would take care of that, so ignore my last line.
[18:43:29] <tomprince_loki> Well, are all the effects in effect.ids from the original game? Or some just there because they need to be there with the current design?
[18:43:43] <fuzzie> yes, they're all from the original game
[18:45:15] <fuzzie> the only reason there's a problem with Turn and Bard Song is that the original engines hard-coded the modal actions in C++
[18:46:22] <tomprince_loki> Well, it is a thought, that I might return to at a later date. It isn't like I don't have enough on my plate anyway. :)
[18:46:36] <fuzzie> well, yes, just thoughts on my part, as you can hopefully tell :)
[18:46:40] <tomprince_loki> Yes.
[18:47:11] <tomprince_loki> Picking your brain ...
[18:53:49] <tomprince_loki> Anyway., I was trying to come up with a minimal dataset that would allow Interface::Init to run.
[18:55:21] <tomprince_loki> One has to create a bunch of bams. I was doing it in vi (:)), and then realized that it would be simple enough to create an equivalent text format, that stored the images them selves as seperate files...
[19:08:13] <-- Maighstir has left IRC (Quit: Maighstir)
[19:35:19] <fuzzie> so now you're writing a crazy plugin? or just a script to make bams?
[19:50:33] <tomprince_loki> I was considering making it a plugin.
[19:50:50] <tomprince_loki> I haven't started yet.
[19:57:31] <tomprince_loki> I have had in the back of my head the idea of adding plain-text versions of a number of IE formats.
[19:59:04] <tomprince_loki> I think that it would make modding easier.
[19:59:58] <tomprince_loki> And if the plugins were suffciently divorced from the details of core, we could perhaps even ruse the code in the plugins as converters. :)
[20:12:47] <tomprince_loki> s/ruse/reuse/
[20:38:16] <tomprince_loki> Does anybody know if count == 1 in the tilemap bit of WED files, when there is a secondary, or if there is a reason we force it to 1?
[20:39:15] <fuzzie> isn't there a comment at that bit?
[20:40:14] <fuzzie> odd
[20:40:40] <tomprince_loki> There is a comment about secondary should always be 0xFFFF.
[20:41:10] <fuzzie> i have distant memories that the reason is that we don't handle count != 1, and it doesn't happen with the original engine anyway
[20:41:28] --> |Cable| has joined #GemRb
[20:41:37] <tomprince_loki> But in the branch where it isn't, we pass 1, instead of count to GetTile.
[20:42:02] <fuzzie> yes, i'm pretty sure that is it
[20:42:27] <tomprince_loki> Which we have to, since we treat secondary as an array, which has length one. But that is just silly, we could just treat it as a number, and let the count be honored for the first bit.
[20:42:30] <fuzzie> but i don't know if we're missing an assert(count == 1)
[20:42:51] <fuzzie> or if the original data files have garbage in the count field, which is probably more likely
[20:43:22] <tomprince_loki> That would be sad, but not unexpected.
[20:43:27] <fuzzie> no, that can't be it
[20:43:37] <fuzzie> because the str->Read is based on count
[20:44:03] <fuzzie> oh, i guess that could just be going off the end, the next action is a seek, i forget if such errors get reported
[20:45:02] <tomprince_loki> They do, but if enough data exists after it, it won't trigger an error.
[20:45:11] <tomprince_loki> Or maybe only seeks trigger an error...
[20:45:26] <fuzzie> i would just add an assert in there and see if it still loads the bg2/pst areas
[20:46:20] <fuzzie> oh wow, that code is really horrible
[20:46:56] <fuzzie> i hadn't realised what was going on with that pointer :)
[20:48:06] <tomprince_loki> :)
[20:58:02] <tomprince_loki> WEDImporter used indicies, and TISImporter indexes. :P
[21:03:51] <tomprince_loki> or.cz/gettile is what I want to do, with an if (secondary!=0xFFFF) count =1; if I have to.
[21:06:51] <fuzzie> well, i would prefer someone look into it carefully first
[21:07:09] --> Maighstir has joined #GemRb
[21:07:19] <fuzzie> but i forget how this works, and in particular i forget in which games this is tempermental
[21:07:59] <fuzzie> (i would also really prefer this wasn't so hard-coded, but this is no harder to fix than the previous code, i gues)
[21:10:19] <tomprince_loki> This is in preparation for adding TIZImporter. I was going to factor it to core, but you suggested, and I agree, that it should be factored all the way into WEDImporter.
[21:10:40] <tomprince_loki> And yes, it needs testing and review.
[23:06:25] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[23:20:04] <-- kingron has left IRC (Quit: Leaving)