[CF-Devel] plugin and events

[Mark Wedel]

Todd Mitchell wrote:
>
     
      Reading the python plugin code...
     
     >
     
      Local Events are:
     
     >
     
      ATTACK, APPLY, DEATH, DROP, PICKUP, SAY, STOP, TELL, TIME, THROW, TRIGGER,
     
     >
     
      CLOSE
     
     >
     
      these can have code linked to specific objects (by putting an event call in
     
     >
     
      the object)
     
     >
     
      Global events are:
     
     >
     
      BORN, CRASH, LOGIN, LOGOUT, REMOVE, SHOUT, MAPENTER, MAPLEAVE, CLOCK,
     
     >
     
      MAPRESET
     
     >
     
      these can not have code linked to specific objects
     
     
  There is probably some good reasons that global events can not be linked to 
local objects.

  First, the number of objects that need to be examined for one of these events 
could be prohibitive - even if only 20 objects currently in memory use it, all 
objects in memory (thousands, or tens of thousands) would need to get examined.

  Second, the objects listening for these events may not be in memory when the 
event happens.  IF a map is reset, it is likely in most cases that the objects 
for the map that is being reset is not in memory.

  Some, like mapenter and mapleave could be perhaps be tied to the specific 
exits (although, apply can be used for that).  It would perhaps be interesting 
to have plugins based on the map's themselves.

  Eg, be able to say something like '/city/city' have mapenter and mapleave 
plugins associated with it.


>
     
      This did dash my hopes for putting in a map reset event call into certain
     
     >
     
      exits to have the object name and message read from a file on reset.
     
     >
     
      (although I am still thinking how to use one of the local event hooks...say
     
     >
     
      time) I don't know the wisdom of creating a local event hook for a map reset
     
     >
     
      but here are some things you could do if there was one:
     
     
  Have to be careful about plugging things into objects, as you can never be 
sure the objects are going to be in memory when some of the events are called, 
as I mention above.


>
     
      -Since the plugin can override the event you could also have maps that did
     
     >
     
      not reset if there was a player on a linked map (this would let some maps
     
     >
     
      have a shorter default reset time as well I suppose...)
     
     
  This is probably a different issue - scripts could be used to do this, but 
it'd be better if it was somehow simpler, like the map header having a list of 
related maps, eg, something like:

related_maps: tower1 tower2 tower3 tower4

This is an old discussion - the problem typically isn't the reset times on 
linked maps, the problem is that a player doesn't know the status of the map, 
wanders in, sees it been cleared out, but that means the reset time is once 
again extended.


>
     
      -have other objects in some maps that could change (or not change) based on
     
     >
     
      events external to the map reset cycle like a file (local or net), or a
     
     >
     
      condition (player count?) --this would be better than using unique floors
     
     >
     
      (and the associated files in Unique-items) for small object scale
     
     >
     
      semi-permanences.
     
     
  As said, problem is these objects may not be in memory at the time of the 
event.  In any case, what's the problem with using unique-item files?  you can 
make individual objects unique, and they will persist no matter where they are 
dropped.

  Now it would be useful to attach scripts to most unique objects - in 
particular to the pickup and drop - if someone drops a unique item in a shop 
(tries to sell it), it goes back to its starting location for example - pickup 
could be used for it to store away where it was picked up.