Some notes about CFPython... RemoveObject() -------------- RemoveObject() expects an integer representing an object. An object ID can be obtained by functions like CreateObject or WhoAmI, for example. CreateObject() -------------- CreateObject() was supposed to allow an archetype name or a 'full name' to be given. Due to a typo (around line 4566), it doesn't work as expected. It looks like CreateObjectInside should work as expected. I'll check this and correct as appropriate. Two wrappers are used by those functions: CFWGetArchetype() (returning an object, given its arch name); CFWGetArchetypeByObjectName() (returning an object, given its 'clear' name); The reason why CreateObject and CreateObjectInside were created to handle both cases was to allow creating objects from what a player could say - and a player is more likely to say 'strange key' than 'key2'. CFWReadyMapName() wrapper ------------------------- This is a wrapper for ready_map_name(), which is used here to attempt to load a map, given its name. The Python function returns a handle (pointer) to the loaded map. CreateInvisibleInside() ----------------------- Browsing through the plugin_python.h file, it appears that the correct name for this one is CreateInvisibleObjectInside(). The same applies to CheckInvisibleObjectInside(). CLOCK Global event ------------------ The CLOCK Global event handling is disabled by default in CFPython. If you need such an event, remove the comment marks around lines 6899-6901 in plugin_python.c source file. TIME Local event ---------------- TIME was created to allow a specific action to trigger 'whenever the object gets an opportunity to move'. TIME could be used to create random-bomb-like devices, or monsters with time-based abilities. TIMER Local event ----------------- A timer is a kind of "clock" associated with an object. When the counter of a timer reaches 0, it is removed from the list of active timers and an EVENT_TIMER is generated for the target object. TIMER and TIME events are not the same thing: the first one is called when a timer delay has reached 0 while EVENT_TIME is triggered each time the object gets the opportunity to move. TIMER could be used to create bomb-like objects. See timers.h for more informations about timers. The global vs local event scheme -------------------------------- I think some clarification is required about those. The base idea is that the Crossfire world is made of object entities 'influencing' each other in the same game environment. Note that what is called 'object' here doesn't cover maps (because maps were considered as part of the environment, not an entity the player could carry or directly interact with - the player can only interacts with the objects inside the map). So, local events are events 'that can be bound to a specific object': When you kill a monster for example, it is clear that a DEATH event is triggered for him, and only him. Local events have a well definite 'target'on which they should apply. Global events, on the other hand, are events that cannot easily be tied to a specific game object, or are outside the scope of CF inner point-of-view (That's why LOGIN and LOGOUT are global - they could be caused by external problems, like a broken connection). They're 'general informative' events. You may object that they could (and should) have been implemented as local events. Well, performances are an important obstacle. Informing all loaded objects of MAPENTER/MAPLEAVE events would have been quite difficult (even if you create a small map, this could become a problem - what if a player throws a lot of equipment on the floor ?). Hope this helps, Y. Chachkoff ------------------------------------------------ Help supporting JXFire ! ( http://jxfire.sf.net ) ------------------------------------------------