[00:05:01] <-- Maighstir has left #GemRb
[00:21:03] <goddard> sdf
[00:21:07] <goddard> opps
[00:41:33] <-- tomprince_loki has left IRC (Ping timeout: 265 seconds)
[02:09:56] <-- _pickle has left IRC (Remote host closed the connection)
[02:39:02] <-- budlust has left #GemRb
[02:40:12] --> Gekz has joined #GemRb
[03:41:19] <-- goddard has left IRC (Quit: leaving)
[03:50:14] <-- Gekz has left IRC (Quit: This computer has gone to sleep)
[03:59:32] <tomprince> Our handling of python imports is a bit buggy right now.
[04:00:01] <tomprince> Cause
[04:00:33] <tomprince> 'from GUICommon import *' just copies the *current* values of things like ClassTable.
[04:01:27] <tomprince> So, right now in PsT, LUCommon is loaded before LoadCommonTables is called, so that the version of ClassTable in LUCommon is None, even after LoadCommonTables is called.
[04:08:55] --> raevol has joined #GemRb
[04:19:39] <tomprince> fuzzie: This seems to fix the timing issues with pox's dialogue http://hermes.hocat.ca:4010/builders/cmake%20g%2B%2B-4.4.3/builds/67/steps/git/logs/patch
[04:19:45] <tomprince> Certainly a hack ....
[06:15:09] --> lynxlynxlynx has joined #GemRb
[06:15:10] --- ChanServ gives channel operator status to lynxlynxlynx
[06:21:18] --> Gekz has joined #GemRb
[06:23:09] --> cubathy has joined #GemRb
[06:41:31] <lynxlynxlynx> http://forums.gibberlings3.net/index.php?showtopic=19375&st=0entry168354 <-- who will burst the bubble?
[06:44:51] <tomprince> What bubble?
[06:47:25] <lynxlynxlynx> the scale of the attempt
[06:49:07] <tomprince> I would say cheer them on, rather than burst the bubble.
[06:49:42] * tomprince goes to bed
[06:50:55] <lynxlynxlynx> i've seen too many proclamations like that, not just in gemrb, to be optimistic
[06:54:47] <-- cubathy has left IRC (Remote host closed the connection)
[07:23:40] <-- raevol has left IRC (Quit: Leaving.)
[08:02:28] --> anji_ has joined #GemRb
[08:04:36] --> xrogaan_ has joined #GemRb
[08:04:36] <-- xrogaan_ has left IRC (Changing host)
[08:04:36] --> xrogaan_ has joined #GemRb
[08:04:40] --> pupnik_ has joined #GemRb
[08:06:27] * pupnik_ winces
[08:09:15] <-- pupnik has left IRC (*.net *.split)
[08:09:15] <-- |Cable| has left IRC (*.net *.split)
[08:09:16] <-- anji has left IRC (*.net *.split)
[08:09:16] <-- xrogaan has left IRC (*.net *.split)
[08:15:28] <fuzzie> tomprince: yeah, you break other dialog that way, so i wouldn't commit, but it is the idea
[08:15:53] --> |Cable| has joined #GemRb
[08:16:53] <fuzzie> the trouble being that (obviously) this stuff needs to actually be on the queue, so sigh
[08:20:51] <fuzzie> but the only real way to implement this stuff is to test it in the original engines first, and so it is a question of time and not code :)
[08:23:32] <lynxlynxlynx> btw, what were those "obviously broken" bits in ::Die/fx_death
[08:26:32] <fuzzie> most of the CheckOnDeath code should be in there too, for a start
[08:27:19] <fuzzie> and obviously we already know that the code is *in* fx_death, so there must not be any non-effect callers
[08:27:23] <fuzzie> but, again, messages..
[08:28:15] <lynxlynxlynx> ok
[08:28:22] <fuzzie> i forget the rest, should i make a list?
[08:29:00] <lynxlynxlynx> as long as you know it, it's fine
[08:29:15] <fuzzie> do we handle the verbal constant?
[08:29:21] <lynxlynxlynx> yes
[08:30:45] <lynxlynxlynx> i think it would be better to make a list of things we need to check in the original
[08:31:07] <lynxlynxlynx> since it is a lot of work, it pretty much has to be done systematically
[08:31:19] <fuzzie> got to remove hold, stun, icons for those, delete poison/disease, a lot of state fiddling, frozen/stone/etc death, set corpse removal time, complex stuff with the action queue, etc
[08:32:42] <fuzzie> yes, it would be a good idea to make a list of things to check in the originals
[08:34:12] <fuzzie> but technically even now i'm meant to be in an exam, so i am a bit pushed for time in general :)
[08:34:13] <lynxlynxlynx> and it is something our advanced users could help with
[08:38:15] <fuzzie> the trouble with the instants is that i know from elsewhere that it is not as nice as it looks: there's hardcoded behaviour in at least pst
[08:38:19] <fuzzie> and that is difficult to observe
[08:41:27] <fuzzie> my current #1 wish is to know how the local/global IDs work
[08:43:51] <lynxlynxlynx> where's the catch?
[08:44:29] <fuzzie> what in?
[08:45:08] <lynxlynxlynx> the ids
[08:45:26] <lynxlynxlynx> it sounds just like something you could trivially print in a script
[08:45:37] <fuzzie> they're internal use only
[08:45:57] <fuzzie> and they're truncated to a value which ends up identical in savegames
[08:46:15] <fuzzie> i should ask again, probably
[08:48:17] <-- |Cable| has left IRC (Remote host closed the connection)
[08:48:30] <fuzzie> but i spent so much time un-breaking our scripting that i would like to be sure about things before going changing things again
[08:48:47] <lynxlynxlynx> of course
[08:49:04] <lynxlynxlynx> we're in a pretty good state already
[08:49:44] <fuzzie> but even a trivial 100-line messaging queue improves some things tremendously
[08:50:09] <fuzzie> just that i have to sabotage all the localID stuff for that, and i have yet to work out why the localID exists at all.
[08:51:38] <lynxlynxlynx> :s
[08:51:41] <fuzzie> much easier if it is useless, but i learnt to stop assuming that :(
[08:52:24] <fuzzie> another thing we should fix is object matching, where for example [PC] should still match self
[08:52:43] <fuzzie> and after that, visibility, where [blah] should only match things which can be seen, if called by an actor
[08:53:09] <fuzzie> and then i think almost all this inactivity stuff can be removed
[08:53:28] <fuzzie> so that is the Plan for July :)
[08:54:59] <lynxlynxlynx> oh nice
[09:00:26] <fuzzie> and i guess i should fix cutscenes at some point, before tomprince refactors the code to the point where i can't any more :)
[09:01:22] <fuzzie> or maybe i can persuade him to, it is pretty trivial
[09:01:58] <lynxlynxlynx> ;)
[09:02:35] * fuzzie makes pleading eyes
[09:08:22] <fuzzie> although that listbox refactoring is maybe better
[09:48:02] <-- pupnik_ has left IRC (Quit: leaving)
[09:57:41] --> pupnik has joined #GemRb
[10:01:16] --> Maighstir|work has joined #GemRb
[10:31:17] <-- Gekz has left IRC (Remote host closed the connection)
[10:31:55] --> Gekz has joined #GemRb
[10:35:06] <-- Maighstir|work has left IRC (Quit: Page closed)
[10:59:02] <pupnik> this is it! this is Zha Jiang! 炸醬 http://yukiblog.pixnet.net/blog/post/28282785
[10:59:05] <pupnik> 4 euro per can
[11:17:06] --> budlust has joined #GemRb
[11:49:14] <-- budlust has left #GemRb
[12:12:10] <tomprince> fuzzie: Certainly, I can do the cutscene stuff, if you can tell me what the algorithm is.
[12:15:00] <fuzzie> you simply take the object from the first action of each block, and then queue the remaining actions on that object
[12:15:59] <fuzzie> although it is maybe slightly less trivial than that, because whilei think the objects are evaluated in the context of the caller, i don't know
[12:16:30] <tomprince> How do you determine the object? And do you do all the response blocks of each response set in order?
[12:17:14] <tomprince> Is it the first object param of the action? What thre is none. :)
[12:17:22] <fuzzie> the object is just a standard action object, so GetActorFromObject
[12:17:30] <fuzzie> and, yes, that :)
[12:17:42] <fuzzie> and if there isn't one i imagine you spout an error
[12:18:07] <fuzzie> in reality i imagine this might be where the Biff the Understudy and zombies and etc come in
[12:18:42] <fuzzie> actually, it's got to work for CutSceneId(Player6) when your party is empty, so i guess you ignore those blocks
[12:20:24] <fuzzie> afaik the only remotely tricky bits are CutSceneId(Myself) and CutSceneId([IDS matching])
[12:21:14] <fuzzie> so, i don't know if there's important missing information
[12:21:38] <tomprince> Well, I'll code something up, probably tomorrow.
[12:25:32] <-- Gekz has left IRC (Read error: Connection reset by peer)
[12:25:38] <fuzzie> but we have all this useless support stuff hanging around for code that doesn't work properly anyway
[12:26:29] --> Gekz has joined #GemRb
[12:27:02] <fuzzie> so it seems like a nice candidate to fix, with clear test cases :)
[12:30:03] <tomprince> Well, I can code up the fix, anyway.
[12:31:19] <fuzzie> sure
[12:31:42] <tomprince> Does it make any difference whether an action is on the queue?
[12:31:51] <fuzzie> you just add to the queue
[12:32:20] <tomprince> I am refering to the instant stuff.
[12:32:25] <fuzzie> oh
[12:32:26] <fuzzie> yes
[12:32:56] <tomprince> How so? Or is that something else unimplemented?
[12:33:13] <fuzzie> one of the games depends on it somewhere
[12:34:35] <fuzzie> usually i would assume it was pst, but pst's instant.ids seems pretty innocent
[12:35:19] <fuzzie> maybe it was pst and there's an ActionOverride in dialog somewhere?
[12:35:23] <tomprince> It just doesn't seem that we differentiate. Or is that the instant might not be instant, and directly executing it doesn't land it in CurrentAction?
[12:36:34] <fuzzie> well, i can think of two things: one of which is that the instant isn't instant, and the other of which is that one of the instants modifies the queue
[12:36:56] <fuzzie> but i'm not sure the latter can actually happen
[12:37:12] <fuzzie> because ActionOverride doesn't modify the queue, and ClearActions is a message
[12:37:26] <tomprince> So can we just add the instants to the queue first?
[12:37:42] <fuzzie> i don't think we should be executing the non-instants at all there
[12:39:12] <tomprince> So: Clear the queue, add the instants, force run it, add everything else?
[12:39:25] <tomprince> That should work at least for actors.
[12:39:29] <fuzzie> yes, except i'm fairly sure it's more complicated than that for reasons i don't remember.
[12:39:48] <fuzzie> if you actually try it, you don't actually get all the instants run immediately in all circumstances.
[12:40:01] <fuzzie> in pst, that is. i didn't look at the other games.
[12:40:44] <tomprince> Well, is that behavior enough closer to the correct behavior? Even if it isn't the final behavior?
[12:40:47] <fuzzie> it's possible that's simply caused by messages, though.
[12:41:03] <fuzzie> but i would prefer no-one mess with the dialog code until it is actually tested.
[12:41:37] <fuzzie> i know it's tempting to just sort of mess with things on the C++ side until they work for the script you're looking at and then commit it, but i spent months undoing the result of years of that and replacing it with correct code :P
[12:43:03] <tomprince> Well, I am not suggesting just testing it with one thing. But if it is closer to the correct behavior, even if it doesn't get everything absolutely right, if it is an improvement ....
[12:43:12] <fuzzie> sure, but what's the correct behaviour?
[12:43:30] <fuzzie> once you know that, the C++ side is almost always trivial
[12:44:39] <tomprince> 'course
[12:44:48] <fuzzie> kind of a general rule of reverse-engineering projects i guess :)
[12:45:47] <tomprince> :)
[12:45:48] <fuzzie> but as it is, committing the change above will break a lot of things
[12:46:08] <fuzzie> and that doesn't necessarily mean the change isn't the exact right thing to do
[12:46:22] <tomprince> This: Clear the queue, add the instants, force run it, add everything else?
[12:46:25] <fuzzie> but it means at least that someone's got to fix the actions first :)
[12:47:13] <fuzzie> either that, or just running the instants immediately
[12:47:50] <fuzzie> or indeed anything which exposes the sync flaws in our instant actions :)
[12:48:38] <fuzzie> i mean, i would suggest that you simply fix the action code
[12:48:50] <fuzzie> but you seem unmotivated to test things in the original engine, and that is 90% of the work
[12:50:04] <tomprince> At some point maybe, but I have enough other things on my plate. :)
[12:50:27] <fuzzie> i mean, it's not unique to you, everyone is unmotivated to do that :-)
[12:50:47] <fuzzie> even the people on forums who spend their time peering at the disassemblies sometimes get things completely wrong because no-one took the time to actually test
[12:53:03] <fuzzie> but the dialog/action code is in this state where the games are *playable*, and it would be too easy to regress
[12:53:30] <fuzzie> so much easier to test this stuff when you can just stick the binary into an emulator and use savestates :|
[13:01:57] <tomprince> One could perhaps use savevm/loadvm in qemu.
[13:03:24] <fuzzie> doesn't work, though, because the OS is in the way; i wonder if it would be possible to do something with wine
[13:03:58] <tomprince> How is the OS in the way?
[13:04:21] <tomprince> I admit I haven't tried it, but the description seems to say it takes a snapshot of everything in the VM.
[13:04:21] <fuzzie> you can't just change on-disk files, for instance
[13:04:30] <fuzzie> the OS has the filesystem cached and the files cached
[13:05:00] <fuzzie> and you can't just poke around in memory because the OS is doing all this paging etc
[13:05:18] <fuzzie> so you gain pretty much nothing from snapshotting a VM, for RE purposes
[13:05:32] <tomprince> I see what you mean.
[13:05:50] <fuzzie> well, repeatability is very useful to some people, i guess :)
[13:06:37] <wjp> wine and something like cryopid might be worth a shot
[13:07:03] <fuzzie> but i can run old DOS games under something like dosbox and you can just switch files from under them on-the-fly -- but part of that is simply because games of that era were so RAM-constrained and simple that it was standard just to hit the disk when they wanted anything new
[13:09:11] <fuzzie> a fun experiment when i have time, maybe :)
[13:27:20] --> budlust has joined #GemRb
[13:31:20] <fuzzie> that dialog stuff is definitely weirder than that patch
[13:37:50] <pupnik> maybe we can keep gemrb off winCE if it keeps requiring > 128MB
[13:38:12] <pupnik> sorry, i am crumpy
[13:39:55] <fuzzie> it's ok, winCE native apps are pretty much dead at this point :p
[13:41:26] <fuzzie> are there any consumer WinCE devices which run native apps planned?
[13:42:53] --> Maihgstir|work has joined #GemRb
[13:43:20] <fuzzie> can't find any at a glance
[13:44:12] <Maihgstir|work> I doubt any WinMobile 6.5 phones are planned, now that WinPhone 7 will soon be released.
[13:44:29] <Maihgstir|work> Not sure about non-phones though
[13:44:31] <fuzzie> well, there's an awful lot of Windows CE devices which aren't phones
[13:44:41] <fuzzie> but as far as I know they're all for corporations
[13:45:37] <fuzzie> everything else I can find (eg, the tablets Microsoft have been showing off) are just thereotical prototypes
[13:59:52] <-- Maihgstir|work has left IRC (Ping timeout: 252 seconds)
[14:05:54] <edheldil> hello
[14:06:09] <edheldil> back from some IPv5 conference
[14:06:13] <edheldil> v6
[14:06:25] <fuzzie> hello :)
[14:07:05] <fuzzie> my experience with ipv6 so far was good up until the point where i tried using Linux with it
[14:08:01] <fuzzie> and Google/youtube/etc randomly stopped working, confused me terribly until I realised they were on ipv6 here
[14:08:35] <fuzzie> are you conferency people going to fix that? pls? :)
[14:09:04] <edheldil> hehe
[14:09:29] <edheldil> actually, we use google on ipv6 here
[14:09:53] <fuzzie> it works delightfully well
[14:09:57] <edheldil> and we use ipv6 a lot. Sometimes it's more broken than v4, sometimes not
[14:10:04] <fuzzie> and the engineering folks are pretty good at fixing bugs when i report them
[14:11:04] <edheldil> we also do a lot of ipv6 advertising, hence the conference
[14:11:08] <fuzzie> their main problem seems to be their GeoIP code not handling ipv6
[14:11:14] <edheldil> yup
[14:11:45] <edheldil> actually, I think geoip can handle it, buit on in the free version
[14:11:54] <fuzzie> well, i mean, google's code :)
[14:11:58] <edheldil> not in the free version
[14:12:44] <fuzzie> but it's kind of scary, if not even Google can avoid 500 errors everywhere, i have no hope for the internet at large
[14:13:14] <edheldil> I don't like location aware services, last time I connected on ripe60 conference to google I got pages in dutch. grrr
[14:13:25] <fuzzie> hehe :-)
[14:13:42] <fuzzie> i find it very annoying whenever i go anywhere
[14:14:10] <fuzzie> but the conference was interesting/fun/something?
[14:14:30] <edheldil> partially. Some of it was an old vest to me
[14:15:02] <edheldil> because it was rehashing some material from ripe60 I have already seen
[14:15:22] <edheldil> like the delightful story of 184.108.40.206/8
[14:15:32] <fuzzie> it is a good story :)
[14:16:12] <edheldil> have you seen it?
[14:16:12] <fuzzie> my proposal for some kind of orbital laser ray to zap all the misconfigured equipment has seen little support :(
[14:16:20] <edheldil> hehe
[14:16:34] <fuzzie> well, i have seen someone presenting on the results of routing that block
[14:16:46] <fuzzie> with tales of cisco equipment's default example configuration pointing at 220.127.116.11, etc
[14:16:59] <wjp> poor APNIC getting stuck with this "interesting" block :-)
[14:17:08] <edheldil> and with GAME OVER inthe end?
[14:17:20] <fuzzie> i don't remember :)
[14:18:01] <edheldil> the heat graphs with space invaders
[14:19:42] <fuzzie> don't think so
[14:20:12] <fuzzie> but i imagine it was just a random presentation, i don't attend network conferences :)
[14:21:42] <edheldil> it was interesting and funny
[16:12:03] --> raevol has joined #GemRb
[16:15:09] <-- raevol has left IRC (Client Quit)
[17:36:42] --- Dark-Star|Zzz is now known as Dark-Star
[18:06:15] --> cubathy has joined #GemRb
[18:06:55] --> |Cable| has joined #GemRb
[19:17:10] <-- tomprince has left IRC (Ping timeout: 264 seconds)
[19:29:21] <-- anji_ has left IRC (Quit: ZNC)
[20:15:39] <-- budlust has left IRC (Remote host closed the connection)
[20:15:58] --> budlust has joined #GemRb
[20:46:06] <-- budlust has left IRC (Ping timeout: 240 seconds)
[20:49:43] --> budlust has joined #GemRb
[21:17:25] --> tomprince has joined #GemRb
[21:29:49] <-- budlust has left #GemRb
[21:45:03] <-- lynxlynxlynx has left IRC (Read error: Connection reset by peer)
[22:38:07] --- Dark-Star is now known as Dark-Star|away
[23:24:38] <-- cubathy has left IRC (Quit: Leaving)