#gemrb@irc.freenode.net logs for 31 Oct 2010 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage

[00:03:00] --> deepinthewoods has joined #GemRb
[00:13:49] <-- barra_ has left IRC (Ping timeout: 252 seconds)
[01:17:33] --> barraAway has joined #GemRb
[05:03:18] <-- barraAway has left IRC (Quit: Verlassend)
[06:51:44] --> lynxlynxlynx has joined #GemRb
[06:51:45] --- ChanServ gives channel operator status to lynxlynxlynx
[07:24:19] <lynxlynxlynx> is it deliberate that summons are not added to the NPCs vector?
[07:25:06] <lynxlynxlynx> due to that GetGlobalActorByGlobalID doesn't find them
[07:29:52] <lynxlynxlynx> or PCs
[08:04:24] <lynxlynxlynx> with that added, my planetar can cast :)
[09:17:04] <fuzzie> yes, GetGlobalActorByGlobalID doesn't find them because they're not globals
[09:17:17] <fuzzie> and hence don't belong in the PCs/NPCs vectors
[09:18:35] <fuzzie> just change the end of Game.cpp to be 'return GetGlobalActorByGlobalID(globalID);', i guess?
[09:18:49] <fuzzie> then use GetActorByGlobalID again
[09:20:23] <fuzzie> we should really make it a hash, but that can be done *after* everything works
[09:22:29] <fuzzie> i had a poke around at LLVM's hash stuff and some alternatives, but none of them are any better than Variables really. easiest would be to steal scummvm's hashmap probably, even if it is flaky..
[09:22:52] <fuzzie> but not worth the bother. also, good morning! :)
[09:31:44] <lynxlynxlynx> gmornin
[09:34:29] <lynxlynxlynx> trying this out
[09:49:13] <lynxlynxlynx> works fine :)
[09:50:02] <fuzzie> whee :)
[09:58:53] <CIA-29> GemRB: 03lynxlupodian * r3dee8810b7db 10gemrb/gemrb/ (3 files in 2 dirs): added GetFirstSelectedActor and a guiscript interface for it
[09:59:04] <CIA-29> GemRB: 03lynxlupodian * rb9ae9c0a06e0 10gemrb/gemrb/core/Game.cpp: Game::GetActorByGlobalID: try GetGlobalActorByGlobalID if nobody was found
[10:01:16] <fuzzie> probably shouldn't say 'index' if it's a gid?
[10:02:12] <lynxlynxlynx> isn't the gid an index?
[10:02:16] <fuzzie> i guess you're planning large changes on that front, but we *will* still need PC indexes
[10:02:26] <fuzzie> don't know what we call those right now
[10:02:54] <fuzzie> but i think a gid is best described as 'identifier'
[10:03:56] <fuzzie> let me go check a dictionary
[10:04:31] <fuzzie> hm, dictionary very unhelpful :)
[10:04:39] * fuzzie prods wjp
[10:05:21] <lynxlynxlynx> it is an abreviation for identifier, yes
[10:05:35] <CIA-29> GemRB: 03lynxlupodian * r0f811435ca0b 10gemrb/gemrb/plugins/GUIScript/GUIScript.cpp: small clarification to the GemRB_GameGetFirstSelectedActor doc
[10:05:45] <lynxlynxlynx> what i meant was that we assign them consecutively, so they're also indices
[10:05:47] <fuzzie> well, i meant independently of whatever we're using internally :)
[10:40:45] <wjp> fuzzie: yes?
[10:44:55] <fuzzie> it doesn't matter, i'll bug people irl about it, just curious about when it is best to use which term
[10:45:20] --> Maighstir has joined #GemRb
[10:52:45] <lynxlynxlynx> http://pastebin.ca/1977861 <-- agreeable? i left a few uses of GameGetFirstSelectedPC in
[10:54:16] <lynxlynxlynx> some for containers and one for dialog, but both could probably go
[10:54:36] <lynxlynxlynx> only the guiscript wrapper would then be left
[10:59:01] <fuzzie> hm
[10:59:52] <fuzzie> let me look at a couple of things, if you could
[11:01:00] <lynxlynxlynx> sure
[11:01:03] <fuzzie> the thing is, i changed this code away from some of that
[11:01:25] <fuzzie> eg i changed the context around 835 to prefer PCs
[11:01:38] <lynxlynxlynx> oh, maybe just merge some of that in early
[11:01:47] <fuzzie> i mean, months ago, in git
[11:01:53] <fuzzie> erm, 1835
[11:02:26] <fuzzie> the reason is, the selected array isn't sorted properly, and so you end up with a party selected but unable to open doors because a summon is in selected[0]
[11:03:08] <lynxlynxlynx> and they're too dumb, ok
[11:04:03] <lynxlynxlynx> reverted that chunk
[11:04:10] <fuzzie> also i think the QF_ENTERGAME bit should really be the protagonist but i'm not sur ewhy
[11:05:01] <fuzzie> i think the trouble with all the stuff in Interface is that you don't want to switch maps to a map which only has a summon on it
[11:05:33] <fuzzie> and you do want it to work if you don't have a selected actor at all
[11:05:46] <fuzzie> so i think both those Interface.cpp chunks are bad?
[11:05:56] <fuzzie> oh, the second one checks for a selection :) but still
[11:05:59] <lynxlynxlynx> we should disable deselecting everyone
[11:06:07] <lynxlynxlynx> i think it is only possible by the selection dying now
[11:06:28] <fuzzie> but mostly, maps with summons on them should be ignored and swapped out
[11:07:02] <lynxlynxlynx> mhm, leaving is problematic, they can't enter by their own
[11:07:15] <lynxlynxlynx> i hope that's true for familiars too
[11:07:39] <-- devurandom has left IRC (Remote host closed the connection)
[11:07:40] <fuzzie> i am hoping that familiars should be forcibly pulled along if you lose everyone else
[11:07:48] <fuzzie> but honestly i've never played with one
[11:07:58] <fuzzie> the other ones are all fine, anyway
[11:08:38] <fuzzie> and the chunk you reverted would be a nice tidy up if i'd fixed the selection order..
[11:09:02] <lynxlynxlynx> leaving summons would only be a problem if a script suddenly moved you to another area, but i'm sure that happens already
[11:10:08] <fuzzie> even if you just walk through an exit, it would behave oddly, right?
[11:10:47] <lynxlynxlynx> depends on the ordering
[11:11:09] <fuzzie> you can select a party, click on an exit, and then select the summon
[11:11:13] <fuzzie> oh, right, should fix exits!
[11:11:32] <lynxlynxlynx> ah
[11:12:04] --> devurandom has joined #GemRb
[11:13:11] <fuzzie> that is another good question actually
[11:13:32] <CIA-29> GemRB: 03lynxlupodian * r0e6b9590371f 10gemrb/gemrb/core/GUI/GameControl.cpp: added some GetFirstSelectedActor uses
[11:13:32] <fuzzie> if you select a party member, click on a doorway or similar exit, and then select someone else before they get there, what happens? they still go through, or not?
[11:13:35] <lynxlynxlynx> summons never follow you through areas
[11:13:54] <lynxlynxlynx> i think they do, but maybe that's a gemrb memory
[11:17:47] <fuzzie> i guess it is easy enough to do either
[11:18:13] <fuzzie> the idea is, now we have global ids, we can manufacture actions which have anything as a target
[11:18:47] <lynxlynxlynx> thinking more about it, i think the original had no problem with that
[11:19:21] <lynxlynxlynx> fighting liches in subareas, while the rest of the party was in the master one, you could switch between them fluently
[11:21:14] <lynxlynxlynx> but that isn't the same
[11:22:05] <fuzzie> btw, you said that generating actions didn't work with actions from our override?
[11:22:33] <lynxlynxlynx> something like that
[11:22:38] <fuzzie> ok. had better fix that.
[11:22:45] <fuzzie> don't know if you read logs?
[11:22:49] <lynxlynxlynx> it was about BashDoor that has a bad prototype in the original
[11:22:55] <lynxlynxlynx> sometimes
[11:23:03] <fuzzie> but there's a bit in InventoryCommon which you made bg2-specific, using BeginDialogOverride instead of BeginDialog
[11:23:35] <lynxlynxlynx> we did detect we have an override, but since this is in a different list, most of the uses don't care about it
[11:23:37] <fuzzie> it needs to be BeginDialogOverride for all versions, since otherwise it corrupts the dialog field of party members, but that isn't an original action
[11:23:48] <fuzzie> so i guess i have to fix the generation code so it checks the other list
[11:24:31] <fuzzie> and am wondering if there's any other obvious things which could do with that fix
[11:25:07] <lynxlynxlynx> yes, the bashdoor thing - we could make the gui use the action then
[11:25:40] <lynxlynxlynx> the inventorycommon bit is just the result of the merge
[12:07:46] <-- devurandom has left IRC (Remote host closed the connection)
[12:10:48] --> devurandom has joined #GemRb
[12:11:20] <-- devurandom has left IRC (Remote host closed the connection)
[12:14:18] --> devurandom has joined #GemRb
[12:42:29] --> barraAway has joined #GemRb
[13:14:35] --- barraAway is now known as barra_home
[13:22:07] --> SiENcE has joined #GemRb
[16:34:22] <lynxlynxlynx> hehe
[16:34:33] <lynxlynxlynx> summoned spiders have a web spell innate
[16:34:44] <lynxlynxlynx> don't remember being able to cast that in the original
[16:36:42] <lynxlynxlynx> nevermind, this is kittix
[16:46:43] <fuzzie> the figurine?
[16:47:13] <lynxlynxlynx> yes
[16:48:09] <lynxlynxlynx> Web Tangle actually
[17:00:41] <lynxlynxlynx> cool, everything works now
[17:01:11] <lynxlynxlynx> the three hardcoded buttons are slightly problematic, but that's a separate issue
[17:04:36] <fuzzie> cool
[17:06:35] <CIA-29> GemRB: 03lynxlupodian * re36ff53bbca8 10gemrb/gemrb/plugins/GUIScript/GUIScript.cpp:
[17:06:35] <CIA-29> GemRB: made some guiscript functions also callable with a global id
[17:06:35] <CIA-29> GemRB: this is needed to make npcs actionrows functional
[17:06:39] <CIA-29> GemRB: 03lynxlupodian * rdc22d704a162 10gemrb/gemrb/GUIScripts/bg2/GUICommonWindows.py:
[17:06:39] <CIA-29> GemRB: bg2: working actionrows for everyone!
[17:06:39] <CIA-29> GemRB: now all the spellcasting summons are much more useful
[17:08:07] <fuzzie> nice way to avoid big changes
[17:09:46] <fuzzie> SetModalState always takes a globalid now?
[17:10:02] <lynxlynxlynx> didn't change that one
[17:10:09] <fuzzie> you changed the python, though?
[17:10:19] <lynxlynxlynx> probably needed though, since familiars can pickpocket
[17:10:26] <fuzzie> - pc = GemRB.GameGetFirstSelectedPC ()
[17:10:27] <fuzzie> + pc = GemRB.GameGetFirstSelectedActor ()
[17:10:27] <fuzzie> GemRB.SetModalState (pc, MS_TURNUNDEAD)
[17:10:29] <fuzzie> ^- a lot of those
[17:10:43] <lynxlynxlynx> yeah, i'll get a familiar to test
[17:11:31] <fuzzie> well, i'm just confused
[17:11:37] <fuzzie> GameGetFirstSelectedActor always returns a globalid
[17:11:47] <lynxlynxlynx> no, you're right
[17:12:10] <lynxlynxlynx> i just didn't notice it since it is rare in summons and my test chars are fighters and sorcerers
[17:12:35] <fuzzie> same for SetupQuickSlot, GetSlotItem, etc
[17:13:38] <lynxlynxlynx> quickslots are fine
[17:14:04] <fuzzie> you can use the items?
[17:14:45] <lynxlynxlynx> i'll have to try a simulacrum, but i did change the functions so the buttons don't error out (they did even when empty)
[17:14:52] <fuzzie> i'm just looking at the source, but you now call GameGetFirstSelectedActor, get a globalid, and then pass it to those functions which only call FindPC
[17:15:23] <fuzzie> oh, maybe i should say: you should test these by loading a game and then loading a different game after
[17:15:36] <lynxlynxlynx> i see there's a problem
[17:15:53] <lynxlynxlynx> also need to check if we copy their inventory
[17:16:38] <lynxlynxlynx> nope
[17:16:40] <fuzzie> if you do two loads, then any issues should be reproducible for all test chars
[17:17:18] <fuzzie> i guess we should probaby start global ids at a high value to make this stuff obvious :)
[17:18:38] <lynxlynxlynx> the modals don't work, yes
[17:18:44] <lynxlynxlynx> pick pocket does
[17:19:40] <CIA-29> GemRB: 03fuzzie * r1ba00907a6fa 10gemrb/gemrb/core/Scriptable/ActorBlock.cpp: start global ids at a non-zero value to make debugging easier
[17:25:31] <lynxlynxlynx> for the inventory thing a new function is needed or can it be done with a clever memcpy or similar?
[17:26:00] <lynxlynxlynx> it's in Actor::CopySelf in case you forgot
[17:27:22] <fuzzie> hm
[17:27:42] <fuzzie> i think you need a new function
[17:28:09] <fuzzie> does everything get copied, bags and all?
[17:28:36] <lynxlynxlynx> i don't know, but it should get marked as undroppable
[17:29:03] <lynxlynxlynx> at minimum it is all the equipped stuff, since the boni and the actionrow are the same
[17:29:34] <lynxlynxlynx> it's one of the cheesy tactics -> cast simulacrum to use a valuable potion or scroll (since you duplicated it for free)
[17:29:38] <fuzzie> technically i think it is fairly trivial to copy the inventory
[17:30:09] <lynxlynxlynx> i'll first fix the remaining functions
[17:30:14] <fuzzie> oke
[17:30:24] <fuzzie> i'm doing .. something
[17:30:35] <fuzzie> oh, right, git diff tells me it's the action stuff
[17:34:00] <CIA-29> GemRB: 03fuzzie * r3b3a4ea473fe 10gemrb/gemrb/core/GameScript/ (GSUtils.cpp GSUtils.h GameScript.cpp): don't reference actionsTable inside GenerateActionCore
[17:42:41] <fuzzie> action.ids.bg2:293 StartDialogOverride(S:DialogFile*,O:Target*)
[17:42:41] <fuzzie> action.ids.iwd2:293 UnHide(O:Object*)
[17:42:43] <fuzzie> ^- :-(
[17:44:55] <lynxlynxlynx> why not just assign it a high id?
[17:45:14] <-- Maighstir has left IRC (Ping timeout: 255 seconds)
[17:45:21] --> Maighstir has joined #GemRb
[17:45:22] <fuzzie> hehe
[17:45:30] <fuzzie> because until i looked at our existing gemact.ids, i didn't know i could :)
[17:46:45] <lynxlynxlynx> :)
[17:48:13] <fuzzie> $ grep BashDoor action.ids.* | uniq -f 1 -c
[17:48:13] <fuzzie> 4 action.ids.bg1:148 BashDoor(0:Object)
[17:48:13] <fuzzie> 1 action.ids.pst:148 BashDoor(0:Object*)
[17:48:23] <fuzzie> ^- o.O
[17:49:08] <lynxlynxlynx> yep
[17:49:14] <lynxlynxlynx> that's why we don't use it in the gui
[17:50:18] <lynxlynxlynx> http://pastebin.ca/1978056 <-- this is just waiting for the overriding to be fixed
[17:50:34] <lynxlynxlynx> (did the previous commit already do it?)
[17:50:52] <fuzzie> no
[17:51:23] <fuzzie> why remove one 'return;' and not the other?
[17:52:15] <lynxlynxlynx> i don't remember, maybe some more context is needed
[17:55:37] <lynxlynxlynx> uhh, all those InParty checks when doing feedback will need revisiting for familiars
[17:56:44] <fuzzie> we could add a function
[17:57:02] <lynxlynxlynx> sure
[17:58:36] <CIA-29> GemRB: 03fuzzie * r1ac2570f54b4 10gemrb/gemrb/core/GameScript/ (GSUtils.cpp GSUtils.h GameScript.cpp): also check override actions table in GenerateAction
[17:58:39] <CIA-29> GemRB: 03fuzzie * r11d62b0f48b3 10gemrb/gemrb/ (GUIScripts/InventoryCommon.py override/shared/gemact.ids): add StartDialogOverride to gemact.ids, always use it for inventory items
[17:58:54] <fuzzie> afaics that 'return;
[17:58:57] <fuzzie> ' is needed
[18:00:25] <fuzzie> seems i forgot to remove the '|| door->TrapDetected' in HandleDoor back in jan 2009, too
[18:00:59] <CIA-29> GemRB: 03lynxlupodian * re9a55621a80e 10gemrb/gemrb/ (2 files in 2 dirs): fixed the rest of the functions that needed globalid capabilities
[18:01:08] <fuzzie> but that patch should work now for containers, anyway :-)
[18:02:54] <lynxlynxlynx> first it needs some ingame time
[18:03:00] <fuzzie> oh, it won't
[18:03:04] <fuzzie> hmm
[18:03:05] <lynxlynxlynx> but first the simulacrums
[18:03:22] <fuzzie> ok, i didn't actually think about the BashDoor case properly
[18:03:51] <fuzzie> i thought 'oh, i can test it when i write a patch', but then it turns out you had one
[18:10:30] <CIA-29> GemRB: 03fuzzie * r6b8a2fdbdb5d 10gemrb/gemrb/core/GameScript/GameScript.cpp: fix GenerateAction so the overrideActionsTable is checked first
[18:11:39] <fuzzie> hopefully that one will do it. untested for the BashDoor case itself, but i checked some others.
[18:17:05] <lynxlynxlynx> looks better
[18:50:31] <fuzzie> hm, pst journal doesn't work?
[18:51:14] <fuzzie> oh wow, that's some horrible guiscript
[18:53:46] <lynxlynxlynx> the bestiary part worked the any time i tried it
[18:54:05] <fuzzie> i'm just looking at the journal bit
[18:54:15] <fuzzie> don't know if it ever worked, but there seems to be code there for it, at least
[18:54:46] <fuzzie> i was the last person to touch the guiscript code, again all the way back in jan 2009
[18:56:06] <fuzzie> i guess it was maybe broken by a commit in 2004
[18:56:25] <lynxlynxlynx> bah, we keep spamming the tob items
[18:56:38] <fuzzie> one of Avenger's commits titled "added optional section parameter to journal functions in guiscript", so of course it adds a mandatory chapter parameter :-)
[18:56:45] <fuzzie> lynxlynxlynx: bags?
[18:56:54] <lynxlynxlynx> all that intro gear
[18:57:05] <lynxlynxlynx> i started a fresh game
[18:57:11] <fuzzie> anything out of bags should be ok
[18:57:30] <lynxlynxlynx> it isn't
[18:57:36] <lynxlynxlynx> all the gear gets readded
[18:57:42] <lynxlynxlynx> over and over, if you drop it
[18:57:48] <lynxlynxlynx> maybe it's done on load
[18:57:51] <fuzzie> hm
[18:58:05] <lynxlynxlynx> but that's for later
[18:59:02] <fuzzie> GUIScript.cpp:2965 should be <=, not <
[18:59:23] <fuzzie> that's in GameSetExpansion, if you have a modified version locally
[19:00:46] <lynxlynxlynx> cool, thanks
[19:00:55] <lynxlynxlynx> still on the inventory thing
[19:04:33] <lynxlynxlynx> yeah, that's correct
[19:05:37] <-- SiENcE has left IRC (Quit: cya @all)
[19:10:18] <fuzzie> meh, pst journal does work with original games
[19:12:49] <CIA-29> GemRB: 03fuzzie * r89b742d1c506 10gemrb/gemrb/plugins/GUIScript/GUIScript.cpp: GameSetExpansion: return false if supplied expansion mode is already set
[19:57:15] --> edheldil_ has joined #GemRb
[20:44:22] <lynxlynxlynx> muh
[21:00:22] <fuzzie> problems?
[21:03:25] <lynxlynxlynx> yeah, still struggling with the inventory copying
[21:04:00] <lynxlynxlynx> the item transfer is trivial, but i can't seem to make the equipped info be the same
[21:04:15] <fuzzie> you're manually copying the vector?
[21:04:24] <lynxlynxlynx> yes
[21:04:48] <lynxlynxlynx> it was no better when i iterated over it and copied one by one
[21:05:59] <fuzzie> well, i mean, are you copying the CREItems
[21:06:47] <lynxlynxlynx> the whole Slots vector
[21:06:52] <fuzzie> yes
[21:06:54] <fuzzie> but they're pointers
[21:07:18] <lynxlynxlynx> hmm
[21:07:45] <fuzzie> so you have to allocate new CREItems for every one
[21:08:14] <fuzzie> then copy Equipped+EquippedHeader in both the Actor and the Inventory
[21:08:47] <lynxlynxlynx> actor has its own? grrr
[21:08:58] <lynxlynxlynx> but that's just for one slot anyway
[21:09:38] <fuzzie> yes
[21:09:40] <fuzzie> so more things
[21:10:05] <fuzzie> you need a 'if (PCStats) newActor->CreateStats();' for the quickslots etc
[21:11:50] <fuzzie> can't think of anything else relevate at a glance
[21:12:02] <fuzzie> we should be able to get rid of the hack in Window_SetupControls now
[21:19:09] <fuzzie> meh, i thought the bg2 item description text was working
[21:20:29] <lynxlynxlynx> it's the wrapping bug
[21:20:47] <fuzzie> there shouldn't be wrapping issues if it's just plain text :(
[21:22:33] <lynxlynxlynx> really? i don't remember it ever working
[21:23:05] <fuzzie> well, it works in some places fine
[21:23:20] <fuzzie> but i mean, i know of no bug which should cause such issues
[21:24:59] <lynxlynxlynx> maybe the image on the left forces a shift?
[21:25:02] <lynxlynxlynx> it is oversized sometimes
[21:27:42] <-- deepinthewoods has left IRC (Remote host closed the connection)
[21:32:37] <fuzzie> well, i guess the scrollbar in the CHU file is positioned over the text area?
[21:36:54] <-- barra_home has left IRC (Quit: Verlassend)
[21:46:57] <lynxlynxlynx> could be
[22:29:18] --> SiENcE has joined #GemRb
[23:17:44] <-- lynxlynxlynx has left IRC (Remote host closed the connection)