3.2 release candidate is upon us!

[Dean Anderson]

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.

[Dean Anderson]

Hmm. Not my area but there was a lot of chat on IRC last night about how to make this work. Apparently there's an MSVC problem which requires the va_copy macro - I'm not sure if there is an alternative solution which is C89 compliant. I know we had to disable strict C89 checking some weeks ago because of a completely unrelated change elsewhere in the refactoring.

If you're interested in pursuing this, please take a look at http://trac.rephial.org/ticket/1254, which is what required the change in the first place. If you can find a different fix for this problem (which only affects AMD64 systems), which is C89-compliant and compiles under MSVC, please let us know.

As luck would have it, I'm running MSVC on an AMD64 system (exactly the combination that the fix says it won't work on) - although to complicate things slightly I'm using the x86 version of Windows 7, not the x64 version.

Unfortunately, this isn't really my area of expertise either - so I'm rather stumped as to an alternate fix.

If someone else comes up with a fix, I'm in a good position to test it, though.

By the way, the ticket seems to imply that va_copy is a noop on MSVC - with the implication that it will be ignored. This isn't the case. It actually stops compilation because it's an undefined symbol...

[Nomad]

I noticed that in these RC versions so far, Macros don't seem to be working properly in David Gervais tile mode. Using a Paladin, I tried to create a Macro to cast spells from the priest's spell book (trigger is F1, F2, and F3), but every time I try to use the macros, all it does is open up the spell book. I also noticed that this problem does not occur in ASCI mode.

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.

[Magnate]

I just grabbed the latest nightly (0a7b851) to merge the latest changes into my 3.2 beta source (to fix the gold bug and so forth), and discovered that there have been a couple of changes that stop it compiling in VS2010.

Both z-form.c and z-textblock.c have been modified to now use the va_copy compiler macro, but this macro is apparently C99 only, not C89 (which the Angband coding guidelines say should be used) and VS2010 does not support it.

Can someone look at re-doing that code change in a way that's supported in C89 and therefore more broadly compiler friendly?

Hmm. Not my area but there was a lot of chat on IRC last night about how to make this work. Apparently there's an MSVC problem which requires the va_copy macro - I'm not sure if there is an alternative solution which is C89 compliant. I know we had to disable strict C89 checking some weeks ago because of a completely unrelated change elsewhere in the refactoring.

If you're interested in pursuing this, please take a look at http://trac.rephial.org/ticket/1254, which is what required the change in the first place. If you can find a different fix for this problem (which only affects AMD64 systems), which is C89-compliant and compiles under MSVC, please let us know.

[Dean Anderson]

I just grabbed the latest nightly (0a7b851) to merge the latest changes into my 3.2 beta source (to fix the gold bug and so forth), and discovered that there have been a couple of changes that stop it compiling in VS2010.

Both z-form.c and z-textblock.c have been modified to now use the va_copy compiler macro, but this macro is apparently C99 only, not C89 (which the Angband coding guidelines say should be used) and VS2010 does not support it.

Can someone look at re-doing that code change in a way that's supported in C89 and therefore more broadly compiler friendly?

[Magnate]

I noticed that in these RC versions so far, Macros don't seem to be working properly in David Gervais tile mode. Using a Paladin, I tried to create a Macro to cast spells from the priest's spell book (trigger is F1, F2, and F3), but every time I try to use the macros, all it does is open up the spell book. I also noticed that this problem does not occur in ASCI mode.

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? It's hard to fix if we can't reproduce the problem.

[Nick]

For example, Sméagol is displayed as SmČagol; Angamaitë is displayed as AngamaitÎ. The ú in Númenorean shows up as a dot.

I think OSX is not latin compliant; xchars either need a different mapping or to be disabled.

[juggle5]

I thought I would try out the nightly (0a7b85172a) and noticed a bug: accented characters are not showing up properly, at least on mac os x.

For example, Sméagol is displayed as SmČagol; Angamaitë is displayed as AngamaitÎ. The ú in Númenorean shows up as a dot.

[tg122]

I noticed that in these RC versions so far, Macros don't seem to be working properly in David Gervais tile mode. Using a Paladin, I tried to create a Macro to cast spells from the priest's spell book (trigger is F1, F2, and F3), but every time I try to use the macros, all it does is open up the spell book. I also noticed that this problem does not occur in ASCI mode.

[tuppe666]

I wasn't able to reproduce this but I think I saw what the bug was and wrote some code to handle it.

It's checked into master now, so if you want to pull it down and try rebuilding again it might work. If not, please include the new backtrace. Thanks!

Fixed thank you. Wow Nomads tiles

[d_m]

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

You should put something up on kickstarter!

[takkaria]

Why the rush?

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

[Nick]

I think things will have settled a lot more by 2013.

Why the rush?

[takkaria]

You're telling me!

Is the refactoring considered to be mostly "done" now, or is the next version likely to be as different to this one as this was to the last?

Because it's a hell of a moving target for variant makers to keep up with if the core code for things like selecting a spell to cast and the like is completely re-written between versions...

It's not done yet, I'm afraid... there's a lot of old code to clean up. A lot of the cleanup has already been done and a lot of what is left is just finishing off what has been started, one way or another. I think things will have settled a lot more by 2013.

[Dean Anderson]

Yes, those few lines about code changes (bitflags, parsers etc.) conceal a colossal amount of refactoring. The code looks very different from the 3.1.x series.

You're telling me!

Is the refactoring considered to be mostly "done" now, or is the next version likely to be as different to this one as this was to the last?

Because it's a hell of a moving target for variant makers to keep up with if the core code for things like selecting a spell to cast and the like is completely re-written between versions...