Opened 13 years ago

Closed 13 years ago

Last modified 13 years ago

#459 closed bug (fixed (in master))

Potions of Brawn sometimes have bad description, lower strength

Reported by: CunningGabe Owned by:
Milestone: 3.1.0 Keywords:


Two related bugs:

  • a potion of Brawn (or Nimbleness, etc) will sometimes lower your strength and then raise your strength. The random decremented stat should be something other than strength.
  • (tried this on a new character w/ debug commands): the first potion of Brawn I drank decreased my intelligence. Any other one I saw after that claimed that it would lower intelligence, even when other stats were decreased instead. Perhaps the description should simply be that it decreases a random stat and increases strength.

I plan to tackle this and submit a patch in a couple days - I've already started to look into it.

Change History (6)

comment:1 Changed 13 years ago by CunningGabe

After looking at the code a bit, my question is this: should the potion of Brawn always reduce intelligence (as the description currently states), or should it reduce a random attribute? effects.h has a concrete description for each potion where it raises one attribute while lowering another, while effects.c outlines a random stat decrement. I'm currently in favor of going with the fixed decrements given in effects.h - I think that makes the potions more useful than decreasing a random stat, and my guess is that is what was originally intended.

comment:2 Changed 13 years ago by anonymous

The Brawn/nimbleness/etc potions originally lowered a random stat, and then it was changed to always lower a specific stat instead.

comment:3 Changed 13 years ago by CunningGabe

No, they still lower a random stat - they just *say* that they always lower a specific stat :) I'll submit a patch.

comment:4 Changed 13 years ago by GabeCunningham

  • Resolution set to fixed
  • Status changed from new to closed

comment:5 Changed 13 years ago by GabeCunningham

fixed in [403fe08] (SVN r752).

comment:6 Changed 13 years ago by roustk@…

For robustness, I would suggest that the EF_BRAWN and EF_PLEASING cases be written in the style of the other cases. While right now it is true that A_STR==0, A_CHR==5, and A_MAX==6, it is remotely possible that this will not be true in the future. That would lead to a really-hard-to-find bug.

Also, using rand_int0 saves a future change when rand_int goes away.


Note: See TracTickets for help on using tickets.