#gemrb@irc.freenode.net logs for 13 Dec 2013 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage


[00:59:51] <-- raevol has left IRC (Quit: Leaving.)
[01:02:31] <Pepelka> [wiki] pst_bugs - [Gameplay] enjoy yourself, it's later than you think http://www.gemrb.org/wiki/doku.php?id=pst_bugs&rev=1386896261&do=diff
[01:35:05] <-- WingedHussar has left IRC (Remote host closed the connection)
[01:36:57] <Pepelka> [commit] : Redraw a window after setting it gray https://github.com/gemrb/gemrb/commit/371f6ebbe5694af6a1f7fa08f66579fb1dc3ad36
[01:36:59] <Pepelka> [commit] : Show inactive and gray menu window in GUISTORE https://github.com/gemrb/gemrb/commit/fddf375eeb54bc900faf64faba932ccb1a47f41c
[01:37:00] <Pepelka> [commit] : Pause game when opening store https://github.com/gemrb/gemrb/commit/2f4bf6930731fe4c0a5437e5f0d57788d9499980
[01:37:01] <Pepelka> [commit] : Create red tint rects for some items https://github.com/gemrb/gemrb/commit/fac89c9d6c3f27211efaf5278bcb90192d4c687c
[01:37:02] <Pepelka> [commit] : Properly update encumbrance label, fix PC names https://github.com/gemrb/gemrb/commit/123d8afdd00c0561b08cb2ee9db7abb1b4afdb71
[01:50:54] <-- |Cable| has left IRC (Ping timeout: 252 seconds)
[01:54:33] <-- nutron has left IRC (Quit: I must go eat my cheese!)
[01:54:53] --> nutron has joined #gemrb
[02:03:52] --> |Cable| has joined #gemrb
[02:17:55] --> brada has joined #gemrb
[02:18:16] <brada> the amount of repeated code in gemrb is troubling
[02:21:08] <Pepelka> [wiki] pst_bugs - [GUI] totes not an issue anymore http://www.gemrb.org/wiki/doku.php?id=pst_bugs&rev=1386900923&do=diff
[02:29:59] <brada> the fact that projectile keeps coming up in my searches for code inside the scriptable hierarchy disturbs me since they have no common inheritance.
[02:43:45] <-- edheldil_ has left IRC (Read error: Operation timed out)
[02:55:02] <-- brada has left IRC (Quit: brada)
[03:09:15] --> brada has joined #gemrb
[03:48:30] <-- brada has left IRC (Quit: brada)
[04:11:43] --> brada has joined #gemrb
[04:24:11] <-- brada has left IRC (Quit: brada)
[05:18:33] --> Eli2 has joined #gemrb
[05:19:51] <-- Eli2_ has left IRC (Ping timeout: 245 seconds)
[06:52:58] --> edheldil_ has joined #gemrb
[07:05:47] <-- edheldil_ has left IRC (Ping timeout: 260 seconds)
[07:48:08] <-- berenm has left IRC (Quit: berenm)
[07:49:43] --> lynxlynxlynx has joined #gemrb
[07:49:43] --- ChanServ gives channel operator status to lynxlynxlynx
[08:56:49] <edheldil> Hi all
[08:57:09] --> WingedHussar has joined #gemrb
[08:59:37] --> Yoshimo has joined #gemrb
[09:02:27] <lynxlynxlynx> gmornin
[09:09:06] --> edheldil_ has joined #gemrb
[10:43:26] <edheldil> btw, fallout is free on gog for next few hours
[10:51:37] <-- DrMcCoy has left IRC (Ping timeout: 246 seconds)
[10:56:33] --> DrMcCoy has joined #gemrb
[11:11:00] <-- DrMcCoy has left IRC (Ping timeout: 246 seconds)
[11:18:09] <lynxlynxlynx> nice, thanks
[11:18:17] <lynxlynxlynx> it includes fallout tactics :)
[11:23:59] <fuzzie> that one I didn't have
[11:41:15] <-- WingedHussar has left IRC (Ping timeout: 245 seconds)
[11:41:23] --> DrMcCoy has joined #gemrb
[12:00:16] <edheldil> fuzzie: and apparently bethesda is pulling FO from gog at the end of the year
[12:10:50] <-- DrMcCoy has left IRC (Quit: He's dead, Jim)
[12:11:26] --> DrMcCoy has joined #gemrb
[13:23:37] --> WingedHussar has joined #gemrb
[13:53:16] <-- Yoshimo has left IRC (Ping timeout: 246 seconds)
[14:08:40] --> brada has joined #gemrb
[14:13:26] <brada> ed: thanks for the fallout tip!
[14:18:20] <brada> so maybe somebody can suggest to me a better hack/fix for timestop/hold clearing actor path
[14:19:03] <brada> my slightly improved version is to replace all the actor->ClearPath(); calls with actor->timeStartStep = game->Ticks;
[14:19:25] <brada> but obviously thats not optimal
[14:19:35] <brada> and i dont know if there are sideeffects
[14:30:04] <lynxlynxlynx> timestop code is pretty trivial, it's all about the timer
[14:30:15] <lynxlynxlynx> are actors jumping when it ends again?
[14:31:34] <brada> no the problm im having is they dont resume their walking when it ends :)
[14:31:39] <brada> find it quite annoying
[14:31:54] <brada> so that is my hack/fix so they will resume without jumping
[14:37:27] <brada> i think i also had to override do step to return true when immobile
[14:40:46] <lynxlynxlynx> maybe another internal flag would make it cleaner
[14:46:29] <-- brada has left IRC (Read error: Connection reset by peer)
[14:46:47] --> brada has joined #gemrb
[15:06:54] <-- brada has left IRC (Quit: brada)
[15:16:50] --> Yoshimo has joined #gemrb
[15:34:47] <-- Yoshimo has left IRC (Read error: Connection reset by peer)
[15:46:15] --> Yoshimo has joined #gemrb
[15:46:38] <-- WingedHussar has left IRC (Quit: WingedHussar)
[16:09:26] <-- Yoshimo has left IRC (Ping timeout: 245 seconds)
[16:44:20] <-- edheldil_ has left IRC (Ping timeout: 338 seconds)
[17:05:48] --> raevol has joined #gemrb
[17:09:18] --> brada has joined #gemrb
[17:10:28] <brada> lynx: the way I see it is we need to reset the move time to the time when the effect expires.
[17:10:36] --> Yoshimo has joined #gemrb
[17:24:56] <brada> when time stop or hold is applied to an actor can we get the duration for it?
[17:25:19] <brada> maybe that would be a suitable way for setting the move start time
[17:25:46] <brada> except no
[17:25:46] <brada> because cant things cure said effects?
[17:25:47] <brada> hold especially?
[17:28:24] <brada> so maybe add a new actor/scriptable method for clearing effects?
[17:28:37] <lynxlynxlynx> timestop is not curable
[17:28:46] <brada> right now it looks like things reach into the object and mess with the fx queue directly
[17:28:46] <lynxlynxlynx> critters can be immune, but that's it
[17:28:57] <brada> lynx: even so isn't hold?
[17:29:00] <brada> and still seems like a poor way to do it
[17:29:23] <lynxlynxlynx> i don't remember implementing timestop using the hold effects
[17:29:40] <brada> it doesnt but hold and time stop both suffer from this problem
[17:30:21] <lynxlynxlynx> well hold can have extra logic in the effect if needed
[17:30:46] <lynxlynxlynx> or just check if it is there in the loop
[17:30:51] <lynxlynxlynx> cheaper with a flag though
[17:31:09] <brada> I dont see how that will help
[17:32:20] <brada> the problem is that we need to change the movment start time to the time when the effect ends. which i do with my hack
[17:34:39] <brada> i *think* the proper way is to have a cleanup() method that cleans up the effect queue and actor can override it to set the movement start time when clearing immobilizing effects
[17:35:14] <lynxlynxlynx> effect duration is available
[17:35:38] <lynxlynxlynx> if it isn't, the effect is permanent
[17:35:42] <brada> certainly the logic should be contained in the actor/scriptables instead of done in Map.cpp
[17:35:42] <brada> yes but like i said it feels flimsy to rely on that
[17:35:53] <brada> you cant remove those effects tho?
[17:35:54] <brada> i mena technically?
[17:36:34] <lynxlynxlynx> some are permanent after death, some not, but from the engine pow, of course we can remove any
[17:37:11] <brada> so if the hold effect were to be removed but the movement start time had been calculated using its duration then you would still have a problem
[17:37:17] <lynxlynxlynx> what you're thinking can probably already be done in Actor::RefreshEffects
[17:37:32] <lynxlynxlynx> not if the effect is setting a flag
[17:37:39] <lynxlynxlynx> upon removal, the flag would be gone too
[17:38:18] <brada> yeah i can already detect if an actor is held but i dont see how seeing the flag is set or not set tell me to set the value of the movement start time
[17:38:37] <brada> that needs to be the time of exactly when the flag is cleared
[17:38:37] <lynxlynxlynx> though it's not as simple, since there can be multiple in play and a binary flag wouldn't do
[17:40:02] <lynxlynxlynx> i don't see a problem, it would be a most one tick late
[17:40:20] <lynxlynxlynx> show me your hack
[17:41:23] <brada> yeah one tick wouldnt be a problem at all
[17:44:31] <brada> lynx: http://pastebin.com/9FL4mB5h
[17:44:32] <Pepelka> [Diff] diff --git a/gemrb/core/Map.cpp b/gemrb/core/Map.cpp index ccc29b4..2d80453 100 - Pastebin.com
[17:44:38] <brada> thats jsut for timestop
[17:46:06] <lynxlynxlynx> looks fine, though shouldn't it be +1? Hold has to be handled elsewhere anyway
[17:47:15] <brada> sure, its better than before, but i was hoping there was a good place inside of actor or scriptable to do this
[17:48:32] <lynxlynxlynx> refresheffects
[17:51:14] <brada> can you be more specific?
[17:51:27] <brada> i dont wee where the effects are cleared
[17:54:37] <lynxlynxlynx> they're not applied until excplicitly in the middle of the function
[17:54:45] <lynxlynxlynx> or if it is called with a prepared queue
[17:56:58] <brada> well i need to know the instant they are remove not applied
[18:01:18] <lynxlynxlynx> why, just update the timer when they're there
[18:01:44] <lynxlynxlynx> we don't have a clean mechanism for notification of effect removal
[18:01:44] <brada> im not following
[18:02:11] <lynxlynxlynx> set the start walking time to gametime each tick a problematic effect is present
[18:02:28] <lynxlynxlynx> when they're all gone, nothing will set the time again and it will increase normally
[18:02:40] <lynxlynxlynx> err, gametime+1
[18:03:11] <brada> ok let me check something
[18:06:46] <lynxlynxlynx> maybe just checking immobile() would do, but that other conditions too
[18:07:24] <lynxlynxlynx> to remove the need for a lookup, you could add a shared function to the effects plugin(s) and do it all in the effects
[18:08:04] --> gatezz has joined #gemrb
[18:08:54] <brada> well any immobile condidtion should be fine to do this on
[18:09:02] <brada> since immobile means not moving :p
[18:09:20] <-- gatezz has left IRC (Remote host closed the connection)
[18:17:32] <brada> ok that does seem to work for timestop at least
[18:17:55] <brada> i see no reason why it wouldnt apply to other imobility conditions
[18:48:54] <brada> well i have to go, but will you guys look at this patch to see if it is sensible
[18:48:54] <brada> http://pastebin.com/ShpN3CSA
[18:48:56] <Pepelka> [Diff] From 67b686bd2d17e119e6310707d2b39d2555b7c03c Mon Sep 17 00:00:00 2001 From: Br - Pastebin.com
[18:49:05] <-- brada has left IRC (Quit: Page closed)
[18:52:20] <Pepelka> [wiki] pst_bugs - [Inventory] Oh pst you so crazy http://www.gemrb.org/wiki/doku.php?id=pst_bugs&rev=1386960626&do=diff
[19:19:02] --> edheldil_ has joined #gemrb
[20:09:20] --> brada has joined #gemrb
[20:16:58] <edheldil_> where is specified what dialog state is used when I talk to a party membr?
[20:17:48] <fuzzie> nowhere
[20:17:54] <fuzzie> it's based on the triggers in the dialog file
[20:18:16] <edheldil_> so it starts at the first state?
[20:18:30] <edheldil_> (or first that matches)
[20:18:31] <fuzzie> the first one where the triggers match, yes
[20:19:14] <fuzzie> of course pst might be different
[20:19:31] --> chiv has joined #gemrb
[20:20:27] <brada> hell chiv
[20:20:30] <brada> hello
[20:20:32] <brada> ha ha
[20:20:50] <brada> fuzzie: did you look at that patch?
[20:21:02] <chiv> hi brada
[20:21:22] <chiv> was I imagining it, or did you say you never played torment?
[20:21:29] <brada> i havent
[20:21:44] <brada> i never even knew about it till i started working on gemrb
[20:21:57] <chiv> its 5 bucks on gog right now
[20:22:03] <brada> probably because there was never a mac version ha ha
[20:22:09] <brada> oh i do own it :p
[20:22:12] <chiv> ahh
[20:22:26] <chiv> nm, I was just fishing around the sales
[20:22:41] <brada> i intend to play it eventually
[20:22:48] <brada> i would prefer to do so in gemrb
[20:22:50] <brada> over wine
[20:23:03] <Pepelka> [wiki] pst_bugs - [Animation] Vhailor caught stealing the Nameless One's body http://www.gemrb.org/wiki/doku.php?id=pst_bugs&rev=1386965856&do=diff
[20:23:27] <chiv> I should probably try not to spoil it then...
[20:24:09] <chiv> whoops
[20:25:57] <fuzzie> brada: patch seems ok to me. remove the FIXME though?
[20:26:12] <brada> does it still need a fixme?
[20:26:26] <fuzzie> sorry, I mean
[20:26:37] <fuzzie> hm
[20:26:47] <fuzzie> actually I'm not sure what I mean
[20:27:38] <fuzzie> doesn't your combining-loop patch break walking?
[20:27:45] <brada> no
[20:27:53] <brada> at least not in BG2
[20:28:23] <fuzzie> it looks like the walking loop will now keep looping until all actors are done?
[20:29:26] <brada> even tho i override dostep to return if they are immobile?
[20:29:27] <fuzzie> I guess that shouldn't break anything but it'll be inefficient
[20:29:44] <fuzzie> well from memory, the idea of this code is to handle actors which take multiple 'steps' in one frame
[20:29:54] <brada> right
[20:30:06] <brada> but if the actor has no steps it will return that they have no more
[20:30:34] <fuzzie> yes, so it's just inefficient I guess
[20:30:46] <brada> well maybe a bit
[20:30:55] <brada> its not like it does a whole lot
[20:31:09] <brada> and i really hated that public variable that is only ever used from another class
[20:31:19] <fuzzie> it was originally an array I think
[20:31:20] <brada> it made my skin crawl
[20:31:23] <fuzzie> as in, a local one
[20:31:24] <brada> yeah it was
[20:31:32] <brada> I saw in the log
[20:32:50] <fuzzie> it all looks fine anyway
[20:33:02] <brada> well if its going to be terribly ineffitient...
[20:33:07] <brada> inefficient
[20:33:32] <fuzzie> I'm pretty sure we still spend most of our time in the render code.
[20:33:55] <fuzzie> my concern is that the pathing is slow
[20:34:04] <fuzzie> but .. we're really inefficient there anyway, we do it every frame
[20:34:07] <fuzzie> so .. a problem for another day
[20:34:37] <brada> well let me at least check to see if there is a noticable CPU ussage diff
[20:35:03] <fuzzie> I really really hope there isn't!
[20:35:40] <brada> me too
[20:38:19] <brada> well it cant be too much worse
[20:38:50] <brada> in fact this completely unscientific test showed an average of +2% for the old version
[20:40:00] <brada> i could probably alleviate some by tweaking DoStepForActor
[20:43:30] <brada> fuzzie: can anymore of DoStepForActor be skipped for immobile actors?
[20:44:12] <fuzzie> all of it maybe?
[20:44:50] <fuzzie> I'm not quite sure what happened to this code
[20:47:27] <fuzzie> but it's all mixed up
[20:50:43] <brada> well sure the the top bit doesnt seem applicable to immobile actors
[20:51:43] <brada> and actually doesnt this seem like what Actor::doStep should be doing?
[20:52:25] <brada> it seems like more of an actor responsibility to me
[20:58:58] <fuzzie> yes it's weird..
[20:59:14] <fuzzie> although DoStep itself shouldn't be doing it
[20:59:37] <brada> why is that?
[20:59:45] <fuzzie> the outer looping is presumably meant to deal with the case where two actors walk into the same spo
[20:59:48] <fuzzie> t
[21:00:04] <fuzzie> it seems a pretty obscure one, so if we can do without it, fine
[21:00:14] <fuzzie> but DoStep is only doing *one* step, right?
[21:00:24] <brada> yes
[21:00:33] <fuzzie> so I think you'd probably want a wrapper function to deal with re-pathing
[21:00:36] <fuzzie> shrug
[21:01:32] <fuzzie> I have no magical insights here.
[21:04:28] <brada> fuzzie: do you agree that this all seems pretty pointless for immobile actors?
[21:09:24] <chiv> sorry for just floating ideas, but would it be doable to just have one path generated for the party group, and each party member does their best to stay close to it, rather than scattering in 5 different directions when you are in one of those tiny mazes?
[21:09:51] <brada> yeah i hate that
[21:10:22] <brada> surely its possible to do something about it, but its probably a complicated thing to mess with
[21:10:58] <chiv> it was just a vague idea I had ages ago when playing bg1, if it's complicated then its not worth it imo
[21:11:24] <brada> well it may be worthwhile
[21:11:39] <brada> if you can find the actor closes to the destination
[21:12:11] <brada> but nevermind that because actos move at diff speeds
[21:13:09] <brada> the complicated part of that is inventing the concept of a "group"
[21:13:45] <chiv> there's a game I played and I can't remember what it was, but when you had 50 units selected, it would draw a visual pulsating line that showed the path generated for them, they would move as a group and the group would shift depending on obstacles
[21:13:54] <chiv> it might have been age of empires
[21:13:56] <brada> i think gemrb can do that
[21:14:01] <brada> draw the paths i mean
[21:14:23] <brada> the problem is in the recalculation
[21:14:28] <chiv> yeah i saw the keys in the docs, i couldn't get it working though...
[21:14:34] <brada> gemrb has no concept of a group
[21:14:44] <chiv> yeah that would be the difference
[21:14:56] <brada> i mean it does in a way based on selection
[21:15:06] <brada> but obviously that isnt enough
[21:16:47] <brada> an easy workaround might be to detect when a repath is due to an actor that is still mobile
[21:16:48] <chiv> I sort of imagine it like having gps waypoints, you just go in a straight line till you get the next one
[21:16:54] <brada> and then instead of repathing just wait
[21:17:12] <brada> and the wait could be calculated by the blocking actors speed
[21:17:35] <chiv> hey thats a good idea
[21:17:36] <brada> chiv: we already do waypoints
[21:17:40] <brada> well i think
[21:18:01] <brada> the problem is the repathing because it becomes "blocked"
[21:18:10] <brada> even if the block is temporary
[21:19:42] <brada> the one prolem with my idea is if there is a way around the "blocking" actor
[21:20:55] <brada> you dont want somebody jsut riding the heels of the leader when the could jsut step around them i imagine
[21:21:48] <brada> speaking of all this maybe making a group is a worthwhile effort because then we could also keep characters together without getting spread all over the map due to speed diffs
[21:21:49] <chiv> it would be cool if neutral npcs could see the player coming and get he hell out of the way...
[21:22:38] <chiv> hmm, I always use the different speeds to my advantage
[21:22:53] <brada> well it could be optional
[21:23:15] <brada> and i would want it disabled when enemy is sighted
[21:23:17] <brada> or such
[21:23:35] <brada> its all jsut talk anyway :p
[21:23:40] <chiv> yeah
[21:23:43] <brada> i have many other things i want to do
[21:24:07] <chiv> mostly I just want to fix bugs...
[21:25:01] <brada> speaking of bugs
[21:25:12] <brada> are the animations in gemrb messed up?
[21:25:28] <brada> or was the original just as bad?
[21:25:29] <chiv> There are so many in pst, but I am not encountering many new ones which is a good sign
[21:25:34] <chiv> how do you mean?
[21:25:36] <brada> i ask because BGEE seems so much better
[21:25:45] <brada> jsut jerky
[21:25:49] <brada> and funny looking
[21:26:12] <chiv> bgee has bg2 style avatars
[21:26:37] <chiv> but with the bg1 style sprite pack from 1pp
[21:26:54] <chiv> could that be the reason?
[21:27:20] <brada> i dont know
[21:27:32] <brada> im hardly an authority on how any of this works
[21:27:52] <chiv> well bg1 had half as many rotations, frames etc
[21:28:08] <brada> im using BG2 right no so thats not it
[21:28:25] <brada> it seems like maybe its jsut hasted actors
[21:28:46] <brada> maybe we never change the animation speed
[21:29:52] <brada> fuzzie: http://pastebin.com/E51EwyB1
[21:29:53] <Pepelka> [Diff] From a61a4653430125f8c99da61b67817b0f4d035901 Mon Sep 17 00:00:00 2001 From: Br - Pastebin.com
[21:29:56] <brada> does that seem ok?
[21:31:14] <chiv> I think the speed is off, because there's lots of ice skating with all the torment npc's
[21:31:25] <brada> yeah thats what im talking about
[21:32:09] <lynxlynxlynx> chiv: use the single column formation
[21:32:38] <brada> that still doest work well with varying speed PCs
[21:32:43] <brada> in narrow areas
[21:32:55] <brada> tho i guess usually the faster ones are at the front :D
[21:33:00] <chiv> odd, I don't that..
[21:33:11] <chiv> ach, don't have that
[21:34:12] <chiv> also, is it my imagination or does gemrb restrict actor movement to certain vectors?
[21:36:23] <lynxlynxlynx> brada: did you test the change in RemoveActor? That looks the only possibly problematic bit to me (but was looking at original patch)
[21:37:40] <brada> lynx: why would it be a problem to stop all actions there?
[21:38:44] <brada> I would assume when an actor is removed from the map all its actions are now invalidated
[21:39:05] <lynxlynxlynx> is it used only for actor destruction or also in area moves and npc leaves?
[21:40:03] <lynxlynxlynx> as for DoStepForActor, if nothing is done for immobiles, it would be cleaner to exit the function at the start immediately (one indent level less)
[21:40:17] <brada> ok ill rewrite that
[21:43:03] <lynxlynxlynx> the clearpath for avatarremoval can stay if it helps anything. User visible it is only used for imprisonment, which is a teleport to the center of the planet, and maybe maze, which is also iirc. Nobody should be able to continue automatically from that
[21:43:30] <brada> true
[21:43:35] <brada> i will re add that
[21:43:41] <brada> well
[21:43:45] <brada> what about ctrl+t
[21:44:02] <brada> guess that dosnt matter how it behaves
[21:44:35] <brada> yah im fine with ctrl+t teleporting actually
[21:44:38] <brada> its a feature :D
[21:47:18] <lynxlynxlynx> +j you mean? anyway, that's a debug/devel feature, yeah
[21:47:59] <brada> no i mean ctrl+t for advance time
[21:48:21] <brada> it will teleport your actors because of the time advance
[21:48:30] <brada> which is fine
[21:51:09] <brada> lynx: to me it looks like RemoveActor is only for moving between areas and MoveGlobalsTo
[21:51:50] <brada> i dont think either of those qualify for retaining actions, but i dont know what exactly that encompasses
[21:55:07] <lynxlynxlynx> i don't know of the top of my head
[21:55:56] <lynxlynxlynx> but my guess would be you're right
[21:56:06] <fuzzie> think about a script running on player1
[21:56:14] <fuzzie> teleporting between areas
[21:57:15] <lynxlynxlynx> didn't they split the cutscenes in several pieces just for that?
[21:57:17] <brada> fuzzie: so we shouldn't clear actions then
[21:57:20] <brada> ?
[21:57:58] <fuzzie> lynxlynxlynx: no
[21:58:04] <fuzzie> they're usually cut for dialog, no?
[21:58:17] <lynxlynxlynx> that too
[21:58:36] <fuzzie> there's plenty of LeaveArea -> Wait -> <other stuff> type cutscene scripts
[21:59:25] <lynxlynxlynx> yeah, but is the cutscene id the one leaving?
[21:59:29] <fuzzie> yes
[21:59:32] <lynxlynxlynx> anyway, you know better
[21:59:33] <fuzzie> I mean, LeaveArea on self
[21:59:50] <fuzzie> again I have no immediate magical knowledge here
[22:00:01] <fuzzie> I don't recall the original doing this
[22:00:34] <fuzzie> but for example look at bg2's cut70a
[22:00:56] <fuzzie> or cut69a
[22:00:57] <fuzzie> or etc etc
[22:01:08] <fuzzie> so based just on looking at scripts I think it's a bad idea :)
[22:01:11] <brada> ok
[22:01:20] <brada> i shall undo
[22:01:29] <fuzzie> would appreciate someone else look at them to make sure I'm not missing the obvious, as usual
[22:05:52] <edheldil_> Do I have to do anything in a dialog to open the talk window? I have created a simple dialog with 1 state and 2 transitions and actions, but when it should open, nothing happens
[22:06:54] <lynxlynxlynx> no
[22:07:44] <edheldil_> hmmm
[22:07:45] <lynxlynxlynx> we take care of expanding the dialog to max if needed
[22:07:51] <lynxlynxlynx> so it probably didn't start at all
[22:08:05] <Pepelka> [commit] bradallred: TLKOverride: just use strdup (we use it elsewhere) https://github.com/gemrb/gemrb/commit/42b602e11c67f91328d67f5e416501f1fe8f4128
[22:08:06] <Pepelka> [commit] bradallred: remove some duplicated code https://github.com/gemrb/gemrb/commit/5bc0360433386e1dba410f4d8d75544bf231f57c
[22:08:08] <Pepelka> [commit] bradallred: Better fix for preventing actor jumping after hold/timestop https://github.com/gemrb/gemrb/commit/7d457adff8a1cd922a6ca2a0443d1662918c2fc5
[22:08:09] <Pepelka> [commit] bradallred: Remove the no_more_steps hack https://github.com/gemrb/gemrb/commit/b0346298cda4999a323863cc7b3e76d73a070024
[22:08:10] <Pepelka> [commit] bradallred: Make a Stop() method for scriptable https://github.com/gemrb/gemrb/commit/6aad792bc3da9abca7a752c636124b1bf3bba8e7
[22:08:11] <Pepelka> [commit] bradallred: I don’t believe there is a point in processing immobile actors here. https://github.com/gemrb/gemrb/commit/e885f3a3bb88c59a91034466460cf59d974cffb1
[22:08:12] <Pepelka> [commit] bradallred: Map::UpdateScripts: imprisonment and maze should stop actors https://github.com/gemrb/gemrb/commit/4da9bc293b8d59eb1da5a8ccc280d6bd38fa7e49
[22:09:21] <fuzzie> edheldil_: what's the trigger, True?
[22:09:43] <edheldil_> no triggers at all
[22:15:48] <fuzzie> maybe the problem?
[22:16:41] <fuzzie> hm, no, I guess it should default to true
[22:16:57] <edheldil_> no, it needed the trigger
[22:17:02] <edheldil_> now it opens
[22:17:06] <fuzzie> ah, well, yay :)
[22:17:18] <edheldil_> :)
[22:18:22] <edheldil_> thanks :)
[22:34:38] <brada> ed: are you fixing the dialogue bug chiv was on about?
[22:41:30] <chiv> hah that would make my day
[22:52:12] <edheldil_> no, I am just writing a python script that creates dialogue that opens any chosen store, for easier debugging
[22:52:40] <edheldil_> as pst has no console
[23:02:26] <brada> we cant just graft the console in?
[23:09:38] <edheldil_> real pst
[23:10:12] <-- Yoshimo has left IRC (Quit: Yoshimo)
[23:10:15] <edheldil_> afaik, the code is not there
[23:10:44] <edheldil_> ok, the script seems to work...
[23:11:19] <brada> ah
[23:27:26] <edheldil_> pushed to SF repo, if anyone's interested
[23:27:51] <edheldil_> iesh/dlg_stores.py
[23:28:20] <brada> did we not move all our stuff to github?
[23:29:47] <fuzzie> not unless there's a whole bunch of secret repositories hiding somewhere
[23:30:21] <edheldil_> I have not moved iesh yet, out of laziness
[23:36:10] <edheldil_> should Imove iesh to gemrb account at github?
[23:37:30] <Pepelka> [wiki] pst_bugs - [Animation] found source of broken avatar switching http://www.gemrb.org/wiki/doku.php?id=pst_bugs&rev=1386977784&do=diff
[23:38:11] <lynxlynxlynx> no need imo
[23:38:26] <lynxlynxlynx> we only moved the main repo
[23:39:23] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[23:55:38] <Pepelka> [wiki] pst_bugs - Italicise bugs that still need hunting down, to prevent blindness http://www.gemrb.org/wiki/doku.php?id=pst_bugs&rev=1386978854&do=diff
[23:56:25] <chiv> relatively few left to find...
[23:59:06] <chiv> I will start trying to fix some once I've finished my hunting mission, but I think the notes I left should prove useful in any case#