[CF-Devel] New armour case
Mark Wedel
mwedel at scruznet.com
Tue May 22 20:26:00 CDT 2001
On Wed, 23 May 2001, dnh wrote:
>
Is there any major objections to me making a new case light_armour and
>
moving bracers and girdles into it. Then allowing ruggilli and Q's to
>
wear light armour only. The only real gains are, up to 50% acid resistance
>
or +1 magic, +2 str and con and for ruggilli plus an extra 30 to fire
>
(which it doesn't really need).
>
>
I feel looking at the body shape of the Q that is is both acceptable and
>
fun. The beholders and fireborn would not be able to wear any of this
>
though.
>
>
It has also been mentioned that some races, in particular beholders,
>
should be able to wear more than two rings. I put that up to
>
consideration.
Rather than make another general case, I would much rather there be
specific yes/no case for item types, and not just general objects.
For example, being able to give the can_use_shield as a specific
granularity would be nice (I would think that if Q's can use swords,
they should have this).
Likewise with can_use_bracers, can_use_boots, ... and so on.
I would rather go this specific (1 item type) case than go for a
sort of general approach which we'll probably say pretty quickly
still isn't good enough.
I don't want to get into particular races at this point - I'm more interested
in getting an implementation that we will be happy with for a long time.
Which, if we take the above a bit further, perhaps a more general approach
could be called for (instead of using 20 can_use flags), have item_allowed and
item_denied fields, ie, for a Q:
item_allowed all
item_denied armor, boots, helmet, rings
Where as something like the fireborn may have something like:
item_allowed ring,scroll,wand,potion,rod
item_denied all
Fortunately, players don't equip/unequip stuff all that often, so parsing
such a form shouldn't be too costly (and if really desired, it could be made
so that it is only parse at load up or in major changes, and we just have a
bit field for all the object types, with 1/0 values if the player can use the
item or not).
This method is a bit more work, although I'm not precisely how hard, but
has the advantage that it allows as much flexibility as we want - if new
item type is added in the future, don't need to worry about the can_use
flag - just need to update the parsing routine which will almost
certainly be easier (and plus, with the default cases, may not even
need to modify monsters/players much).
Note having item_denied by the default (since it makes sense for most
monsters) works out best, but most players would have item_allowed all.
Just my not so random thoughts.
More information about the crossfire
mailing list