#gemrb@irc.freenode.net logs for 16 Jun 2009 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage

[01:57:43] --- barra_library is now known as barraAway
[02:40:32] <-- barraAway has left IRC (Read error: 104 (Connection reset by peer))
[02:40:58] <-- mattinm has left IRC (Remote closed the connection)
[05:36:20] <-- Gekz has left IRC (Read error: 104 (Connection reset by peer))
[05:59:05] --> Gekz has joined #GemRB
[06:33:49] <-- Gekz has left IRC (Read error: 104 (Connection reset by peer))
[06:37:20] --> Gekz has joined #GemRB
[06:45:26] <-- Gekz has left IRC (Read error: 104 (Connection reset by peer))
[06:45:44] --> Gekz has joined #GemRB
[06:47:20] --> lynxlynxlynx has joined #gemrb
[06:47:20] --- ChanServ gives channel operator status to lynxlynxlynx
[06:49:43] <fuzzie> morning, lynx
[06:50:52] <lynxlynxlynx> gmornin
[07:38:37] <-- |Cable| has left IRC ("Leaving")
[09:31:05] <fuzzie> And all done with the exam, hooray.
[09:44:37] <fuzzie> hm, iwd2 round times are certainly 7s (105/69h)
[09:45:22] <fuzzie> 4 seconds seems the most likely for pst but i'm still not sure
[10:04:14] <lynxlynxlynx> when did you decide against 2s for pst?
[10:04:53] <fuzzie> I tried it on a real computer (outside of a VM) and it wasn't quite as insanely fast.
[10:05:40] <lynxlynxlynx> ah
[10:05:49] <fuzzie> So I sat there with a stopwatch for a little bit :)
[10:06:15] <fuzzie> http://www.shsforums.net/index.php?showtopic=41127 summarises my thoughts.
[10:44:42] <fuzzie> hm, when fighting/talking to someone else, actors should really approach the nearest side, not the far one :)
[10:47:20] <lynxlynxlynx> and take movement into account, not first going to the first destination
[10:47:52] <lynxlynxlynx> sucks in the chasing sense
[10:48:04] <fuzzie> the elves in Saradush end up going to the temple entrance and then wandering off, I thought they were meant to go inside.
[10:52:44] <lynxlynxlynx> the ones you save? i think that too
[11:03:40] <fuzzie> I guess GameScript::EscapeArea doesn't calculate the exit.
[11:04:35] <fuzzie> So EscapeAreaCore tries moving to (0, 0) and the JumpToPoint action to jump areas never works.
[11:05:59] <fuzzie> This is probably a bug anyway, if the MoveToPoint fails then the PopNextAction() shouldn't be removing the JumpToPoint action here.
[11:08:22] --> barra_library has joined #gemrb
[13:58:37] <-- barra_library has left IRC ("Verlassend")
[15:29:32] <CIA-2> gemrb: 03lynxlupodian * r6473 10/gemrb/trunk/gemrb/plugins/Core/GameControl.cpp: made ESC reset the action bar
[15:30:42] <fuzzie> :)
[15:50:30] <CIA-2> gemrb: 03lynxlupodian * r6474 10/gemrb/trunk/gemrb/GUIScripts/bg2/GUIMA.py: bg2: allow escaping from the worldmap window
[15:51:29] <lynxlynxlynx> too lazy to fix half of the main windows
[15:51:48] <lynxlynxlynx> only half can be escaped
[15:52:24] <fuzzie> are they missing an esc handler or do they just not focus anything?
[15:52:36] <lynxlynxlynx> it's pretty trivial
[15:53:00] <lynxlynxlynx> the window closing is not in a separate method, so it can't be assigned to controls
[15:55:00] <lynxlynxlynx> but some of the working ones seem to work by accident
[15:56:12] <lynxlynxlynx> on to more interesting stuff ;)
[15:57:11] <fuzzie> The #1 thing bugging me right now is that the portraits aren't kept in sync.
[15:58:34] <lynxlynxlynx> when doing what?
[15:58:58] <fuzzie> when switching between screens
[15:59:01] <lynxlynxlynx> oh, you probably mean the one-copy-for-each-window thing
[15:59:04] <fuzzie> yeah
[15:59:05] <lynxlynxlynx> mhm
[15:59:51] <fuzzie> I guess we have to store the selected portrait in python somewhere, and reset it when switching to/from the main game view.
[16:00:12] <fuzzie> I tried implementing it by changing the selected actors in-game, but it turns out that that's not how it works, and doing it that way is actually fairly annoying. :/
[17:43:54] --> barra_library has joined #gemrb
[18:38:31] * fuzzie sighs
[18:38:43] <fuzzie> so, the dungeon-escape battle now abort()s on me
[18:39:05] <fuzzie> VHR2 Animation: unhandled stance: nshd 8
[18:40:52] <fuzzie> 8 being IE_ANI_SHOOT
[18:41:19] <fuzzie> (and NSHD being a shadow thief)
[18:44:08] <fuzzie> certainly NSHD has only G prefixes, and no G3
[18:44:22] <fuzzie> but I guess another thing to ask Avenger about.
[18:52:12] --> Edheldil has joined #gemrb
[18:52:12] --- ChanServ gives channel operator status to Edheldil
[19:02:36] <lynxlynxlynx> i found out why all the actors have the same speaker color
[19:02:48] <fuzzie> oh?
[19:03:11] <lynxlynxlynx> absurdly high indexes are passed around and in the end a check sanitizes all of them to 0
[19:05:05] --> barra_away has joined #gemrb
[19:05:38] <fuzzie> hm
[19:05:42] <fuzzie> i thought speaker colour was rgb.
[19:06:27] <lynxlynxlynx> it is, just all of them end up as the same color
[19:08:19] <fuzzie> the format string is %lX for the whole lot where it should be %lX%lX%lX for r/g/b?
[19:09:01] <fuzzie> does /any/ of that colour stuff work? it seems to all be %lX
[19:09:40] <lynxlynxlynx> i didn't even look at that, it is wrong on arrival
[19:10:07] <fuzzie> arrival where?
[19:10:58] <fuzzie> the IE_MAJOR_COLOR stat?
[19:11:16] <lynxlynxlynx> i'm still looking for the actual culprit, but i was trying to say that things go wrong before reaching the printing code
[19:11:47] <lynxlynxlynx> yeah, all of my npcs have it very high, but maybe only a single channel should be passed
[19:13:10] <lynxlynxlynx> not sure why Interface::GetSpeakerColor uses it for the index
[19:13:32] <lynxlynxlynx> it is a good seed for randomizing the colors, but it's not used correctly
[19:13:47] <fuzzie> Where is it even set? I don't see any occurances.
[19:14:25] <fuzzie> Oh, in guiscript.
[19:14:56] <lynxlynxlynx> this is the major clothing color
[19:16:15] <fuzzie> Does it work after chargen?
[19:16:37] <lynxlynxlynx> as opposed to loading? let me check
[19:16:48] <lynxlynxlynx> this is probably just stored in the cre
[19:17:03] <fuzzie> Well, it's stored in the CRE, and then the loader sets all the high bits..
[19:17:25] <fuzzie> with comment "apply RANDCOLR.2DA transformation"
[19:19:07] <lynxlynxlynx> chargen sets it nicely and changing it in the inventory works too
[19:19:15] <wjp> do you want an RGB color from IE_MAJOR_COLOR?
[19:19:19] <fuzzie> wjp: no
[19:19:43] <fuzzie> we want IE_MAJOR_COLOR to make sense itself :-)
[19:19:58] <lynxlynxlynx> the index must be lesser than the Height which is 120 (portrait?)
[19:20:00] <fuzzie> i think the code works fine once you set it, it looks it up in the palette
[19:20:15] <wjp> IE_MAJOR_COLOR consists of a couple of bytes
[19:20:17] <fuzzie> the problem is that the code is trying to store multiple colours in one stat entry
[19:20:17] <wjp> (IIRC)
[19:20:35] <lynxlynxlynx> yes, one per channel
[19:20:43] <wjp> channel?
[19:20:44] <fuzzie> "the colors are stored in 7 dwords", says Actor::SetColor, "maybe it would be simpler to store them in 28 bytes (without using stats?)"
[19:20:58] <fuzzie> lynxlynxlynx: no, the colours are bytes, palette indexes
[19:21:07] <lynxlynxlynx> oh
[19:23:13] <-- barra_library has left IRC (Read error: 110 (Connection timed out))
[19:23:54] <fuzzie> I guess the code is trying to do something clever with colours but it is beyond me. CREImp.cpp:442 seems to just duplicate the same colour in bits 9-16 and 17-24 of the stat dword.
[19:24:29] <wjp> hm, let me see if I can remember
[19:27:14] <wjp> I think they were for colours of equipped items
[19:27:36] <wjp> the values should be modified by effects
[19:28:35] <lynxlynxlynx> it is the clothing color, we even update the paperdoll correctly when changing it
[19:28:47] <fuzzie> lynxlynxlynx: the other code seems to be abusing it for other reasons, though
[19:29:30] <wjp> one of the bytes is clothing, the others are weapon, shield, helmet (I believe)
[19:29:56] <fuzzie> It looks like the CREImp code is never going to produce a valid value for clothing when a creature is loaded.
[19:29:57] <lynxlynxlynx> a hack would be to just mod the value with a small int when calling GetPallete
[19:30:19] <wjp> fuzzie: why?
[19:30:26] <lynxlynxlynx> but i'm looking only from the ingame perspective
[19:30:28] <fuzzie> wjp: Because it's meant to be a single byte.
[19:31:02] <wjp> 'meant' in which way?
[19:31:05] <fuzzie> lynxlynxlynx: Did you try '& 0xF'
[19:31:25] <fuzzie> wjp: Well, it's how it's stored and how a lot of the code assumes it *is*.
[19:31:25] <wjp> in the CRE you mean?
[19:31:52] <fuzzie> But that's all I mean, I don't mean we should start breaking gradient code!
[19:32:01] <fuzzie> Just that this isn't all consistent.
[19:32:03] <lynxlynxlynx> i haven't tried anything yet
[19:32:19] <wjp> I'm confused about what the problem is I think :-)
[19:32:37] <fuzzie> wjp: Various bits of code use IE_MAJOR_COLOR to fish out a palette index.
[19:32:59] <lynxlynxlynx> but it seems like the users are bad, not the stat
[19:33:00] <fuzzie> And this goes horribly wrong the moment that IE_MAJOR_COLOR gains high bits in that CRE loader code, or in SetGradient.
[19:33:00] <wjp> ah, those would need a & 0xFF
[19:33:08] <fuzzie> so, yes, sorry, I mean 0xff of course.
[19:33:20] <lynxlynxlynx> ok, i'll try it
[19:33:41] <wjp> let's see if I can find any documentation for (ab)using the stat like this
[19:33:56] <fuzzie> I guess the GUIScript should also be setting the high bits if the stat is abused like this globally?
[19:34:22] <lynxlynxlynx> out of chargen, the value is already big, so i think it is taken care of
[19:34:52] <wjp> I'm fairly sure I took care of that when I implemented equipment colouring, but I can't remember how
[19:35:19] <wjp> nov 2006 feels like a very long time ago :-)
[19:35:45] <fuzzie> the guiinv is certainly masking the colours with &0xFF
[19:36:54] <fuzzie> wjp: if you remember how this works, perhaps docs/en/Engine/Charcolors.txt would be a good place to note it
[19:36:55] <lynxlynxlynx> yep, works
[19:37:00] <wjp> ah, fun quotes: "Well the game files of BG are huge, but the engine is just simpl
[19:37:03] <wjp> e 2d, with very simple transparency... isn it?"
[19:37:17] <lynxlynxlynx> fun comments: /** No descriptions */
[19:40:49] <CIA-2> gemrb: 03lynxlupodian * r6475 10/gemrb/trunk/gemrb/plugins/Core/Interface.cpp: fixed GetSpeakerColor to not use a bad palette index (thanks to wjp and fuzzie)
[19:44:06] <fuzzie> that is *very* nice :)
[19:45:12] <CIA-2> gemrb: 03lynxlupodian * r6476 10/gemrb/trunk/gemrb/plugins/Core/Interface.cpp: don't duplicate GetSpeakerColor in DisplayStringName + removed dead code
[19:45:35] <lynxlynxlynx> i'm too excited, so i made another mistake
[19:46:30] --- barra_away is now known as barra_library
[19:46:57] <CIA-2> gemrb: 03wjpalenstijn * r6477 10/gemrb/trunk/gemrb/docs/en/Engine/Charcolors.txt: Elaborate on charcolors a little bit
[19:47:01] <CIA-2> gemrb: 03lynxlupodian * r6478 10/gemrb/trunk/gemrb/plugins/Core/Interface.cpp: oops, reinstate the stridx sanity check in DisplayStringName
[19:47:11] <fuzzie> wjp: thankyou
[19:47:30] <wjp> it's not much, but hopefully useful :-)
[20:11:12] --> danamin has joined #GemRB
[20:13:36] <lynxlynxlynx> i'm in another cre problem now
[20:13:45] <fuzzie> hi, danamin
[20:14:27] <lynxlynxlynx> some creatures don't get their StrRefs table filled and this is the reason why there is no death notification when you kill something
[20:14:50] <danamin> hi
[20:15:00] <lynxlynxlynx> oj
[20:15:36] <fuzzie> Maybe the CRE files don't have any strrefs and we're meant to fall back to defaults of some kind?
[20:15:54] <lynxlynxlynx> must be something like that, yes
[20:16:15] <lynxlynxlynx> only one from 100 of the strrefs is set and even that one is bad
[20:19:26] <lynxlynxlynx> ah
[20:20:01] <lynxlynxlynx> the strings are the same for everybody, i guess this is also in the cre format so critters can have individual sounds
[20:31:16] <danamin> Is there anything I could still do?
[20:31:56] <fuzzie> danamin: you looked at the not.applied.patch on sf?
[20:32:04] <danamin> briefly
[20:32:04] <lynxlynxlynx> did you read the comments? :)
[20:32:09] <danamin> no
[20:32:15] <lynxlynxlynx> there you go
[20:32:23] <fuzzie> the top comment has the problems we found, i think
[20:33:20] <lynxlynxlynx> i also suggest you svn up and enjoy the merge conflicts >>
[20:33:39] <fuzzie> well, the not.applied.patch should apply cleanly against svn, i think
[20:33:56] <danamin> where is the top comment?
[20:34:05] <lynxlynxlynx> yes, but clearing everything and applying that is just too easy ;)
[20:34:07] <fuzzie> danamin: "My observations so far" on the patch tracker page.
[20:35:07] <danamin> found it
[20:36:34] <fuzzie> basically, two simple things: the Import button should work, and the proficiency slot UI needs fixing.
[20:38:27] <fuzzie> I don't know if the proficiencies worked before lynx's merge, maybe it is our fault.
[20:38:39] <danamin> they didn't
[20:38:46] <danamin> Forgot to fix it
[20:40:00] <lynxlynxlynx> it's not a must
[20:40:12] <lynxlynxlynx> the first stage is to not introduce regressions
[20:40:22] <fuzzie> yes, i just mean the GUI bugs here :)
[20:40:36] <fuzzie> I am just comparing against our current bg1 chargen, that is all.
[20:40:43] <danamin> I'm hesitating to learn to work with GIT, you seem to use it, but I've never used it (I use HG)
[20:41:04] <lynxlynxlynx> we use svn
[20:41:14] <lynxlynxlynx> git is just enough of a bastard that it can also work with it
[20:41:45] <lynxlynxlynx> the patch can be applied without it, just use -p1
[20:42:16] <danamin> I know, but I'd like to savely store my version, so I don't lose anything
[20:42:33] <lynxlynxlynx> then just svn up and resolve all the conflicts
[20:42:44] <lynxlynxlynx> just heh
[20:42:48] <danamin> correct
[20:42:52] <fuzzie> You could just try copying the whole GUIScripts directory out of your working tree, for now.
[20:42:56] <lynxlynxlynx> svn actually has a nice merging interface
[20:43:12] <danamin> (stupid me, I like the complex solutions too much)
[20:43:40] <danamin> I assume that last one is ironic?
[20:43:52] <lynxlynxlynx> no
[20:44:05] <danamin> then where is the nice merging interfqce?
[20:44:10] <fuzzie> But I think the 'Import' button is important because it worked before and it is a bit complicated (it needs to skip steps, etc).
[20:44:31] <lynxlynxlynx> it may not support octopus or other wierd strategies, but when it comes to doing something about a conflict, you get plenty of shortcuts
[20:44:53] <lynxlynxlynx> it is brought up when you svn up ;)(
[20:45:06] <lynxlynxlynx> tf tf tf tf
[20:50:47] <CIA-2> gemrb: 03avenger_teambg * r6479 10/gemrb/trunk/gemrb/override/bg2/ (gemprjtl.ids invtrav.pro spmagmis.pro): multiple magic missiles and invisible traveling projectiles
[20:51:34] <lynxlynxlynx> :D
[20:54:46] <CIA-2> gemrb: 03avenger_teambg * r6480 10/gemrb/trunk/gemrb/plugins/PROImporter/PROImp.cpp: don't load unused extension type attribute
[20:56:10] <fuzzie> interesting, i cast Chromatic Orb and Imoen's action bar no longer likes me
[20:56:13] <CIA-2> gemrb: 03avenger_teambg * r6481 10/chitem/trunk/ (Chitem.h ProjGemRB.cpp ProjGemRB.h chitem.clw chitem.rc): new projectile flag (missile iteration) in dltcep
[20:56:26] <lynxlynxlynx> fuzzie: patched game?
[20:56:35] <fuzzie> no
[20:56:42] <lynxlynxlynx> the original had a buggy spell that held or charmed the caster instead of the target
[20:56:54] <fuzzie> heh.
[20:56:58] <lynxlynxlynx> i'd still check the description to see what it was trying to do at your level
[20:57:12] <fuzzie> it managed a Stun on the target
[20:57:27] --> Avenger has joined #gemrb
[20:57:31] <CIA-2> gemrb: 03avenger_teambg * r6482 10/gemrb/trunk/gemrb/docs/en/Engine/Projectile.txt: projectile flag doc
[20:57:37] <fuzzie> hi Avenger :)
[20:58:21] <lynxlynxlynx> wow, not a week has passed and we have another 100 revisions
[20:58:28] <Avenger> hi
[20:58:37] <CIA-2> gemrb: 03avenger_teambg * r6483 10/gemrb/trunk/gemrb/override/iwd/gemrb.ini: movie subtitle font in iwd
[20:58:39] <lynxlynxlynx> time for another tale
[20:58:44] <Avenger> hehe
[20:58:49] <fuzzie> Avenger: IE_ANI_SHOOT causes abort()s in CharAnimation, for example on a VHR2 character
[20:59:05] <fuzzie> could you look at that please? it confuses me :/
[20:59:18] <Avenger> huh
[20:59:46] <Avenger> lynx wait a bit
[20:59:48] <fuzzie> the abort() is in the default: of the switch, but i don't know what to do for that animation
[21:00:26] <lynxlynxlynx> Avenger: i'm in the middle of debugging, take your time
[21:00:57] <CIA-2> gemrb: 03avenger_teambg * r6484 10/gemrb/trunk/gemrb/plugins/Core/ (Projectile.cpp Projectile.h ProjectileServer.cpp):
[21:00:57] <CIA-2> gemrb: implemented projectile iteration flag (for magic missiles)
[21:00:57] <CIA-2> gemrb: removed unused attribute (type)
[21:00:58] <Avenger> hmm then vhr2 has no shooting animation
[21:01:05] <fuzzie> and some other animation types have the same problem with abort()ing for some animations (eg, AddFFSuffix, AddSixSuffix, etc)
[21:01:28] <Avenger> yes, i simply didn't find (or they dn't have) shooting animations
[21:01:31] <fuzzie> vhr2 seems not to, but it would be nice if we handled it properly
[21:01:38] <Avenger> imagine a rabbit with a bow :D
[21:01:58] <Avenger> yes it should fall back to normal attack
[21:02:02] <fuzzie> for example, shadow thieves (NSHD) are VHR2
[21:02:07] <Avenger> hmm
[21:02:20] <Avenger> ok
[21:02:22] <fuzzie> and this causes many abort()s in bg2.
[21:06:27] <CIA-2> gemrb: 03edheldil * r6485 10/ie_shell/trunk/infinity/ (4 files in 2 dirs): Added CRE V1.1 format
[21:11:49] <lynxlynxlynx> bah, this sucks, let's go play with magic missiles
[21:13:07] <CIA-2> gemrb: 03avenger_teambg * r6486 10/gemrb/trunk/gemrb/plugins/Core/CharAnimations.cpp: VHR2 animation types: added some animation for IE_ANI_SHOOT so it doesn't crash
[21:13:20] <fuzzie> thanks
[21:13:23] <Avenger> i'm not sure if this is the right animation sequence
[21:13:38] <fuzzie> i think sometime we must check all of the missing/unchecked ones, but not for me today
[21:13:46] <Avenger> yep
[21:13:57] <Avenger> also, the curved path in magic missile now waits you :)
[21:14:08] <Avenger> i've made the multiplication
[21:14:25] <Avenger> just curve their path, and it will be like the original
[21:17:47] <lynxlynxlynx> looks good already
[21:18:05] <fuzzie> what are the blue sprites?
[21:18:12] <lynxlynxlynx> i think the most difficult part will be making spell turning show the turning
[21:18:16] <fuzzie> endian thing or something unimplemented?
[21:18:38] <lynxlynxlynx> i see no blue sprites
[21:18:48] <lynxlynxlynx> only the pink mm stuff
[21:19:16] <lynxlynxlynx> aaah!
[21:19:50] <lynxlynxlynx> had to killdashnine gemrb
[21:20:11] <fuzzie> Avenger: what is displayed on those projectiles below the missile sprites itself, shadows or similar?
[21:20:13] <lynxlynxlynx> [GameScript]: Aborted action due to death[GameScript]: Aborted action due to death[GameScript]: Aborted action due <-- this got into an endless loop
[21:21:56] <fuzzie> strange.
[21:22:46] <fuzzie> in dialog, or in normal play?
[21:24:29] <lynxlynxlynx> play
[21:24:41] <lynxlynxlynx> kelsey used a sequencer on nalia, but it hit him instead
[21:24:54] <lynxlynxlynx> maybe killed him
[21:25:24] <lynxlynxlynx> so i wouldn't worry about the looping yet
[21:25:57] <fuzzie> Could be that there's a death script adding actions or something. Strange, though.
[21:30:29] <danamin> import works, shall I make another patch?
[21:30:55] <fuzzie> you fixed proficiencies UI too?
[21:31:00] <danamin> not yet
[21:31:19] <fuzzie> well, if you're done for today, another patch would be nice
[21:32:37] <danamin> I'm going to take a look at the sprites and if I can find it before 00:00 I'll add that one too
[21:34:27] <lynxlynxlynx> one question
[21:34:45] <lynxlynxlynx> are there multiple bad sprites or just one row or one sprite?
[21:35:04] <lynxlynxlynx> i see i did a mistake when merging
[21:35:05] <danamin> its fixed
[21:35:15] <lynxlynxlynx> you broke bg2 and i fixed it by breaking bg1 ;)
[21:35:15] <danamin> but I don't know how it will affect BG2
[21:35:35] <lynxlynxlynx> that's what the 7!=8 comment was for
[21:36:29] <danamin> can you explain the 7!=8 because I still don't get it
[21:37:25] <lynxlynxlynx> it should be a more thorough check: if bg1: offset = 0; if bg2: offset = table_offset-1
[21:37:49] <lynxlynxlynx> so when i added +1, one thing too many gets used in bg1
[21:38:20] <fuzzie> but the real problem with proficiencies in the chargen is that it lets you pick too many
[21:38:23] <lynxlynxlynx> the profs table has bg1 profs in rows 0-7, the rest are bg2 ones
[21:40:37] <danamin> it has no scrollbar so no problem?
[21:40:44] <danamin> only 7 slots displayed?
[21:40:56] <danamin> ah, it has 8
[21:41:07] <lynxlynxlynx> ;)
[21:41:25] <danamin> now I get it (I'm king of the off-by-one error)
[21:41:45] <danamin> segfault is stell there?
[21:42:26] <fuzzie> yes, but i don't expect you to fix it, i will look
[21:45:19] <danamin> OK, I'm going to sleep anyway, I'll push the patch to sourceforge
[21:45:31] <fuzzie> thanks
[21:47:06] <Avenger> fuzzie: shadows or light spot
[21:47:36] <Avenger> i guess, it is light spot for magic missile
[21:48:39] <CIA-2> gemrb: 03lynxlupodian * r6487 10/gemrb/trunk/NEWS: centirevisional NEWS update
[21:50:35] <Avenger> hmm do you see the magic misiles normally?
[21:50:45] <danamin> its uploaded, the setStartingGold is not fixed yet, I'll do that tomorrow (it's fairly trivial)
[21:50:57] <danamin> goodnight all
[21:51:11] <Avenger> probably i didn't upload a missile, i thought it is in the original, and deleted it :0
[21:51:30] <fuzzie> i see missile sprites in svn
[21:51:44] <Avenger> spmagmis.pro is there
[21:51:45] <-- danamin has left IRC ()
[21:51:51] <fuzzie> light spot is broken for big-endian, sigh
[21:52:39] <Avenger> ahh ok, magicmis.pro is in the original
[21:54:13] <Avenger> Sprite2D* SDLVideoDriver::CreateLight(int radius, int intensity)
[21:54:31] <Avenger> you need the rgb values in the opposite order for big endian?
[21:54:48] <fuzzie> yes
[21:55:22] <fuzzie> i just changed the code to not fiddle around with individual chars
[21:55:27] <fuzzie> i'll commit it in a bit
[21:58:23] <fuzzie> projectiles look a lot better with that, i wish i'd seen the bug before
[21:59:32] <-- lynxlynxlynx has left IRC (Remote closed the connection)
[22:05:46] <CIA-2> gemrb: 03fuzzie * r6488 10/gemrb/trunk/gemrb/plugins/SDLVideo/SDLVideoDriver.cpp: SDLVideoDriver::CreateLight: don't manipulate integers as chars
[22:07:01] <Avenger> bye!
[22:07:04] <-- Avenger has left IRC ("bye!")
[22:16:42] <CIA-2> gemrb: 03avenger_teambg * r6489 10/gemrb/trunk/TODO: updated TODO with finished or in-progress tasks
[22:35:29] <fuzzie> dammit, stupid pyc files
[22:35:43] <fuzzie> they were lying around in my GUIScripts/bg2, giving me the impression bg2 chargen worked
[22:36:12] <CIA-2> gemrb: 03fuzzie * r6490 10/gemrb/trunk/gemrb/plugins/GUIScript/GUIScript.cpp: GUIScript: put GameType in the GemRB module
[22:47:07] <CIA-2> gemrb: 03fuzzie * r6491 10/gemrb/trunk/gemrb/GUIScripts/LUProfsSelection.py: apply LUProfsSelection sprite fix from danamin
[22:48:07] <CIA-2> gemrb: 03fuzzie * r6492 10/gemrb/trunk/gemrb/GUIScripts/LUSpellSelection.py: LUSpellSelection: fix some GameIsBG1 logic reversals
[22:48:18] <fuzzie> this never worked, so i guess lynx probably has the .pyc problem also
[22:52:11] <fuzzie> danamin's bg1 chargen design is so much nicer than our existing ones
[23:10:05] --> |Cable| has joined #gemrb
[23:35:40] <-- CIA-2 has left IRC (Client Quit)
[23:39:50] --> CIA-18 has joined #gemrb