[INFO] Angband on Unix/Linux FAQ
Alexander Ulyanov
I have decided to write this FAQ. I will also send it to Robert,
and upload on my PosBand site.
=== Angband on Unix/Linux systems -- Frequently Asked Questions ===
Copyright (c) 2005 Alexander Ulyanov <u...@urmail.ru>
Last updated: January 10 2005
0. Introduction
1. Installation
1.1. How do I compile *band from source?
1.2. How do I install *band?
1.3. How to run *band?
2. General questions
2.1. The savefiles.
3. Running *bands in console
3.1. What front-end should I use for text mode?
3.2. How to enable big screen mode?
3.3. How to disable cursor?
3.4. How to make walls show as blocks?
3.5. How to set up colors?
3.6. Ctrl-Z, Ctrl-S or Ctrl-Q don't work.
3.7. The game reacts slowly when I press ESC.
3.8. I cannot run with Shift-direction.
4. Running *bands in X Window
4.1. What front-end should I use for graphics mode?
4.2. How to set up fonts and window positions?
4.3. How to make walls show as blocks?
4.4. How to install graphic tiles?
=== 0. Introduction ===
Angband, one of the most addictive (and by far the most prolific) rogue-like
games in existence, was originally a Unix program, based on "Umoria" -- Unix
Moria. But only DOS and Windows ports gave it real popularity. And now, while
Angband is still best suited for Unix systems, there is almost no
documentation at all on its installation and usage on Unix. People who try to
play Angband on Unix/Linux are often disappointed, as they can't fine-tune
Angband to their taste, and find Unix versions inferior to Windows or
Macintosh ones. In this FAQ I have tried to answer some of the most common
questions, which are often asked in rec.games.roguelike.angband newsgroup.
90% of this FAQ applies to most of Angband variants, since they share most of
low-level code with Vanilla Angband. ZAngband and especially ToME are very
different from Vanilla, but you still may find some tips useful.
I will not try to explain what is Angband, or how to play Angband. I also
assume that you understand basic concepts of Unix (they are not as scary as
Windows people try to portrait them ;-).
I will also provide several small patches here. Be careful if you
cut&paste the patches, you may accidentally miss some lines or lose some
whitespace, which is very important. Maintainers, if you want to
be Unix-friendly, I suggest that you apply them *all*.
When I talk about Angband here, I really mean "any Angband variant". Also,
when I talk about Unix, I mean "any Unix-like OS -- Linux, *BSD, Solaris
etc.". Linux-specific information is marked.
If you have any questions or corrections, or want to add your question, mail
me to <u...@urmail.ru>.
=== 1. Installation ===
=== 1.1. How do I compile *band from source?
Unfortunately compiling Angband from source isn't trivial. New Vanilla
versions and possibly some other variants (including mine, PosBand :) have
"configure" script, and can be installed in a standard way. Be sure to read
installation instructions, though. Most likely, you'll need to run
"./configure" with options:
./configure --bindir=/usr/games --with-setgid=games \
--with-libpath=/usr/share/games/angband
Specify also options "CFLAGS=..." and/or "LIBS=...", if you need to set some
compilation options (see below).
Those *bands which don't have "configure" are typically built with
"src/Makefile.std" makefile. First of all, open it with a text editor, and
find the lines which set CFLAGS and LIBS variables:
##
## Variation -- compile for Linux
##
## Allows the use of Angband in the console using ncurses,
## as well as under X11.
##
CFLAGS = -I/usr/X11R6/include -I/usr/include/ncurses -Wall \
-O2 -fno-strength-reduce \
-D"USE_X11" -D"USE_GCU" -D"USE_NCURSES"
LIBS = -L/usr/X11R6/lib -lXaw -lXext -lSM -lICE -lXmu -lXt -lX11 -lncurses
If it looks scary, don't worry, you don't really need to understand all
these options :). You will likely need to add some options to the end of
CFLAGS line, though.
-D"USE_XXX"
Enables front-end "xxx". These are the possible frontends:
"cap" -- libtermcap. You'll also need to add "-ltermcap" to
LIBS line.
"gcu" -- curses. You'll also need to add "-lcurses" to
LIBS line, or, if you have "ncurses" version (Linux has),
"-I/usr/include/ncurses -D"USE_NCURSES" to CFLAGS and "-lncurses"
to LIBS. As you see, this is already done by default.
"gtk" -- GTK+. You'll also need to add "`gtk-config --cflags`"
(pay attention to backticks) to CFLAGS and "`gtk-config --libs`"
to LIBS.
"lsl" -- SVGALib (Linux-specific). There is a commented out
example of compiling with SVGALib.
"sla" -- S-Lang. You'll also need to add "-I/usr/include/slang"
to CFLAGS, and "-lslang" to LIBS.
"vcs" -- virtual console (Linux-specific).
"x11" -- X Window. You'll also need to add "-I/usr/X11R6/include"
to CFLAGS and "-L/usr/X11R6/lib -lX11" to LIBS -- done by default.
"xaw" -- Xaw. You'll also need to add "-I/usr/X11R6/include"
to CFLAGS and "-L/usr/X11R6/lib -lXaw -lXext -lSM -lICE -lXmu -lXt
-lX11" to LIBS (done by default, but -D"USE_XAW" itself is not
set).
"xpj" -- projected view for X Window. Same options as X Window.
See Q3.1 and Q4.1 for information on choosing front-ends.
Note that you'll need access to /dev/vcsa* devices to use "vcs"
front-end. You can do "chmod 666 /dev/vcsa*" as root to grant
access for all users. In multi-user environment (if two or more
users are going to be logged on this machine at the same time) this
is unsafe. Otherwise this should be ok.
-D"DEFAULT_PATH"=\"...\"
Sets hard-coded path to "lib" directory. If you are going to
install Angband system-wide, you'll need to set this.
"/usr/share/games/angband" will do fine. Different variants
need different directories, though!
To build Angband, type "make -f Makefile.std".
=== 1.2. How do I install *band?
Most of users run Angband from the directory where it was built. This is
simpler, and doesn't require root access. Just move the "angband" executable
from "src" directory to the top-level directory of the source tree. If you
don't plan to hack on Angband, you can strip it of debugging symbols
("strip -s angband") and remove the "src" directory.
You can also install Angband system-wide. Be sure that you did set
DEFAULT_PATH option during the compilation!
* Become root.
* Copy angband executable to "/usr/games" (or "/usr/bin", or
"/usr/local/games", or wherever you like). Chgrp it to games, and chmod to
2755. Strip it ("strip -s"). If it is some variant, be sure to rename
it to avoid confusion with Vanilla.
* Copy "lib" directory to DEFAULT_PATH.
* Chgrp to games and chmod to 775 subdirectories "apex" (for score file),
"bone" (for bone files -- unused on Vanilla), "data" (for precompiled
data files), "save" (for savefiles) and "user" (for dumps, pref files
etc.). Depending on the variant, you may need to do this for other
subdirectories.
* You may remove the source tree now.
=== 1.3. How to run *band?
First of all, if you didn't install Angband system-wide, cd to its source
tree. You'll need to specify the directory explicitly ("./angband") to run
it.
On Unix, Angband has some options. Run it with "-h" to view brief help.
The most important options are:
-g Turns on graphics (if possible).
-s Shows the high scores.
-mxxx Uses front-end "xxx".
-uName Loads the savefile "Name".
Each front-end may have its own suboptions. Suboptions need to be specified
after "--" option. Most important suboptions:
-b Big screen with "gcu", big tiles with graphic front-ends.
-o Uses 8x8 graphic tiles (if available).
-a Uses 16x16 graphic tiles by Adam Bolt (if available).
-g Uses 32x32 graphic tiles by David Gervais (if available).
-n Sets number of windows for graphic front-ends.
Examples:
angband -mgcu -- -b
Runs Angband in text-mode ("gcu" front-end), with big screen.
angband -mxaw -- -n4
Runs Angband in X Window ("xaw" front-end), with four windows.
angband -mxaw -g -- -n4 -a
Runs Angband in X Window ("xaw" front-end), with four windows,
with 16x16 tiles.
If you often run Angband with the same options, you can set a shell alias for
it (add "alias angband='angband ...'" to your ~/.bashrc, if you use bash).
=== 2. General questions ===
=== 2.1. The savefiles.
In Windows, DOS or Mac OS the name of the savefile is usually the same as the
name of your character. In Unix, things are a little different.
First of all, the name of the savefile includes your UID (User ID). Type "id"
command, if you don't know your UID. The savefiles are named "UID.Name". If
you copy a "Name" savefile from Windows, you won't be able to read it; you'll
need to rename it to "UID.Name". This way, if Angband is installed
system-wide, other users won't be able to overwrite your savefiles, even if
they use the same names.
By default, Angband uses the savefile "UID.Capitalized_login_name". E.g. if
your UID is 1000, and your login name is "fred", the game will try to use
"1000.Fred". To use the savefile with a different name, use "-u" option.
"-uJim", for example, will load "1000.Jim".
NPPAngband 0.1.x -- 0.3.x and PosBand 0.2.x -- 0.3.x also use a separate file
for character notes. Its name is *not* prefixed with UID, so note files of
different users potentially may clash. However, the note file is not terribly
important, and both NPPAngband 0.4.x and PosBand 0.9.9 fix this problem.
(NPPAngband 0.4.0 has even worse problem, though; it creates the temporary
note file with a fixed name "lib/file/_notes_.txt", so any two simultaneous
games will clash. The problem was reported to the maintainer.)
=== 3. Running *bands in console ===
=== 3.1. What front-end should I use for text mode?
There are four console, text-mode front-ends in Angband.
* "cap" -- libtermcap front-end. It uses "libtermcap" library for terminal
access. Unless you know what you are doing, don't bother with it. It is
awfully slow, black-and-white, and works correctly only on 80x24 terminals.
* "gcu" -- curses front-end, using "curses" or "ncurses" library. You
probably want this. It supports color and big screen mode.
* "sla" -- S-Lang front-end, using "S-Lang" library. You may try this if
you are curious. It supports color, but doesn't support big screen, and
isn't really any better than "gcu".
* "vcs" -- virtual console front-end. Linux-specific -- it uses /dev/vcsa*
devices for direct console access. It is the only front-end which
supports changing colors on Linux console. It also feels the fastest.
If you will play in a Linux console (not in xterm!), you may like this.
Beware that you'll have to enable access to /dev/vcsa* devices. This
is perfectly safe on home PCs and on most of LANs, but it may turn into
the security hole in the multi-user environment. See Q1.1 for details.
So, I recommend "gcu", and for Linux "vcs".
There is also "lsl" front-end, which is really a graphical one -- it uses
SVGALib library. I didn't try this myself; SVGALib apps seem to dislike my
video card.
=== 3.2. How to enable big-screen mode?
For "gcu": just use "-b" suboption ("angband -mgcu -- -b"). Use shell alias
if you don't want to type it all the time. Note that "gcu" by default uses
four windows -- the first one 80x24, it top left corner, and three others
occupying whatever is left. Try setting some windows with '=', 'w' and you'll
see. Personally, I like one big window better, but this is a matter of taste.
For "vcs": apply this patch
|---> CUT HERE <---|
diff -urN angband-3.0.5.orig/src/main-vcs.c angband-3.0.5/src/main-vcs.c
--- angband-3.0.5.orig/src/main-vcs.c 2005-01-09 23:44:51.000000000 +0500
+++ angband-3.0.5/src/main-vcs.c 2005-01-09 23:50:46.000000000 +0500
@@ -485,7 +485,7 @@
*/
game_termios.c_lflag &= ~(ICANON | ECHO | TOSTOP);
- term_data_link(0, 0, 0, 80, 24);
+ term_data_link(0, 0, 0, s_width, s_height);
/* Success */
return 0;
|---> CUT HERE <---|
Rebuild, reinstall (if needed) et voila!
=== 3.3. How to disable cursor?
[Linux-specific information.]
If you play Angband on Linux console with framebuffer (like me), you will soon
find out that the blinking block cursor makes the game very irritating. You
can turn it off by source hacking.
For "gcu": apply this patch.
|---> CUT HERE <---|
diff -urN angband-3.0.5.orig/src/config.h angband-3.0.5/src/config.h
--- angband-3.0.5.orig/src/config.h 2005-01-09 23:44:51.000000000 +0500
+++ angband-3.0.5/src/config.h 2005-01-09 23:45:33.000000000 +0500
@@ -70,8 +70,9 @@
/*
* OPTION: Use the "curs_set()" call in "main-gcu.c".
* Hack -- This option will not work on most BSD machines
+ * But it *will* work on Linux, which is not System V. -uav
*/
-#ifdef SYS_V
+#if defined(SYS_V) || defined(linux)
# define USE_CURS_SET
#endif
|---> CUT HERE <---|
For "vcs": apply that patch.
|---> CUT HERE <---|
diff -urN angband-3.0.5.orig/src/main-vcs.c angband-3.0.5/src/main-vcs.c
--- angband-3.0.5.orig/src/main-vcs.c 2005-01-09 23:44:51.000000000 +0500
+++ angband-3.0.5/src/main-vcs.c 2005-01-09 23:47:40.000000000 +0500
@@ -129,6 +129,13 @@
/* Analyze */
switch (n)
{
+ case TERM_XTRA_SHAPE:
+ {
+ printf("\033[?25%c", v ? 'h' : 'l');
+ fflush(stdout);
+ return(0);
+ }
+
case TERM_XTRA_EVENT:
{
int lch;
|---> CUT HERE <---|
=== 3.4. How to make walls show as blocks?
This depends on your character set.
For "gcu":
First try putting this in "lib/pref/font-gcu.prf".
|---> CUT HERE <---|
# File: font-gcu.prf
### Terrain features ###
# Magma (slate / solid block)
F:50:2/144
F:52:2/144
# Quartz (light slate / solid block)
F:51:1/144
F:53:1/144
# Secret door (white / solid block)
F:48:1/145
# Granite walls & permanent rock (white / solid block)
F:56:1/145
F:57:1/145
F:58:1/145
F:59:1/145
F:60:1/145
F:61:1/145
F:62:1/145
F:63:1/145
|---> CUT HERE <---|
It Works For Me (TM). If it doesn't for you, try adjusting the character
codes "144" and "145". You can use this command (small awk script) to print
the characters 128-255:
awk 'BEGIN { for (i = 0; i < 32; i++) printf("%c=%d %c=%d %c=%d %c=%d\n",
128+i, 128+i, 160+i, 160+i, 192+i, 192+i, 224+i, 224+i); }'
If your variant has some other wall-like features that you'd like to change to
blocks, follow the same pattern -- "F:<index>:<color>/<character>". Look at
"lib/edit/terrain.txt" (may be named "t_info.txt" or "f_info.txt")
file for the indices, and in "src/defines.h" for colors (look for
"#define TERM_...").
For "vcs":
First of all, put these lines in "lib/user/font.prf":
?:[EQU $SYS vcs]
%:font-vcs.prf
--so Angband will actually read your font-vcs.prf. Then, take font-gcu as a
template and start tweaking. The problem is, "vcs" uses raw character
codes, so your codes will almost certainly be different from mine (my font
has CP866 charset).
=== 3.5. How to set up colors?
For "gcu": sorry, no way.
But note that some variants use the old coloring scheme (white is gray,
gray is light blue), and others -- the new one (white is white, gray is gray).
Most people seem to like the new scheme, but on my old monitor it feels too
bright.
Changing the scheme requires, you guessed it, patching the source. To change
from the *old* scheme to the *new* one, apply this patch:
|---> CUT HERE <---|
diff -urN angband-3.0.5/src/main-gcu.c angband-3.0.5.orig/src/main-gcu.c
--- angband-3.0.5/src/main-gcu.c 2005-01-10 00:08:43.000000000 +0500
+++ angband-3.0.5.orig/src/main-gcu.c 2005-01-09 23:44:51.000000000 +0500
@@ -1080,15 +1080,15 @@
/* Prepare the colors */
colortable[0] = (COLOR_PAIR(7) | A_NORMAL); /* Black */
- colortable[1] = (COLOR_PAIR(0) | A_NORMAL); /* White */
- colortable[2] = (COLOR_PAIR(6) | A_NORMAL); /* Grey XXX */
+ colortable[1] = (COLOR_PAIR(0) | A_BRIGHT); /* White */
+ colortable[2] = (COLOR_PAIR(0) | A_NORMAL); /* Grey XXX */
colortable[3] = (COLOR_PAIR(1) | A_BRIGHT); /* Orange XXX */
colortable[4] = (COLOR_PAIR(1) | A_NORMAL); /* Red */
colortable[5] = (COLOR_PAIR(2) | A_NORMAL); /* Green */
colortable[6] = (COLOR_PAIR(4) | A_NORMAL); /* Blue */
colortable[7] = (COLOR_PAIR(3) | A_NORMAL); /* Umber */
colortable[8] = (COLOR_PAIR(7) | A_BRIGHT); /* Dark-grey XXX */
- colortable[9] = (COLOR_PAIR(6) | A_BRIGHT); /* Light-grey XXX */
+ colortable[9] = (COLOR_PAIR(0) | A_NORMAL); /* Light-grey XXX */
colortable[10] = (COLOR_PAIR(5) | A_NORMAL); /* Purple */
colortable[11] = (COLOR_PAIR(3) | A_BRIGHT); /* Yellow */
colortable[12] = (COLOR_PAIR(5) | A_BRIGHT); /* Light Red XXX */
|---> CUT HERE <---|
And to change from the *new* scheme to the *old* one, use:
|---> CUT HERE <---|
diff -urN angband-3.0.5.orig/src/main-gcu.c angband-3.0.5/src/main-gcu.c
--- angband-3.0.5.orig/src/main-gcu.c 2005-01-09 23:44:51.000000000 +0500
+++ angband-3.0.5/src/main-gcu.c 2005-01-10 00:08:43.000000000 +0500
@@ -1080,15 +1080,15 @@
/* Prepare the colors */
colortable[0] = (COLOR_PAIR(7) | A_NORMAL); /* Black */
- colortable[1] = (COLOR_PAIR(0) | A_BRIGHT); /* White */
- colortable[2] = (COLOR_PAIR(0) | A_NORMAL); /* Grey XXX */
+ colortable[1] = (COLOR_PAIR(0) | A_NORMAL); /* White */
+ colortable[2] = (COLOR_PAIR(6) | A_NORMAL); /* Grey XXX */
colortable[3] = (COLOR_PAIR(1) | A_BRIGHT); /* Orange XXX */
colortable[4] = (COLOR_PAIR(1) | A_NORMAL); /* Red */
colortable[5] = (COLOR_PAIR(2) | A_NORMAL); /* Green */
colortable[6] = (COLOR_PAIR(4) | A_NORMAL); /* Blue */
colortable[7] = (COLOR_PAIR(3) | A_NORMAL); /* Umber */
colortable[8] = (COLOR_PAIR(7) | A_BRIGHT); /* Dark-grey XXX */
- colortable[9] = (COLOR_PAIR(0) | A_NORMAL); /* Light-grey XXX */
+ colortable[9] = (COLOR_PAIR(6) | A_BRIGHT); /* Light-grey XXX */
colortable[10] = (COLOR_PAIR(5) | A_NORMAL); /* Purple */
colortable[11] = (COLOR_PAIR(3) | A_BRIGHT); /* Yellow */
colortable[12] = (COLOR_PAIR(5) | A_BRIGHT); /* Light Red XXX */
|---> CUT HERE <---|
[Note for maintainers: you should apply the patch which changes the old scheme
to the new one, if you haven't already done it.]
For "vcs": tweaking from the game (Shift-7) works perfectly.
=== 3.6. Ctrl-Z, Ctrl-S or Ctrl-Q don't work.
They shouldn't. In Unix (for text-mode programs) Ctrl-Z suspends the program
and puts you back to shell. Return back by typing "fg". Ctrl-S suspends the
program output -- until you press Ctrl-Q. Ctrl-C terminates the program
(since this is so dangerous, Angband already captures this keypress itself).
Ctrl-Z, Ctrl-S and Ctrl-Q are not intercepted, though, and will not behave as
expected.
To work around this limitation, press '^' (Shift-6) and the letter key. E.g.
"Ctrl-6, Z" is the same as "Ctrl-Z".
=== 3.7. The game reacts slowly when I press ESC.
This is a feature, too :-). From manpage of getch(3X):
NOTES
Use of the escape key by a programmer for a single charac-
ter function is discouraged, as it will cause a delay of
up to one second while the keypad code looks for a follow
ing function-key sequence.
Pressing '`' (the backtick, usually to the left from '1' key) has the same
effect as ESC, without one-second delay.
=== 3.8. I cannot run with Shift-direction.
This one is unclear to me yet. Run with '.' followed by direction key.
=== 4. Running *bands in X Window ===
=== 4.1. What front-end should I use for graphics mode? ===
Again, you have some choice here :).
* "gtk" -- uses GTK+ library. At least in Vanilla, this one is very
unfinished, and buggy. There isn't really much point in using this.
* "x11" -- plain X Window.
* "xaw" -- uses Xaw library. Looks exactly like "x11", but you can
tweak it with X resources.
* "xpj" -- so-called "X projected". An attempt of pseudo-3D view for
Angband. Works only with Adam Bolt's tiles, and 16x16.txt font
(ever wondered why it was there?). Looks funny, but isn't really
playable, and looks pretty bad. Look for "Iso-Angband"; it is
very unfinished, but it looks much better than "xpj".
Unless you have some specific reasons, I strongly recommend "xaw".
Unfortunately, Makefile.std by default compiles in "x11".
=== 4.2. How to set up fonts and window positions?
This is the voodoo part :).
For "gtk": you can change the font from the menu, though it is not permanent.
No idea about window positions.
For "x11": use the environment variables.
* ANGBAND_X11_FONT_n -- font for window n (window 0 is main window)
* ANGBAND_X11_AT_X_n, ANGBAND_X11_AT_Y_n -- position of window n
* ANGBAND_X11_ROWS_n, ANGBAND_X11_COLS_n -- size of window n
* ANGBAND_X11_IBOX_n, ANGBAND_X11_IBOY_n -- inner border offset of window n
Look at the comments near the beginning of "src/main-x11.c" for example.
If you think that it's silly to tweak programs with environment variables,
then I agree :). That's why I suggest using "xaw".
For "xaw": use X resources. If you don't know what X resources are, read
manpage X(7), section "RESOURCES".
Put the following in your ~/.Xdefaults file (or .Xresources, or whatever):
.angband*Angband*font: <main window font>
.angband*angband*geometry: <main window geometry>
.angband*term-1*font: <window 1 font>
.angband*term-1*geometry: <window 1 geometry>
...
Any valid X fonts (monospaced) can be specified. You can find the font you
like with xfontsel(1). You can also specify the alias, like "6x10",
"6x13bold", etc. -- look at /usr/X11R6/lib/X11/fonts/misc/fonts.alias.
Geometry is also given in X format -- <width>x<height>+<x>+<y>; width and
height are in characters.
For variants, change ".angband" to the name of the variant.
Unfortunately there is a bug in "xaw" front-end, which makes Angband crash if
you try to redefine the geometry for the main window. Apply this patch to fix
it:
|---> CUT HERE <---|
diff -urN angband-3.0.5.orig/src/main-xaw.c angband-3.0.5/src/main-xaw.c
--- angband-3.0.5.orig/src/main-xaw.c 2005-01-09 23:44:51.000000000 +0500
+++ angband-3.0.5/src/main-xaw.c 2005-01-10 10:31:21.000000000 +0500
@@ -668,9 +668,11 @@
int oy = wnew->angband.internal_border;
int i;
- term_data *old_td = (term_data*)(Term->data);
+ term_data *old_td = NULL;
term_data *td = &data[0];
+ if (Term) old_td = (term_data*)(Term->data);
+
/* Hack - Find the term to activate */
for (i = 0; i < num_term; i++)
{
@@ -709,7 +711,7 @@
(void) Term_resize(cols, rows);
/* Activate the old term */
- Term_activate(&old_td->t);
+ if (old_td) Term_activate(&old_td->t);
}
/*
|---> CUT HERE <---|
For "xpj": the font is fixed, you can't change it. Window position settings
are the same as for "x11".
=== 4.3. How to make walls show as blocks?
Add these lines to the bottom of "lib/pref/font-x11.prf" file:
|---> CUT HERE <---|
# open floor
F:1:0x01:0x1F
# invisible trap
F:2:0x01:0x1F
# magma vein
F:50:0x08:0x02
# quartz vein
F:51:0x02:0x02
# magma vein
F:52:0x08:0x02
# quartz vein
F:53:0x02:0x02
# magma vein with treasure
F:54:0x03:0x01
# quartz vein with treasure
F:55:0x03:0x01
# granite wall
F:56:0x01:0x02
# granite wall
F:57:0x01:0x02
# granite wall
F:58:0x01:0x02
# granite wall
F:59:0x01:0x02
# permanent wall
F:60:0x01:0x02
# permanent wall
F:61:0x01:0x02
# permanent wall
F:62:0x01:0x02
# permanent wall
F:63:0x01:0x02
|---> CUT HERE <---|
AFAICT, these work fine on all systems regardless of the charset.
=== 4.4. How to install graphic tiles?
Just like Windows. Unzip them into "lib/xtra/graf". Option "-g" turns on
graphics. Suboptions (need to be after "--") are: "-o" for original 8x8
tiles, "-a" for 16x16 tiles by Adam Bolt, "-g" for 32x32 tiles by David
Gervais (unfortunately they get mercilessly scaled down), and "-b" for bigtile
mode. In the normal mode, the tile size is equal to the character size. In
the bigtile mode, the tile is twice wider than the character. 8x16 font with
bigtile mode will be a good choice, if you have one (Slackware Linux comes with
"linux8x16", which is actually the Linux console font, converted in X format.
This is my favorite, although I don't play with tiles).
Good luck!
--
Alexander Ulyanov, maintainer of PosBand roguelike
E-mail: uav AT urmail DOT ru Web: http://orthanc.chat.ru/pos/
Anyone who is capable of getting themselves made President should on no
account be allowed to do the job. -- The Hitchhiker's Guide To The Galaxy
Velvet Elvis
> === 1.1. How do I compile *band from source?
>
> Unfortunately compiling Angband from source isn't trivial. New Vanilla
> versions and possibly some other variants (including mine, PosBand :) have
> "configure" script, and can be installed in a standard way. Be sure to read
> installation instructions, though. Most likely, you'll need to run
> "./configure" with options:
>
> ./configure --bindir=/usr/games --with-setgid=games \
> --with-libpath=/usr/share/games/angband
I've always just played from the source directory. It only gets
complicated when you want to install it to a multiuser enviornment.
The Quick and Dirty Newbie's method that works 3/4 of the time for me.
1. Unzip tarball with midnight commander. If the packager insists on
using zip, use some GUI tool.
2. cd /home/username/angband/src
3. make -f Makefile.std/Makefile.org
4. cd ..
5. ./src/angband
6. Play the damn thing
You might want to include instructions on how to keep a million windows
from popping up when you play a variant based on old Z code under X.
Hellband and Gumband are a couple that do this. I can never remember the
switches.
Alexander Ulyanov
> On Mon, 10 Jan 2005 09:30:28 +0000, Alexander Ulyanov wrote:
>
>
>> === 1.1. How do I compile *band from source?
>>
>> Unfortunately compiling Angband from source isn't trivial. New Vanilla
>> versions and possibly some other variants (including mine, PosBand :) have
>> "configure" script, and can be installed in a standard way. Be sure to read
>> installation instructions, though. Most likely, you'll need to run
>> "./configure" with options:
>>
>> ./configure --bindir=/usr/games --with-setgid=games \
>> --with-libpath=/usr/share/games/angband
>
> I've always just played from the source directory. It only gets
> complicated when you want to install it to a multiuser enviornment.
>
> The Quick and Dirty Newbie's method that works 3/4 of the time for me.
Exactly. I used to play from the source directory, too, but it always
felt a little dirty way.
> You might want to include instructions on how to keep a million windows
> from popping up when you play a variant based on old Z code under X.
> Hellband and Gumband are a couple that do this. I can never remember the
> switches.
Thanks.
BTW, the up-to-date version is at
"http://posband.earthsea.org/unix-faq/".
I won't post it there, as it will waste lots of bandwidth and likely
annoy many folks.
--
Alexander Ulyanov, maintainer of PosBand roguelike
E-mail: posband_AT_earthsea_DOT_org Web: http://posband.earthsea.org/
magnate
> Due to the large number of posts with Linux-related questions,
> I have decided to write this FAQ. I will also send it to Robert,
> and upload on my PosBand site.
Hi Alex,
Great idea for a FAQ - well done. Just one suggested addition:
"Where is the package file of *band variant X for distribution Y?"
Answer: here is the list of known packages -
Debian Woody:
Vanilla Angband 2.9.x (put link to package file here, or just package
name)
Debian Sarge:
Vanilla Angband 3.0.5 (link or package name)
ToME 2.?.? (link or name)
Sangband 0.9.9beta15 (link or name)
RedHat 6.x,7.x,8.x,9.x:
Etc.
RedHat Fedora:
Etc.
Mandrake 9.x:
You get the idea ....
- a lot of people's problems with installing and running *band have
been solved by those of us who have created packages of our favourite
variants for our favourite distributions!
Obviously you may not be able to populate that list much to start with,
but it'll grow as people tip you off about packages.
Best,
CC
Alexander Ulyanov
> Alexander Ulyanov wrote:
>> Due to the large number of posts with Linux-related questions,
>> I have decided to write this FAQ. I will also send it to Robert,
>> and upload on my PosBand site.
>
> Hi Alex,
>
> Great idea for a FAQ - well done. Just one suggested addition:
>
> "Where is the package file of *band variant X for distribution Y?"
>
> Answer: here is the list of known packages -
Thanks. This is a good idea.
Actually, I think I can do some packages (RPM and TGZ) myself. I've
done then for latest NPP and PosBand 0.9.9. I think I can handle other
variants, too. There are no packages for the current versions of
Vanilla and ToME, right? Perhaps I can volunteer.
So, if anyone wants me to do a Linux package of your favorite variant,
just let me know :).
--
Alexander Ulyanov, maintainer of PosBand roguelike
E-mail: posband_AT_earthsea_DOT_org Web: http://posband.earthsea.org/
jwk
Date: 20 Jan 2005 07:20:21 -0800
> Alexander Ulyanov wrote:
>> Due to the large number of posts with Linux-related questions,
>> I have decided to write this FAQ. I will also send it to Robert,
>> and upload on my PosBand site.
>
> Hi Alex,
>
> Great idea for a FAQ - well done. Just one suggested addition:
>
> "Where is the package file of *band variant X for distribution Y?"
>
> Answer: here is the list of known packages -
>
information in the first place, for example:
Debian:
apt-cache search angband
Jurriaan
--
Das ganze Saarland ist von M$ besetzt - das ganze? Nein eine kleine
Gruppe im Sudwesten trotzt dem ubergrosen Herrscher dank ihres
Zaubertrankes Linux
Tooster on #LinuxGER
Debian (Unstable) GNU/Linux 2.6.10-mm1 2x6078 bogomips load 1.35
Murphy S.
> > Hi Alex,
> >
> > Great idea for a FAQ - well done. Just one suggested addition:
> >
> > "Where is the package file of *band variant X for distribution Y?"
> >
> > Answer: here is the list of known packages -
> >
> That would get stale very fast. Why not explain how to get this
> information in the first place, for example:
>
> Debian:
> apt-cache search angband
>
Great work on the faq; I agree its an excellent idea.
My suggestion would be to continue to promote compiling from source as
the preferred way to install *band on a linux/unix system rather than
installing from packages, because:
1. one set of instructions can cover many variants
2. only root user can install packages, but any user can compile from
source
3. can have library dependency issues with packages, e.g. end user
needs same versions of libraries as whoever built the package
Murphy S.
Alexander Ulyanov
>> >
>> > Hi Alex,
>> >
>> > Great idea for a FAQ - well done. Just one suggested addition:
>> >
>> > "Where is the package file of *band variant X for distribution Y?"
>> >
>> > Answer: here is the list of known packages -
>> >
>> That would get stale very fast. Why not explain how to get this
>> information in the first place, for example:
>>
>> Debian:
>> apt-cache search angband
Thanks -- I have never used Debian myself.
>
> Great work on the faq; I agree its an excellent idea.
>
> My suggestion would be to continue to promote compiling from source as
> the preferred way to install *band on a linux/unix system rather than
> installing from packages,
Well, personally I don't trust much any packages which are not included
in the distribution, but non-technical users can find it convenient.
> because:
> 1. one set of instructions can cover many variants
Yes. But there are subtle differences (and not-so-subtle ones, if you
look at ToME).
> 3. can have library dependency issues with packages, e.g. end user
> needs same versions of libraries as whoever built the package
This is true in general, but remember that *bands don't require any
unusual libraries:
* glibc -- I compile my packages on Red Hat 7.3 (with GCC upgraded
to 3.2.2!), which has glibc 2.2.5. AFAICT, my packages require
at least glibc 2.1. This is old enough version to be safe.
* NCurses -- not so sure about this, but NCurses 5.x seems to be
ubiquitous.
* Xlib/Xaw/other X libraries -- never saw any problem with them.
Their API/ABI is stable, right?
--
Alexander Ulyanov, maintainer of PosBand roguelike
E-mail: posband_AT_earthsea_DOT_org Web: http://posband.earthsea.org/
DarkGod
> This is true in general, but remember that *bands don't require any
> unusual libraries:
>
> * glibc -- I compile my packages on Red Hat 7.3 (with GCC upgraded
> to 3.2.2!), which has glibc 2.2.5. AFAICT, my packages require
> at least glibc 2.1. This is old enough version to be safe.
I plan to distribute new versions of ToME as linux binaries using
autopackage(http://autopackage.org), they have a tool to make sure your
binary is as portable as possible.
They also provide a way to make binaries rellocatable(that is, they dont
have to use hardcoded paths like /usr/share/angband/lib and thus can be
installed anywhere). I wont be using the rellocation stuff myself in ToME
3 because I have already this ability due to the use of physfs but from
what I saw it seems like it works fine.
Murphy S.
> > needs same versions of libraries as whoever built the package
>
> This is true in general, but remember that *bands don't require any
> unusual libraries:
>
> * glibc -- I compile my packages on Red Hat 7.3 (with GCC upgraded
> to 3.2.2!), which has glibc 2.2.5. AFAICT, my packages require
> at least glibc 2.1. This is old enough version to be safe.
>
> * NCurses -- not so sure about this, but NCurses 5.x seems to be
> ubiquitous.
>
> * Xlib/Xaw/other X libraries -- never saw any problem with them.
> Their API/ABI is stable, right?
>
Back when I used to run mandrake 9.0 I had trouble trying to compile Z
with gtk. As I recall I had to use the "linux-no-gtk" target in
"zangband/src/makefile.std" to get it to compile ... I remember keeping
some notes about the issue but I can't find them now and I've since
switched to debian anyway ...
Murphy S.
magnate
> > > "Where is the package file of *band variant X for distribution
Y?"
> > >
> > > Answer: here is the list of known packages -
> > That would get stale very fast. Why not explain how to get this
> > information in the first place, for example:
> >
> > Debian:
> > apt-cache search angband
I guess it depends how often the FAQ gets updated, and how often people
rebuild the packages! I guess it would get stale for some of the newer,
faster developing variants, but things like V and S should be pretty
safe. You're right that it would be a good idea to include instructions
on how to look for more modern versions in each distribution - perhaps
just a link to the V package (which will get updated very rarely), and
instructions on how to find others?
> My suggestion would be to continue to promote compiling from source
as
> the preferred way to install *band on a linux/unix system rather than
> installing from packages, because:
I disagree with this *completely*.
> 1. one set of instructions can cover many variants
No, that's just not correct. One basic set of instructions will require
lots and lots of little things done differently for different variants
(since there is no agreed form or structure of *band sources). It would
be far easier to give basic instructions on how to install a package!
> 2. only root user can install packages, but any user can compile from
> source
Not necessarily, and this is in any case a moot point - most home users
will have root access, in fact most users of linux on PCs will have
root access (except undergrad students, who will probably be techie
enough to compile it).
> 3. can have library dependency issues with packages, e.g. end user
> needs same versions of libraries as whoever built the package
As someone else said, *band's library requirements are so basic that
this shouldn't be a problem on any linux system - glibc, ncurses and
gtk/Xaw/etc.
The most important reason I disagree is none of the above. I think it's
important to have this debate - it's all about user-friendliness. Linux
has taken a decade to become mainstream precisely because it required a
huge amount of technical knowledge and skill to set up and use. IMHO
the advent of packaging systems is the single biggest reason Linux has
become more easy to use (and therefore more widely used).
I may be wrong, but I think most home Linux users would be quite
comfortable installing a package - they probably had to know how to do
that to get it running in the first place, and they've probably
installed *something* new since they finished the initial installation.
Whereas they might well be totally scared of trying to compile anything
(they might never have compiled anything before, ever).
I'm not saying that we shouldn't include help on compiling *band, not
at all. I'm just saying that we should promote finding and installing a
prebuilt package as the first way to get *band onto your Linux system,
*then* describe compiling "for advanced users". I honestly think that
will appeal to a lot more people, who would otherwise be put off trying
*band.
YMMV.
CC
Bruce Sinclair
(snip)
>I'm not saying that we shouldn't include help on compiling *band, not
>at all. I'm just saying that we should promote finding and installing a
>prebuilt package as the first way to get *band onto your Linux system,
>*then* describe compiling "for advanced users". I honestly think that
>will appeal to a lot more people, who would otherwise be put off trying
>*band.
With you here 100 %. My first (unsuccesful !) compile was scary. My first
package install OTOH, went smoothly. If only others had gone as well since
:)
Bruce
-----------------------------------------------------------------------
It was so much easier to blame it on Them. It was bleakly depressing to
think that They were Us. If it was Them, then nothing was anyone´s fault.
If it was Us, what did that make Me ? After all, I´m one of Us. I must be.
I´ve certainly never thought of myself as one of Them. No-one ever thinks
of themselves as one of Them. We´re always one of Us. It´s Them that do
the bad things. <=> Terry Pratchett. Jingo.
Caution ===== followups may have been changed to relevant groups
(if there were any)
Alexander Ulyanov
> On Mon, 24 Jan 2005 11:06:04 +0000, Alexander Ulyanov wrote:
>
>> This is true in general, but remember that *bands don't require any
>> unusual libraries:
>>
>> * glibc -- I compile my packages on Red Hat 7.3 (with GCC upgraded
>> to 3.2.2!), which has glibc 2.2.5. AFAICT, my packages require
>> at least glibc 2.1. This is old enough version to be safe.
>
> I plan to distribute new versions of ToME as linux binaries using
> autopackage(http://autopackage.org), they have a tool to make sure your
> binary is as portable as possible.
And I have just built ToME 2.3.1 packages... Looks like you won't need
them :).
> They also provide a way to make binaries rellocatable(that is, they dont
> have to use hardcoded paths like /usr/share/angband/lib and thus can be
> installed anywhere).
I find this doubtful. How "autopackage" can know that the binary
hardcodes /usr/share/angband/lib? If you somehow feed this information
in it before the compilation, you might as well implement this yourself.
If it uses some kind of wrapper, then it's ugly and error-prone
solution.
And anyway, why on earth would anyone want to install the package in
another place? /usr/share/angband/lib (actually, I use
/usr/share/games/<variant>) is *right*. FHS says so. There is *no*
reason to put this directory in any other place. Of course, there are
people who install each piece of software in /opt, but that's just
because of their brain damage caused by Windows. Linux has completely
different filesystem layout.
> I wont be using the rellocation stuff myself in ToME
> 3 because I have already this ability due to the use of physfs but from
> what I saw it seems like it works fine.
Of course, I respect your choice, but personally I find package relocation
an extremely stupid idea.
DarkGod
>> I plan to distribute new versions of ToME as linux binaries using
>> autopackage(http://autopackage.org), they have a tool to make sure your
>> binary is as portable as possible.
> And I have just built ToME 2.3.1 packages... Looks like you won't need
> them :).
I will only start with ToME 300, and anyway you're welcome :)
>> They also provide a way to make binaries rellocatable(that is, they dont
>> have to use hardcoded paths like /usr/share/angband/lib and thus can be
>> installed anywhere).
> I find this doubtful. How "autopackage" can know that the binary
> hardcodes /usr/share/angband/lib? If you somehow feed this information
> in it before the compilation, you might as well implement this yourself.
> If it uses some kind of wrapper, then it's ugly and error-prone
> solution.
It uses IIRC a small wrapper which seems to work evry well.
But really since I dont use it I cant comment, I suggest you go to
http://autopackage.org and read a bit ;)
> And anyway, why on earth would anyone want to install the package in
> another place? /usr/share/angband/lib (actually, I use
> /usr/share/games/<variant>) is *right*. FHS says so. There is *no*
> reason to put this directory in any other place. Of course, there are
> people who install each piece of software in /opt, but that's just
> because of their brain damage caused by Windows. Linux has completely
> different filesystem layout.
What about people that want to play but are not root ? or just dont
want to install it as root ?
What about people that usr /usr for distrib stuff and /usr/local for
manualy installed stuff?
>> I wont be using the rellocation stuff myself in ToME
>> 3 because I have already this ability due to the use of physfs but from
>> what I saw it seems like it works fine.
> Of course, I respect your choice, but personally I find package relocation
> an extremely stupid idea.
I did not use it to this end it just is a nice side effect of the VFS.
Alexander Ulyanov
> On Tue, 25 Jan 2005 10:51:12 +0000, Alexander Ulyanov wrote:
>
>>> I plan to distribute new versions of ToME as linux binaries using
>>> autopackage(http://autopackage.org), they have a tool to make sure your
>>> binary is as portable as possible.
>> And I have just built ToME 2.3.1 packages... Looks like you won't need
>> them :).
> I will only start with ToME 300, and anyway you're welcome :)
BTW, why don't you use autoconf? That way, installing would be as easy
as "./configure && make && make install" and packages would be less
necessary.
>> And anyway, why on earth would anyone want to install the package in
>> another place? /usr/share/angband/lib (actually, I use
>> /usr/share/games/<variant>) is *right*. FHS says so. There is *no*
>> reason to put this directory in any other place. Of course, there are
>> people who install each piece of software in /opt, but that's just
>> because of their brain damage caused by Windows. Linux has completely
>> different filesystem layout.
> What about people that want to play but are not root ?
1). Ask their admin.
2). Compile the game themselves. Who said that playing at work should
be easy? :-)
> or just dont
> want to install it as root ?
Why?
> What about people that usr /usr for distrib stuff and /usr/local for
> manualy installed stuff?
*All* packages are installed in /usr. /usr/local is for things that the
users build manually.
Juergen Frieling
>
>> What about people that usr /usr for distrib stuff and /usr/local for
>> manualy installed stuff?
>
> *All* packages are installed in /usr. /usr/local is for things that the
> users build manually.
If you follow the traditional UNIX way, /usr is just for the system
distribution. A 3rd party package clearly doesn't belong there.
Many Linuxers think all stuff that is installed with the package system
should go to /usr - many other (me included) still think 3rd party
packages should go to /usr/local...
And btw: I just installed the ToME port on FreeBSD - guess where the
stuff went :-) AFAIR FreeBSD even installs many packages from the
install-CD to /usr/local (because they aren't bsd-licensed and so not
really a part of the BSD-distribution, I think)
Juergen
Murphy S.
> In article <1106597380....@f14g2000cwb.googlegroups.com>,
"magnate" <chr...@dbass.demon.co.uk> wrote:
> (snip)
> >I'm not saying that we shouldn't include help on compiling *band,
not
> >at all. I'm just saying that we should promote finding and
installing a
> >prebuilt package as the first way to get *band onto your Linux
system,
> >*then* describe compiling "for advanced users". I honestly think
that
> >will appeal to a lot more people, who would otherwise be put off
trying
> >*band.
>
> With you here 100 %. My first (unsuccesful !) compile was scary. My
first
> package install OTOH, went smoothly. If only others had gone as well
since
> :)
>
>
I guess I have a minor objection to the package method in principle,
just because it seems to go against the spirit of open source to
distribute software as binaries. But your point is well taken; if it
makes the software accessible to more users which in turn helps promote
linux then I'm certainly for that.
But philosophical debate aside, there's still a monumental task waiting
for someone if they want to build all these packages ... even just from
multiplying the few dozen active variants by a couple of linux
distributions.
Plus if you want the packages distributed via official channels (e.g.
apt-get for debian) there's the logistical issue of getting the
packages signed and uploaded to the debian archives, and I dunno if
there could even be any copyright/license issues with any of the
variants that would disallow that.
Murphy S.
DarkGod
of confusion Alexander Ulyanov wrote:
>> I will only start with ToME 300, and anyway you're welcome :)
> BTW, why don't you use autoconf? That way, installing would be as easy as
> "./configure && make && make install" and packages would be less
> necessary.
I'm not a big fan of autoconf, specially when it comes to setting it up
myself ;)
But I might someady
>> What about people that want to play but are not root ?
> 1). Ask their admin.
> 2). Compile the game themselves. Who said that playing at work should be
> easy? :-)
Lol ;)
>> or just dont
>> want to install it as root ?
> Why?
Because! :)
>> What about people that usr /usr for distrib stuff and /usr/local for
>> manualy installed stuff?
> *All* packages are installed in /usr. /usr/local is for things that the
> users build manually.
I disagree, I run gentoo and I try to never mess with /usr, that is gentoo
playground and I dont want to mess it, /usr/local is my playground and
gentoo never mess with it.
--
DarkGod comes from | Do not meddle in the affairs of wizards
the hells for YOU ! :) | because they are subtle and quick to anger.
-----------------------+----------------------------------------------
ToME power! http://t-o-m-e.net
Alexander Ulyanov
> The Thu, 27 Jan 2005 11:03:37 +0000, after eating far too many mushrooms
> of confusion Alexander Ulyanov wrote:
>
>>> I will only start with ToME 300, and anyway you're welcome :)
>> BTW, why don't you use autoconf? That way, installing would be as easy as
>> "./configure && make && make install" and packages would be less
>> necessary.
> I'm not a big fan of autoconf, specially when it comes to setting it up
> myself ;)
> But I might someady
I had hacked it in for the packages, that's why I asked. :) I can mail
you a patch.
>>> What about people that usr /usr for distrib stuff and /usr/local for
>>> manualy installed stuff?
>> *All* packages are installed in /usr. /usr/local is for things that the
>> users build manually.
> I disagree, I run gentoo and I try to never mess with /usr, that is gentoo
> playground and I dont want to mess it,
But ToME or Angband installation won't mess anything.
> /usr/local is my playground and
> gentoo never mess with it.
I run Slackware. And the whole filesystem is my own playground <g>.
Alexander Ulyanov
> Am 27 Jan 2005 11:03:37 GMT, schrieb Alexander Ulyanov:
>>
>>> What about people that usr /usr for distrib stuff and /usr/local for
>>> manualy installed stuff?
>>
>> *All* packages are installed in /usr. /usr/local is for things that the
>> users build manually.
>
> If you follow the traditional UNIX way, /usr is just for the system
> distribution. A 3rd party package clearly doesn't belong there.
Maybe. But installing packages to /usr is a de-facto standard, anyway.
> Many Linuxers think all stuff that is installed with the package system
> should go to /usr - many other (me included) still think 3rd party
> packages should go to /usr/local...
>
> And btw: I just installed the ToME port on FreeBSD - guess where the
> stuff went :-) AFAIR FreeBSD even installs many packages from the
> install-CD to /usr/local (because they aren't bsd-licensed and so not
> really a part of the BSD-distribution, I think)
That's BSD, not Linux :).
Mikko Nahkola
> Bruce Sinclair wrote:
>> In article <1106597380....@f14g2000cwb.googlegroups.com>,
> "magnate" <chr...@dbass.demon.co.uk> wrote:
>> (snip)
>> >I'm not saying that we shouldn't include help on compiling *band,
> not
>> >at all. I'm just saying that we should promote finding and
> installing a
>> >prebuilt package as the first way to get *band onto your Linux
> system,
>> >*then* describe compiling "for advanced users". I honestly think
> that
>> >will appeal to a lot more people, who would otherwise be put off
> trying
>> >*band.
>>
>> With you here 100 %. My first (unsuccesful !) compile was scary. My
> first
>> package install OTOH, went smoothly. If only others had gone as well
> since
>> :)
Well, there's the fact that it's unlikely that up-to-date binary
packages (both in the *band _and_ host OS terms) would be consistently
available anyway so IMHO it's important to have the compiling process
described up front.
> I guess I have a minor objection to the package method in principle,
> just because it seems to go against the spirit of open source to
> distribute software as binaries. But your point is well taken; if it
> makes the software accessible to more users which in turn helps promote
> linux then I'm certainly for that.
Well. Not sure if we're at the point where binary-packaging Angband is
likely to help promote Linux noticeably, anymore.
So ... anyone to make a package for Debian/hurd-i386 ? ;-)
> But philosophical debate aside, there's still a monumental task waiting
> for someone if they want to build all these packages ... even just from
> multiplying the few dozen active variants by a couple of linux
> distributions.
Plus hardware architectures. And then there are the non-Linux things
too - the BSDs and commercial UNIXes. The build process is effectively
the same for all of these, but binary packaging is very different.
Oh, and different "flavors" too. There seems to be a fundamental problem
with gtk and setgid (they don't like each other) so I choose setgid
without gtk every time (playing mostly with (n)curses bigscreen
nowadays) but ... someone might want to run without even X libraries.
I haven't tried to build V on NetBSD/Sparc since I noticed that the
autoconf script just plain refuses to look for ncurses in
/usr/pkg/include and /usr/pkg/lib, which is where I happened to have it...
(but it was three years ago already, an early release of V to have
autoconf, could well have been fixed a release or two ago already... and
the SparcStation does have mainboard problems.)
V 3.0.5 builds just fine on OpenBSD 3.6 / i386, though. Just "./configure
--prefix=/whatever/path --with-setgid=games ; make ; sudo make install"
and there you go, a full multiuser installation.
Oh, and both probably have an older version, OpenBSD definitely has 2.9.3,
in their package collection already.
Likewise Debian has 2.9.1-2 in stable/non-free.
> Plus if you want the packages distributed via official channels (e.g.
> apt-get for debian) there's the logistical issue of getting the
> packages signed and uploaded to the debian archives, and I dunno if
> there could even be any copyright/license issues with any of the
> variants that would disallow that.
Indeed, Debian for example does classify the Angband license as
"non-free" already, therefore not to be included in the base archive
anyway ... yes. http://packages.debian.org/stable/games/angband :
Package: angband (291-2) [non-free]
architectures: alpha arm i386 ia64 m68k powerpc s390 sparc
--
Mikko Nahkola <mnah...@trein.ntc.nokia.com>
#include <disclaimer.h>
#Not speaking for my employer. No warranty. YMMV.
Mikko Nahkola
> On 2005-01-18, Velvet Elvis <ongamb...@softhome.net> wrote:
>> On Mon, 10 Jan 2005 09:30:28 +0000, Alexander Ulyanov wrote:
>>
>>
>>> === 1.1. How do I compile *band from source?
>>>
>>> Unfortunately compiling Angband from source isn't trivial. New Vanilla
>>> versions and possibly some other variants (including mine, PosBand :) have
>>> "configure" script, and can be installed in a standard way. Be sure to read
>>> installation instructions, though. Most likely, you'll need to run
>>> "./configure" with options:
>>>
>>> ./configure --bindir=/usr/games --with-setgid=games \
>>> --with-libpath=/usr/share/games/angband
>>
>> I've always just played from the source directory. It only gets
>> complicated when you want to install it to a multiuser enviornment.
> felt a little dirty way.
Well, isn't it only the setgid part which prevents you from installing it
_somewhere_ even as non-root?
"./configure --prefix=/home/me/games --without-setgid && make && make
install ; export PATH=$PATH:/home/me/games/bin ; angband" ?
That was the usual way to install a GNU toolset on something where the
sysadmin wasn't cooperating.
> BTW, the up-to-date version is at
> "http://posband.earthsea.org/unix-faq/".
> I won't post it there, as it will waste lots of bandwidth and likely
> annoy many folks.
Proposed additions,
1.1 and 1.2: after the ./configure, just "make" is
supposed to compile the thing, and "make install" as root is supposed to
install the thing into the location specified on the configure command
line.
Indeed, it's possible in some circumstances to build and install an
autoconf-enabled variant (or vanilla) with a single command line
(assuming there are no fatal errors during build), for example:
./configure [configure-options] && make && sudo make install
Using ';' instead of the '&&' means that it'll try to install even if
there _were_ fatal errors during build - not recommended but technically
possible, results may be ... less than optimal.
I did just that to V3.0.5 on OpenBSD a couple of days ago. I think I
should go back and redo it, it took x11 instead of xaw but then again I
usually use the curses frontend even in X.
Oh, and do explain the --prefix option to configure, I at least find it
very useful very often.
1.3: do mention the PATH variable, will you?
3.6: Well, they work as they should in Unix already, don't they? I
regularly use ^Z to suspend angband and do something else in the useful
big terminal window (I usually use curses bigscreen in an xterm) for a
while, then switch back to angband.
Mikko Nahkola
> Am 27 Jan 2005 11:03:37 GMT, schrieb Alexander Ulyanov:
>>> What about people that usr /usr for distrib stuff and /usr/local for
>>> manualy installed stuff?
>>
>> *All* packages are installed in /usr. /usr/local is for things that the
>> users build manually.
>
> If you follow the traditional UNIX way, /usr is just for the system
> distribution. A 3rd party package clearly doesn't belong there.
>
> Many Linuxers think all stuff that is installed with the package system
> should go to /usr - many other (me included) still think 3rd party
> packages should go to /usr/local...
Or /opt or possibly in /usr/pkg or some such.
> And btw: I just installed the ToME port on FreeBSD - guess where the
> stuff went :-) AFAIR FreeBSD even installs many packages from the
> install-CD to /usr/local (because they aren't bsd-licensed and so not
> really a part of the BSD-distribution, I think)
And as an example from the commercial UNIX world, HP-UX comes with certain
GNU and other such utilities - which live in /usr/contrib. (And certain
HP-written scripts then proceed to call /usr/contrib/bin/gzip by full
path.)
Mikko Nahkola
> On 2005-01-27, Juergen Frieling <jue...@beer.com> wrote:
>> Am 27 Jan 2005 11:03:37 GMT, schrieb Alexander Ulyanov:
>>>> What about people that usr /usr for distrib stuff and /usr/local for
>>>> manualy installed stuff?
>>>
>>> *All* packages are installed in /usr. /usr/local is for things that the
>>> users build manually.
>>
>> If you follow the traditional UNIX way, /usr is just for the system
>> distribution. A 3rd party package clearly doesn't belong there.
>
> Maybe. But installing packages to /usr is a de-facto standard, anyway.
It's a BSD4.3-ism, that's what it is.
>> Many Linuxers think all stuff that is installed with the package system
>> should go to /usr - many other (me included) still think 3rd party
>> packages should go to /usr/local...
>>
>> And btw: I just installed the ToME port on FreeBSD - guess where the
>> stuff went :-) AFAIR FreeBSD even installs many packages from the
>> install-CD to /usr/local (because they aren't bsd-licensed and so not
>> really a part of the BSD-distribution, I think)
> That's BSD, not Linux :).
But BSD has gotten a bit more sane since 4.3. The different BSDs in
occasionally slightly different ways, too.
The non-BSD end of the line is with a whole bunch of technically non-core
but practically always required software in /opt/ subtrees. That has
often been overdone too, but has certain advantages.
Anyone else read the Filesystem Hierarchy Standard?
(http://www.pathname.com/fhs/)
I'd think that it would be a good read even if you end up disagreeing with
it.
Alexander Ulyanov
> In article <slrncurr5p...@beryl.local>, Alexander Ulyanov wrote:
>> On 2005-01-18, Velvet Elvis <ongamb...@softhome.net> wrote:
>>> On Mon, 10 Jan 2005 09:30:28 +0000, Alexander Ulyanov wrote:
>>>
>>>> === 1.1. How do I compile *band from source?
>>>>
>>>> Unfortunately compiling Angband from source isn't trivial. New Vanilla
>>>> versions and possibly some other variants (including mine, PosBand :) have
>>>> "configure" script, and can be installed in a standard way. Be sure to read
>>>> installation instructions, though. Most likely, you'll need to run
>>>> "./configure" with options:
>>>>
>>>> ./configure --bindir=/usr/games --with-setgid=games \
>>>> --with-libpath=/usr/share/games/angband
>>>
>>> I've always just played from the source directory. It only gets
>>> complicated when you want to install it to a multiuser enviornment.
>
>> Exactly. I used to play from the source directory, too, but it always
>> felt a little dirty way.
>
> Well, isn't it only the setgid part which prevents you from installing it
> _somewhere_ even as non-root?
>
> "./configure --prefix=/home/me/games --without-setgid && make && make
> install ; export PATH=$PATH:/home/me/games/bin ; angband" ?
>
> That was the usual way to install a GNU toolset on something where the
> sysadmin wasn't cooperating.
Sure. It's my home PC, so I can install it as root. But the majority
of variants don't have a configure script, so you have to install
everything by hand.
>> BTW, the up-to-date version is at
>> "http://posband.earthsea.org/unix-faq/".
>> I won't post it there, as it will waste lots of bandwidth and likely
>> annoy many folks.
>
> Proposed additions,
[snip].
Thanks!
> 3.6: Well, they work as they should in Unix already, don't they? I
> regularly use ^Z to suspend angband and do something else in the useful
> big terminal window (I usually use curses bigscreen in an xterm) for a
> while, then switch back to angband.
Sure, but Ctrl-Z is supposed to enter the borg mode, and the help
doesn't say that it behaves differently on Unix.
Alexander Ulyanov
> In article <slrncvjvm3...@beryl.local>, Alexander Ulyanov wrote:
>> On 2005-01-27, Juergen Frieling <jue...@beer.com> wrote:
>>> Am 27 Jan 2005 11:03:37 GMT, schrieb Alexander Ulyanov:
>
>>>>> What about people that usr /usr for distrib stuff and /usr/local for
>>>>> manualy installed stuff?
>>>>
>>>> *All* packages are installed in /usr. /usr/local is for things that the
>>>> users build manually.
>>>
>>> If you follow the traditional UNIX way, /usr is just for the system
>>> distribution. A 3rd party package clearly doesn't belong there.
>>
>> Maybe. But installing packages to /usr is a de-facto standard, anyway.
>
> It's a BSD4.3-ism, that's what it is.
But this is a _de-facto_ _standard_. All RPMs/TGZs I've seen install in
/usr. While I agree that /usr/local is, in theory, more appropriate,
users expect their packages to be installed in /usr.
>>> Many Linuxers think all stuff that is installed with the package system
>>> should go to /usr - many other (me included) still think 3rd party
>>> packages should go to /usr/local...
>>>
>>> And btw: I just installed the ToME port on FreeBSD - guess where the
>>> stuff went :-) AFAIR FreeBSD even installs many packages from the
>>> install-CD to /usr/local (because they aren't bsd-licensed and so not
>>> really a part of the BSD-distribution, I think)
>
>> That's BSD, not Linux :).
>
> But BSD has gotten a bit more sane since 4.3. The different BSDs in
> occasionally slightly different ways, too.
>
> The non-BSD end of the line is with a whole bunch of technically non-core
> but practically always required software in /opt/ subtrees. That has
> often been overdone too, but has certain advantages.
Well, I like having all KDE-related stuff in /opt/kde (I use some KDE
software occasionally), but installing every package in its own
subdirectory in /opt is a Bad Thing (tm).
> Anyone else read the Filesystem Hierarchy Standard?
> (http://www.pathname.com/fhs/)
You mean *someone* reads standards? :)
> I'd think that it would be a good read even if you end up disagreeing with
> it.
Well, having a standard is always good, and FHS is rather well-thought,
though I just can't agree with some of its requirements (the separation of
/media and /mnt is particularly stupid one). /usr/local is a good idea,
and I agree with FHS on this issue. The problem is, it's much harder to
change the common practice (to install packages in /usr) than to change
the standard :).
Mikko Nahkola
> On 2005-01-28, Mikko Nahkola <mnah...@trein.ntc.nokia.com> wrote:
>> In article <slrncurr5p...@beryl.local>, Alexander Ulyanov wrote:
>>> On 2005-01-18, Velvet Elvis <ongamb...@softhome.net> wrote:
>>>> I've always just played from the source directory. It only gets
>>>> complicated when you want to install it to a multiuser enviornment.
>>
>>> Exactly. I used to play from the source directory, too, but it always
>>> felt a little dirty way.
>>
>> Well, isn't it only the setgid part which prevents you from installing it
>> _somewhere_ even as non-root?
>>
>> "./configure --prefix=/home/me/games --without-setgid && make && make
>> install ; export PATH=$PATH:/home/me/games/bin ; angband" ?
>>
>> That was the usual way to install a GNU toolset on something where the
>> sysadmin wasn't cooperating.
>
> Sure. It's my home PC, so I can install it as root. But the majority
> of variants don't have a configure script, so you have to install
> everything by hand.
Well, er, yes; I was merely pointing out that the install target
location as such _can_ be a user-owned directory outside the source tree.
It just requires tweaking the paths in the makefile in that case - and
at least I always go through those with vi or some such, myself ...
IIRC I've never built *band with an unmodified makefile, configure or no
configure.
>>> BTW, the up-to-date version is at
>>> "http://posband.earthsea.org/unix-faq/".
>>> I won't post it there, as it will waste lots of bandwidth and likely
>>> annoy many folks.
>>
>> Proposed additions,
>
> [snip].
>
> Thanks!
>
>> 3.6: Well, they work as they should in Unix already, don't they? I
>> regularly use ^Z to suspend angband and do something else in the useful
>> big terminal window (I usually use curses bigscreen in an xterm) for a
>> while, then switch back to angband.
> Sure, but Ctrl-Z is supposed to enter the borg mode, and the help
> doesn't say that it behaves differently on Unix.
That's a problem with the help then, I suppose.