[00:41] dreammaster (~dreammast@c-73-149-116-247.hsd1.ma.comcast.net) joined #scummvm. [00:41] #scummvm: mode change '+o dreammaster' by ChanServ!ChanServ@services. [01:00] GitHub168 (~GitHub168@192.30.252.42) joined #scummvm. [01:00] [scummvm] dreammaster pushed 1 new commit to master: https://git.io/vHn3W [01:00] scummvm/master f9f835e Paul Gilbert: TITANIC: Fix orientation threshold check in CStarControlSub24 [01:00] GitHub168 (GitHub168@192.30.252.42) left #scummvm. [01:07] Mia (~Mia@unaffiliated/mia) left irc: Read error: Connection reset by peer [01:15] Farmboy0 (~quassel@xoreos/farmboy0) left irc: Remote host closed the connection [01:21] GitHub6 (~GitHub6@192.30.252.40) joined #scummvm. [01:21] [scummvm] dreammaster pushed 1 new commit to master: https://git.io/vHns1 [01:21] scummvm/master 50a6100 Paul Gilbert: TITANIC: Simplify FVector addAndNormalize [01:21] GitHub6 (GitHub6@192.30.252.40) left #scummvm. [01:45] Dominus (~dominus@unaffiliated/dominus) left irc: Ping timeout: 260 seconds [01:46] Dominus (~dominus@unaffiliated/dominus) joined #scummvm. [02:24] snover (~snover@unaffiliated/snover) left irc: Ping timeout: 272 seconds [02:29] snover (~snover@unaffiliated/snover) joined #scummvm. [02:29] #scummvm: mode change '+o snover' by ChanServ!ChanServ@services. [02:44] Littleboy (~littleboy@c-73-4-50-241.hsd1.ma.comcast.net) left irc: Quit: Ętre dans le vent, une ambition de feuille morte. [03:14] aww. lsl6hires. you naughty game, calling an empty kernel function in your code and depending upon whatever random value was in the accumulator already to do different stuff. [03:19] Naughty Naughty :P [03:24] GitHub132 (~GitHub132@192.30.252.45) joined #scummvm. [03:24] [scummvm] dreammaster pushed 1 new commit to master: https://git.io/vHnCs [03:24] scummvm/master 7d8cff0 Paul Gilbert: TITANIC: Fix calculation of acceleration powers table [03:24] GitHub132 (GitHub132@192.30.252.45) left #scummvm. [03:37] dreammaster (~dreammast@c-73-149-116-247.hsd1.ma.comcast.net) left irc: [03:44] _t0by: Sorry, I fell sleep yesterday. [03:46] _sev, t0by: Ok, I see the part of code #ifdef'd you mentioned . I continue to replace file functions now. [03:47] Morning, everyone:) [04:24] Begasus (~begasus@ptr-4p6jpimbynv1k0nyyqz.18120a2.ip6.access.telenet.be) joined #scummvm. [04:40] Begas_VBox (~Begasus@d54C3C8C2.access.telenet.be) joined #scummvm. [04:49] I have a question. What is the advantage of creating a SeekableReadStream instead of using seek() of Common::FIle to read game data? [04:53] I think it's possible to pass a Common::File pointer everywhere to read data just like what we do with standard functions. Is there any problem of doing so? [05:02] using Streams instead of Common::File allows to reuse the same code to work with the data whether it comes from a file or from memory, or from anything else in ScummVM that produces a stream [05:03] (Common::File is just a dumb wrapper around SearchMan and SeekableReadStream anyway) [05:15] bgK: Thanks, I think I get the idea. But when do we have SeekableReadStream from memory? [05:18] you can instanciate the MemoryReadStream class to get the SeekableReadStream API for a chunk of memory [05:20] Ok, I see. Thanks! :) [05:25] Lightkey (~Darklock@p200300764C7B178622CF30FFFE083718.dip0.t-ipconnect.de) left irc: Ping timeout: 260 seconds [05:37] Lightkey (~Darklock@p200300764C7B178822CF30FFFE083718.dip0.t-ipconnect.de) joined #scummvm. [05:51] ny00123 (~ny00123@dsl217-132-0-115.bb.netvision.net.il) joined #scummvm. [06:12] Polynomial-C (~Poly-C@gentoo/developer/Polynomial-C) joined #scummvm. [06:45] m_kiewitz (~m_kiewitz@x4d03c1e8.dyn.telefonica.de) joined #scummvm. [06:45] m_kiewitz (~m_kiewitz@x4d03c1e8.dyn.telefonica.de) left irc: Changing host [06:45] m_kiewitz (~m_kiewitz@scummvm/undead/m-kiewitz) joined #scummvm. [06:45] #scummvm: mode change '+o m_kiewitz' by ChanServ!ChanServ@services. [07:39] GitHub169 (~GitHub169@192.30.252.45) joined #scummvm. [07:39] [scummvm] sev- closed pull request #947: GRAPHICS: Include bytesPerPixel in toString representation (master...graphics_pixelformat) https://git.io/v9ula [07:39] GitHub169 (GitHub169@192.30.252.45) left #scummvm. [07:39] GitHub116 (~GitHub116@192.30.252.42) joined #scummvm. [07:39] [scummvm] sev- pushed 1 new commit to master: https://git.io/vHnRm [07:39] scummvm/master 57eda6a Vincent Pelletier: GRAPHICS: Include bytesPerPixel in toString representation [07:39] GitHub116 (GitHub116@192.30.252.42) left #scummvm. [07:48] LittleToonCat (~littlecat@47.54.148.237) left irc: Remote host closed the connection [08:22] I remember a fun bug my brothers and I triggered in Mixed-Up Fairy Tales when we were kids. Try walking back into the hedge maze when the Beast is hopping towards you. "Oops! You did something we weren't expecting" because why would someone go towards their attacker? :p [08:25] Deledrius: if you can still reproduce it, please do and report is as a bug [08:26] Yeah I was just thinking, I should see if I can replicate it in ScummVM [08:26] It should be pretty easy. [08:26] It's been a long time since I've played, but the bug itself was simple to trigger, IIRC. [08:26] Seeing the discussion above about the long list of QfG4 bugs reminded me. [08:27] QfG4 was so good, even despite those. [08:40] I still never really played any of the qfg games [08:41] TMM: you should they are all great (except for the VGA remake of qfg1) [08:55] wjp: is there an opcode that pops the stack and puts it into acc? [08:59] I was about to say 'of course', but maybe not... [09:01] it seems i have to do a ldi 0, add [09:02] would this even work on an object? [09:02] I'm a little worried of the heisenbugs I've had the last two games. I don't see any errors in valgrind during game start either. [09:02] girafe (~girafe@LFbn-1-11729-221.w2-7.abo.wanadoo.fr) joined #scummvm. [09:02] heisenbugs? [09:03] I can't find any reason why lsl7 would be misdetected, and I can't see why phant2 would give that error only once [09:03] m_kiewitz, bugs that seem to go away when you look into them :P (heisenberg uncertainty principle) [09:04] ah [09:04] after each one I have done a recompile of scummvm, and I didn't keep the old binary, it *could* be some 'interesting' bug related to order of building [09:05] but that doesn't really make me any less worried [09:09] Polynomial-C (~Poly-C@gentoo/developer/Polynomial-C) left irc: Remote host closed the connection [09:13] m_kiewitz: adding 0 will trigger arithmetic errors with objects AFAIK [09:13] :/ [09:14] (with a workaround table...) [09:15] but maybe there's an alternative solution bypassing the accumulator? [09:17] for the workaround would it be possible to select an unused tempvar slot, dump the current acc in there, do your thing and read it back? [09:18] wjp: i need to save some bytes, but I guess I can go another way [09:22] Mia (~Mia@unaffiliated/mia) joined #scummvm. [09:25] wjp: toss removes 1 reg_t from stack, correct? [09:27] yes [09:28] Begas_VBox (~Begasus@d54C3C8C2.access.telenet.be) left irc: Quit: Vision[0.9.8]: i've been blurred! [09:28] Polynomial-C (~Poly-C@gentoo/developer/Polynomial-C) joined #scummvm. [09:32] I'm replacing fread functions, so how do we replace these 2 lines of code? [09:32] https://www.irccloud.com/pastebin/wwOsX7yh/ [09:35] SeekableReadStream and File have a 'read' function that does this [09:38] I didn't find a read of 3 paramters, so just "read(tmp, 8)" here? [09:38] waltervn (~waltervn@541B2DBA.cm-5-4a.dynamic.ziggo.nl) joined #scummvm. [09:38] #scummvm: mode change '+o waltervn' by ChanServ!ChanServ@services. [09:38] yes [09:39] wjp: Thanks, And for fopen(filename, "wt"), what do we have? [09:41] that depends on what the output file is going to be used for [09:41] we assume the game data itself is read-only and we shouldn't write to it (or the game data directory) [09:42] Yes, it's just for saving files [09:43] Maybe I leave them there at present [09:43] for things like savegames, or settings files maintained by the scripts themselves, there's the SaveFileManager [09:44] Common::WriteStream *outFile = engine->getSaveFileManager()->openForSaving(filename, compress); [09:45] (with a matching openForLoading) [09:45] wjp: Ah, thanks, it's exactly I'm looking for [09:46] it's considered good practice to put the name of the engine and/or gameid into the filename, to avoid files "leaking" between different games and engines [09:47] Ok, I see. I note it. [09:51] Farmboy0 (~quassel@p5DD10015.dip0.t-ipconnect.de) joined #scummvm. [09:51] Farmboy0 (~quassel@p5DD10015.dip0.t-ipconnect.de) left irc: Changing host [09:51] Farmboy0 (~quassel@xoreos/farmboy0) joined #scummvm. [10:08] wjp: hmm i think i have fixed the qfg4 slope crash now. However ego will now just float around until he slides down the slope in the end (because there is no cycler) [10:09] not sure if that's fine. I don't even know if ego actually walking around was intentionally done [10:11] I'm a little surprised just how buggy these games can be [10:12] how can they even generate bad opcodes, they had a compiler for sci right? [10:12] bad opcodes? [10:12] well, sorry, I mean illegal sequences [10:12] like, things that are illegal in sci [10:12] well in qfg4 case it's simply a call to a nullptr [10:13] that happens, it's basically a coding error [10:13] I was just going through some of the workarounds/hotpatches in the sci engine directory [10:13] no way for the compiler to figure the possibility out [10:13] ah [10:13] well for the workarounds there are also plenty of coding errors [10:13] m_kiewitz: NRS may have a different fix [10:14] there is of course also a design issue in SCI, where the VM never deletes the temp variable space [10:14] wjp: yes, I have already looked into that one [10:14] he literally waits within sFallsBackSide::changeState(0) for 1 tick (by doing a loop) [10:15] im instead fixing the coding bug inside Grooper::doit, so that it's able to handle actors in a specific situation when there is no cycler active [10:16] Another question. How to replace "rewind(fp);" ? :) [10:19] Simei, File has a ::seek() [10:19] m_kiewitz, I was unable to reproduce the Beast crash in Mixed-Up Fairy Tales. Looks like it's fixed. ^_^ [10:19] Simei, seek(0) should be equivalent [10:19] we didn't fix it [10:19] but maybe the speed throttling is responsible, idk [10:19] TMM: Ah, ok. Thanks! [10:19] Yeah. I just mean it's not bugged in ScummVM. [10:22] TMM (hp@fsf/member/pdpc.professional.tmm) left #scummvm ("Ex-Chat"). [10:22] TMM (~hp@fsf/member/pdpc.professional.tmm) joined #scummvm. [10:22] #scummvm: mode change '+o TMM' by ChanServ!ChanServ@services. [10:22] Simei, if you install 'manpages-dev' you can do things like 'man rewind' to figure out what a call actually does. Then finding an equivalent call in common/ is much easier [10:23] m_kiewitz: does NRS do that by recompiling, or is there room in the script? [10:23] recompiled of course [10:24] and i don't think that waiting for 1 tick or so in an inner loop is a good fix anyway [10:24] TMM: Ah, thanks, I just found that I actually have it [10:25] Simei, it's a great resource for porting [10:26] Ok, I will use it. :) [10:26] Simei, to make sure you get the C library version you should always search in sections 1 or 3. so man 3 rewind and man 1 open. You can also try 'apropos open' for instance to see in what sections an 'open' like thing is defined [10:26] Simei, linux system calls are usually documented in section 1, c library functions in section 3 [10:27] Simei, initially it is ok to just try both, you'll get a feel for what is in what section as you begin to understand the systems' layering. But that'll come by itself. [10:28] Simei, err, system calls are in section 2, not section 1, sorry. So 'man 2 open' not 'man 1 open' [10:30] TMM, yes, they gave different things. I'll note it [10:30] Thanks. :) [10:30] Simei, yw. take a good look at the top line of 'man 3 open' for instance [10:31] TMM: ? [10:31] Simei, open(3pm) the stuff between () is the section number. So in this case man helpfully opened section 3*pm* (perl manual) because there was no 'open' in section 3 [10:31] wjp, ? [10:32] wjp, I figured if you're porting 'plain c' code to osystem it would be helpful to know how to find the documentation on the non-osystem calls [10:32] I was very confused why you'd try 3 open [10:32] wjp, I was just trying to explain that man will display what section you're actually in, in case you get something unexpected [10:33] man 3 open gives "See 'man 7 undocumented' for help when manual pages are not available." [10:33] assuming you have perl manpages installed at all [10:33] (which I don't, for example) [10:33] sure [10:34] Simei, try man 1 open then, that should give you a manpage for openvt, the point is that you should look at the very top line of a manpage :) [10:34] OPENVT(1) Linux 1.x OPENVT(1) [10:35] For man 2 open is [10:35] OPEN(2) Linux Programmer's Manual OPEN(2) [10:36] Hmm, I think I have the main idea of them [10:37] That's useful. Thanks [10:37] :) [10:59] omer_mor (~Omer@46-117-132-33.bb.netvision.net.il) joined #scummvm. [11:01] omer_mor_ (~Omer@46-117-132-33.bb.netvision.net.il) left irc: Ping timeout: 240 seconds [11:27] Simei: section 1 are commandline tools, probably not very relevant in this context [11:27] Simei: see "man N intro" (with N = 1, 2, ...) [11:31] Begas_VBox (~Begasus@d54C3C8C2.access.telenet.be) joined #scummvm. [11:34] GitHub122 (~GitHub122@192.30.252.42) joined #scummvm. [11:34] [scummvm] bluegr pushed 2 new commits to master: https://git.io/vHn2V [11:34] scummvm/master 03c1b33 Filippos Karapetis: SCI: Remove a leftover SCI32 hack [11:34] scummvm/master a8b3b67 Filippos Karapetis: SCI32: Update some old comments related to virtual files [11:34] GitHub122 (GitHub122@192.30.252.42) left #scummvm. [11:37] logix: Yes, it seems so. I note it. Thanks [11:38] _sev, t0by: I've replaced the file reading functions and pushed it. Not the file writing functions yet. [11:38] https://github.com/yinsimei/scummvm/commits/newWIP1-1 [11:40] _sev: By the way, _sev, last time you mentioned "make atomic commit". I think I don't get what it means exactly. Could you give an example? [11:41] _sev, t0by: I've a group work meeting with my classmates this afternoon. I'll be back in around 4 hours. [11:41] Simei: I think he means split up commits as much as possible, i.e., as long as it still makes sense [11:42] logix: Ah, ok, I get it. [11:43] Strangerke_ (~Strangerk@cable-85.28.84.13.coditel.net) joined #scummvm. [11:43] Simei: so don't fix audio and graphics in one commit, fix audio in one and graphics in a second - but you obviously don't want one commit per line changed because a single line change (usually) doesn't fix anything, add a feature etc. [11:45] So, even these changes are in one file [11:45] We make one change first and commit, then the other one? [11:45] Strangerke (~Strangerk@cable-85.28.84.13.coditel.net) left irc: Ping timeout: 260 seconds [11:45] Nick change: Strangerke_ -> Strangerke [11:46] correct - but it is absolutely ok to change more than one file at once (a usual case would be a .c/.cc/... file and a corresponding .h file) [11:48] Simei: for two changes within the same file, if you can separate the two into two separate commits, and it then turns out that something seemingly unrelated broke, it's easier to find the problem than if you had made both changes in one commit [11:48] that's the main idea [11:49] so in this case: revert both commits, everything works - apply first commit, it still works, apply second, it breaks, so now you know that you only have to debug the code you changed in the second commit [12:08] Ok, I get it. It seems I still put too much things in one single commit. :/ [12:08] Mia (~Mia@unaffiliated/mia) left irc: Ping timeout: 260 seconds [12:09] I'll try to split it later. :/ [12:09] logix: Thanks a lot. :) [12:18] you're welcome [12:19] Simei: oh, also, another reason for atomic commits is that it's easier to review them [12:20] somebody (I suppose t0by) looks at a small commit and can say "yup, looks right", and then move on to the next commit and mostly forget about the first one [12:21] compare that to something that fixes 100 completely different issues at once - it's a lot harder to understand what's happening there [12:21] or similarly, imagine you fix issue A, then later will fix issue B but you know that for B you need a helper function that you've already written, so you decide to add that right away in commit A [12:22] the reviewer looks at that and has no idea what the helper function is doing there [12:29] WooShell (~Markus@ipbcc06af5.dynamic.kabel-deutschland.de) joined #scummvm. [12:30] t0by (~t0by@unaffiliated/t0by) joined #scummvm. [12:30] #scummvm: mode change '+o t0by' by ChanServ!ChanServ@services. [12:31] Mia (~Mia@unaffiliated/mia) joined #scummvm. [12:31] Afternoon, peppes [12:31] *peeps [12:31] did I miss anything? [12:32] Hrrrm [12:32] Simei, when we say "atomic commits" we say something roughly like this: [12:33] each commit is the *minimal* set of modifications that brings your project to a different and self-consistent status. [12:33] The implication is two fold: [12:33] *twofold [12:33] 1. if you do two different "things" (e.g. patch a method and add an unrelated class), that's two commits [12:33] 2. your commit shall not include unnecessary modifications [12:34] The reason for this is manyfold, but the *main idea* of a VCS like git is that your work is represented as a graph of individual modifications. [12:35] This way, you can reorganize them, remove an individual one, I myself can only add *one* of your commits on top of my work for testing, etc etc. [12:35] Or, you can compare different commits by compiling and running the tree and see *which* commit introduces a bug. [12:36] If the commit is indeed atomic, you know *exactly* how you broke it. [12:37] Simei: for example adding detection for Welcome2 in your commit should ideally be its own commit. [12:37] Simei: also *generally* you want to avoid committing empty lines such as https://github.com/yinsimei/scummvm/commit/ef0836111f6ae41780ab0a6fe16beea1ced82dad#diff-45a1c974a22ab8db9bde8529998ed7c5L32 [12:38] git isn't smart enough to know that they are "just" empty lines and make history more difficult to read and manipulating commits more cumbersome. [12:38] Simei: anyway -- good work, thanks! Does it work? [12:39] Simei, _sev: if this works I think, alas, the time to work on sprite loading has come? [12:40] _sev: how do you feel about it? [12:45] Henke37 (~Henrik@81-227-16-59-no133.bredband.skanova.com) joined #scummvm. [12:53] meow =^.^= [13:09] Vampire0 (~Vampire@jEdit/Vampire) left irc: Ping timeout: 246 seconds [13:11] ajax16384 (~User@109.60.130.33) joined #scummvm. [13:11] #scummvm: mode change '+o ajax16384' by ChanServ!ChanServ@services. [13:19] Begas_VBox (~Begasus@d54C3C8C2.access.telenet.be) left irc: Quit: Vision[0.9.8]: i've been blurred! [13:37] digitall (~digitall@unaffiliated/digitall) joined #scummvm. [13:37] #scummvm: mode change '+o digitall' by ChanServ!ChanServ@services. [13:55] t0by (~t0by@unaffiliated/t0by) left irc: Read error: Connection reset by peer [13:56] t0by (~t0by@unaffiliated/t0by) joined #scummvm. [13:56] #scummvm: mode change '+o t0by' by ChanServ!ChanServ@services. [13:57] Gentle (~tier@quassel/contributors/gentle) left irc: Ping timeout: 255 seconds [14:01] logix, I didn't know about man N intro, thanks [14:07] TMM: anytime - and yeah, it's hard to run into it by accident, that is, by following "see also" links in other manpages one might read [14:09] digitall (digitall@unaffiliated/digitall) left #scummvm. [14:15] Begas_VBox (~Begasus@d54C3C8C2.access.telenet.be) joined #scummvm. [14:16] Gentle (~tier@quassel/contributors/gentle) joined #scummvm. [14:50] Begas_VBox (~Begasus@d54C3C8C2.access.telenet.be) left irc: Read error: Connection reset by peer [14:53] Begasus (~begasus@ptr-4p6jpimbynv1k0nyyqz.18120a2.ip6.access.telenet.be) left irc: Ping timeout: 246 seconds [14:54] Strangerke (~Strangerk@cable-85.28.84.13.coditel.net) left irc: Ping timeout: 246 seconds [14:55] Strangerke (~Strangerk@cable-85.28.84.13.coditel.net) joined #scummvm. [14:56] Begasus (~begasus@ptr-4p6jpiotj275f1pwfwt.18120a2.ip6.access.telenet.be) joined #scummvm. [15:01] Begas_VBox (~Begasus@d54c3c8c2.access.telenet.be) joined #scummvm. [15:18] t0by (t0by@unaffiliated/t0by) left #scummvm. [15:19] t0by (~t0by@unaffiliated/t0by) joined #scummvm. [15:19] #scummvm: mode change '+o t0by' by ChanServ!ChanServ@services. [15:39] LittleToonCat (~littlecat@47.54.148.237) joined #scummvm. [15:58] Vampire0 (~Vampire@jEdit/Vampire) joined #scummvm. [16:07] Mataniko (~EmeraldM3@cpe-184-153-5-143.nyc.res.rr.com) left irc: Read error: Connection reset by peer [16:19] m_kiewitz: fwiw, waiting for 1 tick is essentially what the frame throttler does to fix the various timer-related bugs. i dont think its any worse to do that in a script patch. [16:28] Begasus (~begasus@ptr-4p6jpiotj275f1pwfwt.18120a2.ip6.access.telenet.be) left irc: Ping timeout: 246 seconds [16:29] I wonder if we could even make a special client hook / guest addition for inserting such frame throttling [16:29] (in a low number of bytes) [16:32] wjp: snover added a kernel call to get kWait back [16:32] it costs 7 bytes afaik [16:32] ah ok [16:34] t0by (~t0by@unaffiliated/t0by) left irc: Quit: t0by [16:35] and in any case one could also add another state and set ticks to 1 to get a ::cue [16:35] still i do not fully understand what is happening internally [16:36] during the setup call multiple Grooper::doit calls are made [16:36] in the second cycler is 0:0 [16:36] and a new cycler is set up afterwards in cases where it doesn't error out [16:36] weirdly i have fixed the bug inside Grooper::doit and no new cycler is set up and thus ego slides around without animation [16:37] the buggy code that is not able to handle no cycler is called when loop is the last loop possible, which is why i don't fully understand why even waiting for 1 tick works in the end [16:38] cycler is still 0:0 on the second call [16:40] Begasus (~begasus@ptr-4p6jpiotj275f1pwfwt.18120a2.ip6.access.telenet.be) joined #scummvm. [16:48] if necessary it would be possible to reduce the cost of a kScummVMWait(1) call further by adding a zero-argument variant that defaults to 1 tick for scenarios like this, or if we need to get really crazy, we could steal one of the unused opcodes to make it a 2 or 3 byte operation [16:50] the number of instructions necessary for a spinloop gives more than enough bytes to do a normal kcall (which was the original reason for adding that kcall) [17:03] for this one, i think i can get up to 4 bytes only [17:04] ah that actually would work out then [17:04] (kScummVMWait() [17:16] oh, there are special sci opcodes for broken games? [17:16] fun! :) [17:17] logix, t0by: Thanks a lot for informations about "atomic commit". So now at least I will split detection for Welcome2 out of this huge commit. I'll pay attention next time. :) [17:17] special kernel calls, not opcodes (yet); kScummVMWait adds support for kernel wait back to SCI32 games (SCI16 had this function but sierra deleted it for no good reason), and kScummVMSaveLoad which is used to support save/load integration with ScummVM [17:18] ah, so those are patched into the games like the other workarounds? [17:19] they are added to the kernel table in Kernel::loadKernelNames, kScummVMWait is patched using normal script patches, save/load is patched in GuestAdditions [17:23] _sev, t0by: I re-test it. debug logs are well printed. But I haven't changed the file writing functions yet, as they don't have much effects for now. So, I continue to complete this file thing ? [17:23] <_sev> Simei: regarding the atomic commits [17:23] _sev, t0by: Then we move to graphics? [17:24] <_sev> Simei: they contain one single thing, e.g if you fix some bug, make it a separate commit. And they should be small [17:24] <_sev> Simei: in this case, you could split big file-related commit into several, so it is easier to review then [17:24] <_sev> Simei: yep, graphics [17:31] _sev: Ok, I see. So I image for replacing functions like this. It would be better to change only some of the files, leave others in #ifdef and then make a first commit [17:31] <_sev> Simei: exactly [17:32] _sev, t0by: For the graphics, where should I start? [17:32] <_sev> Simei: do the initGraphics() call [17:33] <_sev> Simei: our graphics is a Surface with required bit depth, so you need to see how the original was rendering [17:33] <_sev> let me see the code [17:34] <_sev> Simei: btw, current code does not compile for me [17:34] <_sev> Undefined symbols for architecture x86_64: [17:34] <_sev> "Sludge::showSetupWindow()", referenced from: [17:34] t0by (~t0by@unaffiliated/t0by) joined #scummvm. [17:34] #scummvm: mode change '+o t0by' by ChanServ!ChanServ@services. [17:34] <_sev> Simei: I see it is in winstuff.cpp Did you forget to put it to module.mk? [17:35] Ah, it's true. As I work on linux, I forget about that stuff [17:35] Evening [17:36] Littleboy (~littleboy@c-73-4-50-241.hsd1.ma.comcast.net) joined #scummvm. [17:36] #scummvm: mode change '+o Littleboy' by ChanServ!ChanServ@services. [17:36] <_sev> Simei: I'm on Mac [17:37] Simei, _sev: note that at the moment everything is pretty much borked because of what I said yesterday about uninitialized stuff from loadSprites [17:37] loadSpriteBank [17:37] <_sev> Simei: but lunuxstuff.cpp is commented out in module.mk [17:38] _sev: True, I'll add them both. But why the code can compile for me? :/ [17:38] <_sev> no idea [17:42] Mellified_Man (~Mellified@eddie.mellified.com) left irc: Ping timeout: 240 seconds [17:43] https://www.irccloud.com/pastebin/UGa9kQ2R/ [17:43] _sev: there are some of these codes [17:44] Could it be that you have old .o files still lying around? [17:44] make clean perhaps? [17:44] <_sev> Simei: all those must be eventually removed [17:45] Ok, I will put them all in #if0endif ? Or remove them now ? and then to make code compile ? [17:45] <_sev> err [17:45] <_sev> when you understand what is the difference [17:45] <_sev> and make your code platform-agnistic [17:46] <_sev> so, just ignore it for now perhaps [17:46] <_sev> ignore the fact that I cannot link [17:47] Simei: I was bored, so I took the liberty of cleaning up a bit the mess that is loadSpriteBank in the original sludge engine [17:47] Particularly, I've neatly separated PNG, GL and file reading stuff [17:47] Ok, so we move on to the graphics ignoring this? [17:47] https://github.com/opensludge/opensludge/compare/master...tobiatesan:refactor [17:47] In a short while I'll patch your ScummVM tree accordingly and PR you. [17:48] (note: this is *not* how you commit stuff, it's just something quick & dirty for me( [17:48] Feel free to use it as reference if needed in the meanwhile [17:48] ("A short while" is probably after dinner) [17:51] Simei: looking at your latest commit looks like you haven't touched loadSpriteBank yet -- which is good. [17:54] _sev, Simei: oh, actually I forgot to exit on error -- i.e. the functions I added should be inside if (!...) return [17:59] Begasus (~begasus@ptr-4p6jpiotj275f1pwfwt.18120a2.ip6.access.telenet.be) left irc: Ping timeout: 258 seconds [17:59] Begas_VBox (~Begasus@d54c3c8c2.access.telenet.be) left irc: Ping timeout: 272 seconds [18:01] There, fixed. [18:04] Mellified_Man (~Mellified@192.64.190.17) joined #scummvm. [18:08] what is the easiest way of copying structs between idbs? [18:11] t0by (~t0by@unaffiliated/t0by) left irc: Ping timeout: 272 seconds [18:11] Begasus (~begasus@ptr-4p6jpim79clnw2urlo5.18120a2.ip6.access.telenet.be) joined #scummvm. [18:15] snover: File > Produce file > Dump typeinfo to IDC file ? [18:18] bgK: oh, right. i forgot about that. thanks :) [18:19] Mellified_Man (~Mellified@192.64.190.17) left irc: Ping timeout: 246 seconds [18:20] t0by: Ok, I'll wait for your PR then. But I split my last commit into several relatively small one just now. Does this make a mess for you ? [18:24] Begasus (~begasus@ptr-4p6jpim79clnw2urlo5.18120a2.ip6.access.telenet.be) left irc: Quit: Ex-Chat [18:25] _sev, t0by: I split my last commit into several relatively small ones just now. But I just realized this may make a mess for you. Is this ok ? [18:25] Mellified_Man (~Mellified@eddie.mellified.com) joined #scummvm. [18:28] m_kiewitz, snover: I added a commit moving bpk/logkernel to the main breakpoint list [18:32] one small interface change is that to catch all DoSound subcalls, you now say 'bpk DoSound*'. Not sure if that's better than matching on DoSound. [18:37] t0by (~t0by@host191-242-dynamic.16-79-r.retail.telecomitalia.it) joined #scummvm. [18:37] t0by (~t0by@host191-242-dynamic.16-79-r.retail.telecomitalia.it) left irc: Changing host [18:37] t0by (~t0by@unaffiliated/t0by) joined #scummvm. [18:37] #scummvm: mode change '+o t0by' by ChanServ!ChanServ@services. [18:46] ajax16384 (~User@109.60.130.33) left irc: Read error: Connection reset by peer [18:57] dreammaster (~dreammast@c-73-149-116-247.hsd1.ma.comcast.net) joined #scummvm. [18:57] #scummvm: mode change '+o dreammaster' by ChanServ!ChanServ@services. [18:58] wjp: IIRC, for kcalls with subops, the main function is not ever used, so it seems a little weird to have to know whether or not your kcall has subops since e.g. `bpk DoSound` will never do anything [18:59] but, honestly, its not that much of a problem; if it makes the breakpoint code easier to understand, then thats probably a worthwhile tradeoff [19:02] it'll at least tell you: [19:02] debug> bpk DoSound [19:02] No kernel functions match DoSound. [19:02] oh, ok, nice. in that case, this behaviour sounds fine. [19:14] GitHub118 (~GitHub118@192.30.252.45) joined #scummvm. [19:14] [scummvm] dreammaster pushed 1 new commit to master: https://git.io/vHn5Z [19:14] scummvm/master cb527ac Paul Gilbert: TITANIC: Rename _powers array to _speeds [19:14] GitHub118 (GitHub118@192.30.252.45) left #scummvm. [19:17] Vampire0 (~Vampire@jEdit/Vampire) left irc: Ping timeout: 268 seconds [19:24] blah. some smart cookie at sierra reordered some of the audio channel properties in GK2. [19:24] its like they didnt care that someone would have to reverse engineer it 20 years later& [19:30] so inconsiderate [19:35] Mia (~Mia@unaffiliated/mia) left irc: Read error: Connection reset by peer [19:41] snover, write a strongly worded letter [19:47] Simei: hey, how's it going? [19:49] t0by (~t0by@unaffiliated/t0by) left irc: Quit: t0by [19:49] t0by (~t0by@unaffiliated/t0by) joined #scummvm. [19:49] #scummvm: mode change '+o t0by' by ChanServ!ChanServ@services. [19:50] Strangerke_ (~Strangerk@cable-85.28.84.13.coditel.net) joined #scummvm. [19:52] snover: reordered? [19:53] Strangerke (~Strangerk@cable-85.28.84.13.coditel.net) left irc: Ping timeout: 268 seconds [19:53] Nick change: Strangerke_ -> Strangerke [19:53] yes, things like, `robot` boolean was at 0x80 in SQ6, now it is at 0x88 [19:54] sample rate was at 0x7c, now it is at 0x80 [19:58] maybe compiler? [19:58] really weird [19:58] Mmmh compiler? [19:59] t0by, _sev: Ah, sorry, I didn't understand what I should do now exactly. I thought I was waiting your PR to patch my tree or _sev's instructions on how "initGraphics()" things and rendering are working in the original sludge file. [19:59] IIRC, C++ compilers are not allowed to reorder structs, they are only allowed to reorder blocks of private/protected/public [19:59] Simei: if you didn't understand what you should do... you ask instead of wasting precious time :P [20:00] Simei: so, what's the status at present? [20:00] was sci32 compiled with a C++ compiler? sci16 was written in regular C if I remember correctly [20:00] yes, but that is not relevant, as the reason why C++ forbids this is for compatibility with C [20:01] hmmm, very weird then [20:01] although who knows, it's not like C/C++ compilers do everything correctly all the time [20:02] Simei: you have a PR for the loadSprite thingy. It's something very quick and dirty and I was waiting for _sev's input, but whatever, if it enables you to do something, have it. We'll fix it later in case something's wrong. [20:02] i mean it feels very weird that someone would reorder something like this just for fun. that's why I'm thinking of other possibilities of that difference [20:02] (Aaah the benefits of VCS) [20:02] t0by, _sev: I've just finished the file reading stuff and spliting the last commit. So now I should start to call initGraphics() ? [20:03] <_sev> Simei: yes [20:03] Simei: you have a PR. This is exactly a copypaste of the functions from the opensludge commit I linked earlier today. [20:04] That one should be semantically equivalent to the original and, in fact, it works but it's probably more readable. [20:05] m_kiewitz, snover, couldn't it be the sci compiler that changed? [20:05] _sev, Simei: at some point soon we'll probably need to 1. hook that to our png.h 2. implement file reading in there as well and finally 3. replace the GL stuff with osystem [20:05] <_sev> t0by: correct [20:05] _sev, t0by: If I didn't make any mistake, the initGraphics only allows creating a empty window with a defined size ? [20:06] _sev, t0by: What else does it do? [20:06] And you're probably asking: does opensludge only do "fixed size"? [20:06] TMM: I think snover is talking about an internal SCI structure, within the engine itself [20:06] <_sev> Simei: yes [20:06] <_sev> Simei: and after you initialize it, you may start calling copyRectToScreen() [20:07] TMM: this is audio code in the engine, not to do with the SCI VM/game scripts at all [20:07] (Answer: I don't know, have a look at the original.) [20:07] <_sev> Simei: I recomment to take a look into testbed engine. It is small enough, and you might see how to work with graphics [20:07] snover, ah, ok, thanks :) [20:07] <_sev> Simei: or even plumbers engine, which is super-tiny [20:07] LOL [20:08] I'm actually laughing out loud [20:08] _sev, t0by: in sludge, it reads it size from game data file [20:08] It would be hysterical if plumbers ended up being the hello world of scummvm. [20:08] It'd make sense to use it that way [20:08] _sev, t0by: the game commited on April 1st ? :) [20:08] That one. [20:08] <_sev> t0by: in fact, it is better than quux [20:09] yeah, it actually does 'stuff' [20:09] (for certain definitions of stuff) ;) [20:10] You do realize that if Simei tries to actually launch that thing she would probably end up in therapy and have grounds to sue us all, right? [20:10] Anyway [20:10] we don't suggest people launch it [20:10] only read the code :P [20:11] TMM: you know, one might accidentally... [20:11] Anyway [20:11] Hate to be that guy, but there won't be many rects to display until sprite loading is fixed :| [20:12] Simei: can you see the PR? [20:12] https://github.com/yinsimei/scummvm/pull/1 [20:12] Yes, I see it now? [20:12] Merge it? [20:12] You can merge it in your tree by clicking the big "merge" button and then pulling [20:13] If we are super picky we might want to split this into sensible commits much later before merging it scummvm/scummvm [20:13] _sev, Simei: anyway, sorry, I didn't follow your discussions today. Do we have a plan now? [20:14] Init and then? [20:15] so far, it seems like the biggest, or possibly only (ha ha, wishful thinking), change in GK2 is to add a bit of extra code to load samples into memory. they did manage to add 16 bytes to the channel structure, though most of this *might* be due to extra alignment on these moved fields [20:15] _sev, t0by: See how copyRectToScreen() works for testbed and plumber ?_sev, Simei: [20:15] Simei: that's a given. [20:15] Beside seeing things, what will we be doing though? [20:16] What does "1. hook that to our png.h" mean exactly? [20:16] Vampire0 (~Vampire@jEdit/Vampire) joined #scummvm. [20:16] Simei: you might have noticed that sprite loading is dependent on libpng [20:17] _sev, t0by: So I guess what I do next is to follow your 1. hook that to our png.h 2. implement file reading in there as well and finally 3. replace the GL stuff with osystem ? [20:17] In order to load pngs we want to use image/png.h instead [20:18] _sev, t0by: Yes, I noticed it, so replace the png/png.h by image/png.h [20:18] 1 and 2 are probably good ideas in general. I'm not sure if you can move to #3 already. [20:18] _sev, t0by: and the related functions? [20:18] The best thing about #2 is that it will presumably allow us to run scripts without the interpreter segfaulting... [20:18] (or at least segfaulting somewhere different) [20:19] _sev: what's your take on the big plan to get to Milestone #1? [20:19] _sev, t0by: Do png/png.h and image/png.h have same functions ? [20:19] I'm almost positive they have a different interface [20:20] _sev, t0by: So why we can jump to #3 directly? [20:20] image/png.h probably talks Graphics::Surface and Common::File [20:20] *speaks [20:20] DAMNIT, I can't speak english anymore [20:20] Graphics::Surface is used instead of what ? [20:21] instead of byte arrays or something. [20:21] Simei: are you asking this out of curiosity or because you want to know what to replace with what? [20:22] t0by: #2 :§ [20:22] The latter is probably your task [20:22] Ok, I see [20:22] And probably doesn't amount to a simple search & replace [20:22] this is step 2? [20:22] the good news is that image/png.h has a higher level interface [20:22] so it's probably two lines. [20:22] Ok, so I need to compare the 2 codes [20:22] Simei: read image/png.h [20:22] it's pretty much self explanatory [20:23] And figure out how to use image/png.h in sludge [20:23] you feed it a SeekableReadStream and get a Graphics::Surface with the decoded sprite. [20:23] It's rather simple. [20:24] The other half of the job is reading the original low-level png-loading code [20:24] figuring out what it does [20:24] and... replacing it with a two-liner [20:24] Simei: if you look at my commit I've sort of done half the work for you [20:24] Read it? [20:24] As in, did you read it? [20:25] t0by: Not in detail. Sorry [20:25] Simei: read the code, everything will probably be clear immediately thereafter. [20:26] t0by, _sev: So this PR is about the part of code we want to replace with 2 liners ? [20:26] Ok, I'll read it [20:26] Simei: assume this PR has always been part of the original code. [20:26] Ok [20:28] Simei: I took the original, super hairy, 300-lines function and clearly separated it into 1. file reading 2. PNG decoding 3. GL-specific handling. [20:29] I've linked the original opensludge commit earlier, if you want you can check it out and run it. It works exactly the same for me (and I would be surprised otherwise) [20:30] So for 1, it's just Common::File [20:30] Simei: so, assume that stuff has always been there. [20:30] Simei: correct. [20:30] 2, 3 are done with using Surface ? [20:30] Then use copyRectToScreen() to display Surface to Screen ? [20:32] #1 is where you instantiate a File and can read it via a SeekableReadStream; #2 is where you put that SeekableReadStream into PNGDecoder and get a Surface out of it; [20:33] #3 is... I'm not 100% sure of what the semantics of that thing are, but I *think* it creates GL textures and attaches them to loadhere.myPalette [20:33] snover: sample rate moving rom 0x7c to 0x80 and robot moving from 0x80 to 0x88 could be explained by a 32bit -> 64bit change [20:33] s/rom/from/ [20:34] snover: I don't know the context, so if things actually got *reordered*, that's a different beast... [20:34] Simei: at a *very quick glance* I think those textures are then actively displayed in various helpers called by some builtins. [20:34] (Don't take my word for this last one) [20:35] Simei: obviously we want to migrate those to Graphics::Surface instead of GL stuff. [20:36] logix: things may not have been fully reordered, someone may have just stuck some new fields in the middle of the struct instead of at the end [20:36] t0by, _sev: So, normally, with Graphics::Surface created or a png, the GL stuff is handled automaticcally inside? [20:36] t0by, _sev: Or we adapt it ? [20:36] Simei: yes and no. [20:36] there wouldnt be anything 64-bit in this code [20:37] That's confusing :x [20:37] Simei: Graphics::Surface hides the low level stuff, of course. That might or might not be implemented with OpenGL. [20:37] So, no, there's not necessarily GL inside Graphics::Surface. [20:37] So, yes, Graphics::Surface hides the ugly parts away and you can focus on the high level stuff. [20:38] high level stuff such as what ? [20:39] Simei: such as what Graphics::Surface exposes (read the header!) You can think in terms of high level graphics primitives such as surfaces and rectangles instead of byte arrays, shaders, pointers to pointers and all the GL ugliness. [20:39] logix: the property order in this struct never made any logical sense; there are 5 parts to an Audio36 ID, and they are at 0x2D (char), 0x6C (word), 0x6E (char), 0x70 (word), and 0x88 (char), instead of being contiguous [20:40] Simei: GL is is pretty low level. Read any GL tutorial and they'll make you write 50 lines of very thick C to display a white rectangle. [20:41] Anyway [20:41] Simei, _sev: more importantly, I lied. loadSpriteBanks is used *only* for animations and used only in sprbanks.cpp. [20:42] Ok, so I have all the "draw" in the Graphics::Surface [20:43] Simei, _sev: I lied about lying. Apparently it's used even for static sprites. [20:43] Simei: in general, Graphics::Surface is probably close to struct sprite in there. [20:44] Ok, I note that [20:44] Or rather, struct spritebank minus the animation part. [20:47] @people: do we have any primitive for animation? Any neat example from an engine? [20:47] The wme one is a bit of a mess for Simei to peek into. [20:48] Simei: anyway, don't concern yourself with animations just yet. Probably just use the first frame as a static sprite. [20:48] _sev, t0by: So let me make a conclusion, What I'll do is [20:48] _sev, t0by: 1. read your PR about png loading code, and figure out first where to replace Common::FIle [20:49] _sev, t0by: 2. read the byte reading procedure and figure out how can our Surface can be loaded and used instead of struct sprite [20:49] 1. Good idea in general. [20:49] _sev, t0by: 3. Figure out how images are drawn, and apply Surface calls [20:49] _sev, t0by: 4. take a look at how copyRectToScreen() works with plumber, and put the surface to screen [20:49] 2. Yes, but PNGDecoder essentially does that for you in a couple of lines [20:49] _sev, t0by: 5. then explore the animation stuff with spritebank ? [20:49] 5.: Disregard for the time being [20:49] snover: why did you use "([iro])([ro0])" for ScummVMSaveLoad kernel func? [20:50] shouldn't this be simply "(iro)(ro0)"? [20:50] 3,4.: Probably? I'd like to hear from _sev [20:51] snover: possible reason for a struct reorder between versions: 1) people come up with required stuff over time, always just append to struct, 2) v1 is released, 3) somebody reorders the struct to get rid of padding ("uint8 a; uint32 b; uint8 c; uint8 d; uint8 e" -> "uint8 a, c, d, e; uint32 b"), 4) v2 is released [20:51] m_kiewitz: i dont think so, kernel_tables.h:32 says (io) is optionally integer AND an object [20:52] snover: not saying that this happened here... really just a general "this could be the motivation to reorder a struct" [20:52] ah right [20:53] logix: it isnt really important why things changed, its just annoying since it makes bindiff less effective and there are ambiguous cases where i cant tell yet whether a property has been shifted [20:54] snover: yeah, true :) [20:55] _sev, Simei: I lied about lying about lying. I'm sorry. backdrop.cpp has its own sprite loading function. [20:55] Which includes png of course. [20:55] <_sev> t0by: you're recursive liar [20:55] I know. [20:56] I apologize. [20:56] haha, recursive [20:56] The various #if 0 apparently confuse my gtags. [20:56] I only now realized it. [20:57] Simei, _sev: then I'd probably start from backgrounds, and then everything said above. [20:58] backgrounds is the same: refactor it a bit, fix file loading, replace libpng with PNGDecoder, replace GL textures with Graphics::Surface. [20:58] Henke37 (~Henrik@81-227-16-59-no133.bredband.skanova.com) left irc: Ping timeout: 240 seconds [20:59] The function is loadHSI [21:00] Simei, _sev: fwiw I'd do the refactoring of the backdrop loading on top of the original opensludge, like I did, to see if it explodes. Then copypaste to scummvm and go on with the plan. [21:00] At the end we should probably be able to display a backdrop indeed, as was the plan. [21:02] dang i need to wait more than 1 tick :/ [21:02] and i got 1 byte left, not two :( [21:02] _sev, Simei: so here's my proposal: [21:02] 1. Refactor loadHSI on original opensludge, looking at what I did on loadSpriteBanks as an example 2. Make sure it still works 3. Copypaste it to scummvm (remember to astyle it) 4. Replace stdio.h with Common::File 5. Replace libpng with PNGDecoder 6. ass initGraphics and boilerplate as needed 7. Replace various low level stuff with Graphics::Surface 8. You can probably now display a backdrop. Then move on to sprites. [21:03] *add initGraphics [21:03] _sev: sane idea? [21:03] m_kiewitz: push2? [21:03] 2 isn't enough [21:03] <_sev> t0by: yes [21:04] man& they made changes the ResourceMgr vtable too [21:05] Simei: good news it bits 1 to 7 are probably more work at explaining them than actually doing them [21:05] cycle speed is 6 in the worst case, so to be sure i have to wait 12 ticks at least [21:05] In italian we say "si fa prima a dirsi che a farsi", I don't know if they have an equivalent expression in english or a chengyu in chinese. [21:05] m_kiewitz: this is for the slope? [21:05] yes [21:06] *a farsi che a dirsi [21:06] maybe i really need to look into it what's exactly happening internally [21:06] maybe there needs to be another set up call [21:06] t0by: 1->7 All of them? [21:06] it's really weird in any case, because the Grooper definitely has an issue with no cycler being set [21:06] 1 is probably boring but not hard. [21:07] if i would reset the cycle, then i guess it should work as well [21:07] Simei: oh, and 0. look how I did it for loadSpriteBanks [21:07] t0by: "easier said than done"? [21:07] logix: thanks. [21:07] I see, they are just for preparation for 8, which is an obscure stuff ? [21:08] logix: no, easier done than said :P [21:08] t0by: was a wild guess, I entered your phrase in dict.leo.org and it suggested instead "piu facile a dirsi che a farsi" (with an accent on the piu) [21:08] t0by: oh, right, I missed your correction up there, didn't see that you swapped the verbs [21:09] Simei: 8 is probably the end result, or very close. [21:10] Ok, I see [21:10] We'll see when we get there if there is something more to add. [21:11] Ok, I'll get started from 1 to 7 now. [21:12] Yay :) [21:17] Simei: please ping us when you've completed each step and, of course, also in the middle of it if it takes you a while. [21:18] Ok, I'll do it. Thanks in advance. :) [21:21] I'm going to bed, good night! [21:21] t0by (~t0by@unaffiliated/t0by) left irc: Quit: t0by [21:21] ny00123 (~ny00123@dsl217-132-0-115.bb.netvision.net.il) left irc: Quit: Leaving [21:21] Good night! [21:29] snover: in that qfg4 case a "doorMat" is used (script 49), which triggers when ego reaches a certain place. It seems the system calls are not meant to be called while ego is walking around. [21:29] so maybe other scripts, which also use "doorMat" are vulnerable to this error too [21:29] do you have qfg4 decompiled somewhere to check for other instances? [21:30] which system calls are you referring to? [21:30] yes [21:30] i mean game system calls (internally the 64xxx scripts) [21:30] in theory other instances should either handle the walking differently, or should have the same issue [21:33] 0, 250, 260, 270, 290, 300, 320, 390, 460, 520, 600, 633 (rm620code), 629, 630, 650, 663, 670, 680, 740, 780, 800 [21:34] Strangerke_ (~Strangerk@cable-85.28.84.13.coditel.net) joined #scummvm. [21:34] girafe (~girafe@LFbn-1-11729-221.w2-7.abo.wanadoo.fr) left irc: Read error: Connection reset by peer [21:35] wow [21:35] i didn't expect that [21:36] Henke37 (~Henrik@81-227-16-59-no133.bredband.skanova.com) joined #scummvm. [21:36] Strangerke (~Strangerk@cable-85.28.84.13.coditel.net) left irc: Ping timeout: 260 seconds [21:36] Nick change: Strangerke_ -> Strangerke [21:36] oh, oops, i screwed up a little bit. remove script 0 and add script 360 to the list [21:39] bbiab [21:39] i can't find doorMat inside script 780? [21:42] Nick change: Stormkpr -> Stormkeeper [22:20] snover: nvm, it works via ::yourself and scriptID [22:42] Littleboy (~littleboy@c-73-4-50-241.hsd1.ma.comcast.net) left irc: Quit: Ętre dans le vent, une ambition de feuille morte. [22:55] bgK (~bgk@2001:41d0:2:599c::2a60:8434) left irc: Ping timeout: 245 seconds [22:55] lateral[m] (lateralmat@gateway/shell/matrix.org/x-dfkmqgbvrehnmgve) left irc: Ping timeout: 245 seconds [22:58] Gentle (~tier@quassel/contributors/gentle) left irc: Ping timeout: 245 seconds [22:58] Gentle (~tier@quassel/contributors/gentle) joined #scummvm. [22:59] Dominus (~dominus@unaffiliated/dominus) left irc: Ping timeout: 260 seconds [23:00] Dominus (~dominus@unaffiliated/dominus) joined #scummvm. [23:01] waltervn (~waltervn@541B2DBA.cm-5-4a.dynamic.ziggo.nl) left irc: Quit: Leaving [23:02] bgK (~bgk@2001:41d0:2:599c::2a60:8434) joined #scummvm. [23:02] #scummvm: mode change '+o bgK' by ChanServ!ChanServ@services. [23:04] lateral[m] (lateralmat@gateway/shell/matrix.org/x-qsyddttgxuexcbhn) joined #scummvm. [23:13] Farmboy0 (~quassel@xoreos/farmboy0) left irc: Remote host closed the connection [23:14] dreammaster (~dreammast@c-73-149-116-247.hsd1.ma.comcast.net) left irc: [23:38] m_kiewitz: yeah, i looked for ScriptID 47 since it was only used as an export AFAICT [23:38] 49* [23:38] can you please do another search for an additional PolyPath? [23:38] im not entirely sure but the issue may only be when PolyPath is used as well [23:38] *be happening [23:39] you want the intersection of scripts that have both doorMat and PolyPath? [23:39] yes [23:42] 250, 260, 270, 290, 320, 390, 460, 520, 600, 630, 633, 650, 663, 670, 680, 740, 780, 800 [23:44] i guess i need to check manually [23:44] 780 for example doesn't use PolyPath for the automatic walking [23:45] still it eliminates quite a few scripts, thx [23:45] script 17 also exports a PolyPath instance which is used in 270, 320, 600 [00:00] --- Sun May 28 2017