Crossfire Mailing List Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CF: Fix for Wizard crashes (fwd)
- To: crossfire (at) ifi.uio.no
- Subject: Re: CF: Fix for Wizard crashes (fwd)
- From: Mark Wedel <>
- Date: Sun, 28 May 2000 22:23:21 -0700
- References: <> <>
- Sender:
Jan Echternach wrote:
>
> > ---------- Forwarded message ----------
> > Date: Sat, 27 May 2000 03:17:11 +0200
> > From: Norbert Irmer <>
>
> > But this alone wasn't sufficient. When you left and reentered a map which
> > contains animated weapons the server still crashed, because it couldn't
> > find the animation for e.g. "animated dagger" in the saved map file.
>
> > int find_animation(char *name)
> > {
> > Animations search, *match;
> >
> > + if( !name || (strcmp(name,"(null)")==0) ) return 0;
>
> An ugly workaround that seems to work only if the libc's sprintf()
> implementation produces "(null)" when printing a null pointer as a
> string. I don't know how faces and animations are supposed to work,
> but a real fix is required here.
Agree with Jan on this one. If the libc's sprintf does not generate a '(null)'
when passed a null string (which several major OS's will not do), the server
will die at the sprintf, so that is really where any such fix would be needed.
Checking for a null name is valid.
Animations are pretty simple - items can have an anim <name> in addition to the
fact - this denotes an animated item, in which the face changes.
More important here is how something is getting the name 'animated dagger' in
the first place. The only place animations should come from is the 'animations'
file - if there is code someplace adding in animations, that is just plain
wrong.
> apply_special() probably needs a new flag AP_FORCE_UNAPPLY that ignores
> FLAG_CURSED and FLAG_DAMNED.
Perhaps - provided it only works for monsters and not players. Currently,
monsters already have some other special abilities (learn spells from spellbooks
without using them up), so letting them do this is perhaps OK. Otherwise, it
would seem that checking the return value of apply_special to see if it worked
or not and do the right thing accordingly.
> I think a better solution is to let hit_player_attacktype() damage
> unapplied objects in a golem. If this shouldn't be done for normal
> golems (type GOLEM), a new type for animated weapons could be created.
Not quite sure what you mean by damage unapplied objects in a golem. I haven't
looked at the animated weapon code to see exactly what it does however.
-
[you can put yourself on the announcement list only or unsubscribe altogether
by sending an email stating your wishes to ]