#pentagram@irc.freenode.net logs for 18 May 2003 (GMT)

Archive Today Yesterday Tomorrow
Pentagram homepage


[00:15:41] --> Kirben has joined #pentagram
[00:15:41] --- ChanServ gives channel operator status to Kirben
[00:20:31] <-- wjp has left IRC ("Zzzz...")
[02:37:56] --> Cashman has joined #pentagram
[02:38:10] * Cashman reads all the log entires after he went to sleep this morning!
[02:38:26] <Cashman> eeeh - ehhe I knew somthing was up with devon hiding from us!
[02:38:41] <Cashman> wjp broke that again - is devon not hiding now people!
[02:39:12] <Cashman> and what about cvs - I'll have a look just now - you are still committing all the source ovbiously - but are you committing binary for people as well?!
[02:39:27] <Cashman> do we really even have the fans yet for a binary committ - is it worth it
[02:39:48] <Cashman> you there kirben?? are you able to answer
[02:40:22] <Kirben> No snapshots until pentagram is playable a bit I guess.
[02:40:40] <Cashman> aaah I dont mean snap shows - I mean binary commit! .exe
[02:40:50] <Cashman> darkes been doing a lot with the cvs strcuture
[02:40:52] <Cashman> hehe
[02:41:57] * Cashman checks out Darkes mucking around - his efficiency
[02:43:26] <Cashman> yay it was the aniversary yesturday
[02:43:32] * Cashman claps
[02:43:35] <Cashman> 1 year
[03:03:39] <Cashman> l8er Kirben
[03:03:48] <Kirben> cya
[03:03:53] <-- Cashman has left IRC ()
[04:01:29] --> Cashman has joined #pentagram
[04:07:17] <-- Cashman has left IRC ()
[07:03:29] --> Cashman has joined #pentagram
[07:04:21] <Cashman> Hi
[08:58:43] --> Cash-man has joined #pentagram
[08:58:44] <-- Cashman has left IRC (Read error: 54 (Connection reset by peer))
[08:59:03] --- Cash-man is now known as Cashman
[10:52:34] --> Cash has joined #pentagram
[10:52:35] <-- Cashman has left IRC (Read error: 54 (Connection reset by peer))
[10:52:42] <Cash> eh hehe
[10:52:43] <Cash> ghosting
[10:52:47] --- Cash is now known as Cashman
[11:09:55] * Cashman downloads latest cvs
[11:43:53] --> wjp has joined #pentagram
[11:43:53] --- ChanServ gives channel operator status to wjp
[11:48:06] <Cashman> hehe I get like 45 fps compared to 25 fps when devon is walking off the map!
[11:48:17] <Cashman> just shows that you guys have much faster processor than mine
[11:48:37] <wjp> 25fps is plenty
[11:48:54] <wjp> and don't forget it'll go up a lot when the resolution is decreased
[11:48:58] <Cashman> pentagram continues to use like 92 % cpu useage but only uses 1.8mb ram! nice one!!
[11:49:09] <Cashman> yeah thats true
[11:49:28] <Cashman> yeah 25 is plenty - even less is ok if I remember you saying
[11:49:42] <wjp> 1.8Mb ram? that's almost impossible
[11:49:53] <Cashman> wait..
[11:49:55] <wjp> the screen buffer alone is 1.2Mb
[11:51:48] <wjp> pentagram is 13-14Mb here
[11:52:34] <Cashman> oh yeah its win32 - I have different stats showing in my process list
[11:52:43] <Cashman> like average mem and peak mem
[11:52:50] <Cashman> 14mb peak
[11:52:52] <Cashman> here
[11:53:02] <Cashman> smallest is like 3 mb
[11:53:12] <wjp> that was probably at startup :-)
[11:53:16] <Cashman> was 1.8
[11:53:17] <Cashman> yeah
[11:55:28] <Cashman> yeah peak useage 14 mb - but there is another mem useage option which says 1.8 to 2 mb when devon is off the map
[11:55:54] <Cashman> hmm I wonder if devon and other nps are going to need slowing down! they might be fine at this speed or close to it
[11:56:29] <Cashman> actually if they randomly move a lot then they might need to be slowed down slightly!
[11:57:20] <Cashman> nice to know that devon is no longer the invisible man!
[11:59:04] <Cashman> hows ur day been wjp
[11:59:26] <wjp> it just started :-)
[12:00:33] <Cashman> oh hehe thats right! ur not au
[12:00:39] <Cashman> what is is it
[12:00:56] <Cashman> ur about 12hrs diff from nz arn't u - well very close
[12:01:01] <Cashman> ?
[12:01:10] <wjp> a bit less probably
[12:01:14] <wjp> it's 2pm here
[12:01:32] <Cashman> its 1 am here now
[12:01:58] <Cashman> 2pm? you just woke up
[12:02:01] <Cashman> ?
[12:02:12] <Cashman> hehe sunday still for ya
[12:02:23] <wjp> well, not 'just', but I haven't really done anything so far
[12:03:08] <Cashman> yeah I get what u mean! sunday sunday sunday
[12:03:31] <wjp> :-)
[12:06:44] * wjp sighs... I really should start implementing item loops
[12:08:07] <Cashman> oh - some handling so we can move stuff
[12:08:13] <wjp> no
[12:08:18] <wjp> usecode stuff :-)
[12:08:29] <Cashman> ohh so jumping fish for example!?
[12:08:38] <wjp> no :-)
[12:08:52] <Cashman> hehe
[12:09:00] <wjp> this is for cases where usecode wants to do something with all items in a container
[12:09:14] <wjp> so it loops over all items
[12:09:20] <Cashman> oh ok
[12:10:02] <wjp> or all items in a small area
[12:10:11] <wjp> (like when you throw a burning flask somewhere :-) )
[12:10:18] <Cashman> hehe startreck on aus on again!
[12:10:26] <Cashman> oh the burning flask - my favourite
[12:10:29] <Cashman> ehhe
[12:10:30] <Cashman> and the darts
[12:10:34] <wjp> s/treck/trek/.. tsk tsk :-)
[12:11:00] <Cashman> heheh typos
[12:13:03] <Cashman> have you found the reason for devon moving the wrong way
[12:14:21] <wjp> well, it may actually be the right way
[12:14:27] <wjp> hard to remember
[12:15:16] <wjp> but I don't think we handle directions correctly atm
[12:16:08] <Cashman> hmm no he looked straight up at the docks I think - 180 degree turn - hehe even though there arnt shapes for handling all angles
[12:16:23] <wjp> there are 8 directions
[12:16:30] <wjp> all have shapes
[12:16:58] <Cashman> yeah
[12:17:45] <Cashman> eeeeh I meant frames for handling all angles per shape
[12:18:07] <Cashman> hehe - I should sleep soon
[12:18:10] <wjp> I'm pretty sure there are :-)
[12:18:52] <wjp> k, goodnight :-)
[12:20:00] <Cashman> hehe I mean you cant do 360 degree rotation like todays games - most of which use 3d modeling now anyways
[12:20:20] <Cashman> but that aint matter
[12:20:20] <Cashman> I like the old skool stuff
[12:20:30] <wjp> 8 directions is plenty :-)
[12:21:06] <Cashman> yeah it is
[12:21:17] <Cashman> well for this sorta game anyhows
[12:22:36] <Cashman> do you remember the map hacker for the crusader series! that was interesting! - hmm u8 had somthing like that I think
[12:23:34] <wjp> I never played crusader
[12:24:17] <Cashman> hehe what will be funny and interesting is if you leave the triggers visible - of course they probably only going to get handled as invis much l8er on
[12:24:46] <Cashman> oh ok! I loved the crusaer series and those cut scenes man they were great
[12:24:48] <wjp> it doesn't really matter if we paint them or not
[12:25:21] <Cashman> sb-x is another big fan - completed both without cheats hehe only on muma's boy - lowest difficulty
[12:26:17] <Cashman> nah it doesnt - eh because they are fixed items - thats gotta be easy for ya
[12:26:37] <Cashman> dont have to have them with da nonfixed stuff
[12:27:15] <Cashman> handling nonfixed stuff sounds hard - easy for u?
[12:27:44] <wjp> why would it be hard?
[12:30:12] <Cashman> eh well I aint thinking - just sounds diff?
[12:30:59] <Cashman> just storing them as tmp with key information for each e.g. x:y:z and other attributes
[12:31:25] <Cashman> ah hehe - I should stop talking
[12:31:54] <wjp> we store them exactly the same interally as fixed objects
[12:31:59] <wjp> s/interal/internal/
[12:32:09] <wjp> just load them differently
[12:32:34] <Cashman> what about usecode? are there many items which use usecode
[12:33:04] <wjp> nearly everything uses usecode, and usecode uses nearly everything :-)
[12:33:24] <wjp> usecode is (arguably) the core of the game
[12:33:36] <Cashman> so drinking out of a bottle e.g. for saying its empty or burrp
[12:33:39] <Cashman> yeah
[12:33:41] <Cashman> true
[12:35:53] <Cashman> but say for instance the bottle next to the guard
[12:37:44] <Cashman> e.g. bottle full or empty - does u8save.000 contain pre info for playing the game for the first time
[12:38:15] <wjp> usecode uses one of the data fields on the bottle object to store if it's full or empty
[12:38:28] <wjp> and that data field is indeed stored in u8save.000
[12:39:10] <Cashman> aah so just datafields for da object - tmp
[12:39:34] <Cashman> so if you wanted to make a saved game - it would basically be the lines of u8save.000 in structure
[12:39:39] <Cashman> ?
[12:39:51] <wjp> no, it'll have to be more complex
[12:40:10] <wjp> we also have to save all running processes
[12:40:30] <Cashman> ok so u8save.000 is kinda like a saved game but only simple handling of that idea
[12:40:38] <Cashman> true!
[12:41:57] <Cashman> but e.g. devons moving around is hardcoded right!
[12:42:07] <Cashman> generally speaking
[12:42:15] <wjp> yeah, probably
[12:42:56] <wjp> we're not too sure yet about AI, schedules, etc..
[12:43:04] <Cashman> hehe might be fun comming up with ideas - creativeness for that sorta thing
[12:43:10] <Cashman> if it is hardcoded
[12:44:29] <Cashman> hehe imagine devon or beren doing random tricks with there majic
[12:45:15] <Cashman> I'll have to try and get u8 working under windows with that patch again!
[12:45:25] <Cashman> and play and get the feel again
[12:54:09] --- Cashman is now known as CashZzz
[12:55:26] <-- CashZzz has left IRC ()
[13:07:06] <Kirben> hmm what am I missing ?
[13:07:07] <Kirben> g++ -mwindows -o disasm.exe tools/disasm/Disasm.o tools/fold/CallNodes.o tools/fold/Folder.o tools/fold/FuncNodes.o tools/fold/IfNode.o tools/fold/OperatorNodes.o tools/fold/Type.o tools/fold/VarNodes.o filesys/FileSystem.o filesys/Flex.o filesys/U8Save.o misc/Args.o misc/Console.o misc/pent_include.o misc/Q_strcasecmp.o misc/util.o -mconsole
[13:07:08] <Kirben> tools/disasm/Disasm.o(.text+0xa374):Disasm.cpp: undefined reference to `Args::process(int, char**)'
[13:08:31] <wjp> hm, Darke has gone a little overboard with const's there maybe :-)
[13:08:43] <wjp> void Args::process(const sint32 argc, const char * const *argv) :-)
[13:09:34] <wjp> still should work though
[13:09:46] <wjp> is this from a clean build?
[13:10:12] <Kirben> yes
[13:11:26] <Kirben> wait, maybe not.
[13:23:42] <Kirben> works now, I should have done an allclean instead of just clean.
[13:28:25] --> Colourless has joined #Pentagram
[13:28:25] --- ChanServ gives channel operator status to Colourless
[13:28:53] <wjp> Kirben: *phew* :-)
[13:28:57] <wjp> hi
[13:35:27] <wjp> loop script stack sizes: 02: -34h, 03: -34h, 04: -28h, 05: -2Ah, 06: -3Dh
[13:36:29] <wjp> if we gather loop items right at the start, we'll only need about 4 bytes I guess (a list and a loop index)
[14:25:54] <wjp> hmm... no...
[14:26:00] <wjp> we need to store the loopscript too
[14:26:12] <Colourless> stictly speaking no you don
[14:26:13] <Colourless> t
[14:26:20] <Colourless> you can references it from the stack
[14:26:37] <wjp> but don't we have to pop it when 'loop' is executed?
[14:26:38] <Colourless> you just need to store pointer to the first element
[14:27:17] <Colourless> hmmm, good point
[14:27:36] <Colourless> i though that the script wasn't poped
[14:27:48] <wjp> I'm not sure
[14:29:46] <wjp> the add sp after the loop seems to be independent of loopscript size
[14:30:07] <Colourless> you are probably correct
[14:30:19] <Colourless> why specify the loop script size to the opcode
[14:30:40] <wjp> probably so you don't have to parse it immediately
[14:30:43] <Colourless> if it's not poped, it would sound suspiciously like some bound checking... such things didn't occur in ultima 8 :-)
[14:31:02] <wjp> hehe, good point :-)
[14:32:29] <wjp> this partially explains the large stack area size
[14:33:01] <Colourless> that would imply hard coded limit... yes makes perfect sense :-)
[14:33:08] <wjp> lol
[14:33:34] <wjp> limit is 34 bytes atm
[14:33:53] <wjp> but that'll go down when I think of more things to put on the stack :-)
[14:34:35] <-- Kirben has left IRC ("Sleep")
[14:34:43] <Colourless> just do you don't get any foolish ideas, remember to iterate objids not pointers
[14:34:54] <wjp> of course :-)
[14:35:01] <Colourless> :-)
[14:35:18] <Colourless> that should be the manta of Pentagram, ObjIDs NOT POINTERS!
[14:36:44] --- wjp has changed the topic to: Pentagram: a game engine for Ultima 8 - http://pentagram.sf.net/ - ObjIDs, NOT pointers!
[14:38:03] <Colourless> :-)
[14:40:08] <wjp> I wonder where these search functions belong
[14:40:26] <wjp> container searches should probably go into Container
[14:41:00] <Colourless> a area search, into map
[14:41:17] <wjp> makes sense
[14:41:52] <Colourless> surface search... probably into item
[14:41:55] <wjp> I'll just have them add item to a passed UCList
[14:41:58] <Colourless> actually no
[14:41:59] <wjp> s/item/items/
[14:42:09] <wjp> that way recursive searches will become easy too
[14:42:10] <Colourless> surface search should go into map too
[14:42:22] <wjp> yeah, you need to iterate over item lists
[14:42:30] <Colourless> yeah exactly
[14:42:39] <wjp> I wonder when an item is considered 'in range'
[14:42:57] <wjp> when the origin is close enough, or when any part of the bounding box is
[14:43:07] <wjp> and do you need a rectangular or a circular area...
[14:43:19] <wjp> choices choices... :-)
[14:44:11] <Colourless> for a surface search i was thinking when the objects boinding boxes are overlapping and if the surf.ztop == obj.zbot (if above) or surf.zbot == obj.ztop (if below)
[14:44:36] <Colourless> rectangular is easier
[14:45:03] <Colourless> circular would require a square root which i doubt they would have done
[14:45:32] <Colourless> my guess would be bounding box overlapping rectangular/square area
[14:45:48] <Colourless> if it proves to be wrong, it's not difficult to change
[14:46:53] <wjp> what's the max. size of a bounding box?
[14:47:21] <Colourless> 15*32 units for x and y and 15*8 units for z
[14:48:02] <wjp> ok, so you have to search at most one 'chunk' extra in each dir.
[14:48:16] <Colourless> yes which is nice
[15:08:26] <wjp> ugh
[15:08:32] <wjp> we don't need to store the loopscript at all
[15:08:41] <wjp> not when we gather all items in advance
[15:09:01] <Colourless> hehe, true :-)
[15:09:10] <wjp> OTOH, maybe we should recheck an item
[15:09:24] <Colourless> perhaps, perhaps not
[15:09:44] <wjp> I'm pretty sure the original gathered items on the fly
[15:10:04] <wjp> but that'll be messy
[15:12:30] <wjp> I'll just save the loopscript for now. (Since I already wrote the code... *sigh* :-) )
[15:23:47] <Colourless> Oh No!! My computer is currently broadcasting an IP address!! According to this window that came up someone could start attacking my computer....
[15:23:52] <wjp> OH NO!
[15:23:59] <wjp> mine isn't :-)
[15:24:06] <Colourless> strange, neither is mine :-)
[15:24:28] <wjp> nat too? :-)
[15:24:56] <Colourless> of course
[15:25:19] <wjp> oh, btw, the avatar stands up when FIRST is executed
[15:25:42] <wjp> at least, he does here :-)
[15:25:52] <Colourless> i'm not crazy. with the 'quetsionably' stability of my system due to my programming efforts, having my system connected to the internet isn't wise
[15:26:21] <wjp> yeah, I totally agree
[15:26:44] <wjp> having a system you use for any kind of experimenting directly online is asking for trouble
[15:27:53] <wjp> oh, press 'f' to trigger the first egg, btw
[15:28:03] <Colourless> ok
[15:28:04] <wjp> (really big hack, as usual... I hardcoded the objid it gets :-) )
[15:28:17] <Colourless> hehe
[15:28:28] <Colourless> it could change depending on game version you realize :-)
[15:28:37] <wjp> I don't care :-)
[15:28:39] <wjp> it works on mine ;-)
[15:29:10] <Colourless> as long as you are using english 2.12, i'm fine with that ;-)
[15:29:33] <wjp> you can easily check which objid your first egg has, I guess
[15:30:06] <wjp> if it's different you can use an #ifdef WIN32 to change it in Application.cpp :-)
[15:30:22] <wjp> if Darke's is different than mine we'll have to think of something else :-)
[15:30:26] <Colourless> #ifdef WJP_IS_A_HACK
[15:34:03] <wjp> so what's the difference between that and #if 1? :-)
[15:34:29] <Colourless> just depends on if it works or not :-)
[15:34:35] <wjp> ah :-)
[15:35:37] <Colourless> so, when is this hack being committed?
[15:35:46] <wjp> any specific hack?
[15:35:53] <wjp> the 'f' hack is already in
[15:36:01] <Colourless> the egg hack
[15:36:11] <wjp> if you want to see it do anything, you could have opcode 0x70 temporarily return 0
[15:36:18] <Colourless> not according to my sources...
[15:36:19] <wjp> hm, or maybe I didn't commit it
[15:36:30] <wjp> maybe it was too big a hack for even my standards :-)
[15:36:48] <wjp> case SDLK_f: { // trigger 'first' egg
[15:36:52] <wjp> Item* item = p_dynamic_cast<Item*>(World::get_instance()->getObject(21183)); // *cough*
[15:36:54] <wjp> item->callUsecodeEvent(7);
[15:36:59] <wjp> } break;
[15:37:42] <Colourless> my source still says no
[15:38:01] <Colourless> you 'could' have just iterated through all the items in that specfic 'chunk' and checked for the egg with the correct quality
[15:38:13] <wjp> sure :-)
[16:05:49] <wjp> ok... things seem to work
[16:06:06] <wjp> or at least loop is returning items to loop over :-)
[16:06:18] <wjp> (and it isn't infinitely looping, which helps too :-) )
[16:06:37] <Colourless> :-)
[16:06:50] <Colourless> does it clean up after finishing?
[16:07:19] <wjp> if loop/loopnext return false they also clean up
[16:07:32] <wjp> but they're counting on usecode to adjust the stack pointer
[16:07:34] <Colourless> good
[16:07:51] <Colourless> so do you have loop fall into loopnext?
[16:07:59] <wjp> no
[16:08:13] <wjp> it isn't that much code
[16:08:19] <Colourless> just wondering because it could be done
[16:08:29] <Colourless> you'd have loop setting up the object list
[16:08:49] <Colourless> it then falls into loop which gets the object an increments the list iterator
[16:12:30] <wjp> ah well, why not :-)
[16:23:43] <wjp> committed
[16:24:28] <Colourless> updating
[16:25:19] <wjp> I haven't done surface searches yet
[16:25:25] <wjp> won't be hard to add though
[16:25:40] <wjp> they're a pretty trivial extension to areaSearch()
[16:26:09] <Colourless> 'F' doesn't work properly... avatar doesn't get up
[16:26:40] <wjp> oh?
[16:26:59] <wjp> is the objid of your first egg the same as mine?
[16:27:29] <Colourless> i'm about to find out
[16:27:34] <Colourless> it does exec lots of usecode
[16:29:14] <wjp> hm, just got a segfault here
[16:29:30] <Colourless> what quality is the egg suppsed to have?
[16:29:49] <wjp> 36 here
[16:30:08] <Colourless> i'm getting 37
[16:30:38] <Colourless> and that is the wrong egg
[16:30:54] <Colourless> 37 is for FISHEGG
[16:31:09] <wjp> why not just click on the first egg to find its objid?
[16:31:48] <Colourless> my object is 22184
[16:32:11] <wjp> mine's 21183 :-)
[16:32:27] <wjp> off-by-1001?
[16:33:00] <Colourless> um, it seems to be changing every time i run the game....
[16:33:09] <wjp> huh?
[16:33:25] <Colourless> it's actually 21184
[16:33:41] <wjp> I didn't think there are any random elements in item loading
[16:33:58] <Colourless> i think i may have been looking at the wrong thing
[16:34:23] <Colourless> yes i think i accidently clicked on the ocean
[16:34:24] <wjp> press down arrow three times and it should be in the center of the screen
[16:34:30] <wjp> ah, k
[16:34:43] <Colourless> the number i got was in the 17 k range
[16:40:23] <wjp> hm, loop is causing a couple of invalid memory accesses
[16:40:56] <wjp> oh, silly me...
[16:41:17] <wjp> looks like I'm not sign extending an 8 bit number
[16:44:44] <Colourless> you do realize you are meant to remove the ! before an opcode name once you implement it :-)
[16:44:55] <Colourless> it was intended to indicate an unimplemented opcode :-)
[16:45:00] <wjp> realize, yes; remove it, no :-)
[16:45:29] <wjp> I like leaving them in for opcodes I'm experimenting with
[16:45:43] <wjp> makes it easier to spot them in large amounts of disassembly :-)
[16:46:15] <Colourless> ok
[16:46:23] <wjp> anyway, they're gone now
[16:46:29] <Colourless> this is also why i didn't remove them when i had the opportunity, i didn't think it was wise to remove them from possibly partially implemented opcode
[16:52:02] <wjp> does first work for you ok if you use the right objid?
[16:52:16] <Colourless> yes
[16:52:59] <wjp> it also seems to initiate conversation with Devon, but any evidence of that is long gone when things stop scrolling by :-)
[16:53:15] <Colourless> :-)
[16:54:08] <wjp> hm, weird
[16:54:20] <wjp> when you talk to Devon again after the first conversation
[16:54:26] <wjp> , he turns a bit
[16:54:43] <Colourless> yes he is supposed to turn to face you
[16:54:46] <wjp> ah, of course
[16:54:48] <Colourless> as are all npcs when you talk to them
[16:54:53] <wjp> and getDirTo(something) doesn't work yet
[16:55:12] <Colourless> i'm guessing that ... yes
[16:56:12] <wjp> ok, four intrinsics for that
[16:56:19] <wjp> getDirTo/FromCoords/Item
[16:56:31] <wjp> I guess those are next on the list, then :-)
[16:56:34] <wjp> anyway, dinner first; bbl
[16:56:40] <Colourless> k
[17:34:12] <wjp> I'm considering putting some 'magic' on the stack to recognize the start of loop data
[17:34:36] <wjp> right now we have no way of making sure SP is in the right place when loopnext is executed
[17:36:55] <Colourless> i'm thinking it should be
[17:37:03] <Colourless> why wouldn't it?
[17:37:04] <wjp> yeah, it should
[17:37:11] <wjp> usecode bugs? :-)
[17:37:21] <wjp> it's just to make it a bit more robust
[17:37:27] <Colourless> the compiler would have ensure that the stack is always cleaned up
[17:46:13] <wjp> heh, the avatar and Devon are turning away from eachother now :-)
[17:46:24] * wjp switches some terms
[17:49:31] * wjp hmms
[17:50:11] <wjp> some synchronization issues here it seems
[17:50:28] <wjp> Devon starts talking before the avatar has a chance to get up
[17:50:40] <wjp> which prevents the avatar from turning towards Devon
[17:55:08] <Colourless> i'm not surprised there are problems
[17:55:16] <wjp> neither am I :-)
[17:55:44] <wjp> there's animations, resetRef's, implies, etc... working together here
[17:57:23] <wjp> I'm getting a couple of "Non-existant process PID in implies" errors too
[17:59:53] <wjp> huh? process 1 is making process 4 wait for process 6?
[18:00:23] <wjp> I hope not...
[18:00:45] <Colourless> yeah such things happen
[18:01:16] <wjp> it should work
[18:01:23] <wjp> but I don't think that's what's supposed to happen
[18:02:25] <wjp> FIRST::107
[18:03:01] <wjp> if I read things properly, that implies should get pid and retval
[18:03:11] <wjp> (pushed at F4 and 106 resp.)
[18:03:35] <wjp> spawn should probably pop the this pointer
[18:03:56] <wjp> I thought it already did
[18:04:06] <Colourless> look at a8
[18:04:15] <wjp> but I may have screwed that up when I re-arranged spawns last week
[18:04:45] <wjp> A8?
[18:04:55] <Colourless> that spawn doesn't to an impiles
[18:05:22] <Colourless> but i guess that probably doesn't matter
[18:06:06] <Colourless> what's the problem with F4 and 108?
[18:06:20] <Colourless> 106 i mean
[18:06:26] <wjp> well, implies isn't popping those two :-)
[18:06:37] <wjp> the SP is 4 higher there than what I was expecting it to be
[18:07:40] <wjp> anyway, spawn was buggy
[18:07:43] <Colourless> the problem is in spawn
[18:07:45] <wjp> it didn't remove the this pointer from the stack
[18:07:45] <Colourless> the this pointer is supposed to be poped by spawn
[18:08:06] <Colourless> yes it did
[18:08:25] <Colourless> look at all the instances of spawn
[18:09:00] <Colourless> calli didn't pop the this pointer, but spawn does
[18:09:58] <wjp> cute, pid 1 is waiting for pid 1
[18:10:26] <wjp> think I should check for that? :-)
[18:10:59] <Colourless> have you 'fixed' spawn yet?
[18:11:11] <wjp> I made it pop this, yes
[18:11:45] <Colourless> and has pid 1 wainting for pid1?
[18:11:49] <wjp> yes :-)
[18:12:01] <Colourless> where?
[18:12:05] <Colourless> it shouldn't ever do that
[18:12:06] <wjp> the implies in FIRST::EF
[18:12:15] <wjp> pid is 1
[18:12:30] <wjp> retval from that spawn too, strangely
[18:12:52] <Colourless> are you even setting the retval?
[18:13:28] <Colourless> yes it appear it is
[18:13:31] <wjp> spawn sets temp32 to the new pid
[18:15:27] <Colourless> something is 'breaking'
[18:15:40] <wjp> indeed
[18:15:51] <Colourless> try debugging addProcess
[18:16:12] <Colourless> firstly what does the adding process output say?
[18:16:14] <wjp> I get a '[Kernel] Adding process 0x89027e0, pid = 5' there
[18:16:23] <wjp> so that sounds ok
[18:16:37] <wjp> hm, this isn't the first problem
[18:16:41] <Colourless> maybe temp32 is being overwritten somewhere
[18:16:48] <wjp> there's a "Non-existant process PID (0) in implies" earlier
[18:17:21] <wjp> yes, it would have to be
[18:18:26] <Colourless> is it bad for temp32 to be global?
[18:18:29] <Colourless> yes it is :-)
[18:18:35] <wjp> is it global?
[18:18:49] <Colourless> temp32 is in UCMachine, when i think it should be in UCProcess
[18:18:51] <wjp> yikes
[18:18:55] <wjp> I thought it was
[18:19:45] <wjp> although the fact that there wasn't a p-> in front of it should've tipped me off :-)
[18:19:59] <Colourless> :-)
[18:20:23] <Colourless> i should have noticed too... so who is to blame for putting it in UCMachine
[18:20:28] <wjp> me
[18:21:13] <wjp> hm, avatar doesn't even start getting up anymore now :-(
[18:21:17] <Colourless> you know, i would be seriously shocked if things sort of end up just 'working'
[18:22:11] <Colourless> which process makes him get up?
[18:22:30] <wjp> METHOD::15E7 I think
[18:22:33] <wjp> that calls doAnim
[18:22:40] <wjp> hm, doAnim does get called
[18:26:23] <wjp> who's NPC 6?
[18:26:51] <wjp> I'm guessing a bug :-)
[18:26:57] <wjp> (that's the NPC that's being animated there)
[18:26:59] <Colourless> no one
[18:27:11] <wjp> the animation number is 4 ('recovering from falling down')
[18:27:23] <Colourless> there is no npc 6
[18:27:29] <Colourless> 5 Darion
[18:27:31] <Colourless> 7 Mordea
[18:28:14] <wjp> seems we have some more bugs :-)
[18:29:34] <wjp> [BP+06] is 0x00010FF0 in METHOD::15E7
[18:30:20] <wjp> which should be a pointer to the 0x0001 that was pushed somewhere earlier
[18:30:57] <wjp> after push 0x0001, SP = 0x10
[18:31:07] <wjp> and stack size is 0x1000, so that looks ok
[18:31:33] <wjp> so why is it getting 6 from there... *sigh*
[18:34:57] <Colourless> is the base pointer properly being reset on ret?
[18:34:58] <wjp> oh
[18:35:15] <wjp> this is bad
[18:35:37] <Colourless> yes?
[18:36:19] <wjp> after METHOD::15E7 is called, the 'add sp -06h; push retval' pushes 6 to that place
[18:37:04] <wjp> METHOD::15E7 starts to run before that, but it does a suspend
[18:37:24] <wjp> which gives pid 1 a chance to run again, which screws up the stack
[18:38:31] <Colourless> ok, so let me understand this correctly
[18:38:58] <Colourless> 00FB: 6F push addr [SP+04h]
[18:38:58] <Colourless> 00FD: 57 spawn 04 02 057C:15E7 (unknown)
[18:38:58] <Colourless> 0104: 6E add sp -06h
[18:38:58] <Colourless> 0106: 5E push retval
[18:39:18] <Colourless> the push this pointer goes out of scope
[18:39:34] <Colourless> solution is simple actually
[18:40:05] <Colourless> deference the this pointer (catching nulls) and then copy it to the start of the new stack
[18:40:20] <Colourless> there must have been 'some' reason why they specified the this pointer size
[18:40:49] * wjp hmms
[18:41:00] <wjp> yes, that makes sense
[18:42:21] <Colourless> need to modify UCProcess::UCProcess() though
[18:42:29] <wjp> again, yes :-)
[18:42:51] <Colourless> now, you need to know how to exactly do what you need to do
[18:43:08] * wjp parses that sentence
[18:43:20] <wjp> yes, I do :-)
[18:43:20] <Colourless> :-)
[18:43:54] <Colourless> you push the deferenced this_pointer to stack
[18:43:59] <Colourless> you get the sp value
[18:44:05] <wjp> it would have to be the first item on the stack
[18:44:09] <Colourless> push thet args (minus the this pointer)
[18:44:37] <Colourless> then push a pointer to the this pointer
[18:44:44] <wjp> no, push the new this pointer
[18:44:47] <Colourless> (using the sp and the stack id)
[18:45:01] <Colourless> oops yeah, pointer to the 'deferenced this pointer'
[18:45:05] <wjp> we're not doing pointers to pointers :-)
[18:45:11] <wjp> (at least, I hope not :-) )
[18:45:19] <Colourless> hey it shouldn't matter
[18:45:26] <Colourless> we could support it
[18:45:27] <wjp> if we get the details right, it shouldn't, no
[18:46:02] <Colourless> a pointer is a pointer, whether it is to an int, a void, a object, or another pointer
[18:46:34] <Colourless> the other UCProcess::UCProcess() should probably be modified to do the same
[18:46:35] <wjp> ok, so we'll need a UCProcess constructor which takes a _lot_ of arguments
[18:46:44] <Colourless> or combine them into the same constructor
[18:47:01] <Colourless> not really, you only need '2' more
[18:47:15] <Colourless> this_ptr and sizeof_this
[18:47:15] <wjp> we'll have 7 arguments then :-)
[18:47:41] <Colourless> it's not 'that' bad :-)
[18:48:01] <wjp> I guess it could become one constructor with args/argsize defaulting to 0
[18:48:14] <Colourless> yes a wise idea :-)
[18:49:59] <wjp> ok, so... first, push *this
[18:50:11] <wjp> unless thissize == 0
[18:50:23] <Colourless> yes
[18:50:43] <Colourless> should probably check for a null this as well, and in such a case push null as the pointer too
[18:51:06] <Colourless> in theory it thissize should always be 0 if the poitner is null
[18:51:14] * wjp nods
[18:51:19] <wjp> better safe than sorry, though :-)
[18:51:20] <Colourless> funny, i was playing fallout2 ealier and i was crtically hit and i got knocked down in vault 15. I got knocked down into the elevator door, and something really strange happened. Some 'flag' on my character got set which changed the draw order properties because from then on my character was getting drawn before the walls, and i couldn't trigger the elevator anymore. Most annoying because i had to then reload from an ealier game
[18:51:47] <wjp> heh :-)
[18:52:00] <wjp> you're already in V15?
[18:52:09] <Colourless> even changing maps or saving and reloading didn't fix the problem
[18:53:19] <Colourless> finished it, been to v13 and am now in San Francisco
[18:53:32] <wjp> heh, you're further then me then :-)
[18:53:46] <Colourless> my character is level 12
[18:53:51] <wjp> I'm level 21 :-)
[18:54:10] <wjp> or maybe 24 already
[18:54:24] <Colourless> heh, i have been ignoring some stuff along the way
[18:54:32] <Colourless> such as all of redding pretty much
[18:55:15] <Colourless> haven't been exploring much either
[18:55:34] <Colourless> i've sort of stumbled onto the plot starting with NCR :-)
[18:57:39] <Colourless> i'm taking the easy way out though, i've got it set to 'Easy' combat level
[18:58:02] <Colourless> i should probably set it back to normal because i now am finding the combat pretty easy :-)
[18:58:29] <wjp> what kind of character are you playing?
[19:00:31] <Colourless> a charasmatic character
[19:00:45] <wjp> high speech?
[19:00:56] <Colourless> yeah
[19:00:59] <wjp> cool :-)
[19:01:02] <Colourless> 100
[19:01:05] <Colourless> chrisma is 8, endurance 7, luck 7, agility 6, the rest 5
[19:01:05] <wjp> you'll have to tell me about the ending
[19:01:09] <wjp> 100 isn't high :-)
[19:01:28] <wjp> I'm playing an unarmed char atm
[19:01:42] <Colourless> yeah i know, it can go higher
[19:01:56] <Colourless> but i think that skill points could be better spent else where
[19:01:56] <wjp> strength 9, agility 10, endurance 7 or 8, the rest rather low :-)
[19:02:04] <wjp> unarmed 180% :-)
[19:02:16] <wjp> it costs 5 skill points to go up 2% now
[19:02:36] <Colourless> hehe
[19:03:05] <wjp> (but I can hit everything in the eyes at 95%)
[19:03:08] <Colourless> my small guns is 101,first aid 100
[19:03:37] <Colourless> pretty good
[19:03:56] <wjp> are laser/plasma/gauss pistols small guns?
[19:04:04] <Colourless> no
[19:04:07] <Colourless> energy
[19:04:09] <wjp> pity
[19:04:19] <Colourless> yeah i knoq
[19:04:20] <Colourless> know
[19:04:22] <wjp> what weapon are you using?
[19:04:48] <Colourless> .223 pistol
[19:04:52] * wjp nods
[19:04:57] <wjp> they're pretty good
[19:05:00] <Colourless> occasionally an assult rifle for burst
[19:05:05] <wjp> 25-35 dmg?
[19:05:22] <Colourless> 'heaps' is all i can say. but yeah about that
[19:05:54] <wjp> I really wonder about how the ending goes with high speech
[19:07:54] * wjp uh-ohs
[19:08:21] <wjp> can't get a pointer to your own stack in the constructor
[19:08:31] <wjp> because process doesn't have a pid yet
[19:09:06] <Colourless> hmm, is that 8 args i hear?
[19:09:29] <wjp> it could just give itself a pid
[19:09:47] <wjp> or move this stuff outside of the constructor
[19:09:51] <Colourless> yes true
[19:10:24] <Colourless> you'd create an 'empty' uc process
[19:10:35] <Colourless> which you then get to call a class
[19:11:32] <Colourless> that is practically what is done now, execpt all in the constructor
[19:13:08] <wjp> we'll have to take a good look at spawn inline too
[19:14:07] <Colourless> the devil as code
[19:16:27] <wjp> what a mess...
[19:21:27] <wjp> ok, things look good now
[19:21:31] <wjp> avatar gets up
[19:21:40] <wjp> after that, Devon and Avatar turn to face eachother
[19:27:55] <wjp> I'm a bit confused about direction numbers
[19:28:06] <wjp> I'm pretty sure doAnim takes a direction from 1-8
[19:28:21] <wjp> but it seems the getDirToX intrinsics have to return a direction from 0-7
[19:29:00] <wjp> (could of course be that it should return 1-8 but another bug causes things to screw up then)
[19:29:33] * wjp sighs
[19:29:38] <Colourless> odd
[19:29:42] <wjp> I think I've spent enough time staring at usecode for a while :-)
[19:29:55] <wjp> I think I'll go watch some tv or something :-)
[19:30:56] <Colourless> :-)
[19:33:48] <wjp> ...but the result from getDirToItem is passed straight to doAnim in places
[19:34:00] * wjp sighs
[19:34:18] <wjp> anyway, I'm gone :-)
[19:34:20] <wjp> see you later
[19:34:23] <Colourless> cya
[20:18:49] <wjp> back
[20:19:15] <wjp> don't tell me you're still playing F2? :_)
[20:19:19] <wjp> s/_/-/
[20:19:20] <Colourless> wb
[20:19:32] <Colourless> of course
[20:20:06] <wjp> one of the best parts about F2 is that it runs flawlessly in Wine :-)
[20:21:11] <wjp> anyway, time to continue staring at usecode to figure this direction stuff out
[20:21:54] <wjp> 056E::0292 has a doAnim call with dir = 8
[20:22:36] <wjp> as well as several others
[20:22:53] <wjp> the result of Npc::getDir() is often passed to doAnim as direction
[20:23:03] <Colourless> might mean current direction
[20:23:23] <Colourless> then again i don't know
[20:24:02] <wjp> hm, do you remember how the drowning animation plays?
[20:25:08] <wjp> hm, nvm, the drowning anim looks the same in all dirs
[20:25:13] <wjp> oh, except 3
[20:25:19] <Colourless> yeah it does
[20:25:26] <wjp> direction 3 is weird
[20:25:36] <wjp> the avatar moves forward in that one somehow
[20:26:10] <wjp> interesting
[20:26:19] <wjp> the dir==8 are exactly the ones with the flag=1
[20:26:27] <wjp> (the flag = last argument to doAnim)
[20:38:32] <wjp> ah... Get_direction doesn't seem to return the right direction?
[20:39:26] <Colourless> hhuh?
[20:39:37] <wjp> what exactly does Get_direction return?
[20:39:54] <Colourless> where??
[20:39:55] <wjp> the two 'NOTE's at the top seem to conflict
[20:40:02] <wjp> misc/Direction.h
[20:40:39] <Colourless> it's screenspace
[20:40:46] <Colourless> it's for the mouse cursor
[20:41:02] <wjp> ah, the "NOT screen coords" kind of threw me off :-)
[20:42:48] <Colourless> you pretty much want the same sort of code
[20:43:12] <Colourless> recopying the code from exult would probably be the 'easy' solution
[20:43:19] <wjp> it looks like just the return value of that one -1
[20:43:42] <Colourless> that.. may not be entirely correct though. i may have made some changes
[20:44:11] <Colourless> but i can't remember making any other
[20:46:24] <wjp> on second though, some of the axes are probably inverted too
[20:47:07] <Colourless> actually the axis would be correct for that function
[20:51:15] <wjp> hm, uh oh
[20:51:26] <wjp> talking to the guard at the gate causes an infinite loop
[20:52:05] <Colourless> any ide why?
[20:52:23] <wjp> I'm getting "class is empty..." messages
[20:52:47] <wjp> ack
[20:53:06] <wjp> nvm, that message is always triggered :-)
[20:53:10] <wjp> (typo)
[20:57:25] <wjp> hm, weird
[21:00:49] <wjp> it's looping GUARD1::1033
[21:01:44] --> Dark-Star has joined #pentagram
[21:02:29] <wjp> can't say I'm surprised...
[21:02:37] <wjp> there's no way to get out of that function
[21:02:40] <wjp> hi Dark-Star
[21:03:38] <wjp> Colourless: ah... it looks like that's the "patrol" function :-)
[21:03:55] <wjp> it's just looping very fast because we don't have pathfinding in yet :-)
[21:05:30] <Dark-Star> hi
[21:06:10] <Colourless> hehe
[21:08:41] <wjp> I assume it gets stopped when you leaveFastArea
[21:24:11] <Dark-Star> hmmm...
[21:24:24] <Dark-Star> mkdir() on Windows needs #include <direct.h> somewhere...
[21:24:38] <wjp> dirent.h?
[21:24:55] <Dark-Star> no, direct.h
[21:25:13] <wjp> sure?
[21:25:19] <wjp> Kirben didn't mention it
[21:25:48] <Colourless> i'll check
[21:25:50] <Dark-Star> hmm... MSVC7 won't compile without it. I put it in my local msvc_include.h
[21:26:02] <Colourless> and what do you know, it's in my header too :-)
[21:26:11] <Dark-Star> what a coincidence!! ;-)
[21:26:40] <wjp> well, seems like I'll be going to bed before Colourless :-)
[21:26:53] <wjp> who's in a timezone 7 1/2 hours further *sigh* :-)
[21:27:01] <wjp> g'night :-)
[21:27:06] <Dark-Star> cya
[21:27:18] <-- wjp has left IRC ("Zzzz...")
[21:27:35] <Dark-Star> hey, there are a few more warnings where MSVC complains...
[21:28:11] <Dark-Star> "not enough parameters given for macro ARG_NULL32" for example...
[21:29:29] <Dark-Star> and UCProcess.cpp line 54: "unsigned type was assigned an unary minus operator. the result is still unsigned"... this *might* cause trouble...
[21:30:04] <Dark-Star> because it seems the minus is evaluated before the uint is cast to an sint (which makes sense)
[23:07:53] --> Kirben has joined #pentagram
[23:07:53] --- ChanServ gives channel operator status to Kirben
[23:10:38] <-- Colourless has left IRC (Read error: 60 (Operation timed out))
[23:14:12] <Dark-Star> 'night
[23:14:30] <-- Dark-Star has left IRC ("ZZZzzz...")
[23:46:38] --> Cashman has joined #pentagram
[23:46:44] <-- Cashman has left IRC (Client Quit)