Raphael, 24th September 2004

Implementing removal of already generated elements (dynamic world generation):

* If an element posesses a GDynamicGeneratorAgent then this agent can have
  a timeout and when this timeout is reached he will send an influence to
  its parent notifying it about the removal, then he will emit a signal
  for the GWE to remove the element.

* The receiving parent (the GDynamicGeneratorAgent) will take note of the
  removed child and mark the node that generated the child as NOT generated
  (implement a GDynamicGeneratorOctreeNode::resetGenerated())
  
* Somehow the node needs to be correctly identified (either use the position
  of the child... but the child could have moved in the meantime).
  On creation a path to the correct node could be stored in the subelement's
  GDynamicGeneratorAgent which will then be used with the influence (see above).
  The element property system can be used for this (as soon as it is implemented).
  
  
  
DETAILS:

* If a GDynamicGeneratorAgent is generated for a child it can be told whether
  it should remove itself after some timeout and if no childs are present.
  Thus a completely randomised element will automatically disappear if it is
  suitable for it.
  These things would be especially useful for organic things like plants,...
  because they have a very complex element hierarchy and can thus be VERY
  easily transported to the client - or other GWE servers (network layer
  optimisation!!). Whole landscapes can thus be stored. Of course on individual
  changes to these elements they become persistent and won't be removed (this
  is guranteed as the parent would only remove himself if no childs are left).