5 May 2011 development release(s)

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

[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]

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-

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

[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]

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

[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]

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.

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

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

[buzzkill]

Before we go any further, I'm discussing what I believe to be Mass Banishment (hereafter referred to as Banishment), the one that removes everything around you, not the one that targets a specific race. My bad if I'm off topic.

Okay, let me put it this way: this is an "obvious rule patch", a change in the rules solely to prevent some undesirable behavior, that makes no sense in-universe. Banishment destroys monsters. Naturally that means that the monsters' inventories are gone. Why should it affect things on the floor? The spell explicitly targets monsters, not terrain or objects.

Your making assumptions that aren't necessarily true. Literally, Banishment should banish things. Who's to say that it's only monsters. Using your logic, I could just as easily definitively state it to be only treasures. Banishment targets monsters only because that's what it has always done. It could just as easily be interpreted to banish all things in the vicinity.

Now, obvious rule patches can be acceptable or even important if the alternative is seriously broken. Then there's an obvious strong justification -- if we didn't do this, then this undesirable result would occur, with a significant impact on the game. If you don't have that kind of strong justification, though, then obvious rule patches are undesirable, because they break the illusion of a consistent world.

Since when is a "strong justification" needed to push something into nightlies. While the current implementation isn't broken, it is highly exploitable by the mage class, or by anyone with the right scroll. Consistency isn't Angband's strong suit, legacy is. Lot's of things in Angband make no sense and are inconsistent. These things are generally accepted because player are used to them and/or it's the way it always been.

Basically, what we have here is a corner case that is, yes, technically exploitative. The requirements for exploitation require you to be playing a specific class and to have gotten that class's last spell book, so there's a very narrow window for exploitation before you go on to win the game.

An exploit none the less. Why not fix it? Are we still "making the game harder" or has that been abandoned already. In terms of cost/benefit, the best way to make the harder is to eliminate known exploits.

If you patch the game to remove this exploitation, then all the other presumably-justified uses of the Banishment ability in more limited form (scrolls and staves) have this bizarre behavior for no real gain.

It's not bizarre behavior, it's just a little different from what we're used to. It might even produce unanticipated good side effects, like players actually fighting monsters rather than skipping by them. Of course, they would still have the option to skip by them, just at a cost.

In other words, I don't think the cost-benefit is there.

The benefit is there, what's the cost? I doubt that coding this would be that big of a deal, but what do I know.

[Max Stats]

My day job, oddly enough, is software development. But thanks for the compliment.

Aren't software developers usually obfuscators instead of explainers?

[Nick]

What is your day job? Lawyer? You have an amazing way of explaining things clearly.

Not a lawyer, then

[Magnate]

Magnate added some x2 brands, with the idea that they might be more viable for off-weapon branding (though as far as I'm aware nothing uses them yet in the standard set). Feel free to suggest better messaging.

The x2 cold brand is on Paurnimmen in the nightlies. So far it doesn't appear to be dramatically unbalancing.

[Derakon]

Here's my votes for weak/strong brands:

Frost: chill / freeze
Fire: singe / burn
Lightning: shock / zap (I feel "zap" sounds stronger than "shock", personally...)
Acid: corrode / dissolve
Poison: poison / strongly poison (...I got nuthin', aside from that "weakly X" is worse IMO than "strongly X" since the weak variant is still stronger than a bog-standard attack)

My day job, oddly enough, is software development. But thanks for the compliment.