FAangband 2.0.0

[tg122]

Do you use a tile multiplier bigger than 1x1 ? I uploaded a new version that improves the map view in FA (I forgot to copy that from the android version of V, sorry).

No, I'm using asci 1x1. I tried messing around with a bunch of my settings in the game and on my phone but haven't figured anything else out yet.

[Pete Mack]

1x1 is the only feasible choice, though it's hard to read. Wiyh 200' range attacks, anything less is too dangerous

[Nick]

I am still not able to reproduce this crash, including with provided savefiles. It's very annoying.

[Cuboideb]

I am still not able to reproduce this crash, including with provided savefiles. It's very annoying.

I feel the same.

I'm looking at every ocurrence of memset (I have the feeling that a large portion of the memory is wiped in some place). This line seems strange in ui-term.c (2626):

/* Assume no key */
memset(ch, 0, sizeof *ch);

It's valid ?

[tg122]

I once had an issue with the Angband Android app because of a storage permission issue. I had to move the directory out of the Android/data folder to fix it. Could this be somehow related to the scoped storage system with Android 11?

Edit: that was with an old phone. Currently the game is installed to Android/data.

[Nick]

I'm looking at every ocurrence of memset (I have the feeling that a large portion of the memory is wiped in some place). This line seems strange in ui-term.c (2626):

/* Assume no key */
memset(ch, 0, sizeof *ch);

It's valid ?

I think it's just zeroing the memory that's going to store a keypress, so it looks fine to me. Also it's been there for 10 years without causing a problem

[Cuboideb]

I had some problems with Android 10 concerning storage. I don't know if it's related to this.

There is a long standing bug in the android port that arises once in a while. A monster race pointer becomes null and the game crashes.

"...Google reports a lot of errors in mon_take_hit, get_lore, player_kill_monster. All related in some way to an invalid mon->race pointer..."

As I said, perhaps a rogue memset is wiping a chunk of memory.

[Cuboideb]

I think it's just zeroing the memory that's going to store a keypress, so it looks fine to me. Also it's been there for 10 years without causing a problem

Sorry, I didn't know that sizeof could be used without parenthesis.

[swim]

I am still not able to reproduce this crash, including with provided savefiles. It's very annoying.

Maybe this will help...

https://drive.google.com/file/d/1wblEvp7ny3Jhv8TW8BZdTDHFfU3LlIfR/view?usp=sharing

That's the full game directory including the save file.

[Nick]

Maybe this will help...

https://drive.google.com/file/d/1wblEvp7ny3Jhv8TW8BZdTDHFfU3LlIfR/view?usp=sharing

That's the full game directory including the save file.

Thank you. I can confirm that this crashes in Win 10, both in the directory you supplied and in a clean copy. Testing continues

[swim]

Thank you. I can confirm that this crashes in Win 10, both in the directory you supplied and in a clean copy. Testing continues

Thank YOU!
I loved what I saw of the game so far.

[Cuboideb]

Nick, which compiler do you use for windows ?

If I put a fresh copy of the executable made with mingw (32 bits), the savefile provided by swim doesn't crash.

[backwardsEric]

Nick, which compiler do you use for windows ?

If I put a fresh copy of the executable made with mingw (32 bits), the savefile provided by swim doesn't crash.

It's the mingw cross-compiler as picked up from the package, gcc-mingw-w64, in the ubuntu-18.04 runner on Gihub's Actions. configure was run with

env CFLAGS="-O2" ./configure --enable-release --enable-win --disable-curses --build=i686-pc-linux-gnu --host=i686-w64-mingw32

Because of Arralen's report of trouble with the Windows executable and Windows 8, have not been using the ubuntu-20.04 runner and its version of mingw.

[Nick]

The latest builds should not have the crash on moving house, thanks to backwardsEric for finding and fixing the bug.

It seems that someone had put some essential code inside an assert(), and then optimised out asserts in release builds...

[swim]

Excellent!
I'm going to give it a try right now!