> No crashes as of yet from it, but one small bug that I cant figure out
^^^^^^^^^^ Hehe. Something was done right eh? Well, moving on...
> In medit, when I try to aff invis, blind, whatever, it sets the
> aff to the aff after the aff in the table (confused yet? I am).
Ok. Using OLC to set affects on (in this case) a mob.
> IE
> AFF_BLIND (1)
> AFF_INVIS (2)
> AFF_DETECT_EVIL (3)
>
> <1hp 20ma 20mv> medit 4000
> <1hp 20ma 20mv> aff blind
> Affect flag invisible set
> <1hp 20ma 20mv> aff blind
> Affect flag invisible removed
> <1hp 20ma 20mv> aff invisible
> Affect flag detect_evil set
> <1hp 20ma 20mv> aff invisible
> Affect flag detect_evil removed
>
> Im not exactly sure where to look for the bug here....
Now the solution is different depending on what version of OLC you are
running.
But, I know you are using OLC 2.0 since only my function says what flag you
are toggling and whether it was set or removed... *innocently whistles*
in ed_str_flag_toggle change:
STR_TOGGLE_BIT((FLAG *) arg, ((struct flag_type *) par)[value].bit );
to
STR_TOGGLE_BIT((FLAG *) arg, value );
and this:
printf_to_char( ch, "%c%s flag %s %s.\n\r", toupper(n_fun[0]),
&n_fun[1], (( struct flag_type * ) par)[value].name,
STR_IS_SET( (FLAG *) arg, ((struct flag_type *)
par)[value].bit )
? "set" : "removed" );
to
printf_to_char( ch, "%c%s flag %s.\n\r", toupper(n_fun[0]),
&n_fun[1], STR_IS_SET( (FLAG *) arg, value )
? "set" : "removed" );
This will remove the error, and remove a bit of the message as well. Another
option would be to insert a -1 after each instance of value:
(( struct flag_type * ) par)[value-1].name
etc. This is a hackish way to do it and only works if your affect table is
in sequential order... (mine is, so I don't have to worry about it atm), but
does leave one open to a crash if your affect table is tinkered with in the
wrong way.
If you want to approach this problem in another light, that is an exercise
for the reader.
Ammaross Danan
Ardenmore
http://www.ardenmore.com
telnet://mud.ardenmore.com:3200
