[crossfire] Plugins

[Mark Wedel]

Nicolas Weeger wrote:
>
     
      Hello.
     
     
>
     
      * what functions should a plugin be able to access? I'd say the more
     
     >
     
      the better, to have nice effects. But a plugin should not be concerned
     
     >
     
      with server logic - it should just issue simple orders.
     
     
  Note that some number of server functions probably make no sense to be called 
externally.  That said, this is perhaps driven by what functionality the clients 
need.

>
     
     
     >
     
      * should we take care that a plugin can't crash the server or make it
     
     >
     
      a mess? This would mean active verification of object state after
     
     >
     
      calls, and take time to implement. Or we could just let plugins access
     
     >
     
      functions, the script developer being responsible for not crashing
     
     >
     
      server. Simple example: remove player object. That's a bad thing to do
     
     >
     
      - should a plugin be able to do that, or should the server forbid it?
     
     
  Ideally, nothing should every be able to crash the server.  So if we can do 
extra sanity checks to preven that from happening, probably a good idea.

  That said, there are certainly checks in the server or other places where the 
server code does call abort(), simply because if we get to that state, we want 
to log it ASAP, because trying to continue will just cause a panic a few seconds 
later.  But that is controlled by the MANY_CORES define.

  At minimum, we probably want to at least log bad things that the plugin is 
doing, so if it does panic, it is very easy to see (look, plugin xyz removed a 
player object).  There are certainly some number of crashes I see on metalforge 
that I have no clue how the thing got into that state - I'm not saying a plugin 
is responsible, but if we can log bad things, sounds like a good idea to me.