#gemrb@irc.freenode.net logs for 4 Mar 2011 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage

[00:45:39] <-- Maighstir_ has left IRC (Quit: ~ Trillian Astra - www.trillian.im ~)
[00:48:24] <-- edheldil_ has left IRC (Ping timeout: 240 seconds)
[04:20:00] <-- PixelScum has left IRC (Ping timeout: 240 seconds)
[04:25:10] --> PixelScum has joined #GemRb
[07:10:35] --> edheldil_ has joined #GemRb
[07:41:37] <-- edheldil_ has left IRC (Ping timeout: 252 seconds)
[07:44:35] --> Bo_Thomsen has joined #GemRb
[07:57:21] <MikeChelen> can anyone check this bug https://sourceforge.net/tracker/?func=detail&aid=3195989&group_id=10122&atid=110122
[08:10:11] --> lynxlynxlynx has joined #GemRb
[08:10:11] <-- lynxlynxlynx has left IRC (Changing host)
[08:10:11] --> lynxlynxlynx has joined #GemRb
[08:10:11] --- ChanServ gives channel operator status to lynxlynxlynx
[08:20:33] --> adominguez has joined #GemRb
[08:26:05] --> edheldil_ has joined #GemRb
[08:28:02] --> lubos has joined #GemRb
[08:31:03] <-- edheldil_ has left IRC (Ping timeout: 272 seconds)
[08:32:56] <-- Bo_Thomsen has left IRC (Quit: Leaving.)
[09:09:22] <wjp> MikeChelen: it looks like Avenger already commented on it a few times
[09:10:02] <wjp> for gemrb.log I assume you redirected the output to a file? Try running gemrb directly in a terminal and copying the last few lines before the crash
[09:10:42] <wjp> the stdio buffering seems to have cut off the end where the most relevant information is
[09:11:47] --> Demitar has joined #GemRb
[09:12:31] <fuzzie> that's a pretty weird gap in the backtrace, too
[09:12:48] <fuzzie> so we're missing the spell and we're missing the FXOpcodes function name..
[09:14:24] <wjp> I guess the function names from core are only there because they have to be for dynamic linking
[09:17:56] <fuzzie> it is FX_TARGET_SELF because ApplyEffectQueue is called from GetEffectBlock
[09:21:30] <fuzzie> TRAP_FIREBALL_4D6 or TRAP_HOLD_PERSON maybe
[09:22:05] <wjp> there aren't many NewStat calls in FXOpcodes
[09:22:12] <fuzzie> they're hidden inside macros
[09:22:15] <wjp> ah
[09:22:22] <fuzzie> it's the most common call i think :/
[09:22:45] <fuzzie> those spells are 2023 and 2306
[09:23:07] <wjp> ah, STAT_MOD...
[09:26:37] <fuzzie> well i guess the spells looks fine
[09:29:01] <fuzzie> oh, i guess if it's a door trap then it's TRAP_SLEEP, 2021
[09:29:29] <fuzzie> opcode 0xa5 on self, fx_pause_target, STAT_MOD(IE_CASTERHOLD)
[09:29:56] <fuzzie> so, spell bug? i would have to ask lubos
[09:29:59] <fuzzie> erm, lynxlynxlynx
[09:33:26] <fuzzie> although really we should never be crashing on bad spell data :/
[09:37:18] <lubos> Ha:) Any progress with missing license headers?
[09:37:46] <-- |Cable| has left IRC (Remote host closed the connection)
[09:39:11] <fuzzie> don't suppose you could just write a patch to put them in? :)
[09:39:24] <fuzzie> otherwise i'll put it on my todo list
[09:39:45] <fuzzie> we keep fixing licensecheck's complaints just in time to add more files and forget the headers on those
[09:46:08] <lubos> I can't write patch about licensing your project. Problematic files are here http://log.usecode.org/gemrblog.php?log=2Mar2011
[09:46:57] <fuzzie> well, you can, anything without license headers is all GPL2+, promise :-)
[09:47:28] <fuzzie> actually maybe not
[09:48:03] <fuzzie> snprintf.cpp has a license header already, i guess, and that is not GPL2+
[09:49:06] <lubos> and boost macro
[09:49:44] <fuzzie> and operatorbool.h is surely uncopyrightable
[09:49:57] <fuzzie> but i guess it is Boost licensing
[09:50:40] <fuzzie> ok so that is more annoying than i thought :/
[09:54:56] <lubos> Yes, it is. This delays uploading to Debian until next RemRB release.
[09:57:29] <fuzzie> sometimes i really hate the idea of releases at all :)
[09:58:34] <lynxlynxlynx> releases are great since they usually help with regression finding and fixing (beforehand)
[09:59:02] <fuzzie> but then you release, and there turn out to be a bunch of complex things which are a pain to backport and everyone uses the release for the next 6 months
[09:59:52] <fuzzie> i realise the alternative is something like ffmpeg where you have to sacrifice chickens when picking the revision to check out in the hope of finding one which isn't fulkl of regressions, though :)
[10:01:21] <wjp> gah, don't mention ffmpeg :-)
[10:16:16] <lynxlynxlynx> even ffmpeg has releases nowadays or did they revert back?
[10:16:57] <lynxlynxlynx> releases are important mostly from a user perspecitve, hackers don't have problems with tree builds
[10:18:49] <fuzzie> yeah, i just wish it were more common to provide snapshot tree builds
[10:19:25] <lynxlynxlynx> we do that partly
[10:19:37] <lynxlynxlynx> i rerun the build service now and then
[10:19:39] <fuzzie> everyone is still distributing gemrb 0.6.3, for example
[10:19:48] <fuzzie> i mean, distro-side :)
[10:20:01] <lynxlynxlynx> pretty impossible to change that
[10:20:06] <fuzzie> or even just things like this playdeb thing
[10:20:15] <lynxlynxlynx> at best you can get latest head builds
[10:20:57] <fuzzie> well, debian at least are pretty good at taking snapshots when it's important stuff, but things like gemrb hardly qualify ':)
[10:26:53] <lynxlynxlynx> they have no other choice since they release so rarely
[10:50:12] <fuzzie> i mean, for packages in sid
[10:50:16] <fuzzie> who uses debian releases? :P
[11:34:02] --> Maighstir has joined #GemRb
[11:38:42] <edheldil> btw, I would like to create a machinima for our 30 years war reenactment group, serving as a manual for doing manouevres. For that I would like to create a minimal dataset, basically only an empty area, avatars and script making them walk in special formations. Is it doable in gemrb? I need to control their position and rotation explicitly, no random walk allowed :)
[11:44:09] <lynxlynxlynx> sure
[12:07:12] <-- lynxlynxlynx has left IRC (Ping timeout: 240 seconds)
[12:28:23] --> lynxlynxlynx has joined #GemRb
[12:28:23] --- ChanServ gives channel operator status to lynxlynxlynx
[12:47:36] <MikeChelen> wjp: yup he just did
[12:48:19] <MikeChelen> yeah it was made with gemrb > gemrb.log
[12:48:27] <MikeChelen> tried using 2> before but there was nothing there
[12:48:36] <wjp> redirection is a bad idea for crashes
[12:48:53] <MikeChelen> just want me to copy paste from terminal?
[12:49:05] <wjp> yes
[12:49:11] <MikeChelen> ok let me try
[12:49:21] <wjp> especially the bit after what's in the log file you attached
[12:51:13] <MikeChelen> http://pastebin.com/YTwzvHCt
[12:52:01] <MikeChelen> on sf should it go as comment or attachment?
[12:52:15] <wjp> attachment
[12:54:12] <MikeChelen> ok uploaded it
[12:54:37] <fuzzie> tsk
[12:54:41] <fuzzie> i already found the bug, darnit :P
[12:55:00] <fuzzie> right there in the pastebin, spwi021.spl, TRAP_SLEEP, as predicted
[12:55:01] <wjp> does it match what you found?
[12:55:05] <wjp> ok, good :-)
[12:55:22] <wjp> verification never hurts :-)
[12:55:31] <fuzzie> someone should perhaps note the cause in the comment too
[12:55:40] * wjp volunteers fuzzie
[12:55:54] <fuzzie> (spell has fx_pause_target with FX_TARGET_SELF, which calls STAT_MOD(IE_CASTERHOLD))
[12:56:05] <fuzzie> i am allergic to actually doing things
[12:56:26] <MikeChelen> if you tell me exactly what to do, i will do it :D
[12:56:37] <wjp> I'll copy-paste your message in there
[12:59:48] <MikeChelen> is there any way to fix it?
[13:01:08] <fuzzie> well i would like lynxlynxlynx or someone to confirm the issue first
[13:02:39] <lynxlynxlynx> i can look at it later
[13:02:43] <lynxlynxlynx> iwd right?
[13:03:43] <fuzzie> yes
[13:30:35] <edheldil> I Shadow pass that skeleton ridden place next to Kuldahar?
[13:30:35] <edheldil> I->Is
[13:36:47] <MikeChelen> yup right after kuldahar
[13:37:01] <MikeChelen> yetis and lesser shades outside
[13:37:08] <MikeChelen> and skeletons and stuff in the dungeons
[13:37:39] <MikeChelen> its a fun area, but has lots of traps :D
[14:05:40] <-- adominguez has left IRC (Quit: Saliendo)
[14:19:33] <lynxlynxlynx> which area specifically?
[14:19:41] <lynxlynxlynx> press ctrl-m over the ground
[14:44:57] <MikeChelen> it is when opening a trapped contained
[14:44:59] <MikeChelen> *container
[14:45:59] <tomprince> The question is, what is the (internal) name of the area.
[14:46:22] <fuzzie> it's ar3501
[14:46:36] <fuzzie> but the bug seems obvious
[14:49:26] <fuzzie> i just wonder if we really need to add checks to every single opcode to avoid random crashes from silly spell casts
[14:55:45] <lynxlynxlynx> that's how it was decided
[14:56:31] <lynxlynxlynx> when i was doing the first playthrough, i added a general guard, but it was reverted and avenger said we should just fix any opcodes that also get used by non-actors
[14:57:05] <fuzzie> a general guard with a whitelist?
[14:57:27] <lynxlynxlynx> no, just a null check
[14:57:36] <fuzzie> on the stat modifications?
[14:57:43] <lynxlynxlynx> empty target iirc
[14:58:23] <fuzzie> oh, right, we don't support scriptable targets even for the opcodes which need them
[14:58:26] <fuzzie> sigh
[15:00:05] <fuzzie> i'm just curious how such a solution would handle e.g. fx_knock
[15:00:06] <lynxlynxlynx> i can't boot up the iwd machine, so no testing from me
[15:00:09] <lynxlynxlynx> want me to just plug it?
[15:00:16] <fuzzie> where your target is a scriptable
[15:00:21] <fuzzie> so you get NULL
[15:00:36] <fuzzie> if you could
[15:01:12] <fuzzie> i mean, plug it if you could :)
[15:01:22] <fuzzie> i'm pretty sure that's the bug, especially after the stdout dump confirmed
[15:01:47] <edheldil> what about an assert which would be possible to eventually phase out?
[15:02:05] <lynxlynxlynx> the end user doesn't care
[15:02:12] <lynxlynxlynx> it's still a crash to him
[15:02:53] <fuzzie> yes, i'm not sure the "fix it when it breaks" approach is very sensible given the huge amount of mods out there
[15:03:09] <lynxlynxlynx> maybe a whitelist wouldn't be that bad, i can't think of many targetless opcodes
[15:03:27] <fuzzie> ideally we would do this properly like the original :/
[15:03:41] <fuzzie> but i can understand Avenger not really wanting to give everything an EffectQueue
[15:06:17] --> Maighstir_ has joined #GemRb
[15:06:56] <-- Gekz has left IRC (*.net *.split)
[15:06:57] <-- edheldil has left IRC (*.net *.split)
[15:15:08] <-- Maighstir has left IRC (Read error: Connection reset by peer)
[15:15:09] <tomprince> We could add a flags field to EffectRef.
[15:15:28] <CIA-36> GemRB: 03lynxlupodian * rc6c7c0af85c0 10gemrb/gemrb/plugins/FXOpcodes/FXOpcodes.cpp: avoid (iwd) crash in fx_pause_target when target is null
[15:16:43] --> fuzzie_ has joined #GemRb
[15:17:40] --> Demitar_ has joined #GemRb
[15:25:07] <-- Demitar has left IRC (*.net *.split)
[15:25:08] <-- fuzzie has left IRC (*.net *.split)
[15:26:39] --> Gekz_ has joined #GemRb
[15:26:39] <-- Gekz_ has left IRC (Changing host)
[15:26:39] --> Gekz_ has joined #GemRb
[15:26:55] --> edheldil_ has joined #GemRb
[15:35:13] --- edheldil_ is now known as edheldil
[15:36:33] --- ChanServ gives channel operator status to edheldil
[15:56:07] <-- PixelScum has left IRC (Read error: Connection reset by peer)
[15:56:36] --> PixelScum has joined #GemRb
[16:13:11] --> ar_ has joined #GemRb
[16:13:41] --> tomprinc1 has joined #GemRb
[16:17:02] --> CIA-91 has joined #GemRb
[16:17:52] <-- tomprince has left IRC (*.net *.split)
[16:17:52] <-- ar has left IRC (*.net *.split)
[16:17:53] <-- CIA-36 has left IRC (*.net *.split)
[16:17:58] --- ar_ is now known as ar
[16:18:01] <-- ar has left IRC (Changing host)
[16:18:01] --> ar has joined #GemRb
[16:23:05] --- tomprinc1 is now known as tomprince
[16:26:15] --> lynxlynxlynx_ has joined #GemRb
[16:27:02] --> Gekz has joined #GemRb
[16:27:02] <-- Gekz has left IRC (Changing host)
[16:27:02] --> Gekz has joined #GemRb
[16:29:36] --> fuzzie has joined #gemrb
[16:35:56] <-- Gekz_ has left IRC (*.net *.split)
[16:35:56] <-- fuzzie_ has left IRC (*.net *.split)
[16:35:57] <-- lynxlynxlynx has left IRC (*.net *.split)
[16:36:13] --> Bo_Thomsen has joined #GemRb
[16:44:24] --> Avenger has joined #GemRb
[16:44:24] --- ChanServ gives channel operator status to Avenger
[16:44:29] <Avenger> hello
[16:45:06] <edheldil> Hi
[16:46:02] <Avenger> lynx: your fx_pause_target fix was for the iwd trap on the container?
[16:46:21] <lynxlynxlynx_> something like that
[16:46:38] <Avenger> was it target self?
[16:46:55] <Avenger> was it a scorcher spell maybe?
[16:47:57] <Avenger> spwi217?
[16:48:52] <-- lubos has left IRC (Quit: Leaving.)
[16:49:14] <Avenger> ahh i see the bugfix note
[16:49:53] <Avenger> spwi021, why would a trap spell have a target self opcode, that is a mistery
[16:50:23] <Avenger> ahh copied from color spray
[16:50:27] <Avenger> ok, now i understand
[16:50:35] <Avenger> it is good that this wasn't something more complicated
[16:51:42] <Avenger> maybe we need a list of opcodes that are allowed on non-actors, instead of hand fixing them one by one
[16:52:18] <lynxlynxlynx_> yeah, see the previous discussion
[16:52:59] <lynxlynxlynx_> something like a separate list like we have for diced effects or a flags field in the existing effectref were suggested
[16:54:06] <Avenger> i don't want to do this exactly like the original, because the original hardcoded a separate applyeffect for every scriptable, and hardcoded the accepted opcodes for them in every applyeffect
[16:54:27] <Avenger> so basically it is a cut&pasted huge switch/case for every scriptable except actor
[16:55:10] <Avenger> i prefer the list, yeah
[16:55:42] <Avenger> the list itself could be hardcoded like the diced effects, that's not a problem
[16:56:02] <lynxlynxlynx_> yeah, i don't think it'd be long
[16:56:23] <Avenger> it is about 5-6 effects, that are positively supported on non-actors
[16:56:27] --> |Cable| has joined #GemRb
[16:56:27] <lynxlynxlynx_> knock, sounds, weather change (our extension) comes to mind
[16:56:30] <Avenger> we could add a few more
[16:56:33] <edheldil> hardcoded? Would not it prevent, ehm, extendability?
[16:56:54] <Avenger> no ed, the list would list opcodes that are safe for non-actors
[16:57:04] <Avenger> their safety is 'hardcoded' because it is code dependent
[16:57:05] <lynxlynxlynx_> sounds pretty hardcore for a modder to want to affect that
[16:57:30] <Avenger> their opcode is not hardcoded like in the original, though
[16:57:45] <edheldil> so? If it's 'hardcoded' in FXOpcodes, ok - but it does not belong to core
[16:57:46] <Avenger> the modder has the freedom to assign opcodes to actual effects
[16:58:18] <Avenger> well, it is exactly the same level as the diced effects list
[16:58:18] <lynxlynxlynx_> nobody said it would be in the core :)
[16:58:28] <Avenger> depends on definition of core :)
[16:58:47] <lynxlynxlynx_> well, he didn't use "the" like i did, so i took it as Interface
[16:58:55] <Avenger> if we move the lists to the effect plugins, we'll triple every list without much benefit
[16:59:07] <Avenger> except that they would need to be merged when registering the plugin
[16:59:48] <Avenger> it would be in the EffectQueue object, which is in the core dll, but not in the Interface object
[16:59:53] <lynxlynxlynx_> maybe they're all in fxopcodes, need to check it first
[17:00:02] <Avenger> diced effects? no
[17:00:10] <Avenger> there are iwd specific diced effects
[17:00:28] <lynxlynxlynx_> not diced, these non-actor affectors
[17:00:30] <edheldil> I mean - it is something referencing details from plugins, so it should not be in a/the core, should it?
[17:00:44] <Avenger> i think pst's play animation opcodes are safe for nonactors
[17:00:55] <Avenger> and probably there are the iwd specific area effects too
[17:01:16] <Avenger> i would like to have more effects as 'safe for non-actors' than the original engines
[17:01:25] <Avenger> because i'm the friend of modders :P
[17:01:52] <Avenger> stuff that modifies a stat is not safe
[17:02:03] <lynxlynxlynx_> obviously
[17:02:26] <Avenger> i would start with the hardcoded effects, and then check more effects for safety, and add them to the list
[17:02:38] <Avenger> this way we would always be safe, and compatible
[17:03:14] <edheldil> should not then each *Opcodes plugin define a list of opcodes which are safe and a core whould check that list?
[17:03:46] <edheldil> or do I miss something?
[17:04:06] <Avenger> ed: its logical place would be in the plugins, but it would mean each plugin would need 3 separate lists. As we already got 3 effect lists: diced effects, dices not count as level limit effects and now safe for not actor effects
[17:04:41] <Avenger> so we gather them in EffectQueue
[17:06:20] <edheldil> well, it could also be a method of Opcode plugin : getOpcodeFlag(FX_HIDE_IN_SHADOWS, OF_NEEDS_ACTOR) or something like that
[17:07:31] <Avenger> its not that simple, the plugin doesn't know the opcode's number, that is determined when it is registered
[17:08:20] <Avenger> so we have a list of fx names and associated opcode numbers. The numbers are resolved on first access
[17:08:32] <edheldil> sure, it's a pseudocode bug. should have been fx->something
[17:09:20] <Avenger> the fx are not classes like in the original engine, though :) So they don't own attributes or methods
[17:09:57] <Avenger> i still prefer our way, i don't know how could they be flexible if they are all separate classes
[17:10:38] <Avenger> our 'effect object' is the EffectQueue, that contains all effect specific code
[17:11:34] <edheldil> I do not remember the actual code I wrote, sorry :-P, But what I want to argue is that the knowledge of what effects are safe for whatever belongs to the plugin or gametype, not core.
[17:12:49] <fuzzie> it would be easy for the plugins to add to a core list at startup?
[17:13:14] <Avenger> yes, it would be slightly nicer, but not much practical
[17:13:35] <Avenger> you know the list at compile time
[17:13:51] <fuzzie> mostly i think of modders
[17:14:03] <Avenger> well, they cannot affect the plugin code
[17:14:05] <fuzzie> if you hardcode it in the core, you can't just add a plugin for new effects
[17:14:28] <fuzzie> so a modder has to actually distribute a whole hacked gemrb, and keep it up-to-date, not just some plugin directory
[17:14:29] <Avenger> heh, so far all 3 plugins are shipped by me :P
[17:15:00] <fuzzie> well gemrb doesn't really work better than original engine yet :)
[17:15:13] <Avenger> that's true, as soon as someone seriously wants to create their own effect pack, that means, seriously code in c++, we need to consider this
[17:15:58] <Avenger> the plugins are split up into 3 files only because bg1 and bg2 need only the fxopcodes
[17:16:04] <fuzzie> but i am happy with lynx's solution and a hardcoded list, i just think it's not difficult to fix the plugins
[17:16:37] <Avenger> as soon as it will be more practical to have the plugins supply their own lists, i will agree
[17:17:04] <fuzzie> but then i guess i don't see why we don't put it in a 2da :P
[17:17:25] <Avenger> because it is code dependent, as soon as you manage to code in 2da, yeah :)
[17:17:39] <edheldil> that's why I suggested a gametype, even if it's subpar :-)
[17:17:42] <fuzzie> oh, i am not understanding which lists then
[17:18:13] <Avenger> the 3 lists are: safe for non-actors, diced effects, dice is not level limit.
[17:18:30] <fuzzie> sure, but there is code for those?
[17:18:39] <Avenger> the actual plugin code, yes
[17:18:57] <Avenger> lets say: PlayMovie is safe for non actors, then it belongs to that list
[17:19:01] <fuzzie> sure
[17:19:02] <Avenger> Damage is a diced effect
[17:19:07] <Avenger> etc
[17:19:10] <fuzzie> so you put 'PlayMovie' in a 2da and 'Damage' in a 2da
[17:19:14] <Avenger> no
[17:19:43] <Avenger> it doesn't belong to the 2da, because i supply PlayMovie in code, so this info belongs to the very same code, that is the plugin
[17:19:50] <fuzzie> i mean, i see that safe for non-actors should really be hardcoded since otherwise you crash
[17:20:01] <Avenger> yes, that's what i mean
[17:20:04] <fuzzie> but if you are willing to put lists in the core then it seems no worse in a 2da
[17:20:19] <fuzzie> since the info no longer belongs to the effect plugin :)
[17:20:23] <fuzzie> but i spent too much time talking about it!
[17:20:42] <fuzzie> crash fixed, i am happy.
[17:21:00] <Avenger> well, this is design theory :)
[17:21:38] <fuzzie> i don't care about modders at all, but i do think that FXOpcodes is full of bg-specific stuff which people might want to replace.
[17:22:12] <Avenger> yep, we need an own plugin that is nice and clean
[17:22:49] <Avenger> i bet you seen the bugreport of beholder, about the boot of grounding
[17:23:11] <Avenger> looks like bg1 has the resistance portrait icons in the resistance effect
[17:23:19] <Avenger> bg2 doesn't have that
[17:23:33] <Avenger> so there are tiny differences that will bite us
[17:23:43] <edheldil> in other words, the effects are diffrent
[17:24:20] <Avenger> yes, they are, but i always hoped they are different only in a superset way, or a bugfixed way
[17:25:19] <Avenger> in fact, you can easily find effects that exist in all 5 games, in 3-4 different form
[17:25:22] <edheldil> well, but tiny and infrequent differences are probly better solved by just having fx_bg1_resistance() and fx_bg2_resistance()
[17:25:39] <Avenger> yep
[17:25:51] <Avenger> that is what i tried with GF_ENHANCED_EFFECTS, for iwd
[17:26:20] <Avenger> i just don't want 5-6 game flags per gametype :)
[17:26:49] <Avenger> it would even be nicer if we have an fx plugin per gametype with all the common code in an inner module
[17:26:55] * Avenger shrugs.
[17:27:28] <edheldil> the other day I was thinking about getting rid of all the DnD-encumbered stuff in gemrb for the purpose of a more libre ruleset and getting rid of FXOpcodes was high on a list
[17:28:11] <Avenger> yep, that's another reason to have a clean separate fx plugin for our own game
[17:28:20] <edheldil> but stuffing it into the core would make things worse
[17:31:07] <edheldil> as a kind of shibboleth, what needs ie_stats.h is not safe :)
[17:31:22] <Avenger> :(
[17:31:25] <edheldil> s/shibboleth/quick test/
[17:31:38] <Avenger> ie_stats is bad itself
[17:31:57] <Avenger> iwd2 has different stats, and pst has a few new ones too
[17:32:20] <Avenger> i think we can get away with the pst stats, because the original engine doesn't use them
[17:32:33] <Avenger> i mean, the Original game
[17:32:53] <Avenger> but i'm not sure about iwd2
[17:33:04] <edheldil> the reason is that iwd2 uses different ruleset
[17:33:14] <edheldil> not ADnD, but DnD
[17:33:43] <Avenger> i thought it is 3rd ed ad&d :)
[17:34:04] <edheldil> and from there it's not such a big leap to consider some totally different ruleset as well
[17:34:12] <Avenger> yes
[17:34:55] <Avenger> actually, it just needs a new layer of mapping scripting stats to engine stats
[17:35:01] <edheldil> well, 3ed is called DnD, 2ed is ADnD. The are not completely different, but different a lot nonetheless
[17:35:21] <Avenger> and probably increase the engine stat counts
[17:36:00] <edheldil> e.g. AC in 2ed goes down from 10, in 3ed it goes up from 10
[17:36:29] <edheldil> similar from saving throws
[17:36:32] <edheldil> for
[17:37:06] <Avenger> yep, and a heap of other stuff, 3rd ed has a lot of simplifications
[17:37:24] <Avenger> and weird stuff that makes it boring :)
[17:37:41] <Avenger> it is basically a bab optimisation game that the player cannot win
[17:38:28] <edheldil> well, ADnD's logic is simply weird.
[17:38:52] <edheldil> 3ed is at least logical and mostly regular
[17:40:13] <edheldil> but the hit probability distribution remains the same flat line :)
[17:40:14] <Avenger> well, i always ended up in iwd2 with characters that cannot harm the enemy, but they get 0 xp for killing them
[17:41:34] <Avenger> so i think my flat line converged to 0
[17:42:20] <edheldil> if you solo an instance in WoW, it's the same problem. The resume is to not solo the instances :-)
[17:43:19] <edheldil> I have to leave. See you later
[17:44:10] <Avenger> see you
[17:45:27] <Avenger> ahh cool, i started gemrb just to find this bug, but it is all done by you :)
[17:46:41] --> edheldil_ has joined #GemRb
[17:52:03] <-- edheldil_ has left IRC (Ping timeout: 260 seconds)
[17:52:29] <-- Avenger has left IRC (Quit: ChatZilla 0.9.86 [Firefox 3.6.13/20101203075014])
[18:02:15] --> Avenger has joined #GemRb
[18:02:15] --- ChanServ gives channel operator status to Avenger
[18:03:14] <Avenger> errm, just read the whole chat log, and to answer fuzzie about fxqueue for all scriptables: we are lucky, all fx that are 'safe for non-actors' are instant fx :) So 'fxqueue for all' is an overkill
[18:04:16] <Avenger> so the main blocking reason now, that we got global ids for all scriptables is that fxqueue in every scriptable would be a performance hit
[18:05:09] <-- Avenger has left IRC (Client Quit)
[18:08:01] <-- |Cable| has left IRC (Remote host closed the connection)
[18:09:25] --> |Cable| has joined #GemRb
[18:37:04] <-- |Cable| has left IRC (*.net *.split)
[18:37:05] <-- fuzzie has left IRC (*.net *.split)
[18:37:11] <-- Maighstir_ has left IRC (Read error: Connection reset by peer)
[18:37:20] --> Maighstir_ has joined #GemRb
[18:38:12] --> fuzzie has joined #gemrb
[18:38:23] --> |Cable| has joined #GemRb
[18:41:59] <-- lynxlynxlynx_ has left IRC (Ping timeout: 276 seconds)
[18:54:10] --> edheldil_ has joined #GemRb
[19:05:58] <-- |Cable| has left IRC (Remote host closed the connection)
[19:07:18] --> |Cable| has joined #GemRb
[19:16:34] <-- Demitar_ has left IRC (Ping timeout: 250 seconds)
[19:28:54] --> Demitar_ has joined #GemRb
[19:33:36] <-- DrMcCoy has left IRC (Disconnected by services)
[19:33:52] --> DrMcCoy has joined #GemRb
[20:05:37] <CIA-91> GemRB: 03avenger_teambg * r075ecaa9ca89 10gemrb/gemrb/override/pst/ (effects.ids iknife.pro speak.eff stories.pro stories.spl): projectile game data and new effect names
[20:05:45] <CIA-91> GemRB: 03avenger_teambg * r32126125e818 10gemrb/gemrb/ (2 files in 2 dirs): Merge branch 'master' of ssh://gemrb.git.sourceforge.net/gitroot/gemrb/gemrb
[20:11:40] <CIA-91> GemRB: 03avenger_teambg * r40e504dbf0af 10gemrb/gemrb/plugins/PSTOpcodes/PSTOpcodes.cpp: some hints about the last missing PST opcode
[20:25:55] <-- Demitar_ has left IRC (Ping timeout: 252 seconds)
[20:26:21] --> Demitar_ has joined #GemRb
[21:29:17] <-- Bo_Thomsen has left IRC (Quit: Leaving.)
[21:44:57] <tomprince> I think that adding flags to what is EffectRef2 in this patch https://gist.github.com/855751
[21:45:06] <tomprince> Would be the sensible thing to do.
[21:46:35] <fuzzie> what does the EffectRef::* mean?
[21:47:02] <fuzzie> (I')
[21:47:05] <fuzzie> ugh
[21:47:24] --> lynxlynxlynx has joined #GemRb
[21:47:24] --- ChanServ gives channel operator status to lynxlynxlynx
[21:49:25] <fuzzie> Attaching flags there seems like a good suggestion.
[21:49:43] <fuzzie> Can't give informed opinion right now though.
[21:54:21] <tomprince> That was just to make the patch easy, that field should go, since it is never used. It was just easier for a quick patch to leave it in, rather than go and delete all the NULLs.
[21:55:42] <fuzzie> I mean, sorry, I am curious as to what the syntax means (if anything).
[21:55:52] <tomprince> Pointer to member variable.
[21:58:51] <fuzzie> Huh, I didn't know that existed. Thanks :)
[22:01:22] <tomprince> It is what is used to make the 'operator bool' work sanely as well. It is a pointer type, and so can be used in if statements, but otherwise doesn't do much besides be dereferenced with .* and ->*
[22:54:22] --> BaldimerBrandybo has joined #GemRb
[22:58:05] <-- PixelScum has left IRC (Ping timeout: 276 seconds)
[23:02:35] <-- lynxlynxlynx has left IRC (Read error: Connection reset by peer)
[23:13:20] --- Maighstir_ is now known as Maighstir
[23:44:46] <-- Maighstir has left IRC (Quit: ~ Trillian Astra - www.trillian.im ~)