Crossfire Mailing List Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

CF: Animate Weapon Blues (Was: Fix for Wizard crashes)



> > 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.

Agreed, this is kind of messy, inasmuch as in the save routine the 
pointer should be checked for nullness.

> > +    if(op->type==PLAYER)
> > +    {
> >       esrv_send_item(op, weapon);
> >       new_draw_info(NDI_UNIQUE, 0,op,"Your staff becomes a serpent and 
leaps to the ground!");
> > +    }

> Yes, this should fix the problem I noticed.

> But there are at least two other problems:

> >     remove_ob(weapon);
> >     /*    apply_special(op, weapon, AP_UNAPPLY);*/

> The apply_special() call is required.  Without it, we get problems 
like
> monsters with FLAG_READY_WEAPON and no weapon.

> apply_special() probably needs a new flag AP_FORCE_UNAPPLY that 
ignores
> FLAG_CURSED and FLAG_DAMNED.

Speaking of FLAG_DAMNED, the fact that it's overloaded to mean 
no-prayer, no-dimension-door and no-save makes for no-end-of-mischief. 
 Most notably, you have a problem when some random monster you knocked 
over drops a small shield of Doom or some such obnoxiousness, and now 
that odd bit of junk blocks your spells-- you fail to heal while 
standing on the pile, bump up against it if trying to d-door away from 
a bigger monster further down the hall, etc.

> >     SET_FLAG(weapon,FLAG_APPLIED); /* so it can take acid damage */

> Playing games with FLAG_APPLIED is not fun.  apply_special() does much
> more than setting FLAG_APPLIED for weapons.  Even if this works now, 
it
> may break easily.

> 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.

The problem here is that a golem can acquire an inventory, at least by 
missile/thrown weapons sticking in it, possibly in other ways.  Maybe 
the weapon should just be applied by the golem instead of some of the 
whole messy properties transfer going on earlier in the function?

Oh, incidentally-- I've heard from about 4 people now on rte-crossfire 
that say that ifi.uio.no is ignoring subscribe requests.
> --
> Jan
> -
> [you can put yourself on the announcement list only or unsubscribe 
altogether
> by sending an email stating your wishes to 
crossfire-request@ifi.uio.no]

> ---------------------------------------------------------------------
> To submit a bug: http://bugzilla.real-time.com
> To unsubscribe, e-mail: 
rte-crossfire-unsubscribe@listserv.real-time.com
> For additional commands, e-mail: 
rte-crossfire-help@listserv.real-time.com