LAngband FAQ

1. What is Langband?
   Langband is a rewrite of the traditional/vanilla version of Angband. It is based on version 2.9.0, but will be upgraded to 2.9.x at a later stage. Langband is written in Common Lisp, which will allow me to combine the dynamic nature of easy scripting with good compiler technology providing an environment that allows a very high level of customisation and the necessary speed. It is a toy project which I work on when I find time, and the development-pace reflects this. However, even if it is a toy-project, I try to write quality-code and have a good design. This also ensures that it will take more time than the usual Angband-variant.
2. Where can I download it?
   It isn't finished yet and won't be finished for some time as it will need go to through several stages, as all newly written programs must. I hope to have a minimal playable version ready in the 1st quarter of 2002. You can check it out from CVS or download pre-alpha versions on Sourceforge though. There are also some experimental debian-packages if you use debian, and if you have Debian these are the simplest to get started with.
3. Does it run on [insert OS]?
   The main development-platform is my x86 Debian-system, using CMU Common Lisp. The status of various ports is as follows (things are still in development so the overall "product" is fairly incomplete):

   Implementation	Architecture	Status
   CMUCL 3.x	Debian x86	Well-tested
   ACL 6.0 (Prof)	Debian x86	Tested bi-weekly
   CLISP 2.26	Debian x86	Tested monthly. not optimised
   LispWorks 4.1.20	Debian x86	Recent/immature port. not optimised
   LispWorks 4.1.20	Win98	Recent/immature port. not optimised
   Corman Lisp 1.5b	Win98	Incomplete port. not finished

   The status for the various UI-interfaces are as follows:
   • X11 is the most mature and the one used for development.
   • GCU is tested basically only for releases.
   • Gtk+ is non-prioritised at the moment, but is usually tested at releases.
   • Win is a very immature port with many errors.
4. I found a bug, what do I do?
   Please check if the bug has been reported first in the Sourceforge bug-tracking. If it is not reported, please try to describe what caused the crash, include any messages printed before the crash, and if you were dumped into the lisp-debugger please include a backtrace. This is accomplished in CMUCL with the command 'backtrace' and in ACL with the command ':zo'. These commands work in the debugger.
5. How can I see if a bug is fixed?
   A reported bug will be marked as FIXED when it is fixed and the updated code has been put in the CVS-tree. The priority of a FIXED bug is set to the minimum. It will be marked as CLOSED when a new release have been made where the bug is fixed. If you reported the bug, you will be mailed whenever there is an update on the bug.
   BTW: If you have extra information on a non-fixed bug, please add it.
6. The game hangs once in awhile, why?
   I have noticed this earlier though not frequently anymore. It might be the garbage-collector interfering. This will be adressed gradually and memory-allocation will be reduced when it is a problem. But during early development this isn't crucial.
   Note: This is still visible in the slower CLISP and in the win32-port if the lispworks-code isn't compiled. Gradual optimisation of the code will probably "remove" this "problem".
7. How do I get things working with CLISP?
   It's a bit tricky still but can be done. Assuming csh/tcsh you can do:

   	  $ make
   	  $ clisp -q -ansi
   	  > (load "game")  ;; this stops at foreign loading, use ^D to quit
   	  $ setenv LD_LIBRARY_PATH `pwd`/linking
   	  $ make clisp-link
   	  $ linked/lisp.run -B /usr/lib/clisp -M linked/lispinit.mem -q -ansi
   	  > (load "game") ;; this should work now
   	

   This will be improved later, but it's an important step ahead. You might need to edit the paths in Makefile and linking/Makefile. For other shells use the equivalent command of setenv which sets and environment value.
8. How do I get things working with LispWorks Windows?
   Currently it's not 100% streamlined, but if you have it installed in c:/cygwin/home/default/langband/ you might edit zterm/Makefile and set ENVIRONMENTS to WIN and compile zterm with 'make', and then do:

   	  > (setq *default-pathname-defaults* #p"c:/cygwin/home/default/langband/")
   	  > (load "game")
   	  > (lb::a)
   	

9. How is the code structured?
   Currently the code is changed frequently and this answer may not be up-to-date. Please look at the Technical description for an hopefully updated description.
10. The code in CVS crashes/does not work, why?
    The code in CVS is development code, and might not even compile, and much less work. Please use releases if you want things to "work". The CVS-version is bleeding edge though and may have bug-fixes and features missing in releases. CVS is also where exciting things happen and where you can track day-to-day development.
11. Regular Angband has several windows, where are the other windows in Langband?
    Several windows can be quite useful but they introduce some extra complexity which isn't essential this early in development. So until the game reaches a stage where more windows is needed it will remain a single-window game.
12. When I quit the game, my whole lisp is terminated, why?
    Some parts of the UI-code is still structured as if it was still an app with main() that is started and then quitted when one is done playing. This is extremely annoying if you use a slow loader like CMUCL or a big graphical IDE like LispWorks. I hope to eventually make things more intelligent, but this will take time. [Note: This should be fixed in current CVS for X11 and curses, tested with CMUCL, Lispworks and ACL.]
13. How do I get sounds working?
    
    1. uncomment the using-sound line in game.lisp
    2. set SOUND_USE in zterm/Makefile to YES
    3. recompile all C-code and lisp-code
    4. get example sounds from the langband project page dowload area
    5. install wanted sounds in lib/sound and configure in lib/file/sound.lisp
    6. start zterm/sound_daemon in the background
    7. start the game
    8. play the game and if possible, hit something
    9. quit game and exit the sound_daemon
14. CMUCL freezes in lib/compat/obj-kind.lisp, or? [obsolete]
    It just takes a really really long time to compile in CMUCL, several minutes. This file is for compatibility with traditional angband and isn't really needed when the necessary files have been converted to lisp. Please be patient.
15. I am a lisper, but I find parts of the code a bit odd, why is it the way it is?
    

    The code is in development and changes relatively often and the interface for the engine that should be extensible and alterable by variants and user-code needs to gradually be worked out. This must be done gradually as I need to experiment with what is interesting to extend/alter, and what can be extended/altered and still get reasonable performance and decent-looking code.

    Some of the interface will be functions which variants may call, and sometimes with function-arguments as plug-ins. Other parts will be generic functions which are designed to be tailoured by a variant. Other parts are extensible classes which variants are allowed to extend. As this interface gets clearer it will be exported from the :org.langband.engine package and variants will reside in their own packages. But we're not there yet, so vanilla currently lives in the same package.