#pentagram@irc.freenode.net logs for 24 Nov 2010 (GMT)

Archive Today Yesterday Tomorrow
Pentagram homepage

[00:57:33] <-- jvlee has left #pentagram
[04:28:44] <-- Colourless has left IRC (Read error: Connection reset by peer)
[04:34:27] --> Colourless has joined #pentagram
[04:34:27] --- ChanServ gives channel operator status to Colourless
[07:11:10] --> jvlee has joined #pentagram
[07:40:40] <-- jvlee has left #pentagram
[12:55:06] <-- Kirben has left IRC ()
[20:52:00] <wjp> ugh, this sorcery/objid issue is annoying
[20:52:25] <wjp> object IDs >= 0x8000 (for the focus specifically) break sorcery...
[20:53:27] <wjp> the usecode function that checks for a focus returns either the object ID or 0 or 1 for errors, and it does a 'ret < 2' check (signed) to see if there's an error
[20:58:49] <wjp> restricting all object IDs to < 0x8000 would theoretically be possible, but will break the current GameMapGump::dumpMap because some maps have more objects than that, and would only fix new games
[21:10:42] <Colourless> could just implement a 'fixup'
[21:11:09] <Colourless> either in the opcode when executing for the function make it unsigned, or a runtime patch for the usecode file
[21:12:47] <wjp> I wonder if it's a problem in other locations
[21:12:58] <Colourless> might well be
[21:13:35] <Colourless> i could imagine key of the caretaker might have a similar check
[21:13:57] <Colourless> though i don't know why such a check is even needed
[21:15:09] <wjp> just checked it; that one's just counting reagents
[21:15:37] <wjp> (or at least that's how it appears at a glance)
[21:17:57] <wjp> coordinates, attributes, time, frame, flags, ... lots of lt opcodes
[21:21:38] <Colourless> i'm thinking that we should change the id allocator so it will only now allocate new ids less than 32768. Old saves games if they have ids greater than that should still run, but may have issues like that one pop up
[21:22:09] <Colourless> we could also have a flag in the allocator to temporarily allow all ids to be allocate for GameMapGump::dumpMap
[21:23:12] <wjp> this sounds familiar somehow. Did we do this before for process IDs maybe?
[21:23:55] <wjp> (not that it's particularly relevant)
[21:24:10] <wjp> but, yes, limiting it is probably best in the long run
[21:24:42] <wjp> we need to fix dumpMap so that it doesn't "hog" the IDs, though, which it currently does
[21:24:56] <wjp> (not sure why, but the number of object IDs in use is huge after dumpMap)
[21:26:54] <Colourless> we could also change think so certain category of objects can be allowed ids greater than 32768 (such as glob egg spawned items, gumps)
[21:27:05] <Colourless> s/think/things/
[21:27:43] <wjp> true; could get a bit tricky though
[21:27:57] <Colourless> aye might overly complicate things
[21:33:24] <wjp> we may want to rework dumpMap anyway... setWholeMapFast might have some rather nasty side-effects
[21:35:35] <Colourless> dumpMap really should using a chunking algorithm to do it
[21:36:43] <Colourless> set an reasonable sized area fast, unset everything else fast, dump that, move across a bit, and repeat
[21:37:01] <wjp> yeah, I was a bit lazy :-)
[21:37:31] <wjp> but it'll still have side-effects when items become fast
[21:37:53] <Colourless> it coudl trigger usecode that should be triggered
[21:38:10] <Colourless> should possibly filter things for it....
[21:38:21] <Colourless> only really want globeggs fast
[21:38:39] <wjp> that might work
[21:38:39] <Colourless> though in catacombs might need some usecode triggered
[21:38:45] <wjp> ah, true
[21:39:28] <wjp> the lazy options would be killing dumpMap entirely or making it a command-line option that doesn't actually load/save a game
[21:40:12] <Colourless> an alternative option would be to make it save a game, dump the map, the load the savegame
[21:40:29] <wjp> good idea
[21:41:19] <wjp> that combined with chunking should fix any issues
[22:10:15] <-- Colourless has left IRC (Quit: casts improved invisibility)
[22:18:58] --> Colourless has joined #pentagram
[22:18:58] --- ChanServ gives channel operator status to Colourless
[23:10:41] --> Kirben has joined #pentagram
[23:10:41] --- ChanServ gives channel operator status to Kirben
[23:42:10] <wjp> oh, this exposed a bug
[23:42:48] <wjp> when loading AudioProcess it accesses the ObjectManager via playSFX, even though objects haven't been loaded yet
[23:44:43] <wjp> only for the lvol/rvol it seems
[23:54:32] <watt> Is it necessary to worry about the side effects of dumping the map if we create a save before it and restore after?
[23:56:48] <wjp> no
[23:57:00] <wjp> but Colourless only mentioned that idea _after_ worrying ;-)
[23:59:19] <watt> I was actually looking at both the minimap and dump map code recently. It would probably be nice to separate it from their gumps if at all possible