#pentagram@irc.freenode.net logs for 16 Jul 2003 (GMT)

Archive Today Yesterday Tomorrow
Pentagram homepage

[00:03:16] <-- Dark-Star has left IRC ("ZZZzzz...")
[00:08:45] <-- DarkeZzz has left IRC (vinge.freenode.net irc.freenode.net)
[00:09:17] --> DarkeZzz has joined #pentagram
[00:12:15] <-- DarkeZzz has left IRC (vinge.freenode.net irc.freenode.net)
[00:12:50] --> DarkeZzz has joined #pentagram
[00:52:50] <-- Fingolfin has left IRC ("42")
[02:12:45] --> Kirben has joined #pentagram
[02:12:45] --- ChanServ gives channel operator status to Kirben
[05:56:41] <-- Kirben has left IRC (vinge.freenode.net irc.freenode.net)
[05:56:50] --> Kirben has joined #pentagram
[06:00:32] <-- DarkeZzz has left IRC (vinge.freenode.net irc.freenode.net)
[06:00:44] --> DarkeZzz has joined #pentagram
[08:39:47] --> servus has joined #pentagram
[08:58:56] --> wjp has joined #pentagram
[08:58:56] --- ChanServ gives channel operator status to wjp
[08:59:04] --- wjp is now known as wjp|busy
[09:01:58] --> Dark-Star has joined #pentagram
[10:52:53] <-- servus has left IRC ()
[10:53:22] --> Cashman has joined #pentagram
[11:24:51] <-- Cashman has left IRC ()
[13:06:07] --> Colourless has joined #Pentagram
[13:06:07] --- ChanServ gives channel operator status to Colourless
[13:06:45] <Colourless> hi
[13:25:51] <wjp|busy> hi
[13:28:25] <-- Kirben has left IRC (Read error: 54 (Connection reset by peer))
[13:28:29] --> Kirben has joined #pentagram
[13:36:25] <wjp|busy> Colourless: how's the AskGump issue going?
[13:43:55] <wjp|busy> hmm.. keyrings seem to be a bit broken :-)
[13:44:11] <wjp|busy> I'll have to take a look at those when I get home
[14:01:18] <-- Dark-Star has left IRC ()
[14:26:28] <Colourless> i don't even know why it's broken. i didn't touch it
[14:26:49] <Colourless> probably something really simple
[14:30:50] <Colourless> but i don't even know where to look for it
[14:32:41] <Colourless> hmm, even barkgumps are broken
[14:33:09] <Colourless> i'm guessing then it's ItemRelativeGump that is broken
[14:38:17] <Colourless> hmm, maybe not...
[14:41:05] <wjp|busy> in which way is it broken?
[14:41:39] <Colourless> it's not
[14:42:19] <Colourless> as far as I can tell. I tried talking to vividos and it didn't even call I_bark
[14:42:35] <wjp|busy> hm
[14:42:44] <wjp|busy> does it work when you 'f'?
[14:43:18] <Colourless> i'll try, but i've been having issues everywhere
[14:43:26] <wjp|busy> I've had it happen occasionally that double clicking vividos didn't work
[14:44:06] <Colourless> hmm
[14:44:17] <Colourless> I press 'f' and the avatar doesn't even get up a second time
[14:44:21] <wjp|busy> hmm
[14:44:35] <wjp|busy> going home; brb
[14:44:39] <-- wjp|busy has left IRC ("brb")
[15:03:42] --> wjp has joined #pentagram
[15:03:42] --- ChanServ gives channel operator status to wjp
[15:20:00] <wjp> any news?
[15:20:25] <Colourless> ni
[15:20:36] <Colourless> does it work for you?
[15:22:42] <wjp> 'f' works fine here
[15:23:10] <Colourless> enabling usecode output suggests it's not recovering from suspends
[15:23:35] <wjp> you can get number of processes with 't', btw
[15:23:41] <wjp> is that suspiciously high?
[15:24:56] <-- Kirben has left IRC (Read error: 60 (Operation timed out))
[15:25:14] <Colourless> they keep going up and up and up
[15:25:32] <Colourless> at last push:
[15:25:32] <Colourless> Processes : 744/32765
[15:25:39] <wjp> that's rather a lot
[15:25:45] <Colourless> now:
[15:25:46] <Colourless> Processes : 1204/32765
[15:26:20] <Colourless> and now:
[15:26:21] <Colourless> Processes : 2136/32765
[15:27:08] <wjp> umm.. :-)
[15:27:08] <Colourless> what have i done to my code
[15:27:21] <Colourless> Processes : 4015/32765
[15:27:36] <Colourless> that's like 2000 a minute :-)
[15:27:53] <Colourless> or 1 process a frame
[15:27:54] <wjp> if you want you can commit it and we can look at it together
[15:28:10] <Colourless> i might try diff
[15:28:23] <Colourless> on the usecode an kernel dirs to see if i changed something obvious
[15:28:47] <Colourless> first though, i'm going to let it get to 32k processes to see pentagrams behaviour :-)
[15:30:43] <wjp> something like *kaboom* probably :-)
[15:31:55] <Colourless> gee, only 2 lines added... i wonder if that is the problem
[15:32:05] <Colourless> // Don't count us, were are not really here
[15:32:06] <Colourless> if (p->terminate_deferred) continue;
[15:32:24] <wjp> where's that?
[15:32:29] <Colourless> in Kernel::getNumProcesses
[15:32:30] <wjp> (is that variable initialized?)
[15:32:39] <wjp> uh, in getNumProcesses?
[15:32:49] <wjp> I wonder how that would cause this
[15:35:08] <Colourless> that wasn't the problem would you believe
[15:35:21] <Colourless> i removed the line and it was still doing it
[15:38:02] <wjp> try defining DUMP_PROCESSTYPES in Kernel.cpp
[15:38:10] <wjp> (and see what happens when you use 't')
[15:38:27] <Colourless> yeah
[15:38:30] <Colourless> good idea
[15:38:45] <Colourless> i was going to breakpoint addProcess to see what processes were being added
[15:38:59] <Colourless> but... that seems a little 'easier'
[15:40:00] <Colourless> what the...
[15:40:01] <Colourless> CameraProcess: 56
[15:41:04] <Colourless> that's not good
[15:43:05] <Colourless> but i don't know 'why' it would be doing that
[15:43:50] <Colourless> uh, yes i do
[15:43:59] <Colourless> oops :_)
[15:44:19] <Colourless> i added CameraProcess::Terminate and I didn't make it call Process::Terminate
[15:44:26] <wjp> ah :-)
[15:44:48] <Colourless> it's going to crash any minute now
[15:44:49] <wjp> so that stops everything that's waiting for a camera
[15:45:50] <Colourless> well, it didn't crash
[15:46:00] <Colourless> it just keeps outputting Unable to allocate id
[15:46:22] <Colourless> and things like:
[15:46:23] <Colourless> Trying to access segment 0
[15:46:23] <Colourless> Process 0 caused an error. Killing process.
[15:47:29] <wjp> internal segfault :-)
[15:47:42] <Colourless> yeah
[15:47:57] <Colourless> pentagram handles them just as gracefully as every operating system
[15:48:05] <Colourless> i think we should make pentagram coredump too :-)
[15:48:23] <Colourless> i.e. dump the entire map to a file, then every process including stack....
[15:48:26] <wjp> it's actually not a bad idea
[15:48:28] <Colourless> in otherwords make a save game :-)
[15:48:34] <wjp> yes :-)
[15:49:24] <wjp> it wouldn't capture the exact moment of the error, though
[15:49:40] <wjp> (in which process it was, and what it was doing)
[15:49:56] <wjp> ideally it would save just before executing the guilty process :-)
[15:49:59] <Colourless> it could be modified to
[15:50:28] <Colourless> that is' when dumping kernel make it output which process was currently running
[15:50:50] <Colourless> yeah. 'F' works! :-)
[15:51:49] <Colourless> hmm, now though, i have yet another curious problem to fix :-)
[15:52:42] <Colourless> i opened the basket next to the bedroll at the start, and the mushroom in side started flying round the screen
[15:52:55] <Colourless> ok, it's not just happening with those items
[15:53:09] <wjp> uh?
[15:53:17] <wjp> that's kind of weird :-)
[15:53:23] <Colourless> the items in any gump (other than avatars backpack) fly around the screen
[15:53:25] <wjp> is it falling or something?
[15:53:39] <Colourless> i can't actually tell it's so fast
[15:53:49] <Colourless> you know, multiple of every item
[15:53:55] * wjp wonders if making an item fall() inside a container have that effect
[15:54:01] <wjp> s/have/would have/
[15:54:21] <Colourless> it shouldn't
[15:55:39] <Colourless> fall modifies z
[15:55:45] <Colourless> this 'seems' to be a y problem
[15:56:14] <wjp> does it happen as soon as you open the container?
[15:57:54] <Colourless> hmm, running a debug build doesn't even show the items
[15:58:27] <Colourless> uninitialized var perhaps
[15:59:23] <Colourless> of course this code is not ready to be committed, seeing that i'm getting npcs appearing in the wrong maps
[15:59:43] <Colourless> i had 'forgotten' about that
[16:00:25] <Colourless> of course it's not just any npcs' it's only the palace guards and bentic
[16:23:36] <Colourless> uh :-)
[16:23:38] <Colourless> foolish me
[16:24:06] <Colourless> Actor::teleport probably shouldn't call 'move' if the actor isn't being teleported in this map
[16:28:06] <wjp> um, no :-)
[16:36:29] <Colourless> now to fix busted containers
[16:36:45] <Colourless> if i add an item to a container it works fine
[16:38:54] <Colourless> hmm, first thing. You are not supposed to be overloading Gump::Paint
[16:39:00] <Colourless> which ContainerGump does
[16:39:18] <Colourless> you 'should' be overloading Gump::PaintThis
[16:39:33] <Colourless> but that's not relevant to this
[16:43:28] <Colourless> ok, this would explain the gump problem :-)
[16:43:51] <Colourless> parent is not being set for the items when they are created from the u8 data
[16:44:13] <Colourless> getGumpLocation then doesn't return anything
[16:54:00] --> Fingolfin has joined #pentagram
[16:54:00] --- ChanServ gives channel operator status to Fingolfin
[16:56:18] <Colourless> wjp, if PaintThis() was used instead of Paint() the gumpToParent() calls are not required
[16:56:32] <Fingolfin> hiya
[16:56:40] <Colourless> hi
[17:24:42] <wjp> uh, ah
[17:24:49] <wjp> oops :-)
[17:26:20] <-- Fingolfin has left IRC ("42")
[17:26:58] <Colourless> ok, all problems fixed
[17:27:03] <Colourless> this is all ready to go
[17:31:22] <Colourless> committing this many files is always fun
[17:31:35] <wjp> :-)
[17:35:28] <Colourless> and most of this, just to get the skull of quakes to work :-)
[17:35:53] <wjp> well.......
[17:36:10] <wjp> it might have some other good side-effects ;-)
[17:36:21] <Colourless> ok, done... committed
[17:36:29] <Colourless> oh, save games are broken people :-)
[17:36:56] <Colourless> probably the only required update is for current map to save it's fast area info
[17:37:36] <Colourless> no substantial changes were made to much of anything else
[17:38:53] <Colourless> out glob hacks were removed
[17:38:55] <Colourless> yay!
[17:38:59] <Colourless> s/out/our/
[17:39:11] <wjp> we had glob hacks? *innocent look* ;-)
[17:39:30] <Colourless> exactly
[17:39:42] <Colourless> also, we have save games? :-)
[17:40:27] <wjp> we may have had those at some point in the past :-)
[17:40:40] <Colourless> too all those out there that didn't think we do, don't you read the cvs-logs emails? It would be 'so' obvious to anyone they there is something resembling savegame support
[17:41:14] <Colourless> s/they/that/
[17:41:26] * wjp gets to work on the build errors :-)
[17:42:10] <wjp> ethereal is now a list?
[17:42:18] <Colourless> yes
[17:42:52] <Colourless> you can now remove items from the list no matter where they are. you don't 'have' to pop them
[17:43:22] <Colourless> it makes things 'easier' when moving a item from ethereal
[17:43:58] <wjp> world/GravityProcess.cpp:111: warning: right shift count >= width of type
[17:43:59] <Colourless> move and moveToContainer can be used on an item in the ethereal list without anything special done first
[17:44:03] <wjp> (several times)
[17:44:25] <wjp> umm... you're shifting _how far_? :-)
[17:44:25] <Colourless> ok... lets see
[17:44:31] <wjp> ty = iy + ((yspeed*scale)>>0x2000);
[17:44:48] <Colourless> hmm
[17:44:51] <Colourless> ok...
[17:45:22] <wjp> uint16384 ty? :-)
[17:45:39] <Colourless> that should be /
[17:45:41] <Colourless> not >>
[17:46:04] <wjp> are the scale = ... above those correct?
[17:46:04] <Colourless> i think i was going to change it to >>11
[17:46:10] <Colourless> but 'half' did it
[17:46:24] <Colourless> no. i don't think so
[17:46:54] <Colourless> they should be <<
[17:47:13] <Colourless> that code just looks wrong though....\
[17:48:18] <Colourless> ah, just delete that code
[17:48:27] <Colourless> it's 'broken'
[17:48:50] <Colourless> or #ifdef it out till i fix it
[17:53:22] <wjp> hm, crumbling floors in the catacombs look better but still aren't entirely correct
[17:53:42] <Colourless> yes, their problem is something else
[17:54:15] <Colourless> it looks like incorrect frames are being used
[17:54:34] <Colourless> i haven't attempted to look at exactly what the usecode is attempting to do
[17:56:52] <wjp> skull of quakes sequence seems to be working, but for some reason the teleporters there don't
[17:57:11] <Colourless> the eggs check for z ==
[17:57:25] <Colourless> so you need to be on the floor for it to work
[17:57:58] <wjp> ok
[17:58:11] <Colourless> if you press 'c'
[17:58:21] <Colourless> then go down the stairs, you'll trigger the eggs
[17:59:01] <wjp> but I guess once I screw it up it won't work until I leave the map? :-)
[17:59:37] <Colourless> nope. i forgot to mention eggs now get reset when you leave the fast area
[17:59:44] <wjp> ok
[17:59:50] <Colourless> one problem, i think my fast area is too large
[18:00:16] <Colourless> i'll make it a bit smaller 'soon'
[18:00:26] <wjp> I wonder... if you jump over the teleporter on the main catacombs floor, does that trigger the egg?
[18:00:45] <Colourless> the way i work out if a chunk is fast isn't ideal yet
[18:00:55] <Colourless> i don't know. pentagram might be triggering it
[18:01:10] <Colourless> it seems to be triggering some things when perhaps it shouldn't
[18:01:16] <Colourless> all z related
[18:04:02] <wjp> ok, let's get saving working again :-)
[18:04:14] <Colourless> well, it works
[18:04:25] <Colourless> and loads too
[18:04:37] <Colourless> but just the fast area isn't save
[18:04:41] <Colourless> d
[18:06:37] <wjp> hm, did you update savegame.txt with what you changed?
[18:07:01] <Colourless> hmm, no
[18:07:17] <Colourless> i keep forgetting about that file
[18:07:40] <wjp> did you change anything other than Item?
[18:07:56] <Colourless> yes i did
[18:08:02] <Colourless> GUIApp and CameraProces
[18:08:03] <Colourless> s
[18:08:05] <Colourless> Glob eggs
[18:08:19] <wjp> PaletteFader
[18:08:32] <Colourless> yes palettefader
[18:08:37] <Colourless> not cameraprocess
[18:08:48] <Colourless> i don't think any of the cameraprocess changes effected savegames
[18:09:27] <wjp> palettefader just did a s/float/uint16/?
[18:09:35] <Colourless> yes
[18:10:25] <wjp> bbl, dinner
[18:12:11] --> Dark-Star has joined #pentagram
[18:16:52] <Colourless> wjp that should be sint16
[18:26:11] <-- Colourless has left IRC ("bbl")
[18:32:32] <wjp> sint16, ok :-)
[20:20:37] --> Colourless has joined #Pentagram
[20:20:37] --- ChanServ gives channel operator status to Colourless
[20:21:02] <Colourless> b
[20:21:10] <wjp> wb
[20:24:46] <Colourless> hey, you didn't update the item saver to conditionally save gump :-)
[20:25:11] <Colourless> every k counts :-)
[20:31:50] <wjp> oh no! I forgot?!
[20:32:06] <wjp> however will pentagram survive!? *cough*
[20:32:44] <wjp> feel free to change it, btw ;-)
[20:35:55] <Colourless> might do it to 'gravity' too :-)
[20:36:06] <Colourless> i would need to add a flag though!
[20:36:36] <Colourless> it's not like we we don't have 20+ extended flags free though
[20:39:31] <wjp> actually, I economized on saving extendedflags a bit, so we only have 16-(number of used flags)
[20:41:23] <Colourless> well, if we need more in the future, we can update the version :-)
[20:49:40] <wjp> indeed :-)
[20:53:40] <Colourless> it saved 28 kb !!
[20:54:04] <Colourless> the savegame is 749 kb
[20:54:12] <Colourless> for the start of the game
[20:54:19] <Colourless> actually not quite 28 kb
[20:54:31] <Colourless> maybe 24 or something
[20:55:07] <Colourless> 773 before 749 after
[20:57:59] <Colourless> question, what do you do with the sint32 fast_x_min, fast_y_min, fast_x_max, fast_y_max;
[20:58:02] <Colourless> values?
[20:58:14] <Colourless> (from CurrentMap)
[21:00:33] <wjp> oh, I forgot those
[21:00:36] <wjp> just save them, I guess
[21:00:41] <wjp> unless you want to save 8 bytes?
[21:00:58] <wjp> ;-)
[21:01:07] <Colourless> well, they can be set to -1
[21:01:18] <Colourless> since they will just be regenerated
[21:02:40] <Colourless> though in reality, it doesn't actually matter what those values are set to.
[21:02:52] <Colourless> if they are wrong, they are regenerated
[21:02:59] <Colourless> if they are right nothing happens :-)
[21:03:40] <Colourless> all they are used to do is save time in CurrentMap::updateFastArea
[21:04:07] <Colourless> i'll just reset them, just to be sure
[21:04:52] <Colourless> you know, there really must be a better way of saving the free id. Kernel is taking up 64k, all of the just pids
[21:05:12] <Colourless> hell if i can think of one though
[21:06:03] <wjp> depends on how much of the idMan state we really want to save
[21:06:57] <wjp> we could store the first 1000 free ids, and store the rest as extents or something
[21:07:22] <Colourless> but if it becomes really fragmented, then that wont work greatly well
[21:07:53] <wjp> or restore the rest from the used ids
[21:08:06] <wjp> (will need some work to avoid the O(n^2) :-) )
[21:08:46] <Colourless> in theory, we only need to save the 'last' ones, and we can ignore the first 'n'
[21:09:06] <Colourless> since the id system is designed to use the most recently freed pids last
[21:11:38] <Colourless> what we 'could' do is this. on load set all pids to 0xFFFF. Load the last freed pids from the save games. The object and process loaders would set the actual used pids to 0. Then a second pass for idMan would add any 0xFFFF ids to the front of the free list
[21:13:12] --> Dominus has joined #pentagram
[21:13:22] <Colourless> saving pids wouldn't be difficult. Just need to iterate the entire list and find the 1000th to last id and save from there to the end
[21:13:39] <wjp> yeah, that was what I was thinking too
[21:13:41] <Dominus> hi
[21:13:47] <Colourless> hi
[21:13:51] <wjp> wouldn't you need the first to the 1000th?
[21:14:08] <wjp> oh, I see, depends on your perspective
[21:14:09] <Colourless> either way, it doesn't really matter
[21:14:38] <Colourless> you'd think that after 1000 pids that things wouldn't matter as far as reuse goes
[21:14:43] <wjp> you guarantee the 1000 last freed pids (if there are that many) will be used last
[21:14:48] <Colourless> first 1000 would be easier
[21:15:26] <wjp> hi Dominus
[21:15:28] <Colourless> using the first 1000 you would add any unused pids to the end of the list, rather than to the beginning with the last 1000
[21:15:35] <Colourless> (when loading)
[21:16:49] <wjp> hm, I still need to convert the usecode listheap/stringheap to idman
[21:17:59] <Colourless> hmm, first 1000 unused would actually probably be the best idea, as we could rough guess at the rest of the free pids
[21:18:50] <Colourless> it would generally be safe to assume that the general order of the unused it would be from the last saved free id to the highest id, wrapped around to 0, bad up to last saved id
[21:19:35] <Colourless> s/it/id/
[21:20:56] <Colourless> the reason that would mostly work is because in theory the first allocated id, would be the last freed
[21:24:40] <Colourless> s/last freed/first freed/
[21:29:21] <Colourless> time for me to go
[21:29:28] <Colourless> cya
[21:29:34] <Dominus> ciao
[21:29:57] <-- Colourless has left IRC ("casts invisibility")
[23:14:15] <-- Dark-Star has left IRC ()
[23:14:27] <-- Dominus has left IRC ("enough for now")
[23:51:40] <-- wjp has left IRC ("Zzzz...")