January 31, 2017 
< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | >
January 31, 2017 [00:00:49] *** TMM <TMM!~hp@fsf/member/pdpc.professional.tmm> has quit IRC (Ping timeout: 260 seconds)[00:02:41] *** TMM <TMM!~hp@fsf/member/pdpc.professional.tmm> has joined #scummvm[00:02:41] *** ChanServ sets mode: +o TMM[00:04:35] *** TMM <TMM!~hp@fsf/member/pdpc.professional.tmm> has quit IRC (Client Quit)[00:09:33] *** GitHub80 <GitHub80!~GitHub80@192.30.252.40> has joined #scummvm[00:09:33] <GitHub80> [scummvm-tools] criezy pushed 1 new commit to master: https://git.io/vDIoT[00:09:33] <GitHub80> scummvm-tools/master ee13a91 Thierry Crozat: TOOLS: Update README file for extract_cine and extract_cruise_pc tools[00:09:33] *** GitHub80 <GitHub80!~GitHub80@192.30.252.40> has left #scummvm[00:14:15] <criezy> Am I the only one who can access the forum and wiki right now?[00:15:06] <criezy> Hmm, I can't access hosteurope.de either. Maybe an issue on their side.[00:18:50] <snover> wiki works for me[00:19:00] <snover> sounds like a routing problem, or they fixed it already[00:19:24] <criezy> Indeed. It works now.[00:23:38] *** girafe <girafe!~girafe@LFbn-1-11729-221.w2-7.abo.wanadoo.fr> has quit IRC (Read error: Connection reset by peer)[00:26:26] *** waltervn <waltervn!~waltervn@541B2DBA.cm-5-4a.dynamic.ziggo.nl> has quit IRC (Quit: Leaving)[00:30:40] *** Farmboy0 <Farmboy0!~quassel@xoreos/farmboy0> has quit IRC (Remote host closed the connection)[00:32:12] <snover> ugh. so i don’t know if these scripts that manage screen items that persist across game loads need to be pinned to specific segments or what the right solution is[00:33:02] <snover> when sq6 script 32 isn’t always allocated to the same segment, things explode[00:36:21] *** bgK <bgK!~bgk@2001:41d0:2:599c::2a60:8434> has quit IRC (Ping timeout: 255 seconds)[00:38:00] <snover> (it controls the control panel)[00:38:42] *** bgK <bgK!~bgk@2001:41d0:2:599c::2a60:8434> has joined #scummvm[00:38:42] *** ChanServ sets mode: +o bgK[01:00:10] *** WooShell <WooShell!~Markus@ipbcc071f7.dynamic.kabel-deutschland.de> has quit IRC (Quit: Walking upside down in the sky, between the satellites passing by. Gliding along the black rainbow, I fly away with my shadow. Scratching the moon like a DJ, the night follows its odyssey.)[01:12:27] *** dreammaster <dreammaster!~dreammast@c-73-167-118-204.hsd1.ma.comcast.net> has joined #scummvm[01:12:27] *** ChanServ sets mode: +o dreammaster[01:12:30] *** sQUALE_ <sQUALE_!~squale@80.12.55.69> has joined #scummvm[01:18:11] *** Guest30711 <Guest30711!~tompsson@h-236-221.a199.priv.bahnhof.se> has quit IRC (Ping timeout: 245 seconds)[01:35:16] *** Tomaz^ <Tomaz^!~tompsson@h-236-221.a199.priv.bahnhof.se> has joined #scummvm[01:40:17] *** sQUALE_ <sQUALE_!~squale@80.12.55.69> has quit IRC (Remote host closed the connection)[01:51:42] *** m_kiewitz <m_kiewitz!~m_kiewitz@scummvm/undead/m-kiewitz> has quit IRC (Quit: technology isn't intrinsically good or evil. It's how it's used. Like the Death Ray.)[02:30:28] *** WinterGrascph <WinterGrascph!~WinterGra@winter.sch.bme.hu> has joined #scummvm[02:30:28] *** ChanServ sets mode: +o WinterGrascph[03:20:35] *** Dominus <Dominus!~dominus@unaffiliated/dominus> has quit IRC (Ping timeout: 240 seconds)[03:21:26] *** Dominus <Dominus!~dominus@88-117-73-254.adsl.highway.telekom.at> has joined #scummvm[03:21:26] *** Dominus <Dominus!~dominus@88-117-73-254.adsl.highway.telekom.at> has quit IRC (Changing host)[03:21:26] *** Dominus <Dominus!~dominus@unaffiliated/dominus> has joined #scummvm[03:45:23] *** Vampire0_ <Vampire0_!~Vampire@jEdit/Vampire> has joined #scummvm[03:48:35] *** Vampire0 <Vampire0!~Vampire@jEdit/Vampire> has quit IRC (Ping timeout: 240 seconds)[03:49:20] *** dreammaster <dreammaster!~dreammast@c-73-167-118-204.hsd1.ma.comcast.net> has quit IRC ()[04:14:59] *** WinterGrascph <WinterGrascph!~WinterGra@winter.sch.bme.hu> has quit IRC (Ping timeout: 276 seconds)[04:18:09] *** dreammaster <dreammaster!~dreammast@c-73-167-118-204.hsd1.ma.comcast.net> has joined #scummvm[04:18:09] *** ChanServ sets mode: +o dreammaster[04:18:58] *** GitHub143 <GitHub143!~GitHub143@192.30.252.45> has joined #scummvm[04:18:58] <GitHub143> [scummvm] dreammaster pushed 1 new commit to master: https://git.io/vDIxk[04:18:58] <GitHub143> scummvm/master 02ebaf0 Paul Gilbert: TITANIC: Implementing music room handler update & trigger[04:18:58] *** GitHub143 <GitHub143!~GitHub143@192.30.252.45> has left #scummvm[04:22:34] *** dreammaster <dreammaster!~dreammast@c-73-167-118-204.hsd1.ma.comcast.net> has quit IRC (Client Quit)[04:37:32] *** Littleboy <Littleboy!~littleboy@c-73-218-19-43.hsd1.ma.comcast.net> has quit IRC (Read error: Connection reset by peer)[05:41:08] *** Strangerke_ <Strangerke_!~Strangerk@cable-85.28.84.13.coditel.net> has joined #scummvm[05:43:10] *** Strangerke <Strangerke!~Strangerk@cable-85.28.84.13.coditel.net> has quit IRC (Ping timeout: 240 seconds)[05:43:10] *** Strangerke_ is now known as Strangerke[08:15:00] *** Axy <Axy!~Mia@88.224.209.225> has joined #scummvm[08:15:00] *** Axy <Axy!~Mia@88.224.209.225> has quit IRC (Changing host)[08:15:00] *** Axy <Axy!~Mia@unaffiliated/mia> has joined #scummvm[08:18:22] *** Mia <Mia!~Mia@unaffiliated/mia> has quit IRC (Ping timeout: 264 seconds)[08:19:34] *** Strangerke <Strangerke!~Strangerk@cable-85.28.84.13.coditel.net> has quit IRC (Ping timeout: 264 seconds)[08:20:34] *** Axy <Axy!~Mia@unaffiliated/mia> has quit IRC (Ping timeout: 248 seconds)[08:27:38] *** Mia <Mia!~Mia@85.110.62.112> has joined #scummvm[08:27:38] *** Mia <Mia!~Mia@85.110.62.112> has quit IRC (Changing host)[08:27:38] *** Mia <Mia!~Mia@unaffiliated/mia> has joined #scummvm[08:32:40] *** Mia <Mia!~Mia@unaffiliated/mia> has quit IRC (Ping timeout: 240 seconds)[08:36:19] *** Mia <Mia!~Mia@78.167.72.188> has joined #scummvm[08:36:19] *** Mia <Mia!~Mia@78.167.72.188> has quit IRC (Changing host)[08:36:19] *** Mia <Mia!~Mia@unaffiliated/mia> has joined #scummvm[09:11:45] *** Lightkey <Lightkey!~Darklock@p200300764C2EBF7122CF30FFFE083718.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 240 seconds)[09:18:40] *** _sev|work_ <_sev|work_!~sev@scummvm/undead/sev> has joined #scummvm[09:18:40] *** ChanServ sets mode: +o _sev|work_[09:18:49] *** _sev|work_ <_sev|work_!~sev@scummvm/undead/sev> has quit IRC (Remote host closed the connection)[09:24:50] *** Lightkey <Lightkey!~Darklock@p200300764C2EBF0522CF30FFFE083718.dip0.t-ipconnect.de> has joined #scummvm[09:30:16] *** m_kiewitz <m_kiewitz!~m_kiewitz@x4d03ca8c.dyn.telefonica.de> has joined #scummvm[09:30:16] *** m_kiewitz <m_kiewitz!~m_kiewitz@x4d03ca8c.dyn.telefonica.de> has quit IRC (Changing host)[09:30:16] *** m_kiewitz <m_kiewitz!~m_kiewitz@scummvm/undead/m-kiewitz> has joined #scummvm[09:30:17] *** ChanServ sets mode: +o m_kiewitz[09:44:25] *** waltervn <waltervn!~waltervn@541B2DBA.cm-5-4a.dynamic.ziggo.nl> has joined #scummvm[09:44:25] *** ChanServ sets mode: +o waltervn[09:45:29] *** Mia <Mia!~Mia@unaffiliated/mia> has quit IRC (Read error: Connection reset by peer)[09:46:37] *** LittleToonCat <LittleToonCat!~littlecat@sydnns0115w-047054148237.dhcp-dynamic.FibreOP.ns.bellaliant.net> has quit IRC (Remote host closed the connection)[09:47:23] *** Mia <Mia!~Mia@unaffiliated/mia> has joined #scummvm[09:54:28] *** ajax16384 <ajax16384!~User@109.60.138.138> has joined #scummvm[09:54:28] *** ChanServ sets mode: +o ajax16384[10:11:56] *** GitHub162 <GitHub162!~GitHub162@192.30.252.42> has joined #scummvm[10:11:56] <GitHub162> [scummvm] waltervn pushed 1 new commit to master: https://git.io/vDLnb[10:11:56] <GitHub162> scummvm/master 2a74a97 Walter van Niftrik: ADL: Allow stray data bytes in pics...[10:11:56] *** GitHub162 <GitHub162!~GitHub162@192.30.252.42> has left #scummvm[10:14:36] <waltervn> I've been going through a hires5 walkthrough, but it's slow going... keep finding issues[10:17:27] <waltervn> and I wonder how many of the 1200+ rooms this walkthrough covers...[10:18:16] *** _sev|work <_sev|work!~sev@5.57.20.49> has joined #scummvm[10:18:16] *** _sev|work <_sev|work!~sev@5.57.20.49> has quit IRC (Changing host)[10:18:16] *** _sev|work <_sev|work!~sev@scummvm/undead/sev> has joined #scummvm[10:18:16] *** ChanServ sets mode: +o _sev|work[10:38:00] *** criezy <criezy!~criezy@host86-175-214-121.range86-175.btcentralplus.com> has quit IRC (Quit: criezy)[10:45:31] <m_kiewitz> waltervn: 1200+ rooms? o_O[10:46:13] <waltervn> yes, a lot of them are empty, and there's some mazes I think, but still...[10:47:51] <waltervn> hires5 is probably about the same size as all the other hires games combined[10:48:52] <m_kiewitz> wow[10:50:58] *** user10 <user10!~Thunderbi@leoseb.ujf-grenoble.fr> has joined #scummvm[10:52:05] *** user9 <user9!~Thunderbi@leoseb.ujf-grenoble.fr> has quit IRC (Ping timeout: 240 seconds)[10:52:05] *** user10 is now known as user9[11:05:03] *** Strangerke|work <Strangerke|work!5bb7582b@gateway/web/freenode/ip.91.183.88.43> has joined #scummvm[11:05:07] <Strangerke|work> hi guys[11:37:50] *** TMM <TMM!~hp@fsf/member/pdpc.professional.tmm> has joined #scummvm[11:37:50] *** ChanServ sets mode: +o TMM[11:40:06] *** WinterGrascph <WinterGrascph!~WinterGra@winter.sch.bme.hu> has joined #scummvm[11:40:06] *** ChanServ sets mode: +o WinterGrascph[12:49:26] *** D0SFreak <D0SFreak!~D0SFreak@172.56.4.16> has joined #scummvm[13:40:12] *** marcus_c_ <marcus_c_!~marcus@bahamut-int.mc.pp.se> has quit IRC (Ping timeout: 258 seconds)[13:43:08] *** marcus_c <marcus_c!~marcus@bahamut-int.mc.pp.se> has joined #scummvm[14:22:20] *** waltervn <waltervn!~waltervn@541B2DBA.cm-5-4a.dynamic.ziggo.nl> has quit IRC (Ping timeout: 252 seconds)[15:33:58] *** Axy <Axy!~Mia@unaffiliated/mia> has joined #scummvm[15:36:10] *** Mia <Mia!~Mia@unaffiliated/mia> has quit IRC (Ping timeout: 240 seconds)[15:41:57] *** user9 <user9!~Thunderbi@leoseb.ujf-grenoble.fr> has quit IRC (Quit: user9)[15:42:22] *** user9 <user9!~Thunderbi@leoseb.ujf-grenoble.fr> has joined #scummvm[16:09:35] *** WinterGrascph <WinterGrascph!~WinterGra@winter.sch.bme.hu> has quit IRC (Ping timeout: 252 seconds)[17:06:42] *** WooShell <WooShell!~Markus@ipbcc071f7.dynamic.kabel-deutschland.de> has joined #scummvm[17:07:16] <WooShell> meow =^.^=[17:33:54] *** ajax16384 <ajax16384!~User@109.60.138.138> has quit IRC (Read error: Connection reset by peer)[17:46:12] *** ny00123 <ny00123!~ny00123@89-139-172-204.bb.netvision.net.il> has joined #scummvm[17:50:48] *** ST1 <ST1!~ScottT@203-227-181-180.cpe.skymesh.net.au> has joined #scummvm[17:50:48] *** ST <ST!~ScottT@203-227-181-180.cpe.skymesh.net.au> has quit IRC (Disconnected by services)[18:10:05] *** Strangerke <Strangerke!~Strangerk@cable-85.28.84.13.coditel.net> has joined #scummvm[18:10:40] *** girafe <girafe!~girafe@LFbn-1-11729-221.w2-7.abo.wanadoo.fr> has joined #scummvm[18:10:40] *** _sev|work <_sev|work!~sev@scummvm/undead/sev> has quit IRC (Quit: This computer has gone to sleep)[18:17:29] *** GitHub20 <GitHub20!~GitHub20@192.30.252.41> has joined #scummvm[18:17:29] <GitHub20> [scummvm] Strangerke pushed 1 new commit to master: https://git.io/vDtEJ[18:17:29] <GitHub20> scummvm/master f4472d2 Strangerke: DM: Fix GCC warnings[18:17:29] *** GitHub20 <GitHub20!~GitHub20@192.30.252.41> has left #scummvm[18:17:45] *** GitHub183 <GitHub183!~GitHub183@192.30.252.40> has joined #scummvm[18:17:45] <GitHub183> [scummvm] criezy pushed 1 new commit to master: https://git.io/vDtET[18:17:45] <GitHub183> scummvm/master afb6941 Thierry Crozat: I18N: Update translations templates[18:17:45] *** GitHub183 <GitHub183!~GitHub183@192.30.252.40> has left #scummvm[18:25:35] <Strangerke> seennick criezy[18:25:35] <LeChuck> criezy (~criezy at host86-175-214-121 dot range86-175.btcentralplus.com) was last seen quitting from #scummvm 7 hours, 47 minutes ago stating (Quit: criezy).[18:30:08] *** _sev|work <_sev|work!~sev@scummvm/undead/sev> has joined #scummvm[18:30:08] *** ChanServ sets mode: +o _sev|work[18:37:37] *** Mia <Mia!~Mia@unaffiliated/mia> has joined #scummvm[18:39:26] *** Axy <Axy!~Mia@unaffiliated/mia> has quit IRC (Ping timeout: 240 seconds)[18:41:33] *** LittleToonCat <LittleToonCat!~littlecat@sydnns0115w-047054148237.dhcp-dynamic.FibreOP.ns.bellaliant.net> has joined #scummvm[18:51:26] *** omer_mor_ <omer_mor_!~Omer@46-117-132-33.bb.netvision.net.il> has quit IRC (Ping timeout: 256 seconds)[19:04:39] *** _sev|work <_sev|work!~sev@scummvm/undead/sev> has quit IRC (Quit: This computer has gone to sleep)[19:07:15] <snover> wjp: when you have some time, i would really appreciate some brainstorming help on what to do with these objects that persist across save game loads[19:13:14] *** _sev|work <_sev|work!~sev@a238130.upc-a.chello.nl> has joined #scummvm[19:13:14] *** _sev|work <_sev|work!~sev@a238130.upc-a.chello.nl> has quit IRC (Changing host)[19:13:14] *** _sev|work <_sev|work!~sev@scummvm/undead/sev> has joined #scummvm[19:13:14] *** ChanServ sets mode: +o _sev|work[19:13:43] *** GitHub41 <GitHub41!~GitHub41@192.30.252.41> has joined #scummvm[19:13:43] <GitHub41> [scummvm] sev- pushed 4 new commits to master: https://git.io/vDtoB[19:13:43] <GitHub41> scummvm/master 95be2f2 Eugene Sandulenko: GRAPHICS: Overwhauling of MacText rich formatting[19:13:43] <GitHub41> scummvm/master c4f7301 Eugene Sandulenko: DIRECTOR: Generate font style runs for MacText[19:13:43] <GitHub41> scummvm/master 89e8bdc Eugene Sandulenko: GRAPHICS: More fixes to MacText rich text formatting[19:13:43] *** GitHub41 <GitHub41!~GitHub41@192.30.252.41> has left #scummvm[19:17:55] *** _sev|work <_sev|work!~sev@scummvm/undead/sev> has quit IRC (Client Quit)[19:23:19] *** CTCT <CTCT!~kvirc@109.144.210.85> has joined #scummvm[19:25:26] *** CTCT|2 <CTCT|2!~kvirc@109.144.210.85> has joined #scummvm[19:25:31] <CTCT|2> Okay, I timed out.[19:25:59] <CTCT|2> What can I do if a game can't be found? Most likely it is a customised version of another (supported) engine.[19:26:04] *** waltervn <waltervn!~waltervn@541B2DBA.cm-5-4a.dynamic.ziggo.nl> has joined #scummvm[19:26:04] *** ChanServ sets mode: +o waltervn[19:26:23] <waltervn> evening[19:26:32] <CTCT|2> Evening. :)[19:27:28] *** CTCT <CTCT!~kvirc@109.144.210.85> has quit IRC (Ping timeout: 240 seconds)[19:27:51] *** CTCT|2 is now known as CTCT[19:28:40] <CTCT> So, uh, it detects the resources, but can't read them.[19:30:07] <CTCT> waltervn: I don't know who to give this to here, so uh... http://pastebin.com/raw/qNAAEjbR[19:30:22] *** Axy <Axy!~Mia@unaffiliated/mia> has joined #scummvm[19:32:01] *** Mia <Mia!~Mia@unaffiliated/mia> has quit IRC (Ping timeout: 248 seconds)[19:33:07] <snover> CTCT: INN is not a supported product[19:34:57] <snover> waltervn: i don’t know if you read the backlog and/or whether what i said before was even coherent, but i would be interested in your thoughts too, if you have any, about how to deal with objects in sci32 that need to persist across save game loads[19:35:36] <CTCT> I've never been here before.[19:35:54] <CTCT> Will INN be a supported product? It's simply a slightly different coded version of SCI.[19:37:09] <snover> CTCT: omer_mor has looked at INN in the past, so he would be the most authoritative person to talk to[19:37:51] <CTCT> Funnily enough, I know Omer. :P[19:40:06] <snover> like in SQ6, the control panel script is initialised in SQ6::init, which runs only once, and then that control panel is expected to persist for the lifetime of the game. at the moment i am thinking maybe it is possible to deal with this by checking for existing scripts in the _scriptSegMap and then making sure the correct segment gets reused[19:40:21] <m_kiewitz> snover: why is the control panel not saved?[19:40:59] <m_kiewitz> i doubt you can recreate those references as stable ones[19:41:15] <m_kiewitz> with the original interpreter that worked somewhat, because it's built completely differently[19:41:29] <snover> m_kiewitz: well, it is that thing you noted, “Attention: at least Space Quest 6's option plane seems to stay in memory right from the start and is not re-created.”[19:41:50] <m_kiewitz> ah wait, that's planes[19:42:02] <m_kiewitz> so that's SCI32 plane objects only[19:42:07] <m_kiewitz> not inside script space[19:42:41] <m_kiewitz> so there are references to those inside script space, and when the references change they don't work anymore obviously[19:42:49] <snover> yes, that’s right.[19:43:04] <snover> it is a problem for both planes and screen items[19:43:17] <m_kiewitz> that's quite a big problem. I guess we could probably save them, but this could and probably would create issues because the scripts surely recreate some of them[19:43:55] <m_kiewitz> it's sorta works like that in sci16 as well, but in sci16 sierra never did something like that, because it was literally impossible[19:44:18] *** GitHub65 <GitHub65!~GitHub65@192.30.252.42> has joined #scummvm[19:44:18] <GitHub65> [scummvm] waltervn pushed 1 new commit to master: https://git.io/vDtX1[19:44:18] <GitHub65> scummvm/master a113b1c Walter van Niftrik: ADL: Fix saving inside first-visited rooms[19:44:18] *** GitHub65 <GitHub65!~GitHub65@192.30.252.42> has left #scummvm[19:44:40] <m_kiewitz> do i recreate those objects after restore?[19:44:58] <m_kiewitz> sierra did the same, however the VM of our SCI works completely different[19:45:14] <m_kiewitz> so I'm not surprised that existing references do not work anymore in some cases[19:45:56] <m_kiewitz> hmm we could for example also mark those planes/screen items, that were created for the first few cycles as something special[19:45:59] <m_kiewitz> and save them in such a case[19:46:06] <m_kiewitz> not sure if that could work out[19:46:18] *** frankyboy_ <frankyboy_!~franky@ppp91-78-193-193.pppoe.mtu-net.ru> has joined #scummvm[19:46:29] <m_kiewitz> i guess it's also a larger engine design fault in general[19:46:45] <m_kiewitz> for example in case anything got modified for those screen items, old saved games wouldn't work as well[19:46:54] <m_kiewitz> (script patching wise I mean)[19:48:07] <snover> “do i recreate those objects after restore??” —at the moment, i’ve removed that planes iteration code that was pulled out of the game scripts, so the system is back to only using the game scripts’ own code for it[19:48:34] <m_kiewitz> but i guess it still doesn't work properly[19:48:59] <snover> it works ok as long as everything is created in exactly the same order so the segment and offsets are the same[19:49:21] <m_kiewitz> well obviously, but as i said - it's a bigger engine design fault[19:49:22] <CTCT> One thing that would be needed to support INN would be a section in the Settings of ScummVM for COM Ports.[19:49:41] <snover> i managed to finally trigger and get to the root problem when i started preloading the SRDialog script, since that modified the script->segment id map[19:49:56] <snover> i agree it is a design fault[19:50:11] <m_kiewitz> we could really try to mark those items and then save them + restore them[19:50:23] <m_kiewitz> that however would create a problem with the current original scripts of course[19:50:29] <m_kiewitz> because those would try to recreate them as well[19:50:49] <m_kiewitz> ah, well[19:50:57] <m_kiewitz> we could also mark them and then just save their references[19:51:12] <m_kiewitz> and when we restore, we could use that data and fix up all references in script space to the new references[19:52:00] <m_kiewitz> i mean we would have to obviously save a bit of their data too, so that we are able to match them[19:52:02] <CTCT> Could ScummVM support COM Ports, might be a good idea for other games too.[19:52:04] *** frankyboy_ <frankyboy_!~franky@ppp91-78-193-193.pppoe.mtu-net.ru> has quit IRC (Read error: Connection reset by peer)[19:52:04] <snover> yeah, that might work. i am a little fuzzy today[19:52:28] *** frankyboy_ <frankyboy_!~franky@ppp91-78-193-193.pppoe.mtu-net.ru> has joined #scummvm[19:52:28] <snover> CTCT: i’d recommend to talk to omer when he is around[19:52:44] <m_kiewitz> still the other question is how to hook save/restore in a better way for sci32 then[19:53:08] *** criezy <criezy!~criezy@host86-175-214-121.range86-175.btcentralplus.com> has joined #scummvm[19:53:08] *** ChanServ sets mode: +o criezy[19:53:19] <snover> aside from this persistence issue, the SRDialog hook seems to be working well[19:53:28] <m_kiewitz> but not for all games?[19:53:43] <m_kiewitz> or would it cover all games?[19:53:56] <m_kiewitz> except for games that save automatically obviously[19:54:02] <m_kiewitz> like mother goose[19:54:07] <snover> it covers all the games that use SRDialog, which is the same as before, since the other ones were just being excluded from scummvm save/load by game ID[19:54:27] <snover> the other ones = the ones that didn’t use SRDialog[19:54:58] <snover> i’m sorry, i am rambling and incoherent the last few days :)[19:55:18] <m_kiewitz> no problem, i understood the original anyway[19:55:32] <snover> https://github.com/scummvm/scummvm/blob/master/engines/sci/sci.cpp#L596-L607 this list[19:56:17] <m_kiewitz> PQ:SWAT saves automatically?[19:56:33] <snover> no, but it has a stupid custom save system[19:56:36] <m_kiewitz> lol[19:56:48] <m_kiewitz> oh well, the game is horrible anyway[19:56:59] <snover> because obviously, you would want to have multiple different characters each with their own sets of save games[19:57:06] <m_kiewitz> kq7 uses the name afaik[19:57:06] *** frankyboy_ <frankyboy_!~franky@ppp91-78-193-193.pppoe.mtu-net.ru> has quit IRC (Read error: Connection reset by peer)[19:57:13] <m_kiewitz> shivers too afaik[19:57:19] <snover> the name?[19:57:28] <m_kiewitz> the name the player entered[19:57:28] *** frankyboy_ <frankyboy_!~franky@ppp91-78-193-193.pppoe.mtu-net.ru> has joined #scummvm[19:57:34] <snover> ah, yes.[19:57:36] <m_kiewitz> somewhat similar to mother goose[19:58:13] <m_kiewitz> hmmm question is how to identify the screen items/planes to save[19:58:35] <wjp> hrm, so games expect some part of the state not be affected by saving/loading at all?[19:59:00] <snover> wjp: yeah.[19:59:06] <m_kiewitz> wjp: i think games try to recreate planes + screen objects[19:59:18] <m_kiewitz> but then expect those to get the same references as they had before[19:59:31] *** frankyboy_ <frankyboy_!~franky@ppp91-78-193-193.pppoe.mtu-net.ru> has quit IRC (Client Quit)[19:59:45] <m_kiewitz> i mean it seems they save the reference of for example the original option menu plane and save it somewhere[20:00:01] <m_kiewitz> then recreate it, but don't change that reference, but simply expect it to be the same as before[20:00:09] <m_kiewitz> and in our SCI that doesn't need to be the case[20:00:16] <m_kiewitz> and when it isn't, it crashes later obviously[20:01:11] <snover> in SQ6, SQ6::init runs, calls to SQ6Controls::init, SQ6Controls::init saves a reference to itself at global 63, and this thing is never touched during the entire game[20:01:33] <m_kiewitz> i wonder if it would be fine to just save all references of all plane + screen items including view celnumber and position[20:01:59] <m_kiewitz> and then match those when plane + screen items are recreated during the restore method[20:02:05] <wjp> snover: and "the entire game" means from starting the .exe to exiting to dos?[20:02:21] <snover> wjp: yep[20:02:42] *** TMM <TMM!~hp@fsf/member/pdpc.professional.tmm> has quit IRC (Quit: Ex-Chat)[20:02:51] <m_kiewitz> interesting, but i wouldn't want to modify globals in some hardcoded way. and you never know if they save a reference somewhere else[20:03:22] <m_kiewitz> wjp: it gets even more complicated at least back then when i wrote that replacement code for the script code[20:03:33] <m_kiewitz> some stuff is created, but isn't recreated during restore[20:03:41] <snover> what i don’t know is how the interpreter serialised all the VM state[20:03:56] <m_kiewitz> it didn't, afaik[20:04:03] <m_kiewitz> in sci16 ports were not saved either[20:04:15] <snover> i mean the globals, i would expect those to get saved[20:04:15] <m_kiewitz> ports were in a way planes[20:04:20] <m_kiewitz> yes, those are saved[20:04:49] <m_kiewitz> but they are simply saved directly, so when the game stores references somewhere to such things then they may go bad[20:05:41] <m_kiewitz> such things as in ports, screen items, planes etc.[20:05:51] <m_kiewitz> they simply shouldn't do that[20:06:02] <snover> i guess that means that the original game also relied on memory handles being used in the same order[20:06:07] <m_kiewitz> yes[20:06:12] <m_kiewitz> and that worked for sci16 too[20:06:29] <m_kiewitz> i think a few games also had bugs, so we had to reuse the same port ids[20:06:36] <m_kiewitz> otherwise games could error out in some cases[20:06:47] <m_kiewitz> and there were also other bugs like games freeing a port[20:06:49] <snover> so i guess that means that only the segmentid needs to be worried about, since the order of the objects in that segment will be consistent[20:06:53] <m_kiewitz> and then accessing it immediately afterwards[20:07:01] <m_kiewitz> which worked in DOS obviously, but didn't in our V[20:07:02] <m_kiewitz> VM[20:07:17] <m_kiewitz> doesn't need to be consistent[20:07:19] <CTCT> Back.[20:07:36] <m_kiewitz> i mean we can't really guarantee that it's going to be consistent[20:07:53] <CTCT> snover: Well, that specifically, isn't an INN question, it's a question regarding the capabilities of ScummVM itself.[20:08:04] <m_kiewitz> do the segment ids change in your cases only and the offsets stay the same?[20:08:25] <snover> yeah[20:08:42] <snover> offsets are consistent here[20:09:13] <m_kiewitz> if we fix it, we should better fix it fully[20:09:27] <m_kiewitz> and you can't be sure that offsets will always stay the same[20:10:32] <m_kiewitz> hmmm, can you check if duplicates are getting recreated or if just unique screen items / planes are recreated?[20:12:42] <snover> i’m pretty sure that nothing is recreated, as the only place this code is invoked is by SQ6::init[20:13:14] <snover> i need to run for a while, i will be back in about 1.5 hours[20:13:17] <m_kiewitz> ah wait was the code I wrote back then based on script code recreating the other planes + screen objects only?[20:13:51] <m_kiewitz> i think that was it[20:15:04] <m_kiewitz> if i remember correctly, the original script code deletes all non-persistent screen objects/planes[20:15:10] <m_kiewitz> and then recreates those[20:15:16] <m_kiewitz> it doesn't touch the persistent ones[20:15:38] <m_kiewitz> i think it checked some flag for that[20:16:06] <m_kiewitz> so we could save references to the persistent ones and match those to the current ones and adjust VM data accordingly[20:16:49] <m_kiewitz> we could in theory also walk through the VM data and then actually create the persistent ones, but we would then still have to adjust the VM data[20:17:02] <m_kiewitz> or well, in case persistent flag is set right at the start[20:17:23] <m_kiewitz> we could also just put persistent ones inside a special segment[20:17:40] <m_kiewitz> and then recreate those when restoring based on VM script data[20:17:53] <m_kiewitz> that way, we wouldn't have to adjust the VM data anymore[20:19:21] <m_kiewitz> snover: just say something when you are back[20:19:49] *** omer_mor <omer_mor!~Omer@46-117-132-33.bb.netvision.net.il> has joined #scummvm[20:28:22] <CTCT> omer_mor: INN in ScummVM, what needs to be done?[20:32:49] *** omer_mor <omer_mor!~Omer@46-117-132-33.bb.netvision.net.il> has quit IRC (Ping timeout: 248 seconds)[20:46:37] *** omer_mor <omer_mor!~Omer@46-117-132-33.bb.netvision.net.il> has joined #scummvm[20:48:07] <omer_mor> CTCT: INN uses a variant SCI engine called LSCI[20:48:24] <omer_mor> it's pretty similar, but with added network support[20:49:08] *** D0SFreak <D0SFreak!~D0SFreak@172.56.4.16> has quit IRC (Ping timeout: 240 seconds)[20:49:09] <omer_mor> also, INN is spawning different processes for different games[20:50:13] <omer_mor> not all of them are (L)SCI, e.g. Red Baron (flight simulator), Shadows of Yserbius (RPG) and more[20:52:54] *** CTCT|2 <CTCT|2!~kvirc@109.144.210.85> has joined #scummvm[20:53:21] <CTCT|2> It seems like the files are encoded differently too.[20:53:32] <CTCT|2> Compared to SCI.[20:54:04] <omer_mor> They are? I have no idea.[20:55:21] *** CTCT <CTCT!~kvirc@109.144.210.85> has quit IRC (Ping timeout: 255 seconds)[20:58:27] <omer_mor> CTCT = CTxCB = Christopher?[20:58:36] <CTCT|2> Probably.[20:58:46] <CTCT|2> I can't remember my password.[20:58:56] <CTCT|2> They do have a different format.[20:59:15] <CTCT|2> That's why SCI Companion can't read some of the art files, epecially the sound and script files.[20:59:26] <CTCT|2> SCIC can't read ANY of the script files.[20:59:36] <omer_mor> There's this thread about this here: http://sciprogramming.com/community/index.php?topic=1530.0[20:59:41] <CTCT|2> I think they're encoded differently.[21:00:01] <CTCT|2> That's where I'm getting my information from.[21:00:09] <CTCT|2> I literally already had that open.[21:00:09] *** frankyboy_ <frankyboy_!~franky@ppp91-78-193-193.pppoe.mtu-net.ru> has joined #scummvm[21:00:29] <omer_mor> But are you the same CTxCB that opened that thread?[21:00:41] <CTCT|2> Yeah.[21:00:54] <omer_mor> :)[21:01:12] <CTCT|2> I'm also Christopher, the one who sent you FOOTBALL without knowing you had it.[21:01:45] <omer_mor> Yes - I know CTxCB = Christopher[21:01:54] <CTCT|2> Part of ScummVM's structure would have to be changed to support INN.[21:02:00] <omer_mor> I just wasn't sure it's also CTCT :)[21:02:16] <CTCT|2> Because I've forgotten my passsword it is. :P[21:02:25] <CTCT|2> And CTCB is taken (not mine).[21:02:28] <omer_mor> There's another network-supported SCI game: The Realm Online.[21:02:49] <CTCT|2> The thing is, INN uses COM Ports, The Realm doesn't.[21:03:05] <omer_mor> Correct[21:03:24] <CTCT|2> There'd need to be a COM Port section in ScummVM's settings.[21:03:36] <CTCT|2> It could cover other online games of the time too, such as Habitat.[21:05:12] <omer_mor> Well out of these 3, The Realm Online has the best chance of being supported, as it's actually an RPG game (which is in scope now), and has an actively running server[21:05:23] <omer_mor> Habitat is not really a game[21:05:30] <omer_mor> and there's no server[21:05:36] <omer_mor> same goes for INN[21:05:42] <wanwan> that realm once shipped with unstripped debug symbols, even[21:05:48] <CTCT|2> Well, INN is a game, and could eventually have a server again.[21:06:12] <omer_mor> INN is more of a plarform which is able to run games[21:06:32] <CTCT|2> Well, yeah.[21:06:40] <omer_mor> but games uses different engines. each game would have to be reverse engineered separately.[21:07:31] <omer_mor> wanwan: cool. Is this version still obtainable?[21:07:49] *** ajax16384 <ajax16384!~User@109.60.130.33> has joined #scummvm[21:07:49] *** ChanServ sets mode: +o ajax16384[21:07:55] <CTCT|2> Then how did the original server work?[21:08:00] <wanwan> probably i still have it in my archives somewhere[21:08:17] <omer_mor> wanwan: would you mind sharing it?[21:08:22] <CTCT|2> Not like, the original game one, but the INNRevival one.[21:08:52] <omer_mor> the server is not emulating the games[21:09:12] <omer_mor> dosbox is emulating the host OS which runs the games. they all run on the client side.[21:09:29] <CTCT|2> No, I mean't that as a question regarding the original server.[21:09:44] <omer_mor> the server is just used to allow the clients to interact with each other and maintain shared persistent state[21:09:45] <wanwan> i'll try to find it. but there's no guarantee that i still have it around[21:10:02] <CTCT|2> As in "What's the problem with like, bringing back the original server." whilst you work on a new one.[21:10:09] <wanwan> as it was really old version[21:10:57] <omer_mor> wanwan: if you do - it'll be great. but don't sweat it. :)[21:11:44] <omer_mor> CTCT|2: you mean the old innrevival server? the author doesn't want to run it.[21:12:17] <omer_mor> he said it was horribly written and wanted to rewrite it.[21:12:49] <CTCT|2> Sorry, that's stupid. It might have been horribly written but it was functional.[21:13:13] <CTCT|2> It might be a long time until a brand new server is up and running.[21:13:13] <omer_mor> well, that's his call to make[21:13:34] <CTCT|2> I know it is, I'm just acting on behalf of the belief of every other fan of INNRevival.[21:15:16] <omer_mor> he's actually a cool guy. I guess he's got other stuff he needs to attend to.[21:15:59] <CTCT|2> Yeah. I thought the logical idea would have been to: Keep the current server up, work on a new one, and just switch them over when it's done.[21:17:41] <CTCT|2> The thing about INN's rights has never been to stop you from doing any of this, because I love this, it'll probably never be about that.[21:18:22] <CTCT|2> Evetually, depending on the far future, there could be two INN projects going on at once.[21:18:44] <CTCT|2> Two drastically different INNs.[21:19:06] <CTCT|2> Or it might never happen.[21:23:14] <CTCT|2> omer_mor: Where can I find the specifications of SCI Files? Like resource maps and such.[21:25:17] <m_kiewitz> CTCT|2: you could just check the wiki[21:25:30] <omer_mor> https://github.com/scummvm/scummvm/blob/master/engines/sci/resource.cpp[21:25:36] <omer_mor> http://wiki.scummvm.org/index.php/SCI/Specifications#Resource_files[21:25:38] <m_kiewitz> or right check the source code[21:25:58] <omer_mor> https://github.com/icefallgames/SCICompanion/tree/master/SCICompanionLib/Src/Resources[21:28:29] <omer_mor> http://sierrahelp.com/SCI/Wiki/index.php?title=SCI_Specifications:_Chapter_1_-_Introduction[21:35:56] <CTCT|2> Okay, thanks.[21:45:22] <snover> m_kiewitz: back now for about an hour or so[21:56:02] *** CTCB <CTCB!~kvirc@109.144.210.85> has joined #scummvm[21:56:07] *** CTCB is now known as CTCT[21:56:20] <CTCT> Are there any good tutorials for creating file formats?[21:56:31] <CTCT> Particularly Binary Formats.[21:56:44] *** _sev <_sev!~sev@scummvm/undead/sev> has quit IRC (Quit: This computer has gone to sleep)[21:57:03] *** _sev <_sev!~sev@a238130.upc-a.chello.nl> has joined #scummvm[21:57:03] *** _sev <_sev!~sev@a238130.upc-a.chello.nl> has quit IRC (Client Quit)[21:57:35] *** CTCT|2 <CTCT|2!~kvirc@109.144.210.85> has quit IRC (Ping timeout: 240 seconds)[22:00:20] *** frankyboy_ <frankyboy_!~franky@ppp91-78-193-193.pppoe.mtu-net.ru> has quit IRC (Remote host closed the connection)[22:02:17] *** _sev|work <_sev|work!~sev@a238130.upc-a.chello.nl> has joined #scummvm[22:02:17] *** _sev|work <_sev|work!~sev@a238130.upc-a.chello.nl> has quit IRC (Changing host)[22:02:17] *** _sev|work <_sev|work!~sev@scummvm/undead/sev> has joined #scummvm[22:02:17] *** ChanServ sets mode: +o _sev|work[22:19:44] <snover> CTCT: unfortunately, that question is unanswerably vague. creating binary file formats?[22:21:01] <CTCT> Like, in the long term I'd like to make my own engine for ImagiNation, not for ScummVM, just in general. And a lot of the Sierra Formats I can't use at all.[22:21:24] <CTCT> A Binary File Format is the type of file that looks all jumbled up if you try to read it in a text file.[22:21:44] <CTCT> I need to learn how to define a file format like that, headers and bytes and bits, and how to create and read them.[22:24:16] <CTCT> I mean, unreadable compared to like a CSV which is readable text.[22:25:49] <snover> the only difference between a text file and a binary file is that the text one is ostensibly designed to be read or written by humans[22:26:07] <m_kiewitz> snover: have you read what i last wrote?[22:26:29] <snover> m_kiewitz: yeah, i am looking to see what the flag is that you are thinking of, it looks like kInfoFlagViewInserted[22:26:52] <m_kiewitz> possibly, you would have to check my c++ code based on the script code[22:27:04] <m_kiewitz> i think back then i used a hardcoded value[22:27:17] <CTCT> Probably my first plan will be to make some sort of zip-like format, than can store data like a game's resources.[22:28:13] *** rootfather is now known as rootfather|afk[22:28:30] <snover> m_kiewitz: i’m still digging to see what this flag actually looks like on views at the time of the restore[22:29:47] <snover> (since normally, *any* view object that got sent to GfxFrameout has this flag set, including hidden ones)[22:30:41] *** TMM <TMM!~hp@fsf/member/pdpc.professional.tmm> has joined #scummvm[22:30:41] *** ChanServ sets mode: +o TMM[22:31:47] <m_kiewitz> hmm, im pretty sure by filtering on that and maybe some other value, i only got a few hits[22:33:43] <m_kiewitz> ah no that was the only check, weird[22:35:12] *** ajax16384 <ajax16384!~User@109.60.130.33> has quit IRC (Read error: Connection reset by peer)[22:35:30] *** CTCT <CTCT!~kvirc@109.144.210.85> has quit IRC (Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/)[22:35:56] <m_kiewitz> ah wait, it's the other way[22:36:11] <m_kiewitz> so actually persistent planes/item do not have this flag set[22:37:08] <m_kiewitz> and im not sure about planes, maybe planes are not involved only screen items[22:37:11] <m_kiewitz> it looks that way[22:39:37] <snover> you are seeing some screen items without flag 0x10 at the time of restore?[22:41:44] <m_kiewitz> need to verify[22:42:00] <m_kiewitz> although it makes sense, we are not supposed to reset all screen items[22:42:13] <m_kiewitz> we are only supposed to clear and create non-persistent screen items[22:47:04] <m_kiewitz> ah maybe those persistent ones aren't inside the regular list? idk[22:47:16] <m_kiewitz> that would be a problem, well maybe there is another list[22:47:25] <m_kiewitz> difficult to figure out[22:47:35] <snover> the control panel plane is in the global planes list[22:49:42] <m_kiewitz> and bit 0x10 is not set?[22:49:53] <m_kiewitz> ah wait, the plane[22:50:08] <snover> and all the plane’s screen items are in the plane[22:50:17] <m_kiewitz> that's what's weird about the code, the plane is always created[22:50:25] <m_kiewitz> and the items have that bit not set?[22:50:54] <snover> the items always have that flag set.[22:50:56] <snover> always always.[22:51:23] <snover> it is set by kAddScreenItem, so the game would need to call that call and then mask out the flag, which i’m not seeing anywhere yet[22:52:09] <snover> it does do some weird stuff though[22:52:09] <m_kiewitz> hmm, but we had problems with that one originally?[22:52:31] <m_kiewitz> do you really look into the actual script object?[22:52:41] <snover> yeah, i am looking at Game::restore[22:52:49] <snover> and in the debugger, vo address[22:53:02] <m_kiewitz> hmmm[22:53:34] <m_kiewitz> hmm my comment: // Attention: at least Space Quest 6's option plane seems to stay in memory right from the start and is not re-created.[22:53:43] <m_kiewitz> but the plane would be recreated?![22:53:57] <m_kiewitz> im confused right now :P[22:54:04] <snover> me too[22:54:07] <snover> working on getting unconfused[22:54:54] <m_kiewitz> could it be that we create a second options plane right now?[22:55:26] <snover> nothing new is in _planes at the time the game crashes[22:56:02] <snover> when the user agrees to restore the game, all the planes’ cast members are iterated, and the ones with 0x10 set are deleted via kDeleteScreenItem and then the flag gets OR’d back onto them[22:56:09] <m_kiewitz> yes[22:56:20] <m_kiewitz> but only the screen items are checked for 0x10[22:56:25] <snover> which appears to be designed so that if the actual game restoration fails, the game can restore all the items[22:56:40] <m_kiewitz> but all planes would get deleted by my code[22:56:44] <m_kiewitz> maybe that was even a bug?[22:56:49] <m_kiewitz> does the script code do the same?[22:57:29] <snover> yes, but they are only deleted in GfxFrameout, the plane list in the VM isn’t destroyed until kRestoreGame runs successfully[22:57:40] <m_kiewitz> yes, that makes sense[22:58:21] <DrMcCoy> http://www.tomshardware.com/news/cd-projekt-red-hack-details,33546.html[22:59:43] <m_kiewitz> DrMcCoy: that's why I use throw-away e-mails and simple passwords for almost all forums[23:00:27] <m_kiewitz> "It is our understanding that the obsolete forum database contained usernames, email addresses and salted MD5 passwords"[23:00:28] <m_kiewitz> argh[23:00:36] <snover> i guess there is a question why _planes still has anything in it since all the planes were supposed to have been deleted…[23:01:09] *** WinterGrascph <WinterGrascph!~WinterGra@catv-178-48-146-216.catv.broadband.hu> has joined #scummvm[23:01:09] *** ChanServ sets mode: +o WinterGrascph[23:01:17] <m_kiewitz> nah, we definitely should not delete all planes during restore inside the frameout code[23:01:18] <DrMcCoy> Interestingly, the quote says MD5, the article SHA1?[23:01:34] <DrMcCoy> A dutch article from earlier today also said SHA1[23:01:36] <m_kiewitz> DrMcCoy: one is their old database, the other one seems to be the new database. So old MD5, new SHA1[23:01:52] <m_kiewitz> instead of removing their old database from that server, they kept it[23:02:11] <m_kiewitz> at least that's what I think it means[23:02:22] <snover> m_kiewitz: kDeletePlane is called on all of them. but i just remembered that a frameout has to occur for the graphics manager to process that and actually delete them[23:02:57] <m_kiewitz> snover: hmm, i'm pretty sure that we shouldn't delete everything. at least screen items related[23:03:10] <snover> i’m just saying what the game scripts do[23:03:11] <m_kiewitz> maybe the delete plane doesn't go through when there are still screen items left?[23:03:17] <m_kiewitz> do you know?[23:03:37] <snover> irrelevant since the game deletes all the screen items first[23:03:37] <m_kiewitz> trying to make sense of the code. it definitely skips some screen items - or is able to do so[23:04:04] <m_kiewitz> im really sure that we originally deleted _planes and _screenItems completely and that ruined the game[23:04:19] <m_kiewitz> because it assumed that the options would still be there[23:05:39] <snover> i need to go for a while again, but let me just wrap up my thoughts so hopefully we are on the same page[23:06:37] <m_kiewitz> need to look into it once again via debugger[23:06:48] <m_kiewitz> im definitely sure that originally we deleted everything and that made the game go mad[23:06:57] <m_kiewitz> so right now we can't delete everything[23:09:59] <snover> First, there is no more GfxFrameout::syncWithScripts in the working branch, so whatever that used to do isn’t the cause of the problem—or the solution to the problem, because this happens with original save/load too. The problem happens when the segment of SQ6Controls changes, because the game needs the reg_ts to match the addresses in the save game.[23:13:08] *** GitHub107 <GitHub107!~GitHub107@192.30.252.41> has joined #scummvm[23:13:08] <GitHub107> [scummvm] sev- pushed 3 new commits to master: https://git.io/vDqZC[23:13:08] <GitHub107> scummvm/master 93265c6 Eugene Sandulenko: GRAPHICS: Fix font transtion formatting for MacText[23:13:08] <GitHub107> scummvm/master c15e063 Eugene Sandulenko: GRAPHICS: Store more metainformation on lines in MacText[23:13:08] <GitHub107> scummvm/master d4e4a20 Eugene Sandulenko: GRAPHICS: Implement rendering of rich MacText[23:13:08] *** GitHub107 <GitHub107!~GitHub107@192.30.252.41> has left #scummvm[23:13:36] <snover> The solutions I can think of are either to ensure segment IDs remain the same (like by deriving the segment ID from the script number), or to figure out which script pointed to which segment in the original save game and then relocating those segments when the game is loaded to match the existing segment IDs in the engine for each script.[23:15:41] <snover> Maybe there is a better option that I can’t think of, since both of these are kind of brittle solutions. But then, the original interpreter was this brittle as well, and it seems that games leveraged the brittle but predictable behaviour of MemIDs.[23:16:22] <snover> OK. I’ll be back in another hour or so.[23:17:06] <m_kiewitz> hmm, how exactly are the screen items created on our side?[23:17:22] <m_kiewitz> or is it a script object problem internally?[23:17:51] <m_kiewitz> changing segment for script objects is a major change[23:18:34] <m_kiewitz> i really wonder why the segment id changes[23:18:52] <m_kiewitz> during restore all of that should be reinitialized and loaded from the save file[23:18:58] <m_kiewitz> maybe something got broken inbetween[23:41:50] *** _sev|work <_sev|work!~sev@scummvm/undead/sev> has quit IRC (Quit: This computer has gone to sleep)[23:48:08] *** ny00123 <ny00123!~ny00123@89-139-172-204.bb.netvision.net.il> has quit IRC (Quit: Leaving)[23:49:29] *** _sev <_sev!~sev@a238130.upc-a.chello.nl> has joined #scummvm[23:49:29] *** _sev <_sev!~sev@a238130.upc-a.chello.nl> has quit IRC (Changing host)[23:49:29] *** _sev <_sev!~sev@scummvm/undead/sev> has joined #scummvm[23:49:29] *** ChanServ sets mode: +o _sev