#gemrb@irc.freenode.net logs for 6 May 2013 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage


[00:25:02] <-- vampirefrog has left IRC (Quit: Leaving)
[04:06:31] <-- Maighstir_ has left IRC (Quit: .)
[07:18:38] --> WingedHussar has joined #gemrb
[08:13:51] <edheldil> I wonder - would it be possible to _completely_ control GemRB, so that we could write tests? E.g. script a complete game walkthrough
[08:14:04] --- ermo^ is now known as ermo
[08:14:19] <fuzzie> sure
[08:14:54] <fuzzie> the challenge is more, how do you control it?
[08:15:21] <edheldil> Not with IEScript, probably, but something that would "click" mouse, send keys and control rngs
[08:15:27] <fuzzie> but then it breaks too often
[08:15:41] <fuzzie> i mean, obviously the first step is to make Roll() feed from a stored source
[08:15:51] <fuzzie> but tiny fixes can completely change responses to input
[08:15:57] <edheldil> sure
[08:16:25] <fuzzie> so stored runs of input usually aren't useful beyond a few weeks at a time
[08:16:29] <edheldil> but most of the time, the "timelines" would soon converge again
[08:16:51] <fuzzie> sure, but how would you make them converge?
[08:17:51] <edheldil> hmm, the fact is, your targets could be elsewhere
[08:17:54] <fuzzie> i mean, say i change a minor script detail so that some actor takes an extra second to do something
[08:18:05] <fuzzie> now your RNG is out-of-sync
[08:18:12] <fuzzie> and so everything is in different places, etc
[08:18:17] <fuzzie> and spawns happen at different times
[08:18:52] <edheldil> right - but that mostly irons out on area transition, no?
[08:19:10] <fuzzie> yeah, but you can't actually get to the area transition at that point :)
[08:19:27] <fuzzie> (and assuming you force the seed back to whatever it should be on transition, but you could do tht)
[08:19:53] <fuzzie> you could perhaps do it a bit more realistically by having pairs of (savegame, event recording)
[08:20:27] <fuzzie> certainly I just have a bunch of savegames before troublesome points in the games, for loading and testing manually
[08:21:49] <edheldil> you are right that it would be more doable in these small chunks
[08:21:53] <fuzzie> but, well, the problem is equivalent to the problem of multiplayer: tiny problems or changes cause you to completely desync.
[08:22:48] <fuzzie> so I am universally discouraging about such ideas nowadays :-p
[08:22:50] <edheldil> but then, these tiny changes that make it desync is often what you are looking for - changes with collateral damage :)
[08:23:10] <fuzzie> sure, just you get a lot of red herrings too
[08:24:06] <fuzzie> but anyway, it'd be viable, I'm sure we could fairly trivially hook something up
[08:25:55] <edheldil> I was thinking about custom headless SDLVideo driver
[08:26:12] <edheldil> ... clone of ...
[08:27:09] <edheldil> although without the gfx lag, the timing would be hard to get right, probably
[08:27:21] <fuzzie> i don't think so
[08:27:29] <fuzzie> i mean, we run it in a single game loop
[08:27:48] <fuzzie> so, you can just record events by frame (i.e. how many times your event function got called)
[08:28:29] <fuzzie> and, make sure to record GetTickCount responses :)
[08:29:07] <fuzzie> you have to sabotage all these rand() calls which popped up too, maybe
[08:29:35] <edheldil> yeah, but quite possibly, it's a good thing to do anyway
[08:29:45] <fuzzie> although we do srand() ourselves
[09:02:57] --> Xelasarg has joined #gemrb
[09:03:21] <-- Xelasarg has left #gemrb
[14:14:06] --- ermo is now known as ermo^
[15:08:01] <-- WingedHussar has left IRC (Quit: WingedHussar)
[15:40:52] --> vampi-the-frog has joined #gemrb
[17:42:45] --> edheldil_ has joined #gemrb
[17:46:51] --> Yoshimo has joined #gemrb
[18:26:27] <-- edheldil_ has left IRC (Ping timeout: 252 seconds)
[19:00:50] --> edheldil_ has joined #gemrb
[19:52:27] --> fizzle has joined #gemrb
[19:54:44] <fizzle> what would be the preferred way to add a "spawned" flag to Actor? bitfield? bool? reuse InternalFlags?
[19:59:57] <-- Yoshimo has left IRC (Ping timeout: 252 seconds)
[20:18:28] <fuzzie> you have to do whatever the original does, right?
[20:18:52] <fizzle> no, why? just in what's written to disk
[20:19:04] <fuzzie> yes, but I mean, that's the place to start thinking
[20:19:42] <fuzzie> and that's .. gender, right? if you're thinking summoning cap, anyway
[20:19:53] <fizzle> well, it's a bool in ARE, but I don't see why that matters
[20:20:00] --> Yoshimo has joined #gemrb
[20:20:02] <fizzle> not summoning, spawning
[20:20:24] <fuzzie> well, I mean, it's not an InternalFlag if it's written to disk
[20:20:40] <fuzzie> it's a totally not internal at all flag
[20:21:14] <fuzzie> so if it's a bool in the area the logical approach would just be a bool
[20:22:00] <fuzzie> am I missing some obvious bit of logic there?
[20:22:03] <fizzle> fine with me but if we get more of those it seems like a bit of a waste
[20:22:27] <fuzzie> yes, this would be Avenger's argument
[20:22:52] <fuzzie> my argument is that it's a few bytes in a relatively rare data structure, we'll live :P
[20:23:50] <fuzzie> (and bool is fast)
[20:24:16] <fuzzie> as usual do as you want though, but InternalFlags at least isn't really the place I imagine
[20:24:47] <fizzle> okay
[20:25:49] <fuzzie> and we can worry about optimisation later
[20:27:26] --- ermo^ is now known as ermo
[20:28:56] <-- Yoshimo has left IRC (Quit: Yoshimo)
[20:39:43] <-- edheldil_ has left IRC (Ping timeout: 245 seconds)
[20:52:39] <-- vampi-the-frog has left IRC (Quit: Leaving)
[21:00:01] --- ermo is now known as ermo^
[22:38:16] <-- fizzle has left #gemrb
[23:52:11] --> vampi-the-frog has joined #gemrb