[CF-Devel] Python again

[Todd Mitchell]

----- Original Message -----
From: Yann Chachkoff


>
     
      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'.
     
     
I changed my code to use CreateObjectInside instead of Create object and it
worked exactly the same way (I just remaned the function and replace the x,y
coords with the activator (the player).  It seems to use the object name
(strange key) as well rather than the arch - but then again I didn't try it
with 'key2'  - anyway no problems with this function.

>
     
      CreateInvisibleInside()
     
     >
     
      -----------------------
     
     >
     
      Browsing through the plugin_python.h file, it appears that the correct
     
     name
>
     
      for this one is CreateInvisibleObjectInside(). The same applies to
     
     >
     
      CheckInvisibleObjectInside().
     
     
Great - will try it out.  Looking in the plugin code it is called
CreateInvisibleInside however which could be confusing.  I like the longer
name myself and would suggest it be renamed in the code rather than in the
header.

>
     
     
     >
     
      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 ?).
     
     >
     
     
     
Just to avoid misunderstanding - I don't want to link global events to
specific objects or change the global events. The scheme makes a lot of
sense to me as it is and I am sure is better as is because of timing and
processing requirements. Forgive my 'newby' terminology.  I think Mark
summed it up when he said I was looking for a new local event to hook to
specific objects on a map when that map is loaded (when the object is
loaded?) to allow for some more control over the objects on the maps, like
changing the message field or name of an object or checking an external file
or environmental condition or some such.

>
     
      Hope this helps,
     
     >
     
     
     >
     
      Y. Chachkoff
     
     
yes it does thanks.