Bugs and complaints on current master

[Derakon]

Yes, I also think that defeats the purpose of traps... they're just "obstacles" now.

Not to broach this whole subject all over again (we've had many discussions about traps), but just to explain how I understand the development process to have been: the attitude guiding this change is that traps must be interesting, first and foremost. We weren't able to come up with a mechanism for hidden traps to be interesting; everything we thought of ultimately would have devolved into "the player chooses a dumb but optimal playstyle (e.g. manually searching every single tile) because that's preferable to risking getting hit by an undiscovered trap at an inopportune time."

And note that current traps are not interesting, except possibly in vaults (where the player will have invariably detected them, so they're not exactly hidden their either). They're haphazardly scattered about the dungeon, and everyone spams magical trap detection all the time anyway. They're an inventory slot tax for warriors, and that's really about it.

The new system hopes to make traps more interesting by placing them more intelligently, so that the player is forced to interact with them. However, we also want to get rid of the detection spam, without forcing the player to risk getting hit out of the blue by a trap at an inopportune time. To do that, traps have to not be hidden -- or at least, the player has to know there's a trap present at least one turn before they move into a tile.

[PowerWyrm]

the "detect traps area", that big yellow box, is now gone? and i dont see the DTrap notification either, i must assume this is voluntary?

not sure why traps are automatically detected, it kinda defeats the purpose of traps.

if the detected area box comes back, could it not disturb? i can see the big yellow line, should be enough.

black market is throwing out waaay too many stacks of useful items .. bundles of 10~15 of *heal, life, augmentation, banish, etc.

Traps are now automatically detected when walking next to them, so the indicator has become obsolete.

Yes, I also think that defeats the purpose of traps... they're just "obstacles" now.

I cannot reproduce what you describe about BM. Those items are generated one by one, not in stacks, and they're not "kept" indefinitely, so even if you get a stack of 2-3 in the BM, that stack should be also be able to decrease over time and eventually vanish.

[PowerWyrm]

Currently looking at the new object power calculation... it seems that the power from object curses has been lost in the process (old curse_power() method).

[Sky]

the "detect traps area", that big yellow box, is now gone? and i dont see the DTrap notification either, i must assume this is voluntary?

not sure why traps are automatically detected, it kinda defeats the purpose of traps.

if the detected area box comes back, could it not disturb? i can see the big yellow line, should be enough.



black market is throwing out waaay too many stacks of useful items .. bundles of 10~15 of *heal, life, augmentation, banish, etc.

[PowerWyrm]

Just a little memory leak: "msg" and "desc" from "struct obj_property" are not freed in cleanup_object_property().

[Nick]

New build on the nightlies page, with a big change to how randarts are handled. If you have a current character with randarts DO NOT update; this should be the last time I have to say that, though.

Randarts are now written to an 'artifact.txt' file in the user directory, which is then automatically loaded. The old "keep randarts" option is now a "keep arts" option, and works as follows:

• if on, any existing 'artifact.txt' file in the user directory is used; in particular, if you just finished a randarts game, the same randarts will be used
• if off, any existing 'artifact.txt' file in the user directory is archived into an 'archive' directory inside the user directory (as artifact_1.txt, etc), and then randarts are generated or not according to the randarts option

IMHO this simplifies everything massively, but let me know if there are any problems with it.

[Nick]

New build is up, fixing

• Power levels of clairvoyance and enlightenment
• Hang on trap creation in town
• Crash on trying to create a lit labyrinth
• Error in update_mon()
• Savefile not loading for dead randart characters

I forgot to change the default for keeping the randart set, will do that soon.

Thanks to kandrc and PowerWyrm (and others) for these ones.

[Nick]

Clearly because of:

square_memorize(c, yy, xx);
square_mark([COLOR="Red"]cave[/COLOR], yy, xx);

"cave" and "c" are not identical, one is the new level (c), the other is the old one (cave) which doesn't exist anymore.

Thank you, of course that's it. I'll have a look for others like that too.

[Nick]

I like saving those things. I believe that the choice to cheat death should be done the next time the game is started, when the emotions of YASD have worn off.

Yes, I take your point. I'll do this for now, but may revisit it later.

[PowerDiver]

OK, thanks for that.

My plan to fix this is just not to save the dead player's gear and stores, which is where the problem seems to be arising. This should make reloading savefiles fairly robust; I will think about some more savefile restructuring to allow keeping setting on abort.

I like saving those things. I believe that the choice to cheat death should be done the next time the game is started, when the emotions of YASD have worn off.

[Nick]

I've been frequently getting an error in which the save file is treated as if corrupt when the game fails to load an artifact for a dead character. The game aborts, forcing me to delete the save file and lose macros, inscriptions, etc. I haven't reported it before because I didn't want to dive into unknown code deeply enough to understand it. I decided to take a look this time.

My last game was randart (always randart). Load fails on the first call to lookup_artifact_name(), which fails to match the name of the randart. Peeking inside a_info[], I see that it's full of the standard artifacts.

OK, thanks for that.

My plan to fix this is just not to save the dead player's gear and stores, which is where the problem seems to be arising. This should make reloading savefiles fairly robust; I will think about some more savefile restructuring to allow keeping setting on abort.

[kandrc]

I've been frequently getting an error in which the save file is treated as if corrupt when the game fails to load an artifact for a dead character. The game aborts, forcing me to delete the save file and lose macros, inscriptions, etc. I haven't reported it before because I didn't want to dive into unknown code deeply enough to understand it. I decided to take a look this time.

My last game was randart (always randart). Load fails on the first call to lookup_artifact_name(), which fails to match the name of the randart. Peeking inside a_info[], I see that it's full of the standard artifacts.

In case it's apropos, I play with "use old set of randarts" false, and I literally never explicitly save or close the game; just keep it up on another virtual desktop.

This isn't a big deal when loading a dead file, but if the character were alive (don't know if this would occur then), it would be very annoying. Regardless, it might be beneficial to provide a fallback mechanism to keep settings while discarding the rest of the file, rather than simply aborting on any error.

Come to think of it, I'm pretty sure I've had this happen when loading an autosave after a crash. Not 100% certain on that, unfortunately.

[Derakon]

How many of those "try infinitely until we find a match" loops are there in the game, anyway? Those seem like clear opportunities for bugs that lead to infinite loops. There should at least be a cap on how long we try for (like, 1000 attempts or something) and a graceful handling of failure.

[PowerWyrm]

Here's another. Not a crash, but an infinite loop. Read an un-id'd scroll in town. Turned out to be create traps.

Create traps should be disabled in town anyway...

[PowerWyrm]

Yes, I've seen that too - it's an issue with labyrinths, but I don't fully understand it yet.

Clearly because of:

square_memorize(c, yy, xx);
square_mark([COLOR="Red"]cave[/COLOR], yy, xx);

"cave" and "c" are not identical, one is the new level (c), the other is the old one (cave) which doesn't exist anymore.