Source:
http://rephial.org/downloads/3.1/angband-3.1.0beta.tar.gz
Windows compile:
http://rephial.org/downloads/3.1/angband-3.1.0beta-win.zip
OS X compile:
http://rephial.org/downloads/3.1/Angband-3.1.0beta-osx.dmg
There are a lot of changes in this release. The most notable are that
the UI has been tweaked, refined and generally twiddled so it should be
the easiest-to-use release ever. Other than that, there should be less
junk and some new item kinds. Underneath all this is some fairly
wide-ranging code cleanup and rewriting.
There is no exhaustive changelog for this release since the changes are
so wide-ranging. However, a fairly complete one is attached to the end
of this post. I welcome all criticism and bug reports; this release is
not complete, and new releases will probably stay in beta through to
3.1.3 or thereabouts, so if you have issue with anything, please make it
known!
Angband 3.1.0
=============
This is an Angband development version -- it may be buggy, so be warned!
Special thanks for this release go to: Eytan Zweig, pelpel, Kenneth Boyd,
J.D. White, Eddie Grove, Rowan Beentje, Nick McConnell, Gabriel
Cunningham, Shanoah Alkire, Alexander Philips, mikon, Antony Sidwell,
Joe Buck, Erik Osheim, d_m, Antoine, and all the alpha- and beta- testers
who downloaded the game, sometimes in an extremely shaky state, and played
it anyway.
Noticeable up-front UI changes
------------------------------
* Add EyAngband-style quickstart option.
* Notes, like NPP and FA, except with brand new code by J.D. White.
(#10)
* Add a trap detection indicator. Also, colour the edges of trap-
detected areas green. (#19)
* Make status bar display all timed effects, left-to-right, which
involves moving the dungeon level to the bottom of the left-hand
display. (#191)
* Add show_lists option, which is the same as always_show_lists in
Ey. (#25)
* Auto-wield birth items (#24)
* Change the object information screen quite a bit: (#214, #26)
- Show average damage for weapons and ammo (#26)
- Make descriptions a fair bit terser (#399)
- Show breakage chance for ammo
- Track item origin, so every item has a tag telling you where it
came from (#149)
* Monster recall changes (part of #152)
- some colouring removed, some added
- Monster's depth is in red if it's beyond maximum depth, light
green otherwise.
- more information is known about monsters before they are killed
* Add how many items the player already has when buying something at
the store. (closes #151)
* Allow use of the space bar to advance a screenful in all
menus. (#244)
* Make all menus wraparound at the top/bottom. (#244)
* Monster recall display now cycles through monsters in level order,
not in the order that the monster definition file is written
in. (#302)
* Add an indication of maximum capacity in the inventory
display. (#358)
* Menus should use 1234567890 as little as possible for "tags". (#292)
* Remove the "depth_in_feet" option, instead displaying both the
dungeon level and the depth everywhere.
* Ensure that store-bought and birth-given torches have the same number
of turns for stacking purposes.
* Death screen now uses scrollable menu. (#416)
* Drop squelched items
* Append {tried} to tried items in the object browser (r606)
* Put {tried} items before untried items in the object browser
* The monster list display has a little more colour-coding
* Death menu now uses a scrolly menu.
* Preserve mode has a sensible description again.
* Try and differentiate the level feelings more.
* Add the moderately well-tested "lazy movement" patch which allows a
movement delay to be set, during which it is possible to choose a
second direction. This means that up and left in quick succession
can be translated to an actual diagonal. This may improve some
people's laptop playing experience without resorting to the
roguelike keyset.
* Add bigscreen support to the self-knowledge screen.
* Make inscriptions like "!k!k!k" prompt multiple times again. (#492)
* Make monster XP and native depth always known, even without
kills. (#596)
* Rejig social status a bit -- it rises with level from a certain
baseline.
* Display various skills numerically on the character sheet, rather
that with text. This is like Eddie's patch, but a bit more polished.
* Add a "display item list" command and term window. (Thanks to Eric
Osheim)
* Add method of death to the character dump. (#501)
* Tell the payer when timed effects increase or decrease as the result
of effects. (idea by Eddie Grove)
* Windows versions now use hashes and percent signs for walls until
there's time to sort out all existing fonts to be Vista-compatible.
(#232)
* Squelch 'K'ind feature now available in the roguelike keyset. (#339)
Gameplay changes
----------------
There are some pretty big gameplay changes.
The object list has been reworked quite a bit. It is a bit more
varied and has less duplication. Some items have been removed and
others added. The new items have had relatively little testing and
may be gone again next release.
- The number of items that monsters drop has been reduced drastically.
- Potions tend to appear in stacks now.
- The range of food items has been reduced.
- Healing heal a proportion of wounds, not just a set value-- this
makes all the potions useful.
- Add a selection of "gain one, lose one" stat potions to replace the
old stat loss potions-- they guarantee a stat to raise and reduce one
randomly.
- The Elven Rings have a variety of healings, at the suggestion of
Timo. Also, apply some other changes from the TV-patch (r428)
- Replace the sustain {stat} rings with sustain mind and sustain body,
providing three sustains each.
- (#543) Make ammo of slay evil/venom apply to Mithril ammo too.
Gold drops have also been reworked. By the end of the game, there is
about 3.6x less gold per drop than in any earlier version or Angband
or Moria, but the amount per drop at the beginning of the dungeon
is quite similar to pre-existing levels. You may be interested in
looking at http://rephial.org/research/avg_gold_drop.pdf for an
illustration.
Magic mapping and detection use the same-sized rectangular area around
the player regardless of screen size.
Fear now carries a to-hit penalty to missile weapons of 20, as well as
giving an AC bonus of 8. It also increases the failure chance of
spells, but spells that cure fear have been made harder to fail to
balance this out.
Birth:
* Make point-based points worth less gold.
* Minimum starting gold is 200AU.
* Add an option to start the character with 500AU but no equipment.
* Point-based character generation is now equivalent to best available
from the autoroller. (Eddie Grove)
* All characters start with WoR.
Stores:
* Phase Door is now a staple item.
* Start stocking deeper items as the character descends.
* Rewrite the rules for shopkeepers
- Remove individual-shopkeeper and race-based price changes from the
store code, to make it easier to balance pricing.
- Adjust adj_chr_gold[] values upwards to represent the average-110%
inflation usually applied by the individual-shopkeeper greed
values. This should really be applied to the object.txt file
instead, though.
ID:
* Make ID reveal all powers of an object, and remove *ID*. (#158)
* Make pseudo-id not occur whilst resting, but also make pseudo-ID
lengths shorter (by a little over half) to compensate.
* Some items, when worn long enough, get automatically ID'd
* Items pseudo-id'd as {average} are automatically ID'd, and thus will
stack properly
* Make wands/staffs stack even when un-ID'd
* Pseudo-ID obviously excellent items as {excellent} when possible
(e.g. brands/slays/obvious stat bonuses).
* Remove "good" pseudo-ID, replace with "magical" -- for non-cursed
non-average non-ego non-artifacts
* Add "strange" pseudo-ID, for when items have mixed blessings
* Stop automatically cursing all bad weaponry
* Make weak pseudo-id notice the difference between magical and
excellent
* Allow any/all rings/amulets to be cursed if the game wants to
generate a "bad" item. This is liable to be rethought in the future.
A small selection of other changes:
* Remove autoscum. (#365) -- really?
* Add minimum depths for each kind of trap. As such, only teleport and
confusion traps occur at dlev1. This should help some people.
* Make the rogue slightly better at combat than the ranger, based on
Timo's sugges
tion. (Message-ID: <651vknF...@mid.individual.net>)
* Lower the distance missile weapons can fire into the 10-14 grids range.
* Make monster arrow attacks sometimes miss. (#537)
* Some improvements to monster AI.
Port
----
* X11: Add -x commandline option for choosing the location of the
settings file (#333, patch by morth)
* GTK2: Continue work; add term windows, graphics, etc. and also some
special dedicated display windows, like "messages" and "monster
list". (shanoah)
* OS X: the OS X version is now a universal binary, and runs faster,
better, quicker, and with more sound than before. (Rowan Beentje)
Code-level
----------
Monster HP is now specified as an average value around which to
randomise, instead of using a "12d5"-type calculation. Uniques always
have the number of HPs specified in the monster.txt file, like before.
This is copied from Ey.
A lot of code-level cleanup has been applied to this release, much of it
still in flux. Many new files have been split out of existing files,
which should now have much more self-explanitory names. The player/,
monster/ and object/ subdirectories have been created, to aid seperation
of code.
There is also a new generic effects handler so that all item activations
and use abilities share the same code; this replaces use-obj.c and a lot
of descriptions from lib/edit/object.txt. (#234)
Memory handling has been reviewed. Now, all code should assume that
allocation will succeed, just like it did already. There is also a
realloc()-style function along with its own hook. string_make() has
been modified to no longer return a "const char *", and so all the code
now only uses "const" when it means "const". Some macros have been
removed.
"Elly" rewrote the message and quark packages, previously in util.c,
and in the process split them out into their own z- files. The z-msg
package is now much more understandable but marginally less "efficient",
and certainly less "optimised".
Option definitions have moved to option.h, and the names and
descriptions for options have moved to option.c. Option data is now
stored in a much more visually compact way, much more suitable for
editing than the old system was. (#64)
Additionally, a new file API has been introduced which combines the
previous mishmash of fd_*() and my_f*() calls into a simpler, better
documented interface. (#137)
Store stocking is specified in lib/edit/store.txt now, in a reasonably
flexible format.
A fair bit of work has gone into allowing item names to be used in the
edit files rather than the tval/sval numbers. For example, see the
new store.txt file; but also the lib/pref/ graphics files, and the
starting items in the p_class.txt file, amongst others. This is a
fairly easy thing to do and is a massive massive usability enhancement.
It means that invalid item references are caught much sooner, since if
an item is removed, all references to its name become invalid.
Set up an event system for UI display updates, where the game
communicates with the UI by sending messages saying that something's
changed that the UI might be interested in, rather than deciding that
specific things should be redraw. The main screen updates all use this
system now. Amongst other things, this system should help things like
the borg and graphical frontends, because they can hook right into
changes in state. (#348)
object1.c and object2.c have been split out into a series of files,
obj-{desc,make,ui,util}.c. This makes it much easier to remember what
is where. Also, object_desc() has seen a rewrite, so hopefully it's a
lot more hackable now.
The beginnings of an organised code documentation scheme have started,
using doxygen. Makefile.std provides an easy mechanism to generate docs
(try "make docs").
Other assorted changes:
* Remove a whole load of useless or unused configuration options from
config.h.
* "make -f Makefile.inc depgen" will output "Makefile.new", which then
contains up-to-date dependencies for the project.
* Add "flags" back to object_type, removing the need for the hacky
"xtra" bytes. This paves the way for e.g. fireproofing scrolls
later. (#120)
* Makefile for MSVC/NMAKE command-line build. Currently works with
MSVC 6+; flags could use tweaking for MSVC 8+.
* Clean up racial and class skill values into arrays. (Kenneth Boyd)
* Use header file guards in all header files, and use a consistent
naming scheme for them ("Elly")
* Add a very basic test harness for "unit testing" of the game's code,
though this is barely used at present. Thanks to Fennec for cleaning
this up a bit.
* Introduce the one_in_() notation to the game, for percentile dice.
* Move to using randint0() and randint1() for random numbers.
* Add proper transparency to the PNG files. (fixes #270; thanks to
Rowan Beentje)
* Move to using flags[6] for monster flags rather than individual
flagsets.
* Score code moved to score.c and extensively refactored.
Really don't like this.
Will just end up running back and forth in a corridor to get the same
effect, just in a more annoying way.
> * Remove autoscum. (#365) -- really?
Why!?
I hope that pseudo-ID is quick enough now that resting and running back
and forth are not necessary. If this is not the case, then I'll remove
the resting restriction.
>> * Remove autoscum. (#365) -- really?
>
> Why!?
It's my opinion that it shouldn't be necessary, and not having it there
also makes the game easier to balance; if there are issues with dungeon
generation, they should be resolved, rather than putting together a hack
so that they aren't noticeable.
Trying that windows version on a Vista 64 bit yields a very bad result :
game launches but no game window ever opens. Process is still listed in
the process list but uses no ressources at all.
Have you any console windows open? It is a known issue that if there
are console windows open, Angband refuses to load until they are closed.
If not, I have no ideas-- I have neither a 64-bit machine nor Vista.
Andi
There is no console window open that I know off. It freezes in
main-win.c line 1479 :
/* Notify other applications that a new font is available XXX */
SendMessage(HWND_BROADCAST, WM_FONTCHANGE, 0, 0);
Of course, commenting that line just yields a completly black window.
Well, if there are any Windows coders who have the faintest idea what
this might be about, I'd appreciate it. Do you have this problem with
FAAngband? If not, it may be an issue with the particular fonts this
release has and it will be fixed in 3.1.1.
Andi
Ah, your comment about a window console open make me test the older
version of Angband which worked perfectly before but now freezes too.
Looking though the process list, I killed the hidden Adobe autoupdater
thing and the game unstucked itself. Killed also a few other services
before so I cannot rule out the others weren't guilty too but I think it
was that one that is the problem.
Checking the MSDN, it says an application should send that message when
it adds or removes a font to warn the other windows that the available
font list changed. It seems SendMessage waits until all the applications
that receive the message answer it so a lone rogue app could freeze
angband launch forever.
Maybe using PostMessage instead of SendMessage would work since that
way, angband would not have to wait for an answer from the other
windows. Testing here shows that the rogue Adobe Updater doesn't prevent
angband launch anymore like that but my knowledge of Win16 API
programing is rather poor I must say so I don't know the other
consequences of such change.
Next stage, find why the standard font shows completly black in the game :p
Interesting. I will have to try that and see what it screws up. :)
> Next stage, find why the standard font shows completly black in the game :p
I know that Vista likes to use its own 8x13 font rather than the one
provided, but short of that, I have no idea. Try changing font and see
if that makes things less blank?
I get the feeling the current frontend for Windows could do with a bit
of a rewrite...
Andi
Yes, it does work, only the 8x13 font has that problem that I know of.
Too bad since I'm really used to that one and I'll miss it.
There was a follow-up about the game not starting under Vista, just sitting in Task Manager but never doing anything. I experienced
the same thing in XP. For me, I had to kill Backupservice.exe (a process from an online backup service, DriveHQ) to get it to run. I
suspect that others who can't get it to start will have to experiment with killing processes to find which one is the magic one.
The other thing is that it won't load my 3.0.9b savefile. Has the game changed too much to allow previous save files to load, or is
this only an issue with the beta? Will I lose my monster memory by going to 3.1.x?
I haven't had time to actually play it to make comments about the game, but it is nice to see the work continuing.
This forum post:
http://angband.oook.cz/forum/showthread.php?p=13005#post13005
indicates that running the latest nightly build might fix the problem.
> The other thing is that it won't load my 3.0.9b savefile. Has the game changed too much to allow previous save files to load, or is
> this only an issue with the beta? Will I lose my monster memory by going to 3.1.x?
Yes - savefile compatibility has been broken due to many object changes.
Nick.
PS: If you can get it working with the version linked to from that post,
please post here saying as much, because then I can strike off a whole
bunch of bugs as fixed.
Andi
I'm still not clear what the original reason for the change was.
>>> * Remove autoscum. (#365) -- really?
>> Why!?
> It's my opinion that it shouldn't be necessary, and not having it there
> also makes the game easier to balance; if there are issues with dungeon
> generation, they should be resolved, rather than putting together a hack
> so that they aren't noticeable.
IMO, Autoscum isn't a way of correcting a problem with the game, but a way
of getting a different game experience. Like always taking quests in NPP,
you are taking on a more exciting game, with the expectation that it will
kill you in painful ways most of the time.
Autoscum also creates two different games to balance. IMO it is better
that it doesn't exist and game is balanced for just one game.
Same with maximize and preserve mode.
Timo Pietilä
Well I'd say autoscum isn't meant to be balanced, that is sort of the point.
It was part of a set of ideas I had when first looking at the pseudo
system. The idea was to discourage people from resting to get psuedo,
and rather explore instead. I'm not convinced it was a great idea, but
I thought I'd try it to see what difference it makes.
Andi
> Autoscum also creates two different games to balance. IMO it is better
> that it doesn't exist and game is balanced for just one game.
I'm inclined to agree with this
> Same with maximize and preserve mode.
...but only if preserve is kept as the default! :-)
Matthew
--
Rapun.sel - outermost outpost of the Pick Empire
http://www.pick.ucam.org
I really like the majority of these changes, and I like how the
codebase is modernizing. You're bringing Angband several years forward
while not compromising its spirit and vision. Keep up the good work.
Scott
Have a nice day. :)
Andi
Awesome !!
T.
Actually, I wasn't using the service that was plugging up the game for
me anymore, so I uninstalled it. Since I don't have a problem anymore,
I won't know if the new build fixes it. I imagine there are plenty of
others with the problem, though.
> > The other thing is that it won't load my 3.0.9b savefile. Has the game changed too much to allow previous save files to load, or is
> > this only an issue with the beta? Will I lose my monster memory by going to 3.1.x?
>
> Yes - savefile compatibility has been broken due to many object changes.
All right, it seems reasonable that with these changes you cannot load
an active character. But how about allowing the loading of a dead
character, so that the monster memory can stay intact? You could
either offer to load the char and start a new game, or give a message
that the char will have to be killed before it can be loaded.
I have managed to keep the monster memory intact from way back in
version 2.7.8. I even installed an intermediate version just to bridge
the gap to the newest version at the time. It would be such a shame to
start over now!
A repeat of my plea on the forums follows:
Now if someone could successfully contact Frank Galligan (aka Bolt
Vanderhuge (!)), we'd be able to get a GPL Windows CE port too.
More than one person has tried email...
Nick.
If you send me the savefile, I'll see what I can do. :)
Andi
Congratulations. Champagne all round.
For those who've branched variants from Angband from an earlier
release, what non-approved code did you have to remove in order to GPL
up?
Andrew
Might it be better to scrap the current and make a new Windows CE
port from scratch?
> Timo Pietilä <timo.p...@helsinki.fi> writes:
>
>> Autoscum also creates two different games to balance. IMO it is better
>> that it doesn't exist and game is balanced for just one game.
>
> I'm inclined to agree with this
While true, the question now is what the new goal of balance will be.
Personally, when I first started playing with autoscum, it really
hammered home just how boring vanilla play was.
I'll put together a report on the process with details on this and whose
code exactly is covered over the next few weeks if that'd be helpful.
Don't expect it until February, though-- it'll take a little while to
get it sorted.
Andi
In that case, vanilla play should be made more interesting. I believe
3.1.0 beta makes a big improvement in this; I certainly hope it does!
Andi
I would like to see same kind of balance as Topi Ylinen -era Zangband
had. Some would say that it was not balanced, but I'd say it was,
because it was fun to play. "Balanced" is not same as "everything is
equal and everything can be predicted". Game is balanced when it is fun,
and for fun I count when it can surprise you, even if it kills you, as
long as those surprises are rare enough that they do not generate too
much frustration and when you _can_ get in godlike position where you
can enjoy your supremacy over puny dungeon habitants. Mostly I prefer
dark and dangerous feeling, though.
> Personally, when I first started playing with autoscum, it really
> hammered home just how boring vanilla play was.
Boring levels are boring. Autoscum prevents generation of those. But it
wasn't very well balanced either, because you get swamped in items and
it generates imbalance between your clvl and your equipment status.
Timo Pietilä
> Might it be better to scrap the current and make a new Windows CE
> port from scratch?
As far as the current Vanilla port is concerned, maybe. However there
has been a _large_ amount of work done on the FA/O port which will
probably be ported back to Vanilla at some point; I'd far rather see
the CE port remain as the only unGPL'd part than replicate all that.
In a sense it's probably unimportant for the CE port to be GPL'd,
anyway - it's hardly likely to be bundled with Linux distros.
Nick.
>> Personally, when I first started playing with autoscum, it really
>> hammered home just how boring vanilla play was.
>
> Boring levels are boring. Autoscum prevents generation of those. But
> it wasn't very well balanced either, because you get swamped in
> items and it generates imbalance between your clvl and your
> equipment status.
I certainly won't argue that autoscum was "balanced". But I did
find it more interesting than playing without autoscum.
Mind, I also think there are too many dungeon levels.
And think that the levels themselves are a bit too big for their
contents and gameplay. Autoscum deals with that to a degree by
putting more stuff inside any individual level. The option for
"Small" levels helped hammer that point as well, as even a
non-autoscum small level is generally more interesting than a
regular level. Not that I'm calling for Angband levels to be reduced
to two screens in size either, but maybe they could use a trim.
> Now if someone could successfully contact Frank Galligan (aka Bolt
> Vanderhuge (!)),
It's an MST3K joke :)
I don't recall when I switched to small levels in Z, but by now I am
sure I won't be switching back. The regular angband level size is too
big; it's just boring to walk around it all if you're a compulsive
level-cleaner like I am. (Well, until about 3000'-4000', then I start
getting picky and try to get ready for the endgame, diving a bit more.
Still do try to kill uniques, though.)
Of course, I don't know how V is balanced, but I think a good guideline
is that a semi-experienced player can normally descend 2-4 levels
between each recall, usually having some challenging encounter but very
rarely a badly OoD one (or only shallow ones).
Otto Martin - so yeah, count one vote for smaller levels
--
"Try not to get any more ships shot out from under you. The budget
won't take it." "The constabulary doesn't /have/ a budget, Fabula."
"Then what have I been embezzeling from all these years?"
http://project-apollo.net/mos/mos158.html
I happen to agree with you that there are too many levels and that they
are generally too big. Expect changes in this area at some point whilst
I'm maintainer.
Andi
> The regular angband level size is too
> big; it's just boring to walk around it all if you're a compulsive
> level-cleaner like I am.
Interesting. I would say there are two solutions here; the levels
could be made infinite in size (game keeps generating more chunks the
further you go), so "clearing" the level becomes clearly nonsense, or
smaller so "clearing" the level becomes more reasonable.
Either way would nullify compulsive level-cleaning. But which way
would actually be more fun?
Bear
> Billy Bissette wrote:
>> Personally, when I first started playing with autoscum, it really
>> hammered home just how boring vanilla play was.
>
> Boring levels are boring. Autoscum prevents generation of those. But
> it wasn't very well balanced either, because you get swamped in items
> and it generates imbalance between your clvl and your equipment
> status.
FWIW: I used to play with autoscum exclusively, and I could never get
very deep or very far without dying. Eventually I tried it without
autoscum, and I found myself making it considerably farther with no more
difficulty. In essence, and counterintuitively (at least to me at the
time), autoscum makes the game harder rather than easier.
In my experience, the increased benefit (drops, etc.) provided by
autoscum is significantly outweighed by the increased danger. I wouldn't
want to play with it on unless that ratio were tilted much farther from
the "danger" side of the balance.
--
The Wanderer
Warning: Simply because I argue an issue does not mean I agree with any
side of it.
Secrecy is the beginning of tyranny.
I'd agree that autoscum makes the game more difficult, but also more
interesting. That is why I'm not sure how you balance both current settings
into one, they were quite different experiences.
Woo, the next version can go in Debian proper, rather than non-free
:-) :-)
> I happen to agree with you that there are too many levels and that
> they are generally too big. Expect changes in this area at some point
> whilst I'm maintainer.
Moria used to have 50 levels, but I think you'd struggle to get to
Morgoth-killing power in 50 levels.
> Timo Pietilä wrote:
>
> > Billy Bissette wrote:
>
> >> Personally, when I first started playing with autoscum, it really
> >> hammered home just how boring vanilla play was.
> > Boring levels are boring. Autoscum prevents generation of those. But
> > it wasn't very well balanced either, because you get swamped in items
> > and it generates imbalance between your clvl and your equipment
> > status.
>
> FWIW: I used to play with autoscum exclusively, and I could never get
> very deep or very far without dying. Eventually I tried it without
> autoscum, and I found myself making it considerably farther with no more
> difficulty. In essence, and counterintuitively (at least to me at the
> time), autoscum makes the game harder rather than easier.
I always have autoscum on. I've yet to win, but I can make it pretty
far without YASD...
If you make the levels even bigger, people will still travel
excessive amounts, particularly if they are unsure whether it is
safe to go deeper.
If you make the levels smaller, a cautious player will clear it
quicker, and thus get that nudge to go a bit deeper quicker as well.
More so when you've got such a slow increase in difficulty between
levels. (While I do feel the dungeon is too deep for its content,
cutting the dungeon depth could counter this. With fewer levels,
the increase in difficulty between levels may actually become a
factor for more cautious players.)
As for those not compelled to clear entire levels, larger levels
would add nothing. Smaller levels might or might not affect their
play. If you cut the level size enough, a few players might be
tempted to spend the extra turns finishing it, or at least detecting
the whole thing.
> Andi Sidwell <an...@takkaria.org> writes:
>
>> I happen to agree with you that there are too many levels and that
>> they are generally too big. Expect changes in this area at some point
>> whilst I'm maintainer.
>
> Moria used to have 50 levels, but I think you'd struggle to get to
> Morgoth-killing power in 50 levels.
How many different levels does the average player actually "play" on
currently, versus skipping past to get to something more profitable?
Well, how many once you disregard the cautious players who will
search every individual level regardless of the full dungeon size?
(Because, let's be honest, even if Angband were stretched to 150 or
200 levels, there would still be some people who would scour every
one of them. And people who would sit back farming XP before
progressing down a stairway.)
I consider myself quite cautious player and I skip regions between
1000-1500 and 2500-4000, or at least go down ASAP in those areas.
1500-2500 is for me "stat-gain", between 1000-1500 danger increase is
minimal but rewards down to 1500 is much greater, 2500-4000 again change
in danger is pretty minimal and 4000 I can get native RoS.
Levels between those "skipped" areas do get some exploring just because
stairs are not always easy to find, and sometimes you get GV or very
interesting LV in them.
So I would say 0-1000: 20, 1500-2500:20, 4000-5000:20 + some odd levels
between skips. 60+ maybe 70-75 in total.
I don't think levels are too big, I think level size is pretty good,
even that I hardly ever clear whole level. Smaller levels can be much
much much more dangerous, because monsters can't be teleported far
enough to be safe, and one large open GV can be rather deadly when you
can't deal with monsters in them.
Timo Pietilä
> Well, it took some time, but finally there's a beta version out... get
> it while it's fresh!
I've had a bit of a play with this, and on the whole I like the UI
changes! The little green dots that show the edge of trap detection is
a real win. I like the NXT indicator of how many EXP you need for the
next level, but would it be possible to optionally show current and
advance exp instead? it looks like there's enough vertical space for
one more thing here.
A couple of bugs:
i) when playing in console mode (whether a virtual console, or an
xterm), you have to hold escape down for too long for it to register -
in old angbands (and in the beta, running in X11 mode) you just need
to press it like any other key. This is deeply irritating.
ii) I compiled with --with-setgid=games. angband could write a
savefile, but then would just create a new character each time I
started up the game again. From strace:
stat64("/var/newangband/share/angband/save/1024.Matthew", 0xbf824300) = -1 EACCES (Permission denied)
I'm not quite sure why that's happening - the directory was created
d---rwx--- root:games and the executible -rwxr-sr-x root:games
So, something's wrong with the savefile/setgid handling, and I feel
angband really ought to produce an error message in these
circumstances, rather than silently creating a new character.
A couple of wishlists:
i) what happened to angband -s [to show the high-score table]?
ii) spoilers (sorry!). It Would Be Nice if you could generate
obj-desc.spo, artifact.spo mon-desc.spo and mon-info.spo from the
command-line and/or during the build process by invoking a make rune,
rather than having to do so in-game. Might this be doable?
Many thanks,
I don't really see the need to include both current and next-level XP;
if you want the former, just go to teh character sheet.
> A couple of bugs:
>
> i) when playing in console mode (whether a virtual console, or an
> xterm), you have to hold escape down for too long for it to register -
> in old angbands (and in the beta, running in X11 mode) you just need
> to press it like any other key. This is deeply irritating.
It also isn't anything to do with Angband; pressing escape in terminals
evokes that behaviour. It's because the terminal waits a couple of
tenths of a second to check you're not going to press anything else.
Pressing Esc-1 is equivalent to pressing Alt-1. This isn't anything I
can change and if you look at earlier versions should find it there too.
> ii) I compiled with --with-setgid=games. angband could write a
> savefile, but then would just create a new character each time I
> started up the game again. From strace:
> stat64("/var/newangband/share/angband/save/1024.Matthew", 0xbf824300) = -1 EACCES (Permission denied)
>
> I'm not quite sure why that's happening - the directory was created
> d---rwx--- root:games and the executible -rwxr-sr-x root:games
>
> So, something's wrong with the savefile/setgid handling, and I feel
> angband really ought to produce an error message in these
> circumstances, rather than silently creating a new character.
I'll look closer into this. Thanks.
> A couple of wishlists:
>
> i) what happened to angband -s [to show the high-score table]?
When I rewrote the highscore code it went away, since it was quite crufty.
> ii) spoilers (sorry!). It Would Be Nice if you could generate
> obj-desc.spo, artifact.spo mon-desc.spo and mon-info.spo from the
> command-line and/or during the build process by invoking a make rune,
> rather than having to do so in-game. Might this be doable?
Certainly not in the build process, no, and not from the command-line
either, the way the code is currently set up. I've noted your
suggestion, but it may not happen for a while.
Andi