#gemrb@irc.freenode.net logs for 15 Aug 2010 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage


[00:08:22] <-- SiENcE_ has left IRC (Quit: cya @all)
[00:10:58] <-- Ayla has left #GemRb
[00:42:18] <-- nickdaly` has left IRC (Ping timeout: 248 seconds)
[05:23:29] <Gekz> what's the engine that is similar to GemRB
[05:23:35] <Gekz> but was for Fallout or something
[05:23:39] <Gekz> erm
[05:23:44] <Gekz> yeah lol
[05:24:10] <Gekz> fife engine
[06:33:45] --> edheldil_ has joined #GemRb
[06:46:03] <-- edheldil_ has left IRC (Ping timeout: 265 seconds)
[08:15:58] <fuzzie> oh hm, i just realised that we can deal with triggers in an easier way than i'd thought
[08:16:08] --> pupnik has joined #GemRb
[08:17:20] --> Maighstir has joined #GemRb
[08:26:25] <fuzzie> hi pupnik, Maighstir
[08:35:26] <Maighstir> Morning
[08:45:38] --> lynxlynxlynx has joined #GemRb
[08:45:38] --- ChanServ gives channel operator status to lynxlynxlynx
[09:45:20] --> edheldil_ has joined #GemRb
[09:53:33] <-- raevol has left IRC (Quit: Leaving.)
[10:10:59] <-- edheldil_ has left IRC (Ping timeout: 260 seconds)
[10:42:58] --- Maighstir is now known as Maighstir_away
[10:52:25] --> edheldil_ has joined #GemRb
[11:45:16] <fuzzie> so, Interact doesn't care about the target
[11:49:16] <fuzzie> well, not entirely true
[11:49:22] <fuzzie> if the target doesn't exist, nothing happens
[11:49:46] <fuzzie> but if the target is some monster on the other side of the map, far out of the way, you still get whichever banter happens next
[11:50:25] <fuzzie> and if the actor is near the target, they turn to face them (but the banters usually seem to be pausing dialog, so if a banter happens, the turning actually happens after the dialog)
[11:50:36] <-- edheldil_ has left IRC (Read error: Operation timed out)
[11:53:09] <fuzzie> and it doesn't block; Interact([PC]) only does something if a PC is visible right at that moment
[12:03:06] <fuzzie> and Dialog([PC]) on Imoen with Player1 nearby will start Imoen's dialog, but vice-versa won't work
[12:03:23] <fuzzie> so our code is wrong there, unsurprisingly
[12:04:20] <fuzzie> or maybe it's ok. tired. just dumping this in here as i find it, for future notes
[12:06:07] <fuzzie> Dialog([PC]) will have Imoen happily talk to anyone, which is reassuring
[12:06:15] <fuzzie> but it doesn't block until it finds a PC..
[12:12:23] <fuzzie> so, well, that is annoying
[12:23:24] <fuzzie> can't make Imoen block on anything
[12:25:51] <fuzzie> (the bystander right after leaving the dungeon does Wait(3) and then Dialog([PC]) - so i want to know how that works, since that only runs *once*)
[12:39:06] --> SiENcE has joined #GemRb
[13:28:57] <-- SiENcE has left IRC (Quit: cya @all)
[13:30:45] <-- Maighstir_away has left IRC (Quit: Maighstir_away)
[14:57:44] --> SiENcE has joined #GemRb
[15:37:25] --> kettuz has joined #GemRb
[15:49:51] --> Avenger has joined #GemRb
[15:49:51] --- ChanServ gives channel operator status to Avenger
[15:49:57] <Avenger> hi
[15:50:28] <Avenger> hey, do you know why variable entries are so huge?
[15:51:01] <Avenger> originally the developers planned on point/string even probably float variables
[15:51:18] <Avenger> they just forgot to remove the cruft
[15:52:54] <fuzzie> heh
[15:52:58] <fuzzie> hi Avenger :)
[15:53:21] <Avenger> hi fuzzie i read you got some problem with wait and dialog?
[15:53:28] <Avenger> what's exactly the problem?
[15:53:59] <fuzzie> nothing important, just trying to work out how things work
[15:55:30] <fuzzie> you have any idea how the messages in ToBEx's OMessage.h relate to the ones in your disasm?
[15:55:51] <fuzzie> like, they have 0xAA5BF4 for CMessgeAction, but this is 0AA5C10h
[15:56:18] <Avenger> one or two has copies
[15:56:42] <Avenger> aa5c10 is the base class
[15:57:41] <Avenger> aa5bf4 is push action
[15:57:57] <fuzzie> ok.
[15:58:06] <Avenger> it inserts the action to be executed next (the other actions executed later)
[15:58:40] <fuzzie> well, it's very confusing to me :)
[15:59:08] <fuzzie> but it's not important, i guess, i have no time to do RE
[15:59:34] <Avenger> i typed in lots of structs and went through usages
[16:00:12] <Avenger> for example, i found the mc flag stuff (iesdp is very precise in that)
[16:00:15] <lynxlynxlynx> hey, can you fix the worldmap changing before the release?
[16:00:24] <fuzzie> for which game?
[16:00:26] <Avenger> that is iwd
[16:00:29] <Avenger> no way :)
[16:00:36] <fuzzie> oh yes, that is annoying
[16:00:46] <Avenger> it is only HoW
[16:00:54] <lynxlynxlynx> why no way? oO
[16:01:03] <Avenger> and it requires some rewrite of the worldmap class
[16:01:18] <lynxlynxlynx> oh, could be volatile
[16:01:20] <Avenger> it has the potential to break iwd2 which also has multiple maps, but in one file
[16:01:51] <fuzzie> well, i think you can simply swap them at new area load
[16:02:01] <fuzzie> but it would be a bit volatile
[16:02:10] <Avenger> i already do some swapping
[16:02:14] <Avenger> looks like it is not enough
[16:02:35] <fuzzie> well, i think the only swapping we handle right now is "overwrite old map with new map", ToB-style
[16:02:53] <Avenger> i will make a guiscript function which passes a wmp names list to the core
[16:04:05] <Avenger> tob doesn't overwrite the map, it has worldm25.wmp
[16:04:16] <fuzzie> yes, but it doesn't keep the old map
[16:04:39] <Avenger> well, if we do that, it won't break anything
[16:04:39] <fuzzie> you just get a new map, and the old one is thrown away and no longer saved
[16:04:48] <fuzzie> not much use for HoW
[16:05:00] <Avenger> i would rather keep both in our tob saves
[16:05:37] <fuzzie> i think we can't do that, because it breaks the original
[16:05:46] <fuzzie> which detects whether a game or SoA or ToB by seeing which wmp it has
[16:05:54] <Avenger> really?
[16:05:56] <fuzzie> yes
[16:06:00] <Avenger> i thought it is some field in the .gam
[16:06:05] <fuzzie> no
[16:06:07] <Avenger> pfft
[16:06:18] <fuzzie> well, maybe i am wrong
[16:06:30] <fuzzie> it has been a long time
[16:07:31] <fuzzie> but i'm pretty sure the .gam field is just used for the XP/item/Yoshimo/etc logic
[16:07:52] <fuzzie> and what i mean is, when you click 'Load', it shows only SoA or ToB games depending on which mode you're in
[16:08:23] <fuzzie> and i think that is done by looking at which .wmp file is present.
[16:09:34] <fuzzie> but when SoA is broken, HoW doesn't seem worth spending all this time on
[16:10:54] <fuzzie> Avenger: btw, you say in a comment that bg2's fx_avatar_removal is called 'SummonDisable': that is surely then the effect i was looking for which is applied to summons while the summon anim is playing?
[16:11:16] <fuzzie> also not important, i just wonder if you have a comment
[16:11:39] <Avenger> yes, i think that's the effect you need to disable summons until the anim ends
[16:11:43] <fuzzie> cool
[16:11:45] <Avenger> i just don't know how is it applied
[16:12:23] <fuzzie> not important
[16:12:37] <fuzzie> i still struggle with the action queue stuff, but i think i can make it work 'well enough'
[16:14:07] <fuzzie> and the dialog code needs work, but i hope i have that worked out too
[16:14:18] <fuzzie> the Interact() thing is annoying, but oh well
[16:14:22] <fuzzie> leftover from bg1 i guess
[16:14:49] <Avenger> oh yes, i found it
[16:14:55] <Avenger> i just needed to look ;)
[16:15:02] <fuzzie> :-)
[16:15:21] <Avenger> if you got IDA open: 00518D0B
[16:15:34] <fuzzie> no, but it is in my log now, so i can look later
[16:15:38] <Avenger> this is the call in the summon opcode, that plays the animation AND applies the 0x10f opcode
[16:15:50] <fuzzie> cool
[16:16:32] <fuzzie> so, there is some check at the beginning of a lot of actions, which skips a lot
[16:16:35] <Avenger> i just skipped it earlier, because it starts with 'createprojectile' call, and i thought it just does the standard vvc spell hit anim
[16:16:44] <fuzzie> this is the check for the ClearActions flag?
[16:17:03] <Avenger> it helps a lot that 'createv2effect' and such are now named
[16:17:13] <Avenger> ?
[16:17:41] <fuzzie> my notes-from-Avenger say that the ClearActions message sets some flag
[16:18:10] <Avenger> tell me an address
[16:18:19] <fuzzie> hmm, i have none of it here now :(
[16:18:38] <Avenger> btw, not just 0x10f effect is added, there is a 0x14 (invisible) too
[16:18:43] <Avenger> why the redundancy....
[16:19:00] <fuzzie> because targeting only checks invisible
[16:20:19] <Avenger> hmm, that could be, but that sucks entirely
[16:20:30] <Avenger> avatar removal disables scripts, i think
[16:20:44] <fuzzie> yes
[16:21:01] <fuzzie> action queue isn't processed, so only instants run, same as Hold etc
[16:21:37] <Avenger> the queue is processed, but a blocking action cannot continue, imo :)
[16:21:49] <Avenger> mostly because it cannot move the actor
[16:22:01] <fuzzie> movement is not the only blocking action
[16:22:09] <fuzzie> but, ok, not the same as Hold, then?
[16:22:15] <Avenger> and non movement actions are also freezed?
[16:22:17] <fuzzie> Held creatures do not process the queue at all
[16:22:24] <fuzzie> you get instants only
[16:23:19] <fuzzie> i thought this was the same for avatar removal, but maybe i didn't check well
[16:23:31] <Avenger> ok, so applyspell(myself,"holdme"); SmallWait(1); setglobal("x","global",1) won't set x only until after the spell is gone?
[16:23:42] <fuzzie> yep
[16:24:02] <fuzzie> same with actionoverride and etc
[16:24:31] <Avenger> heh, i'm happy i found this summon disable :)
[16:24:38] <fuzzie> yes, it is good to know, thankyou!
[16:24:47] <Avenger> it is a very small cosmetic stuff, but it was a directed query
[16:25:10] <fuzzie> well, right now, you get no chance to respond to summons :)
[16:25:30] <Avenger> eep
[16:25:35] <Avenger> the game sucks
[16:25:43] <Avenger> they actually hardcode the vvc playtime
[16:26:06] <Avenger> there are select vvcs, whose resref is compared, then the duration is set to a hardcoded value
[16:26:20] <Avenger> we definitely will ask the vvc its run length, ok?
[16:26:36] <fuzzie> sure
[16:26:53] <fuzzie> if we have to change durations we can always do it sensibly
[16:27:05] <Avenger> though, there are 3 variables determined by the resref
[16:27:23] <Avenger> one is the avatar removal duration, lemme see the others
[16:28:58] <Avenger> huh, one is the invis duration, it is set to 0, and it is not set to any other value, then it checks if it is 0, if it is nonzero, it doesn't apply invos
[16:29:02] <Avenger> huh
[16:30:46] <fuzzie> from the code i would think that +2B8 on a scriptable is 'ClearActions'
[16:30:52] <Avenger> the last variable is the visual effect length, obviously that is the vvc's runlength
[16:30:53] <fuzzie> but ToBEx disagrees
[16:30:53] <lynxlynxlynx> could be a last-minute change
[16:31:02] <Avenger> the guys appear slightly faster than the visual ends
[16:31:46] <fuzzie> oh i guess it works for both things; if it is 0 then you have no current block, so you break actions
[16:32:24] <Avenger> fuzzie, you want to know what is 2b8?
[16:32:38] <fuzzie> and look, it is checked in randomwalk, movetopoint, randomwalkcontinuous
[16:33:05] <fuzzie> Avenger: it is not important
[16:33:23] <Avenger> it is a break flag, i think
[16:33:41] <Avenger> the tobex text is nonsense :)
[16:33:48] <fuzzie> you think?
[16:33:50] <fuzzie> it makes sense
[16:33:51] <Avenger> yes
[16:34:06] <fuzzie> if it is 1 then you are executing code, if it is 0 then you break
[16:34:12] <fuzzie> but you are the one with the code
[16:34:24] <Avenger> the 'use the above' part is probably written after a single occurence, you have to see how it is used in actions
[16:34:27] <Avenger> like randomwalk
[16:34:39] <fuzzie> but it is used in very few actions
[16:34:48] <fuzzie> and yet, almost all actions can be broken
[16:34:52] <fuzzie> except randomfly
[16:34:56] <Avenger> it is used in actions that pump +1 action on the queue, i think
[16:35:03] <fuzzie> oh!
[16:35:06] <fuzzie> that makes sense
[16:35:12] <Avenger> you remember my code earlier?
[16:35:14] <fuzzie> yes
[16:35:24] <Avenger> when i pumped x on the queue, then the action itself
[16:35:26] <fuzzie> i have a text file where i put everything :P
[16:35:31] <Avenger> and a break did remove only the top
[16:35:39] <Avenger> this is to ensure it breaks correctly
[16:35:39] <fuzzie> sure, so the action has to know to die itself
[16:35:41] <fuzzie> that is cool
[16:35:44] <fuzzie> makes perfect sense
[16:35:48] <Avenger> :)
[16:36:23] <fuzzie> so there are two kinds of breaks: one is 'wipe entire queue', and the other is 'break current action'
[16:36:38] <Avenger> yes
[16:36:43] <fuzzie> but then, if randomfly cannot be broken, the first kind cannot exist
[16:37:05] <Avenger> randomfly cannot be broken
[16:37:10] <fuzzie> oh, i guess randomfly just sets nointerrupt
[16:37:14] <Avenger> that is used only in scenery birds
[16:37:16] <fuzzie> then the queue is never wiped
[16:37:23] <fuzzie> does that sound likely?
[16:37:38] <Avenger> let me see if randomfly sets any interrupt stuff
[16:37:54] <fuzzie> 00937479 66 8B 0D 50 67 AA 00 mov cx,word ptr ds:[0AA6750h] ;;not breakable
[16:38:20] <Avenger> hmm, that is not decisive
[16:38:22] <fuzzie> but i'm not sure i believe that comment
[16:38:30] <fuzzie> because every other action has that noted as '-1' :)
[16:38:56] <fuzzie> which is just blocking, right?
[16:39:06] <Avenger> no, it is just 'done'
[16:39:11] <fuzzie> ah, ok
[16:39:20] <Avenger> -1 is done, that's pretty sure
[16:39:24] <Avenger> all instants return it
[16:39:35] <fuzzie> sure, i see it in almost every action if i grep your notes
[16:39:40] <Avenger> and -2 is failure
[16:40:02] <Avenger> i 'm not sure on 1 an 0
[16:40:14] <Avenger> 1 could be blocking
[16:40:17] <Avenger> but 0 is blocking too
[16:40:43] <fuzzie> 1 is definitely blocking
[16:40:51] <Avenger> smallwait returns 1
[16:40:57] <fuzzie> i don't know what 0 s
[16:40:58] <fuzzie> is
[16:42:03] <Avenger> ok, 356 receives the return value
[16:42:12] <Avenger> i think 356 is the interruptible field :)
[16:42:22] <fuzzie> not 366?
[16:42:55] <Avenger> WORD u356; //the return value of ExecuteAction()
[16:43:00] <Avenger> ok, then this is different
[16:43:27] <Avenger> lets continue, maybe it has some effect on 366 later
[16:46:21] <fuzzie> well, none of this is vital
[16:46:30] <Avenger> ok, gimme some time, returning from virtual functions is not supported :)
[16:46:48] <fuzzie> the action stuff can all be fixed pretty well by observation
[16:46:57] <fuzzie> although i see new things everywhere
[16:46:59] <Avenger> heh, if you say so :)
[16:47:12] <fuzzie> haste checks in Wait, luck rolls(?) in BashDoor and lockpicking, etc
[16:48:08] <Avenger> yea, wanted to mention the haste thing
[16:48:17] <Avenger> haste and slow :)
[16:48:34] <Avenger> luck is basically added to any roll
[16:48:59] <fuzzie> and i have a new plan for triggers
[16:49:01] <Avenger> i found one part of the code looking for hidden doors and playing bardsong/turning etc
[16:49:17] <Avenger> dispelling illusions :)
[16:49:19] <fuzzie> i suggest: we add an AddTrigger message for everything, we keep a trigger list, we wipe triggers just before processing messages at the end of a frame
[16:49:34] <fuzzie> does that sound sensible?
[16:49:50] <Avenger> did you know that? a high detect illusions skill dispels the illusion monsters
[16:49:59] <fuzzie> the manual says so :)
[16:50:08] <Avenger> it could help in the aerie tent
[16:50:37] <fuzzie> this detect illusions stuff is run every frame, along with any modal action?
[16:50:44] <Avenger> fuzzie: don't do the trigger stuff before this release
[16:50:47] <fuzzie> that was our best bet about how secret doors work
[16:51:01] <Avenger> yes, fuzzie, maybe not every cycle, though
[16:51:07] <Avenger> i saw some timer ticking
[16:51:11] <fuzzie> i think we run those every round
[16:51:26] <Avenger> maybe the timer ticking was for bardsong
[16:51:38] <Avenger> if you stop it, it lingers for some time
[16:51:56] <Avenger> ahh, and then there is iwd2 with the lingering song feat :)
[16:52:01] <fuzzie> and yes, i guess i leave a lot of rewrites (dialog code needs rewritten, message window code, all the triggers) until after the release
[16:52:14] <fuzzie> i just wanted to know if the idea made sense
[16:52:48] <Avenger> these automatic hardcoded effects are nasty
[16:52:51] <fuzzie> i guess the real question is: when a trigger is added, is it *only* a message?
[16:53:04] <Avenger> i think it is best to create a special spell and execute it
[16:53:28] <Avenger> i don't want our core to apply random effects
[16:53:34] <fuzzie> and another thing is: when some string is displayed, what comes first, the effect opcode or the display string message? :)
[16:53:46] <fuzzie> sure, we already did the spell thing for modal effects, it is easy to do that for everything
[16:54:30] <Avenger> well, i will answer these later :)
[16:54:57] <Avenger> if you got time, look at: 008E6A1E
[16:55:08] <Avenger> it is the main living script loop :)
[16:55:17] <Avenger> full of the blocking goodies
[16:55:21] <fuzzie> heh
[16:55:29] <fuzzie> some things i hear about already
[16:55:38] <fuzzie> like object decoding in the main loop, and not in the actions
[16:55:44] <Avenger> i found it ages ago, it is even in the files
[16:55:44] <fuzzie> i think our system is better :)
[16:56:34] <fuzzie> but i would like to hear about the trigger thing, because our current system breaks too much
[16:57:00] <Avenger> we break because a type of trigger can be stored only once in our system
[16:57:46] <fuzzie> well, we break because we don't keep a list, and we break because we wipe objects, and we break because we reuse fields, and we break because fields are in Actor and not Scriptable, and.. :)
[16:58:01] <Avenger> lets say something is attacked by an elf and then a human, if it checks for attackedby([elf]), ours breaks, i think
[16:58:07] <Avenger> yes
[16:58:38] <Avenger> fields in actor and not scriptable: that's not a problem
[16:59:24] <Avenger> there is no commander of a door or container
[16:59:29] <fuzzie> sure, but there is a LastSeen
[16:59:44] <Avenger> well, if all scriptables 'see' then it should be moved
[16:59:47] <fuzzie> and there is i think a LastMarked
[16:59:58] <Avenger> move those that need to be moved
[17:00:01] <fuzzie> and we reuse LastTrigger
[17:00:07] <fuzzie> so that breaks
[17:00:11] <fuzzie> and, well, you get the idea :)
[17:00:46] <Avenger> there are 12x2 objects stored
[17:00:51] <fuzzie> it's not so hard to fix
[17:00:52] <Avenger> as 'last...'
[17:01:03] <Avenger> and additionally there is the trigger list
[17:01:11] <fuzzie> yes
[17:01:15] <fuzzie> no-one knows how the trigger list works
[17:01:22] <fuzzie> i asked on the forum, i got nothing helpful
[17:01:30] <fuzzie> this is why i ask: are things added to it only by messages?
[17:01:45] <fuzzie> i thought, you can just look somewhere which adds a trigger, and see :)
[17:02:07] <Avenger> well attackedby([elf]) looks if the trigger list has an attackedby([elf]) element
[17:02:16] <Avenger> i just don't know when the trigger list is cleared
[17:02:19] <fuzzie> that bit is easy to do
[17:02:34] <Avenger> something surely clears it
[17:02:43] <fuzzie> in fact, i did that in my local copy and it works much better :)
[17:03:20] <Avenger> all triggers are sent by message, as far as i see it
[17:03:21] <fuzzie> but i do this by what i said: i use messages for all triggers, so it is much easier to keep in sync
[17:03:53] <Avenger> but this could be because messages are easier to spot :)
[17:04:07] <Avenger> i guess noticing a virtual function call is not too easy
[17:04:17] <Avenger> it cannot be marked
[17:04:31] <Avenger> and i know only 1-2 yet
[17:05:06] <fuzzie> the trick is usually: if you find the constructor, then you can find where it fills in the vtable, and then you find the vtable, and then you have this offset<->function lookup
[17:05:12] <fuzzie> well, i guess you know this already :P sorry
[17:05:40] <Avenger> spotting a call [eax+7ch] in middle of spaghetti, is hard
[17:06:11] <fuzzie> Ascension64 says "a MessageAddTrigger that will be attached to the target"
[17:06:38] <Avenger> i said: all triggers are sent by message, as far as i see it :)
[17:06:39] <fuzzie> well, if you select a 'call' in IDA Pro then it will highlight all the 'call' keywords, which i find helpful for trying to spot things
[17:07:08] <fuzzie> but yes, it would be much nicer if it was magic :)
[17:07:23] <Avenger> there is no difficulty in finding all the parts that add a trigger by message
[17:07:33] <Avenger> the difficulty is finding the few that don't
[17:08:05] <Avenger> aa5c84 is the trigger message vtab, btw
[17:08:33] <fuzzie> that cutscene setinterrupt stuff is still weird
[17:09:01] <fuzzie> oh well
[17:09:06] <Avenger> ok, good news
[17:09:18] <Avenger> 1. the trigger is not added by virtual, this is odd...
[17:09:21] <fuzzie> i was going to ask if you knew anything about how the ToB stuff worked, but lynx thinks it's not important to fix ToB in gemrb
[17:09:28] <Avenger> 2. there are only 1-2 renegade cases
[17:09:40] <lynxlynxlynx> what??
[17:09:53] <fuzzie> well, i asked if you wanted things fixed for the release, and you said no :)
[17:10:04] <lynxlynxlynx> "for the release" ok :)
[17:10:13] <fuzzie> well, eventually we'll fix everything :P
[17:10:21] <fuzzie> so sorry, i just talk about things i want right now
[17:10:29] <fuzzie> and triggers are the #1
[17:10:32] <Avenger> there is a trigger, 0x93
[17:10:41] <Avenger> lets see which, it is added directly
[17:10:45] <fuzzie> PartyRested
[17:11:16] <Avenger> yes
[17:11:37] <fuzzie> where is it added, somewhere outside the action code?
[17:11:46] <Avenger> it is sent only to party members, iirc
[17:11:58] <fuzzie> yes
[17:12:26] <Avenger> it is the compresstime event
[17:12:59] <Avenger> i can tell you where it is called, i think it is in a message itself
[17:13:10] <fuzzie> oh, that would be perfect
[17:13:22] <fuzzie> as long as everything adding a trigger is in a message, i am very happy
[17:13:35] <Avenger> hmm, it is a virtual function of creatures o_o
[17:13:53] <Avenger> i thought it is done in the game, but no, it is called for each critter
[17:14:27] <fuzzie> Taimon said that it was on spawn points too
[17:14:31] <Avenger> it is the 0x28 vtab entry
[17:14:48] <Avenger> gotta see how it is used in spawnpoints
[17:15:00] <fuzzie> it is used by them to see if they should spawn new critters, i think
[17:17:08] <Avenger> i'm sure i miscalculated, the 0x28 for spawnpoints is rather crappy
[17:19:47] <fuzzie> woah, their CCreatureObject is huge
[17:21:12] <fuzzie> Avenger: did you decode their damage opcode hack for the slayer?
[17:21:34] <Avenger> it is easy
[17:23:09] <Avenger> there is a 'stateoverrideflag' and a 'stateoverridetime'
[17:23:19] <Avenger> we already implement those (basically)
[17:23:53] <Avenger> if any of them are set, and the source is spin823, then damage is going away
[17:24:35] <fuzzie> ok. that is easy enough, but i have no idea how to do that without hardcoding it
[17:24:49] <Avenger> there is one good way
[17:24:55] <Avenger> there is a special spell 2da
[17:25:25] <Avenger> splspec.2da
[17:25:27] <Avenger> it is a bitfield
[17:26:13] <Avenger> 1 - identify spells, 2 - can cast in silence, 4 could be: cannot damage in stateoverride :P
[17:26:41] <Avenger> so, in damage, you check if the source is in splspec with bit 4 set
[17:26:50] <Avenger> that's configurable enough
[17:28:17] <Avenger> this just needs to be documented
[17:28:34] <fuzzie> ok
[17:29:04] <Avenger> can you do this?
[17:30:54] <fuzzie> i am still trying to work out this stupid Dialog([PC]) thing, but i can do it sometime
[17:31:43] <Avenger> i am afk a bit
[17:44:08] <-- SiENcE has left IRC (Quit: cya @all)
[17:47:46] --> edheldil_ has joined #GemRb
[18:06:14] --> nickdaly` has joined #GemRb
[18:12:33] --> Micru has joined #GemRb
[18:13:03] <Micru> hi
[18:37:27] --> Maighstir_away has joined #GemRb
[18:37:41] --- Maighstir_away is now known as Maighstir
[18:51:30] <Micru> fuzzie, I have it almost done, but it seems that the gametype is needed before
[18:55:12] <fuzzie> oh? it didn't look like it, as long as you don't try doing something complicated (like trying to use search paths)
[18:58:20] <Micru> only FindInDir. i'll pass you the modified files. maybe you can spot what's wrong
[19:06:39] <-- nickdaly` has left IRC (Ping timeout: 240 seconds)
[19:07:54] --> nickdaly has joined #GemRb
[19:22:14] <-- kettuz has left IRC (Quit: Leaving)
[19:31:32] <Micru> here: https://sites.google.com/site/dacuetu/patch_autodetect_game.zip
[19:32:47] <Micru> somehow it is as if that part of the code is not executed or there is something overwriting it
[19:40:49] <Micru> now i'm looking for exe's, but if needed i could detect the install type by looking at the data folder
[19:41:22] <Micru> the installed files can be found here: https://sites.google.com/site/dacuetu/output_files_installs.zip
[19:42:22] <lynxlynxlynx> you're in a git clone
[19:42:33] <lynxlynxlynx> if you want to show changes, just run git diff and upload that somewhere
[19:43:09] <Micru> i'll try
[19:50:29] <Micru> http://pastebin.ca/1917586
[19:50:57] <fuzzie> well, your modification to FindInDir is going to break things very quickly
[19:52:22] <Micru> there is nothing using findindir, is it?
[19:52:34] <Avenger> hi lynx
[19:52:35] <fuzzie> the main file code uses FindInDir
[19:52:58] <Micru> ok, then i shouldnt change it
[19:53:03] <fuzzie> so with your change, nothing will ever find files unless their case matches exactly
[19:53:07] <fuzzie> maybe that is what breaks for you?
[19:53:31] <Micru> it could be that it breaks before of getting to my part
[19:54:59] <Micru> how can i pass constant strings to findindir?
[19:55:05] <fuzzie> you can't
[19:55:39] <fuzzie> you can use a temporary buffer, though, and copy your string into it
[19:55:46] <Micru> ok
[19:55:59] <fuzzie> which this code needs to do eventually anyway, because the data will have to come from a 2da
[19:56:26] <Micru> yes, i know, i just wanted to try it first
[19:56:32] <fuzzie> sure :)
[19:56:42] <fuzzie> i just mean, it is not wasted work
[19:57:56] <lynxlynxlynx> i think it would be better to always do autodetection if the type or the name isn't set (=old configis)
[19:58:08] <Micru> probably i should move those gamename strings to a 2da too
[19:58:15] <Micru> ok
[19:59:03] <fuzzie> more notes: no Dialog actions block, they all exit as soon as dialog is started
[19:59:34] <fuzzie> ok, so this is obvious, but i thought i'd make sure
[20:05:56] --> SiENcE has joined #GemRb
[20:15:43] <nickdaly> I was wondering, has there been any decision whether to accept or reject the multiple configs patch? http://bit.ly/dtVbvY
[20:16:25] <lynxlynxlynx> there's plenty of comments in the tracker
[20:17:17] <nickdaly> I was pretty sure all of the comments had been implemented, but I'll take another loo
[20:17:19] <nickdaly> * look
[20:17:51] <nickdaly> Yup, I think they were.
[20:18:10] <fuzzie> i think i tried looking and there's no working http url there
[20:18:21] <fuzzie> lemme go through your user page
[20:19:03] <nickdaly> huh. The right link is http://github.com/NickDaly/GemRB-MultipleConfigs
[20:19:48] <nickdaly> I must've renamed it at some point, I guess
[20:21:04] <fuzzie> but i think my last comment was that you broke it on Windows
[20:22:15] <nickdaly> It should be fixed on Windows. It just doesn't change the current Windows behavior.
[20:22:27] <fuzzie> it does
[20:22:41] <fuzzie> because you split off FixConfig
[20:22:48] <nickdaly> haha, it's not *supposed to*
[20:23:12] <fuzzie> but you also break everyone's installs because it doesn't check for GemRB.cfg any more
[20:23:30] <fuzzie> unless LoadConfig is case-insensitive now
[20:23:56] <fuzzie> but those are the two things i remember, and they seem to still be there :/
[20:24:25] <nickdaly> Case-sensitive config names never made sense to me - that just seems like a bug waiting to happen to some poor user.
[20:24:38] <fuzzie> well, you don't seem to have fixed it
[20:24:43] <fuzzie> maybe you did?
[20:25:53] <nickdaly> well, I mean: depending a mixed-case config name is probably going to surprise users
[20:25:58] <fuzzie> sure
[20:26:04] <fuzzie> but everyone has a 'GemRB.cfg' right now
[20:26:55] <nickdaly> that's something that you might want to change before the 1.0 release, but I'll fix my bug .
[20:27:28] <fuzzie> well, i have no problem with it being case-sensitive
[20:27:54] <fuzzie> but i don't like patches which break people's installs, users get confused enough as it is
[20:27:58] <fuzzie> erm, case-insensitive.
[20:28:05] <nickdaly> fair enough
[20:28:31] <nickdaly> yeah, it's just the mixed-case-ness - changing to case-insenitive would fix that without breaking installs
[20:29:42] <Avenger> fuzzie, do you know about some association between stats and saving throws?
[20:30:08] <Avenger> ahh, ok this is all constitution
[20:30:21] <fuzzie> heh
[20:30:31] <fuzzie> i mean, you man other than the saving throw stats? :)
[20:31:12] <Avenger> i'm checking the level drain code, and i noticed some recalculation using a stat and a saving throw, i didn't notice all saving throws use the same :)
[20:31:12] <Maighstir> it'll break installs if someone has both gemrb.cfg and GemRB.cfg - but then they probably know what they're doing and can fix it with relative ease
[20:31:51] <nickdaly> Maighstir: do you mean currently, or with the proposed patch? The changes I'm making now should cause it to ignore the lowercase "gemrb.cfg"
[20:32:16] <fuzzie> we print the config file we open, so
[20:32:30] <Maighstir> changing to case-insensitive, I mean
[20:32:43] <fuzzie> i guess we really need to have a logging framework :(
[20:33:51] <lynxlynxlynx> i'm against case-insensitivity too
[20:34:08] <fuzzie> well, from the sound of it, nickdaly is just going to check GemRB.cfg and then gemrb.cfg
[20:34:40] <Lightkey> lynxlynxlynx: I am not sure anyone else is ;-)
[20:34:49] <fuzzie> i personally am happy with any patch which makes nothing worse
[20:35:08] <nickdaly> Not quite ;) - we're just checking one of them, unless the user asks for additional configs. Then, we'll look in "~/.gemrb/" and SYSCONFDIR
[20:35:47] <fuzzie> "do no harm" along with "do as i say, not as i do" covers it nicely i guess :-)
[20:36:10] <nickdaly> and if we find additional configs, we include the extra options from the extra configs - essentially allowing config file templating/including
[20:36:56] <nickdaly> Yay, CMake! You're so much easier than make!
[20:37:10] <nickdaly> (or make alone, anyway)
[20:39:05] <Maighstir> so how would it determine the the active value of a setting, if two configs has the same setting but different values? (such as Width=640 and Width=800)
[20:39:24] <nickdaly> it's read from the first config file
[20:39:31] <nickdaly> (./gemrb)
[20:39:40] <nickdaly> rather, ./GemRB.cfg
[20:40:20] <nickdaly> it reads each setting once, never overriding them, starting with: ./GemRB.cfg, ~/.gemrb/, SYSCONFDIR
[20:41:49] <nickdaly> so, if you specify Width in both ./GemRB.cfg and SYSCONFDIR, it'll read the local one and ignore SYSCONFDIR's value.
[20:41:59] <fuzzie> a lot simpler to customise a config file if you just need the game-specific bits.
[20:42:04] <nickdaly> yup!
[20:42:20] <fuzzie> i do notice on the forum posts etc that people struggle with the whole thing.
[20:42:24] <nickdaly> my config files are 5 lines long
[20:42:31] <nickdaly> it's magical
[20:46:25] <fuzzie> but we are pretty bad at applying patches
[20:46:41] <nickdaly> I think I've fixed both the broken windows (hehe) and the config filename with this latest update... I'll test it a few times first though.
[20:47:06] <nickdaly> Don't have Windows, so can't actually test that part, but I can make sure it didn't change anything else
[20:48:04] <fuzzie> i have applied patch #2909449 now (fix finding next actor in banters), if anyone can login to sf and close that
[20:48:14] <fuzzie> pity about finding the *first* actor in banters :P
[20:49:52] <fuzzie> and i guess Avenger fixed #2813259 (CombatCounter)
[20:50:36] <fuzzie> Avenger: is your "sound effects are rarely played" bug still there?
[20:51:10] <Avenger> i think there is a channel leak
[20:51:10] <lynxlynxlynx> i still think overriding with includes would be better
[20:51:21] <Avenger> if you play for a long time, you can see it even in linux
[20:51:34] <fuzzie> lynxlynxlynx: is there a way to do that without having the includes in the user config?
[20:51:37] <lynxlynxlynx> fifo settings are hard to track down if you want to change them
[20:51:40] <fuzzie> i haven't looked at the proposals
[20:52:03] <lynxlynxlynx> i'm fine with includes
[20:52:23] <fuzzie> just looking from the perspective that users manage to mess up all kinds of internal lines in the example configs of the porters, so not having any unnecessary lines in the user-edited config would be nice
[20:53:06] <Maighstir> I'd like includes
[20:53:20] <fuzzie> myself, i am unlikely to use any of this myself
[20:53:31] <Avenger> i saw someone complaining that /somepath/ /some.cbf is not in his system :)
[20:53:32] <fuzzie> because i know what everything does :)
[20:53:47] <Avenger> they just added a space after the last / :)
[20:53:55] <fuzzie> and i guess if i did use anything, i would use the includes
[20:54:05] <Maighstir> would make it easy to have one central config with default settings, untouchable by non-admin users and a config for each user that they can mess with themselves
[20:54:08] <fuzzie> but i don't see them being too helpful for confused end-users
[20:54:40] <Avenger> is that a realistic scenario?
[20:55:28] <fuzzie> lynxlynxlynx: would you object to having both?
[20:57:25] <nickdaly> fuzzie, if you would look at the latest commit, I think that fixes both issues.
[20:58:06] <nickdaly> the majority of *nix programs seem to check multiple locations for config file overrides/additions - checking ~/.whatever/ before /etc/whatever/
[20:58:54] <fuzzie> they generally override, they pick the first config, though
[20:58:59] <fuzzie> so it's not a very good example
[20:59:14] <fuzzie> i think tomprince would argue that there shouldn't *be* any need for a global config file
[21:00:34] <-- Micru has left IRC (Remote host closed the connection)
[21:01:09] <Maighstir> if he'd argue that, how would GemRB know where the games sit? magic? command-line switch --game-sits-at=/mnt/winshare/bg1/ ?
[21:01:45] <fuzzie> well, that would be in the 'local' config
[21:02:11] <fuzzie> but i think his argument was that the game path should really be the only thing you need
[21:02:32] <Maighstir> so each user would need a copy of the same file even if they do not care to change it themselves?
[21:02:41] <nickdaly> perhaps the game path should really be the only thing you need to override
[21:02:42] <Maighstir> but yes, I can agree with the second statement
[21:02:46] <fuzzie> well, i think Avenger's question applies
[21:03:04] <fuzzie> you think anyone will really run gemrb on some multi-user system like that?
[21:03:27] <fuzzie> maybe they would, i don't know :)
[21:03:39] <nickdaly> storing the default config values within the engine would allow the engine to regenerate its config on demand and seriously simplify the config files themselves
[21:04:00] <fuzzie> i think we do try and store as much default config as we can
[21:04:14] <nickdaly> yeah, you're pretty close already, it seems
[21:04:24] <fuzzie> i don't know anything about it.
[21:04:24] <-- pupnik has left IRC (Quit: leaving)
[21:04:33] <Maighstir> I know in many Windows games, the settings are user-specific. And if I manage to finish this dataset I'm working on, it'll probably be installed on a number of multiuser systems
[21:04:46] <nickdaly> most of the paths (other than the GemRBPath) don't need to be specified
[21:05:05] <fuzzie> i think, if you 'make install', the GemRBPath should be automatic too, with cmake
[21:05:20] <nickdaly> very nice
[21:05:51] <fuzzie> but you should ask lynxlynxlynx
[21:06:13] <Avenger> haha, this code is ridiculous. The IE derived stats is a complex class, the level drain code got two of these in a local object. At every tick it builds/copies/destructs about 14*2 lists
[21:06:23] <fuzzie> i think i'll have to look at your patch when i'm awake, at least to get more comments from lynx
[21:06:45] <Avenger> it doesn't use the lists for anything :)
[21:06:48] <nickdaly> I actually specify a couple more paths (cachepath, savepath, etc), but that's just because I'm crazy and like everything stored under ~/.local
[21:07:45] <Maighstir> GemRB accepts ~ in config files?
[21:07:57] <fuzzie> yes
[21:08:06] <nickdaly> ooh, is that new?
[21:08:41] <fuzzie> i think it has done so forever
[21:09:13] <fuzzie> but ok maybe only since June :)
[21:09:40] <fuzzie> see 51eda9b3
[21:09:57] <fuzzie> oh, no, that just makes it work with strings
[21:10:33] <fuzzie> "resolve ~ in pathnames" by Avenger in 2007, 0af9206f
[21:16:43] <nickdaly> Alright! No conflicts between my patches and the current head!
[21:21:42] <lynxlynxlynx> the gemrbpath can be burnt in, yes
[21:22:15] <lynxlynxlynx> all of them can and since they can be individually changed, i think all of them should
[21:23:13] <fuzzie> i thought they were all burnt in
[21:23:31] <fuzzie> not a solution for everyone, but it is something
[21:24:27] <lynxlynxlynx> nothing is
[21:29:50] <fuzzie> no :(
[21:29:54] <fuzzie> so i leave decisions in your hands
[21:30:08] <fuzzie> i am *still* messing with dialog :)
[21:33:53] <fuzzie> if i click Check here, DLTCEP complains about my action, but i don't know why :(
[21:36:38] <fuzzie> i suppose it is just stupid
[21:51:53] <Avenger> which part of dltcep?
[21:52:03] <Avenger> ahh dialog editor?
[21:52:06] <Avenger> well :)
[21:52:31] <-- Avenger has left IRC (Quit: ChatZilla 0.9.86 [Firefox 3.6.8/20100722155716])
[21:52:40] <fuzzie> dialogs are just *weird* in the original engine
[21:55:16] <fuzzie> oh!
[21:55:21] <fuzzie> i had SetInterrupt(FALSE) on
[21:55:41] <fuzzie> and this means dialog scripts can't interrupt the running code
[21:56:24] <fuzzie> that is an interesting discovery
[22:00:36] --> pupnik has joined #GemRb
[22:02:27] <fuzzie> but means i wasted half an hour, :(
[22:04:03] <-- SiENcE has left IRC (Quit: cya @all)
[22:04:45] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[22:05:47] --> nickdaly` has joined #GemRb
[22:07:33] <-- nickdaly has left IRC (Ping timeout: 265 seconds)
[22:13:07] <fuzzie> this general knowledge about instants is all wrong
[22:17:37] <fuzzie> everything is added to a list, that list is cleared on transitions between actors, the list is executed at the end of the dialog
[22:18:08] <fuzzie> v.interesting
[22:29:41] <-- Maighstir has left IRC (Quit: Maighstir)
[23:50:59] <-- edheldil_ has left IRC (Ping timeout: 265 seconds)