5 May 2011 development release(s)

[SSK]

For what it's worth, I side with Derakon on Banishment (the spell at issue here is Banishment, not Mass Banishment--the one where you eliminate a monster symbol, formerly known as "genocide"). Leave it alone. Mages are weak enough and others don't get unlimited banishment except if they have Celeborn--thus its limited availability is already a balancing factor.

As for branding language:

I like:

Flame:
STRONG: Scorch, Incinerate, Immolate, Burn
WEAK: Singe, Braise, Char

Frost:
STRONG: Freeze
WEAK: Chill

Lightning:
STRONG: Electrocute
WEAK: shock, zap

Venom:
STRONG: Poison
WEAK: Sicken, toxify, blight

Acid:
STRONG: Blister, Burn (if we decide to go with a different word for flame)
WEAK: corrode, scathe

I also propose better language for *slay* vs slay for dragon and demon (don't like "fiercely smite" much)

*SLAY*: Wallop, Lambaste, Smash
slay: smite

Taking this further, one could also extend specific words to weapon types:

Blunt: Strike, Hit, bash
Slashing swords: Slash
Scythes: slice
puncturing weapons: Impale, pierce

But this would be harder and there are combo type weapons like Halberds...

[Taha]

Mass Banishment, if it also removes items, becomes Destruction minus the messy terrain, but with damage to the character so less useful as an escape. If we really want to go down that road (my vote is against it), then I think we are better off removing Mass Banishment rather than changing it into a less useful version of Destruction.

Normal one monster Banishment is just as easy if you are talking about clearing pits with a mage; by the time a mage has the spell, he has more than enough mana to cast it repeatedly, and it can be done from any range.

With destruction removing artifacts from the floor, luring the monsters out of an undead pit before destructing them has already become a relevant strategy. This just leaves you with another spell requiring the same thing.

[Max Stats]

Bug ignoring unidentified rod

I have hard-coded some squelch settings into my copy of the game, so that items that I think are always useless are pre-squelched to save myself the trouble. Because of this, I have several items that are squelched before they are identified. I had an unidentified rod in my inventory, and I used the ignore command on it. My choices were:

a) This item only
b) Unignore all Iron Rod

I suspected that this meant that this was one of the rods I had "pre-squelched" so I identified it, and sure enough it was. So if you try to ignore an unidentified item that would be squelched if it were identified, you get tipped off that it is an item in your squelch list.

A very patient player could ID an item for free (assuming it had been seen in previous games to show up in the squelch list) by squelching items of the same kind, ignoring the unknown item (but aborting the command), then refining the squelch list and repeating until the item is isolated. It's not a major exploit, because it requires a lot of work for a pretty minor gain.

[SSK]

I have hard-coded some squelch settings into my copy of the game, so that items that I think are always useless are pre-squelched to save myself the trouble. Because of this, I have several items that are squelched before they are identified...

Actually, this brings up an issue I'd wanted to raise:

Can we have the default at the beginning of the game set to ignore certain worthless items without having to set them all by hand every dang time you play?

I mean can't we have it begin as default to squelch "bad" for quality settings instead of "none"?

[Max Stats]

Can we have the default at the beginning of the game set to ignore certain worthless items without having to set them all by hand every dang time you play?

I would like this to be an option on the squelch screen, to save the current squelch settings to a .prf file to be used as starting squelch settings when creating a new character. This would work best if saved to a class-specific pref file (Warrior.prf, Mage.prf, etc.) because different classes find different items useful, and you won't have to worry about making a new copy when you start a character with a different name.

I mean can't we have it begin as default to squelch "bad" for quality settings instead of "none"?

This fix is as simple as changing a '0' to a '1' in squelch_init (or maybe it is init_squelch, not 100% sure ATM).

[takkaria]

I have hard-coded some squelch settings into my copy of the game, so that items that I think are always useless are pre-squelched to save myself the trouble. Because of this, I have several items that are squelched before they are identified. I had an unidentified rod in my inventory, and I used the ignore command on it. My choices were:

a) This item only
b) Unignore all Iron Rod

I suspected that this meant that this was one of the rods I had "pre-squelched" so I identified it, and sure enough it was. So if you try to ignore an unidentified item that would be squelched if it were identified, you get tipped off that it is an item in your squelch list.

A very patient player could ID an item for free (assuming it had been seen in previous games to show up in the squelch list) by squelching items of the same kind, ignoring the unknown item (but aborting the command), then refining the squelch list and repeating until the item is isolated. It's not a major exploit, because it requires a lot of work for a pretty minor gain.

Hmm, did you hardcode this in the pref files or in the source code?

[Max Stats]

Hmm, did you hardcode this in the pref files or in the source code?

I did it in the source code, as described here (I think the function names have changed since I wrote this post). Is it possible to do it in the pref files? That would probably be a better solution, since I wouldn't have to keep reinserting the code every time I update to a new version.

[Spacebux]

Separate Squelch Issue

I noticed no longer is one able to say kill a certain # of a specific item from inventory or quiver. However, if you tried to say, drop x items from a stack of y in one of your slots, then kill that item on the ground, it actually does not destroy those items just dropped.

The kill code was working fine in 3.2.0, I thought... I know you guys are working hard on revamping the item-handling code, but this current revision of kill/squelch is a bit spotty.

I like the work and effort being done to increase usability of item squelch in the vanilla code, but at times it seems like for all the effort you are putting into the project, its coming out as a less useful solution to what already exists. (***Please, I'm trying to be tender here!***)

If you can cinch up the 'k'ill code a tad more, then you will have improved on the older 3.2.0 system.

-SBux-

[Magnate]

I noticed no longer is one able to say kill a certain # of a specific item from inventory or quiver. However, if you tried to say, drop x items from a stack of y in one of your slots, then kill that item on the ground, it actually does not destroy those items just dropped.

The kill code was working fine in 3.2.0, I thought... I know you guys are working hard on revamping the item-handling code, but this current revision of kill/squelch is a bit spotty.

I like the work and effort being done to increase usability of item squelch in the vanilla code, but at times it seems like for all the effort you are putting into the project, its coming out as a less useful solution to what already exists. (***Please, I'm trying to be tender here!***)

If you can cinch up the 'k'ill code a tad more, then you will have improved on the older 3.2.0 system.

-SBux-

I'm pretty sure this has been mentioned before, but just for clarity: we're trying to move from a system where items can actually be destroyed to one where they are actually just hidden from view (squelched). The current system has more or less moved to this new paradigm, but one of the wrinkles yet to be ironed out is that you can't squelch part of a stack, whereas you could previously destroy part of a stack. This will of course be sorted out eventually.

[Spacebux]

Fixed. This fixes crashes from eating a stack of food off the floor, quaffing potions off the floor, and reading scrolls off the floor when pressing 'n' or CTRL-V when the item count reaches 0.


In cmd-obj.c, insert:

void do_cmd_use(cmd_code code, cmd_arg args[])
{

int item = args[0].item;
object_type *o_ptr = object_from_item_idx(item);
int effect;

if (!item_is_available(item, NULL, (USE_INVEN | USE_FLOOR | USE_EQUIP))) {

msg("That item is not within your reach.");
return;

}
bool ident = FALSE, used = FALSE;
bool was_aware = object_flavor_is_aware(o_ptr);
int dir = 5;

Maybe that is not the best place for it, but that check prevents the code from going further, generating segmentation faults and worse.

-SBux-

Update:
My artifacts were no longer activatable...

I modified my code above to included the USE_EQUIP flag check. My items are activatable again.

-SBux-