#exult@irc.freenode.net logs for 10 Nov 2011 (GMT)

Archive Today Yesterday Tomorrow
Exult homepage


[01:02:53] <-- ParuNexus has left IRC (Ping timeout: 260 seconds)
[01:03:05] --> ParuNexus has joined #exult
[06:01:51] <-- sh4rm4 has left IRC (Ping timeout: 248 seconds)
[06:41:41] --> sh4rm4 has joined #exult
[07:11:33] --> ParuCodex has joined #exult
[07:15:26] <-- ParuNexus has left IRC (Ping timeout: 276 seconds)
[07:18:30] --> Dominus1 has joined #exult
[07:18:30] <-- Dominus has left IRC (Read error: Connection reset by peer)
[07:20:29] <-- RadoS has left IRC (Remote host closed the connection)
[08:09:59] <-- Dominus1 has left IRC (Read error: Connection reset by peer)
[08:10:07] --> Dominus has joined #exult
[08:10:08] --- ChanServ gives channel operator status to Dominus
[08:11:35] --> Matt_O1 has joined #exult
[08:15:23] <-- Matt_O has left IRC (Ping timeout: 258 seconds)
[08:34:12] --> Rottingbeef has joined #exult
[09:22:24] --> RadoS has joined #exult
[10:18:26] --> SiENcE has joined #exult
[10:18:29] <-- Colourless has left IRC (Read error: Connection reset by peer)
[10:23:44] --> Colourless has joined #exult
[10:23:44] --- ChanServ gives channel operator status to Colourless
[11:04:08] <-- SiENcE has left IRC (Quit: @all: cya)
[11:17:44] <-- Matt_O1 has left IRC (Read error: Connection reset by peer)
[11:18:12] --> Matt_O1 has joined #exult
[13:04:44] <-- Kirben has left IRC ()
[13:27:48] --> TheCycoONE has joined #exult
[15:42:22] --> SiENcE has joined #exult
[16:09:47] <-- SiENcE has left IRC (Quit: @all: cya)
[16:40:23] <-- TheCycoONE has left IRC (Read error: Connection reset by peer)
[16:42:58] --> TheCycoONE has joined #exult
[17:33:07] --> sh[4]rm4 has joined #exult
[17:34:07] <-- sh4rm4 has left IRC (Ping timeout: 248 seconds)
[18:21:17] --- sh[4]rm4 is now known as sh4rm4
[19:08:07] <sh4rm4> i just added a couple of bugreports
[19:08:13] <sh4rm4> including the endless loop
[19:08:34] <sh4rm4> which should be relatively easy to fix with a bit of knowledge about game internals
[19:09:49] <sh4rm4> maybe that bug (inserting an item (which references itself via next) multiple times in the gameobjects list) is the cause of the random disappearing items bug as well
[19:13:42] <sh4rm4> btw. i remember having played serpent isle using exult in 2007, and i hit no single bug
[19:13:56] <sh4rm4> while the current svn is full of them
[19:15:43] <wjp> the trick with the endless loop is not figuring out where it loops, but where the problem is introduced
[19:16:02] <wjp> I think we got somewhere earlier, but not far enough
[19:16:11] <wjp> your observation that it's shape 462 is interesting
[19:16:26] <wjp> (462 is "fighter", by the way)
[19:17:23] <sh4rm4> wjp, indeed
[19:17:46] <sh4rm4> one had to look for the spot where that kind of item gets inserted into the list
[19:19:32] <wjp> I wrote up a patch last thing that adds some sanity check asserts to the list manipulation functions
[19:19:36] <wjp> s/thing/time/
[19:20:06] <sh4rm4> yep, that could help
[19:20:26] <sh4rm4> i imagine a debug "insert" function, which asserts that the item to be inserted is not in the list yet
[19:20:34] <wjp> that's the idea
[19:20:41] <sh4rm4> so it would cause the debugger to break
[19:22:06] <sh4rm4> but i first would look at the spots where shapes of type "fighter" get inserted
[19:22:11] <sh4rm4> maybe its obvious
[19:22:39] <wjp> things like that aren't in our code but in the scripts and map data
[19:23:35] <sh4rm4> means the usecode is bugged ?
[19:23:42] <wjp> no
[19:23:57] <wjp> it just means there's no well-defined spot where shapes of type "fighter" get inserted
[19:24:07] <sh4rm4> ok
[19:25:03] <sh4rm4> if you could come up with a patch that implements that assert in the list_insert function, i could do some testing
[19:25:52] <wjp> hm, reading back the logs it might be a slightly different one
[19:26:52] <wjp> no, probably the same
[19:26:58] <wjp> http://log.usecode.org/exultlog.php?log=14Dec2010
[19:30:15] <wjp> starting at 23:28 I give a number of locations to add asserts
[19:30:38] <sh4rm4> [23:27:22] <wjp> except that it's a bit annoying that that's valid if there's only one object
[19:31:02] <sh4rm4> why isnt the end of the list just NULL ?
[19:31:06] <sh4rm4> would be much simpler
[19:31:35] <sh4rm4> i kinda had trouble to understand the whole cur = first; last = first, blah logic going on there
[19:32:02] <wjp> circular lists simplify some things
[19:32:22] <sh4rm4> and complexify others...
[19:32:48] <sh4rm4> you can just start with list->first if list->next == NULL
[19:32:56] <sh4rm4> *if* you want to restart
[19:33:17] <wjp> the point is removing special cases, not adding them :-)
[19:33:52] <wjp> anyway, changing basic things like that is a recipe for trouble
[19:37:34] <sh4rm4> if you have a borked complexed list implementation, it's better to just rewrite instead of trying to fix the crap
[19:39:03] <wjp> my guess would be the list is fine but there's just one spot where it's corrupted
[19:39:21] <wjp> the core really hasn't changed since 2007 when you said things were fine
[19:40:06] <sh4rm4> ok
[19:40:08] <wjp> the thing with issues like this is that the data structure implementation itself is hardly ever the problem
[19:40:31] <wjp> and all the other code will depend on the list having the properties it does
[19:41:00] <sh4rm4> well that specific case is a bit extraordinary. the iterator does all kind of stuff which it actually shouldnt
[19:41:16] <wjp> ?
[19:41:27] <sh4rm4> the only thing an iterator has to know is start, end, and current position
[19:41:44] <sh4rm4> instead it is twisting around state on each iteration
[19:41:49] <wjp> what are you talking about?
[19:42:02] <sh4rm4> the GameObject ListIterator
[19:42:58] <wjp> I don't see what you mean?
[19:43:33] <sh4rm4> second, i have to find the file again
[19:47:24] <sh4rm4> objiter.h
[19:47:51] <sh4rm4> if (cur == stop)
[19:47:51] <sh4rm4> return 0;
[19:47:51] <sh4rm4> T ret = cur;
[19:47:51] <sh4rm4> cur = cur->next;
[19:47:51] <sh4rm4> stop = first;
[19:47:52] <sh4rm4> return ret;
[19:49:38] <wjp> it's a bit awkward, but no more than that
[19:50:21] <sh4rm4> and weird in that the the lists current object is actually the next
[19:50:53] <wjp> that's just internal to the iterator
[19:50:54] <sh4rm4> and that stop has to be set to first is strange
[19:51:05] <wjp> no, that's what you get with a circular list without a dedicated anchor node
[19:51:26] <sh4rm4> well, first should always be the same, no ?
[19:51:29] <wjp> you need to differentiate between "at first node at start" and "at first node after one step"
[19:51:48] <wjp> s/after one step/at end/
[19:52:18] <sh4rm4> see how a circular list makes stuff complicated ? ;)
[19:52:24] <wjp> this isn't complicated :-)
[19:53:19] <sh4rm4> i could imagine some of your contributors haven't found out that list->cur is actually list->cur->next after the iterator was invoked...
[19:53:37] <wjp> that isn't true
[19:53:46] <wjp> this variables are completely internal to the iterator
[19:53:52] <wjp> s/this/these/
[19:54:03] <wjp> no other code ever gets to see them
[19:54:41] <sh4rm4> i was able to access obj->next from code outside the iterator
[19:54:52] <wjp> yes, but that's not what you said
[19:56:10] <sh4rm4> anyway, does "first" change while the iterator gets queried ?
[19:56:29] <wjp> first is internal to the iterator
[19:56:44] <wjp> and you have the entire code of the iterator class right there :-)
[19:57:28] <sh4rm4> mhm, 186 lines of code in a *header*
[19:57:50] <wjp> yeah, it's pretty short
[19:57:50] <sh4rm4> the iterator code for my hashlist is 20 lines
[19:58:01] <wjp> so is this one
[19:59:04] <sh4rm4> so whats that nonflat stuff ?
[19:59:38] <wjp> I'm a bit fuzzy on the specifics, but there are flat and non-flat objects
[19:59:42] <wjp> the flats are the ground tiles
[20:06:12] <sh4rm4> ok, i'm not really in the mood to try to understand this braindead C++ code...
[20:06:35] <wjp> it would help not to start out with the assumption it's braindead
[20:06:37] <sh4rm4> i have posted a savegame, so you guys can look at the issue... or not
[20:06:53] <sh4rm4> i don't assume, i see
[20:07:18] <wjp> all your points so far were based on incomplete understanding of the code
[20:07:23] <wjp> so you assume :-)
[20:07:43] <sh4rm4> and why is that ? because its overly complex
[20:07:47] <wjp> once you start assuming things are done for no reason, you won't see the reasons...
[20:07:52] <sh4rm4> or "braindead" in my terms
[20:08:36] <sh4rm4> even that it is stored in a header makes me angry
[20:08:43] <wjp> templates
[20:08:50] <sh4rm4> one little change means everything has to be recompiled
[20:09:42] <sh4rm4> you can do it in a C file using void*
[20:10:02] <sh4rm4> and the whole iterator can be written in a straightforward way in 20 lines
[20:10:04] <wjp> or we can not get rid of type-safety
[20:11:03] <wjp> the iterator _is_ only 20 lines
[20:11:29] <sh4rm4> ok, and the rest if template boilerplate ?
[20:11:32] <sh4rm4> *is
[20:11:38] <wjp> those are different iterators
[20:12:36] <wjp> and some logic to allow you to detect iterating while a list is modified
[20:13:34] <sh4rm4> ok...
[20:15:42] <wjp> hm, I wish I had better luck with reproducing bugs :-(
[20:16:59] <wjp> ooh, dragons
[20:17:05] <wjp> but still no fighters or hangs :/
[20:17:29] <sh4rm4> yeah, it can take some minutes
[20:17:50] <sh4rm4> however, iirc it was not while in a fight
[20:18:06] <sh4rm4> it happened randomly while running around in the dungeon
[20:18:27] <sh4rm4> maybe the act of collecting gold and other stuff helps as well
[20:19:03] <sh4rm4> one could write a "play-bot" which does that automatically ;)
[20:19:14] <wjp> I do kind of feel like one now :-)
[20:19:36] <sh4rm4> are you on x64 ?
[20:19:40] <wjp> yes
[20:20:02] * sh4rm4 too
[20:20:11] <sh4rm4> i compiled exult using gcc 4.5,1
[20:20:19] <sh4rm4> -O0 -g
[20:20:44] <sh4rm4> but i dont think it is a compiler bug
[20:21:54] <wjp> yeah, I think enough people have seen it to rule that out
[20:23:45] <wjp> are you playing at the normal resolution?
[20:24:09] <wjp> (game area 320x200)
[20:25:52] <sh4rm4> mmh, i used to play at 11xx* 768
[20:27:22] <wjp> oh, _Sentry_ is shape 462
[20:27:29] <wjp> s/y/i/
[20:27:41] <sh4rm4> aha!
[20:54:33] <sh4rm4> oh btw...
[20:54:46] <sh4rm4> i've made a coredump from inside the endless loop
[20:55:14] <sh4rm4> if it helps i can upload it together with the exult binary
[20:55:58] <sh4rm4> the coredump is 80MB
[20:57:23] <wjp> I think we'll really have to catch it while it's trying to corrupt the list
[20:57:42] <sh4rm4> yeah, the coredump doesnt help there
[20:57:59] <sh4rm4> neither the asserts inside the iterator code
[21:13:23] --> SiENcE has joined #exult
[21:47:24] <-- Rottingbeef has left IRC ()
[22:00:25] <-- TheCycoONE has left IRC (Quit: KVIrc 4.0.4 Insomnia http://www.kvirc.net/)
[23:03:43] <-- SiENcE has left IRC (Ping timeout: 248 seconds)
[23:17:21] --> SiENcE has joined #exult
[23:21:48] --> Kirben has joined #exult
[23:21:48] --- ChanServ gives channel operator status to Kirben
[23:42:48] <-- SiENcE has left IRC (Quit: cya)