#gemrb@irc.freenode.net logs for 1 Aug 2009 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage

[00:38:26] <pupnik> ni
[01:55:02] <-- barra_away has left IRC (Read error: 104 (Connection reset by peer))
[03:36:55] <-- tombhadAC has left IRC (Remote closed the connection)
[07:34:18] --> Avenger has joined #gemrb
[07:34:42] --- ChanServ gives channel operator status to Avenger
[07:34:52] <Avenger> hi
[07:58:22] --> lynxlynxlynx has joined #gemrb
[07:58:23] --- ChanServ gives channel operator status to lynxlynxlynx
[08:16:58] <lynxlynxlynx> gmornin
[08:26:10] <-- Gekz has left IRC ("leaving")
[08:30:25] --> Gekz has joined #GemRB
[08:58:50] <lynxlynxlynx> Avenger: btw, my old dltcep doesn't find any items with item type 38 (familiars and others)
[08:59:20] <Avenger> maybe you filter original items
[08:59:40] <Avenger> there is an option to skip biffed files
[09:00:54] <lynxlynxlynx> that was it, yes
[09:01:23] <lynxlynxlynx> only familiars in bg2
[09:01:32] <Avenger> FAMFAI25
[09:01:34] <Avenger> Found 0x26-Broken sword/Earring/Familiar
[09:01:45] <Avenger> new dltcep will call them familiar too
[09:02:26] <fuzzie> yes, i changed that one to FAMILIAR in our itemtype.2da a while ago after checking
[09:02:44] <fuzzie> i don't know what to call 0x25 though, it's BOOK in itemtype.2da but i think it's used for other things too?
[09:03:10] <fuzzie> what does new dltcep say for it?
[09:03:13] <Avenger> it is irrelevant how we call them there, that's just a 'label'
[09:03:38] <fuzzie> it is helpful for not being confusing, that is all :)
[09:03:44] <Avenger> i could add book to it
[09:03:52] <Avenger> but 0x00 is also used for books
[09:03:55] <Avenger> in the same game
[09:04:11] <Avenger> i added familiar because it is very special, and in bg2 it is used only for familiars
[09:04:19] <fuzzie> ok.
[09:04:21] <lynxlynxlynx> http://forums.gibberlings3.net/index.php?showtopic=7457 <-- here is some bg info on it
[09:04:33] <Avenger> yes i read that, again :)
[09:05:21] <Avenger> we can change bag to container, and 0x25 to book, if 0x00 is misc
[09:05:30] <Avenger> if that's what you want
[09:05:30] <fuzzie> oh, it is nice to have confirmation of that Uses Key flag
[09:05:34] <Avenger> but it is bg2 specific
[09:05:43] <Avenger> i meant the itemtype names
[09:05:48] <fuzzie> i forget if i changed that in gemrb, but it leads to game breaking
[09:06:38] <Avenger> both ways: keep key when game intended to remove it, or destroy key when game didn't intend to remove it could be game breaker
[09:07:07] <Avenger> so we need to implement this carefully
[09:07:11] <fuzzie> looks like I only fixed it for PS:T and not BG1, so that is something to keep in mind.
[09:07:51] <Avenger> well, one thing: if the original game doesn't use a feature, just implements it, it has lower priority
[09:08:16] <Avenger> i understood those notes that the key itemtype isn't used by bg1
[09:08:37] <fuzzie> the key itemtype is not used by anything in-game, no
[09:09:38] <Avenger> if bg1 has no 'remove key' bits set anywhere, we can still remove the key
[09:10:02] <fuzzie> from memory, there was a 'remove key' bit set somewhere :(
[09:10:09] <fuzzie> but i will check with ie_shell later
[09:10:16] <Avenger> oh that broke something, i guess
[09:11:30] <fuzzie> and the DOOR_KEY flag is set on lots of PS:T doors, i wonder what it means
[09:14:03] <Avenger> meh
[09:15:36] <fuzzie> anyway, good morning :) will you add the code for the PS:T death variable handling?
[09:21:47] <fuzzie> Qwinn's summary agrees that the handling is only done in Die(), so it can presumably just go there with the existing ones
[09:25:51] <Avenger> please do it, if you can
[09:26:09] <Avenger> i want to jump into pst projectiles
[09:26:33] <fuzzie> oh, that would be wonderful!
[09:26:45] <Avenger> is this place where one could get ida pro? --> http://www.hex-rays.com/idapro/idadownfreeware.htm
[09:27:01] <fuzzie> that's the one i'm using, yes
[09:29:35] <fuzzie> it took an hour or so to finish analyzing torment here, i think because there are some huge jump tables
[09:41:54] <Avenger> hmm, did you find where the projectile code is, by chance? :)
[09:43:10] <fuzzie> sorry, I was just looking at the effects myself :/
[09:44:47] <Avenger> np
[09:44:50] <-- Avenger has left IRC ("bye!")
[09:47:29] <lynxlynxlynx> the ground pile copy doesn't work due to the sender not being an area
[09:47:50] <lynxlynxlynx> http://pastebin.ca/1514692
[09:48:49] <lynxlynxlynx> it's the protagonist
[09:53:29] <lynxlynxlynx> trying with GetCurrentArea()
[10:03:40] <lynxlynxlynx> worked like a charm :)
[10:06:08] <CIA-22> gemrb: 03lynxlupodian * r6770 10/gemrb/trunk/gemrb/plugins/Core/Actions.cpp: made CopyGroundPilesTo accept actors too, so now the first tob use works
[10:09:20] --> barra_away has joined #gemrb
[10:09:28] <fuzzie> ah, great :)
[10:17:24] --> zefklop has joined #gemrb
[10:26:23] <-- barra__out has left IRC (Read error: 110 (Connection timed out))
[10:30:21] <Gekz> fuzzie: I found ToB on my mac drive
[10:30:27] <Gekz> so I have SoA and ToB guaranteed
[10:30:28] <Gekz> :D
[10:33:30] <fuzzie> i wonder if the multiplayer would be easier to analyse in the mac one..
[10:34:28] <Gekz> it is ppc
[10:34:38] <Gekz> and I dont know if its compatible with the pc one
[10:34:42] <fuzzie> it isn't
[10:35:55] <fuzzie> but it would be interesting to see what goes over the network, to get an idea of how it works - the networking code is the same in both
[10:36:30] <Gekz> I see
[10:38:23] <fuzzie> just the pc one uses directx, which is a pain to decode :(
[10:46:46] --> dawid has joined #GemRb
[10:51:38] <Gekz> ew.
[11:02:44] <CIA-22> gemrb: 03lynxlupodian * r6771 10/gemrb/trunk/gemrb/plugins/GUIScript/GUIScript.cpp: fixed container item's tooltips (now shows the proper name)
[11:06:50] <CIA-22> gemrb: 03lynxlupodian * r6772 10/gemrb/trunk/gemrb/plugins/GUIScript/GUIScript.cpp: removed unnecessary casts from the end of GemRB_GetContainerItem
[11:24:22] --> Avenger has joined #gemrb
[11:24:52] <Avenger> lynx, what about always using Sender->GetCurrentArea() in copygroundpilesto ?
[11:25:27] <lynxlynxlynx> i don't know of any use, so i just added the actor
[11:25:37] <fuzzie> that sounds like it'd work fine though
[11:25:48] <Avenger> that seems to be simple, and useful, and most likely always doing the thing the writer would want
[11:25:49] <fuzzie> i keep forgetting you can just use GetCurrentArea() on an area too
[11:25:57] <Avenger> yep :)
[11:26:10] <lynxlynxlynx> fuzzie: can you grep through your decompiled scripts for copygroundpilesto?
[11:26:12] <Avenger> and it would work in the global script or, whatever
[11:26:18] <fuzzie> sure
[11:26:55] <Avenger> doh, i forgot to switch to windows
[11:26:57] <-- Avenger has left IRC (Client Quit)
[11:26:58] <fuzzie> they're all in cutscenes: cut205a, cut30a, cut41r, cut57c and cut86a
[11:27:34] <fuzzie> all from actors, and i don't have the dialogs extracted but they'd also be all from actors
[11:27:51] <lynxlynxlynx> ok, thanks (that was fast :))
[11:31:53] <fuzzie> decompiling all the scripts turned out to be really convenient :)
[11:42:41] <Gekz> make a loot all button
[11:42:47] <Gekz> lol.
[11:44:20] <Gekz> fuzzie: tarball them
[11:44:23] <Gekz> for the good of us all>
[11:44:28] <Gekz> ?*
[11:51:00] <fuzzie> http://fuzzie.org/nfs/gemrb/baf.tar.bz2 but it's easy enough to make yourself :)
[11:54:57] <Gekz> nah
[11:55:05] <Gekz> does fuzzie.org point to your home system?
[11:55:38] <fuzzie> it points to a shared box here
[11:55:54] <fuzzie> so the nfs/ is something i can write to from my machine, over the network
[11:59:33] <fuzzie> it's not very fast (student building, people always using the connection) but it's easier for small files than uploading it somewhere useful :)
[12:00:01] <Gekz> well I could get you hosting if you needed
[12:00:04] <Gekz> with ssh access
[12:00:06] <Gekz> on dreamhost
[12:02:26] <fuzzie> i have a better-connected machine for permanent hosting (i'm using it to irc), i'm just lazy :) thanks though
[12:03:06] <lynxlynxlynx> ssh, nice
[12:56:09] --> Cable_ has joined #gemrb
[12:56:52] <-- |Cable| has left IRC (Read error: 104 (Connection reset by peer))
[13:26:30] --> tombhadAC has joined #gemrb
[13:38:59] <-- dawid has left IRC (Read error: 110 (Connection timed out))
[13:45:41] --> dawid has joined #GemRb
[13:50:16] <CIA-22> gemrb: 03lynxlupodian * r6773 10/gemrb/trunk/gemrb/plugins/Core/Actions.cpp: simplified CopyGroundPilesTo by always using Sender->GetCurrentArea()
[13:51:33] <CIA-22> gemrb: 03lynxlupodian * r6774 10/gemrb/trunk/gemrb/ (4 files in 2 dirs): fixed last uses of GetText vs QueryText (mostly docs)
[13:54:31] <CIA-22> gemrb: 03lynxlupodian * r6775 10/gemrb/trunk/gemrb/docs/en/GUIScript/ (19 files): fixed doc interlinking and added a stub for the missing SetPlayerString
[13:56:27] <fuzzie> familar packing does GiveItemCreate("FAMFAIR",Player1,0,0,0)
[13:56:34] <fuzzie> so i guess our Player1, Player2 etc functions are broken?
[13:57:39] <lynxlynxlynx> only the protagonist can have a familiar
[13:57:48] <fuzzie> yes indeed, Player1 returns the first portrait
[13:57:54] <fuzzie> using FindPC and not GetPC
[13:57:57] <fuzzie> i guess that must be wrong
[13:58:08] <lynxlynxlynx> as you describe it, yes
[13:59:40] <fuzzie> Player1Fill is meant to return first portrait slot, Player1 first player
[13:59:46] <fuzzie> gemrb seems to have them the wrong way around
[14:00:21] <fuzzie> it has Player1 calling FindPC(1) which searches by InParty, and Player1Fill calling GetPC(0,false) which returns the first entry in the player list
[14:00:28] <fuzzie> so that might explain quite a few bugs :)
[14:00:59] <fuzzie> i noticed previously that GameControl.cpp has a "FindPC(1); //protagonist" which is clearly wrong also for the same reason
[14:13:40] <-- Cable_ has left IRC ("Leaving")
[14:13:56] --> |Cable| has joined #gemrb
[14:14:26] <fuzzie> the GetPC code seems to date back to revision 714 and the Player1 calls back pretty far too, so I will assume I don't miss anything and change it all
[14:18:57] <CIA-22> gemrb: 03lynxlupodian * r6776 10/gemrb/trunk/admin/check_gui_doc.pl: check_gui_doc.pl: print the description part used for the hash for new files
[14:19:10] <lynxlynxlynx> the only catch is that some methods may be using the correct one by virtue of testing and not correctness
[14:19:58] <fuzzie> Interface.cpp:605 may also be nonsense, it says 'switch map to protagonist' but then picks the first portrait
[14:20:00] <CIA-22> gemrb: 03lynxlupodian * r6777 10/gemrb/trunk/gemrb/docs/en/GUIScript/SetPlayerSound.txt: SetPlayerPortrait doesn't exist
[14:26:01] <CIA-22> gemrb: 03fuzzie * r6778 10/gemrb/trunk/gemrb/plugins/Core/ (5 files): fix some apparent GetPC/FindPC mix-ups
[14:26:16] <fuzzie> Now packed familiars always end up in the protagonist's inventory, amongst a whole bunch of other fixes .. but since no-one seems to have noticed it before, perhaps I've missed behaviour differences in another game.
[14:32:47] <lynxlynxlynx> familiars are only in bg2 and maybe iwd2
[14:33:03] <fuzzie> the fix was changing 'Player1', which is kind of used everywhere :)
[14:33:09] <lynxlynxlynx> you can't summon them, so it is hard to notice other failures ;)
[14:33:37] <fuzzie> I did some quick checks in bg1, bg2 and iwd2, but it's sort of difficult to believe that no-one would have noticed that Player1 was returning the wrong actor before now. :P
[14:33:46] <lynxlynxlynx> hmm, i'm not sure, but i don't think familiars will talk to anyone but their master
[14:34:27] <fuzzie> yes, the dialog is hardcoded to reject you unless InPartySlot(LastTalkedToBy,0) is true
[14:34:44] <fuzzie> that bit was working fine
[14:35:23] <fuzzie> the rest of the familiar stuff is working fine too now, I'm just worried about all the other scripts :)
[14:36:57] <lynxlynxlynx> you still can't summon or release them though
[14:37:14] <lynxlynxlynx> maybe you fixed the summoning with this, but releasing definitely not
[14:37:33] <fuzzie> i think we are simply missing the code for those
[14:38:20] <lynxlynxlynx> releasing: yes, summoning: partly
[14:46:50] <fuzzie> what goes wrong with summoning? fx_find_familiar looks fairly complete
[14:46:55] <fuzzie> i guess i'll take a look after dinner :) bye
[14:48:36] <lynxlynxlynx> didn't investigate, bye
[15:02:12] <CIA-22> gemrb: 03lynxlupodian * r6779 10/gemrb/trunk/admin/check_gui_doc.pl:
[15:02:12] <CIA-22> gemrb: check_gui_doc.pl: fixed overzealous scoping eating up the description;
[15:02:12] <CIA-22> gemrb: the md5 is still only computed from the last line
[15:12:53] <CIA-22> gemrb: 03lynxlupodian * r6780 10/gemrb/trunk/admin/guidoc_wikifier.sh:
[15:12:53] <CIA-22> gemrb: added guidoc_wikifier.sh, a script which was used for the wikification of
[15:12:53] <CIA-22> gemrb: the guiscript docs; this is an improved version (the wiki will be updated later)
[15:18:08] --- barra_away is now known as barra_home
[15:33:09] <CIA-22> gemrb: 03zefklop * r6781 10/gemrb/trunk/CMakeLists.txt: OpenAL is not mandatory, even if having no sound is sad...
[15:40:16] <lynxlynxlynx> maybe we should recommend openal-soft instead
[15:43:34] <zefklop> you mean, openal-soft.org instead of openal.org ?
[15:43:50] <zefklop> in the error message
[15:46:16] <zefklop> BTW, is zlib mandatory?
[15:49:12] <fuzzie> i believe so, yes
[15:49:46] <fuzzie> otherwise you cannot load/save games, for example
[15:50:15] <zefklop> so I should upgrade the zlib dependance then
[15:50:29] <zefklop> lynxlynxlynx: openal-soft sounds nice
[15:51:06] <zefklop> as sound effects would be very nice
[15:51:33] <lynxlynxlynx> it is maintained :)
[15:51:41] <lynxlynxlynx> and they started adding eax support too
[15:51:44] <zefklop> it seems yes :-)
[15:52:20] <fuzzie> well, base openal is pretty well-maintained on windows :)
[15:53:46] <zefklop> yes, but EAX has been asked on forum, and I think it is a good request
[15:54:42] <fuzzie> i wonder if you can build against openal-soft on windows, but still use the hardware EAX openal if present
[15:57:58] <fuzzie> looks like openal-soft doesn't even install the effect headers
[15:58:10] <fuzzie> strange, i wonder how it works
[16:01:20] <zefklop> they don't provide development files :-(
[16:58:00] <CIA-22> gemrb: 03lynxlupodian * r6782 10/gemrb/trunk/gemrb/docs/en/GUIScript/ (24 files): added all the missing guiscript method doc stubs
[16:58:33] <CIA-22> gemrb: 03lynxlupodian * r6783 10/gemrb/trunk/gemrb/docs/en/GUIScript/ (22 files): enriched the new doc stubs :)
[16:59:03] <CIA-22> gemrb: 03lynxlupodian * r6784 10/gemrb/trunk/gemrb/plugins/GUIScript/GUIScript.cpp: fixed a few syntax errors in two original script docs
[17:01:05] <CIA-22> gemrb: 03lynxlupodian * r6785 10/gemrb/trunk/admin/guidoc_wikifier.sh: added missing license header to guidoc_wikifier.sh
[17:03:03] <CIA-22> gemrb: 03lynxlupodian * r6786 10/gemrb/trunk/ (TODO admin/add_missing_gui_docs.sh): added script that creates missing guiscript docs (more like good stubs)
[17:03:16] <lynxlynxlynx> grrr
[17:03:20] <lynxlynxlynx> forgot to save
[17:04:00] <CIA-22> gemrb: 03lynxlupodian * r6787 10/gemrb/trunk/admin/add_missing_gui_docs.sh: grr, forgot the license again
[17:18:30] --> barra_away has joined #gemrb
[17:28:48] <zefklop> ouch fog of war is broken in BG1
[17:35:07] <zefklop> I think we should take the camera angle when calculating this
[17:35:12] <-- barra_home has left IRC (Read error: 110 (Connection timed out))
[17:47:24] --> D_T_G has joined #gemrb
[17:47:36] <D_T_G> hi
[17:47:56] <D_T_G> amazing, svn was silent for so long but recently so many commits :)
[17:50:01] --- D_T_G is now known as D_T_G_away
[17:53:07] <fuzzie> zefklop: you can see fog-of-war is especially broken in some outside areas :(
[17:53:43] <zefklop> even in inside areas
[17:53:52] <zefklop> :-(
[17:54:50] <fuzzie> but i think some of it is maybe game-specific: i noticed in pst that you can see right through walls sometimes, but never through closed doors, maybe a polygon thing
[17:54:55] <zefklop> the fact is that characters are much taller in BG1, so they don't have their eyes in the same place than BG2
[17:54:59] <fuzzie> but if you have any ideas then it sounds good :)
[17:56:06] <zefklop> yeah, I have some ideas...
[17:56:38] <zefklop> I'll have a look to commit logs, when I fixed it on BG2 and broke it on BG1
[18:07:09] --> zefklop_ has joined #gemrb
[18:11:54] <fuzzie> well, it is awfully broken in some places in BG2 also
[18:12:12] <fuzzie> but i really have no clue how it is meant to work, maybe that is a completely different thing
[18:21:51] <-- zefklop has left IRC (Read error: 113 (No route to host))
[18:36:46] --- D_T_G_away is now known as D_T_G
[18:39:11] <D_T_G> do you know this bug that when you for the first time click sleep button in irenicus dungeon when you have open inventory window Imoen's dialogue that triggers after it totally breaks the gui?
[18:39:12] <fuzzie> D_T_G: is the combined patch linked from the forum finished?
[18:39:24] <D_T_G> which patch?
[18:39:41] <fuzzie> the guienhancements for mage/priest spellbooks
[18:39:49] <D_T_G> yes it's finished
[18:40:22] <fuzzie> i never saw that bug in particular, but dialogue triggering can break the gui often - for example if you're viewing your inventory at the time.
[18:40:34] <D_T_G> yes, that's the one
[18:40:43] <fuzzie> i think that is all in python if you want to look
[18:40:49] <D_T_G> and you have to kill gemrb to fix the gui
[18:41:18] <fuzzie> when dialog is displayed, the python scripts should be forcibly switching back to the main gui first, if it's not there already
[18:41:32] <D_T_G> the output was saying something about a missing function return_to_main or sth like that
[18:41:57] <D_T_G> but normally this function works
[18:42:26] <D_T_G> and about gui enhancements in spell books
[18:42:44] <D_T_G> what about creating new bams for it for better look?
[18:43:22] <D_T_G> the silver background does not look too good
[18:43:50] <lynxlynxlynx> go ahead :)
[18:44:06] <fuzzie> it's trivial to make bams and check for them from the code if someone makes the graphics
[18:44:11] <D_T_G> i'm not best painter :)
[18:44:12] <lynxlynxlynx> ReturnToGame is a mistery to me
[18:44:17] <fuzzie> i would ask on the forums
[18:44:31] <D_T_G> and i think it would be illegal to just remake the bams from game's resources
[18:44:48] <lynxlynxlynx> works most of the time, but isn't defined anywhere in our code?!
[18:47:07] <D_T_G> you have some weird graphics in some of gemrb's overrides
[18:47:13] <D_T_G> colour palletes?
[18:49:07] <fuzzie> ReturnToGame never works
[18:49:25] <fuzzie> but that doesn't matter, as long as the code doesn't have bugs
[18:53:18] <fuzzie> since it should only be overlaying on top of the main game screen anyway..
[18:54:31] <D_T_G> the dialog itself does not trigget ReturnToGame but clicking "return to game" button in broken gui caused by it
[18:54:51] <fuzzie> that happens also if you click "return to game" from the normal game view
[18:55:41] <D_T_G> yes, i see it
[18:55:54] <fuzzie> so it is normal! it just thinks it already changed to the normal game view
[18:57:09] <D_T_G> is it really coded in guiscripts? i would imagine faster it in game scripts
[18:57:38] <D_T_G> from there the dialog is fired i guess
[18:58:03] <lynxlynxlynx> she was talking about ReturnToGame
[18:58:41] <fuzzie> it does seem that the game scripts handle the show/hide logic here, though..
[18:58:49] <fuzzie> i mean, the guiscripts
[18:59:47] <D_T_G> ok, so when the dialog fires the guiscript should recognise it and properly 'return to game window' from all other windows properly
[18:59:51] <D_T_G> ?
[19:00:02] <fuzzie> the gemrb core has HideGUI() and UnhideGUI(), and knows to check MessageWindow for the window id..
[19:00:50] <fuzzie> otherwise it just calls OpenContinueMessageWindow, which is in GUIWORLD.py
[19:01:05] <fuzzie> or OpenEndMessageWindow if that is the appropriate call
[19:03:22] <D_T_G> oh, you know all that better :)
[19:03:39] <fuzzie> well, i know this from the C++ side because it is complicated to make work :)
[19:03:46] <fuzzie> but i don't have any idea about the python side
[19:03:52] <D_T_G> btw, that's odd, no wine biweekly release yesterday
[19:04:01] <fuzzie> perhaps you could change the functions to 'print' a debug, just to make sure i am right and they get called?
[19:04:49] <fuzzie> and if they do get called, maybe try fixing it for one window - for instance, if GUIPR.PriestWindow is set, then you have to call GUIPR.OpenPriestWindow() which will close it
[19:05:09] <fuzzie> i'm not sure how to do it properly though, maybe lynxlynxlynx has a thought if that idea works
[19:06:14] <lynxlynxlynx> D_T_G: i bet aj is on vacation
[19:07:25] <lynxlynxlynx> re windowing: these are things i try to avoid :)
[19:09:19] <fuzzie> i think probably you want to have a shared 'CloseCurrentWindow' variable in GUICommon, which is set to the relevant function when a window is opened and set to None when a window is closed
[19:09:20] <D_T_G> well, in guipr i see "if CloseOtherWindow (OpenPriestWindow):", maybe in main game window it should be checked too
[19:09:55] <fuzzie> D_T_G: i think you must actually call the function, some of them do different things to close themselves
[19:10:54] <fuzzie> but if you simply do 'GUICommon.CloseCurrentWindow = OpenPriestWindow' in OpenPriestWindow, then 'GUICommon.CloseCurrentWindow = None' when closing it, you can simply do 'if GUICommon.CloseCurrentWindow: GUICommon.CloseCurrentWindow()' in the dialog functions
[19:11:05] <fuzzie> and then hopefully everything should work by magic
[19:12:24] <fuzzie> well, most of it - maybe you have to have it twice, because when a store window closes it can re-open the inventory :)
[19:12:54] <fuzzie> in fact i can see a lot of circumstances in which it's quite complicated to close windows but I am hoping it will all work..
[19:13:22] <fuzzie> i think it is worth a try to fix it without writing specific code for every window, though!
[19:13:52] <D_T_G> i'm hoping i will eventually understand all you write :)
[19:14:17] <D_T_G> maybe i'm not at best condition to think today
[19:14:52] <D_T_G> eventhough 2 beers are not that much
[19:16:18] <fuzzie> well, there is no rush :)
[19:18:04] <D_T_G> do you plan any round release in near future too?
[19:19:42] <lynxlynxlynx> round as in point0? no
[19:20:24] <lynxlynxlynx> progress is back to normal ;)
[19:23:04] <D_T_G> yes svn commits are a reall thing that attract my attention :)
[19:23:45] <fuzzie> in a new game, i can summon a familiar and then pack it, it seems to work ok
[19:23:52] <D_T_G> releases are more like an advert for wider attention
[19:24:03] <fuzzie> no releasing, but that should be simple, maybe even in guiscript
[19:24:43] <D_T_G> last time i tried summon familiar spell worked but familiar landed in wrong inventeory
[19:24:49] <fuzzie> i fixed that now :)
[19:24:57] <D_T_G> cool :)
[19:31:09] <fuzzie> i wonder if Avenger has any luck with pst projectiles, they are the last huge thing, I think
[19:31:47] <D_T_G> all the rest would be small? :>
[19:33:43] <D_T_G> there's programmers' saying that last 1% of things takes 99% of time to implement :P
[19:34:30] <D_T_G> well, at least I read that 'true' in a few interviews ;)
[19:35:34] <D_T_G> nm, good luck ppl, bye
[19:35:41] <-- D_T_G has left IRC ()
[20:01:12] <-- lynxlynxlynx has left IRC (Remote closed the connection)
[20:14:23] <-- dawid has left IRC ("Not leaving, quitting.")
[20:17:52] --> dawid has joined #GemRb
[21:21:04] --> Avenger has joined #gemrb
[21:21:20] --- ChanServ gives channel operator status to Avenger
[21:21:56] <Avenger> i didn't know we missed so many guiscript doc files :)
[21:23:52] --> pupnik_ has joined #gemrb
[21:39:15] <CIA-22> gemrb: 03avenger_teambg * r6788 10/gemrb/trunk/gemrb/plugins/GUIScript/GUIScript.cpp: implemented SetPlayerString
[21:40:06] <-- pupnik has left IRC (Read error: 110 (Connection timed out))
[21:48:39] <CIA-22> gemrb: 03avenger_teambg * r6789 10/gemrb/trunk/gemrb/plugins/GUIScript/GUIScript.cpp: fixed a few NULL returns
[21:49:15] <CIA-22> gemrb: 03avenger_teambg * r6790 10/gemrb/trunk/gemrb/GUIScripts/bg2/GUIREC.py: using the correct params for SetPlayerString
[22:09:06] <-- Avenger has left IRC ("bye!")
[22:42:04] --- zefklop_ is now known as zefklop
[22:46:26] <-- zefklop has left IRC ("ChatZilla 0.9.85 [Firefox 3.0.8/2009032609]")
[22:57:55] <-- tombhadAC has left IRC (Remote closed the connection)