3.2 release candidate is upon us!

[Chud]

No gold or equipment?

Hmm. I just created new Gnome Mage in the most current nightly (revision d1a64ee55c, Windows) and she came up with no gold AND no equipment. This might be a challenge initially...

[Magnate]

Reading through the change log, I'm actually very pleasantly surprised by it.

I'd got the impression - a false impression it now seems - from reading what people have been saying about the nightly builds that there were big changes happening on an almost daily basis.

But that change log looks nicely conservative (I think Vanilla should change only incrementally, and leave radical stuff to the variants; only after something big is tried and tested in a variant and reasonably universally liked should it be back-ported to V).

So - how long do you guys reckon it will take to go from a release candidate to an actual 3.2 release?

Personally I think 3.2 will be out before the end of the year, though there may well be a 3.2.1 in Jan/Feb with fixes.

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.

I think the issues with changes in nightlies is not that they are large (as you observe, there aren't many of those over the lifetime of a new release), but that they are immediately noticeable, even if small. Since nightlies appear much more quickly than the length of the average game, people have to cope with changes mid-character. I think that's harder than anybody likes to acknowledge.

[PowerDiver]

Could you compile it with CFLAGS+=-g, run it in gdb and paste the backtrace?

I should have mentioned I got the code with git clone as per rephial.

Reading symbols from /home/eddie/Angband/nightlies/angband/angband...done.
(gdb) run
Starting program: /home/eddie/Angband/nightlies/angband/angband 
angband: game-cmd.c:270: cmd_set_arg_choice: Assertion `game_cmds[idx].arg_type[n] & arg_CHOICE' failed.

Program received signal SIGABRT, Aborted.
0x0012d422 in __kernel_vsyscall ()
(gdb) trace
Tracepoint 1 at 0x12d422
(gdb) backtrace
#0  0x0012d422 in __kernel_vsyscall ()
#1  0x002ad651 in raise () from /lib/tls/i686/cmov/libc.so.6
#2  0x002b0a82 in abort () from /lib/tls/i686/cmov/libc.so.6
#3  0x002a6718 in __assert_fail () from /lib/tls/i686/cmov/libc.so.6
#4  0x08065ddb in cmd_set_arg_choice (cmd=0x8117444, n=0, choice=1) at game-cmd.c:270
#5  0x080ca6ad in get_birth_command (wait=true) at ui-birth.c:841
#6  0x08065393 in cmd_get (c=CMD_BIRTH, cmd=0xbffff0f8, wait=6) at game-cmd.c:234
#7  0x0804dd87 in player_birth (quickstart_allowed=false) at birth.c:1075
#8  0x0805d5f0 in play_game () at dungeon.c:1746
#9  0x080e558f in main (argc=1, argv=0xbffff4b4) at main.c:468
(gdb)

[takkaria]

I downloaded, ./autogen.sh, ./configure --with-no-install, compiled, ran, and immediately got an assert error after I "Press any key to continue". A quick look suggests that the problem might be that with no savefile, there is no stack of previous commands. However, I don't see how the money bug described above could happen if the code dies before the birth process.

Is there any likelihood this could be platform specific? Where does that mean I should look? I've never looked at the command code before, so I'd appreciate a hint where to start looking.

angband: game-cmd.c:270: cmd_set_arg_choice: Assertion `game_cmds[idx].arg_type[n] & arg_CHOICE' failed.

Could you compile it with CFLAGS+=-g, run it in gdb and paste the backtrace?

[PowerDiver]

I downloaded, ./autogen.sh, ./configure --with-no-install, compiled, ran, and immediately got an assert error after I "Press any key to continue". A quick look suggests that the problem might be that with no savefile, there is no stack of previous commands. However, I don't see how the money bug described above could happen if the code dies before the birth process.

Is there any likelihood this could be platform specific? Where does that mean I should look? I've never looked at the command code before, so I'd appreciate a hint where to start looking.

angband: game-cmd.c:270: cmd_set_arg_choice: Assertion `game_cmds[idx].arg_type[n] & arg_CHOICE' failed.

[Lord Fell]

How quickly are bugs being traced and squashed with the 3.2 candidate? Will you post to the thread when a reported bug is fixed?

Also, I'm wondering if my tinkering with yeeks & harpies as playable races will be affected by the 3.2 changes, or if the edit files will keep the same format.

[Nomad]

Sorry about that! This may be a problem with the autobuilder.

Since I don't normally play the windows port (I run it through WINE) can you be specific about which files you expect to see where in the zip file?

Thanks!

There should be an "8x16.bmp" and "mask8x16.bmp" going into the \lib\xtra\graf directory.

[d_m]

Incidentally, while I see that the code for my new tile set has been implemented and all seems to be working fine, the actual BMP files aren't included in the zip at the moment.

Sorry about that! This may be a problem with the autobuilder.

Since I don't normally play the windows port (I run it through WINE) can you be specific about which files you expect to see where in the zip file?

Thanks!

[ewert]

Can't help with the starting char problem, except to mention that there was also maximize stat problems with starting first chars per save file (guess these were fixed, with that mention in change file). So you guys are probably not imagining things.

[Nomad]

Yeah it does, but I usually get more stuff with the 2. char and I get money.

Yep, I get the exact same thing. Start a new game, create a High-Elf warrior, and he starts with zero gold. He dies, I reload that save file and create a second character to the same specs, and this one has identical starting gear (in fact, he's got more food and torches) but starts with 243 AU.

Incidentally, while I see that the code for my new tile set has been implemented and all seems to be working fine, the actual BMP files aren't included in the zip at the moment.

[Philip]

Yeah it does, but I usually get more stuff with the 2. char and I get money.

[Derakon]

I believe the way starting gold currently works is that you get a starting allowance based on social status / unallocated stat points, and then you automatically buy your starting gear using that allowance. It may well be (haven't checked) that if your gear costs more than the allowance provides, then you buy it anyway but start with zero money.

[Philip]

Old versions had gold inversely related to stats, with randomness tossed in on top. I don't know how much of that has been kept. There have been changes to initial equipment and to prices, and pricier equipment now means less money.

It's probably a bug, but it might not be.

Yeah I still see it in the 3.2 release candidate.

[takkaria]

Hmmm....

I tried merging the 3.2 changes to 3.1.2v2 with my own homebrewed changes to it last night, and it seems that the internals of the code have changed much more than the change list would indicate.

There has been a lot of refactoring under the hood which - while not changing the gameplay - does mean that some functions that I modified no longer exist, and many flags that my code uses now work in a different way, and so forth.

I think the easiest way for me to incorporate the 3.2 changes is actually to scrap what I've done to 3.1.2 so far (it's only few evening's worth of work anyway) and reproduce the same functionality in 3.2 by hand.

Yup, we aim to keep people on their toes.

[Dean Anderson]

Hmmm....

I tried merging the 3.2 changes to 3.1.2v2 with my own homebrewed changes to it last night, and it seems that the internals of the code have changed much more than the change list would indicate.

There has been a lot of refactoring under the hood which - while not changing the gameplay - does mean that some functions that I modified no longer exist, and many flags that my code uses now work in a different way, and so forth.

I think the easiest way for me to incorporate the 3.2 changes is actually to scrap what I've done to 3.1.2 so far (it's only few evening's worth of work anyway) and reproduce the same functionality in 3.2 by hand.