#exult@irc.freenode.net logs for 10 Oct 2013 (GMT)

Archive Today Yesterday Tomorrow
Exult homepage

[00:24:51] <-- Rottingbeef has left IRC (Ping timeout: 264 seconds)
[03:27:25] <-- poutine has left IRC (Quit: ZNC - http://znc.sourceforge.net)
[03:47:08] --> poutine has joined #exult
[05:34:08] --> Rottingbeef has joined #exult
[06:00:37] <-- Rottingbeef has left IRC ()
[07:48:33] --> shazza has joined #exult
[09:04:28] <-- shazza has left IRC (Ping timeout: 248 seconds)
[09:10:16] --> shazza has joined #exult
[10:52:44] <Dominus> hmm, ok, houston, we have a problem. another save/load crash in britain... :(
[10:52:58] * Dominus goes on to build a debug enabled exult...
[10:58:14] <Dominus> actually from my snapshots it must be Jeff's latest commit.
[11:00:04] <Dominus> wjp, do you have any idea why rev 7433 bombs Exult in Britain?
[11:13:33] <Dominus> yeah, gdb confirms it is in there schedule.cc:2486
[11:14:07] <Dominus> so if (item->get_lift() / 5 != floor || memchr(desk_frames, item->get_framenum(), DESK_FRAMES_CNT) == 0) makes it crash
[11:44:39] <sh4rm4> i'm waiting since a year for a *stable* version to play again...
[11:45:05] <sh4rm4> it's probably best to find out what ubuntu 7.07 used - that one seemed to work
[12:04:04] --> Rottingbeef has joined #exult
[12:06:11] <wjp> Dominus: and r7432 worked?
[12:16:14] --> TheCycoONE has joined #exult
[12:27:55] <Dominus> wjp: I'm not at home anymore, but yes, 7432 worked
[12:28:15] <Dominus> gdb also points there in bt
[12:28:58] <Dominus> first at objs because of get_lift and then at the schedule.cc line
[12:29:18] * Dominus is gone again
[12:42:14] <wjp> oh, the erase is broken
[12:42:40] <wjp> so the bug was already there, but not triggered before
[13:09:25] <-- shazza has left IRC (Ping timeout: 252 seconds)
[15:16:48] <-- RadoS has left IRC (Quit: reboot)
[15:17:34] --> ShamblerDK has joined #exult
[15:29:20] --> RadoS has joined #exult
[16:09:55] --> Malignant_Manor has joined #exult
[16:10:25] <Malignant_Manor> wjp: Dominus , shouldn't this work? http://pastebin.com/9V0ivLcz
[16:24:23] <wjp> no
[16:25:17] <wjp> hm, or maybe? I can't look closely right now
[16:25:55] <Malignant_Manor> I don't have a test save for it. I think erase screws up the index and that may be the problem.
[16:27:37] <wjp> yes, that's broken in the current code
[16:44:01] <sh4rm4> that patch looks like it should work
[16:44:25] <sh4rm4> (not an expert on C++ iterators tho)
[16:44:51] <Malignant_Manor> Wow, I made a stupid mistake 2 and a half years ago to combat ai and it was just now reported.
[18:27:36] <Malignant_Manor> There's a bug that has probably always happened that was reported 2 days ago on the forum. UI_remove_item removes the contents if it deletes a container. Exult isn't doing that.
[18:41:24] <Dominus> hey Malignant_Manor, you're on a roll! great!
[18:41:40] <-- TheCycoONE has left IRC (Quit: And then there were n-1)
[18:42:01] <Dominus> I'm still not at home, so can't check your above patch
[18:43:20] <Malignant_Manor> I can reproduce that crash and my fix seems to work fine.
[18:48:25] <wjp> I'm not entirely comfortable with moving the iterator to before the vector start
[18:49:57] <Malignant_Manor> I guess it could go below zero or wrap around if unsigned.
[18:51:15] --> TheCycoONE has joined #exult
[18:53:38] <Malignant_Manor> http://wiki.ultimacodex.com/wiki/Exploded_Powder_Mill lists Keyring Mod instead of Serpent Isle Fixes page link. I'm blocked since it says I have an open proxy
[19:02:35] <Malignant_Manor> wjp: Here's something that should work http://pastebin.com/uDv6vXWv
[19:04:04] <wjp> that'll behave exactly like the current code
[19:04:24] <wjp> 'it' is still invalidated after the erase
[19:05:10] <wjp> the typical thing to do here is remove the ++it from the for() itself, and do a 'it = vec.erase(it); else ++it'
[19:06:03] <Malignant_Manor> Yeah, I see what you mean
[19:07:23] <Malignant_Manor> Would it be it++; ?
[19:10:23] <Malignant_Manor> http://pastebin.com/ZzAgY0V4
[19:11:24] <wjp> same thing if the value itself is unused
[19:11:36] <wjp> but you missed the first part of my line :-)
[19:11:51] <wjp> since now 'it' is still invalidated
[19:11:53] <Marzo> (01:10:20 PM) Malignant_Manor: wjp: Dominus , shouldn't this work? http://pastebin.com/9V0ivLcz
[19:12:03] <Marzo> Use it = vec.erase(it);
[19:12:14] <wjp> Marzo: see aboe :-)
[19:12:16] <wjp> s/oe/ove/
[19:12:26] <Marzo> Oh, I was still catching up
[19:16:33] <Malignant_Manor> wjp: Marzo , Dominus , oops, brain wasn't working. http://pastebin.com/vmEpjaWA
[19:17:16] <Malignant_Manor> I don't know why I added brackets
[19:17:49] <wjp> haven't tested, but that should do it
[19:18:07] <Marzo> Malignant_Manor: use ++it instead, it is faster
[19:18:24] <Malignant_Manor> I need to eat. I will blame that instead of my own incompetence.
[19:18:26] <wjp> not that that matters one bit here :-)
[19:27:33] <sh4rm4> <Marzo> Malignant_Manor: use ++it instead, it is faster
[19:27:45] <sh4rm4> ugh, if that's really the case, you should use another compiler
[19:28:21] <Marzo> Try telling that to -O0 -g I use for debugging
[19:28:27] <Malignant_Manor> For some reason I thought it++ was faster.
[19:28:59] <sh4rm4> i bet this was true 15 years ago, and the myth keeps living on since then
[19:31:46] <Malignant_Manor> Seeing pseudo code for what happens definitely shows I was wrong.
[20:31:23] <-- TheCycoONE has left IRC (Quit: And then there were n-1)
[20:33:49] <Dominus> thanks Malignant_Manor
[20:34:21] <Malignant_Manor> I'm surprised you haven't bugged Marzo to do anything.
[20:35:38] <Dominus> I was surprised you waited so long mentioning me bugging Marzo so often
[20:40:31] <Dominus> there are two things that need to be done that *I* can't do (big surprise with my vast programming knowledge):
[20:40:34] <Dominus> - hack sorting of the y-shapes on the altar of discipline
[20:40:48] <Dominus> - fix the trap of that altar
[20:41:13] <Dominus> THEN we might think about getting any release out there
[20:41:29] <Dominus> if we can do that before middle of december, great!
[20:42:34] <Dominus> if not I assign Malignant_Manor the honor of release manager. I will not have time after that for awhile
[21:31:24] <wjp> Malignant_Manor: re. your comment on the bug tracker: I'm pretty sure we won't mind you fixing bugs even if they're not severe :-)
[21:31:47] <Malignant_Manor> Well tracker assignment
[21:31:49] <Malignant_Manor> e
[21:32:00] <Malignant_Manor> etiquette
[21:32:38] <Dominus> nah, when someone assigned it to someone else, take it when you want it :)
[22:53:28] <-- ShamblerDK has left IRC (Remote host closed the connection)
[23:35:36] <Malignant_Manor> Dominus: The original handles the trap poorly. It
[23:36:24] <Malignant_Manor> just deletes the usecode egg that keeps hatching it.
[23:36:42] <Malignant_Manor> It will start firing again once you cache out and come back.
[23:37:07] <Dominus> Malignant_Manor: I was just about to go to bed :)
[23:37:52] <Dominus> thanks, I didn't test whether it "resets" in the original. never thought of that when I tested it last time
[23:38:04] <Malignant_Manor> It would be so easy if we could edit usecode to delete the trap egg.
[23:38:27] <Malignant_Manor> (once that egg was removed)
[23:38:49] <Dominus> :(
[23:39:42] <Dominus> but why can't we do it as poorly as the original?
[23:40:06] <Dominus> or rather why does that not work as in the original?
[23:41:57] <Malignant_Manor> I don't know how they handled eggs. I had to hardcode some SS teleport eggs so they would reset.
[23:42:48] <Malignant_Manor> But those eggs work fine in the original engine.
[23:43:22] <Dominus> Marzo had some insight here last time he had a burst of activity
[23:45:01] <Dominus> http://log.usecode.org/exultlog.php?log=28Jul2013
[23:45:42] <Dominus> really got to go now
[23:45:45] <Dominus> thanks
[23:51:05] <Malignant_Manor> It definitely fires more than once when it gets cached back in using the original engine after the hatching usecode egg is deleted. So I guess if hatched traps fire once in SI, the traps somehow get reset on cache out even without auto-reset and then don't set the hatched flag.
[23:51:35] <Malignant_Manor> Having you own game data is so much better than reverse engineering.
[23:58:23] --- Epictrope is now known as Epitrope