The other fuse problem (was RE: [UM1-coders] Fixing the problem)

[Adrian S. J. <AS...@pa...>]

> From: Adrian St. John=20
>=20
> > From: Peter Crowther [mailto:pet...@ne...]
> >=20
> > (Blink).  What problem?

Just so Peter gets the entire thing...

  BUG REPORT

  I'm sending this internally as I did not want to announce game
crashing bugs
  over the um...@jm... list.  Recently, our only worry was a dodgy array
that
  only wizards could examine, so not much threat, this is different.

  A bug has recently appeared in @fuse.  If you create a fuse without
  setting the ticks (@desc) or reset value (@drop) then examining the
fuse
  crashes us.

  Both the ticks and reset value MUST be set before examining it.

  Other bugs were highlighted in trying to determine the nature of this
bug.

  I created a fuse, set the ticks, reset value, and @csucc, @cfail.  To
try and
  investigate the bug I reset the @csucc and @cfail values to see were
they
  necessary to avoid the crash...  Resetting them also executed the
commands
  they had previously been linked to, which was odd.

  So, @desc and @drop new fuses, and be careful of executing
csuccs/cfails in
  resetting them.

  Humblehope.

Now, the first part of the problem (description & drop NULL pointers)
has been
fixed.

The second part, I suspect, is a side-effect of the fuse being on
Humblehope,
and of course they will trigger as you do things. But, since it is part
of
the bug report, has anyone got any other suggestions as to why this is
true?

Adrian.