[02:20:31] <-- Dominus has left IRC (Ping timeout: 256 seconds)
[04:23:42] --> azeem has joined #exult
[04:27:35] <-- azeem_ has left IRC (Ping timeout: 246 seconds)
[05:55:00] --> KnightCaptain has joined #exult
[05:55:16] <-- KnightCaptain has left IRC (Client Quit)
[08:20:41] <-- Lightkey has left IRC (Ping timeout: 245 seconds)
[08:29:23] --> Dominus has joined #exult
[08:29:23] <-- Dominus has left IRC (Changing host)
[08:29:23] --> Dominus has joined #exult
[08:29:23] --- ChanServ gives channel operator status to Dominus
[08:33:10] --> Lightkey has joined #exult
[10:47:30] <wjp> Marzo: when did we discuss shared_ptr and such on the mailing list?
[10:47:52] <wjp> I think I only remember it specifically in the context of game objects and schedules
[11:21:19] <Marzo> It was, yes
[11:21:52] <Marzo> But as I found out, applying it to game objects mean a LOT of changes
[11:22:26] <wjp> I don't remember performance being considered as a factor
[11:23:03] <Marzo> I still have some uncommitted changes from that era (shared_ptr branch) which are hefty and never tested because they were still only halfway through the codebase, with the result that Exult did not compile
[11:23:16] <Marzo> Jeff raised performance as a concern
[11:23:20] <wjp> ah
[11:23:48] <Marzo> To be fair, I think it will be easier to do as I was discussing with Dominus the other day
[11:24:19] <wjp> my personal feeling is that mixing C++ memory management and script-related memory management might be problematic
[11:24:28] <Marzo> Keep existing Exult and do bug fixes and patches, and start a new codebase using everything learned over these 2 decades
[11:25:07] <Marzo> The way I was doing it had the script having either a shared_ptr or a weak_ptr to the object
[11:25:14] <wjp> a new codebase does have its attractions
[11:25:16] <Marzo> The former would allow the script to complete
[11:25:27] <Marzo> The latter would allow checking if the object still exists
[11:25:41] <Marzo> Win-win, either way
[11:26:24] <wjp> is saving and loading easily doable that way?
[11:26:56] <Marzo> I never did get to that part, to be honest
[11:27:19] <Marzo> Scripts would not be too much of a concern because they are saved right after their parent object
[11:27:52] <Marzo> But schedules are saved separately, and may have references to objects other than the NPC they apply to
[11:27:59] <Marzo> (not that we save schedule state)
[11:28:50] <Marzo> Also, static usecode variables referencing game objects don't save anything currently
[11:29:14] <Marzo> They just write a (possibly truncated) null pointer (4 bytes)
[11:29:44] <Marzo> So until we fix those, saving/loading is not much of an issue
[11:31:01] <wjp> in master or in your branch?
[11:31:05] <Marzo> Ideally, we would save the map chunks first and use the position of the object there to serialize it
[11:31:22] <Marzo> This is all in master
[11:35:51] <Marzo> Also, at some point we might want to save and restore weather effects
[11:37:53] <Marzo> wjp: the major thing about a new codebase is that I would push *hard* for at least C++14 and Boost; as well as at least *some* level of test-driven programming with tests meant to ensure that several components are working correctly
[11:38:33] <Marzo> Also, for this: http://gameprogrammingpatterns.com/
[11:43:23] <wjp> I'll have to read that
[12:10:38] <wjp> c++14 is probably fine these days. Debian stable is still at gcc 4.9 IIRC, but the next debian is due to be released relatively soon
[12:10:49] <wjp> and I assume apple is at a modern enough clang by now?
[12:11:17] <wjp> (RHEL is also still a bit behind, but that has a developer toolset available with a more modern gcc)
[12:13:26] <Marzo> wjp: interestingly, DJGPP (GNU tools for DOS) already has GCC 6.2
[12:14:03] <Marzo> But yeah, most distributions are getting newer GCC/clang these days, and even MSVC++ has full support for C++14
[12:16:04] <Marzo> Even more, newer GCC, Clang and MSVC already have partial support for C++17, and it is not even out yet
[12:18:04] <wjp> yeah, cppreference has a nice chart
[12:39:48] <Dominus> Marzo: about that recent playthrough BG Keyring by a user on the forum
[12:40:17] <Marzo> I haven't been following it; can you give me a summary?
[12:40:20] <Dominus> While there are many small known issues he also mentioned "frozen" NPCs
[12:40:40] <Dominus> Which only move when you talk to them
[12:41:02] <Dominus> I think this is only happening in BG Keyring mod
[12:41:49] <Dominus> I noticed this with some of the other outdated mods and I fear this might be one of the dreaded outdated savegame base bug
[12:43:07] <Marzo> Did he say who were these frozen NPCs?
[12:43:25] <Dominus> I think all over the place
[12:43:29] <Dominus> Let me look
[12:44:22] <Dominus> Markus(?) in Trinsic
[12:45:10] <Dominus> Morfin, Baleva and Thurston in Paws
[12:46:03] <Dominus> Still not at home for a couple of days so can't really verify but I didn't notice such behaviour in normal playing
[12:49:01] <Dominus> Apart from that he noticed many many little things and of course the big one "combat"
[14:29:25] <-- RadoS has left IRC (Quit: not planned disconnect)
[14:46:14] --> RadoS has joined #exult
[17:29:02] --> Malignant_Manor has joined #exult
[17:29:48] <Malignant_Manor> Marzo: do you know if there is still anything holding Kirben back from using a newer GCC?
[18:05:23] <Malignant_Manor> Would MinGW-w64/MSYS2 be a better build environment for Windows than Mingw/MSYS?
[18:14:25] <Dominus> I think it's all about keeping backward compatibility
[18:15:16] <Dominus> But why don't you write and ask him?
[18:16:10] <Dominus> When I get home I will apply wjp's scale x1 circumvention to make SDL2 work and then will ask him to make SDL2 the default
[18:16:28] <Malignant_Manor> I know I had 2 MinGW folders so I could compile older versions of Exult.
[18:17:05] <Dominus> Is mingw-w64 32bit compatible?
[18:18:13] <Dominus> And, judging from Kirben's previous compatibility concerns, what is the lowest Windows version compatibility of mingw-w64?
[18:18:27] <Malignant_Manor> Yes. I can use 32 bit and 64 bit binaries.
[18:18:34] <Malignant_Manor> I=It
[18:19:24] <Malignant_Manor> It has a newer GCC version, and I think it has more default packages.
[18:19:27] <Dominus> Yes, lowest compatibility is w2k
[18:23:21] <Dominus> I had to "cheat" to make Studio work in Wine... I took the gtk stuff from a recent Gimp installation and threw everything into Exult's folder ;)
[18:23:40] <Dominus> Another case of keeping compatibility too low ;)
[18:24:06] <Malignant_Manor> I need to install a build environment on this computer. I think I will just copy it from another computer for the time being. I hate having to compile all the dependencies. Lubuntu is crashing, and I don't feel like messing with it atm.
[18:25:44] <Malignant_Manor> I probably need the Nvidia proprietary driver for Xinerama.
[18:32:15] --> KnightCaptain has joined #exult
[18:32:39] <KnightCaptain> Having some trouble with yesterday's build: exult_si.flx has a wrong checksum!
[18:42:01] <KnightCaptain> Using the --nocrc option works, as expected.
[18:49:56] <KnightCaptain> I don't what changed with the spell shapes in both the 2016-12-03 and 2017-01-03 builds, but I cannot add the spell shapes to containers for the standardized SS NPCs. I get a WON'T FIT when trying to give Shal any spell shapes into his new backpack, but I can drop in anything else.
[18:50:36] <KnightCaptain> So I can't actually outfit him in a canonical fashion with his New England Patriots like offense.
[18:51:15] <KnightCaptain> This was _not_ an issue ~2 months ago when I did these new NPCs then on my cancelled pull request.
[18:58:17] <KnightCaptain> Odd, some spell shapes will fix, others won't. But I'd still say this is a regression.
[19:06:27] <Malignant_Manor> You'd have to a commit from back then to confirm for sure. Then you could track down when the issue happened.
[19:09:59] <KnightCaptain> Thanks MM. I'm not much of a coder. But I can see the three shapes affected have both Light source and On Fire flags set on them.
[19:10:23] <Malignant_Manor> Okay, then that would be the problem.
[19:11:07] <Malignant_Manor> Marzo added a check that would stop lit torches from being put in containers.
[19:11:29] <Malignant_Manor> There is no need to go back and check what caused it.
[19:13:26] <KnightCaptain> Phew. It does work, in that I can't add lit candles, torches, nor fires, etc.
[19:13:52] <KnightCaptain> So hack mover / ES edit mode should not use that new check then.
[19:27:15] <KnightCaptain> Bug reports are in for both issues. The original games used the generic red X cursor for rejecting On Fire shapes, not Won't Fit.
[19:27:37] <KnightCaptain> Lucky me, I got bugs 2000 and 2001. I've got a bad feeling about this...
[19:38:38] <-- amatecha has left IRC (Ping timeout: 246 seconds)
[19:40:35] --> amatecha has joined #exult
[20:16:26] <-- KnightCaptain has left IRC (Quit: Nettalk6 - www.ntalk.de)
[20:47:36] <-- Malignant_Manor has left IRC (Quit: ChatZilla 0.9.93 [Firefox 50.1.0/20161208153507])
[21:01:34] <-- tsoliman has left IRC (Quit: ZNC - http://znc.in)
[21:03:32] --> tsoliman has joined #exult
[22:59:41] <-- tsoliman has left IRC (Quit: ZNC - http://znc.in)
[23:48:48] --> KnightCaptain has joined #exult
[23:49:24] <KnightCaptain> I've got the old 2016-08-22 build working for the NPC edits, so progress will happen. w00t!
[23:49:30] <-- KnightCaptain has left IRC (Client Quit)