Opened 9 years ago

Closed 9 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 9 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 9 years ago by takkaria

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

I'll take this one.

comment:3 Changed 9 years ago by magnate

  • Keywords inscriptions added

comment:4 Changed 9 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 9 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 9 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 9 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 9 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 9 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 9 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 9 years ago by magnate

  • Status changed from assigned to pending

Better fix pushed to staging in

comment:12 Changed 9 years ago by magnate

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