Assertion failed in object\identify.c

[jens]

Playing the latest nightly (june 10) on Windows 7. I've downloaded the master branch from Git and compiled it myself with mingw. When checking the version ingame it says 3.2 though... The character I am playing was created in the previous nightly (angband-rd39a356436), and using my updated artifacts (noticed this since I had to increase the limit for artifacts to 140).

I just managed to kill Ar-Pharazôn, then the game crashed.

[Magnate]

Playing the latest nightly (june 10) on Windows 7. I've downloaded the master branch from Git and compiled it myself with mingw. When checking the version ingame it says 3.2 though... The character I am playing was created in the previous nightly (angband-rd39a356436), and using my updated artifacts (noticed this since I had to increase the limit for artifacts to 140).

I just managed to kill Ar-Pharazôn, then the game crashed.

Sorry, the savefile is no help because it has your additional artifacts in it and won't load. It's impossible to tell whether the crash is something to do with that or not. The assert is in object_flavour_is_aware ... have you by any chance added a new INSTA_ART object for a new light source, or something?

[jens]

Did you try to just increase the number of artifacts in limits.txt?

The artifact list is the one I posted here earlier, no new light source, only Evenstar with INSTA_ART.

I just managed to Ar-Pharazôn again, no crash this time. Items:
armor of Elvenkind, DSM of Craftmanship, Raal's Tome

[Magnate]

Did you try to just increase the number of artifacts in limits.txt?

The artifact list is the one I posted here earlier, no new light source, only Evenstar with INSTA_ART.

I just managed to Ar-Pharazôn again, no crash this time. Items:
armor of Elvenkind, DSM of Craftmanship, Raal's Tome

Then the likelihood is that he tried to drop something illegal when you killed him the first time - like an artifact for which there was no base kind. When you re-instated Evenstar, did you restore the "jewel" entry in object.txt?

[jens]

Then the likelihood is that he tried to drop something illegal when you killed him the first time - like an artifact for which there was no base kind. When you re-instated Evenstar, did you restore the "jewel" entry in object.txt?

Don't monsters get their items when the level is generated? Ar-Pharzôn was generated from the start ( He was sleeping just a few steps from the staircase).

I did not change anything in object.txt, but I just checked, and the jewel entry is the same as it always was. So as far as I can tell you did not change it for this release.

I'll switch to testing with a new char as soon as there is a new nightly to download ;-)

[Magnate]

Don't monsters get their items when the level is generated? Ar-Pharzôn was generated from the start ( He was sleeping just a few steps from the staircase).

Yes, but the assertion failure is in object_flavour_is_aware, which is not checked until you can see/detect the object!

I did not change anything in object.txt, but I just checked, and the jewel entry is the same as it always was. So as far as I can tell you did not change it for this release.

I'll switch to testing with a new char as soon as there is a new nightly to download ;-)

Good. If it happens again with a nightly and I can reproduce it, I'll fix it.

If there are no objections I'll merge your artifact changes this weekend btw, so they'll be in the next nightly.

[jens]

Yes, but the assertion failure is in object_flavour_is_aware, which is not checked until you can see/detect the object!Good. If it happens again with a nightly and I can reproduce it, I'll fix it.

My point was that the second time I killed him, he would be carrying the same items as the first time, but no crash the second time, so it's probably something more specific in the circumstances...

If there are no objections I'll merge your artifact changes this weekend btw, so they'll be in the next nightly.

Great! Was thinking about pushing it, arguing that it's not a new feature, but rather a tuning of a previous feature :-) In case you have gone into feature freaze that is...

[Magnate]

My point was that the second time I killed him, he would be carrying the same items as the first time, but no crash the second time, so it's probably something more specific in the circumstances...

Ah. I don't think I had realised that you had re-played from *after* he was generated. Yes, it's quite odd then, and clearly hard to reproduce. It could be a memory corruption issue.

Great! Was thinking about pushing it, arguing that it's not a new feature, but rather a tuning of a previous feature :-) In case you have gone into feature freaze that is...

Not yet - we're going to make a big decision about shading support for Shockbolt's 64x64 files: if we postpone that until 3.4, we'll be in feature freeze pretty soon. If we try and get it into 3.3, we will have a little longer before freeze. We all want to get Shockbolt's tiles included ASAP, but the code for supporting tiles is unbelievably crufty and not quickly fixable.

[jens]

Ah. I don't think I had realised that you had re-played from *after* he was generated. Yes, it's quite odd then, and clearly hard to reproduce. It could be a memory corruption issue.

Was a bit surprised at the outset, I don't believe I had saved... have you added auto save functionality?

Not yet - we're going to make a big decision about shading support for Shockbolt's 64x64 files: if we postpone that until 3.4, we'll be in feature freeze pretty soon. If we try and get it into 3.3, we will have a little longer before freeze. We all want to get Shockbolt's tiles included ASAP, but the code for supporting tiles is unbelievably crufty and not quickly fixable.

Don't know if it's relevant, but when I compiled this version I had to move the .dll files to the same folder as the .exe to be able to execute (Win 7).

Postponing the release date for 3.3 in that case?

[d_m]

Was a bit surprised at the outset, I don't believe I had saved... have you added auto save functionality?




Don't know if it's relevant, but when I compiled this version I had to move the .dll files to the same folder as the .exe to be able to execute (Win 7).

Postponing the release date for 3.3 in that case?

How did you compile? Makefile.win should move those DLLs automatically. It might be worth putting something in a file (BUILDING, README, COMPILE, etc) that documents this if certain build systems aren't doing that.

[jens]

How did you compile? Makefile.win should move those DLLs automatically. It might be worth putting something in a file (BUILDING, README, COMPILE, etc) that documents this if certain build systems aren't doing that.

Not at home at the moment so can't really check, but I followed the advice here. So something along the line of:
mingw32-make Makefile.win