#gemrb@irc.freenode.net logs for 26 Sep 2010 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage


[01:06:38] <-- Maighstir has left IRC (Quit: ~ Trillian Astra - www.trillian.im ~)
[07:54:21] <-- spike411 has left IRC (Quit: Manga & anime pokec na Jabberu: manga.cz@conf.netlab.cz)
[08:38:40] --> lynxlynxlynx has joined #GemRb
[08:38:40] --- ChanServ gives channel operator status to lynxlynxlynx
[08:38:50] <CIA-93> GemRB: 03avenger_teambg * r8307c674deca 10gemrb/gemrb/GUIScripts/ (GUIDefines.py iwd2/LoadScreen.py): support areaload.2da in iwd2
[08:54:42] --> Maighstir has joined #GemRb
[09:29:43] <-- deepinthewoods has left IRC (Ping timeout: 245 seconds)
[09:49:11] --> deepinthewoods has joined #GemRb
[10:05:33] <CIA-93> GemRB: 03lynxlupodian * r1e2dea8ab3c4 10gemrb/gemrb/plugins/GUIScript/GUIScript.cpp: restored selling to stores
[10:25:33] <fuzzie> did someone fix the Capacity==0?
[10:26:31] <lynxlynxlynx> :P
[10:26:37] <fuzzie> oh, you did
[10:26:42] <fuzzie> ok :P
[10:26:49] <fuzzie> bit slow
[11:05:51] <CIA-93> GemRB: 03lynxlupodian * r05ccf4f2d452 10gemrb/gemrb/GUIScripts/GUISTORE.py: GUISTORE: a bit more code share
[11:05:55] <CIA-93> GemRB: 03lynxlupodian * rb0a1b5a64ce4 10gemrb/gemrb/ (GUIScripts/GUISTORE.py core/Interface.cpp):
[11:05:55] <CIA-93> GemRB: GUISTORE: do all the important price calculation at the same spot;
[11:05:55] <CIA-93> GemRB: implemented the charisma discount
[11:31:34] <CIA-93> GemRB: 03lynxlupodian * r9aecd3294c80 10gemrb/gemrb/GUIScripts/GUISTORE.py: GUISTORE: implemented the reputation bonus/malus to price
[11:36:35] <CIA-93> GemRB: 03avenger_teambg * r44a255dc1401 10gemrb/gemrb/ (11 files in 8 dirs):
[11:36:35] <CIA-93> GemRB: loadscreen during area load
[11:36:35] <CIA-93> GemRB: fixed previous commit and added HoW support of areaload.2da
[11:36:35] <CIA-93> GemRB: 03avenger_teambg * rc7a93c133f56 10gemrb/gemrb/ (3 files in 3 dirs): Merge branch 'master' of ssh://avenger_teambg@gemrb.git.sourceforge.net/gitroot/gemrb/gemrb
[11:36:54] --> Avenger has joined #GemRb
[11:36:54] --- ChanServ gives channel operator status to Avenger
[11:37:00] <Avenger> hi
[11:37:12] <lynxlynxlynx> oj
[11:38:09] <Avenger> first i thought i can do the loadscreen stuff easily, but then it turned out, the loadscreen isn't even displayed for area loading
[11:39:41] <Avenger> how goes the store stuff?
[11:40:01] <Avenger> did you manage to fix the bags?
[11:42:40] <fuzzie> the loadscreen stuff is really broken anyway
[11:42:54] <fuzzie> i tried looking at it, but it uses some MOS field for text or something really odd like that
[11:43:47] <fuzzie> oh, no, the MOS field for text is the text screens
[11:44:01] <fuzzie> the loadscreen is the one where there's no .chu in the original and we have a broken chu
[11:44:21] <Avenger> what is broken in it?
[11:44:41] <fuzzie> positions and text size, i think
[11:44:54] <fuzzie> i tried fixing it for one game - i guess bg2?
[11:45:35] <Avenger> well, it has now the potential to be even more broken ;)
[11:45:39] <fuzzie> no, just bg1, i guess
[11:48:26] <fuzzie> oh right, and STR_LOADMOS is the one which only exists on the python side
[11:48:59] <Avenger> it is just a constant, 0
[11:49:07] <Avenger> STR_AREANAME is 1
[11:49:16] <fuzzie> yes, and the other one is just a constant 1, but this is confusing to look at
[11:49:32] <Avenger> yep, they could be named in the c code too
[11:49:47] <fuzzie> but mostly this was just the fact that LOADMOS is not a MOS
[11:50:06] <fuzzie> which confused me
[11:50:19] <Avenger> actually, initially i thought it is, it was supposed to come from the worldmap
[11:50:36] <Avenger> there is a field which i thought to be the mos resref for loading areas
[11:50:40] <fuzzie> sorry, i mean, i'm looking at the TextScreen
[11:50:57] <fuzzie> it makes more sense for the LoadScreen stuff
[11:51:50] <fuzzie> but the TextScreen sets some LoadPic variable from the STR_LOADMOS and then doesn't ever use it
[11:52:00] <fuzzie> not lynx's fault, it's always been like that
[11:52:53] <lynxlynxlynx> it does use it, just not in every game
[11:52:59] <fuzzie> no
[11:53:02] <fuzzie> it uses the TableName
[11:53:02] <lynxlynxlynx> it was a merge with no cleanup
[11:53:11] <fuzzie> but the LoadPic is never used
[11:53:37] <lynxlynxlynx> if LoadPic == "":
[11:53:42] <fuzzie> see the line above that
[11:53:52] <fuzzie> oh, or else that is just the same as TableName
[11:53:59] <fuzzie> i mean, it is really not a merge artifact
[11:54:09] <fuzzie> but i am probably not explaining my problem well
[11:54:11] <Avenger> well, it is variable recycling
[11:54:26] <fuzzie> i looked into it because it breaks in some places, STR_LOADMOS isn't set
[11:54:27] <lynxlynxlynx> i know, i was trying to say that it needs research, since probably a few of those ifdefs can go
[11:54:35] <Avenger> tablename may be different
[11:54:41] <fuzzie> or rather, it is still set to the LoadScreen one
[11:54:53] <Avenger> merging spaghetti just caused more spaghetti :)
[11:55:03] <fuzzie> at least the spaghetti is all in one place..
[11:55:59] <Avenger> well, at least it is working
[11:56:16] <Avenger> i won't touch it because i might just break it ;)
[11:56:27] <fuzzie> i wanted to handle bg1 dreams, i forget what the problem there was
[11:57:47] <Avenger> there is some player1d support
[11:58:07] <fuzzie> that is a script, though
[11:58:09] <fuzzie> so that is bg2
[11:58:11] <Avenger> hmm, yep, it worked at one point, even the sarevok following :)
[11:58:17] <fuzzie> not interesting :P
[11:58:26] <fuzzie> i think the bg2 dreams all work fine
[11:58:26] <Avenger> player1d is bg2?
[11:58:44] <fuzzie> is it not?
[11:58:45] <Avenger> ok
[11:58:49] <Avenger> i don't know ;)
[11:58:59] <fuzzie> i thought it is a script, for dream cutscenes
[11:59:04] <fuzzie> and that is bg2 only as far as i know
[11:59:10] <fuzzie> bg1 has text screens
[12:00:13] <Avenger> yes, you are right
[12:00:18] <Avenger> and what's wrong with them
[12:00:22] <fuzzie> trying to find a youtube video of it
[12:00:43] <fuzzie> you would think there would be one
[12:01:53] <fuzzie> but i just couldn't make them work, but maybe i was trying to trigger them from the GUIScript and this was getting all messed up
[12:03:26] <fuzzie> oh, searching for 'Baldur's Gate dream' on youtube has them all.
[13:02:27] <lynxlynxlynx> bum crash
[13:03:00] <lynxlynxlynx> after LoadProgress: 70
[13:03:12] <lynxlynxlynx> in GameControl::Draw oO
[13:03:38] <lynxlynxlynx> GetCurrentArea() returns null
[13:06:23] <lynxlynxlynx> it's from the new LoadProgress calls
[13:11:48] <Avenger> yes i fixed that locally
[13:13:44] <CIA-93> GemRB: 03avenger_teambg * rb48997cb1acd 10gemrb/gemrb/ (GUIScripts/TextScreen.py core/GUI/GameControl.cpp): fixed crash when gamecontrol already exists but no area loaded yet
[13:18:09] <lynxlynxlynx> this can still crash
[13:18:20] <lynxlynxlynx> and sometimes the mos is changed during loading
[13:19:38] <lynxlynxlynx> can't reproduce the crash though (it died after a third reload)
[13:21:57] <Avenger> the mos change is actually part of the new code :)
[13:22:07] <Avenger> i mean, that is intended
[13:22:55] <Avenger> ok, this is almost fine
[13:23:05] <lynxlynxlynx> oh
[13:23:44] <lynxlynxlynx> you sure they don't depend on the (w)map? they nicely correspond to familiar scenes
[13:26:22] <Avenger> yes, because the 2da is set up that way
[13:26:39] <lynxlynxlynx> heh, now it crashed again
[13:26:49] <Avenger> oh, heh, i found the problem with the picture position
[13:27:03] <Avenger> try to catch the crash
[13:27:32] <lynxlynxlynx> the next time it worked
[13:27:50] <lynxlynxlynx> also the 10 or so times i tried it in gdb
[13:29:27] <Avenger> yeah
[13:29:30] <Avenger> same here
[13:37:27] <Avenger> phew, finally nailed the picture in its right place
[13:38:03] <lynxlynxlynx> crash, yay
[13:38:10] <lynxlynxlynx> but huh at the same time
[13:38:18] <Avenger> crash?
[13:38:22] <Avenger> git gdb?
[13:38:27] <Avenger> i mean got it with gdb?
[13:38:35] <lynxlynxlynx> Point mapsize = game->GetCurrentArea()->TMap->GetMapSize(); <-- same thing as before, just in another function
[13:38:39] <lynxlynxlynx> GameControl::OnSpecialKeyPress
[13:38:42] <Avenger> lol
[13:38:56] <Avenger> so it is itchy fingers crash
[13:39:29] <Avenger> gamecontrol should be 'dead' if there is no current area
[13:41:42] <Avenger> i hope there are no others
[13:41:55] * Avenger kicks CIA-93
[13:41:56] <lynxlynxlynx> key up? mouse up/down?
[13:42:15] <lynxlynxlynx> for this you don't have to press anything btw
[13:42:39] <CIA-93> ow
[13:42:56] <lynxlynxlynx> buggy commit
[13:43:02] <lynxlynxlynx> core/GUI/GameControl.cpp:2054:19: error: ‘class Game’ has no member named ‘game’
[13:43:59] <lynxlynxlynx> game->game-
[13:44:40] <lynxlynxlynx> so it is itchy fingers crash
[13:45:38] <Avenger> itchy fingers compile bug too :)
[13:45:55] <Avenger> ok, try now
[13:46:21] <CIA-93> GemRB: 03avenger_teambg * r5ffc7dc07603 10gemrb/gemrb/GUIScripts/iwd2/LoadScreen.py: loadscreen almost fixed
[13:46:39] <Avenger> cia is a bit slow today
[13:47:30] <lynxlynxlynx> sf compensates
[13:47:39] <CIA-93> GemRB: 03avenger_teambg * r05be56470d8a 10gemrb/gemrb/ (GUIScripts/iwd2/LoadScreen.py override/iwd2/guils.chu): fixed the loadscreen position (added a new control for the picture)
[13:47:39] <CIA-93> GemRB: 03avenger_teambg * r308d0fad2322 10gemrb/gemrb/core/GUI/GameControl.cpp: fixed rare crash
[13:47:40] <CIA-93> GemRB: 03avenger_teambg * reb0bb0399556 10gemrb/gemrb/core/GUI/GameControl.cpp: more possible null pointer defense
[13:47:41] <CIA-93> GemRB: 03avenger_teambg * r114f5b81eca8 10gemrb/gemrb/core/GUI/GameControl.cpp: fixed typo
[13:48:21] <Avenger> i had to mess with the .chu too
[13:48:38] <Avenger> the loadscreen images are smaller than the original background
[13:50:18] <Avenger> probably half of the code is not needed now, though
[13:53:48] <lynxlynxlynx> that's a good thing
[13:55:50] <CIA-93> GemRB: 03avenger_teambg * r3495ad67d13b 10gemrb/gemrb/GUIScripts/iwd2/LoadScreen.py: cut out unneeded parts
[13:56:40] <Avenger> yeah, it is still working, i didn't know why i lost half of the window graphics, so i tried everything to keep it on the screen
[13:58:39] <Avenger> hmm an import GUICommon still left in
[14:01:26] <lynxlynxlynx> and the window isn't properly unloaded
[14:02:13] <lynxlynxlynx> i'm in a store and clicking in a few areas the full loading circle bam is displayed
[14:02:31] <lynxlynxlynx> if i click lower i can also get the bottom labels
[14:14:46] <Avenger> this is iwd2?
[14:14:53] <lynxlynxlynx> bg2
[14:15:34] <Avenger> funny, because it has LoadScreen.Unload()
[14:18:20] <Avenger> i don't see that
[14:19:12] <lynxlynxlynx> click on the background in the middle of the buy/sell areas
[14:20:04] <lynxlynxlynx> or just play with the store for a while
[14:24:24] <Avenger> something is odd with exits
[14:25:42] <Avenger> or maybe just gaelan's house
[14:25:48] <Avenger> weird
[14:26:39] <lynxlynxlynx> how did odd manifest?
[14:28:48] <Avenger> i want to go up on the stairs, but i find myself outside the building
[14:29:01] <Avenger> and i see the store bug too
[14:29:44] <lynxlynxlynx> that one is known, sometimes we pick the wrong exit
[14:29:47] <Avenger> and the aerie/jaheira romance scripts seem to be madly sped up
[14:29:53] <lynxlynxlynx> (i think we just use the nearest one)
[14:29:56] <Avenger> they talk to me every second
[14:31:31] <lynxlynxlynx> ah, found my problem
[14:31:45] <Avenger> the store bug?
[14:31:47] <lynxlynxlynx> we only ever decrease AmountInStock
[14:31:52] <Avenger> ahh
[14:31:57] <lynxlynxlynx> no, i'm working on depreciation
[14:31:58] <Avenger> another store bug
[14:34:29] <fuzzie> Avenger: you have to make sure everyone is far away from the door before you go up the stairs
[14:34:40] <fuzzie> because, yes, what lynx said
[14:34:53] <Avenger> meh
[14:35:06] <Avenger> we gotta implement LeaveAreaName then
[14:35:22] <fuzzie> i don't think that is enough
[14:36:32] <fuzzie> but i forget how this works, can we identify all travel regions uniquely that way?
[14:36:35] <Avenger> LeaveAreaName is how the original engine did it. It is a separate action
[14:36:40] <Avenger> yes
[14:36:46] <fuzzie> the original engine has everything being an object, though
[14:37:01] <Avenger> yes
[14:37:12] <fuzzie> i thought we don't, for some important thing here
[14:37:29] <Avenger> we do for travel regions
[14:37:41] <Avenger> that's enough for this ;)
[14:37:45] <fuzzie> ok
[14:37:52] <fuzzie> well, i guess that works fine then :)
[14:38:32] <fuzzie> and the only person to change the romance script code recently is you, but i guess you know that
[14:39:29] <fuzzie> right, you noted in the commit that it was broken
[14:43:36] <Avenger> huh i did?
[14:44:00] <Avenger> how recently? i forgot that completely
[14:44:18] <Avenger> this is some timer i guess
[14:46:21] <fuzzie> the interact count
[14:47:40] <fuzzie> you changed the triggers so they don't use InteractCount, so now the scripts will think there's been no interacts yet
[14:51:24] <CIA-93> GemRB: 03lynxlupodian * r6c56301f1f9a 10gemrb/gemrb/plugins/GUIScript/GUIScript.cpp: increment AmountInStock when an item is sold
[14:51:25] <CIA-93> GemRB: 03lynxlupodian * r0edbcc3c1b4c 10gemrb/gemrb/ (GUIScripts/GUISTORE.py plugins/GUIScript/GUIScript.cpp): implemented store item depreciation
[14:53:25] <Avenger> oh
[14:53:54] <Avenger> that might be, though interact doesn't handle the protagonist
[14:54:05] <Avenger> it is a matrix of joinable npcs
[14:54:08] <fuzzie> how do you mean?
[14:54:14] <fuzzie> i mean, the interact checks are in the NPC scripts
[14:54:17] <Avenger> the protagonist is not in the matrix
[14:54:25] <fuzzie> oh, right
[14:54:36] <fuzzie> huh, i thought those scripts still had all the interact checks?
[14:54:39] <Avenger> but it could affect somehow
[14:55:07] <Avenger> jaheira/aerie talked to each other in one of those
[14:55:24] <Avenger> anyway i think it is more like some timer
[14:56:06] <fuzzie> it does use timers
[14:56:07] <fuzzie> but they work
[14:56:26] <fuzzie> or, well, they used to work :P
[14:57:36] <fuzzie> but you're right, the romance scripts in at least SoA don't check the interact counts outside
[14:59:00] <Avenger> RealSetGlobalTimer("JaheiraRomance","GLOBAL",3600)
[14:59:01] <fuzzie> i assume you get the right dialog?
[14:59:04] <Avenger> this may be too fast
[14:59:09] <Avenger> i guess
[14:59:18] <fuzzie> well, if you say it runs every second, those were working fine 6 months ago..
[14:59:28] <Avenger> weird
[15:00:00] <Avenger> well i don't really know if it was the romance stuff, but they definitely talk a lot :)
[15:00:43] <fuzzie> oh, is this a save?
[15:00:56] <Avenger> yes
[15:01:12] <Avenger> but i think it was an original game save
[15:01:14] <Avenger> why?
[15:01:39] <fuzzie> it doesn't look like the code is correct
[15:02:04] <fuzzie> it should be int0Parameter*AI_UPDATE_TIME you would think
[15:02:57] <Avenger> yep
[15:03:00] <fuzzie> in fact, worse, RealTime is in milliseconds
[15:03:15] <Avenger> so, they are really speed up
[15:03:17] <fuzzie> yeah
[15:03:22] <fuzzie> and it is just timer stuff
[15:03:34] <Avenger> i just wonder why we didn't notice this earlier
[15:04:49] <fuzzie> well, the interact stuff didn't work properly for a long time
[15:05:13] <fuzzie> because it would run the first state and then try finding the actor with the target dialog, and there was no actor with the target dialog
[15:06:00] <fuzzie> so you didn't get the variables incremented or timers set
[15:06:01] <Avenger> i gotta reboot and look at the original realsetglobaltimer
[15:06:06] <-- Avenger has left IRC (Quit: bye!)
[15:21:56] <CIA-93> GemRB: 03lynxlupodian * r6bb7668b716c 10gemrb/gemrb/GUIScripts/GUISTORE.py: GUISTORE: hide the extra infowindow button in iwd2 too
[15:31:58] <CIA-93> GemRB: 03lynxlupodian * rf010f5cf2f25 10gemrb/NEWS: the regular NEWS bump
[15:41:25] --> Avenger has joined #GemRb
[15:41:25] --- ChanServ gives channel operator status to Avenger
[15:41:43] <Avenger> fuzzie: it just multiplies by AI_UPDATE_TIME
[15:42:30] <Avenger> looks like RealTime has the same timescale as GameTime, it just continues to tick away when you pause the game?
[15:43:57] <lynxlynxlynx> sounds plausible
[15:44:12] <lynxlynxlynx> i doubt it has 5 minutes in an hour though
[15:44:20] <fuzzie> then you just have to change the RealTime increases to use 'count', then
[15:44:28] <Avenger> yes
[15:44:36] <Avenger> i guess that's what i need to do
[15:44:39] <fuzzie> :)
[15:44:54] <Avenger> i didn't see how is it changed yet
[15:45:29] <Avenger> are you still ill?
[15:46:23] <fuzzie> yes.. if i wasn't then i'd be catching up on university and not chatting on irc :(
[15:46:55] <fuzzie> we should probably never be increasing GameTime/RealTime by more than 1 tick at a time
[15:47:06] <fuzzie> so i would really love to know what the original engine does, to confirm
[15:48:29] <lynxlynxlynx> ouch
[15:49:00] <lynxlynxlynx> during cutscenes the loadscreen flickers a lot, but not constantly, at different points
[15:49:24] <Avenger> i guess it is not turned off then :)
[15:49:48] <lynxlynxlynx> it looked like all the area moves used it and it got stuck in between
[15:49:51] <Avenger> maybe i should call EndLoadScreen manually
[15:50:16] <lynxlynxlynx> and now it crashed
[15:50:24] <Avenger> itchy fingers again?
[15:50:52] <lynxlynxlynx> no, end of (third?) cutscene; i'll have to revisit it
[15:51:12] <Avenger> i hope it is unrelated to my loadscreen hack
[15:53:10] <lynxlynxlynx> Map::UpdateScripts crashes will a null actor
[15:55:39] <lynxlynxlynx> huh
[15:56:27] <lynxlynxlynx> Qcount[0] is 2, queue[PR_SCRIPT][i] is fine for 0 and 1 i, but at the crash point q is still 2
[15:57:12] <lynxlynxlynx> how come this didn't crash sooner?
[15:57:47] <lynxlynxlynx> or how come it is 2
[15:57:52] <fuzzie> how can q be 2?
[15:58:22] <lynxlynxlynx> gcc fail?
[15:58:51] <fuzzie> is something doing drawing inside a script, maybe?
[15:59:36] <fuzzie> this new loadprogress stuff, i guess
[15:59:37] <lynxlynxlynx> the backtrace is from the game loop
[15:59:52] <lynxlynxlynx> could be, since i do see it and a lot
[16:00:11] <lynxlynxlynx> by this point it is offset by half it width too
[16:00:38] <Avenger> heh, i guess drawwindows shouldn't be called from random places like this :)
[16:00:56] <fuzzie> yes, Avenger added a bunch of calls to LoadProgress
[16:00:59] <Avenger> though i would rather not draw gamecontrol
[16:01:02] <fuzzie> and that calls DrawWindows
[16:01:06] <Avenger> yep i know
[16:01:33] <Avenger> it would be good if it wouldn't even try to draw gamecontrol during load
[16:01:50] <fuzzie> the loadscreen isn't managing the windows properly, i guess?
[16:02:08] <fuzzie> but that is difficult to fix
[16:02:32] <Avenger> well, if it causes crash, it should be handled by the core
[16:02:35] <fuzzie> since this code is deep in LoadMap, so you can't interfere with the GUI
[16:03:16] <Avenger> i think i should somehow just set something like GameControl->ScreenFlags|=DO_NOT_DRAW while loading :)
[16:03:19] <fuzzie> i guess we really need a RealHideGUI function which hides everything
[16:03:34] <fuzzie> in any case, this code shouldn't be in the drawing code :P
[16:03:45] <Avenger> what code
[16:03:46] <fuzzie> and there is a comment there to this effect
[16:03:52] <fuzzie> the code which recreates the script queue
[16:04:10] <Avenger> yep, probably
[16:04:50] <fuzzie> so the proper fix is probably to move that..
[16:05:12] <fuzzie> Map.cpp:1028 if anyone is motivated
[16:05:19] <Avenger> oh cool,i found the random treasure stuff
[16:05:29] <Avenger> ie's version of ResolveRandomItem
[16:05:41] <Avenger> they set the charges of random scrolls to 1 :)
[16:06:58] <Avenger> hmm wait, they set them to 1 in many places, it is just not modular :)
[16:06:59] <fuzzie> i guess the queues should be replaced at the end of UpdateScripts
[16:07:08] <fuzzie> but the hack for textscreens makes that difficult
[16:07:23] <Avenger> how does that involve TextScreen's?
[16:07:35] <fuzzie> we do textscreens in the main loop and not in the action, or something like that
[16:07:58] <lynxlynxlynx> eat both the chicken and the egg
[16:08:01] <fuzzie> and so there's a hack in the script updating code
[16:08:20] <fuzzie> oh, i guess it has to go at the beginning anyway, since that code needs the queue..
[16:08:44] <fuzzie> i'm just a bit worried about whether we will draw things incorrectly, if it's only recalculated before scripts run
[16:09:29] <fuzzie> so this means, i am not volunteering to fix this :)
[16:12:55] <fuzzie> i still don't see why my patch from the other day for the bashing distance doesn't work :(
[16:14:17] <fuzzie> Avenger: hey, that is a useful thing we could do with knowing: anything you notice about scriptable positions
[16:14:57] <Avenger> scriptable positions?
[16:15:09] <Avenger> ah, hmm
[16:15:23] <Avenger> you want to know what is the 'operating distance' for bash?
[16:15:26] <fuzzie> no
[16:15:37] <fuzzie> i want to know where we measure the distance to :)
[16:15:43] <fuzzie> but the operating distance would also be interesting
[16:16:04] <lynxlynxlynx> what is Pos for non-actor scriptables?
[16:16:04] <Avenger> well, i take a peek at bashdoor
[16:16:07] <fuzzie> at the moment we just pick a position in the middle of the bounding box, which doesn't work for large doors
[16:16:30] <fuzzie> and for travel triggers we just check several different possible positions and hope one of them is right..
[16:16:34] <Avenger> btw, there is some baseline calculation for doors
[16:17:05] <Avenger> if i see it correctly, its position is the middle of the bottom edge
[16:17:16] <Avenger> but ijust remember this vaguely
[16:17:37] <fuzzie> oh, that would make a lot of sense!
[16:19:52] <Avenger> ok, let me see, all doors got 2 operating points, and there is a function which gets the closest
[16:20:01] <Avenger> this is the same as ours
[16:20:16] <fuzzie> and the bashing is done from the operating point?
[16:20:36] <fuzzie> that would make things a lot easier
[16:21:22] <fuzzie> do scriptables in the original engine even all have a Pos?
[16:21:49] <fuzzie> maybe it would make a lot more sense if we got rid of ours, if not
[16:21:51] <Avenger> containers do
[16:22:14] <fuzzie> well, i mean, in some parent class
[16:22:15] <Avenger> all scriptables got positions, actually
[16:22:19] <Avenger> yes
[16:22:21] <fuzzie> ok
[16:22:24] <Avenger> at offset 6/a
[16:22:31] <Avenger> every gameobject has it :)
[16:22:53] <Avenger> Position is right after the object type field
[16:23:24] <Avenger> you can see that in tobex
[16:23:39] <Avenger> actually, at 0xe they got a the Z coordinate too
[16:23:56] <Avenger> so every scriptable has a height too, which is totally unused in 99% of the time
[16:25:15] <Avenger> well, the weird thing is: i see no operating distance (or walking near to) in the BashDoor action :(
[16:26:57] <fuzzie> we do it in Attack
[16:27:10] <fuzzie> and we make our BashDoor always succeed, no rolls at all
[16:27:14] <fuzzie> don't know if it's the same in the original
[16:27:18] <fuzzie> also a good question :P
[16:28:00] <Avenger> hmm, since i dont' see it in opendoor either...
[16:28:12] <Avenger> maybe the move near to object stuff is done elsewhere
[16:28:54] <fuzzie> you want action 142, UseDoor
[16:28:56] <Avenger> there should be a 'bend bars' check
[16:29:10] <Avenger> yes fuzzie, i look at UseDoor now
[16:29:18] <fuzzie> opendoor is internal, no move near
[16:30:27] <Avenger> ok, i see it now
[16:31:37] <Avenger> operating distance is: (cellsize.x * 2)^2
[16:31:48] <-- tomprince has left IRC (Ping timeout: 245 seconds)
[16:32:31] <Avenger> that is 16*2*16*2 = 1024 (in pixels)
[16:33:39] <Avenger> this seems to be used only in UseDoor though
[16:34:56] <fuzzie> so that is 32
[16:35:02] <fuzzie> not too different from what we have
[16:36:18] <Avenger> this is just an additional check in doors, not the value used for move near
[16:36:34] <Avenger> if the distance is bigger, the action simply ends
[16:37:15] <fuzzie> do you see move near code?
[16:38:28] <Avenger> yes, but i'm confused by this
[16:38:47] <fuzzie> well, it is not so important
[16:38:51] <fuzzie> as usual
[16:44:48] <Avenger> oh i see the move near stuff in bashdoor now. It constructs a remove trap message before actually checking the distance, dunno why (it will discard it if the door isn't touched)
[16:45:07] <Avenger> i just thought it would already use it
[16:46:44] <Avenger> oh, it isn't a remove trap message, meh
[16:47:17] <Avenger> it is more like the stuff responsible for 'target busy'.
[16:47:42] <Avenger> mislabeled this message at one point
[16:53:30] <Avenger> ok, that cellsize_x*2^2 stuff is stored in different places, i just found the same value (different memory area) for containers
[16:53:53] <fuzzie> don't you love that :p
[16:54:44] <Avenger> the one used for containers is also used in LeaveAreaName (that is for travel regions)
[16:55:15] <Avenger> so, yeah, either they use separate constants for everything or the same, but wtf they have it this half assed way
[16:55:34] <Avenger> totally confuses me :)
[16:58:03] <Avenger> looks like the thing i thought as remove trap message just associates the door/trap/container whatever with the acting actor
[16:58:37] <fuzzie> not for walking towards it? :)
[16:59:55] <Avenger> no, that comes a bit later
[17:00:29] <Avenger> so bashdoor does: parse target, if target is not door/container abort
[17:01:00] <Avenger> then gets the object's operating point (for doors this is selecting from 2 points) for container it is the position
[17:01:07] --> SiENcE has joined #GemRb
[17:01:26] <Avenger> then does this fancy message i still don't know what for
[17:01:40] <Avenger> it just sets a field in the door/container to 1
[17:01:48] <Avenger> never seen it set to 0 though
[17:02:09] <Avenger> and THEN, i see the movenear stuff
[17:02:54] <Avenger> its kinda funny, because it has special cases for ankheg :)
[17:03:04] <fuzzie> heh
[17:03:24] <Avenger> when an ankheg moves, it 'emerges' first, when it stops, it hides again
[17:03:28] <fuzzie> sometimes i really envy the little scummvm engines which do everything in 10k lines of code
[17:03:37] <Avenger> yeah
[17:03:46] <Avenger> the IE is totally complex
[17:05:25] <fuzzie> but at least they tried to make it not too hardcoded
[17:11:54] <Avenger> ahh , i didn't know why the actor's EA is important here
[17:12:06] <Avenger> but now i know, you can bump your partymembers out of the way :)
[17:12:54] <Avenger> i just peer at the 'search request' data, which initiates pathfinding
[17:13:09] <Avenger> the IE doesn't calculate the walkpath in the same AI cycle
[17:13:19] <fuzzie> clever
[17:13:26] <Avenger> it creates a search request, which seems to be evaluated in another thread
[17:13:34] <Avenger> probably
[17:13:38] <fuzzie> maybe easier to look at bg1 :P
[17:13:59] <fuzzie> well, i guess not, since everything is going to be so different there
[17:14:01] <Avenger> why do you think so? you expect, bg1 has no such threads?
[17:14:27] <lynxlynxlynx> bg1 has stupid pathfinding
[17:14:41] <Avenger> anyway, our pathfinder is fast enough to be evaluated in the same ai cycle
[17:14:54] <fuzzie> bg1 doesn't do the bumping, certainly
[17:15:14] <Avenger> ah you meant the bumping part
[17:15:29] <fuzzie> well, i think lynx summarises it better
[17:15:34] <lynxlynxlynx> hehe
[17:15:43] <Avenger> i think we also mark the searchmap differently for partymembers
[17:15:49] <Avenger> or we did it at one time
[17:15:50] <fuzzie> yes
[17:15:52] <lynxlynxlynx> i don't remember any option to set the node count either
[17:15:57] <fuzzie> although it is a bit broken
[17:16:05] <fuzzie> i think totsc increases the pathfinder node count
[17:16:16] <lynxlynxlynx> in bg2 it is user-editable
[17:16:25] <fuzzie> i wonder what it means, i guess they do A* or something
[17:21:34] <Avenger> isn't it the maximum distance?
[17:21:49] <Avenger> we also have such a value
[17:22:03] <Avenger> if you increase it, it takes up more time, but finds longer paths
[17:23:28] <fuzzie> it is presumably the maximum number of tiles visited
[17:24:57] <lynxlynxlynx> it's high number, 40k iirc
[17:25:58] <fuzzie> i'm just thinking that our pathfinder is probably really slow
[17:26:03] <Avenger> we have a theoretical maximum of 64k
[17:26:04] <fuzzie> just doesn't matter on modern machines
[17:26:13] <Avenger> as long as we store the cost on a word
[17:26:53] <fuzzie> oh drat, the visibiity code is still broken :( i forgot abotu that
[17:48:02] <Avenger> ok, bashdoor success : gets the bend_bars values from strmod/strextra.2da then rolls 1d10 and adds that too
[17:48:09] <Avenger> the roll is a luck adjusted roll
[17:48:25] <Avenger> that is 1d10+luck (if > 10 then maximum 10)
[17:48:49] <Avenger> we need this luck adjusted roll in core, it is used in many places
[17:49:04] <Avenger> it sets the minimum value to x
[17:49:47] <lynxlynxlynx> we already have it
[17:49:55] <lynxlynxlynx> Actor::LuckyRoll
[17:50:20] <Avenger> then it compares this adjusted bend bars to the lock removal difficulty of the door/container
[17:50:28] <Avenger> oh cool
[17:50:43] <Avenger> then you probably can do the luck check from what i just said
[17:50:54] <lynxlynxlynx> the luck check is inherent
[17:51:40] <Avenger> that's fine, as far as i seen it is always adjusted by luck
[17:52:51] <Avenger> lol, i found the code where items break
[17:53:08] <Avenger> the whole code is still in bg2, there is just an if(0) ...
[17:53:39] <Avenger> a single byte written back to 0 could bring back the iron plague in bg2
[17:54:18] <Avenger> well, anyway, the chance to break a weapon in bg1 is 5 in 1000, but if you have luck>5 it never happens
[17:55:06] <Avenger> hmm, here i see an instance where luck decreases the roll
[17:55:57] <lynxlynxlynx> we use 1% for that
[17:56:43] <Avenger> well then we have double the chance than should
[17:56:57] <lynxlynxlynx> yep, it was just a guess
[17:57:26] <Avenger> ok, this negative luck could probably be ignored. it just rolls d100 subtracts luck, then checks if it is 100
[17:57:45] <Avenger> the same would be accomplished by rolling 100 adding luck and checking if it is 0
[17:58:26] <Avenger> for damage: it adds damageluck and luck for the adjustment
[17:58:43] <lynxlynxlynx> we handle negative luck btw
[17:59:06] <lynxlynxlynx> for damage: both increase it? we only use one now
[17:59:58] <Avenger> yes
[18:00:05] <lynxlynxlynx> ok
[18:00:16] <fuzzie> huh, luck is typically below 5?
[18:01:15] <Avenger> well, i don't know what sets it
[18:01:32] <fuzzie> in bg1, just effects, i think. lynx?
[18:01:36] <Avenger> until recently i ignored luck totally, but it turns out it is the best stat :)
[18:01:47] <lynxlynxlynx> yep
[18:02:01] <lynxlynxlynx> fuzzie: no idea
[18:02:33] <fuzzie> i know someone pasted a list of what luck affected in pst, and it was best summarised as "everything"
[18:02:37] <Avenger> power word stun uses luck, but changes it a bit
[18:02:51] <lynxlynxlynx> oh, i have a snippet for this laying around
[18:03:02] <lynxlynxlynx> not ideal or it would be in the tree
[18:03:17] <lynxlynxlynx> svn days
[18:03:56] <lynxlynxlynx> http://pastebin.ca/1949077 only related to a resistance check though
[18:04:09] <Avenger> yeah fuzzie, there are 26 luck adjusted rolls in bg2
[18:04:10] <lynxlynxlynx> we already do a couple of lucky rolls
[18:04:27] <lynxlynxlynx> 6
[18:04:54] <Avenger> but it is a bit an overstatement, pw stun has 3 of those
[18:05:44] <Avenger> even heal uses it
[18:06:31] <CIA-93> GemRB: 03lynxlupodian * r0dfa98fd5978 10gemrb/gemrb/core/Scriptable/Actor.cpp: weapon breaking chance is 0,5% not 1%
[18:07:15] <Avenger> hmm heal increases the dice rolls based on target luck, damage decreases it
[18:10:09] <Avenger> ok, all calls to this rolldice function uses luck in one way or another, but sometimes it is negative or adjusted.
[18:16:40] <lynxlynxlynx> no problem
[18:19:21] <-- deepinthewoods has left IRC (Read error: Connection reset by peer)
[18:20:41] <Avenger> lynx, maybe it would be easier to call the dice roll calculations in the few functions that use it
[18:21:16] <Avenger> since we cannot simply use that stuff in pastebin, as it would always increase the rolls
[18:21:32] <Avenger> it wouldn't decrease the damage on lucky victims
[18:21:55] <fuzzie> not easier just to make two tables?
[18:22:15] <Avenger> well, probably not
[18:22:30] <lynxlynxlynx> it would
[18:22:47] <Avenger> but what if i find a 3rd type of dice roll usage
[18:22:53] <lynxlynxlynx> the roll takes the target and uses the difference of the stats as the luck to use
[18:22:53] <Avenger> then a 4th :)
[18:22:55] <fuzzie> then we make it a table with a flag :P
[18:23:27] <Avenger> ok, i don't really care as long as it works
[18:24:03] <Avenger> i finished peering at disassembly for today
[18:24:38] <Avenger> will someone do the bash door check?
[18:24:57] <lynxlynxlynx> tommorow
[18:25:06] <lynxlynxlynx> still fighting stores
[18:25:34] <Avenger> ok
[18:25:36] <-- Avenger has left IRC (Quit: ChatZilla 0.9.86 [Firefox 3.6.10/20100914125854])
[18:28:14] --> tomprince has joined #GemRb
[18:37:47] --> Avenger has joined #GemRb
[18:37:47] --- ChanServ gives channel operator status to Avenger
[18:38:28] <Avenger> hmm, there was a question about default scrollbars. Looks like the engine is very clever here, the default scrollbar (for mousewheel) is the nearest scrollbar :)
[18:39:03] <Avenger> it works very nicely in stores, if my mouse is on the left side, it handles the left scrollbar, if it is on the right side, it moves the right scrollbar
[18:39:11] <Avenger> regardless of which was active last or such
[18:40:04] <fuzzie> heh
[19:37:12] <-- Avenger has left IRC (Quit: ChatZilla 0.9.86 [Firefox 3.6.10/20100914125854])
[20:11:24] <lynxlynxlynx> in hindsight, the STOImporter::GetItem change for random items looks bad
[20:12:09] <lynxlynxlynx> the items are not compatible, so we can't just expect all the fields to match
[20:24:58] <lynxlynxlynx> or not :|
[20:25:25] <lynxlynxlynx> but for some reason, store items have whacko flags now
[20:25:33] <lynxlynxlynx> forgot the simplest way to check
[20:27:22] <lynxlynxlynx> ok, it's from somewhere else
[20:29:00] <lynxlynxlynx> and then a cruel realisation that this is about inventory items, not store items >>
[20:49:03] <lynxlynxlynx> bleh
[20:49:22] <lynxlynxlynx> better call it a night
[20:54:29] <CIA-93> GemRB: 03avenger_teambg * rb437ced52a21 10gemrb/gemrb/core/Item.h: added item bit definitions specified by modders
[22:11:31] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[22:23:19] --> _pickle has joined #GemRb
[22:31:31] <-- SiENcE has left IRC (Ping timeout: 240 seconds)
[23:42:00] <-- _pickle has left IRC (Remote host closed the connection)
[23:54:10] <-- Maighstir has left #GemRb