[crossfire] exploding MOBs

[Mark Wedel]

Todd Mitchell wrote:
>
     
      Well you can put arches into inventory now - so you can already for 
     
     >
     
      example spawn a couple guards or fireballs or something when a MOB is 
     
     >
     
      destroyed.  I was thinking of a will_explode and explode_attacktype 
     
     >
     
      flags where if will_explode = 1, it produces a little pop graphic and 
     
     >
     
      deals out damage from attacktype (or explode_attacktype if it's not 0).
     
     
  Putting fireballs in the inventory is less likely to work, because of the 
timing - to get them to blow up after the monster dies, not before and not a 
long time after, is more complicated.

  Of course, I'd think exploding monsters could also be done via script (hook 
into the death event of the monster).  When the monster dies, death event is 
called, which basically just creates some objects specified wherever the monster 
died.

  That still has some problem in that you could only use standard archetypes for 
those objects (this is actually one problem with using other_arch also - you 
can't customize the object, which with the spell code, is pretty important - 
taking just the firebullet arch (or whatever) and putting it in a map won't do 
much at all).

  The scripts could in theory be more clever, by looking at the objects in the 
now deceased monster, and if those objects have some flag set, it knows to use 
those objects as the explosion objects (remove from inventory, update the 
speed/speed_left so they blow up immediately, insert onto map).  Script could 
look either at nrof field for number to insert, or find number of objects in 
inventory with unique flag (value) set.

  I'm uncertain how often such functionality would end up being used - there are 
lots of cool things that can be envisioned, but at some level, for things that 
don't happen a lot, using scripts may be the way to go instead of trying to C 
code all these possible events.

  OTOH, an intermediate approach could make sense - something like built in 
basic script hooks that don't require external python scripts.

  For example, you could keep all the current script hooks (death, apply, whatever).

  You could then have another set of basic script actions (insert onto map, 
remove object, change value, identify, etc).

  These actions could then take some number of optional paremeters.

  Thus, you could have something like:

event_apply_plugin Builtin
event_apply Change_Value, -1

  (which would decrease the value of the object by 1 each time it is applied).

  Or in this case, could be something like:

event_death_plugin Builtin
event_death insert_spell_from_inventory_to_map, fireball

  The advantage of doing this via builtin scripts is that it allows more 
flexibility (was mentiond to do this would require something like 
FLAG_INSERT_AT_DEATH) - the problem is that you would need a whole bunch of 
flags to cover all the possiblities (death, apply, etc).

  The other problem is that there are not always available fields.  For example, 
other_arch was mentioned as a field to use.  One problem there is that 
other_arch is used by some monsters for what they turn into/generate, which then 
means you can't have those monsters explode.

  The advantage of builtin scripts (vs the external python) is twofold - builtin 
scripts would basically always be available (nothing external required - not 
even dynamic linking), and performance shoudl also be better.  My understanding 
right now is that whenever a python script is loaded, it will read the python 
script from disk - granted good OS's will cache the file, but I imagined there 
is certainly more overhead in loading that file, parsing it, and handling the 
conversion of the C structures to something that is usuable in python.

  All that said, builtin scripts (which is a bit of a misnomer in fact, since 
they are not scripts) would largely cover the most basic and common things that 
need to be done.  But the builtin method has the nice advantage of being able to 
take those optional parameters and thus be quite flexible in what it can do - 
can specify those different objects to insert instead of trying to find free 
files to put them into in the object structure.