Opened 10 years ago

Closed 10 years ago

#1212 closed bug (fixed (in master))

Too many confirmations by {!x} inscriptions

Reported by: Timo Owned by: takkaria
Milestone: 3.2.0 Keywords: inscriptions


I have inscribed my rods of recall with {!*!*!*} which should force me to confirm any action three times. Instead it forces me to confirm them six times. I thought I had seen it before with other inscriptions with drop confirmation before (I have three high-dice weapons and several DSM:s autoinscribed with !k!d), and now I am sure. Those confirmations are multiplied.

Actually I think it asks for each "!" for confirmation in inscription, because inscription !k!d!v=g also gives three prompts for dropping an item.

Testing...yes, it asks for confirmation for action for each "!" no matter what the action is. Basically any "!x" is treated like "!*".

Change History (12)

comment:1 Changed 10 years ago by Timo

Correction. !* asks confirmation for any action like it should and _in addition_ all "!" also asks confirmation, so you get minimum of "!" count of confirmations. Weird thing is that this is not plain correct confirmation + amount of "!", because that !k!d!v asks three times for dropping (which is confirmed action) and three times for zapping (which is not confirmed action).

comment:2 Changed 10 years ago by takkaria

  • Owner set to takkaria
  • Status changed from new to assigned

I'll take this one.

comment:3 Changed 10 years ago by magnate

  • Keywords inscriptions added

comment:4 Changed 10 years ago by Timo

I think this one also prevents using any @x<number> inscriptions, all I get is "zap which rod?" with \e\e\e\e\ez4 as macro and @z4 in rod.

For someone that uses *a lot of* macros and keymaps, that's really annoying.

comment:5 Changed 10 years ago by Taha

I can confirm both that the !* requests double confirmations in the latest nightly (24th), and that u# with the staff inscribed as @u# doesn't work. The book ones do work now, and I am not getting triple confirm for my m1b1G1!k!d!v inscriptions anymore.

I could have sworn that f0 wasn't working earlier, but just retested and it is okay for the moment.

comment:6 Changed 10 years ago by Taha

Also, rods inscribed as !!, for notify on recharge, require double confirmation to zap. The recharge notification does work.

comment:7 Changed 10 years ago by noz

I know why this is happening, but the fix is non-trivial. In takkaria's absence, I'll start looking at it.

comment:8 Changed 10 years ago by takkaria

just noticed this comment, i was planning to do a lookup of command -> key using the tables in cmd0.c, and make get_item take a cmd_code instead of the key pressed.

comment:9 Changed 10 years ago by noz

OK. Just seen this. I've done a temporary hack just to get it working, but it's a kludge, adding the key to the commadn structure. I'll try to achieve what you'd planned.

comment:10 Changed 10 years ago by noz

Have done a better fix, along the lines that takkaria suggested (thanks!), with the command->key lookup being done during get_item, and the command queue only holding the command code.

comment:11 Changed 10 years ago by magnate

  • Status changed from assigned to pending

Better fix pushed to staging in

comment:12 Changed 10 years ago by magnate

  • Resolution set to fixed
  • Status changed from pending to closed
Note: See TracTickets for help on using tickets.