ldmud-3.2.9/doc/
ldmud-3.2.9/doc/efun/
ldmud-3.2.9/mud/
ldmud-3.2.9/mud/heaven7/
ldmud-3.2.9/mud/heaven7/lib/
ldmud-3.2.9/mud/lp-245/
ldmud-3.2.9/mud/lp-245/banish/
ldmud-3.2.9/mud/lp-245/doc/
ldmud-3.2.9/mud/lp-245/doc/examples/
ldmud-3.2.9/mud/lp-245/doc/sefun/
ldmud-3.2.9/mud/lp-245/log/
ldmud-3.2.9/mud/lp-245/obj/Go/
ldmud-3.2.9/mud/lp-245/players/lars/
ldmud-3.2.9/mud/lp-245/room/death/
ldmud-3.2.9/mud/lp-245/room/maze1/
ldmud-3.2.9/mud/lp-245/room/sub/
ldmud-3.2.9/mud/lp-245/secure/
ldmud-3.2.9/mud/morgengrauen/
ldmud-3.2.9/mud/morgengrauen/lib/
ldmud-3.2.9/mud/sticklib/
ldmud-3.2.9/mud/sticklib/src/
ldmud-3.2.9/mudlib/uni-crasher/
ldmud-3.2.9/pkg/
ldmud-3.2.9/pkg/debugger/
ldmud-3.2.9/pkg/diff/
ldmud-3.2.9/pkg/misc/
ldmud-3.2.9/src/autoconf/
ldmud-3.2.9/src/bugs/
ldmud-3.2.9/src/bugs/MudCompress/
ldmud-3.2.9/src/bugs/b-020916-files/
ldmud-3.2.9/src/bugs/doomdark/
ldmud-3.2.9/src/bugs/ferrycode/ferry/
ldmud-3.2.9/src/bugs/ferrycode/obj/
ldmud-3.2.9/src/bugs/psql/
ldmud-3.2.9/src/done/
ldmud-3.2.9/src/done/order_alist/
ldmud-3.2.9/src/done/order_alist/obj/
ldmud-3.2.9/src/done/order_alist/room/
ldmud-3.2.9/src/gcc/
ldmud-3.2.9/src/gcc/2.7.0/
ldmud-3.2.9/src/gcc/2.7.1/
ldmud-3.2.9/src/hosts/
ldmud-3.2.9/src/hosts/GnuWin32/
ldmud-3.2.9/src/hosts/amiga/NetIncl/
ldmud-3.2.9/src/hosts/amiga/NetIncl/netinet/
ldmud-3.2.9/src/hosts/amiga/NetIncl/sys/
ldmud-3.2.9/src/hosts/i386/
ldmud-3.2.9/src/hosts/msdos/byacc/
ldmud-3.2.9/src/hosts/msdos/doc/
ldmud-3.2.9/src/hosts/os2/
ldmud-3.2.9/src/hosts/win32/
ldmud-3.2.9/src/util/
ldmud-3.2.9/src/util/erq/
ldmud-3.2.9/src/util/indent/hosts/next/
ldmud-3.2.9/src/util/xerq/
ldmud-3.2.9/src/util/xerq/lpc/
ldmud-3.2.9/src/util/xerq/lpc/www/
Short: Extra wiz_info data vanishes
Date: Mon, 4 Dec 2000 11:38:05 +0100
From: Christian Mudra <mudra@informatik.uni-kl.de>
Type: Bug
State: Fixed - corrected in 3.2.9-dev.246

Hi Lars,

es gibt Probleme bei get_extra_wizinfo():
Ich habe hier bei get_extra_wizinfo() viele Listen der Art
  0: ({ /* #2, size: 1 */
   -500
 }); ({ /* #3, size: 1 */
   <local function in destructed object>
 }),
da wir ueber set/get_extra_wizinfo() die event-listen abspeichern,
d.h.  get_extra_wizinfo(0)["events"] liefert
([ "event-type":
     ([ object : ({ liste der event-prioritaeten });
                 ({ liste der jeweiligen callback-funktionen }),
     ]),
])

Ein weiteres Problem ist seit 239, dass z.B. aus dem Eintrag fuer
global/commands/comm, der so

   <global/commands/comm> : ({ 0 });
                            ({ #'global/commands/comm->receive_event });

aussehen sollte, unter nicht geklaerten Umstaenden ein

   <global/commands/comm> : 0;
                            ({ #'global/commands/comm->receive_event });

wird, und damit funktionieren alle communication-events nicht mehr.
Analog fuer move-events. Mir scheint, in der einen Aenderung von
238 zu 239 loescht Du irgendwo zuviel, und bei gespeicherten Objekt-Mappings
zu wenig ...
Wenn ich z.B. unser global/commands/comm destructe und neu lade, dann meldet
es sich wieder beim event-server an, der dann ueber etc/shared in
set_extra_wizinfo() eintraegt, dass global/commands/comm mit prio 0 auf
alle Kommunikation hoert. Dann funktionieren die events wieder, aber nur
eine begrenzte Zeit (und der event-server holt sich immer nur per
get_extra_wizinfo() die Prios der Objekte, die auf einen bestimmten
event lauschen, also er schreibts nicht selbst dortrein, ausser ein Objekt
meldet sich an oder ab). Daher gehe ich davon aus, dass es sich hierbei
um einen echten Treiberbug handelt.

Ich werde fuer Tub jetzt erstmal wieder zu dev238 wechseln, augenblicklich
laeuft einfach nichts mehr im Mud.


Analysis: The bug was triggered by not cleaning a rhs mapping in a mapping
addition from destructed objects. The exact reasons why this happens are
unclear. Originally the mapping has been cleaned, but in dev-239 I removed
the call for performance reasons.