[CF-Devel] Python again

Yann Chachkoff yann.chachkoff at mailandnews.com
Fri Sep 27 03:21:37 CDT 2002


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
     
     )
------------------------------------------------


    
    


More information about the crossfire mailing list