Angband Forums - 22 May 2011 development release

Angband Forums (http://angband.oook.cz/forum/index.php)

- Vanilla (http://angband.oook.cz/forum/forumdisplay.php?f=3)

- - 22 May 2011 development release (http://angband.oook.cz/forum/showthread.php?t=4447)

Quote:

Originally Posted by Derakon (Post 53733)

Sounds very interesting though, and I'd love to be able to query that database, maybe make some plots tracking stats against dungeon level and suchlike.

When I've created it, I'll make it public. It'll be a slow download, but it won't go anywhere. In fact instead of ppl needing to download it I'll put up a web interface for querying it (with some help from myshkin and d_m!).

Quote:

Any plans to have a version that uses randarts instead? I know the randart generator is expensive to run, though. Given that you're just tracking the artifact index number, maybe it'd be possible to generate a set of randarts, use them as the artifact set for a series of runs (maybe only a few hundred), save stats, generate a new set of randarts, etc. The goal would be to see how randarts track compared to standarts on various metrics, if there's something they consistently do better or worse in (e.g. off-weapon damage boosts, elemental immunities, pConf...).

Even without randarts I'm sure this will provide much interesting data. Best of luck!

It can already deal with randarts via the -r subopt to -mstats. The problem is that the current randart generator is dog slow, and slows down the runs by a factor of 10-20. (You can still do ~1000 runs in about six hours though.) This is on my to-do list for 3.4 though.

But no, the idea is not to sim randarts specifically. Your goal can be achieved by doing the runs with randarts and comparing the total availability of OF_FOO with the total availability using standarts. There is no need to compare standarts directly with randarts without looking at what's actually available in the dungeon, IMO. If there is, it would be much quicker and simpler to write a dedicated sim.

It would be quite easy to set a number of runs between each new set of randarts (it currently defaults to 1, which simulates real games), but the problem would be writing out the intermediate data.

Let's see how we get on.

Quote:

Originally Posted by Derakon (Post 53599)

Vaults seem to periodically be missing entire rows of blocks, replaced by empty space. E.g. I found a Bubbles vault that was missing its top row, and I know I've found vaults missing rows through the middle. Don't think I've seen any vaults missing columns. It's actually a bit interesting since it breaks up the flow of the vault, but it's still a bug.

This would be the fault of the function ensure_connectedness() which I've added. It's supposed to ignore "icky" squares to prevent vaults from being mauled, but I definitely believe that it could be messing up somehow.

Do you remember which version of the game generated that level (I assume it was pretty recent)? Also, do you remember how the vault connected with the result of the level? Usually there is a passage leading to some random part of the GV and then the player has to tunnel into it. I've been trying to replicate this without success (so far) so I'm curious if you remember any more details (or maybe even have a screenshot)?

Thanks for your feedback!

EDIT: Of course, after generating 15 Bubbles vaults that are fine (and posting this) I find one that has a column removed! So... clearly I *can* reproduce this. Sorry for the noise ;)

This was with the most recent version. I went ahead and wizard-scummed until I got another vault showing the behavior. This time it's a missing column, and it does indeed coincide with a corridor:

http://derakon.dyndns.org/~chriswei/temp2/vault.png

Sounds like you ought to be able to fix this by treating icky tiles and all non-border permanent walls as passable for your connectivity checker.

Quote:

Originally Posted by Derakon (Post 53754)

Sounds like you ought to be able to fix this by treating icky tiles and all non-border permanent walls as passable for your connectivity checker.

It turns out it was a slight bit more complicated than I thought.

The core function (join_region) isn't trying to connect to the vault... but instead trying to connect regions on both sides of the vault. It was first written for use with caverns (which don't currently have vaults) and didn't realize that it had to go around permanent walls/icky squares.

This is now fixed in staging (I confirmed it by generating vaults until I found one with regions on both sides and a weird tunnel going around the vault to connect them) closing ticket #1455.