3.2 release candidate is upon us!

[Sirridan]

Why not get rid of percentile's all together? I never understood why they would be used in the first place.

[PowerDiver]

Good catch - presumably there is a misplaced % somewhere, because stat loss works fine between 18/10 and 18/100. How did you get to 18/04 in the first place? I thought all increments were in 10s nowadays?

No, increments haven't changed. I went from 18 to 18/14 to 18/04 to 18/03.

[Magnate]

Stat decrease seems messed up. I quaffed a gain-1-lose-1 and pre-bonus str dropped from 18/04 to 18/03. Rather than fixing the code for things between 18/01 and 18/09, perhaps it is time [i.e. before 3.2 release] to make the rule that the player's pre-bonus percentile is always a multiple of 10.

Good catch - presumably there is a misplaced % somewhere, because stat loss works fine between 18/10 and 18/100. How did you get to 18/04 in the first place? I thought all increments were in 10s nowadays?

[PowerDiver]

Stat decrease seems messed up. I quaffed a gain-1-lose-1 and pre-bonus str dropped from 18/04 to 18/03. Rather than fixing the code for things between 18/01 and 18/09, perhaps it is time [i.e. before 3.2 release] to make the rule that the player's pre-bonus percentile is always a multiple of 10.

[Nick]

I'd really like it if we could get it all over and done with much quicker, but having made a few releases now, experience tells me that it'll take a few years. I'd expect, though, that in even one year's time a lot of the changes will be pretty close to done.

If I could work full-time on Angband...

I hope I didn't come across as critical - believe me, I'm not in any position to point the finger.

[Magnate]

How curious. The previous time I used it was to aim at a monster. Is that how you tested yours? Of course, it would be very weird if that was the difference. I'll save before testing rods in the future and see if I can get something reproducible.

It wasn't, but just I ran a separate test where the first attempt was aimed at a monster and I got the same result.

[PowerDiver]

I can't reproduce this. I get "Your Iron Rod has recharged" with no other info, and the rod remains unIDd and {tried}.

How curious. The previous time I used it was to aim at a monster. Is that how you tested yours? Of course, it would be very weird if that was the difference. I'll save before testing rods in the future and see if I can get something reproducible.

[Magnate]

I was resting to recharge an unided rod so I could test it on a trap, and got the message that my rod of disarming had recharged. Sure enough, a rod of disarming in my pack. I am nearly certain [what a meaningless phrase!] it was unaware before the message.

Has this already been reported? I vaguely remember reading something similar, but couldn't find anything searching the forum on various words starting recharg nor clicking on the new bugs link on trac.

I can't reproduce this. I get "Your Iron Rod has recharged" with no other info, and the rod remains unIDd and {tried}.

[PowerDiver]

I was resting to recharge an unided rod so I could test it on a trap, and got the message that my rod of disarming had recharged. Sure enough, a rod of disarming in my pack. I am nearly certain [what a meaningless phrase!] it was unaware before the message.

Has this already been reported? I vaguely remember reading something similar, but couldn't find anything searching the forum on various words starting recharg nor clicking on the new bugs link on trac.

[Magnate]

Huh. Wow. Yep, I can reproduce this (also on Windows) and I stand corrected - it seems to be an entirely separate issue from '@p1' not working. It affects mage casting as well; macro 'mab' to the '#' key and it works fine if bigtile or double/triple tile modes are all off, stalls at selecting the book if any of them are switched on.

The issue still occurs if you use 'm1b' instead of 'mab', and when I tried macroing 'maa' it did select the book but not the spell, suggesting that the second 'a' went through but the first one didn't.

ETA: spell macros work fine in tile mode if bigtile and double/triple are turned off, and the issue doesn't seem to affect other types of inscription-based macros: I macro'd "a1" to the '#' key and that selected the wand inscribed '@a1' quite happily regardless of whether I had bigtile mode on or not.

Good luck tracking this one down, folks...

Yes, I too can now reproduce this, and it is indeed totally separate from the @p1 inscriptions issue. I couldn't reproduce it because I was trying with "normal" tiles. As soon as you extend tile_width or tile_height >1, the problem occurs.

This is ticket #1262.

[Nomad]

I went back to double check the issue I described and can confirm the macros will not work for me in tile mode, and I can get them to work in ASCI mode. However, I just realized that the only way I can get them to work in ASCI mode is if Bigtile mode, double tile mode, and triple tile mode are all unchecked.

To create the macros, I went to options > Interact with macros > create a macro > F1 > pae (pushed enter) > then pushed enter again > append macros to file. I did this 2 more times (F2=pab, F3=paf).

When I hit F1, F2, or F3 in tile mode (or ASCI mode with bigtile, double tile, or triple tile checked), my spell book pops up and it says "recite which prayer"? However, if I go to options > graphics > none, and then I push F1, F2, or F3, it works. If I go back into options > Graphics, and I put a checkmark next to bigtile mode, double tile mode, or triple tile mode, it does not work.

I also can confirm that it happens with a new save fie as well. I have attached my PRF file. Hope this helps.

Edit: Also, if it helps, I'm running windows XP 32 bit.

Huh. Wow. Yep, I can reproduce this (also on Windows) and I stand corrected - it seems to be an entirely separate issue from '@p1' not working. It affects mage casting as well; macro 'mab' to the '#' key and it works fine if bigtile or double/triple tile modes are all off, stalls at selecting the book if any of them are switched on.

The issue still occurs if you use 'm1b' instead of 'mab', and when I tried macroing 'maa' it did select the book but not the spell, suggesting that the second 'a' went through but the first one didn't.

ETA: spell macros work fine in tile mode if bigtile and double/triple are turned off, and the issue doesn't seem to affect other types of inscription-based macros: I macro'd "a1" to the '#' key and that selected the wand inscribed '@a1' quite happily regardless of whether I had bigtile mode on or not.

Good luck tracking this one down, folks...

[tg122]

I think there may be a problem with your macros. I can create and use macros without problems in David Gervais tile mode. Can you provide some more details about the macros which work in ascii but not with these tiles - or maybe attach a prf file containing them?

I went back to double check the issue I described and can confirm the macros will not work for me in tile mode, and I can get them to work in ASCI mode. However, I just realized that the only way I can get them to work in ASCI mode is if Bigtile mode, double tile mode, and triple tile mode are all unchecked.

To create the macros, I went to options > Interact with macros > create a macro > F1 > pae (pushed enter) > then pushed enter again > append macros to file. I did this 2 more times (F2=pab, F3=paf).

When I hit F1, F2, or F3 in tile mode (or ASCI mode with bigtile, double tile, or triple tile checked), my spell book pops up and it says "recite which prayer"? However, if I go to options > graphics > none, and then I push F1, F2, or F3, it works. If I go back into options > Graphics, and I put a checkmark next to bigtile mode, double tile mode, or triple tile mode, it does not work.

I also can confirm that it happens with a new save fie as well. I have attached my PRF file. Hope this helps.

Edit: Also, if it helps, I'm running windows XP 32 bit.

[Dean Anderson]

Thanks for this. I'm sorry - I wrote my earlier reply before I noticed that d_m pushed a fix to staging after I went to bed last night. It's very similar to yours, so I've pushed it to master and you should be able to test it - either update from github and compile yourself or wait a couple of hours for the next nightly build.

Please let us know if it's fixed the problem.

That appears to work (as far as I can tell). It's the same solution I found, except it specifically targets MSVC rather than simply targeting any compiler which doesn't support va_copy.

While we're on the "MSVC Specific" subject, I had to make another couple of trivial changes to avoid compiler conflicts...

1. I had to change GF_INERTIA to GF_INERT to avoid conflicts with a GF_INERTIA definition in Windows 7's windows.h (I think this one has been mentioned before).
2. I had to change the "class" and "race" members of the birther structure to "pclass" and "prace" ("class", of course, being a reserved word in C++ - and MSVC doesn't like you calling things that even if you're doing plain C).

Neither of these actually stop it compiling, but they both produce warnings...

[Magnate]

Oh, I hit this in rd1a64ee55c last night. It's actually the inscriptions at fault, since I'm not using macros, just numbered books. I found that '@p1' on a priest book didn't work, but '@m1' does, even if you use the 'p' key to cast.

I'm not convinced it's got anything to do with tile mode, though: I've been using my own tiles, but I switched over to ASCII and still had this issue.

Well, the OP said specifically that he had a macro that worked in ascii but not in tile mode. That sounds very unlikely, but that's what he said.

I think this issue is very narrow indeed: I think it's specific to the p command and it's specific to @pX inscriptions where X is a single digit. For example, I can macro F2 to paa and it works fine for casting the first spell from the book I'm carrying in slot a.

In fact, testing reveals that this isn't a macro issue at all: the 'p' command does not recognise @pX inscriptions, whether in a macro or from direct input.

The p command was removed recently (by accident) and restored. I think somewhere during this process this problem was introduced.

I have opened ticket #1260 for this.

[Magnate]

After looking on the Internet, where there are lots of discussions about va_copy and MSVC, I've added...

/*
 * Some compilers don't have va_copy predefined.
 * This redefinition may work as a substitute on some of them.
 */
#ifndef va_copy
#define va_copy(ap1, ap2) ((ap1) = (ap2)) 
#endif

...to the top of each of the two files that use it.

Some quick testing (acquiring random items - including artefacts - and identifying them) hasn't crashed it yet, so it might be a potential workaround for MSVC compilers - but I'm not qualified to judge for certain.

Thanks for this. I'm sorry - I wrote my earlier reply before I noticed that d_m pushed a fix to staging after I went to bed last night. It's very similar to yours, so I've pushed it to master and you should be able to test it - either update from github and compile yourself or wait a couple of hours for the next nightly build.

Please let us know if it's fixed the problem.