News:
  - Interface mail <-> news: siehe Notizbuch
  - Ein virtuelle Gruppe mail.* einrichten, die auf den Mailmaster abgebildet
    wird.
  - Newsmatrix/board ueberarbeiten, /news/newslib, /std/newsclient machen
  - Im Master die Headers einzeln speichern (-> list unread darstellung)
  - Defaultgroup fuer Newsmatrix setzbar machen
  - Umbenennen von Boards
  - Artikel als einzelne Dateien speichern (=> komplett neuer Master)
  - Matrix: any regexp pattern for ignored should be evaluated again on every
    check, to catch even newly created groups.
  - Unreadable groups shouldn't be listed?

Gun:
  - In outside rooms kein 'impact into a wall'
  - Doorhandling, possessive pronouns

Sonst:
 - mauern spielen
 - PGP-Schutzfeldgenerator?

Micro:
 - "Indoors"/"Outdoors" is a bad naming esp for rooms with windows.
 - Properties: generisches Init(...), analog zum Get(...), das extra Magie
   erlaubt; evtl durch InitFoo() filtert?
 - Skills: preferred/special skills (verallg von Guildskills)
 - WEIGHT_CHG: 0 no change, -1000: reduction by who e wiight, 
   +1000 doubling of weight.
 - Die NumberHands bei Waffen/Schilden default-dynamisch von Level
   und so abhaengi machen.
 - Die feste Link/Player-Objekt Verknotung ist machbar, wenn man wie im secure/master
   das modify_command einmal sich selbst rufen laesst und so input_to/prompt
   handling von Hand macht. Um den ed laesst sich herumhacken, indem man die
   cleanup-Funktion stets auf eine feste Funktion zeigen laesst, und die
   originale Object-Funktion als temporaere Prop speichert. Die feste Funktion
   kann dann den prompt malen.
   Analog kann man input_to auf eine feste Funktion zeigen lassen, die dann
   die eigentlich input_to-Funktion aufruft und nach Rueckkehr feststellt,
   ob ein neuer input_to anhaengt, oder ob der Prompt gemalt werden muss.
   Die Fehlerbehandlung liesse sich ueber ein Call-Back im master machen.
 - Bei automatischer Formatierung nicht vergessen, auch nicht-formatierende
   efuns bereitzustellen (schon aus Geschwindigkeitsgruenden).
 - who kann man besser machen. Basis-who brauch 'passive' nicht; Jobtag
   laesst sich besser vorweg schreiben. who details kann dann passive und
   so mit ausgeben.
 - Shops mit inherit basearticles ausstatten.
 - Besseres Lichthandling:
   For darkness: lower bound for lightlevels (and/or more the human ivision
     level up from 0). Or more exactly: the ivision check should not be
     done by a simple number comparisions: some races must be able to
     see in _any_ darkness.
     The handling of darksources should be analog to that of lightsources,
     esp. the additional part.
   Mica says: was ich bei licht gerne haette waere das was ich schonma
     geschrieben hab, dass torches ein maxlight haben was sie erzeugen koennen
     einfach addieren ist sehr unrealistisch
     nach dem motto: 100 torches und man steht in einer supernova
  Mica says: aber das koennte man so loesen dass jedes environment zwei werte
     hat, ein 'theoretisches' licht, und ein effektives, letzteres angepasst,
     wenn sich was andert schaut man in allen items nach dem theoretischen und
     adjusted es
  Mica says: jedes item hat zwei licht-eigenschaften, einmal wieviel licht es
     aussendet und eine zweite eigenschaft wieviel licht in einem raum es
     maximal erzeugen kann
     z.b. torch: 20 licht und bis maximal 150 int light
     um sich die deep inventories zu ersparen, koennte mal folgendes
     machen:
     jeder container, auch player, fragen von allen ihren items das
     licht und das maxlicht ab und speichern es in zwei werten als quasi das
     licht was der container aussendet und das was er maximal erzeugen kann
     (unter hinzufuegung seiner eigenen werte)
     der raum ueberprueft dann nur das container-licht
  You say: Ok. Nun habe ich zwei verschiedene Lichtquellen mit zwei
     verschiedenen Additiv-Maxima. Welches davon gebe ich an meine Umgebung
     weiter?
  Mica says: das hoechste logischerweise
  You say: Ah, ich sehe. Wenn 20 Spieler im Raum sind, jeder hat(nur)  eine
     Fackel mit 10/150, dann hat auch jeder Spieler 10/150, und der Raum wird
     nur um 150 heller - die Fackeln von 5 Spielern fallen weg.
  Mica says: wobei es zwei loesungen fuer das vermurksen gibt
     die 1. ist den code nach move() zu verlegen
     die 2., dann eigentlich kaum noch zu vermurksen ist -> H_MOVE_HOOK .)
     das .) muss da eigentlich weg, da ich diese loesung bevorzuge
     denn jedes item hat licht, zumindest wenn es gemoved wird
     und alle licht-handle-funktionen die intern sind, wie _add_light
     etc. als nomask deklarieren
