#gemrb@irc.freenode.net logs for 4 Sep 2011 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage

[00:40:01] <-- barra_away has left IRC (Quit: Verlassend)
[00:40:44] <-- brad_a has left IRC (Quit: brad_a)
[05:16:49] <-- Maighstir has left IRC (Quit: .)
[05:27:21] <-- Drakkar has left IRC (Read error: Connection reset by peer)
[05:27:55] --> Drakkar has joined #gemrb
[05:37:12] <-- Drakkar has left IRC (Read error: Connection reset by peer)
[05:37:29] --> Drakkar has joined #gemrb
[05:47:01] <-- Drakkar has left IRC (Quit: The deer is teal.)
[05:50:06] --> Drakkar has joined #gemrb
[06:48:47] --> Yoshimo has joined #gemrb
[07:09:44] --> lynxlynxlynx has joined #gemrb
[07:09:49] <-- lynxlynxlynx has left IRC (Changing host)
[07:09:49] --> lynxlynxlynx has joined #gemrb
[07:09:49] --- ChanServ gives channel operator status to lynxlynxlynx
[08:17:47] --> test32894789234u has joined #gemrb
[08:20:22] <CIA-26> GemRB: 03lynxlupodian * r46a26e6df6ce 10gemrb/gemrb/core/GameScript/GSUtils.cpp: don't abort casting if the target went invisible and the caster can see invisibles
[08:49:19] --> Avenger has joined #gemrb
[08:49:56] <Avenger> hello
[08:50:23] <Avenger> do you have any idea which commit broke the textscreen cursor?
[08:56:16] <lynxlynxlynx> no
[08:56:26] <lynxlynxlynx> let me check if we have the same problem in bg2
[08:56:42] <lynxlynxlynx> could be the scrolling changes
[08:56:45] <Avenger> hmm, i would be surprised if it is a guiscript problem ;)
[08:57:04] <Avenger> especially textscreen being common
[08:57:25] <Avenger> but i admit i saw it on HoW too
[08:58:59] <Avenger> it looks like acvscreature is non cumulative in the original engine, so ac bonus coming from this source can be only 2
[08:59:06] <Avenger> meh
[08:59:06] <lynxlynxlynx> still works in bg2
[08:59:12] <Avenger> really O_o
[08:59:16] <Avenger> interesting
[08:59:31] <lynxlynxlynx> i was testing with the chapter textscreens
[08:59:44] <Avenger> i check bg1, it has some textscreen in the beginning, iirc
[09:00:21] <lynxlynxlynx> textscreen.py is common, but let's see if it has any iwd checks
[09:00:38] <Avenger> bg1 starting textscreen also has cursor
[09:00:41] <Avenger> hmmmm
[09:00:46] <Avenger> ok, i know what's the problem
[09:00:54] <Avenger> HoW starts the textscreen from a cutscene
[09:01:27] <lynxlynxlynx> just for music
[09:01:46] <Avenger> i guess, we originally re-enabled the cursor in the textscreen, but it was removed
[09:02:03] <lynxlynxlynx> my bg2 test was on entering underdark
[09:02:17] <lynxlynxlynx> that is from a cutscene too, but maybe at the end
[09:04:01] <lynxlynxlynx> yes, movie04b.baf
[09:06:55] <Avenger> well textscreens should kill cutscene mode anyway
[09:07:06] <Avenger> so, i'm adding something there
[09:07:16] <Avenger> with a comment, and we'll see :)
[09:10:24] <fuzzie> i think they shouldn't kill cutscene mode
[09:10:45] <fuzzie> due to that HoW cutscene
[09:13:48] <Avenger> hmm?
[09:14:05] <Avenger> it continues after the textscreen?
[09:14:07] <fuzzie> yes
[09:14:19] <Avenger> so it was you? :P
[09:14:25] <Avenger> which resref is this?
[09:14:32] <fuzzie> this bug is many years old, no?
[09:14:33] <Avenger> i mean where is this cuscene
[09:14:39] <Avenger> i don't know
[09:14:49] <fuzzie> you can see this behaviour e.g. right at the start of iwd, i thought
[09:14:57] <Avenger> i just noticed the lack of cursor now, and wham, someone else reported it
[09:15:00] <fuzzie> cutscene starts, textscreen happens, cutscene continues
[09:15:12] <fuzzie> did someone remove the hack?
[09:15:26] <Avenger> not sure what hack
[09:15:44] <Avenger> was there already some hack to enable the cursor for the time of the textscreen?
[09:15:51] <fuzzie> there's one specifically for iwd in there, which stops a cutscene from happening
[09:16:13] <Avenger> there is no gameplay problem atm
[09:16:18] <Avenger> just no mouse
[09:16:21] <fuzzie> presumably it is not enough to cover your case, since it only tries dealing with a cutscene which happens *just after* a textscreen
[09:16:25] <Avenger> enter still works on the textscreen
[09:16:51] <fuzzie> yes, it is still there, so it is just insufficient
[09:16:53] <Avenger> the only problem atm, is that during textscreens i see no cursor, because of the cutscene active
[09:17:00] <fuzzie> see "This fixes starting a new IWD game", in Map.cpp
[09:17:33] <Avenger> i don't think i want to change that
[09:17:56] <fuzzie> no, i guess not
[09:17:58] <Avenger> that would really break the flow, i think we just need one more hack :P
[09:20:07] <Avenger> what about calling video->SetMouseMode before textscreen?
[09:20:33] <Avenger> it would leave the mouse after textscreen
[09:20:55] <Avenger> i've no idea how could we fix that
[09:21:35] <Avenger> meh, actually, THAT is in the code?
[09:22:07] <Avenger> fuzzie, why this won't work?
[09:22:59] <fuzzie> well, i don't know
[09:23:37] <Avenger> but you also see the mouseenable in TextScreen :)
[09:23:43] <fuzzie> yes, but it doesn't block, right?
[09:23:56] <Avenger> meh
[09:24:01] <Avenger> why
[09:24:31] <Avenger> well, maybe it shouldn't be a 'blocking action'
[09:24:39] <fuzzie> yes, it shouldn't be
[09:24:42] <Avenger> it should freeze the gametime completely
[09:24:48] <fuzzie> it should set a flag, and then the main loop should do the textscreen
[09:25:06] <fuzzie> or else we could do like the original, and simply do another loop inside the textscreen action
[09:25:40] <Avenger> you saw that's how the original works?
[09:25:59] <fuzzie> but "messing with the GUI inside an action and then returning and hoping nothing goes wrong" is not really a very reliable idea :P
[09:26:23] <Avenger> as far as i see the original has no loop
[09:26:30] <Avenger> it always returns with -1
[09:26:52] <fuzzie> well, it sends a message and then the textscreen GUI class loops, afaik
[09:27:25] <Avenger> yes, that's true, and that means, all the instants slip in before the actual textscreen starts, no?
[09:28:22] <fuzzie> but that doesn't matter
[09:28:49] <fuzzie> because the original textscreen GUI completely ignores any game GUI settings
[09:28:54] <Avenger> well, it matters, we currently have a setwait
[09:29:14] <fuzzie> well there is a "should this be blocking?" comment for a reason there :)
[09:29:28] <Avenger> yes, the original isn't blocking at all
[09:29:45] <Avenger> not even with setwait, so we need to do something more like the original
[09:31:12] <fuzzie> well, as I suggested, I think "it should set a flag, and then the main loop should do the textscreen" is best
[09:31:21] <fuzzie> and there you could save and restore the mouse status
[09:31:26] <Avenger> i guess, we need a special guiscript action that clears the flag
[09:31:51] <Avenger> yes, i already accepted that part ;P
[09:32:04] <fuzzie> oh, ok :)
[09:33:40] <Avenger> so EF_TEXTSCREEN
[09:37:36] <lynxlynxlynx> once you're done with that, i need your help with something
[09:48:47] <Avenger> i won't be done soon :(
[09:49:01] <Avenger> there is some blocking action in the queue
[09:49:32] <Avenger> oh hehe, incrementchapter
[09:49:44] <fuzzie> is that a problem?
[09:49:57] <fuzzie> i mean, there's no reason to mess with the queue, right?
[09:50:14] <fuzzie> just set the flag and display the textscreen when everything is back at the main loop
[09:51:08] <Avenger> i do it with the EF_* stuff
[09:51:11] <Avenger> it works
[09:51:21] <Avenger> but strangely i get the wrong text
[09:51:41] <Avenger> but it is getting better
[09:51:54] <Avenger> i think i just have to remove the ++ chapter hack
[09:52:41] <Avenger> i meant this: ID = (GemRB.GetGameVar("CHAPTER") + 1) & 0x7fffffff
[09:52:54] <Avenger> that +1 was always fishy, maybe not it is not needed :)
[09:53:01] <Avenger> now
[09:54:53] <Avenger> perfect, for the HoW starting scenario
[09:54:58] <Avenger> now... what did i break :)
[09:56:43] <Avenger> bg1 still works!
[09:57:04] <-- Avenger has left IRC (Quit: ChatZilla 0.9.87 [Firefox 6.0.1/20110830092941])
[10:12:49] <lynxlynxlynx> i remember you start with chapter 0 in some games in gemrb, but that may have been caused by something else
[10:26:55] <CIA-26> GemRB: 03avenger_teambg * reb3a7ccbca5d 10gemrb/gemrb/core/GameScript/GSUtils.cpp: Merge branch 'master' of ssh://gemrb.git.sourceforge.net/gitroot/gemrb/gemrb
[10:27:00] <CIA-26> GemRB: 03avenger_teambg * ra53ec2c318ef 10gemrb/gemrb/core/Scriptable/Actor.cpp: fixed a possible compilation error
[10:27:00] <CIA-26> GemRB: 03avenger_teambg * r8ddf48bb0fc2 10gemrb/gemrb/ (5 files in 3 dirs): converted TextScreen/IncrementChapter to non blocking actions (this fixes some cutscene/textscreen interactions in HoW)
[10:28:07] --> Avenger has joined #gemrb
[10:32:07] <Avenger> lynx did you consider using something like CanSee instead of direct stat checks?
[10:32:48] <lynxlynxlynx> that checks more stuff
[10:33:02] <lynxlynxlynx> i don't know what everything the original uses in this case
[10:33:47] <Avenger> actually, ValidTarget is a better guess
[10:34:14] <Avenger> yes, validtarget is what you need
[10:34:15] <lynxlynxlynx> that's also incomplete
[10:34:19] <Avenger> why?
[10:34:27] <lynxlynxlynx> the one in actor?
[10:34:37] <Avenger> yes
[10:34:46] <Avenger> if it is incomplete, then it needs fixing :)
[10:35:03] <Avenger> yes, it doesn't handle the Seeinvis flag
[10:35:05] <Avenger> but it should
[10:35:11] <lynxlynxlynx> incomplete was the wrong word
[10:35:25] <lynxlynxlynx> it only does the invisibility check for a certain range of ea
[10:35:26] <Avenger> it is truly incomplete
[10:36:46] <Avenger> i don't have any idea why
[10:37:18] <Avenger> this is weird
[10:37:26] <Avenger> validtarget assumes the targeter is a pc
[10:38:04] <lynxlynxlynx> it is used for scripting
[10:38:10] <lynxlynxlynx> maybe it is an old remnant
[10:38:31] <Avenger> it is old, yeah
[10:38:39] <Avenger> it should use the seeinvis flag :)
[10:38:55] <Avenger> because it is the 'detect invisible by script' flag :)
[10:39:14] <Avenger> but that flag actually makes a lot of invisible things targetable
[10:41:11] <lynxlynxlynx> the seeinvisible stat is separate
[10:41:23] <lynxlynxlynx> big baddies like dragons use it
[10:42:45] <Avenger> tell me both stat numbers then :P
[10:43:04] <lynxlynxlynx> oh, i thought you meant GA_NO_HIDDEN
[10:44:00] <Avenger> GA_NO_HIDDEN should be used where you used the direct stat references, IF, validtarget would actually handle the see invis stat and the targeter/targeted allegiances
[10:44:23] <Avenger> so at the time your solution is good, but validtarget is totally outdated
[10:45:11] <Avenger> there are things you don't calculate with, like the avatar removal
[10:45:21] <Avenger> but that is rare thing
[10:45:40] <Avenger> like: someone is going to be mazed/imprisoned by a beholder, and immediately cast some spells upon
[10:46:12] <lynxlynxlynx> and the deactivated problems too
[10:46:39] <Avenger> luckily not many other deactivation could happen during combat when the actor is visible :)
[10:47:36] <Avenger> same about hiding
[10:48:02] <Avenger> though, probably a friendly caster could cast spells on a thief which is just hiding, i don't know how is that handled in the original
[10:48:14] <lynxlynxlynx> it also affects pretty much anything using CanSee
[10:48:32] <Avenger> what?
[10:49:44] <Avenger> ah i see, you mean validtarget doesn't handle Schedule / activation?
[10:50:31] <Avenger> yeah, i wonder if that's a problem
[10:51:32] <lynxlynxlynx> we do have problems with (de)activate
[10:51:42] <lynxlynxlynx> one of them is visibility related
[10:52:03] <lynxlynxlynx> what i meant specifically is that cansee uses validtarget, so the userbase is bigger
[10:53:04] <Avenger> yes, and it should use them
[10:53:21] <Avenger> hmm, maybe
[10:53:38] <Avenger> this is something for fuzzie too :)
[10:53:57] <Avenger> scripting can go mad if it cannot target something it should
[10:54:16] <Avenger> and i have a feeling, there is even difference between games
[10:54:48] <fuzzie> scripting doesn't use this code, right?
[10:54:55] <Avenger> CanSee?
[10:55:02] <Avenger> i thought it uses CanSee
[10:55:13] <fuzzie> only in specific actions
[10:56:01] <Avenger> well, i specifically meant, that we need to know which actions need to use it. And this may be different among gametypes
[10:56:08] <fuzzie> ah, ok
[10:56:12] <fuzzie> i was thinking of things like [PC]
[10:56:28] <Avenger> i think iwd2 has a more strict object parsing
[10:56:37] <fuzzie> and i didn't even think about iwd2 :)
[10:56:37] <Avenger> and it ignores actors where other games don't
[10:57:15] <Avenger> i don't dare to think about it too much either, especially now that i seen how ancient is our Validtarget/CanSee code :)
[10:57:43] <fuzzie> but since CanSee/ValidTarget keep being broken, the [PC]-type matching is all done manually in Matching.cpp
[10:58:26] <fuzzie> since, as you say, scripting goes mad if the targeting refuses to match legitimate targets
[10:58:26] <Avenger> well, there are at least 2 if not 3 different object parsing in actions
[10:58:38] <fuzzie> that is *only* [PC]-style though
[10:59:32] <Avenger> you already started to rewrite them, but i'm not sure every action is already like the original, especially if they are different from each other too
[10:59:57] <fuzzie> the only crazy thing so far in bg2 is Detect() I think
[11:00:41] <Avenger> i thought we can do these with different flags
[11:00:48] <fuzzie> yes, we handle that already :)
[11:02:22] <Avenger> yes, it uses CanSee, well, then it is more or less the way i imagined it :)
[11:02:56] <Avenger> We just need to handle the 'can see invisible by script' flag to it somehow
[11:03:01] <Avenger> without breaking anything
[11:03:03] <fuzzie> already dealt with
[11:03:05] <fuzzie> really :p
[11:03:09] <Avenger> where?
[11:03:50] <fuzzie> SeeCore passes GA_DETECT to GetActorFromObject which ignores invis if needed
[11:03:52] <Avenger> you mean you have it locally?
[11:04:10] <Avenger> oh i see
[11:04:24] <Avenger> hmm, then you handle the specific creature immunities there too
[11:05:15] <fuzzie> yes. they block object matching only at that level.
[11:05:33] <Avenger> that's also something lynx doesn't handle now
[11:05:37] <Avenger> though, he should
[11:05:39] <fuzzie> no
[11:06:02] <fuzzie> if you are targetted by another method, the immunities do not make you immune
[11:06:06] <Avenger> why? if you are not targetable by undead
[11:06:18] <Avenger> then undead cannot cast spell on you
[11:06:20] <fuzzie> they block *only* object matching via fields
[11:06:23] <fuzzie> like [PC]
[11:06:27] <fuzzie> they must not block targeting like Player1
[11:07:03] <fuzzie> because then you break scripts :)
[11:07:26] <Avenger> ok, what about spellcasting specifically
[11:07:36] <fuzzie> it's all done at the object matching level
[11:08:02] <Avenger> i cast a protection from undead, and the protection spell finishes before their spell
[11:08:21] <fuzzie> the action ends up with a NULL target if you do that, right?
[11:08:37] <Avenger> not right now, i guess
[11:09:04] <Avenger> lynx handles only if the target goes invis and you dont' see invis
[11:09:22] <Avenger> nothing about sanctuary type effects
[11:09:38] <fuzzie> hm
[11:09:42] <fuzzie> that is probably a bug on my part, actually
[11:10:05] <fuzzie> I don't re-verify object fields in GetStoredActorFromObject
[11:10:17] <fuzzie> probably I should
[11:10:28] <Avenger> ahh i see, so spellcasting actions should validate the target before spellcastend?
[11:10:29] <fuzzie> I thought the original Spell action specifically handles sanctuary though :)
[11:10:35] <fuzzie> they do validate the target, i think
[11:11:13] <Avenger> well, then i don't see why lynx had to add those lines
[11:11:14] <fuzzie> yes, SpellCore calls GetStoredActorFromObject
[11:11:40] <Avenger> if target is invis, then the spellcasting should abort anyway
[11:11:49] <fuzzie> and that calls ValidTarget
[11:12:28] <fuzzie> well, this way you get a message I guess? you'd have to ask lynx :)
[11:13:04] <lynxlynxlynx> it was an extra idea when adding the dead checks
[11:13:16] <lynxlynxlynx> didn't think about just putting it there
[11:14:11] <Avenger> i just don't see how it would work if what fuzzie says is true: if someone went invis, they should be invalid target already, and she said there is a recheck
[11:15:11] <lynxlynxlynx> there is no message, so you'd see no difference
[11:16:10] <Avenger> what about the stance?
[11:16:31] <Avenger> i see you reset the stance in some case
[11:17:06] <Avenger> i see why getting hit wouldn't reset it, but i don't see why the invis target wouldn't, shouldn't it?
[11:18:15] <lynxlynxlynx> getting hit resets it in the actor code
[11:18:44] <Avenger> but yeah, i guess, the invis target should never reach this. Yes, getting hit alters the stance already so it is not needed to do anything about it here
[11:18:47] <lynxlynxlynx> but yes, it should also be done for invisibles
[11:21:13] <Avenger> lynx, i suspect the code should never reach that part anyway because fuzzie would never let it there
[11:21:31] <fuzzie> doesn't original continue with casting stance if it fails?
[11:21:49] <fuzzie> or is that just the cast anim?
[11:22:03] <lynxlynxlynx> definitely not infinitely
[11:22:33] <Avenger> GetStoredActorFromObject would scrap the target. Hmm, you could just switch it to the cast stance?
[11:22:53] <Avenger> the one that is not looping
[11:23:08] <Avenger> but we need to do a more complex animation handling here anyway
[11:23:53] <Avenger> maybe that wouldn't affect this code, if only the looping parts are different
[11:30:21] <lynxlynxlynx> i'll just do the simple thing for now
[11:34:26] <CIA-26> GemRB: 03lynxlupodian * r7ba69f5eeed1 10gemrb/gemrb/core/GameScript/GSUtils.cpp: SpellCore: handle invisible targets better
[11:47:59] <Avenger> yep, this is better, now anything that invalidates the target will also restore the stance
[11:48:03] <lynxlynxlynx> so what to do with validtarget then? just the extra stat check or more?
[11:48:29] <Avenger> no idea, it may be used in different callers
[11:49:13] <Avenger> the problem is, it doesn't have both objects at hand
[11:49:45] <Avenger> so, if the caller sees invisible by script, the invisibility flag shouldn't play
[11:50:09] <lynxlynxlynx> btw, the hack i needed for deactivated actors is http://pastebin.com/FjNEneen
[11:50:09] <Avenger> also ValidTarget doesn't handle all EA cases as you pointed out
[11:50:44] <Avenger> why isn't that right in ValidTarget?
[11:51:06] <lynxlynxlynx> it's was a quick hack
[11:51:24] <Avenger> at least, this one is sure: the original engine has 3 flags with equivalent result: 1. schedule 2. activated 3. avatar removed.
[11:51:26] <lynxlynxlynx> just so i could continue playing and i guess i traced into there
[11:51:34] <Avenger> the 2. is the IF_VISIBLE, i think :)
[11:51:54] <Avenger> the original always handles those 3 flags as equivalent
[11:52:15] <Avenger> like if (first || second || third)
[11:52:47] <Avenger> we apparently use the 3 flags in different contexts
[11:53:24] <lynxlynxlynx> we use IF_ACTIVE for activated
[11:53:38] <Avenger> ok, then the IF_VISIBLE comes from schedule?
[11:53:47] <Avenger> one of them should ;)
[11:53:59] <lynxlynxlynx> i don't know what it is
[11:54:12] <Avenger> it is to remove/enable actors based on days of time
[11:54:22] <Avenger> err times of day :D
[11:54:40] <lynxlynxlynx> we use it only from the two relevant actions
[11:54:42] <Avenger> in actor there is a Schedule call
[11:54:49] <lynxlynxlynx> oh
[11:55:04] <Avenger> but that is just the base query
[11:55:39] <Avenger> hmm apparently it uses the IF_VISIBLE flag too
[12:53:31] --> duckpunch has joined #gemrb
[13:14:52] <Yoshimo> this discussion sounds highly professional and weird from my point of view, i guess school needs some better it-classes^^
[13:27:42] --> Maighstir has joined #gemrb
[13:32:18] <Yoshimo> didnt the mac version or so of bg include function names? i vaguely remember something like that
[13:33:56] <fuzzie> there's a lot of debug messages present too.
[13:33:57] <Maighstir> someone said it included debugging symbols, yes
[13:34:38] <fuzzie> mac porters are universally *very bad* at remembering to disable debug symbols in their builds
[14:21:39] <Yoshimo> good for us^^
[14:47:51] <lynxlynxlynx> Avenger: still here?
[15:04:30] <-- duckpunch has left IRC (Quit: Lost terminal)
[15:15:04] <Avenger> yes
[15:15:26] <lynxlynxlynx> the other thing i mentioned earlier
[15:15:49] <lynxlynxlynx> i started to add npclevel.2da support, but i have problems with substituting the actors
[15:16:01] <Avenger> hmm
[15:16:06] <lynxlynxlynx> http://sprunge.us/FDie?diff <-- now i'm trying it in the action itself
[15:16:14] <Avenger> they have to be replaced only when they haven't been in party yet
[15:16:40] <lynxlynxlynx> hmm, i don't handle that
[15:17:12] <Avenger> you need to handle that, once in party, they won't auto advance, i'm pretty sure :)
[15:17:31] <lynxlynxlynx> i need to do it for rejoins
[15:17:46] <lynxlynxlynx> there's a beeninparty flag somewhere iirc
[15:17:49] <Avenger> yes
[15:18:06] <lynxlynxlynx> ah, part of the mc bunch
[15:18:07] <Avenger> so rejoins are not important, and i think the best to replace them is when you add them to area
[15:18:21] <Avenger> but... i think i will have to find where npclevel is handled in the original
[15:18:31] <Avenger> so we'll be compatible
[15:18:37] <lynxlynxlynx> the forum thread discussing this suggested it is done on jooin
[15:18:58] <Avenger> that would be great (so you just have to check the been in party flag)
[15:19:03] <Avenger> if it is set, no replace
[15:19:41] <Avenger> i just wonder what level they are when you meet them
[15:19:57] <Avenger> not many would attack a joinable npc, though :)
[15:20:33] <Avenger> but, npclevel would be useful for more if it isn't just handled on join, but a little before that
[15:21:11] <lynxlynxlynx> the point of this table is so they're not too lowlevel when you meet them
[15:21:27] <Avenger> yes
[15:21:49] <lynxlynxlynx> the patch above is fair, it will also downscale them if they're higher, but i think the original didn't do that
[15:22:03] <lynxlynxlynx> the key question is still how to swap the actors properly
[15:23:37] <Avenger> well, if you need to swap them, then destroy the old, and clone a new. Then cover up for the change in all lists :D
[15:23:47] <Avenger> but, i consider that a bit brute force
[15:24:01] <Avenger> i would have do it without swap
[15:24:34] <Avenger> 1. this swapping is needed only for npcs stored in the npc list
[15:24:48] <Avenger> not actors cloned by area
[15:24:57] <lynxlynxlynx> well, another way that may please most players is to just grant them the xp of the new actor, so they can level them up themselves
[15:25:00] <Avenger> in other word, global npcs
[15:25:22] <Avenger> but they already created different cre files
[15:25:34] <Avenger> i would first implement the original engine
[15:26:37] <lynxlynxlynx> that's what i tried
[15:26:48] <lynxlynxlynx> the replacement part is dodgy
[15:26:56] <Avenger> but if you clone the actor the first time, it wasn't loaded yet
[15:27:18] <lynxlynxlynx> this doesn't happen on load, but in the joinparty action
[15:27:22] <Avenger> 'first time' :) global npcs are not cloned by the area
[15:27:40] --> duckpunch has joined #gemrb
[15:27:43] <Avenger> you think that because of some forum note, or you did extensive testing?
[15:28:34] <lynxlynxlynx> i'm mostly talking about how i implemented it, but yes, the info is from the forum
[15:28:52] <lynxlynxlynx> with you saying something along "too bad, it would be better if it was done on load"
[15:29:02] <Avenger> but you cannot really implement it differently if the actor is already there
[15:29:23] <Avenger> yes, i say that, but that's only if the forum info is really true :D
[15:29:43] <fuzzie> um
[15:30:01] <fuzzie> the action runs *on the actor*, right?
[15:30:03] <lynxlynxlynx> http://forums.gibberlings3.net/index.php?showtopic=3756&hl=npclevel.2da
[15:30:05] <fuzzie> there is no way it swaps the actor out
[15:30:17] <fuzzie> unless there is a hack before the action is called at all
[15:30:28] <Avenger> it may be doing a weird polymorph feat :)
[15:30:43] <fuzzie> there's nothing in the action which looks like swapping either
[15:30:47] <Avenger> but fact is: all the npc replacements are in separate .cre files
[15:30:50] <lynxlynxlynx> it doesn't really need to swap it out, since it can create a new one, join that one to the party and destroy the original
[15:31:08] <Avenger> lynx: and what happens with the action queue
[15:31:08] <fuzzie> well, what the original action *does* is join the actor to the party and init it.
[15:31:30] <lynxlynxlynx> Avenger: problems
[15:31:36] <Avenger> fuzzie: do you see npclevel being used by joinparty?
[15:31:42] <fuzzie> Avenger: no, and no CRE loading, etc
[15:31:53] <Avenger> do you see what uses npclevel?
[15:31:54] <fuzzie> and no hack in the caller
[15:32:11] <fuzzie> but i don't have the idb, so i am looking blind :)
[15:32:12] <Avenger> if not, then i guess, i just reboot to windows and try to find out :)
[15:32:12] <lynxlynxlynx> i first added it to Game::JoinParty, but then it turned out only the action should use it
[15:32:21] <-- Avenger has left IRC (Quit: bye!)
[15:32:53] <-- duckpunch has left IRC (Quit: leaving)
[15:34:51] <fuzzie> i don't see it anywhere else either though, so i am being stupid somewhere
[15:34:54] <fuzzie> i guess avenger will work it out
[15:36:07] <fuzzie> there's a CGameSprite::AddReplacementToArea, but it's only used by multiplayer i think
[15:36:44] --> duckpunch has joined #gemrb
[15:36:58] <fuzzie> but the actor is really completely irrelevant before then? no need to copy anything?
[15:38:34] <fuzzie> if so, it does sound fine to just DestroySelf the original and spawn a new
[15:39:13] <fuzzie> but so many edge cases, like what happens if you're in dialog
[15:42:13] --> Avenger has joined #gemrb
[15:42:14] <lynxlynxlynx> i don't know any cases where this wouldn't be at the end of the dialog
[15:42:18] <Maighstir> There may not be many situations where you attack a joinable NPC, but if you decide to let Edwin join your party in BG1, there is a quest to kill the mage who Minsc is tasked to guard (I forget her name though), and I believe she's joinable up until you decide to attack her, making it possible to have her join even if Edwin is in the party. (Although I may remember wrong, and it may be only possible to have them tog
[15:42:50] <Avenger> lol lynx, the npc change is done in MANY places, except in JoinParty
[15:43:05] <fuzzie> Maighstir: cut off at 'to have them tog'
[15:43:28] <Maighstir> ... 01 have them together in the party if you picked her up first and Edwin decides he "needs to keep an eye on her").01
[15:44:01] <Avenger> well, those many places all call 'areaunmarshal' which is just the yoshimo unfriendly name for loading an area ;)
[15:44:06] <lynxlynxlynx> their xp is deliberatly set to 0 though
[15:44:40] <Avenger> it identifies the actors to replace by their dialog resref
[15:45:14] <Avenger> and yeah, here is the 'was in party mc flag' check
[15:45:29] <Avenger> also an 'is alive' check
[15:45:36] <Avenger> it doesn't bother with dead actors
[15:46:27] <Avenger> heh, they also use the **** :)
[15:46:44] <fuzzie> but it replaces them when the ARE loads an actor?
[15:47:22] <lynxlynxlynx> **** and dialog resref are from the table, nothing interesting there
[15:47:31] <Avenger> well, this IS a bit fuzzy yet :)
[15:47:48] <Avenger> it is definitely not when, but after
[15:47:55] <Avenger> i just don't see clearly here
[15:48:02] <Avenger> because these actors are NOT in the area
[15:48:11] <Avenger> so areaunmarshal wouldn't load them
[15:48:24] <Avenger> i think i look at the part where global actors are placed in the area
[15:48:54] <Avenger> i'm just a bit wary to state this explicitly, though this is where i would have put it too :D
[15:49:35] <Avenger> when you load an area, you load it first, then place those actors that come from the gam struct on it
[15:49:51] <Avenger> and this is where you replace them with the correct leveled parts
[15:50:22] <Avenger> here is a string: Loading Area
[15:50:24] <Avenger> :)
[15:51:17] <Avenger> ok basically i saw this called from many places, because there are a few actions that load areas
[15:52:11] <Avenger> and such, but this is where it puts 'loading area' into the loadscreen, then loads area, then does some loop on the actors
[15:52:23] <Avenger> gets the party average level
[15:53:21] <Avenger> gets the global npc's dialog resref, and indexes npclevel or npclev25
[15:54:20] <Avenger> i'm not really sure what it would do if the result is ****
[15:54:33] <Avenger> apparently it would remove the npc from the list, but that is ODD
[15:57:10] <Avenger> the loop goes through on the global npcs, matches their current area with the loaded area, skips if they don't match, the actor was in party, or dead
[16:00:31] <Avenger> oh, and here it also replaces the portrait :)
[16:02:39] <Avenger> it truly doesn't lower the level
[16:03:25] <Avenger> and if it sees ****, it just skips the actor, nothing serious
[16:08:02] <Yoshimo> Avenger: whats up? :P
[16:08:06] <Avenger> the portrait change happens after this, in a separate if/then. but that also checks if the actor was already in party
[16:08:51] <Avenger> and alive, and some field in .gam i don't know about :(
[16:09:00] <Avenger> yoshimo: nothing
[16:15:08] <lynxlynxlynx> yeah, those in the table don't have portraits set
[16:15:37] <lynxlynxlynx> i added a note that it's probably due to portraits.2da (which we don't handle yet either)
[16:16:16] <-- duckpunch has left IRC (Quit: leaving)
[16:17:40] <Avenger> portraits are replaced even if you don't replace the actors. It would be odd if they don't have any to start with
[16:18:14] <lynxlynxlynx> i mean the replacements don't have them
[16:18:17] <Avenger> portraits are replaced if there is one in the party already. But it is done only in a new game
[16:18:27] <Avenger> yes, i understood that, and it is strange
[16:19:01] <Avenger> i wonder how would that work
[16:19:11] <lynxlynxlynx> yeah, since they probably just copied the cres as templates
[16:19:14] --> yyz has joined #gemrb
[16:19:20] <Avenger> but i didn't see that
[16:19:26] <lynxlynxlynx> we handle it just fine by using noports*
[16:19:50] <lynxlynxlynx> interesting info though
[16:20:15] <lynxlynxlynx> if you level up in the same area you'll be talking to a prospective party member, it is better to reenter it
[16:22:12] <Avenger> yes
[16:22:24] <Avenger> or just save/reload
[16:22:28] <Avenger> that's safer :)
[16:23:07] <Avenger> if you leave to a non master area, the area (and the actor) won't be reload
[16:25:15] <Avenger> why did you say that the actors don't have portraits?
[16:25:42] <Avenger> anomen12 has one. If you saw aerie, then it is because you meet her as an ogre :)
[16:26:30] <Avenger> yes, they all have portraits, except aerie, but that's fine
[16:26:41] <lynxlynxlynx> hehe, i was testing with aerie, yes
[16:27:04] <Avenger> ok, phew :P
[16:28:03] <Avenger> on the other hand, if she joined the team, her script should have changed the portrait
[16:28:23] <Avenger> i hope you never seen noports :)
[16:30:51] <lynxlynxlynx> i did
[16:31:17] <lynxlynxlynx> anyway, this should then all be done in AREImporter::GetMap?
[16:32:00] <lynxlynxlynx> bbl
[16:32:18] <Avenger> if that's where we process global actors, then yes
[16:32:42] <-- Demitar has left IRC (Quit: Burn the land and boil the sea, you can't take the sky from me!)
[16:32:52] <Avenger> we already should have a loop that matches global actors with the 'just recently loaded area' name
[16:33:01] <Avenger> this code goes right into that loop
[16:36:00] <-- yyz has left IRC (Quit: Lost terminal)
[16:37:25] <Avenger> well, i don't find how we place global actors on the map ;)
[16:37:30] <Avenger> this was a long time ago
[16:38:47] <Avenger> ahh i see it
[16:39:01] <Avenger> int Game::LoadMap(const char* ResRef, bool loadscreen)
[16:39:19] <Avenger> for (i = 0; i < NPCs.size(); i++) {
[16:39:21] <Avenger> if (stricmp( NPCs[i]->Area, ResRef ) == 0) {
[16:39:22] <Avenger> newMap->AddActor( NPCs[i] );
[16:39:24] <Avenger> }
[16:39:26] <Avenger> }
[16:39:27] <Avenger> this loop should be more complex
[16:40:03] <Avenger> before doing the AddActor, you need to check NPCs[i], and sometimes totally replace it with a new object before adding it to the area
[16:43:12] --> yyz has joined #gemrb
[16:43:25] <-- Avenger has left IRC (Quit: ChatZilla 0.9.87 [Firefox 6.0.1/20110830092941])
[17:18:45] <-- yyz has left IRC (Quit: leaving)
[18:24:08] <lynxlynxlynx> hmpf, she already has beeninparty set
[18:24:53] <lynxlynxlynx> i'll need a fresh save, it's from her main script
[18:31:32] --> brad_a has joined #gemrb
[18:46:36] <lynxlynxlynx> bah
[18:47:09] <lynxlynxlynx> the area uses MoveGlobalsTo with aerie, so she doesn't get caught on load
[18:48:11] --> yyz has joined #gemrb
[18:52:10] <-- brad_a has left IRC (Quit: brad_a)
[18:55:36] <-- test32894789234u has left #gemrb
[19:40:56] <CIA-26> GemRB: 03lynxlupodian * red785c15149d 10gemrb/gemrb/core/ (Game.cpp Game.h): added npclevel.2da support
[19:43:27] <Yoshimo> what is that about lynx?
[19:44:33] <lynxlynxlynx> the level(s) of the party-joinable npcs is sometimes adjusted when you meet them
[19:45:28] <Maighstir> depending on yor own level, I believe
[19:50:43] <lynxlynxlynx> party level actually
[20:26:52] <Yoshimo> should you be able to do quests in beregost right with the level you have when you go there or do you always need to grind mobs in the fields before the town to advance a bit before that?
[20:29:34] <lynxlynxlynx> depends on your skill
[20:37:52] <Yoshimo> what comes before "beginner" ;)
[20:52:10] <lynxlynxlynx> depends on your class
[20:52:18] <lynxlynxlynx> a mage will have much less hitpoints
[20:52:45] <lynxlynxlynx> and it will require a lot of sleeping, not just for the healing
[20:54:05] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[20:57:23] --> SiENcE has joined #gemrb
[21:12:45] <-- Yoshimo has left IRC (Quit: Yoshimo)
[21:18:29] <-- SiENcE has left IRC (Ping timeout: 245 seconds)
[21:51:51] <-- Gekz has left IRC (Quit: No Ping reply in 180 seconds.)
[22:40:49] --> Demitar has joined #gemrb
[22:45:12] --> brad_a has joined #gemrb
[22:45:33] <-- brad_a has left IRC (Client Quit)
[22:59:11] <-- Demitar has left IRC (Read error: Operation timed out)
[22:59:51] --> Demitar has joined #gemrb
[23:02:51] --> PixelScum has joined #gemrb
[23:05:28] <-- Drakkar has left IRC (Ping timeout: 264 seconds)
[23:46:07] <-- Maighstir has left IRC (Quit: .)