[00:18:54] --> Kirben has joined #pentagram
[00:18:54] --- ChanServ gives channel operator status to Kirben
[04:11:42] --> Servus has joined #pentagram
[09:54:15] <-- Servus has left IRC ()
[09:56:55] --> Servus has joined #pentagram
[10:15:27] --> wjp has joined #pentagram
[10:15:27] --- ChanServ gives channel operator status to wjp
[10:35:11] <-- Servus has left IRC ()
[12:09:18] --> Dark-Star has joined #pentagram
[12:31:21] <-- Dark-Star has left IRC ("Leaving")
[12:59:51] --> Colourless has joined #Pentagram
[12:59:56] --- ChanServ gives channel operator status to Colourless
[13:00:18] <wjp> hi
[13:00:43] <Colourless> Hi!
[13:01:19] <wjp> I was just about to write an email about objID assignment
[13:01:33] <wjp> we may need something like itemcach after all
[13:02:12] <Colourless> well items need to keep their numbers after restoring/saving games and npcs definately need to keep their numbers always :-)
[13:02:18] <wjp> exactly
[13:02:36] <wjp> so we either add an objID field to the save format, or have an itemcache for the current map, I guess
[13:03:17] <Colourless> well we want to be able to quickly access an item from it's number
[13:03:29] <Colourless> and we would also like to be able to quickly get a number from an object...
[13:03:42] <wjp> World will have a objID->object* map, probably
[13:04:06] <Colourless> an array of pointers to objects could be one way of getting quick access to an object from it's number
[13:05:24] <wjp> sorry, I meant map in the mathematical sense :-)
[13:05:31] <wjp> could be std::map/vector/whatever
[13:07:43] <wjp> brb
[13:07:46] <Colourless> whatever method is selected, there will be at least 3 ways of accessing objects. Per 'glob', iterating through the master array/list of objects, and by item number. The last 2 may or may not be the same thing
[13:31:07] <wjp> b
[13:31:26] <Colourless> wb
[13:41:26] <wjp> anyway, back to obj IDs... :-)
[13:42:01] <wjp> would you add an objID field to all objects in a savegame, or add an itemcach-like file to the saves?
[13:42:05] <wjp> I think I'd prefer the former
[13:42:25] <wjp> it'll waste some space, but that shouldn't be too much of a problem
[13:42:58] <Colourless> personally, objID field
[13:44:02] <wjp> we can't store objIDs for fixed objects, so we'll just have to make sure we load those in the same range everytime
[13:44:17] <wjp> I think the original used 256-... for that
[13:44:44] <Colourless> glob handling is going to be interesting
[13:44:54] <wjp> yes
[13:44:56] <Colourless> that is glob eggs
[13:45:04] <wjp> glob egg = shape 2, right?
[13:45:07] <Colourless> yes
[13:45:14] <Colourless> the original game did move glob eggs around
[13:45:19] <wjp> I was considering subclassing Item to GlobEgg
[13:45:28] <wjp> it did? uh oh
[13:45:33] <Colourless> yeah it did
[13:45:43] <Colourless> catacombs did it all over the place
[13:45:52] <wjp> did it keep them in a 512x512 grid?
[13:46:01] <Colourless> as far as I can tell, yes
[13:46:19] <wjp> ah, for skull of quakes, crumbling floors, ... things like that?
[13:46:27] <Colourless> yes the skull
[13:46:33] <wjp> ok, so we could just add the glob egg as 'just another item'
[13:46:39] <Colourless> and also ghouls coming out of tombs
[13:47:16] <wjp> does it just change the glob number of a glob egg there?
[13:47:19] <Colourless> now, handling glob eggs wouldn't really be an issue. when rendering, just get all the glob items, when doing collision detection, do the same as well
[13:47:30] <Colourless> the problem is, what does usecode do
[13:47:55] <Colourless> do the objects really exists... if so, what is their number
[13:47:57] <wjp> yes... does it expect the contents of a glob to 'exist'?
[13:48:05] * wjp nods
[13:48:17] <wjp> I would expect the answer is no
[13:48:41] <Colourless> me too. you'd think they would be classed as 'fixed' items
[13:48:53] <wjp> but fixed items do have IDs
[13:48:57] <Colourless> yeah
[13:50:51] <Colourless> who knows, perhaps we could create 'fudged' ids, if required. something like (GlobEgg->objID << 13) | item->IndexInGlob or some such hacky stuff
[13:51:00] <Colourless> that of course wouldn't really work :-)
[13:51:21] <Colourless> IndexInGlob would be 'too' large and we'd overflow 16 bit
[13:52:07] <Colourless> we could alternatively do something like containers
[13:57:29] <wjp> how persistent are changes to glob eggs?
[13:58:06] <wjp> I guess they won't get saved directly
[13:58:23] <Colourless> if the globegg is in nonfixed, the changes are permanent, but as for the objects in them, i don't even know if they can be modified
[13:58:59] * wjp nods
[13:59:10] <wjp> I would expect not
[13:59:31] <wjp> from what I saw from the gumps, they don't really have any 'interesting' objects in them
[14:00:11] <Colourless> you mean globs?
[14:00:15] <wjp> ack, yes
[14:00:31] <Colourless> no, don't think they even had trees
[14:01:40] <wjp> what about the big mushrooms in some globs?
[14:01:52] <wjp> did they display a name when you clicked them?
[14:02:14] <Colourless> don't think so
[14:03:09] <Colourless> actually, they do have trees
[14:03:15] <Colourless> and you can click and get names
[14:03:31] <wjp> ok... so the objects do exist for usecode to some extent
[14:04:18] <wjp> we could give items a temporary objID when usecode is called on them
[14:05:08] <Colourless> how would you generate the number though?
[14:05:23] <wjp> just any free objID?
[14:05:40] <wjp> (like how we would assign objIDs to newly created items)
[14:05:46] <Colourless> there is a problem with that though
[14:06:06] <Colourless> how do you know when to release the number, if ever
[14:06:36] <Colourless> the objID could be passed to other processes
[14:06:47] <wjp> we could assume it won't be
[14:06:57] <Colourless> no
[14:07:36] <wjp> there's a problem with saving it too, btw
[14:07:39] <Colourless> that is a bad idea
[14:08:07] <wjp> if you save while a process with the ID is running and then load, things will break
[14:08:09] <-- Kirben has left IRC (Read error: 104 (Connection reset by peer))
[14:08:11] <wjp> so temp objID won't work :-)
[14:08:43] <wjp> assigning a permanent ID has the same problem that you can't really save it
[14:09:38] <Colourless> you could 'sort of' do it. the item doesn't really need to exist in the world
[14:09:58] <Colourless> just all of it's info needs to be correct as if it were in the world
[14:10:46] <wjp> how many extra objIDs would we need if we give all items from all globs an ID?
[14:10:51] <wjp> (in a single map, of course)
[14:10:55] <Colourless> i don't really want to know
[14:11:08] <Colourless> as a guess, we might run over 64k
[14:11:20] <Colourless> some globs have lots and lots of items
[14:11:22] <wjp> yeah, I'd expect that to happen in the larger maps too
[14:11:33] <wjp> how about only the items which have usecode?
[14:11:47] <Colourless> that, i don't know. not many i would guess
[14:16:30] <Colourless> then something else to think about. what happens if the globnumber changes (shouldn't, but it could since the number is set in the 'q' value)
[14:18:36] <wjp> for a nonfixed glob it wouldn't be a problem, I guess
[14:18:40] <wjp> for a fixed one it would be
[14:19:17] <Colourless> well, i'm talking about if an item in the glob has an active proces, and the glob changes type
[14:19:40] <Colourless> one solution to this problem could be just to give all the items the 'globeggs' objID
[14:21:03] <wjp> the same problem exists when you delete an item that still has an active process running
[14:21:25] <wjp> not much you can do about it, I guess
[14:21:51] <wjp> maybe do something with the 'process exclusive' flag in usecode
[14:22:30] <Colourless> i already konw what that does :-)
[14:22:40] <wjp> giving all items the globegg's ID kind of defeats the purpose of an ID, doesn' it?
[14:22:55] <wjp> s/n'/n't/
[14:23:13] <Colourless> process exclusive flags a function as only being able to be run 1 at a time for a specific object
[14:23:53] <Colourless> perhaps
[14:24:38] <Colourless> i can't see any of the glob objects doing anything fancy usecode wise, and when executing uc functions it might not cause a problem
[14:25:03] <wjp> but even simple things such as item->bark need the right ID
[14:25:43] <wjp> I guess the original had an advantage here by not needing an ID, but simply a pointer
[14:26:06] <Colourless> yeah
[14:32:00] <wjp> brb, going to get some coffee
[14:32:04] <wjp> want some too? ;-)
[14:32:15] <Colourless> um no
[14:40:33] <wjp> b
[14:40:44] <Colourless> wb
[14:40:54] * wjp is kind of stumped by this glob/objID issue
[14:45:38] <wjp> any ideas on how to handle 'simple' deleting of items? (wrt usecode still having pointers to it)
[14:45:51] <wjp> one way would be to not recycle objIDs
[14:46:32] <wjp> (but there's an obvious problem with that as we don't have infinitely many)
[14:48:03] <Colourless> well, just keep incrementing the objIDs till we are out, then start again from the beginning
[14:48:16] <wjp> and hope the time elapsed has been large enough?
[14:48:30] <wjp> I don't really expect any problems, no
[14:49:44] <Colourless> i wouldn't
[14:51:09] <-- DarkeZzz has left IRC (capek.freenode.net irc.freenode.net)
[14:51:26] <wjp> hm, almost 4pm
[14:51:35] <wjp> I need to go attend some talk
[14:51:45] <Colourless> hm, almost 1:30 am... :-)
[14:51:50] <wjp> :-)
[14:52:06] <wjp> so you'll be gone in an hour?
[14:52:21] <wjp> (seeing how you're keeping almost normal hours these days :-) )
[14:52:21] <Colourless> we'll see
[14:52:38] <wjp> anyway, bbl :-)
[14:54:04] <Colourless> k
[15:03:30] --> Dark-Star has joined #pentagram
[15:12:26] <-- Colourless has left IRC ("casts invisibility")
[15:12:31] --> DarkeZzz has joined #pentagram
[15:50:13] <-- Dark-Star has left IRC ("Leaving")
[15:58:05] <wjp> back
[16:02:53] <-- wjp has left IRC ("bbl")
[17:11:00] <DarkeZzz> The other alternative is to increase the size of the ID namespace to 24 or 32 bits, which would no doubt cause other problems much harder to solve. *grin*
[18:47:48] --> wjp has joined #pentagram
[18:47:48] --- ChanServ gives channel operator status to wjp
[19:03:53] <-- DarkeZzz has left IRC (Read error: 110 (Connection timed out))
[21:02:31] --> Dark-Star has joined #pentagram
[21:58:25] <Dark-Star> aaargh what's that? "cvs [update aborted]: recv() from server cvs.pentagram.sourceforge.net: EOF"
[21:59:26] <wjp> hm, weird
[21:59:44] <wjp> I've been having connection problems to the exult.sf.net website most of the day, though
[21:59:49] <wjp> maybe the same problem
[22:00:04] <wjp> nothing new in pentagram cvs since this weekend, btw
[22:00:22] <wjp> expect more commits starting tomorrow evening :-)
[22:03:57] <-- wjp has left IRC ("Zzzz...")