[CF-Devel] python plugin trigger bug?

[crossfire-devel at archives.real-time.com]

Andreas Kirschbaum wrote:

>
     
     The comment in the source (located somewhere in the server code, just
     
     >
     
     before the plugin code is called) says: originator (WhoAmI) is the
     
     >
     
     object that caused victim (Other) to move onto trap (Activator).
     
     >
     
     
     >
     
     Therefore I'd say Other is the object on the trigger.
     
     >
     
     
     >
     
     I did a quick survey for the events used in the server code (see the
     
     >
     
     attachment). I'll add this information to doc/Developers/python.
     
     >
     
     
     >
     
     
     >
     
     
     Thanks for the table.  It will be very helpful.  I did look at the trigger event hooks for that case you mention and actually thought that it was wrong. I would rather see whoami return the object that contains the trigger script and the activator return the object that caused it to fire. I actually switched victim and trap around in the code there to see If I could change it that easily but there was somehting else wrong since I didn't change the plugin code and I hadn't tried to figure out other changes needed due to the trap code as it applies to buttons and levers and such so it isn't that simple...

I really really think that most of the time (85%?) the trigger event 
code will be used to find out when a player pulls a lever or steps on a 
button and so would like to see activator as the object that 'activates' 
the trigger object and whoami as the trigger object itself.  This would 
bring it in line with other common events.  I don't know how possible it 
is but it should be doable since it passes the info to the plugin so all 
adjustments would be in the plugin, no?  I can try to help if it is hard 
to do but I feel pretty strongly that it should work consistantly if 
possible.

>>
     
     My script had whoami to determine the object being activated - whoami
     
     >>
     
     is not valid causing a segfault...
     
     >>
     
     
     >>
     
     
     >
     
     
     >
     
     I'm currently fixing the plugin code to prevent (or at least reduce)
     
     >
     
     such crashes. The current plugin code has at least the following
     
     >
     
     problems:
     
     >
     
     
     I'll have to look more and I am certainly not an expert in these 
matters.  I  think that Python did not always have a 'NULL' and I 
usually work with a 0 rather than a 'NULL' myself.

_______________________________________________
crossfire-devel mailing list
     
     crossfire-devel at lists.real-time.com
     
     
     https://mailman.real-time.com/mailman/listinfo/crossfire-devel