[Back to Index]

[00:00] <TMM> snover, do you have some information on the sci opcodes and stuff? Is it on the scummvm wiki somewhere?
[00:00] <snover> yessir! someone very nice wrote this http://wiki.scummvm.org/index.php/SCI/Specifications/SCI_virtual_machine/The_Sierra_PMachine
[00:02] <TMM> was it you?
[00:02] <snover> nope, im very terrible
[00:03] <TMM> hmm, that all looks relatively straightforward
[00:08] <TMM> snover, hmm, I did a 'dissect_script' but I get an error: Obj type #61c, size 0x0: Unsupported!
[00:10] <snover> TMM: i dont think that works on sci1.1 or later
[00:10] <snover> try `disasm` instead
[00:11] <snover> `disasm oFlags clear bc` or something
[00:12] <TMM> can I disassemble the 'current script'?
[00:13] <TMM> I know nothing about what is going on now
[00:14] <TMM> I'd like to press the 'bet' button and go into single step mode then
[00:14] <TMM> for starters
[00:14] <TMM> see if I can figure out what variables it's even looking at
[00:14] <TMM> I listed the 'temp variables' but that seems to not be it, at least not in this context
[00:18] <snover> ok
[00:18] <snover> sorry, im paying attention now
[00:20] <snover> so there are a few approaches
[00:20] <snover> usually when i am looking for something that is visual, i will run `pl` to get the plane list and then `pi <plane object id>` until i find what looks like the correct view object
[00:21] <snover> then run `vo <screen item id>` to see what the corresponding VM object for that screen item looks like
[00:22] <snover> that will also say which script owns the object
[00:23] <snover> and it will say what methods exist, if any. usually there will be one like `handleEvent`
[00:24] <snover> so if you want to breakpoint on that then you would `bpx oBetButton::handleEvent` (or whatever the bet button is named)
[00:25] <snover> however, it looks like i made some commits but didnt push them yesterday, so one second while i fix your object names which right now are probably looking gibberish
[00:26] --> GitHub45 joined #scummvm.
[00:26] <GitHub45> [scummvm] csnover pushed 1 new commit to master: https://git.io/vHGqE
[00:26] <GitHub45> scummvm/master d0040dc Colin Snover: SCI32: Fix SCI3 object names > 0xFFFF
[00:26] GitHub45 (GitHub45@192.30.252.42) left #scummvm.
[00:27] <TMM> sweet
[00:27] <TMM> and, they do
[00:28] <TMM> snover, is there a way to see all active script contexts?
[00:28] <snover> `segment_table` will show you an overview of everything that is loaded
[00:29] <TMM> ok, I think the first thing I want to do is figure out where the dice are in memory
[00:29] <TMM> they aren't global :) but that's all I know now
[00:30] <snover> i would assume their values are locals inside whatever script controls the game
[00:30] <snover> global 2 references the current room object
[00:30] <snover> global 1 is the main game object
[00:30] <snover> global 0 is ego
[00:33] <TMM> yeah, I'm trying to determine how to dump variables for a script that's not current
[00:34] <snover> if you know the script, you might try looking at it in SV
[00:36] <TMM> sv?
[00:36] <snover> sci viewer
[00:36] <snover> if you dont have, it i can just gist the output of a script for you
[00:36] <snover> sigh. commas how, do they wo,rk
[00:37] <TMM> Do you have a link to that tool?
[00:39] <snover> http://sci.sierrahelp.com/Files/ResourceTools/SCIViewer(CLI).zip
[00:40] <snover> its not perfect, sometimes it cant deal with scripts that scummvm can, but 511 (roLiarsRoom) seems to be OK
[00:40] <TMM> 403 :-/
[00:41] <TMM> found it, it just didn't like wget
[00:47] <TMM> haha AIBabe::
[00:49] --> Huerbine joined #scummvm.
[00:50] <-- Huerbine left irc: Client Quit
[00:53] <-- WooShell left irc: Ping timeout: 255 seconds
[00:58] <TMM> snover, I managed to play some liar's dice with just using send from the debugger, that's progress
[00:58] <snover> send magicfix enable 1
[00:59] <TMM> awww
[01:02] <TMM> yeah, so the value keeping of the dies and everything works just fine, it appears that accessing the nValue field of the dies isn't, judging by what's going on
[01:19] --> omer_mor_ joined #scummvm.
[01:21] <-- omer_mor left irc: Ping timeout: 240 seconds
[01:24] <TMM> snover, bp_method Object:: doesn't appear to be working
[01:24] <TMM> snover, according to the in-debugger help any method on the object should trigger a bp, but nothing happens
[01:25] <TMM> snover, I verified by setting a breakpoint on Die::rollDie and that works, but a bp_method on Die:: does nothing
[01:27] <snover> TMM: does it work anywhere? scriptdebug.cpp:688 comparison of the name looks fishy
[01:30] <snover> (by anywhere i mean like, some sci16 game that would have conceivably already been known to work)
[01:31] <TMM> snover, I don't know, I've never tried this before
[01:32] <TMM> I may not need it, it was just a lazy thing, but it still shouldn't be broken
[01:32] <TMM> I wanted to just let scummvm find the entrypoint for a turn for me, but I think I found it by just reading the disassembly
[01:34] <TMM> Hey... The AIBabe::Bluff() method looks at larry's dice
[01:34] <TMM> no wonder she's so fucking hard to beat, she cheats
[01:45] <snover> :)
[01:46] --> DominusExult joined #scummvm.
[01:47] <TMM> still haven't found the code that determines who won a round :-/
[01:47] <-- Dominus left irc: Ping timeout: 260 seconds
[01:47] Nick change: DominusExult -> Dominus
[01:48] <snover> search for a caller of soLarryLoses
[01:50] <TMM> given that she also can't see her own dice, I'm assuming that where things go wrong is AIBabe::countDice() it seems to loop over her list of dice oBabeDice and then over oLarryDice and updates some temp values
[01:51] <TMM> it's also the only code that seems to do that
[01:51] <snover> iirc temps are function-scope variables so i hope they go somewhere else
[01:52] <TMM> yeah so soChallenge::changeState eventually calls soLarryLoses
[01:52] <TMM> but it also calls countDice
[01:53] <TMM> countDice() can normally only see dice that are 'showing' but all dice are showing when a determination is made
[01:54] <TMM> seems like an... interesting approach to code reuse
[01:56] <TMM> uch, I'm going to attempt sleep again.
[01:57] <TMM> at least I learned... something?
[02:07] <-- DJW|Badger left irc: Read error: Connection reset by peer
[02:27] --> GitHub146 joined #scummvm.
[02:27] <GitHub146> [scummvm] dreammaster pushed 1 new commit to master: https://git.io/vHGZk
[02:27] <GitHub146> scummvm/master 78f69e1 Paul Gilbert: TITANIC: Fix calculating orientation transition matrixes
[02:27] GitHub146 (GitHub146@192.30.252.40) left #scummvm.
[02:46] <-- Mia left irc: Read error: Connection reset by peer
[03:02] <-- dreammaster left irc:
[03:29] <Simei> Morning, everyone! :)
[03:29] <Simei> _sev, t0by: https://github.com/yinsimei/scummvm/commits/newWIP1-1
[03:29] <Simei> _sev, t0by: It compiles now.
[03:42] --> Strangerke_ joined #scummvm.
[03:45] <-- Strangerke left irc: Ping timeout: 246 seconds
[03:45] Nick change: Strangerke_ -> Strangerke
[04:49] <snover> TMM: sigh. so that breakpoint execute code was cleaned up back in 2011 and broken. i will fix it soon.
[05:03] <_sev> Simei: nice, it compiles over there. From now on, though, try to make atomic commits
[05:27] <-- Lightkey left irc: Ping timeout: 255 seconds
[05:58] --> Lightkey joined #scummvm.
[06:05] <Simei> _sev: Ok, I'll do so.
[07:04] <-- LittleToonCat left irc: Remote host closed the connection
[07:15] --> m_kiewitz joined #scummvm.
[07:15] <-- m_kiewitz left irc: Changing host
[07:15] --> m_kiewitz joined #scummvm.
[07:15] #scummvm: mode change '+o m_kiewitz' by ChanServ!ChanServ@services.
[07:21] <m_kiewitz> PSA: Rising Storm Game of the Year Edition currently free (via Humble Bundle, 2 days only)
[07:26] --> Strangerke_ joined #scummvm.
[07:28] <-- Strangerke left irc: Ping timeout: 246 seconds
[07:28] Nick change: Strangerke_ -> Strangerke
[07:30] Action: TMM wonders how long it'll be before scummvm needs a 'unity' backend to run newer adventures
[07:30] <TMM> err 'engine' not 'backend'
[07:42] --> exmensa_ joined #scummvm.
[07:42] <-- exmensa left irc: Read error: Connection reset by peer
[08:03] <somaen> I'd bet on Unity being out-of-scope for ScummVM for the forseeable future
[08:03] <somaen> Wintermute is way too heavy as it is, and that is _aimed_ at adventure games
[08:11] --> waltervn joined #scummvm.
[08:11] #scummvm: mode change '+o waltervn' by ChanServ!ChanServ@services.
[08:35] --> Strangerke|work joined #scummvm.
[08:35] <Strangerke|work> hi guys
[08:40] <wjp> morning
[09:02] --> t0by joined #scummvm.
[09:02] #scummvm: mode change '+o t0by' by ChanServ!ChanServ@services.
[09:02] <t0by> Morning, beauties.
[09:04] <-- t0by left irc: Client Quit
[09:05] --> t0by joined #scummvm.
[09:05] <-- t0by left irc: Changing host
[09:05] --> t0by joined #scummvm.
[09:05] #scummvm: mode change '+o t0by' by ChanServ!ChanServ@services.
[09:15] <-- Tomaz^W left irc:
[09:19] <TMM> Just for my edification, is there an actually open source adventure creation system like wintermute?
[09:20] <t0by> TMM: OpenSludge!
[09:21] <t0by> Coming soon to a nightly build near you (tm)
[09:21] Action: t0by points at Simei
[09:22] --> Tomaz^W joined #scummvm.
[09:22] <t0by> Simei: so what are you doing now?
[09:23] <TMM> oh, I didn't realize
[09:23] Action: t0by slaps TMM with a trout
[09:24] Action: TMM dies of dysentery
[09:24] <t0by> Wait wha-
[09:25] <TMM> That's what you get when you hit people in the face with rotting fish!
[09:26] <Simei> _sev, t0by: I'm having a distant test for my internship at the moment. I'll be back in 2 hours, discussing the next things to do. :)
[09:27] <Simei> _sev, t0by: I imagine it will be implementing FileManager?
[09:32] --> _sev|work joined #scummvm.
[09:32] <-- _sev|work left irc: Changing host
[09:32] --> _sev|work joined #scummvm.
[09:32] #scummvm: mode change '+o _sev|work' by ChanServ!ChanServ@services.
[09:35] <t0by> Simei: good luck with that!
[09:36] <t0by> TMM: I'm sorry sir, are you suggesting we serve anything other than perfectly fresh fish?
[09:37] <TMM> t0by, given that I just died of dysentery, I'm going to say: yes.
[09:53] --> Begasus joined #scummvm.
[09:56] --> Begas_VBox joined #scummvm.
[10:07] --> Mia joined #scummvm.
[10:13] --> WooShell joined #scummvm.
[10:24] <WooShell> good meowning =^.^=
[10:24] <t0by> Woof
[10:38] <t0by> _sev, Simei: jfyi e68247fc is not building for me: engines/sludge/movie.cpp:47:26: fatal error: vorbis/codec.h: No such file or directory
[10:39] <t0by> oh nevermind, I don't have libvorbis
[10:39] <t0by> although we should probably eventually enforce that in configure
[10:50] <t0by> uh
[10:50] <t0by> _sev, Simei: detection... doesn't detect: http://imgur.com/a/f6Uct
[10:50] <t0by> Am I missing something?
[10:52] <t0by> Simei: as a side note please don't commit .slgs or, in general, build artifacts of any kind.
[11:00] <Simei> _sev, t0by: I didn't test with the detection after compiling the code. I'll see it.
[11:00] <t0by> I thought we had that in already
[11:00] <t0by> Oh, nevermind.
[11:01] <Simei> I commit a slg with the code? I didn't notice it. Let me see.
[11:13] <t0by> You did, it's not a biggie, but it's a *bad habit* to get into: https://github.com/yinsimei/sludge-test-games/blob/master/Welcome2/Welcome.slg
[11:13] <t0by> For future reference, you typically add the extensions of your build products to your .gitignore
[11:14] <t0by> So for example if you are making Windows software your gitignore will contain *.exe, *.dll and the like
[11:14] <t0by> If you are making sludge games, your gitignore will contain *.slg
[11:14] <t0by> This way git doesn't even see them/
[11:14] <t0by> Not important, not a biggie, just letting you know.
[11:17] <Simei> Ah, I see. I'll pay attention to it. But I'm not sure if we will have the same md5 code for the slg file detection if we rebuild it locally.
[11:19] Action: t0by shrugs
[11:19] <t0by> not important
[11:20] <-- Begasus left irc: Ping timeout: 246 seconds
[11:20] <Simei> Ok
[11:20] <t0by> So, let's get down to real business.
[11:20] <Simei> Yes, yes
[11:22] <Simei> _sev, t0by: What I'm doing next? Replace the FileManager?
[11:23] <t0by> Simei: what do you mean by "replace the FileManager" exactly?
[11:24] <Simei> _sev, t0by: I think it's to replace std file functions by scummvm functions to read game data?
[11:25] <Simei> _sev, t0by: Or it's still too early to do so?
[11:27] <Simei> _sev, t0by: Or I do some code reconstructions to Oopify them?
[11:28] <t0by> Simei: I seem to understand there is exactly two "real" fopens in there
[11:28] <t0by> one is in sludger.cpp, FILE *fp = fopen(filename, "rb");
[11:28] <t0by> you're familiar with this one.
[11:28] <t0by> The other is in language.cpp, but IIRC we agreed to ignore translations for the time being
[11:28] <t0by> Well, three
[11:28] <t0by> There is also one in loadsave.cpp
[11:29] <t0by> Everything else appears to be for logging
[11:29] <t0by> e.g. ./fileset.cpp:// FILE * dbug = fopen ("debuggy.txt", "at");
[11:29] <t0by> Or shaders, which we don't care about.
[11:29] <t0by> Let me have a look at that fileset.cpp, though
[11:29] <t0by> what's that
[11:31] <Simei> I think it's where we put all the indexes of resources
[11:31] <t0by> Yes.
[11:31] <Simei> And also help to jump to that index when the resource is needed
[11:32] <t0by> They're called "slices" of a slg, apparently.
[11:32] <t0by> A second.
[11:32] --> Begasus joined #scummvm.
[11:34] <wjp> snover: the conversation last night made me want to revive my breakpoint improvement branch, so I'm working on that now. I also quickly fixed that wildcard selector thing TMM ran into while working on this code
[11:35] <t0by> Simei: here's how I would go about it.
[11:35] <t0by> 1. Decorate the file-reading bits with debug information (what you did already, essentially)
[11:36] <t0by> "file-reading bits" means only the ones for datafiles (it's 3 or 4), disregard dentirely those used for logging.
[11:37] <t0by> 2. Add a #define so as to temporarily enable fopen calls on your working directory (but don't commit that) and see if it roughly works.
[11:37] <t0by> If it still works, that is.
[11:37] <t0by> 3. Starting with replacing all stdio.h stuff with methods from common/file.cpp
[11:37] <t0by> *Start with
[11:37] <t0by> *Start replacing
[11:37] <t0by> adfgd
[11:38] <t0by> and common/archive.h
[11:38] <t0by> sorry, common/fs.h I meant
[11:39] --> ny00123 joined #scummvm.
[11:39] <Simei> what's the difference between the two
[11:39] <t0by> The two what?
[11:39] <Simei> Archive and File
[11:39] <t0by> I *think* you should disregard archive for the time being
[11:40] <Simei> Ok, I see.
[11:40] <t0by> _sev: does this sound reasonable to you?
[11:42] <t0by> Hm
[11:43] <t0by> I'm sorry, can somebody chip in about SearchMan & c?
[11:43] <Simei> _sev, t0by: Or maybe we can replace the Timer first? Just an idea. This one seems easier. It was using SDL timer. And I see there is a Timer in scummvm
[11:43] <t0by> I don't see how Timer should help you reaching your first milestone...
[11:44] <t0by> Ah okay.
[11:44] <t0by> No, on a second thought if you've done your homweork in extending Engine you should have the path inside SearchMan already, so you can probably use stuff from Archive
[11:44] <t0by> I apologize, I never really paid attention to how the archive stuff works
[11:46] <t0by> Looking at engines/engine.cpp:194 I'd say searchman knows the path of your game dir already
[11:49] <Simei> _sev, t0by: Yes, my entry pull request was adding command line for file detection. I think the game path was written into MainConfig when the game is added. But don't know how to get it out.
[11:49] <t0by> wjp: are you familiar with common/archive.cpp?
[11:49] <t0by> I suppose you are
[11:49] <t0by> I never paid any attention to the thing
[11:49] <t0by> Let me see
[11:51] --> ajax16384 joined #scummvm.
[11:51] #scummvm: mode change '+o ajax16384' by ChanServ!ChanServ@services.
[11:51] <Simei> _sev, t0by: For the Timer, it's also part of the main loop. There is Wait_frame() in the while loop. I think it may be useful when really running the game.
[11:52] <t0by> Simei: I think you'd use something to the effect of SearchMan.find("Welcome.slg") to get an iterator, you can iterate over it and use createReadStream(). This yields a Common::SeekableReadStream that you can use instead of stdio.h stuff.
[11:53] <t0by> Simei: and in order to really running the game you need to read files :P
[11:53] <Simei> Euh, yes. That's true. :/
[11:55] <Simei> _sev, t0by: is there an example of getting file content iterator in other engines ?
[11:55] <wjp> t0by: that's a bit of an indirect way
[11:56] <t0by> wjp: what's the sane way?
[11:56] <t0by> (That's what we have in wintermute...)
[11:56] <t0by> Speaking of wintermute, all this made me realize I don't understand what's the use of static Common::FSNode getNodeForRelativePath in there
[11:57] <wjp> Common::File f; f.open("filename"); is probably the easiest
[11:57] Action: t0by facepalms
[11:57] <t0by> Du-uh.
[11:58] <Simei> We normally get that filename from the game description table ?
[11:58] Action: t0by digs hole and buries own self
[11:58] <Simei> Hahaha
[12:00] <Simei> wjp: I search this f.open( a little
[12:01] <Simei> it seems the file names for those games are unchanged
[12:01] <t0by> I'm stupid anyway
[12:01] <t0by> We use Archive to handle what Sluge calls "slices", i.e. the content of packages -- or archives.
[12:02] <t0by> And I'm still not sure how that works.
[12:02] <t0by> I'm terribly sorry about this but I never had to deal with to the thing.
[12:02] <t0by> Simei: anyway, just use Common::File for the time being, ok?
[12:03] <t0by> 1. Decorate the file-reading bits with debug information 2. Add a #define so as to temporarily enable fopen calls on your working directory (but don't commit that) to see if everything still works 3. Starting with replacing all stdio.h calls with their Common::File cousins.
[12:03] <t0by> Simply ignore the million debug files the original engine tries to open
[12:04] <-- Cheeseness left irc: Remote host closed the connection
[12:04] <Mataniko> ok why does calling stream->seek(0) from code does nothing, but from the immediate window it actually seeks
[12:04] <Simei> Ok, I write directly "Welcome.slg" for filename
[12:04] <t0by> We have common/debug.h for that
[12:09] <wjp> Mataniko: sorry, context?
[12:13] Action: t0by O_o
[12:14] <Mataniko> nm i figured it out, i'm creating two substreams from 1 master stream
[12:14] <Mataniko> and seeking on one changes the position on the other
[12:14] <TMM> wjp, is that fix in master?
[12:16] <wjp> TMM: no
[12:17] <wjp> in my sci_breakpoints branch
[12:17] <wjp> it's all still untested
[12:17] <TMM> I don't know your gh username
[12:17] <TMM> :)
[12:17] <wjp> wjp :-)
[12:18] <TMM> well, I stand corrected, I DID know your gh username
[12:19] <t0by> wjp: while you're here -- since Sludge doesn't seem to encapsulate a filesystem-like structure in its data files it's safe to say we won't have to deal with SearchMan at all, excpet perhaps if we need some extra font or the like, right?
[12:19] <wjp> m_kiewitz, snover: work in progress (but pretty much done) on that branch: adding handling for bpw/bpr to the property opcodes (pToa, aTop, ipToa and such), adding the option to only log and/or show backtrace when a breakpoint is triggered
[12:20] <wjp> (that option is per individual breakpoint)
[12:20] <TMM> oh, sounds useful
[12:21] <wjp> t0by: everything will be going through SearchMan, probably
[12:21] <wjp> t0by: since that's the normal way of opening game data files
[12:21] <wjp> t0by: and it's where handling filename case insensitivity happens, for example
[12:22] <t0by> wjp: then why did you discourage her from using it a few lines above?
[12:22] <wjp> did I?
[12:22] <wjp> I just gave the shortcut for the basic file opening
[12:22] <t0by> Unless File::open goes through Searchman
[12:22] <t0by> does it?
[12:22] <wjp> it does
[12:22] <t0by> Ah, nevermind.
[12:23] <t0by> I apologize, I never had to deal with the thing.
[12:23] <wjp> TMM: it should be, yes
[12:23] --> Cheeseness joined #scummvm.
[12:23] <wjp> TMM: I hacked up the basics for this some time ago when debugging time-sensitive things where breaking on breakpoints would critically interfere with things
[12:24] <t0by> In fact, if somebody familiar with it is willing to volunteer, it could be a good time to give Simei the lecture (which can be recycled in case Joefish needs it).
[12:24] Action: t0by volunteers wjp
[12:26] <wjp> TMM: if you play around with this (and/or the bpx wildcard fix), let me know how it goes. This branch needs testing
[12:26] <TMM> wjp, any pushing in putting the bp trigger-on-class-access into master now?
[12:27] <wjp> ?
[12:27] <wjp> (parse error)
[12:27] <TMM> looks super straightforward
[12:27] <TMM> https://github.com/wjp/scummvm/commit/ff507aafc89c052637b894deaa6699a596771861
[12:27] <Simei> _sev, t0by: I have course of 4 hours this afternoon, I will look deeper into this file reading system later, if _sev agrees with it as well.
[12:27] <TMM> any point in pushing...
[12:27] <TMM> I'm sorry, I just took a nap due to my failure to fall asleep last night
[12:28] <TMM> super groggy
[12:28] <t0by> Simei: I think you should get started already
[12:28] <t0by> _sev has already suggested that you start working on file reading.
[12:29] <t0by> It's also a necessity if you want to do anything else.
[12:29] <t0by> But it amounts to replacing C streams with Common::SeakableReadstreams and the like, so i8t's super trivial.
[12:29] <TMM> t0by, i8t?
[12:29] <t0by> it's
[12:30] <TMM> ah
[12:30] <TMM> I thought it was some fancy ass acronym like i10n
[12:30] <t0by> *how* you get to the stream is a trivial detail in this respect, please do hardcode Common::File("Welcome.slg") and be done with it for the time being
[12:30] <Simei> t0by>
[12:30] <t0by> we'll handle it correctly later
[12:30] <Simei> t0by: Ok, I see. I will get started as soon as I can. :)
[12:31] <t0by> wjp, TMM: is there any other example of an engine that has plenty of games with file in the form [A-Za-z0-9]*.ext for some ext?
[12:31] <t0by> That you know of.
[12:31] <TMM> wintermute maybe?
[12:31] <TMM> old agi games have a bunch of separate files
[12:32] <somaen> t0by: [anything-valid-as-a-filename].dcp in wintermute
[12:33] <somaen> Also, I hope that * is a +
[12:33] <t0by> somaen: fallback detection seems to go exclusively for data.dcp
[12:33] <somaen> Yeah, but IIRC, the engine does go through all the files in the folder when loading
[12:33] <somaen> except for the blacklisted language-stuff
[12:34] <TMM> I suppose that AGS would be the next engine then if we have wintermute and sludge? :)
[12:35] <somaen> Also getNodeForRelativePath() was probably used because Wintermute explicitly talks in paths
[12:35] <somaen> AGS?
[12:35] <somaen> You mad?
[12:35] <t0by> Ah, in registerPackages
[12:36] <somaen> IIRC fuzzie started an AGS engine
[12:36] <somaen> But such attempts is for people far braver than I
[12:37] <somaen> The truly brave can take a look at the original AGS-code's ad.cpp
[12:37] <TMM> ags engine is under the artistic license right?
[12:37] <wjp> TMM: I've amended it a bit just now, but that one patch should be safe to add to master, yes
[12:37] <TMM> it could be ported to osystem
[12:38] <t0by> somaen: what about stuff like diskFileExists in base_disk_file.cpp, though?
[12:39] <t0by> Is this thing trying to load a source directory as well?
[12:39] <TMM> Artistic license v2 allows relicensing to GPLv2+ apparently
[12:39] <wjp> TMM: I'm just still a bit puzzled on how this :: wildcard interacts with bpr/bpw
[12:41] <wjp> TMM: since that also goes through this same function
[12:43] <TMM> wjp, I don't see how it would matter, it may trigger multiple times though
[12:44] <TMM> wjp, if Foo::blah calls Foo::stuff perhaps
[12:44] <wjp> bpr/bpw are selector read/write rather than selector exec/call
[12:44] <TMM> wjp, oh, right, sorry. I only started using sci debugger yesterday night
[12:45] <TMM> wjp, I thought you were talking about the conditional conditional breakpoint stuff
[12:50] <wjp> we have conditional breakpoints?
[12:51] <wjp> hrm, maybe I should also add a 'none' action to be able to disable breakpoints temporarily
[12:56] <TMM> I guess what you were talking about aren't conditional breakpoints
[12:56] <TMM> I need more coffee, I'll try and string together a coherent thought later
[13:01] <wjp> and an 'inspect' action to dump the current object maybe
[13:04] <m_kiewitz> wjp: you could add an option to disable/enable certain breakpoints or * for all
[13:05] <m_kiewitz> maybe "bd" / "be" for disable/enable
[13:05] <m_kiewitz> thats how SoftICE does it
[13:06] <m_kiewitz> bd 1 -> disable breakpoint 1
[13:06] <m_kiewitz> bd * -> disable all
[13:06] <m_kiewitz> back then i used SoftICE command names, because I'm used to those
[13:09] <wjp> I'm away for a bit, but will finish this up tonight
[13:24] <-- Begasus left irc: Ping timeout: 245 seconds
[13:36] --> Begasus joined #scummvm.
[13:58] --> Strangerke_ joined #scummvm.
[13:59] --> Henke37 joined #scummvm.
[14:01] <-- Strangerke left irc: Ping timeout: 260 seconds
[14:01] Nick change: Strangerke_ -> Strangerke
[14:02] <TMM> snover, m_kiewitz, I got a little further with the dice thing. I'm 90% sure the problem is in oBabe::countDice(). The AI player always think that your bet is impossible, seemingly because it thinks that there are 0 dice. Somehow looping through the dicelists isn't working
[14:10] <TMM> hhmm, no, iterating through the dice actually works fine
[14:13] <m_kiewitz> will take a look at that later today
[14:17] <TMM> m_kiewitz,
[14:17] <TMM> m_kiewitz, is there a way to dump the content of a 'data' type in sci debugger?
[14:17] <m_kiewitz> data type?
[14:17] <TMM> m_kiewitz, I have this: (0003) [2dc] data = 0014:021e
[14:17] <TMM> I'd like to know what's at that address
[14:17] <m_kiewitz> do a "vo 14:21e"
[14:17] <TMM> this is a IntArray
[14:17] <m_kiewitz> if that doesn't work, try "vr 14:21e"
[14:18] <TMM> ah yeah 'vr'
[14:18] <TMM> hum, this is a somewhat surprising result
[14:18] <TMM> 000000: 0000:0003 0000:000e 0000:0009 0000:000c |........|
[14:18] <TMM> 000004: 0000:0005 0000:000c |.... |
[14:19] <TMM> That is supposed to be the list of dice values for both larry and aibabe
[14:19] <TMM> I'd expect to see 5 or 10 entries between 1 and 6
[14:20] <TMM> can I poke things into that array?
[14:23] <m_kiewitz> not to my knowledge
[14:23] <TMM> hm, hard to test my hypothesis then
[14:24] <TMM> I have to admit I'm not entirely clear on what send does exactly, it is possible I'm completely misreading this assembly. The explanation of the call on the scummvm wiki page is somewhat confusing, but from the description I gather that's because the semantics of that call are somewhat confusing
[14:25] <m_kiewitz> you can set a selector to a certain value with it
[14:25] <m_kiewitz> or call the method
[14:27] <TMM> so, to the best of my ability to understand this now, AIBabe::init creates an IntArray of size 10
[14:27] <TMM> But scummvm seems to think it's only of size 6
[14:29] <TMM> oh, no, nvm, that's not what that does
[14:29] <TMM> it just creates a new IntArray, the '10' I saw is just the selector for the new method
[14:34] <TMM> oh, 6 values would actually make sense
[14:34] <TMM> oCountDice[6]; ocountdice[0] = <number of dice with value 1>... etc
[14:35] <TMM> still I wouldn't expect to see 14 (e) dice with value 2 :P
[14:37] <TMM> I don't understand why having too many dice (seemingly) cause this behavior, I'll have to go look through it again. It's also possible that all of this works just fine but it's actually the bet selector that's not working
[14:37] <TMM> if it say, thinks you bet a number of '7' dice
[14:38] <TMM> sorry for the wall of text I should stop talking out loud I guess :)
[14:38] <logix> TMM: notice that oCountDice[i] is a multiple of i
[14:38] <logix> well, i+1 I guess
[14:39] <logix> 3x1 7x2 3x3 3x4 1x5 2x6
[14:39] <logix> not sure if that's relevant...
[14:39] <logix> perhaps the values are never reset to 0 when they should be
[14:40] <TMM> logix, I'm not sure I understand what you mean by 'multiple of i'
[14:40] <logix> TMM: the numbers up there are 3, 14, 9, 12, 5, 12 - 3 is a multiple of 1, 14 is a multiple of 2, 9 is a multiple of 3 etc.
[14:41] <logix> i is just the iterator, 1 to 6 (I was off by 1)
[14:41] <TMM> oh, clever
[14:41] <TMM> so that could be the total value of all the dice
[14:41] <TMM> 3 is 3 1s, 14 is 7 2s? but that's too many
[14:42] <TMM> but the pattern is pretty telling
[14:42] <logix> yeah, that's what I meant, perhaps the numbers should be reset to 0 when $SOMETHING happens but they're not
[14:42] <logix> really just a wild guess
[14:42] <TMM> you sire, are a better man than I am, I'd never have noticed that
[14:43] <TMM> after another round the values look like this
[14:43] <TMM> 000000: 0000:0000 0000:0011 0000:000b 0000:000f |........|
[14:43] <TMM> 000004: 0000:0008 0000:000d |.... |
[14:44] <TMM> 0x11 isn't a multiple of 2
[14:44] <TMM> and the 1st place went from 3 to 0
[14:45] <TMM> maybe that state was a fluke
[14:48] <TMM> hmm, it does seem that whenever you call oBabe::countDice() all those values go up
[14:48] <TMM> (if there are dice for that number)
[14:52] <TMM> it seems that all but the first one go up
[14:52] <TMM> 000000: 0000:0000 0000:001a 0000:0015 0000:0011 |........|
[14:52] <TMM> 000004: 0000:000c 0000:000d |.... |
[14:52] <TMM> I think you're right logix
[14:53] <TMM> I think it *is* the actual number of dice, but it seems that only the first value gets set to 0 when all of them should be
[14:54] <-- waltervn left irc: Ping timeout: 246 seconds
[14:56] <TMM> logix, m_kiewitz, yeah so this array *is* the amount of dice per value. I just verified for value '1' dice. If aibabe has 3 '1' dice and larry has '1' for the first call of countDice() oBabe::oCountDice[0] is 0x3. Then after the reveal it gets set to '4'. After aiBabe::reset() oBabe::oCountDice[0] gets set to 0, but [1]-[5] stay at their previous number
[14:57] <TMM> err, this happens in obabe::countDice() not reset()
[14:57] <TMM> after countDice() oCountDice[0] is correct, but the rest isn't
[14:58] <TMM> and the other values went up by the number of dice known to aibabe
[14:58] <TMM> whatever else may be a problem I'm sure this is a problem, now I need to figure out why this happens I guess :)
[15:00] <TMM> pushi $10a ; 266, fill
[15:00] <TMM> pushi $3 ; doit
[15:00] <TMM> push0
[15:00] <TMM> pushi $6 ; isClass
[15:00] <TMM> push0
[15:00] <TMM> pToa oDieCounts
[15:00] <TMM> send $a
[15:00] <TMM> could it be that that is this 'fill' method is faulty?
[15:05] <TMM> it calls this: IntArray::fill(0000:0000, 0000:0006, 0000:0000)
[15:05] <TMM> yeah, right after this call returns the array is not fully filled with 0s
[15:08] <m_kiewitz> 6 may be a count?
[15:08] <m_kiewitz> how much of that array is filled with zeroes?
[15:08] <TMM> yeah, void fill(const uint16 index, uint16 count, const reg_t value)
[15:08] <TMM> it seems that 'index' never gets updated in that loop
[15:09] <TMM> while (count--) {
[15:09] <TMM> *target = fillValue;
[15:09] <TMM> }
[15:09] <TMM> it just puts 0 6x in the same location
[15:09] <TMM> err: while (count--) {
[15:09] <TMM> *target = value;
[15:09] <TMM> }
[15:09] <TMM> same thing though
[15:10] <TMM> let me try fixing that loop
[15:11] <-- ajax16384 left irc: Read error: Connection reset by peer
[15:11] <TMM> m_kiewitz, am I reading this completely wrong? because this seems broken
[15:13] <TMM> m_kiewitz, yeah, fixing this fill method fixes the game
[15:14] <TMM> I'll make a PR
[15:16] <logix> TMM: oh, wow, cool
[15:16] <logix> congrats
[15:17] <m_kiewitz> TMM: why does it work in the original interpreter then?
[15:17] <logix> sorry to have sent you down the wrong track...
[15:18] <TMM> m_kiewitz, does the original interpreter also just overwrite the same value 6x?
[15:18] <m_kiewitz> or wait, is there a ScummVM SCI method that is doing this?
[15:18] <TMM> m_kiewitz, yes, that's scummvm sci
[15:18] --> ajax16384 joined #scummvm.
[15:18] #scummvm: mode change '+o ajax16384' by ChanServ!ChanServ@services.
[15:18] <m_kiewitz> urgh
[15:18] <m_kiewitz> yeah that's a bug then
[15:18] <m_kiewitz> i wonder why it didn't cause other issues until now
[15:18] <m_kiewitz> or maybe it already did
[15:20] <TMM> it can't have been good
[15:21] <m_kiewitz> anyway nice job
[15:22] <m_kiewitz> i guess i will look into phantasmagoria 2 subtitle patch now
[15:29] --> LittleToonCat joined #scummvm.
[15:33] --> GitHub73 joined #scummvm.
[15:33] <GitHub73> [scummvm] hpvb opened pull request #953: SCI: Fix kArrayFill (master...sci-fix-karrayfill) https://git.io/vHZO6
[15:33] GitHub73 (GitHub73@192.30.252.41) left #scummvm.
[15:33] <TMM> m_kiewitz, snover, wjp, thanks for explaining how all these toolings work
[15:36] <wjp> oh wow
[15:36] <wjp> nice catch
[15:40] <somaen> t0by: Well, as the comment states, it attemts to check for the files existence as a relative path if it is not directly found
[15:41] <t0by> I understand, but when might that be needed?
[15:43] <snover> TMM: excellent sleuthing
[15:43] <TMM> sorry for my verbosity
[15:43] <wjp> verbosity is good :-)
[15:46] <TMM> My process is rapidly going down wrong paths, I don't know why I sometimes feel the need to narrate it
[15:46] <snover> it is helpful and interesting
[15:47] <wjp> and always very motivating to see work on sci
[15:50] <TMM> I'm heading for beers now, ttyl
[15:50] <-- TMM left irc: Quit: Ex-Chat
[16:01] <wjp> the easier fix is just adding ++ to target
[16:01] <snover> yeah, i was going to tweak the commit to do that. but it seems like there is still something not quite right going on with this dice game code. occasionally you will lose even if the opponents bet is too high
[16:02] <snover> its definitely much less broken though, so maybe now i really *am* misunderstanding something about the rules
[16:04] <snover> ok. i reread them, and i was misunderstanding the rules. :)
[16:13] <-- ajax16384 left irc: Quit: Leaving
[16:15] <-- Begasus left irc: Ping timeout: 258 seconds
[16:23] <-- _sev|work left irc: Quit: This computer has gone to sleep
[16:27] --> Begasus joined #scummvm.
[16:28] --> Farmboy0 joined #scummvm.
[16:28] <-- Farmboy0 left irc: Changing host
[16:28] --> Farmboy0 joined #scummvm.
[16:33] <somaen> t0by: When someone has that kind of path stuffed into some gamescript
[16:34] <somaen> There are even games that have full absolute paths stored in them, but the failed lookup of those files is fine, as those files would only exist on the developer's machine
[16:48] <wjp> snover, m_kiewitz: Updated sci_breakpoints branch with more actions ("none" to effectively disable a bp, and "inspect" to show the object for bpx/bpr/bpw)
[16:51] --> _sev|work joined #scummvm.
[16:51] #scummvm: mode change '+o _sev|work' by ChanServ!ChanServ@services.
[16:54] <t0by> Simei: hey, any news?
[16:56] <-- _sev|work left irc: Ping timeout: 246 seconds
[16:58] --> _sev|work joined #scummvm.
[16:58] #scummvm: mode change '+o _sev|work' by ChanServ!ChanServ@services.
[17:00] <Simei> _sev, t0by: I read a little the Common::File related code in other engine, and I think they are exactly like the standard file functions fopen, fseek, just the parameters in an other order.
[17:01] <t0by> Yes, those are pretty standard AFAIK.
[17:02] <Simei> _sev, t0by: So what I will do is just replacing them, changing the order, keep the rest as they were
[17:02] <t0by> I think so.
[17:02] <Simei> I don't need to touch stream or something, I guess
[17:02] <t0by> Hmm?
[17:02] <Simei> Ok, then I'll get started
[17:03] <t0by> Simei: before you get started I suggest you do as I said
[17:03] <t0by> add some logging next to file operations
[17:03] <t0by> exactly like you did on your other branch
[17:03] <t0by> (and commit)
[17:03] <t0by> enable fopen with the appropriate #define
[17:03] <t0by> (and don't commit)
[17:03] <t0by> and see if it still works
[17:04] <t0by> it's probably 10 minutes but well worth it
[17:04] <t0by> Then yes, proceed with porting stdio.h stuff to common/file.h
[17:04] <-- _sev|work left irc: Quit: This computer has gone to sleep
[17:05] <Simei> _sev, t0by: Ok, I'll 1. create a debug channel and add those debug logs fist, 2. define ALLOW_FILE to see if everything works well 3 begin to repace them
[17:05] <t0by> Note that File *is* a SeekableReadStream
[17:05] <Simei> Ok, I see.
[17:09] --> GitHub45 joined #scummvm.
[17:09] <GitHub45> [scummvm] wjp opened pull request #954: SCI: Various breakpoint improvements (master...sci_breakpoints) https://git.io/vHZRc
[17:09] GitHub45 (GitHub45@192.30.252.41) left #scummvm.
[17:11] <t0by> Simei: if you get stuck we're here.
[17:11] <Simei> Thanks, I won't hesitate to ask. :D
[17:12] <-- Begasus left irc: Ping timeout: 255 seconds
[17:14] Action: wjp wonders if he wants to hook up selector accesses in kernel functions to bpr/bpw
[17:22] --> GitHub5 joined #scummvm.
[17:22] <GitHub5> [scummvm] csnover pushed 1 new commit to master: https://git.io/vHZEE
[17:22] <GitHub5> scummvm/master 04fb40b Hein-Pieter van Braam: SCI32: Fix kArrayFill...
[17:22] GitHub5 (GitHub5@192.30.252.41) left #scummvm.
[17:22] --> GitHub101 joined #scummvm.
[17:22] <GitHub101> [scummvm] csnover closed pull request #953: SCI: Fix kArrayFill (master...sci-fix-karrayfill) https://git.io/vHZO6
[17:22] GitHub101 (GitHub101@192.30.252.42) left #scummvm.
[17:23] --> ajax16384 joined #scummvm.
[17:23] #scummvm: mode change '+o ajax16384' by ChanServ!ChanServ@services.
[17:24] --> Begasus joined #scummvm.
[17:26] <wjp> oh, I didn't really intend for that "SCI32: Fix warning" commit to be in there
[17:27] <wjp> snover: any opinion on that one? https://github.com/scummvm/scummvm/pull/954/commits/153f319338ffd249be077d54de7690e02ae3ac3d
[17:28] <snover> wjp: `assert(!"should never happen")`? i noticed that gcc 6 warns about that even though all the cases in CelType enum are covered
[17:29] <snover> (clang doesnt)
[17:34] --> GitHub136 joined #scummvm.
[17:34] <GitHub136> [scummvm] wjp pushed 1 new commit to master: https://git.io/vHZud
[17:34] <GitHub136> scummvm/master d9807b0 Willem Jan Palenstijn: SCI32: Fix warning
[17:34] GitHub136 (GitHub136@192.30.252.42) left #scummvm.
[17:34] <wjp> ok
[17:35] <snover> wjp: does bpact log on a bpk breakpoint supersede logkernel with this patch?
[17:36] <wjp> bpk is separate
[17:36] <wjp> they're not part of the main breakpoint list that bl, bc operate on either
[17:37] --> _sev|work joined #scummvm.
[17:37] <-- _sev|work left irc: Changing host
[17:37] --> _sev|work joined #scummvm.
[17:37] #scummvm: mode change '+o _sev|work' by ChanServ!ChanServ@services.
[17:41] <m_kiewitz> wjp: i wanted to change that at some point
[17:41] <m_kiewitz> wjp: maybe optionally (hooking up selector access in kernel funcs)
[17:58] <snover> wjp: Im going to pull this into my working branch for a few days and see how it goes. Interactive VM debugging is not something that I seem to be doing very much lately, but I will make an effort to try to exercise the code a bit.
[18:03] <tsoliman> every time I see a bunch of engines/titanic/star_control scroll by when building, it makes me think of The Ur-Quan
[18:04] <wjp> snover: great. It's not as invasive as I thought it would be, so hopefully it's pretty stable
[18:09] <-- _sev|work left irc: Quit: This computer has gone to sleep
[18:09] <tsoliman> more SCI32 bugs .. yay
[18:09] <tsoliman> "lookupSelector: Attempt to send to non-object or invalid script."
[18:09] <m_kiewitz> anyone who has disabled Intel AMT: have you checked that it's really disabled? https://mattermedia.com/blog/disabling-intel-amt/
[18:10] <m_kiewitz> tsoliman: when does that happen?
[18:10] <tsoliman> QFG4 at the beginning .. I'll log a bug unless you want to work on it right now
[18:10] <tsoliman> let me try to repro
[18:11] <tsoliman> (I violated my own rule: always get a backtrace)
[18:11] <m_kiewitz> ah nice, I'm in the mood for fixing qfg4 now :P
[18:11] <wjp> when sliding down the slimey slope?
[18:12] <tsoliman> yeah
[18:12] <tsoliman> I can't repro
[18:12] <wjp> it happens most of the time
[18:12] <tsoliman> I tried for 3 times to make it happen :(
[18:13] <tsoliman> should I keep trying to repro and log a bug?
[18:13] <m_kiewitz> tsoliman: if there is no bug yet, please do
[18:14] <snover> it is a known problem with the game, there is a patch for it (and many other things) http://www.sierrahelp.com/Patches-Updates/Patches-Updates-Games/QuestForGloryUpdates.html#QFG4CD_NRS
[18:15] <tsoliman> I thought we were not supposed to apply NewRisingSun's fixes .. at least I was told not to do so for SQ4
[18:15] <m_kiewitz> yeah, we shouldn't
[18:15] <m_kiewitz> because we want to document the issues properly and also solve them properly
[18:16] <m_kiewitz> which means not breaking saved games and game being patched on-the-fly
[18:17] <m_kiewitz> and - when possible - having 1 signature for all game versions
[18:22] <snover> so, how is a patch from sierra more proper than a patch from NRS?
[18:22] <Simei> _sev, t0by: Oops, I find that I forget to add namespace for new added files. So I think, I'm going to add namespaces and some debug info, and amend the last commmit ?
[18:24] <m_kiewitz> snover: it's official and still we actually fix a few issues, that were also patched by Sierra as well
[18:25] <m_kiewitz> for example qfg2 import character, if I remember correctly
[18:26] <snover> how is official more proper? if a fan patch is bundled into a release on steam or GOG from the publisher, does that mean it is now proper because the official publisher included it?
[18:26] <m_kiewitz> GOG hacks stuff, which I do not like. qfg3 gog for example is fully broken by fan patches
[18:27] <m_kiewitz> new issues were introduced and also our workarounds do not match anymore, because someone had the brilliant idea to recompile scripts
[18:27] <m_kiewitz> and GOG simply does that to make the games at least somewhat work
[18:27] <m_kiewitz> when we properly fix them all, GOG won't have to hack up games anymore
[18:28] <m_kiewitz> so no, just because such a site adds a fan patch doesn't make it official
[18:28] <m_kiewitz> i personally do not want to waste my time fixing additional bugs created by fan patches. i will rather tell the users which patch files to remove
[18:29] <m_kiewitz> that's why I'm working on the better saved game support. because right now this is sadly not possible
[18:29] <snover> but you are ok fixing additional bugs created by sierras own patches?
[18:29] <m_kiewitz> (w/o restarting the game)
[18:29] <m_kiewitz> i don't think there is a single new bug introduced by sierra patches
[18:29] <m_kiewitz> there aren't that many official sierra patches anyway
[18:30] <m_kiewitz> i do not even understand why we are discussing this. why did you add a speed throttler? that will also fix some issues already "fixed" by some fan patches
[18:30] <m_kiewitz> if you do not want to waste your time on it, that's fine
[18:31] <m_kiewitz> however i do. Because I also want that localized games will properly work
[18:31] <m_kiewitz> and those patch files often do not work on localized versions
[18:31] <m_kiewitz> that's why i added script patcher functionality in the first place
[18:31] <t0by> Simei: make an extra commit adding the namespace
[18:32] <Simei> Ok, I see
[18:32] <m_kiewitz> it's also a hassle for the user anyway. User plays game. Gets to broken room. Game crashes. We then tell him, that he should have patched the game using an inofficial patch.
[18:33] <m_kiewitz> and sure, we can add detection and then tell the user to use unofficial patches depending on the game version, but for what? is that user friendly?
[18:33] <tsoliman> m_kiewitz: https://bugs.scummvm.org/ticket/9801
[18:33] <m_kiewitz> and when it's a localized version, then we tell him that he's out of luck? or do we patch those? or tell the fans?
[18:33] <m_kiewitz> tsoliman: thx
[18:34] <tsoliman> DOS CD (from the anthology)
[18:34] <snover> i am not trying to be combative, i just want to understand where this line is drawn
[18:34] <snover> where/why
[18:34] <m_kiewitz> we already have tons of script patches, so I have no idea why it matters. Yes, qfg4 will take a bit of work. But most issues won't be a problem because of speed throttling
[18:34] <m_kiewitz> when sierra just patched something tiny, then I will try to add it into the script patcher - as I already did.
[18:35] <m_kiewitz> and i think right now we check longbow for the official sierra patch because there is a game breaking bug in there
[18:35] <m_kiewitz> and then tell the user. which is granted sub-optimal, but I never had the time to look into it.
[18:35] <snover> yes. i have a pending patch to do the same thing for torin, which crashes when TORINPAT is not applied to the game
[18:36] <m_kiewitz> the point is to make it as simple for the user. it's simply supposed to work in the end.
[18:36] <m_kiewitz> yes, that's great. I think it's also quite nice to get those issues fully documented.
[18:36] <snover> (my patch for torin also enhances the ux to send people to the download now that we can open URLs, but i keep forgetting to talk about it)
[18:37] <snover> for qfg4 im not sure how some of these things can be fixed without expanding the script space, like the antwerp maze puzzle speed problem.
[18:37] <m_kiewitz> the qfg4 update for floppy to 1.1a, i don't know. that one is actually quite large and fixes quite a lot of issues
[18:37] <m_kiewitz> my current path is: fix everything for CD. then look for floppy afterwards
[18:38] <snover> in the NRS patch, script 81 appears to be recompiled, because there arent enough (or any, that i could see) slack bytes in the script to change how the puzzle speed works
[18:38] <m_kiewitz> you added those new kernel ops. maybe i will even have to add functionality into the script patcher, idk yet
[18:39] <m_kiewitz> i guess we could even add functionality to extend script space right when they are loaded via script patcher, but i will have to see. there are tons of tricks with SCI bytecode
[18:40] <m_kiewitz> the phantasmagoria 2 subtitle fan patch is also problematic - it's not really a patch, effectively contains all scripts of the game, breaks saved games, and forces subtitles if i remember correctly
[18:40] <tsoliman> well now I can't not reproduce it :(((
[18:41] <m_kiewitz> and of course does not work with localized versions (they added quite a bit of text, so I guess we will have to add that somehow and/or offer the corresponding additional files, idk yet
[18:42] <m_kiewitz> as i see it, the NRS patch for qfg4 cd only fixes a few actual script issues. most if not all timer issues shouldn't happen already, so no need to patch them
[18:43] <m_kiewitz> at least in sq6 i was unable to reproduce the widely known machine speed bug when you enter the spaceship for the first time
[18:44] <snover> i feel like a stronger case could be made to not support something like that subtitles patch, versus something that just fixes bugs. that said, we'll need to support the lighthouse 2.0 patch, which was official and added an entirely new hint subsystem and changed some puzzles to make them easier
[18:45] <snover> i need to go, i will be back later
[18:46] <m_kiewitz> yes, that one we surely won't implement via script patcher
[18:46] <m_kiewitz> i personally think we should block certain fan patches at some point, at least in a way that the user has to acknowledge that fan patches were used and that issues may occur
[18:47] <m_kiewitz> which means not a hard block, but a soft block, like for qfg3 GOG.
[18:47] <m_kiewitz> if someone wants to go through the game and fix all the new issues and fix the non-matching workarounds for that version - fine by me. But I personally won't do it, because I see it as a huge waste of time.
[18:48] <m_kiewitz> it's also somewhat like a neverending story, fix this fan patch and then something else gets released. fix that one too, etc.
[18:55] <m_kiewitz> snover: urgh Access violation reading script.100 buffer: 2504 + 2 > 2505 (abs: 2504 + 2 > 250
[18:55] <m_kiewitz> 5)!
[18:55] <m_kiewitz> qfg4 cd
[18:56] <m_kiewitz> tsoliman: your qfg4 cd works fine?
[18:56] --> girafe joined #scummvm.
[18:59] <wjp> hm, my script 100 is 0x63e bytes
[18:59] <wjp> (according to hexdump script 100)
[19:02] <m_kiewitz> maybe i have a script dump somewhere :/
[19:03] <m_kiewitz> we should have a debug command to figure out the file where the resource is loaded from (unless we already have)
[19:04] <wjp> debug> resource_info script 100
[19:04] <wjp> Resource size: 1598
[19:04] <wjp> Resource location: 100.SCR
[19:04] <wjp> Resource hash (decompressed): 1a369ae3c37f3b07735cfd06d00c1494
[19:05] <m_kiewitz> hmm mine is 1600 bytes
[19:05] <wjp> For things in the resource files you get Resource location: RESOURCE.000
[19:05] <m_kiewitz> inside patches directory
[19:06] <m_kiewitz> it would be nice in case that command showed the directory of it
[19:06] <wjp> the patch file itself will be 1600 bytes
[19:06] <m_kiewitz> ah yes, it shows 1598 bytes too for me
[19:06] <m_kiewitz> ye
[19:06] <m_kiewitz> yes
[19:07] <m_kiewitz> but for me the saved game doesn't load
[19:07] <m_kiewitz> for you it does?
[19:07] <m_kiewitz> https://bugs.scummvm.org/ticket/9801
[19:08] <wjp> hm, no, same error in fact
[19:08] <wjp> oh, the buffer is script + heap I guess
[19:09] <m_kiewitz> right
[19:09] <m_kiewitz> tsoliman: any patches installed? which qfg4 version is that?
[19:09] <m_kiewitz> maybe floppy even?
[19:10] <wjp> he said CD from anthology
[19:11] <m_kiewitz> hmm i tried with my anthology too, same error

[19:11] <m_kiewitz> ?
[19:11] <wjp> yeah
[19:12] <wjp> interestingly I get a similar error when loading one of my own saves too (from Feb)
[19:12] <m_kiewitz> o_O
[19:13] <wjp> could be too old
[19:14] <wjp> this one works for me: https://www.usecode.org/scummvm/qfg4-cd-win.001
[19:14] <wjp> from that one, walk left one screen, and then down the slope
[19:15] <wjp> oh, I should say that's from the GOG+NRS version
[19:15] <wjp> so YMMV
[19:17] <m_kiewitz> will just start from the start :P
[19:19] <wjp> WARNING: Uninitialized read for parameter 1 from method hero::changeGait (room 770, script 28, localCall ffffffff)!
[19:20] <tsoliman> m_kiewitz: yeah it is a new game I just started in 2017 imported from a really old QFG3 scummvm character
[19:21] <m_kiewitz> tsoliman: your saved game works for you?
[19:21] <tsoliman> yeah
[19:21] <tsoliman> that's how I attempt to repro
[19:21] <m_kiewitz> because for me loading it from GMM error()s out
[19:21] <tsoliman> I load from GMM and try over and over and over
[19:21] <m_kiewitz> you loaded from ScummVM menu directly?
[19:21] <tsoliman> oh wait
[19:21] <tsoliman> yeah from launcher
[19:21] <tsoliman> not from GMM sorry
[19:21] <m_kiewitz> hmm, and you own qfg anthology CD?
[19:21] <tsoliman> yes
[19:21] <m_kiewitz> because I own that too and for me the saved game doesn't work
[19:22] <m_kiewitz> you are up-to-date on master?
[19:22] <tsoliman> yes .. let me try pure master
[19:22] <tsoliman> I have a few local diffs that shouldn't matter
[19:22] <m_kiewitz> really weird
[19:24] <tsoliman> I also have "QFG Collection" from Steam and "QFG 1-5" from GOG .. do you want me to try to repro with one of those?
[19:26] --> waltervn joined #scummvm.
[19:26] #scummvm: mode change '+o waltervn' by ChanServ!ChanServ@services.
[19:26] <m_kiewitz> wjp: where do I get a flint from? right at the start
[19:26] <m_kiewitz> tsoliman: you can, but i would really like to know why your saved game works for you, but not for me and also not for wjp :/
[19:27] <Simei> _sev, t0by: I've pushed the commit for adding namespace
[19:27] <m_kiewitz> wjp: wait, I have a flint. I need steel
[19:27] <wjp> you have a dagger
[19:27] <wjp> you may need a torch
[19:27] <m_kiewitz> no, i dont
[19:27] <t0by> Simei: of course it compiles, right?
[19:27] <m_kiewitz> i'm a thief, not imported
[19:27] <wjp> oh, one of the bodies on the floor has it then
[19:27] <Simei> Yes
[19:27] <t0by> Simei: now let's get to the main business :)
[19:27] <tsoliman> m_kiewitz: I'll investigate
[19:28] <wjp> there are three skeletons on the floor you can loot
[19:28] <Simei> Ok.
[19:28] <wjp> one directly near where you start, and two in the middle of the room
[19:28] <m_kiewitz> wjp: i only found 2. In the middle of the screen
[19:28] <m_kiewitz> ah
[19:28] <wjp> and there's a torch in a torch holder on the middle-right
[19:29] <m_kiewitz> yeah got that one already
[19:30] <wjp> kind of odd though; I thought you're meant to automatically trip over the first skeleton if you don't loot it manually
[19:30] <wjp> (and then pick up the dagger automatically too)
[19:34] <m_kiewitz> wjp: how do i trigger the slope bug?
[19:34] <m_kiewitz> it's right after meeting the lady
[19:34] <m_kiewitz> right?
[19:35] <t0by> m_kiewitz: https://github.com/mjg59/mei-amt-check/
[19:35] <wjp> yes, on the screen to the left of there
[19:35] <t0by> sorry, wrong window
[19:35] <wjp> basically just walk down it
[19:35] <m_kiewitz> doesn't crash
[19:35] <m_kiewitz> is it random?
[19:36] <m_kiewitz> ah wait, i just happened
[19:36] <wjp> it depends a bit on the path you take
[19:37] <wjp> did you get that uninitialized read I copy-pasted earlier when lighting the torch?
[19:37] <wjp> (20 minutes ago)
[19:38] <m_kiewitz> nope
[19:38] <m_kiewitz> im a thief right now
[19:38] <wjp> I was as well
[19:38] <tsoliman> m_kiewitz: I diffed the files on my datadir with the files on the root dir of the Anthology CD and they are identical except for *.ico, *.exe, *.bat (files only on the root)
[19:39] <m_kiewitz> wjp: ah wait, i got it
[19:39] <m_kiewitz> i got it even twice
[19:39] <wjp> me too
[19:40] <wjp> 20 minutes ago, the mouse cursor also turned invisible at the same time
[19:40] <tsoliman> it is a pain to repro .. but then it repros and doesn't wanna stop reproing .. the trick seems to be to walk in one shot as soon as you enter the screen? I dunno
[19:40] <wjp> but this time I get those two uninitialized reads while the cursor remains visible
[19:44] <m_kiewitz> wjp: that sliding down wasn't fixed at all?
[19:44] <wjp> ?
[19:44] <m_kiewitz> i mean i see that possibly scriot 28 is responsible, but there is no script 28 in the NRS patch
[19:44] <m_kiewitz> *script
[19:44] <wjp> it's fixed by NRS
[19:45] <m_kiewitz> it is? i didn't see it being mentioned in the patch text file
[19:45] <wjp> it's "error 47"
[19:45] <m_kiewitz> ah nvm
[19:45] <m_kiewitz> yes
[19:45] <m_kiewitz> just saw it
[19:48] <tsoliman> m_kiewitz & wjp: how did you dump the game data? installed the game and then took the files or what? What dirs did you copy out of the anthology CD?
[19:48] <m_kiewitz> tsoliman: simply the whole CD, all files
[19:49] <m_kiewitz> ah wait, you didn't copy over the patches directory?
[19:49] <tsoliman> no
[19:49] <tsoliman> sorry? :(
[19:49] <m_kiewitz> nah, that explains why your saved game doesn't work for us
[19:49] <m_kiewitz> phew
[19:49] <tsoliman> the whole CD contains other QFG game dirs
[19:49] <m_kiewitz> yes, but patches are patch files for qfg4 cd
[19:49] <tsoliman> ok .. so I seem to have copied JUST the files from the root dir
[19:50] <tsoliman> (and then went and deleted ico files and other junk)
[19:50] <tsoliman> ok I will redump
[20:11] --> xorAxAx joined #scummvm.
[20:11] <xorAxAx> hey, are there any scummvm games that are open source itself?
[20:16] <_sev> xorAxAx: what exactly do you mean?
[20:16] <_sev> xorAxAx: scummvm is open source, you can see how engine works in every detail
[20:18] --> TMM joined #scummvm.
[20:18] #scummvm: mode change '+o TMM' by ChanServ!ChanServ@services.
[20:18] <xorAxAx> _sev: i mean games, not the VM
[20:18] <xorAxAx> like, fangames
[20:19] <TMM> snover, thanks for fixing that PR
[20:20] <_sev> xorAxAx: lots of them. There are fangames for AGI, SCI. Broken Sword 2.5 is fully a fangame
[20:20] <_sev> xorAxAx: then, number of engines have script decompilers written by us
[20:20] <_sev> xorAxAx: and wintermute engine is mostly fangames too
[20:20] <_sev> xorAxAx: with authoring tools
[20:21] <Simei> _sev, t0by: All debug log are printed well with fopen and fclose. I'm going to replace them now.
[20:21] <_sev> Simei: great
[20:22] <t0by> Simei: that goes also for Welcome2?
[20:22] <_sev> Simei: if you need any help for our API, just ask
[20:22] <t0by> Just asking, if so it's very very good.
[20:22] <Simei> Haven't tested Welcome2 yet. I will test it now.
[20:23] <t0by> I'm curious to know if it crashes horribly or not
[20:23] <Simei> Thanks :D
[20:30] <Simei> _sev, t0by: There is still "Segmentation fault" with welcome2 and verb coin :/
[20:31] <t0by> Eh.
[20:31] <_sev> Simei: and what is the backtrace?
[20:31] <Simei> How to see it under Linux ?
[20:32] <t0by> Use a debugger.
[20:32] <_sev> gdb scummvm
[20:32] <t0by> I would strongly suggest using an IDE for this purpose
[20:32] <_sev> run welcome2 (or whatever you use)
[20:32] <t0by> unless you want to learn gdb...
[20:32] <_sev> once it crashes, type 'bt'
[20:32] <_sev> t0by: on Linux?
[20:33] <t0by> _sev: I find that if you have never ever dealt with a debugger having the information presented in a nice, visual GUI helps. I do use gdb (well, gdb with gud in emacs) nowadays, but...
[20:34] <t0by> But sure, let's see what bt yields for now
[20:34] <Lightkey> but is it gud?
[20:34] <t0by> It is.
[20:34] <Simei> I don't know how to use gdb, is there any document about it ? :/
[20:34] <t0by> Your jokes are bud, though.
[20:35] <Lightkey> don't hit me!
[20:35] <Simei> Ah, I have it
[20:35] <t0by> Simei: for now do exactly as _sev instructed you
[20:35] <_sev> t0by: so, which Linux IDE you're talking about?
[20:35] <_sev> t0by: I know 'ddd' but it is even worse
[20:35] <t0by> _sev: *shrug* Eclipse+CDT
[20:35] <t0by> I find QtCreator is also pretty usable
[20:35] <_sev> t0by: and it shows you proper C++ multithreaded backtraces?
[20:36] <Simei> https://www.irccloud.com/pastebin/XYwt0jfO/
[20:36] <tsoliman> Eclipse+CDT is also what I used to use in Linux .. in the newest MacOS it works but not the debugger
[20:36] <t0by> _sev: it does.
[20:37] <_sev> t0by: nice
[20:37] <_sev> in the meantime Simei just got it :)
[20:37] <t0by> Aaaah
[20:37] <t0by> Clearly.
[20:37] <_sev> Simei: so, apparently there are some memory allocation issues
[20:37] <t0by> Let me see
[20:37] <Simei> But, I don't understand, there is no addPerson in Welcome2
[20:38] <criezy> The only gdb frontend I have used if ddd, until I started using QtCreator.
[20:38] <criezy> But I still mostly use command line gdb :P
[20:38] <_sev> Simei: addCharacter?
[20:38] <tsoliman> m_kiewitz: all my saves won't load now but I was at the very beginning so it is cool .. I am so very glad you helped me realize that I was missing the files before I invested hours and hours into it
[20:38] <m_kiewitz> the bug still happens, and I got my own saved game right now
[20:38] <Simei> _sev: yes, no addCharacter
[20:38] <m_kiewitz> you can try to slide down and then continue when it doesn't crash
[20:40] <t0by> Let me see
[20:40] <-- Begas_VBox left irc: Read error: No route to host
[20:41] <Simei> Maybe it's the if else thing?
[20:42] <_sev> Simei: try to print out "fun -> reg.varData.intValue"
[20:42] <_sev> at engines/sludge/sludger.cpp:908
[20:42] <Simei> Ok
[20:42] <t0by> (as a side note, I would have rather written a script with an iterative construct and one with a function call, generally those are a better way to know if your interpreter is borked and, in particular, if it's doing funny things to the stack)
[20:42] <snover> (fwiw, i havent used debugged c++ in vscode, but i have used its intellisense with c++; it is a much better editor than eclipse in my experience. and it does support multithreaded debugging. https://code.visualstudio.com/docs/languages/cpp)
[20:43] <t0by> All hail the One True IDE
[20:43] <-- Begasus left irc: Ping timeout: 272 seconds
[20:43] <t0by> _sev: why BR_PAUSE?
[20:44] <_sev> t0by: because you're using outdated sources?
[20:44] <t0by> ah, nevermind
[20:44] <t0by> I'm one commit behind
[20:44] <t0by> ^
[20:44] <_sev> Simei: are you able to run the original?
[20:44] <_sev> Simei: and particularly, modify it and run?
[20:45] <Simei> Yes
[20:45] <Simei> Compare the two?
[20:45] <_sev> Simei: exactly
[20:47] <t0by> this is puzzling
[20:48] <t0by> I entertained for a second the idea that "beenHere" is a special variable name
[20:48] <t0by> but no
[20:48] <t0by> uh
[20:50] <Simei> Wierd, this time, it works fine :/
[20:50] <Simei> I will try the verb coin, more complicated
[20:50] <t0by> um
[20:50] <t0by> Simei: what do you mean "this time"?
[20:50] <t0by> What have you changed?
[20:51] <Simei> add one more debug log :/
[20:51] <TMM> snover, I don't know when last you used eclipse, but cdt (when properly configured) can certainly match intellisense these days. And the gdb integration with eclipse is superb
[20:51] <Simei> But Verb Coin still crashed
[20:51] <t0by> Oh. That's part and parcel of memory errors.
[20:52] <t0by> They are so cute in their nondeterminism.
[20:52] <t0by> So fuzzy and sweet.
[20:52] <t0by> Let me have a look
[20:52] <TMM> isn't that why we have valgrind now?
[20:52] <t0by> TMM: guess what I'm doing?
[20:54] <Simei> That doesn't sound very good :/
[20:54] <TMM> maybe we should give Simei a crash course in valgrind?
[20:54] <Simei> Yes, please!
[20:55] <TMM> give a programmer the location of a stack fuckup and they are happy for a day, teach them to valgrind and they'll never bother you again
[20:55] <TMM> or something
[20:55] <snover> TMM: i admit it has been quite a while, but the problems i had with eclipse were primarily due to its being written in java, and that part hasnt changed
[20:55] <t0by> Much to nobody's surprise, I just had Welcome.slg segfaulting on me as well.
[20:56] <TMM> snover, well, yeah. I'll take something that works written in Java (rare as that may be) over something written in something else that works less well :P The only 2 IDEs I've used that are actually what I'd call 'helpful tools' are eclipse and kdevelop.
[20:56] <t0by> Simei: http://valgrind.org/docs/manual/quick-start.html
[20:57] <TMM> Simei, what platform are you on?
[20:57] <Simei> Ubuntu 16.04
[20:57] <Simei> Thanks!
[20:57] <TMM> Simei, ok, have you ever used valgrind before?
[20:57] <Simei> No, sorry :/
[20:58] <TMM> Simei, the quickstart t0by sent you there actually looks pretty good :) just try running valgrind on that broken demo program
[20:58] <TMM> Simei, if you have any questions after that feel free to ask
[20:59] <Simei> t0by, TMM: Ok, I'll try it. Thanks :)
[20:59] <t0by> I am terrified that we're running a random memory area as bytecode.
[20:59] <t0by> Let me double check
[21:02] <t0by> Simei: out of curiosity, where have you defined ALLOW_FILE?
[21:03] <Simei> Ah, not define yet in the last push
[21:03] <Simei> I will push what I have now to a new branch ?
[21:03] <t0by> no no no
[21:03] <t0by> don't commit
[21:03] <t0by> just where.
[21:04] <Simei> I define it in allfiles.h here
[21:04] <Simei> I let it undefined in the previous push
[21:05] <Simei> It's not very well organized in the last push
[21:08] <Simei> https://github.com/yinsimei/scummvm/commits/debug_branch
[21:08] <TMM> Simei, are you porting the existing sludge runtime to osystem, or are you reverse engineering the whole engine?
[21:09] <t0by> #1
[21:09] <t0by> Simei: I'm sorry, what exactly have you done to make it compile?
[21:10] <t0by> starting from b809516, that is
[21:11] <Simei> Just put the undefined funtions into #if 0 #endif
[21:11] <t0by> Simei: checkout -b crap_branch && commit -m "useless commit" && push it
[21:11] <t0by> please.
[21:11] <Simei> https://github.com/yinsimei/scummvm/commits/debug_branch
[21:11] <t0by> thanks
[21:11] <t0by> lemme see
[21:14] <snover> m_kiewitz: can i remove setting r_acc in EngineState::wait yet?
[21:14] <m_kiewitz> im on it...
[21:14] <m_kiewitz> not yet
[21:15] <snover> ok, thanks
[21:15] <TMM> are there any more fun sci bugs like the dice game thing? I actually had some fun doing that and I now loaded up my brain with all this sci context
[21:15] <TMM> might as well try to fix a couple more
[21:16] xorAxAx (alexander@moinmoin/coreteam/alexander) left #scummvm ("WeeChat 1.8").
[21:16] <snover> Tmm, I have some ideas. On phone so I'll be slow
[21:18] <snover> First thing that comes to mind are some problems with the computer interface in phant2, there are some bad reads that make Curtis's computer scroll bars not worj
[21:19] <snover> Also all the save games get PROTECTED added to their names
[21:20] <TMM> OK, I haven't played phant2 at all yet
[21:20] <TMM> Is it in any way a continuation of phant1?
[21:21] <snover> Nope, totally new story
[21:21] <TMM> ok, I'll just play it then
[21:21] <snover> There is also a problem with the ratboy puzzle, it needs to have some spin loops replaced with calls to kScummVMWaitId
[21:22] <snover> When you win the puzzle
[21:22] <TMM> You'll know when I am working on it as I'll probably be textwalling here again :P
[21:22] <wjp> m_kiewitz, snover: suggestion for making the bpk/logkernel interface part of the main breakpoint list: "bpk FrameOut" sets bp on frameout; "bc #" clears it again; "bpk *" sets bp on all kernel calls (in a single entry in the bp list), "bpk * log" enables logging from all calls (and "bpk * bt" backtraces). Logkernel would disappear (or could remain an alias for "bpk x log")
[21:22] <snover> Tmm Sounds good to me
[21:23] <m_kiewitz> all kernel calls? o_O
[21:23] <wjp> like "bpk * on" currently
[21:23] <t0by> hee he
[21:23] <m_kiewitz> what are you trying to do? :P
[21:23] <wjp> suggesting an interface
[21:23] <m_kiewitz> nah, just kidding
[21:24] <m_kiewitz> i don't think logging should work via "bpk"
[21:24] <m_kiewitz> "bpk * bt"? how would that work?
[21:24] <m_kiewitz> what is it supposed to do?
[21:25] <wjp> it would be a natural consequence of combining bpk with these new breakpoint actions I've added today
[21:25] <snover> Sounds ok to me on first reading
[21:25] <snover> Wondering idly about harmonising the wildcard syntax
[21:25] <TMM> having logging without breaking would've helped me track down that bug a lot quicker too, I certainly like the feature
[21:25] <snover> Since for objects right now it is obj::
[21:25] <wjp> in my current sci_breakpoints branch, you can do "bpx Ego::doit log" and "bpx Ego::doit bt" to set breakpoints that don't actually break, but only log the trigger, or print a backtrace when it gets triggered
[21:26] <m_kiewitz> "bpk * log" seems really weird to me, you want to log, but you no breakpoint?
[21:26] <snover> But for kcalls it is kFoo*
[21:26] <m_kiewitz> ah
[21:26] <snover> Er, foo*
[21:26] <wjp> (FWIW, in gdb you can also make breakpoints not break but only do other things)
[21:26] <t0by> Rats.
[21:27] <TMM> m_kiewitz, that's actually super useful for when you're trying to figure out in what order something is called. After figuring out that AIBabe always thought that you were bluffing because it thought your bet was impossible it became a lot more clear where to look for the error.
[21:27] <TMM> m_kiewitz, I ended up doing that by generating a list of bp_method lines for scummvm debugger with sed from the disassembly of the script file :P
[21:27] <m_kiewitz> wjp: yes, but that' why i think it's weird having those under bpk
[21:28] <wjp> snover: yeah, that wildcard syntax could probably be more consistent
[21:28] <m_kiewitz> let me check what SoftICE offers in that regard
[21:30] <m_kiewitz> ah it actually has something similar
[21:30] <m_kiewitz> but right, it actually offers those for all sorts of breakpoints
[21:30] <snover> Being able to get all kernel calls with bts and post process sounds useful to me
[21:31] <t0by> I'm sorry, I'm stupid, how do I make super sure I am reading *all* debug messges?
[21:31] <m_kiewitz> bpr xxx tw
[21:31] <t0by> -d 9999 will give me everything?
[21:31] <snover> Well that IS over 9000
[21:31] <m_kiewitz> so I guess what would be really nice is to have log + bt for bpr, bpw and bpx
[21:31] <t0by> No, I mean -- -d alone will give me everything?
[21:32] <m_kiewitz> wjp: ^^
[21:32] <wjp> wasn't 11 the special one?
[21:32] Action: wjp looks
[21:32] <wjp> yes, set debug level to 11 to enable all channels
[21:32] <TMM> makes sense, it's setting the volume knob to 11 ;)
[21:33] <t0by> _sev, Simei: in that case I get exactly zero log messages from the engine.
[21:33] <wjp> m_kiewitz: log and bt for bpr, bpw and bpx is already in my branch now
[21:33] <t0by> wjp: thanks
[21:33] <t0by> Simei: how are you calling it?
[21:33] <m_kiewitz> great, well then yes add kernel breakpoints to that bunch
[21:33] <wjp> m_kiewitz: and I also expanded bpr and bpw to catch the property access opcodes
[21:34] <Simei> scummvm -d 11
[21:34] <wjp> (aTop, sTop, pToa and such)
[21:34] <t0by> Simei: and you are getting *any* debug output from your engine at all?
[21:34] <m_kiewitz> i wanted to do that for a long time :/ never had time to do it
[21:34] <Simei> Do you want the sludge engine with printf message ?
[21:34] Action: wjp has a 4 day weekend and nothing much to do :-)
[21:34] <m_kiewitz> have you added an option to also break on kernel selector access?
[21:34] <m_kiewitz> you're lucky
[21:34] <t0by> We use debug, I guess.
[21:35] <wjp> no, not hooked up to selector access in kernel calls
[21:35] <t0by> Simei, so are you getting *anything at all*?
[21:35] <m_kiewitz> that should be optionally possible too
[21:35] <m_kiewitz> would be really nice to really catch them all[tm]
[21:36] <wjp> there are some annoying corner cases with -info- and such
[21:36] <Simei> t0by: I'm trying to compare the two out put
[21:36] <m_kiewitz> how so?
[21:36] <t0by> o_O
[21:36] <wjp> some of these have custom accessors
[21:36] <Simei> t0by: Sorry, what's your question ?
[21:37] <t0by> Simei: you have peppered your engine with debug() calls.
[21:37] <Simei> t0by: I use scummvm -d 11
[21:37] <t0by> Are you reading *any* of those in your output?
[21:37] <wjp> m_kiewitz: so far example a 'bpr something::-info-' would be ... interesting
[21:37] <wjp> s/far/for/
[21:37] <t0by> So do I, but I'm not getting anything :\
[21:37] <-- girafe left irc: Read error: Connection reset by peer
[21:37] <t0by> wait a second
[21:37] <t0by> let me see if I'm stupid
[21:38] <t0by> Simei: anyway, are you reading those in your output or not?
[21:38] <m_kiewitz> wjp: let's go really crazy and support *::-info-
[21:38] <m_kiewitz> and ego::*
[21:38] <Simei> t0by: Yes, I am
[21:38] <m_kiewitz> unless there is already support for one of those, idk
[21:38] <t0by> Simei: thanks
[21:39] <t0by> Simei: can you pastebin your output?
[21:39] <t0by> (with -d11)
[21:39] <Simei> from valgrind or the normal one ?
[21:40] <wjp> m_kiewitz: 'bpr GKIconbar::' will catch all reads from GKIconbar
[21:40] <wjp> which is, um, a lot
[21:40] <m_kiewitz> is that new?
[21:40] <wjp> kind-of
[21:40] <wjp> it was broken in 2011
[21:40] <m_kiewitz> oh
[21:40] <wjp> (TMM and snover noticed that last night)
[21:41] <Simei> https://www.irccloud.com/pastebin/5S6424Dt/
[21:41] <Simei> t0by: this one is good from welcome2
[21:42] <t0by> Simei: your git head is bf7298d66, right?
[21:42] <Simei> https://www.irccloud.com/pastebin/3vveVAFB/
[21:43] <Simei> Yes
[21:43] <t0by> With no modifications at all?
[21:43] <Simei> Not at all
[21:44] <t0by> Simei: and your command line is *just* ./scummvm -d11?
[21:45] <Simei> t0by: just "scummvm -d 11"
[21:46] <-- Henke37 left irc: Quit: ERR_SHUTDOWN
[21:46] <Simei> t0by: You have the space between -d and 11?
[21:46] Action: t0by blanks
[21:47] <-- wanwan left irc: Quit: poof
[21:48] <Simei> :)
[21:48] <t0by> Yes, I have.
[21:50] <Simei> That's quite wierd :/
[21:51] <t0by> Simei: anyway, please go on with your business
[21:52] <Simei> _sev, t0by: So I ignore the crash and continue to replace the fopen funtions?
[21:53] <t0by> Apparently my build quits on if (!initSludge(sludgeFile)) return 0;
[21:53] <Simei> Ah
[21:54] <t0by> Simei: yes, please continue.
[21:54] <Simei> should run terminal in the same folder as the game
[21:54] <t0by> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
[21:54] --> wanwan joined #scummvm.
[21:54] <t0by> I'm a stupid idiot
[21:54] <Simei> Sorry, I forgot to talk about that
[21:54] <t0by> sorry for wasting your time
[21:54] <t0by> I should have seen that
[21:56] <t0by> Simei: so far what I see from the debug output looks good enough, please continue, don't waste anymore time
[21:56] <Simei> Ok, so I begin the replacement
[21:57] <t0by> Simei: well wait a second.
[21:58] <t0by> We were trying to investigate a segfault
[21:58] <t0by> What does valgrind tell you?
[21:59] <Simei> You want the part of the output ?
[21:59] <TMM> snover, phant2 doesn't start at all for me on master. Is that expected?
[21:59] <TMM> [VM] kFileIO(ReadString): signature mismatch in method p2::init (room 0, script 0, localCall ffffffff)!
[22:02] <TMM> parameter 0: 0017:0036 (object), should be reference
[22:02] <TMM> parameter 1: 0000:0001 (integer), should be null, integer
[22:02] <TMM> parameter 2: 0000:0009 (integer), should be null, integer
[22:02] <TMM> [VM] kFileIO(ReadString): signature mismatch in method p2::init (room 0, script 0, localCall ffffffff)!
[22:02] <TMM> I guess ReadString needs to be able to deal with objects? I'll see if I can figure out what's up
[22:04] <m_kiewitz> bad Sierra, bad
[22:05] <m_kiewitz> phantasmagoria 2 works for me
[22:05] <t0by> Simei: in general.
[22:05] <Simei> https://usercontent.irccloud-cdn.com/file/U1FswFsv/valgrind_verb%20coin
[22:05] <t0by> I can't reproduce the segfaulting under valgrind.
[22:06] <Simei> Do you try Verb Coin ?
[22:06] <Simei> Welcome2 is good for me as well
[22:06] <t0by> Oh, there you probably have it
[22:06] <t0by> variable undefined was added to the stack
[22:06] <t0by> I smell a rat there.
[22:07] <t0by> Simei: tell you what, go on with the replacing.
[22:07] <t0by> We'll see about this later.
[22:07] <t0by> It's too late to go byte-chasing.
[22:07] <Simei> Ok
[22:07] <TMM> yeah, sleepytime for me too
[22:09] <TMM> m_kiewitz, looks like it tries to read some data in a class String
[22:09] <TMM> m_kiewitz, that's probably the object reference there
[22:10] <m_kiewitz> object pointers are considered objects and not references, i think snover said something about sierra doing all sorts of weird things with certain classes
[22:12] <TMM> yeah, looks like they did that here. I wonder if it'll just work if I change the prototype
[22:15] <wjp> that might have rather interesting effects
[22:15] <TMM> got to start somewhere
[22:15] <wjp> as in, overwrite the object with the string. Which may or may not be intended behaviour :-)
[22:16] <TMM> wjp, yeah, or may be exactly what ssci does ;)
[22:16] <TMM> but yeah, judging by the implementation I don't see this working very well
[22:16] <TMM> may actually need to do an implementation of ReadString that can deal with string objects
[22:17] <wjp> but, bedtime; good night
[22:17] <TMM> wjp, well, it sure starts now :P
[22:18] <TMM> anyway, yeah, bedtime
[22:24] Action: t0by is cursing horribly in italian
[22:26] <m_kiewitz> snover: i just took a look at the qfg4 cd slope issue
[22:26] <m_kiewitz> you don't want to know what the NRS patch is doing
[22:26] <snover> TMM: thats interesting. did you copy the data from your discs according to the datafiles wiki?
[22:27] <snover> i cant remember all the places where SCI32 allowed Str objects to be passed directly to array/string kernel calls
[22:27] <TMM> snover, I just copied over the gog.com install dir
[22:28] <snover> is there a RESDUK.PAT file?
[22:28] <TMM> conceptually at least it makes sense to me that you should be able to pass a string as a target for a read call
[22:28] <snover> the string of a Str object is located at Str::data
[22:28] <snover> it is not itself a string
[22:29] <TMM> snover, there's no resduk.pat
[22:29] <snover> kFileIO is kind of a nightmare, I did not reverse it and there are a lot of workarounds in there for things like emulating file seeking on writable files, using game id prefixes, etc.
[22:30] <TMM> there are however a bunch of patches included
[22:30] <TMM> including for the script number that has the read call in it
[22:30] <TMM> let me see if the original has it too
[22:30] <TMM> may be a b0rken fan patch that gog ships
[22:30] <snover> wjp: four days sounds long enough to rewrite all the midi code, dont you think? ;)
[22:32] <TMM> snover, no, that call wasn't patched
[22:32] <snover> so what object is 17:36?
[22:32] <TMM> http://paste.debian.net/944034/
[22:33] <TMM> I don't know, trying to figure out how to get into the debugger
[22:33] <snover> if the game crashes, you are already in the debugger
[22:33] <TMM> oh, right, space
[22:34] <TMM> You know when I said I should go to bed? I should've gone to bed
[22:34] <snover> forever alone
[22:35] <TMM> oh, fantastic
[22:35] <TMM> it doesn't happen anymore now
[22:35] --> Strangerke_ joined #scummvm.
[22:35] <snover> maybe delete any files in your scummvm savegames directory
[22:35] <snover> that are prefix from phant2
[22:37] <TMM> nope...
[22:37] <TMM> the prefix here is phantasmagoria2-win.001
[22:37] <TMM> at least that was how the game was detected
[22:38] <-- Strangerke left irc: Ping timeout: 240 seconds
[22:38] Nick change: Strangerke_ -> Strangerke
[22:38] <TMM> how can this only happen once
[22:39] <snover> magic
[22:39] <snover> (fwiw there were some patches that came with the original us release, so those may be no new patches at all)
[22:39] <TMM> don't like it
[22:40] <snover> i dont see any kFileIO calls in my p2::init disassembly
[22:40] <TMM> no, the only one is in IntensityPassWordWindow::new:
[22:40] <TMM> but it's in the same scriptfile
[22:41] <snover> oh ok
[22:41] <snover> i see it now
[22:41] <TMM> the backtrace at the time didn't show that though
[22:42] <TMM> so I don't know if that is actually the call in question
[22:42] <TMM> it sure seems to call readfile with a string object
[22:42] <TMM> err readString
[22:42] <TMM> oh, no, it just makes one
[22:43] <TMM> uch, seriously sleeptime now :) I'm glad that I found another hisenbug next to my previous hisenbug of lsl7 not being detected 0_0
[22:45] <m_kiewitz> snover / wjp: is that slope issue also in qfg4 floppy?
[22:45] <snover> m_kiewitz: i dont know. i managed to never trigger it when i played the game in scummvm
[22:47] <-- ny00123 left irc: Quit: Leaving
[22:47] <m_kiewitz> let's try the localized qfg4 floppy...
[22:49] <m_kiewitz> hmmm it looks vulnerable scriptwise
[22:53] <m_kiewitz> can't make it crash :/
[22:53] <t0by> OOH
[22:55] <t0by> _sev, Simei: the segfaults are a result of animation variables (SVT_ANIM or SVT_COSTUME) that have pointers to uninitialized memory. Those locations are passed as "&loadHere" to loadSpriteBank which ordinarily *should* initialize them, *but* it's #ifdef'd out, so those point to god knows what.
[22:55] <m_kiewitz> snover / wjp: what do you think about game breaking bugs like the day 5 bug (With this bug, you must visit the Domovoi before Day 5. )
[22:55] <t0by> it looks like a super hairy beast as well on a first glance.
[22:56] <m_kiewitz> is that something we should fix? (if it's even possible to fix and make that NPC not leave)
[22:56] <t0by> So
[22:56] <snover> m_kiewitz: well, if it is truly a bug, then i would like it not to exist
[22:56] <t0by> Simei: continue with your work then, we'll see about this one later.
[22:56] <m_kiewitz> it depends on how you view it. The game designers intentionally made that NPC leave, but I doubt they wanted to make it game breaking
[22:57] <m_kiewitz> or is anything else game breaking in qfg4?
[22:57] <m_kiewitz> for earlier sierra games that's a different matter
[22:57] <snover> i stopped playing after the antwerp puzzle because the game started being nonlinear and i didnt have patience to wait for in-game time to pass
[22:58] <m_kiewitz> isn't there a wait action?
[22:58] <snover> iirc you can only use it so much
[22:59] <m_kiewitz> but yeah it looks as if the game designers just didn't see that NPC leaving would have serious consequences and make it so you can't beat the game anymore
[22:59] <snover> i cant remember if the game stops you or if you just run out of energy and die
[22:59] <m_kiewitz> ah, i never played qfg4. played qfg1 tons of times though
[23:00] <-- ajax16384 left irc: Read error: Connection reset by peer
[23:01] <t0by> Simei: you still up?
[23:01] <m_kiewitz> snover: any idea what error 48 is for sci32 internally?
[23:02] <m_kiewitz> https://www.gog.com/forum/quest_for_glory_series/quest_for_glory_4_error_48
[23:02] <t0by> snover: that's the very question I ask about my life every so often
[23:02] <snover> t0by: nice. 👍
[23:02] <m_kiewitz> ahhh tons of qfg4 bugs that were never patched with descriptions to trigger them
[23:02] <m_kiewitz> http://www.the-spoiler.com/RPG/Sierra/glory.quest.4.2.html
[23:03] <snover> m_kiewitz: bad selector
[23:04] <m_kiewitz> really weird
[23:04] <snover> nice find on that bug list
[23:05] <t0by> Good night, people
[23:07] <t0by> _sev, Simei: tomorrow I won't be around until lunchtime.
[23:08] <m_kiewitz> snover: ha, found another one about error 49
[23:08] <m_kiewitz> http://www.agdinteractive.com/forum/viewtopic.php?f=19&t=9789
[23:08] <t0by> Simei: if you don't hear from anybody, continue your work with replacing stdio with common/file (if necessary ask people in here for help).
[23:08] <m_kiewitz> you know what that one is too?
[23:08] <m_kiewitz> TMM: you want things to fix? I got lots and lots of qfg4 bugs for you :P
[23:08] <m_kiewitz> get your hands on qfg4 floppy and you will be busy for the next 4 months
[23:08] <t0by> Simei, _sev: I suppose the next step in order to display something will be to digest and refactor loadSpriteBank from sprites.cpp.
[23:08] <t0by> Looks pretty scary.
[23:09] <t0by> Nite!
[23:11] <-- t0by left irc: Quit: t0by
[23:14] <m_kiewitz> ah nvm, error 49 is division by zero
[23:23] <-- WooShell left irc: Quit: If you understand or if you don't, if you believe or if you doubt - There's a universal justice, and the eyes of truth are always watching you.
[23:24] --> Littleboy joined #scummvm.
[23:24] #scummvm: mode change '+o Littleboy' by ChanServ!ChanServ@services.
[23:38] <-- m_kiewitz left irc: Quit: technology isn't intrinsically good or evil. It's how it's used. Like the Death Ray.
[23:39] <-- waltervn left irc: Quit: Leaving
[00:00] --- Sat May 27 2017