#gemrb@irc.freenode.net logs for 1 Nov 2010 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage

[00:04:33] <-- SiENcE has left IRC (Quit: cya @all)
[00:43:00] <-- edheldil_ has left IRC (Quit: Really?)
[01:31:23] <-- Maighstir has left IRC (Quit: ~ Trillian Astra - www.trillian.im ~)
[02:20:35] <-- fuzzie has left IRC (Ping timeout: 276 seconds)
[02:28:51] --> fuzzie has joined #GemRb
[07:08:57] <CIA-29> GemRB: 03avenger_teambg * rae9e5dd80a9b 10gemrb/gemrb/plugins/FXOpcodes/FXOpcodes.cpp: FXOpcodes: small updates
[07:59:33] --> lubos has joined #GemRb
[08:08:13] --> lynxlynxlynx has joined #GemRb
[08:08:13] --- ChanServ gives channel operator status to lynxlynxlynx
[08:51:21] <lynxlynxlynx> the inparty checks won't be problematic, we can just swap them with IsSelected() :)
[08:59:13] <fuzzie> summons get all that stuff?
[08:59:44] <fuzzie> not sure what kind of thing you were looking at
[09:00:02] <lynxlynxlynx> they do
[09:00:24] <lynxlynxlynx> well, i'll check with a real summon, the illusion may be different
[09:00:36] <fuzzie> but it's trivial to make a new function for whatever is needed
[09:01:24] --> SiENcE has joined #GemRb
[09:02:17] <-- SiENcE has left IRC (Quit: @all: cya)
[09:03:49] <lynxlynxlynx> yeah it works for regulars too, so it is fine
[09:05:31] <fuzzie> i thought that by feedback you meant messages which appeared when unselected, but i didn't really ask
[09:05:47] --> Avenger has joined #GemRb
[09:05:47] --- ChanServ gives channel operator status to Avenger
[09:05:52] <Avenger> hello
[09:06:16] <lynxlynxlynx> that's just part of it
[09:06:17] <fuzzie> hi, Avenger
[09:06:18] <lynxlynxlynx> oj
[09:06:35] <fuzzie> hm, i forgot what was on my 'ask Avenger' list
[09:06:50] <fuzzie> oh, right
[09:07:02] <fuzzie> you have any idea which action is used in the original when you click on travel regions? :)
[09:07:09] <Avenger> yes
[09:07:28] <Avenger> well, idea is: LeaveAreaName
[09:07:36] <Avenger> it is opcode 0x93, i think
[09:07:47] <Avenger> it isn't in the action.ids
[09:08:00] <Avenger> all engine versions use it
[09:08:00] <fuzzie> ok.
[09:08:12] --> SiENcE has joined #GemRb
[09:08:15] <fuzzie> i fixed GenerateAction so it can make actions from our gemact.ids already :)
[09:08:20] <SiENcE> hey fuzzie
[09:08:23] <fuzzie> hi SiENcE
[09:08:26] <SiENcE> i have a short question
[09:08:35] <SiENcE> i compiled the latest svn
[09:08:37] <Avenger> if you can, make LeaveAreaName usable for scripting too :)
[09:08:55] <SiENcE> now during the load screen there is a picture displayed
[09:08:58] <Avenger> the original has the global ID hacked in by their version of generateaction
[09:09:32] <SiENcE> where can i find it in the sources? i ask because its not centered and i like to adjust it
[09:09:56] <Avenger> hmm, the mismatch happens due to borders, i think...
[09:10:04] <Avenger> so it is not a number issue
[09:10:27] <fuzzie> SiENcE: which game?
[09:10:32] <SiENcE> iwd1
[09:10:34] <Avenger> you can test that by going with a resolution without frames
[09:10:43] <lynxlynxlynx> yes, it is broken here too
[09:10:55] <fuzzie> huh, i thought LoadWindowPack with 640/480 was meant to fix that?
[09:10:56] <lynxlynxlynx> i think it only works on the minimum resolution
[09:11:10] <fuzzie> but it's in the iwd code
[09:11:21] <SiENcE> i also downscale to 320x240 but from 640x480
[09:11:22] <Avenger> yes fuzzie, but somehow the loadscreen is broken
[09:11:30] <fuzzie> oh. but that is ours?
[09:11:32] <SiENcE> so it should not depend on what i'm doing
[09:11:54] <Avenger> i considered it only a marginal problem so i didn't bother with it. But it is definitely because of my recent loadscreen changes
[09:12:17] <fuzzie> well, i'm not sure what to do about the loadscreen stuff
[09:12:27] <fuzzie> it made gui bugs so much worse, we have to find a permanent solution
[09:12:43] <Avenger> yep
[09:13:02] <SiENcE> can someone point me to the sourcefile?
[09:13:07] <Avenger> the other bug where you move across areas while other windows are open is also crappy
[09:13:20] <Avenger> sience: i think it is the loadscreen script
[09:13:23] <fuzzie> SiENcE: well, it is in GUIScripts/iwd/LoadScreen.py but probably you want override/iwd/guils.chu?
[09:13:38] <SiENcE> ok thx i take a look into it
[09:14:06] <fuzzie> well, moving across areas while other windows are open should be fine, if you disable the loadscreen stuff?
[09:14:18] <Avenger> i'm sure guils.chu is fine. You can edit/browse it only with dltcep. it uses a gemrb specific control
[09:14:23] <fuzzie> maybe i forgot to apply that patch
[09:15:16] <Avenger> but that doesn't happen in the original
[09:15:24] <fuzzie> oh, iwd's LoadScreen.py is completely broken
[09:15:29] <Avenger> hmm
[09:15:34] <Avenger> more than usual?
[09:15:45] <fuzzie> yes
[09:15:48] <Avenger> how
[09:15:49] <fuzzie> you added stuff which doesn't work :)
[09:15:52] <SiENcE> so this might be wrong?
[09:15:52] <SiENcE> if LoadPic=="":
[09:15:53] <SiENcE> LoadPic = "GUILS0"+str(GemRB.Roll(1,9,0))
[09:15:53] <SiENcE> LoadScreen.SetPicture(LoadPic)
[09:16:15] <fuzzie> SiENcE: well, that doesn't seem like it could go wrong, which is why i thought the chu file is to blame
[09:16:26] <SiENcE> ah ok
[09:16:33] <fuzzie> ok, i guess i should get rid of all the HideGUI call
[09:16:39] <fuzzie> s
[09:16:50] <Avenger> that will break somethng else
[09:16:55] <fuzzie> i mean, in the whole of gemrb
[09:17:27] <fuzzie> it causes so many disasterous bugs
[09:18:02] <Avenger> well, if that fixes them, fine :)
[09:18:40] <fuzzie> i talked with tomprince about some better design. should implement that. but after the other stuff, i guess.
[09:19:14] <fuzzie> Avenger: also, any idea if ChangeAIScript is done in the action or in a message?
[09:19:54] <Avenger> betting $10 on the message, but let me see
[09:20:34] <Avenger> the script would kill itself? that's your problem?
[09:20:46] <Avenger> in the original, the current action is copied into the actor
[09:20:52] <Avenger> so it would work either way for them
[09:21:15] <Avenger> in our engine, we try to fix this by 'clever' refcounts
[09:21:18] <Avenger> but it fails
[09:21:35] <fuzzie> no, it is ok
[09:22:00] <Avenger> anyway, refcounts are a bad idea, as the original engine modifies the action while running
[09:22:02] <fuzzie> i mean, the script does kill itself, but that is easy enough to fix
[09:22:03] <Avenger> we cannot do that
[09:22:10] <Avenger> we should also copy the current action
[09:22:13] <fuzzie> i didn't find any place yet where we need to modify actions while running
[09:22:17] <Avenger> that would so much fix a lot of things
[09:22:26] <Avenger> heh
[09:22:34] <Avenger> don't you
[09:22:37] <fuzzie> no
[09:22:44] <fuzzie> int0Param and the stored object are covered in other ways
[09:22:59] <Avenger> some actions alter their int0param in the original
[09:23:05] <fuzzie> (two fields in the Scriptable, set at the first run)
[09:23:50] <fuzzie> seems silly to allocate copies of every single action if that suffices
[09:23:50] <CIA-29> GemRB: 03lynxlupodian * r079ec39db2c6 10gemrb/gemrb/core/ (Inventory.cpp Inventory.h Scriptable/Actor.cpp): copy the inventory too when copying the actor (for simulacrum and project image)
[09:23:55] <CIA-29> GemRB: 03lynxlupodian * re487f85ba91e 10gemrb/gemrb/ (3 files in 3 dirs): update the actionbar when something changes for selected npcs too
[09:23:56] <CIA-29> GemRB: 03lynxlupodian * re15f536545ed 10gemrb/gemrb/core/Scriptable/Actor.cpp: illusions don't explore the area
[09:23:57] <CIA-29> GemRB: 03lynxlupodian * r4406321a7c1d 10gemrb/gemrb/ (3 files in 2 dirs): mislead creates just a useless actor, that can't do anything but move around
[09:24:08] <Avenger> whoa, lynx, if a simulacrum dies, will it drop its inventory?
[09:24:15] <lynxlynxlynx> no
[09:24:20] <Avenger> cool
[09:24:27] <Avenger> i wonder how you solved that :)
[09:24:35] <fuzzie> set IE_INV_ITEM_UNDROPPABLE
[09:24:38] <Avenger> not like it is difficult, but i'm still curious
[09:24:39] <fuzzie> on all inv items
[09:25:01] <Avenger> well, it can work, now i'm curious how the original did it ;)
[09:25:17] <Avenger> hmm, what happens if you save the game while a simulacrum is alive
[09:25:22] <fuzzie> we can also check stuff on death, to be sure
[09:25:42] <lynxlynxlynx> that should be fine now, we used to save them with the wrong cre version
[09:25:43] <fuzzie> Avenger: but really, is there stuff other than int0Param and one stored object?
[09:26:00] <fuzzie> it really seems silly to waste memory on loads of copies of actions, but it would be easy to do..
[09:26:34] <Avenger> actually, changeaiscript changes the script on the fly
[09:26:48] <fuzzie> ok
[09:27:01] <Avenger> the original also copies all actions on the queue, no refcounting
[09:27:20] <fuzzie> sure
[09:27:24] <Avenger> i would like to avoid that, though
[09:27:27] <fuzzie> it doesn't refcount actions anywhere, right?
[09:27:33] <Avenger> no i don't think so
[09:27:36] <fuzzie> but i don't see why we shouldn't refcount actions everywhere :)
[09:27:42] <Avenger> it copies actions all the time
[09:28:05] <Avenger> yeah, i would like to do it our way, because it speeds up scripts
[09:28:18] <Avenger> the original had issues at some places
[09:28:40] <fuzzie> 'CurrentActionState' is where i store int0Param, 'CurrentActionTarget' is for the stored globalid
[09:28:43] <Avenger> like the illithid stronghold, i think it was a script overload
[09:29:00] <fuzzie> well, they do *crazy* amounts of things
[09:29:03] <Avenger> that's a good idea
[09:29:23] --> barra_library has joined #GemRb
[09:29:31] <fuzzie> i think our scripting is really fast right now, compared
[09:29:33] <fuzzie> except for bag checking :)
[09:31:12] <fuzzie> lynxlynxlynx: if a party member has spellcasting disabled while not selected, didn't you just disable feedback?
[09:32:07] <Avenger> the original engine has 12 slots for store caching
[09:32:17] <Avenger> we got only one?
[09:32:53] <Avenger> and the original has a simplified store loader that loads only the inventory of a store, in case of bag inspections
[09:32:57] <lynxlynxlynx> for creative mod writers; i don't think it's a problem with the vanilla data
[09:33:04] <Avenger> it is a read-only operation
[09:33:22] <lynxlynxlynx> that'd be great to habe
[09:33:23] <lynxlynxlynx> have
[09:33:25] <fuzzie> i think there are some other issues in there with PCStats
[09:33:36] <fuzzie> but i'm not sure
[09:33:50] <lynxlynxlynx> i'm valgrinding it and it's complaining a lot
[09:34:01] <fuzzie> ok
[09:34:03] <lynxlynxlynx> pcf_maxhitpoint and stuff like that that should be fine
[09:34:11] <fuzzie> my last valgrind run (with python suppressed) was almost entirely clean
[09:34:23] <Avenger> fuzzie: got the info on changeaiscript?
[09:34:24] <fuzzie> after the fixes
[09:35:16] <fuzzie> Avenger: well, if it changes the script on the fly, that is enough :)
[09:36:22] <fuzzie> also, LeaveAreaName(O:Target*) you think?
[09:36:25] <lynxlynxlynx> btw, new valgrind is out
[09:36:56] <fuzzie> with support for ARM? nice
[09:37:54] <-- barra_library has left IRC (Quit: Verlassend)
[09:42:23] <lynxlynxlynx> Avenger: there's no simple way to copy the spellbook too, right?
[09:42:57] <Avenger> lynx: well, you did the inventory too ;) i bet it wasn't simple either
[09:43:52] <lynxlynxlynx> it wasn't, but it is much smaller and fuzzie helped a lot
[09:43:58] <Avenger> fuzzie: yep, that would work
[09:44:21] <fuzzie> spellbook should also not be too hard
[09:44:50] <Avenger> it has more layers full of nasty pointers :)
[09:45:15] <fuzzie> only one more layer
[09:46:00] <fuzzie> you want to iterate through the 'spells' array and copy the four ieWord values manually, and then go through the 'known_spells' and 'memorized_spells' arrays inside and memcpy those into newly-allocated ones
[09:47:09] <fuzzie> then just copy sorceror. no need to copy spellinfo, i think?
[09:48:01] <fuzzie> yes, that should suffice
[09:49:34] <fuzzie> it would be nice if you could name the function 'CopyFrom' though
[09:49:55] <lynxlynxlynx> ok
[09:50:02] <fuzzie> completely unimportant but a little easier for me to understand at a glance :)
[09:50:35] <lynxlynxlynx> i started with CopySelf like the others, but then it didn't make sense with a parameter
[09:50:46] <fuzzie> re the existing patch: you should allocate the new CREItem() inside the 'if (item)' in Inventory::Copy, otherwise you leak it
[09:51:51] <fuzzie> otherwise it all looks fine
[09:51:56] <lynxlynxlynx> ok, thanks
[09:53:42] <lynxlynxlynx> http://pastebin.ca/1978561 if (first || Modified[i]!=previous[i]) {
[09:54:20] <fuzzie> 'first' should be set?
[09:54:25] <lynxlynxlynx> could this be just a bad detection? Only first looks like it could have a wierd value, since we don't copy the internal flags, but both of the others are identical
[09:54:42] <lynxlynxlynx> it's set some 30 lines before
[09:55:13] <fuzzie> InternalFlags are set in the constructor
[09:55:43] --> barra_library has joined #GemRb
[09:56:12] <fuzzie> so that's weird
[09:58:02] <lynxlynxlynx> i'll skip it
[09:58:30] <Avenger> i saw that before, but i couldn't find out why.
[09:59:15] <Avenger> what if i copy an uninitialized value? will it consider the copy as uninitialized too?
[09:59:21] <fuzzie> yes
[10:00:14] <fuzzie> run with '--track-origins=yes' and it will tell you where it came from, but it's slower
[10:00:48] <Avenger> i suspect modified holds some uninitialized field
[10:01:07] <Avenger> that came from the base stats
[10:18:05] <-- barra_library has left IRC (Ping timeout: 255 seconds)
[10:19:07] <lynxlynxlynx> heh, one line killed all the warnings
[10:25:59] <CIA-29> GemRB: 03lynxlupodian * r761b86163d1d 10gemrb/gemrb/core/Inventory.cpp: Inventory::Copy: removed a leak from 079ec39db
[10:26:00] <CIA-29> GemRB: 03lynxlupodian * re810709fec2a 10gemrb/gemrb/core/Scriptable/Actor.cpp: fixed valgrind warnings from Actor::CopySelf
[10:26:01] <CIA-29> GemRB: 03lynxlupodian * rc0384b17797a 10gemrb/gemrb/core/ (Inventory.cpp Inventory.h Scriptable/Actor.cpp): renamed Inventory::Copy to Inventory::CopyFrom for clarity
[10:32:26] <lynxlynxlynx> Avenger: i believe fx_maximum_hp_modifier should also adjust the current hp in the percentage modifier case
[10:32:40] <Avenger> may be
[10:32:51] <Avenger> ahh, and all percentage modifiers should use GetSafeStat :)
[10:32:52] <lynxlynxlynx> tenser's transformation uses it like that
[10:33:06] <Avenger> percentages are calculated from the previous (stable) stat
[10:33:17] <lynxlynxlynx> just 200% it
[10:33:25] <Avenger> not the one just being built
[10:33:32] <lynxlynxlynx> oh
[10:33:39] <lynxlynxlynx> you documented this in dltcep
[10:33:52] <lynxlynxlynx> 2 and 5 are percentage, but 5 doesn't alter the current hp
[10:34:02] <Avenger> oh
[10:34:12] <Avenger> that i forgot somehow
[10:34:22] <Avenger> or got lost somehow
[10:36:53] <lynxlynxlynx> want me to add it?
[10:40:44] <Avenger> yea
[10:40:46] <Avenger> sure
[10:41:02] <Avenger> i'm in windows, cannot add anything :)
[10:57:29] <lynxlynxlynx> can you check what the effect does with the current hp when the type is 1 (flat)?
[10:57:58] <lynxlynxlynx> not sure whether it should just be set to the new max, set via scaling or something else
[11:07:56] --> barra_library has joined #GemRb
[11:13:02] <Avenger> i was eating :)
[11:14:07] <Avenger> so what is the question?
[11:14:16] <lynxlynxlynx> no problem, i was debugging the safe stat problem
[11:14:38] <lynxlynxlynx> what to set current hp to when the max is set to a flat value
[11:15:10] <Avenger> it doesn't change the current hp
[11:15:30] <lynxlynxlynx> are you sure? why two types then?
[11:15:48] <lynxlynxlynx> (1 and 4)
[11:16:40] <Avenger> good question, but they are identical
[11:16:59] <Avenger> i could post them on pastebin, a moment
[11:18:00] <lynxlynxlynx> ok, maybe it was just an interpolation when you wrote those docs
[11:18:22] <Avenger> http://pastebin.com/5Bf0YrcZ
[11:18:53] <Avenger> it is weird, anyway
[11:19:21] <Avenger> 412h would be the current hp
[11:19:27] <Avenger> it is touched by 0 and 2
[11:20:49] <lynxlynxlynx> what's the ebp-1Ch vs ebp-10h difference?
[11:21:32] <lynxlynxlynx> ok, i'll just leave them identical
[11:25:38] <Avenger> that's irrelevant. temporary variables are always separate
[11:26:25] <Avenger> each temporary variable has a different storage area, it bloats the stack, but requires less optimisation
[11:40:36] <-- Avenger has left IRC (Ping timeout: 240 seconds)
[11:44:21] --> Avenger has joined #GemRb
[11:44:21] --- ChanServ gives channel operator status to Avenger
[12:16:56] <edheldil> Hi all
[12:18:31] <Avenger> hello ed
[13:20:41] <Avenger> bg1 has no journal sections?
[13:21:35] <lynxlynxlynx> i think not, as in iwd
[13:21:46] <lynxlynxlynx> i do remember it was annoying it didn't break off completed quests
[13:22:56] <Avenger> problem is, when loading a game with journal sections, it crashes bg1
[13:23:29] <Avenger> it handles the section and the chapter as a single entity, so the chapter becomes 0x40000 which is then used without boundary checking
[13:24:05] <fuzzie> because gemrb sets a section?
[13:24:06] <Avenger> most likely we'll need another game flag
[13:24:08] <Avenger> yes fuzzie
[13:24:11] <fuzzie> hm
[13:24:14] <Avenger> gemrb sets the section to 4
[13:24:20] <fuzzie> ok, that explains another bug i found
[13:24:44] <Avenger> i just try to 'fix' this savegame i got from devurandom ;)
[13:24:50] <fuzzie> i just figured it would default to 0 unless it was bg2
[13:24:52] <Avenger> now manually set all sections to 0
[13:25:20] <Avenger> hmm, i guess, if you do that, it would fix my bug
[13:26:08] <Avenger> even iwd2 sections?
[13:26:39] <Avenger> well, maybe it has no sections, i don't know
[13:26:47] <fuzzie> but i don't see why you'd get section 4, still
[13:26:50] <fuzzie> what sets a section to 4?
[13:27:13] <Avenger> i have no idea, i don't even know if it is 4 in original bg2
[13:29:02] <fuzzie> i don't see why it would be set to anything except 0..
[13:29:13] <fuzzie> which is why i thought, the section can't be the bug i found
[13:30:23] <Avenger> if (core->GetGame()->AddJournalEntry(tr->journalStrRef, sectionMap[Section], tr->Flags>>16) ) (in dialogs)
[13:30:33] <fuzzie> oh, right, dialogs
[13:30:53] <Avenger> complicated crap :)
[13:30:58] <fuzzie> static const int sectionMap[4]={4,1,2,0};
[13:31:00] <fuzzie> ^- heh
[13:31:04] <Avenger> hmm
[13:31:26] <Avenger> it is 4 in the original game, though
[13:31:29] <Avenger> in bg2
[13:31:39] <fuzzie> but that map is bg2-specific, right?
[13:31:49] <Avenger> well, bg2 is the most researched one, yeah
[13:31:58] <Avenger> since the rest got no sections
[13:32:09] <Avenger> sucks that 0 maps to 4
[13:32:48] <fuzzie> well, we just need some game flag which ignores the sectionMap, i guess
[13:32:54] <Avenger> you cannot avoid a GF_JOURNAL_HAS_SECTIONS
[13:34:13] <fuzzie> we're missing an IE_DLG_REMOVE == 0x80 anyway?
[13:34:26] <Avenger> what's that
[13:35:12] <Avenger> some dialog flag?
[13:35:27] <fuzzie> yes, what does DLTCEP think for those?
[13:35:37] <Avenger> no idea what is it
[13:35:41] <Avenger> where is it?
[13:36:49] <Avenger> i don't know what you mean
[13:37:36] <Avenger> cool, when i manually swapped all the sections from 4 to 0, the savegame works :)
[13:37:53] <fuzzie> oh, maybe DLTCEP doesn't do the dialog flag at all?
[13:38:07] <Avenger> fuzzie: i don't know which flag you talk about.
[13:38:17] <fuzzie> oh, no, it does
[13:38:23] <fuzzie> #define HAS_QUEST 64 //missing quest
[13:38:23] <Avenger> O_o
[13:38:26] <fuzzie> //#define ????? 128
[13:38:29] <fuzzie> ^- the one in the middle
[13:38:32] <fuzzie> #define HAS_SOLVED 0x100 //solved quest
[13:38:40] <Avenger> ok, i think that's handled
[13:38:41] <fuzzie> i thought it existed, iesdp agrees but iesdp is not trustable
[13:39:09] <fuzzie> so looking..
[13:39:26] <fuzzie> ok, weidu doesn't think 0x80 is used either
[13:39:27] <Avenger> you mean the journal type combo box
[13:39:49] <Avenger> i don't know if all flags are used in dltcep
[13:39:52] <fuzzie> well, i don't have dltcep here, and it is difficult to work out from dltcep's source what it is doing :)
[13:40:07] <Avenger> i'm looking for it
[13:40:43] <CIA-29> GemRB: 03lynxlupodian * r46d910504680 10gemrb/gemrb/plugins/FXOpcodes/FXOpcodes.cpp:
[13:40:43] <CIA-29> GemRB: display the fx_disable_spellcasting/fx_disable_button warning / update the
[13:40:43] <CIA-29> GemRB: actionbar for any selectable
[13:40:45] <CIA-29> GemRB: 03lynxlupodian * rab87cd332ee2 10gemrb/gemrb/plugins/FXOpcodes/FXOpcodes.cpp: implemented the current hp altering variant of percentage fx_maximum_hp_modifier
[13:40:45] <Avenger> ok, i don't handle that flag
[13:40:58] <Avenger> i didn't know iesdp has any info on it
[13:41:16] <fuzzie> ok
[13:41:27] <fuzzie> this is 0x80 in the Flags field, right?
[13:42:12] <Avenger> yes
[13:42:13] <fuzzie> take a look at dream2.dlg for an example, if so
[13:42:23] <fuzzie> that's just the first one i found by random checks
[13:42:24] <Avenger> i don't handle that in dltcep
[13:42:34] <Avenger> good find
[13:42:39] <fuzzie> well, weidu just says 'FLAGS 128' for it, too
[13:42:48] <Avenger> dltcep would break that dialog
[13:43:55] <fuzzie> but if you look at that dialog, the intention is surely that the journal entry is added
[13:45:09] <fuzzie> so iesdp's "Remove Quest Journal entry" theory is surely wrong?
[13:45:18] <Avenger> hmm
[13:45:23] <Avenger> then what is that flag
[13:45:29] <fuzzie> i hoped you might know :P
[13:45:37] <Avenger> no i didn't even know about it :)
[13:45:54] <Lightkey> impossible~!
[13:46:20] <fuzzie> ok, let's check NI source
[13:47:02] <Avenger> well, it is not removal, that's sure
[13:47:04] <fuzzie> "Add journal note", it says
[13:47:34] <fuzzie> "Add unsolved quest" for 0x40, "Add journal note" for 0x80, "Add solved quest" for 0x100
[13:47:38] <Avenger> maybe it is the 'user notes' ?
[13:47:54] <Avenger> dltcep has the user notes as 0x40+0x100
[13:47:58] <Avenger> but that might be wrong
[13:48:14] <Avenger> i picked that only because i had no idea how it would be marked :)
[13:48:48] <fuzzie> lynxlynxlynx: ideas?
[13:48:49] <Avenger> i didn't find any user notes given by dialog
[13:49:02] <Avenger> easy, create a small dialog with that flag
[13:49:16] <fuzzie> i have no original engine here :P
[13:49:22] <Avenger> theni'll do
[13:49:43] <fuzzie> ok. i'd better get some real work done, then i'll come back and work on some more globalid stuff.
[13:50:04] <fuzzie> the travel regions are next, easy fix which fixes a lot of bugs
[13:50:39] <lynxlynxlynx> cool & no idea about the journal
[13:51:13] <lynxlynxlynx> ni's implementation looks plausible, but you know how looks are and what happens when you assume something
[13:58:44] <Avenger> well i set it to 145 (1+16+128) and it didn't have any effect
[14:00:41] <lynxlynxlynx> check the other chapters just in case
[14:06:26] <Avenger> if you use 17 then it goes to the journal anyway
[14:06:38] <Avenger> so 1+17 is enough
[14:06:44] <Avenger> err 1+16
[14:07:08] <Avenger> i didn't notice it first because a single line journal entry is crippled
[14:25:41] <Avenger> iesdp seems to be right, this one removes a journal entry
[14:26:23] <Avenger> if i use 145 (1+16+128) it removed a quest journal entry, doesn't seem to remove regular journal entries
[14:26:36] <Avenger> it appears to be doing what setquestdone does
[14:29:59] <Avenger> Ok, it removes the journal entry from done quests/quests too
[14:30:13] <Avenger> i wonder why it wouldn't remove a journal entry, though
[14:31:12] <lynxlynxlynx> why would you want to?
[14:36:21] <Avenger> meh, ok, it doesn't remove the entry. actually i see no difference between 17 and 145
[14:36:32] <Avenger> both changes the quest entry to a journal entry
[14:36:52] <Avenger> it doesn't remove the entry just changes the section if an entry is already there
[14:37:37] <Avenger> so, 0x80 is totally unused/unknown as of now
[14:37:53] <lynxlynxlynx> but it is used
[14:37:55] <Avenger> maybe i should ask IDA :)
[14:39:20] <Avenger> hmm, once i already found where it goes about the dialog options...
[14:39:25] <Avenger> i forgot where
[14:39:41] <Avenger> when i looked for colors
[14:41:20] --> AnthIste has joined #GemRb
[14:46:35] <-- AnthIste has left IRC (Quit: Ex-Chat)
[14:48:28] --> Bo_Thomsen has joined #GemRb
[15:08:23] <-- Lightkey has left IRC (Ping timeout: 276 seconds)
[15:09:52] <fuzzie> well, it is possible that it isn't really used and i just happened to randomly find the only dialog file with it accidentally set
[15:09:59] <fuzzie> was the second file i checked..
[15:12:45] <lynxlynxlynx> cool, found some info on how simulacri are level drained
[15:14:28] <fuzzie> you'll do the spellbook copying?
[15:14:47] <Avenger> remind me to not debug in fullscreen :(
[15:15:32] <lynxlynxlynx> i was doing it, but started to do other stuff out of frustration
[15:16:31] <fuzzie> ok, maybe a better question is 'would it help if i made a patch?'
[15:17:46] <Bo_Thomsen> A small question: Is it possible to run BG:TotSC in windowed mode using gemrb?
[15:17:51] <lynxlynxlynx> do you think that'd be faster than me trying to ask specific questions?
[15:18:03] <lynxlynxlynx> Bo_Thomsen: sure
[15:18:33] <Bo_Thomsen> Do I need any extra tools or would a vanilla install through wine work?
[15:18:38] <fuzzie> but you should also be able to do it in the original..
[15:18:57] <lynxlynxlynx> that is fine
[15:19:18] <lynxlynxlynx> turn Fullscreen to off in baldur.ini
[15:19:52] <Bo_Thomsen> And TotSC enables 800x600, right?
[15:21:47] <lynxlynxlynx> no idea
[15:21:52] <fuzzie> i don't think so, but you can then install the Widescreen Mod
[15:22:20] <Bo_Thomsen> Alright, I will try to see if I can get vanilla to work first before experimenting with the mod though
[15:22:30] <Bo_Thomsen> Thank you for the help
[15:22:36] <fuzzie> which will let you run in 800x600
[15:22:39] <Avenger> we wouldn't allow other resolutions than the original allowed
[15:23:18] <Avenger> i mean, you can try to configure/hack gemrb into a higher res, but if the original graphic resources didn't support it it will be ugly
[15:23:25] <fuzzie> just don't start playing games in the original engine and then install the widescreen mod :)
[15:23:26] <Bo_Thomsen> I just read various places that 800x600 was allowed in the expansion(But I never played it before so I had no way of knowing if it as true)
[15:23:42] <Avenger> let me see
[15:23:50] <lynxlynxlynx> run bgconfig.exe or something like that
[15:24:03] <lynxlynxlynx> if it has any resolution options settable, they are settable through that
[15:24:25] <Bo_Thomsen> Can't find any option there so it is probably just a rumour..
[15:24:28] <fuzzie> well, you can't run non-expansion bg1 in 800x600 at all
[15:24:40] <fuzzie> so they probably meant, you can run bg1 in 800x600 using the Widescreen Mod, but only if you have the expansion.
[15:24:42] <Avenger> hmm, i don't see any resolution settings in the original
[15:24:57] <Avenger> it has only guiw.chu, i guess?
[15:25:05] <fuzzie> yes
[15:25:31] <Avenger> well, you will need some .chu hackery to make it work
[15:25:35] <fuzzie> bg1/pst only have 640x480 CHUs
[15:25:38] --> Lightkey has joined #GemRb
[15:25:42] <Avenger> all .chu are set at 640*480
[15:25:44] <fuzzie> but the Widescreen Mod works fine on those, in 'small' mode
[15:26:17] <Avenger> still, i dunno if the wsm for gemrb stuff handles bg1
[15:26:22] <fuzzie> it does
[15:26:37] <fuzzie> it didn't previously, but i bothered lynx into fixing it, and it's in the released version
[15:26:49] <fuzzie> but you can just install it for the original engine, and it will also be fine for gemrb
[15:27:14] <fuzzie> it's just important to install it before people start making original engine savegames..
[15:38:42] <-- Bo_Thomsen has left IRC (Quit: Leaving.)
[15:46:19] <Avenger> hmm ida is very crashy in debug mode
[15:47:00] <fuzzie> when using the debugger?
[15:48:06] <Avenger> yes
[15:48:11] <fuzzie> with some DirectX app?
[15:48:19] <Avenger> tob, in windowed mode
[15:48:21] <fuzzie> oh, i guess you're trying IE :P
[15:48:36] <fuzzie> then yes, that is known to be buggy if you run ida and some DirectX app on the same machine
[15:53:37] <Avenger> dialogs use lots of messages, meh, it is hard to follow, especially if all my marks are lost due to a crash
[15:53:46] <Avenger> gotta save more frequently
[16:06:50] <CIA-29> GemRB: 03lynxlupodian * ra0090dc208e3 10gemrb/gemrb/plugins/GUIScript/GUIScript.cpp: made GemRB_ClearActions also accept global ids
[16:06:53] <CIA-29> GemRB: 03lynxlupodian * r5b38902e5f94 10gemrb/gemrb/ (2 files in 2 dirs): added GemRB_GetSelectedActors, so all the selectees can be stopped from the gui
[16:06:55] <CIA-29> GemRB: 03lynxlupodian * rc58eaa4d4c1f 10gemrb/gemrb/plugins/GUIScript/GUIScript.cpp: made GemRB_ClearActions also stop combat
[16:10:25] <Avenger> hah, finally i see some outlines of the dialog engine :)
[16:27:45] <-- barra_library has left IRC (Quit: Verlassend)
[16:43:23] --> pupnik has joined #GemRb
[16:43:27] <pupnik> http://i.imgur.com/VHMl7.png mushroom sun :)
[16:44:37] <Avenger> fuzzie: i see that bit value 0x20 has some effect in dialogs. (Actually it is the first bit i see in the code to be used)
[16:44:54] <Avenger> i hope i'll find 0x80 too :)
[16:45:32] <Avenger> pupnik what am i looking at?
[16:46:40] <pupnik> i made a visualization plugin (distortion map) and a friend drew an fft-oscilloscope mapped radially, then mirrored in x plane
[16:46:43] <pupnik> input from microphone
[16:46:55] <-- SiENcE has left IRC (Quit: @all: cya)
[16:48:58] <pupnik> is very fun. mkdir oscpix && cd oscpix && wget http://ariel.w.tkb.pl/osc/osc30 && chmod uog+x osc30 && wget http://ariel.w.tkb.pl/osc/pix/the_sun.c && cp the_sun.c osc-pix.c && ./osc30
[16:49:14] <pupnik> then hit f3 to compile osc-pix.c into a working plugin
[16:52:42] <-- lubos has left IRC (Quit: Leaving.)
[16:57:36] <Avenger> haha, tobex is cool, it has an almost correct structure list of internal dialog structures :) the source is marked as 'fixme' at a point though :) i figured out what confused the author
[16:58:57] <Avenger> if it wasn't marked, i wouldn't look for the mismatch
[17:00:11] <edheldil> it's wonderful how you can navigate IE asm so quickly. it always takes me tremendous amount of time to understand short simple procedures ;-/
[17:00:48] <Avenger> fuzzie: dialogs seem to use the same action queueing mechanism as cutscenes. Does that make sense?
[17:01:34] <Avenger> hehe ed, i looked at the code since 2007. So i had a starting point. I started by marking those parts
[17:02:41] <Avenger> i work on this with IDA since august, and all the marks stay in the database. It is really productive
[17:02:59] <Avenger> i wouldn't have noticed that the dialog use the cutscene code if that message wasn't already marked
[17:04:15] <Avenger> this may help a lot with proper queueing of the actions
[17:05:21] <edheldil> the other day I was toying with the idea of sharing IDA's db through git - I haven't tested it though, so I am not sure whether it would work.
[17:06:53] <wjp> can you export things like names in a text format from IDA?
[17:06:59] <wjp> (and import them again)
[17:07:15] <wjp> (and comments, ...)
[17:07:22] <wjp> would be an interesting way to share annotations
[17:08:25] <wjp> (through git, I mean)
[17:14:39] <fuzzie> you can export a script i think
[17:14:43] <fuzzie> which recreates your database
[17:15:10] <fuzzie> Avenger: yes, the same as cutscenes would make sense
[17:15:14] <edheldil> I think so. At least structs are possible and I think more - although a message box warns it's not whole db, which is annoying
[17:15:20] <edheldil> bye, later
[17:23:10] <Avenger> finally, i see the 0x80 bit being used
[17:23:34] <fuzzie> :)
[17:23:51] <Avenger> weird, it seems to be a section selector
[17:23:58] <fuzzie> so 0x20 and 0x80, good thing someone checked?
[17:24:06] <Avenger> aaahhh
[17:24:09] <Avenger> the default section is 4
[17:24:14] <Avenger> and 0x80 also selects 4
[17:24:16] <Avenger> LOL
[17:24:41] <fuzzie> but it doesn't override 0x40/0x100?
[17:24:54] <Avenger> http://pastebin.com/uBaKaGyS
[17:25:27] <fuzzie> ok, so it overrides 0x100
[17:25:50] <Avenger> but 4 is the default, so if you omit all of these bits, it will stay 4
[17:26:16] <fuzzie> very strange
[17:26:38] <Avenger> well, i guess it wasn't always 4 as default
[17:26:45] <Avenger> that's the only explanation
[17:27:09] <fuzzie> and yet, bg1 seems to not use sections at all
[17:27:23] <fuzzie> oh well, it is useful to know
[17:27:28] <fuzzie> any idea if 0x20 is meaningful?
[17:27:35] <Avenger> oh, and when i found it, i see: AddJournalEntry
[17:27:38] <Avenger> grrr
[17:27:45] <Avenger> i should have looked for that function first
[17:27:56] <Avenger> i would have found it much faster that way
[17:28:16] <Avenger> 0x20 has effect, but i don't understand it
[17:28:34] <Avenger> it doubles the response
[17:28:41] <Avenger> i don't quite see how is that useful
[17:28:58] <Avenger> probably it should be disabled the other way
[17:29:47] <Avenger> NI has no note about it?
[17:30:01] <Avenger> probably ask it on the forums
[17:30:03] <fuzzie> no
[17:30:19] <Avenger> taimon/ascension may have something
[17:30:38] <fuzzie> there are quite a few uses of 0x80
[17:31:12] <fuzzie> but none together with 0x100
[17:31:29] <Avenger> they are simple journal entries
[17:31:42] <Avenger> section 4 :)
[17:31:55] <fuzzie> well, gemrb's behaviour would differ if 0x100 was set too
[17:32:22] <Avenger> because it allows user entries?
[17:32:46] <fuzzie> because it would end up in section 2, right?
[17:33:08] <fuzzie> but the highest flags in SoA's dlg files is 0x118
[17:34:11] <fuzzie> there are 23 0x91 flags, 20 0x96 flags, 9 0x98, 8 0x81? but your guess that it is old sounds right
[17:34:58] <Avenger> 0x100 is section 2
[17:35:16] <Avenger> 0x40 is section 1
[17:35:23] <fuzzie> but your disasm shows that if you set 0x80 and 0x100, then you get section 4
[17:35:25] <Avenger> and default (or 0x80) is section 4
[17:35:31] <Avenger> no
[17:35:43] <Avenger> ooh ok, yes
[17:35:58] <fuzzie> but i see no uses of that, so irrelevant, i hope
[17:36:35] <Avenger> i thought your problem is that if 0x40 and 0x100 both set, then i go for section 3 (user entries) which isn't available in the original
[17:36:47] <Avenger> err that is section 0
[17:37:55] <Avenger> do you want to add the GF_HAS_JOURNAL_SECTIONS flag?
[17:38:12] <Avenger> i finished poking at the IE today, so i could :)
[17:38:21] <lynxlynxlynx> just do it then :)
[17:38:25] <fuzzie> go ahead and do it :)
[17:38:34] <Avenger> i'm happy i could find this relatively fast
[17:38:38] <-- Avenger has left IRC (Quit: ChatZilla 0.9.86 [Firefox 3.6.12/20101026210630])
[17:38:47] <lynxlynxlynx> :)
[17:41:25] <fuzzie> for future reference, highest dialog flag in bg1 is 0x19, same in iwd, same in pst, same in iwd2
[17:41:51] <fuzzie> well, i guess not so much 'for future reference' as relevant right now, come to think of it
[17:45:07] <CIA-29> GemRB: 03lynxlupodian * r4aff90e9a4bf 10gemrb/gemrb/plugins/FXOpcodes/FXOpcodes.cpp: level drain the simulacrum
[17:48:51] --> Maighstir has joined #GemRb
[17:55:48] --> Avenger has joined #GemRb
[17:55:48] --- ChanServ gives channel operator status to Avenger
[17:56:17] <Avenger> hmm, my change will break the journal, i think the script uses section 4
[17:56:25] <CIA-29> GemRB: 03avenger_teambg * r22b29a427b78 10gemrb/gemrb/ (4 files in 3 dirs): implemented optional no journal sections (sections crash all but bg2 savegames)
[17:56:29] <CIA-29> GemRB: 03avenger_teambg * r19153fbf7465 10gemrb/gemrb/plugins/FXOpcodes/FXOpcodes.cpp: Merge branch 'master' of ssh://gemrb.git.sourceforge.net/gitroot/gemrb/gemrb
[17:56:51] <fuzzie> Avenger: the bg2 one?
[17:57:02] <Avenger> no, all else
[17:57:05] <fuzzie> no, they should be fine
[17:57:15] <fuzzie> the python functions just ignore the section if one isn't supplied
[17:57:19] <Avenger> but how, now i will use section 0, instead of 4
[17:57:35] <Avenger> hmm, if there is no section given, they will return any?
[17:57:38] <fuzzie> yes
[17:57:41] <Avenger> cool
[17:58:01] <Avenger> that explains why i still seen original game journal entries
[17:58:13] <fuzzie> mhm
[17:58:14] <fuzzie> it confused me
[17:58:39] <fuzzie> apparently some crazy 'fuzzie' person added that back in jan 2009, but i'm sure i don't remember
[17:59:08] <Avenger> hmm, memories are fuzzy too? :P
[17:59:09] <fuzzie> probably it was wrong for me to do that, since it just hid the section bug :(
[17:59:51] <Avenger> yep, it hid the bug a bit, but it is now good to have. Maybe we even need an automatic conversion
[18:00:00] <Avenger> what happens if you load a bg1 game into bg2
[18:00:11] <Avenger> should the journal entries go away, or get converted?
[18:00:24] <Avenger> hmm, maybe go away
[18:00:27] <fuzzie> go away, since the chapters overlap
[18:00:39] <Avenger> we need to add that too
[18:00:58] <fuzzie> well, you know best how the import works, i didn't look at what you did yet
[18:01:04] <Avenger> pft, ok
[18:01:09] <fuzzie> except to fix the set expansion function
[18:01:16] <Avenger> trying to figure out how can i remove all journal entries
[18:02:05] <Avenger> i don't want to hardcode this into the core
[18:02:11] <Avenger> so meh
[18:02:22] <fuzzie> just add a guiscript function which deletes the entry corresponding to a strref
[18:02:37] <Avenger> yes, actually, the user entries are deletable
[18:02:43] <Avenger> we don't have that functionality yet?
[18:02:52] <fuzzie> i don't see any guiscript function which does it..
[18:02:57] <fuzzie> the core has a function for it though
[18:03:07] <Avenger> yep, maybe the user entry is not editable at all
[18:03:24] <Avenger> the tlk override was not around when we last worked on that
[18:03:29] <Avenger> it might still be buggy too
[18:03:35] <fuzzie> yes, you can't add entries from the guiscript either
[18:04:19] <lynxlynxlynx> neither can you change the bio
[18:06:03] --> Bo_Thomsen has joined #GemRb
[18:08:36] <fuzzie> did you look at trying to apply the BashDoor patch, lynx?
[18:08:40] <fuzzie> no rush, just wondering
[18:08:59] <lynxlynxlynx> no, i'm still in the summons area
[18:09:33] <lynxlynxlynx> should be queued soon
[18:09:51] <lynxlynxlynx> i'm looking at the spellbook again ><
[18:10:20] <fuzzie> ok
[18:10:24] <fuzzie> still having problems?
[18:11:00] <lynxlynxlynx> yeah, i'll upload the function
[18:11:29] <lynxlynxlynx> http://pastebin.ca/1978911
[18:12:16] <lynxlynxlynx> now it looks easier to just copy the whole spells and then redo the known/memorised vectors, but i haven't tried it
[18:12:54] <fuzzie> i wouldn't bother calling AddSpellMemorization
[18:13:06] --> micke_ has joined #GemRb
[18:13:06] <fuzzie> just manually push things into the array
[18:13:39] <fuzzie> otherwise it looks fine, except obviously you don't push the tmp_known/tmp_mem variables into the vector
[18:13:58] <fuzzie> oh, right, you don't call that, commented. stupid.
[18:14:54] <lynxlynxlynx> yeah, that couldn't be tested yet
[18:15:15] <fuzzie> let me try changing it
[18:16:47] <lynxlynxlynx> wait a sec
[18:17:02] <Avenger> huh, i found 10+ places where a beginner modder could crash the guiscript engine :)
[18:17:04] <Avenger> fixed some
[18:17:32] <lynxlynxlynx> all the functions that return NULL can
[18:17:53] <micke_> Hi I'm having a spot of trouble running gemrb from source. I've just entered the game and I can't disarm traps or open locks (sneaking and finding traps work fine.). I get "Nested event handlers are not supported!" when clicking the "Thieving" button. Any thoughts? (I downloaded and compiled before the weekend and thieving worked fine then.)
[18:18:31] <lynxlynxlynx> are you sure you're close enough?
[18:18:36] <CIA-29> GemRB: 03avenger_teambg * r686d19a6c7ce 10gemrb/gemrb/plugins/GUIScript/GUIScript.cpp:
[18:18:36] <CIA-29> GemRB: added SetJournalEntry
[18:18:36] <CIA-29> GemRB: fixed some potential crashes when the game isn't loaded
[18:18:45] <Avenger> the nested event handler itself shouldn't affect it
[18:18:57] <fuzzie> lynxlynxlynx: http://fuzzie.org/nfs/gemrb/spellbook.txt ?
[18:19:06] <Avenger> hmm, on the other hand, if it just went wrong recently...
[18:19:16] <lynxlynxlynx> you don't like the wikipedia joke? :(
[18:19:35] <fuzzie> sorry, i rewrote
[18:19:51] <fuzzie> haven't tried compiling it, just typed into vim
[18:20:10] <lynxlynxlynx> it's fine
[18:20:23] <Avenger> micke which game is it? bg2?
[18:20:35] <fuzzie> the most important thing is the '&' really :) i guess you got the rest
[18:20:40] <micke_> yes!
[18:20:45] <micke_> with tob
[18:21:05] <fuzzie> Avenger: you have an idea what it is?
[18:21:56] <Avenger> no
[18:22:01] <fuzzie> oh
[18:22:02] <Avenger> and i just broke the engine?
[18:22:22] <fuzzie> you did?
[18:22:35] <Avenger> what did i change in GetGameString
[18:22:38] <Avenger> O_o
[18:23:06] <Avenger> oh
[18:23:08] <Avenger> heh
[18:23:20] <fuzzie> silly
[18:23:23] <Avenger> looks like it is called without a game
[18:23:44] <fuzzie> yes
[18:23:45] <lynxlynxlynx> that & somehow beats the const? haven't seen it used like that before
[18:24:29] <fuzzie> lynxlynxlynx: that & means you don't make a copy of the spellbook and make everything explode, you probably eed 'const Spellbook &src'
[18:24:32] <fuzzie> need
[18:24:48] <lynxlynxlynx> ah
[18:24:49] <micke_> Is there anything you would like me to try?
[18:25:07] <fuzzie> Avenger: i guess these GameStrings shouldn't be in the game?
[18:25:10] <lynxlynxlynx> i was trying to convert it to a pointer earlier, but the const was in the way and i didn't think of specifying it
[18:25:11] <CIA-29> GemRB: 03avenger_teambg * rf3b1277d79d9 10gemrb/gemrb/plugins/GUIScript/GUIScript.cpp: fixed a borken line
[18:25:35] <fuzzie> lynxlynxlynx: ok. this is equivalent to the pointer.
[18:25:43] <lynxlynxlynx> micke_: just play and checkout the wiki todo for the bugs
[18:25:58] <Avenger> micke_ i can disarm a container trap with Imoen
[18:26:02] <micke_> ok, will do
[18:26:02] <Avenger> in the starting area
[18:26:07] <fuzzie> i can't think why the thief button would be a problem
[18:26:09] <micke_> oh
[18:26:12] <micke_> hmm
[18:26:25] <lynxlynxlynx> const Spellbook &wikipedia = source->spellbook; vs const Spellbook *wikipedia = &(source->spellbook); <-- is this the same?
[18:26:26] <micke_> guess theres something wrong on my side then
[18:26:28] <fuzzie> maybe you have armour on and it isn't being grayed out?
[18:26:29] <Avenger> so can you give some more specific problem?
[18:26:39] <Avenger> which trap is it you cannot work on
[18:26:43] <fuzzie> lynxlynxlynx: effectively, yes
[18:26:51] <fuzzie> lynxlynxlynx: just the prior one lets you keep doing 'wikipedia.'
[18:26:53] <micke_> just started bg2
[18:26:55] <Avenger> using ctrl-m on the trap can print its difficulty
[18:27:07] <fuzzie> micke_: do you get the icon or not?
[18:27:11] <fuzzie> i mean, the changed mouse cursor
[18:27:19] <Avenger> ctrl-x gives the area and coordinates
[18:27:21] <lynxlynxlynx> fuzzie: is there any special name for this kind of referencing?
[18:27:35] <fuzzie> lynxlynxlynx: it is a 'reference' :)
[18:27:38] <micke_> no the mouse cursor dosen't change
[18:27:41] <fuzzie> lynxlynxlynx: http://en.wikipedia.org/wiki/Reference_%28C%2B%2B%29
[18:28:08] <lynxlynxlynx> ok :)
[18:28:21] <Avenger> then you don't see the trap?
[18:28:35] <fuzzie> Avenger: when you click the button
[18:28:54] <fuzzie> so, this is before the trap is relevant
[18:29:40] <micke_> I can see the trap in red, find traps works, but when I click "thieving" I get "Nested event handlers are not supported!" and no the mouse cursor doesn't change
[18:30:14] <micke_> Also I can't open containers
[18:30:22] <Avenger> huh
[18:30:33] <Avenger> then you must have some old files?
[18:30:46] <micke_> I can speak with the golem though
[18:31:02] <fuzzie> did you do 'make install'?
[18:31:11] <Avenger> i think that's the reason, try this: delete all .py scripts from your installed dir, then build again
[18:31:16] <fuzzie> if so, what Avenger said
[18:31:53] <Avenger> that screwed my game a lot of times :)
[18:31:55] <lynxlynxlynx> any .pyc too, if you have them
[18:31:57] <micke_> Ok I'll give it try and tell you how it goes
[18:32:24] <Avenger> lynx: i see something odd though: i get 'trap not disarmed' though the trap vanishes (and doesn't fire)
[18:33:12] <lynxlynxlynx> haven't seen that
[18:33:35] <fuzzie> which trap is this, Avenger?
[18:33:42] <Avenger> ellesime's room
[18:33:46] <fuzzie> the infopoint ones need rewriting
[18:33:59] <Avenger> region traps, yep
[18:33:59] <fuzzie> but the container ones should be fine
[18:34:30] <fuzzie> this is Yet Another Stupid Trigger Bug
[18:34:37] <fuzzie> but i won't get to it for some days
[18:34:51] <micke_> btw I'm ubuntu 10.10 using cmake
[18:34:58] <micke_> compiling now
[18:35:08] <Avenger> that should fix it
[18:35:21] <fuzzie> where is the installed python dir by default?
[18:35:56] <fuzzie> /usr/local/share/gemrb/GUIScripts or something?
[18:36:31] <lynxlynxlynx> yes
[18:37:02] <Avenger> fuzzie: TryDisarm is common code, so why is it broken for regions but not for containers
[18:37:23] <fuzzie> Avenger: because the triggers suck
[18:37:37] <fuzzie> so the script doesn't necessarily actually fire the trap
[18:37:59] <Avenger> ahh so the trap should have fired
[18:38:08] <fuzzie> i already added one hack, if that hack broke then it seems silly to add more hacks for just a short time
[18:39:20] <Avenger> if i recall correctly, not all failed disarms should fire the trap
[18:39:42] <Avenger> but i don't really remember this
[18:39:56] <fuzzie> yes
[18:40:06] <fuzzie> we removed that code for now, so all failed disarms fire the trap
[18:40:17] <Avenger> micke_ does it work now?
[18:40:28] <fuzzie> until someone works out if there is really some case where they don't
[18:41:53] <CIA-29> GemRB: 03lynxlupodian * r3d4559b44c37 10gemrb/gemrb/core/ (Scriptable/Actor.cpp Spellbook.cpp Spellbook.h): copy the spellbooks for simulacrum/projected image too
[18:42:47] <fuzzie> cool
[18:43:37] <fuzzie> so much more works :)
[18:43:47] <micke_> Avenger: it didn't work, I'll redo everything from scratch too make sure it's not on my side. I'll check back in a moment or two
[18:44:04] <Avenger> i always ignored this simulacrum/level drain, because i considered it too complex :)
[18:44:51] <lynxlynxlynx> level drain is still incomplete
[18:45:07] <lynxlynxlynx> the effect probably includes fx_drain_spells
[18:45:19] <Avenger> what effect
[18:45:45] <Avenger> ahh you want to know how leveldrain takes away spells?
[18:46:08] <lynxlynxlynx> yes, but not today
[18:46:39] <lynxlynxlynx> we have three draining effects already and my bet is the main one just duplicates parts of the others
[18:48:17] <Avenger> how do you know there is a level drain on simulacrums?
[18:48:42] <lynxlynxlynx> because people exploit this
[18:48:52] <lynxlynxlynx> they cast restoration spells to buff them
[18:49:15] <lynxlynxlynx> the spell description clearly states that the simulacrum is a lesser copy
[18:49:28] <Avenger> oh, actually i documented this too
[18:49:30] <Avenger> i just forgot
[18:49:50] <CIA-29> GemRB: 03lynxlupodian * r53778f462b7a 10gemrb/gemrb/core/Spellbook.h: Spellbook.h: renamed the single ieIWD2SPellType to match the rest
[18:49:55] --> barraAway has joined #GemRb
[18:50:05] <lynxlynxlynx> where?
[18:50:12] <Avenger> in the opcode listings
[18:51:35] <Avenger> ahh, and there it is target's effective level/2 is the parameter for level drain
[18:52:26] <Avenger> you are cool :)
[18:52:41] <Avenger> copy->GetXPLevel(1)/2 is just that
[18:52:45] <Avenger> hehe, really nice
[18:53:03] <fuzzie> this is the stupid bug where it only looks at the first level?
[18:53:19] <Avenger> no, here it is all cool in the IE
[18:53:25] <Avenger> mirror image is what fucked up
[18:53:27] <fuzzie> ah
[18:53:41] <Avenger> they could have used the same function call in mirror image
[18:54:20] <Avenger> i consider it a bug i don't want to copy
[18:54:54] <Avenger> ok, actually our code is better than effective level
[18:54:59] <Avenger> it asks for mage level
[18:55:03] <lynxlynxlynx> yep
[18:55:04] <Avenger> that's better
[18:56:01] <micke_> all right, everythings fine now :)
[18:56:18] <Avenger> heh, really?
[18:56:23] <Avenger> i wonder what was wrong :)
[18:56:46] <Avenger> i was out of ideas
[18:57:07] <micke_> :)
[18:57:42] <Avenger> make sure you download stuff regularly, we just added something while you compiled :)
[19:00:13] <micke_> nice! I'm going to check out the game and then I'll head to the wiki todo and take a look at that aswell
[19:00:24] <lynxlynxlynx> fuzzie: that "return;" that bothered you when bashing; i don't know why it came in the diff, but it effectively means the door would also be opened on a successful bash
[19:00:35] <Avenger> you say, you might even contribute code?
[19:00:50] <lynxlynxlynx> i don't know what the original does though
[19:00:53] <fuzzie> lynxlynxlynx: it doesn't, because you wipe the queue
[19:01:24] <fuzzie> unless i am really misremembering the patch
[19:01:45] <Avenger> hah, today we filled a whole page on CIA :)
[19:02:22] <lynxlynxlynx> the queue wiping has no effect, since the actions are handcrafted
[19:03:15] <fuzzie> if you AddAction 'BashDoor' and then do ClearActions(), you should lose that action
[19:03:34] <lynxlynxlynx> the behaviour sounds reasonable, what do you guys think we should do? epic break-in (door also opens) vs. just destroying the lock
[19:03:44] <lynxlynxlynx> yes, but the calls are in the opposite order
[19:03:46] <fuzzie> i mean, i don't mind how it's done
[19:04:31] <fuzzie> but the copy i have here does ClearActions, then BashDoor, then ClearActions
[19:05:30] <lynxlynxlynx> then nidspecial9
[19:05:34] <fuzzie> yes
[19:05:40] <fuzzie> so you end up with a queue with NIDSpecial9 in it
[19:06:00] <lynxlynxlynx> ahhh
[19:06:05] <lynxlynxlynx> i see what you mean
[19:06:44] <lynxlynxlynx> it would have to be an instant to work like i described
[19:06:45] <fuzzie> after having thought about it, i think probably door also opens is bad
[19:07:00] <fuzzie> because then you have enemies on the other side jumping you
[19:07:26] <lynxlynxlynx> they're not deaf :P
[19:07:32] <fuzzie> but on the other hand maybe that is bound to happen if you bash a door :)
[19:08:05] <fuzzie> i should get rid of that horrible TargetDoor thing entirely, i suppose
[19:10:01] <Avenger> well, now we got global ids, so targetdoor is not needed :) maybe targetobject with a global id
[19:10:15] <fuzzie> don't even need that
[19:10:24] <fuzzie> we can just stick it in the action, same as we do for actors
[19:11:03] <Avenger> uhm, yes
[19:11:41] <Avenger> that would be much better if the action target is done in a standard way
[19:12:16] <fuzzie> well, for these purposes i thought we could just use int0Parameter like the original
[19:12:26] <fuzzie> but, GenerateActionDirect is fine too
[19:12:29] <fuzzie> you have a preference?
[19:14:42] <lynxlynxlynx> ups
[19:14:52] <lynxlynxlynx> bg2 is not completable again
[19:15:01] <fuzzie> what broke?
[19:15:02] <lynxlynxlynx> you can't get the key out of the chest
[19:15:16] <lynxlynxlynx> the item is undroppable
[19:15:36] <lynxlynxlynx> too aggresive movable changes probably
[19:15:41] <fuzzie> yes
[19:16:01] <fuzzie> avenger always masks with ~IE_INV_ITEM_UNDROPPABLE
[19:16:18] <fuzzie> but i thought that was bg1-specific
[19:17:12] <CIA-29> GemRB: 03lynxlupodian * rffa4717d5779 10gemrb/gemrb/core/Scriptable/Actor.cpp: avoid a crash when determining if an item is viable for backstabbing
[19:17:37] <fuzzie> it is, so i guess that isn't it
[19:17:46] <fuzzie> although i must remember to keep that on the list
[19:18:37] <fuzzie> Avenger: what is CheckRemoveItem meant to do?
[19:18:52] <lynxlynxlynx> i should check in a gemrb save, this one may be original
[19:18:53] <fuzzie> oh, i see, never mind
[19:20:56] <fuzzie> i guess the inability to get the key out of the chest is deliberate, Avenger wrote "needed for unmovable items in containers"?
[19:23:51] <lynxlynxlynx> huh
[19:24:03] <lynxlynxlynx> bashing seems to work fine apart from the range issue
[19:24:20] <CIA-29> GemRB: 03lynxlupodian * rebd71b90ec7f 10gemrb/gemrb/ (core/GUI/GameControl.cpp override/shared/gemact.ids): do the bashing via the BashDoor action
[19:24:36] <lynxlynxlynx> chests can be confusing, since some have a lockdifficulty set, but are not locked, so the debug dump can deceive
[19:25:41] <fuzzie> it doesn't display locked status?
[19:28:09] <lynxlynxlynx> just trapped
[19:30:39] <fuzzie> well, add it, i guess? like printf( "Door Locked: %s\n", YESNO(Flags&DOOR_LOCKED)); except CONT_LOCKED instead
[19:30:53] <fuzzie> save the poor minds of future generations from being confused!
[19:30:59] <lynxlynxlynx> yeah, sure
[19:31:04] <lynxlynxlynx> playing with the range currently
[19:31:26] <fuzzie> range is problematic for containers too?
[19:32:10] <lynxlynxlynx> MAX_OPERATING_DISTANCE is close enough
[19:32:28] <lynxlynxlynx> but we do drop the bashing a lot if you're not close enough
[19:32:41] <fuzzie> oh
[19:32:47] <fuzzie> well, i had a patch for that, but apparently it didn't work.
[19:32:53] <lynxlynxlynx> and that's before hitting any blocked squares
[19:33:22] <fuzzie> http://fuzzie.org/nfs/gemrb/dist_door.txt
[19:37:17] <lynxlynxlynx> no change
[19:38:03] <lynxlynxlynx> the moving nearer worked before too
[19:38:18] <lynxlynxlynx> time for gdb
[19:39:03] <fuzzie> oh
[19:39:07] <fuzzie> oops
[19:39:11] <fuzzie> right, you're using BashDoor now?
[19:39:24] <lynxlynxlynx> SquaredPersonalDistance(pos, Sender) and no squared operating distance
[19:39:36] <lynxlynxlynx> yes, attack core is irrelevant now
[19:39:51] <fuzzie> ot thinking
[19:39:52] <fuzzie> not thinking
[19:41:09] <lynxlynxlynx> yeah, that should be it
[19:41:15] <fuzzie> :)
[19:41:31] <fuzzie> so, we can just remove this stuff from AttackCore now?
[19:41:36] <fuzzie> that would be better
[19:42:09] <lynxlynxlynx> yupyup
[19:43:53] * fuzzie prods Avenger
[19:50:04] <CIA-29> GemRB: 03lynxlupodian * r13ed29cf0fbc 10gemrb/gemrb/core/GameScript/Actions.cpp: GameScript::BashDoor: fixed the range check
[19:50:28] <CIA-29> GemRB: 03lynxlupodian * r17e9143ab3ef 10gemrb/gemrb/core/Scriptable/ActorBlock.cpp: Container::DebugDump: print also if the container is locked
[19:50:57] <lynxlynxlynx> micke_: now the containers are better victims
[19:55:09] <Avenger> fuzzie ?
[19:55:33] <Avenger> oh sh.t
[19:55:37] <lynxlynxlynx> that undroppable container item change, we don't get it
[19:55:47] <lynxlynxlynx> and it breaks the chateau
[19:56:12] <Avenger> are there no drop items in containers???
[19:56:28] <lynxlynxlynx> yes, the portal key
[19:56:33] <Avenger> huh
[19:56:49] <Avenger> so you are supposed to get the key from the container, but never drop it again?
[19:56:55] <fuzzie> yes
[19:56:59] <Avenger> LOL
[19:57:01] <Avenger> ok
[19:57:01] <fuzzie> it is removed when you leave the dungeon
[19:57:01] <lynxlynxlynx> a custcene deletes it
[19:57:10] <lynxlynxlynx> err
[19:57:18] <Avenger> comment out the Change=true
[19:57:27] <Avenger> or the CalculateWeight
[19:57:31] <Avenger> any of the two
[19:57:57] <Avenger> i shouldn't have changed that
[19:58:08] <fuzzie> well, you commented it neatly with an explanation :)
[19:58:34] <Avenger> because i wasn't sure, i knew it was not added on purpose,
[19:58:45] <Avenger> i mean, i just removed some comment, that now goes back
[20:01:22] <lynxlynxlynx> this wouldn't affect savegames?
[20:01:40] <lynxlynxlynx> nevermind, i forgot to save
[20:27:14] <Bo_Thomsen> Are there someone who has some time for helping me with getting TotSC to run with the widescreen mod(It is installed just the gemrb setting that needs poking)
[20:28:06] <lynxlynxlynx> which mode did you choose in the mod?
[20:28:13] <Bo_Thomsen> 800x600
[20:28:32] <lynxlynxlynx> no, at the start it asks you about gemrb
[20:28:44] <Bo_Thomsen> I choose gemrb
[20:28:51] <lynxlynxlynx> ok
[20:29:21] <lynxlynxlynx> then all you should do is set the resolution in the gemrb config
[20:29:52] <Bo_Thomsen> What about windowed mode?
[20:30:35] <lynxlynxlynx> it runs fullscreen?
[20:30:43] <lynxlynxlynx> set it off in baldur.ini
[20:31:24] <Bo_Thomsen> Which option is it?
[20:31:55] <fuzzie> 'Full Screen=1' under [Program Options] i think?
[20:32:13] <fuzzie> yes
[20:33:31] <Bo_Thomsen> Hmm.. I get "[ResourceManager]: Searching for gemrb.ini...[ERROR]"
[20:34:15] <fuzzie> did you set 'GameType=bg1'?
[20:34:50] <Bo_Thomsen> Ahhh! Thank you!
[20:48:19] <CIA-29> GemRB: 03lynxlupodian * r58465422430c 10gemrb/gemrb/core/Inventory.cpp: reverted part of 65e70e91e6 so the bg2 portal key can be picked up again
[20:52:16] <Bo_Thomsen> Nothing happens with savegames if I change the resolution in the widescreen settings?
[20:52:36] <fuzzie> not in gemrb
[21:14:10] <Bo_Thomsen> Hmm... Not I have trouble with the lower and right side bar not showing up
[21:35:21] <Bo_Thomsen> Even going back to 640x480 doesn't solve it
[21:37:22] <lynxlynxlynx> hm
[21:37:41] <lynxlynxlynx> any big red errors on the console?
[21:38:30] <Bo_Thomsen> There are some
[21:39:07] <Bo_Thomsen> "[ResourceManager]: Searching for GUILS04... Tried GUILS04.png GUILS04.bmp GUILS04.mos [ERROR] This one might be the responsible one
[21:40:04] <Bo_Thomsen> [ResourceManager]: Searching for spawngrp.2da...[ERROR]
[21:40:05] <Bo_Thomsen> [ResourceManager]: Searching for tracking.2da...[ERROR]
[21:40:11] <Bo_Thomsen> [TLKImporter]: Not a valid TOT file.
[21:40:11] <Bo_Thomsen> [TlkImporter]: Cannot open tlk override!
[21:40:16] <Bo_Thomsen> Are the only other ones
[21:40:23] <lynxlynxlynx> the others are irrelevant
[21:40:44] <lynxlynxlynx> i can't be of much help though, no bg1 here
[21:42:43] <lynxlynxlynx> the mod install did complete without problems?
[21:43:06] <Bo_Thomsen> Yep
[21:43:24] <Bo_Thomsen> And makes the changes without a problem as well
[22:10:12] <pupnik> :/
[22:27:00] <Avenger> hmm there is no guilsxx.mos in bg1
[22:28:29] <Avenger> i wonder which game has them
[22:32:52] <Avenger> bg1 has gtrsk001-gtrsk005.mos
[22:32:53] <lynxlynxlynx> how has guiwls*
[22:33:06] <Avenger> heh
[22:33:15] <Avenger> how this guils come then
[22:35:21] <lynxlynxlynx> from us
[22:35:31] <Avenger> odd... i found no game having it
[22:35:31] <lynxlynxlynx> gemrb/GUIScripts/bg1/LoadScreen.py:39: LoadPic = "GUILS0"+str(GemRB.Roll(1,9,0))
[22:35:54] <Avenger> that seems to be a wild guess at best :)
[22:36:12] <lynxlynxlynx> guils windowpack in all of our loadscreens
[22:36:28] <Bo_Thomsen> Uh, but that wouldn't have anything to do with the actual game screen?
[22:36:31] <Avenger> yes, but that was my doing
[22:36:42] <Avenger> yes, not much, it is a .chu
[22:36:53] <fuzzie> Bo_Thomsen: your resolution in the gemrb config matches whatever you last ran the widescreen mod with?
[22:36:59] <lynxlynxlynx> what would is GUILSOP, which bg1 uses for a few buttons
[22:37:03] <Bo_Thomsen> Yeah
[22:38:06] <Bo_Thomsen> Or one thing I was wondering, widescreen mod seem to have an odd sence of x and y axis... I think it is inverted as compared to a normal coordinate system
[22:39:12] <lynxlynxlynx> pst definitely has them
[22:39:49] <Avenger> oddly enough i don't even see the engine trying with guils
[22:40:13] <Avenger> ahh i see it
[22:43:58] <Avenger> ok, i don't have much time to fix this, guils.chu needs a change
[22:44:13] <Avenger> similar to the one in bg2
[22:44:34] <Avenger> it needs a new control (a button, i guess) that holds the picture
[22:44:52] <Avenger> LoadPic = "GTRSK00"+str(GemRB.Roll(1,5,0))
[22:45:21] <Avenger> and something like: Middle.SetMOS (LoadPic)
[22:46:02] <Avenger> i'll do this tomorrow, if no one else
[22:46:04] <-- Avenger has left IRC (Quit: bye!)
[23:00:19] <-- lynxlynxlynx has left IRC (Read error: Connection reset by peer)
[23:06:41] <-- micke_ has left IRC (Ping timeout: 255 seconds)
[23:20:02] <-- Bo_Thomsen has left IRC (Quit: Leaving.)
[23:25:09] --> SiENcE has joined #GemRb
[23:28:16] --> MrJones has joined #GemRb
[23:28:20] <MrJones> hey guys
[23:30:37] <-- SiENcE has left IRC (Quit: cya @all)
[23:30:53] --> SiENcE has joined #GemRb
[23:32:21] <MrJones> I got a technical question
[23:32:31] <MrJones> since I have no idea of how the Infinity Engine or GemRB work
[23:32:48] <MrJones> I am curious how the maps are done, since... well, I suppose you render them using opengl or something
[23:32:56] <MrJones> so the main thing I have been wondering about is:
[23:33:01] <MrJones> are the maps streamed?
[23:33:20] <MrJones> or are really ALL textures used in the map with all the prerendered buildings and whatever loaded into memory in full size?
[23:33:33] <-- SiENcE has left IRC (Client Quit)
[23:34:15] <fuzzie> you know the Infinity Engine is the 2D one?
[23:34:45] <MrJones> yea
[23:34:56] <MrJones> but bg2 had 3d acceleration I believe, didn't it?
[23:35:02] <MrJones> and I assume GemRB most likely also does
[23:35:09] <MrJones> and even if it doesn't
[23:35:12] <fuzzie> the background data files are made of tiles
[23:35:17] <MrJones> ok
[23:35:25] <MrJones> are all those tiles loaded?
[23:35:27] <fuzzie> with various things rendered on top
[23:35:40] <MrJones> especially those rendered things on top is what surprises me
[23:35:46] <MrJones> since e.g. in the cities or indoor there is LOTS of prerendered stuff
[23:36:00] <MrJones> I was simply wondering how or if the Infinity Engine could load this all into memory without problems
[23:36:15] <fuzzie> i think a typical set of tiles is less than 40mb
[23:36:16] <MrJones> or whether they are streaming it from disk
[23:36:29] <MrJones> now just the ground/background tiles? excluding the buildings?
[23:36:32] <MrJones> or including the buildings
[23:36:59] <fuzzie> but the IE maps are designed so that almost everything is simply prerendered/baked into the background tiles
[23:37:05] <fuzzie> unlike something like Lionheart
[23:37:23] <MrJones> hm
[23:37:36] <MrJones> but still every house needs an extra graphic of which many reach screen size :-?
[23:37:39] <fuzzie> in both IE and Lionheart, they both did some kind of streaming from disk
[23:37:51] <MrJones> and baldur's gate had mostly individual houses on a map, so that's quite a lot of data
[23:37:57] <fuzzie> but in a very primitive fashion.
[23:37:58] <MrJones> so infinity engine DID indeed stream from disk?
[23:38:17] <MrJones> what about GemRB?
[23:38:26] <MrJones> is it simply loading all graphics at once or also doing some simple streaming?
[23:38:45] <fuzzie> it simply loads all graphics at once, which is not good :) so simple streaming is high on the todo
[23:39:11] <MrJones> hm
[23:39:17] <MrJones> what do you mean by simple streaming?
[23:39:26] <pupnik> MrJones: i recall bg2 had some directx acceleration - i wouldn't call it 3d strictly
[23:39:26] <MrJones> e.g. just the big house graphics and not the small grass/ground tiles?
[23:39:37] <MrJones> pupnik: yea, but surely they had to upload all the graphics to the video card?
[23:39:41] <fuzzie> but there is an important point to make
[23:39:50] <fuzzie> which is: the background tiles are paletted in 256 colours per-tile
[23:39:50] <pupnik> yes but a video display is 2d MrJones
[23:40:30] <MrJones> no I mean they didn't load it as direct3d textures then with real quad drawing?
[23:40:36] <MrJones> was it still software blitting or real 3d textures?
[23:40:38] <fuzzie> this is not such a huge restriction with small tiles, especially if you can render on top, and it reduced their memory usage by 4x compared to 24bpp
[23:40:57] <MrJones> so they loaded all the 256 colour tiles, and all those fancy big house graphics are streamed?
[23:41:00] <pupnik> MrJones: streaming in this case means that not all of the background graphics are loaded into memory at onfce
[23:41:11] <MrJones> sure, but I am just wondering WHAT exactly was streamed
[23:41:13] <fuzzie> but i think maybe your real question is whether they're doing some kind of streaming with textures
[23:41:16] <MrJones> everything, or just some specific parts of the scene
[23:41:44] <MrJones> no I'm assuming now some graphics are streamed, I am just wondering what of the graphics is and what isn't
[23:41:48] <fuzzie> i don't know the answer to that in the original IE, but the usual technique is just to upload enough textures to the graphics card for what is off-screen and some amount of slightly off-screen stuff
[23:41:56] <MrJones> yea...
[23:42:12] <pupnik> i think all bg2 did was use directx to do final compositing of characters on background, along with background blits and translation
[23:42:12] <MrJones> well really useful to hear a confirmation that IE indeed streamed stuff
[23:42:17] <pupnik> is that about right fuzzie ?
[23:42:17] <fuzzie> but that is very different to what is loaded from disk
[23:42:32] <MrJones> sure
[23:42:41] <fuzzie> pupnik: yes, but i think MrJones's point is that you still need to manage the textures there
[23:42:41] <MrJones> but I assume IE also streamed the textures from disk in this case
[23:42:45] <MrJones> yea
[23:43:10] <MrJones> I simply wondered how baldur's gate ran smoothly without any hangs or much hard disk activity with those large maps :)
[23:43:16] <fuzzie> it has become completely irrelevant to the IE, because everyone playing now has enough RAM to set the 'tile cache' to 100%, which means it just loads everything at startup
[23:43:24] <MrJones> oh lol
[23:43:37] <MrJones> again, I need to ask something:
[23:43:41] <MrJones> tiles. is that just the background stuff?
[23:43:45] <MrJones> e.g. paths, flowers, grass
[23:43:45] <fuzzie> but it is still relevant to us, because things like the iPad won't hand gemrb all the RAM :-)
[23:43:47] <MrJones> the ground
[23:43:50] <fuzzie> it is all pre-rendered
[23:44:02] <fuzzie> i don't think i have any good example to show
[23:44:03] <MrJones> so the houses, flowers, grass is all baked together? just one single background texture?
[23:44:05] <MrJones> no multiple layers?
[23:44:08] <fuzzie> but they rendered the buildings right onto it
[23:44:10] <MrJones> just one texture layer?
[23:44:26] <MrJones> so the whole level is just one single huge graphic split up in tiles? O_O
[23:44:53] <MrJones> or is it rendered out of multiple single tiles blit on top of each other (separate blits for each tree graphic and stuff)
[23:45:01] <fuzzie> it is mostly the one single huge graphic :)
[23:45:10] <MrJones> when you say mostly, what isn't?
[23:45:13] <fuzzie> all animations are in seperate overlays
[23:45:16] <MrJones> just the characers then? :)
[23:45:19] <MrJones> oh the water, I see
[23:45:22] <MrJones> and such things
[23:45:24] <MrJones> ok
[23:45:28] <MrJones> that's why it was mostly static I guess :D ha
[23:45:38] <fuzzie> and there are multiple sets of tiles for things like different light levels
[23:45:40] <MrJones> thanks a lot for explaining all that to me. it is very interesting indeed
[23:45:50] <fuzzie> for example, when you open a door, you get light shining from inside.
[23:45:55] <MrJones> ohh ok
[23:45:55] <tomprince> Also, you can walk behind certain tiles.
[23:46:04] <MrJones> is the walk behind actually done in layers?
[23:46:11] <fuzzie> not in graphical layers
[23:46:12] <MrJones> or... did they just have some sort of mask texture and compute it using that
[23:46:14] <fuzzie> they use something called wallgroups
[23:46:50] <fuzzie> tomprince maybe knows the community resources better than me..
[23:47:11] <MrJones> well I am really curious how they achieved the pixel-perfect wall walkbehinds
[23:47:22] <MrJones> one way of doing this would be to keep everything "on top" in a separate texture
[23:47:38] <tomprince> No, not really.
[23:47:38] <MrJones> but then again that seems tedious and causes problems if you can sometimes stand behind or in front of it... (e.g. for a wall)
[23:47:51] <fuzzie> but see 'Area Basics' under http://www.simpilot.net/~sc/dltcep/index.htm
[23:48:25] <MrJones> and the whole background graphics are really just 256 colours?
[23:48:28] <fuzzie> which shows how the wallgroups are done: they are polygon groups specifying walls
[23:48:29] <MrJones> I could have bet it's at least 16bit :D
[23:48:39] <MrJones> oh I see
[23:48:42] <MrJones> do they have some sort of baseline?
[23:48:51] <tomprince> Each tile can have a different palette.
[23:48:58] <MrJones> e.g. if you're on top of the line, you're behind/below and below the line you're on top of it
[23:49:14] <MrJones> tomprince: are the tiles necessarily of a specific size and square? or rather, freeform things
[23:49:40] <tomprince> Square.
[23:49:43] <fuzzie> you can see 'polygon flags' in that page i linked; so you can specify when characters are hidden
[23:50:04] <MrJones> huh
[23:50:28] <fuzzie> and you can also see the tiles and everything :) would highly recommend reading through it if you're interested
[23:54:30] <MrJones> about the polygons
[23:54:42] <MrJones> do you actually convert them to a mask texture internally? so does the engine use a pixel-based approach?
[23:54:46] <MrJones> or does it actually work with those polygons
[23:55:31] <fuzzie> i think gemrb converts into scanlines
[23:55:57] <MrJones> ok, that is probably equivalent to pixels in a certain form
[23:56:18] <MrJones> so those walkbehinds of overhanging walls where your characters become partly grey are also those overlay polygons?
[23:56:25] <fuzzie> yes
[23:56:41] <MrJones> and well.. what about the specific case of a wall that goes perfectly horizontal from the left border of the screen to the right
[23:56:58] <MrJones> and you can stand right in front of the wall with a character (needs to be normal) or right behind it (needs to be covered by that walkbehind)
[23:57:02] <MrJones> can the engine actually do that?
[23:57:10] <fuzzie> yep
[23:57:15] <MrJones> how?
[23:57:24] <fuzzie> 'cover only if feet are in polygon'
[23:57:34] <MrJones> oh lol, interesting
[23:57:45] <MrJones> yea sure, for shadows that seems quite sufficient...
[23:57:54] <MrJones> I thought of some more complicated base line approach but... I guess that's not even needed
[23:57:57] <MrJones> hm
[23:58:04] <MrJones> are the level files of baldur's gate only available as those baked tiles?
[23:58:13] <MrJones> or is it possible to edit those background graphics and e.g. move the buildings
[23:58:26] <fuzzie> it is all just baked tiles
[23:58:26] <MrJones> but I guess they used some internal editor and just shipped the baked graphics with the game? :/
[23:58:29] <MrJones> hm
[23:58:36] <MrJones> do you have some sort of editor for gemrb that offers the same?
[23:58:41] <MrJones> or do people just use e.g. GIMP
[23:59:05] <fuzzie> bear in mind that bg1 was 5 CDs with all this stuff being baked to 256 colours..
[23:59:46] <fuzzie> and i think people just use graphics editors. but i don't know :) and i must go sleep