Todd Mitchell wrote: > On Sat, 2003-10-25 at 23:59, Mark Wedel wrote: > >> Todd Mitchell wrote: >> >>> Whenever I drop an object that has a python script hooked to the drop >>> event I get a segmentaiton fault here: >>> >>> in fix_player (op = 0xbffffaac) at living.c 795 >>> >>> if(!QUERY_FLAG (&op->arch->clone, FLAG_FLYING)) >> >> As is usual in my requests, please provide an example of the broken object, >> and script as applicable. > > > Well any object hooked to 'drop' calling any script will do it. Here is > a map and a simple test script. It doesn't matter if you have event > options or do anything in the script or not - it is the drop hook itself > that is broken as far as I can tell. I think I'll have to defer this one to Gros, as I'm not 100% of the right behaviour. It appears to be an inconsistency in the pointers. in drop_object, we have: CFP.Value[3] = &nrof; but in HandleEvent, we have: StackOther[StackPosition] = (object *)(PParm->Value[3]); So we are basically taking a pointer to nrof and converting it to a object. Needless to say, that doesn't work. I'd guess that nrof should really be put into CFP.Value[5], as that turns into: StackParm1[StackPosition] = *(int *)(PParm->Value[5]); Which would seem to make more sense (nrof is really a parameter), and CFP.Value[3] probably should be set to NULL. It appears that is what the other functions do that set SCRIPT_FIX_ALL. _______________________________________________ crossfire-devel mailing list crossfire-devel at lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel