DEVEL/code_features.txt

   1 # NetHack 3.6  code_features.txt $NHDT-Date: 1524689669 2018/04/25 20:54:29 $  $NHDT-Branch: NetHack-3.6.0 $:$NHDT-Revision: 1.3 $
   2 # Copyright (c) 2015 by Michael Allison
   3 # NetHack may be freely redistributed.  See license for details.
   4
   5 Developer-useful info about code features, assumptions, purpose,
   6 rationale, etc.
   7
   8 ==============================================
   9 FEATURE_NOTICE Alerts for a Release
  10
  11 There is a code mechanism for alerting players to a change in behavior
  12 over prior versions of the game.
  13
  14 Here's how to do it:
  15    o Where the change in behavior needs to alert the player,
  16      - Add an 'if statement' to invoke the alert behavior
  17        if the condition is met, for example
  18           if (flags.suppress_alert < FEATURE_NOTICE_VER(3.6.0))
  19              pline("Note: and explain the change here.");
  20      - The example above will alert the users for a new feature
  21        added in 3.6.0 via a one-liner via pline(), but you
  22        could get more elaborate (just make sure it is all done
  23        in the 'if' code block.
  24
  25 Once the user finds the alert no longer useful, or becoming
  26 annoying, they can set the "suppress_alert" option.
  27       - The user can only set the suppress_alert to the current
  28         version, not future versions. That restriction is done
  29         so that the feature can be used for new things in new
  30         releases.
  31       - The suppression can be done interactively mid game with
  32         the 'O' command, or via
  33            OPTIONS=suppress_alert:3.6.0
  34         in the user's config file.
  35
  36 ==============================================
  37 PREFIXES_IN_USE and NOCWD_ASSUMPTIONS
  38
  39 Those provide a storage mechanism for holding the paths to various different
  40 types of files. Those paths are stored in the fqn_prefix[] array. They are a
  41 mechanism for enabling separation of the different files that NetHack needs.
  42
  43 The prefixes are added to the beginning of file names  by various routines in
  44 files.c immediately prior to opening one of the types of files that the game
  45 uses.
  46
  47 They aren't about config file options (although config file options would be
  48 one way to set non-default values for some of the paths in the fqn_prefix[]
  49 array). Obviously the very first path needed (now sysconfdir, previously
  50 configdir) isn't viable for setting via config file options, but the game
  51 still needs to hunt it down "someplace."  When the "someplace" is figured
  52 out, that place (path) would be stored in fqn_prefix[SYSCONPREFIX].  How it
  53 gets stored in fqn_prefix[SYSCONPREFIX] is up to us as developers.
  54
  55 Any of the fqn_prefix[] entries can be set somehow. It could be done in port
  56 startup code; in options processing; in config file processing; by
  57 translating a system environment variable such as USERPROFILE; whatever
  58 you/we want.  The point is that NOCWD_ASSUMPTIONS and PREFIXES_IN_USE are
  59 there to ensure that there is a place to store that path information.  The
  60 code to *utilize* the information is already in files.c (see fqname()).
  61
  62 There is a fqn_prefix[] entry for holding the path to each of the following:
  63     PREFIX        NAME
  64 0 HACKPREFIX     hackdir
  65 1 LEVELPREFIX    leveldir    location to create level files
  66 2 SAVEPREFIX     savedir location to create/read saved games
  67 3 BONESPREFIX    bonesir location to create/read bones
  68 4 DATAPREFIX     datadir location to read data.base etc.
  69 5 SCOREPREFIX    scoredir    location to read/write scorefile
  70 6 LOCKPREFIX     lockdir     location to create/read lock files
  71 7 SYSCONFPREFIX  sysconfdir  location to read SYSCF_FILE
  72 8 CONFIGPREFIX   configdir   location to read user configuration file
  73 9 TROUBLEPREFIX  troubledir  location to place panic files etc.
  74
  75 To recap, they are about enabling "different paths for different things", and
  76 separation of:
  77 - read-only stuff from read-write stuff.
  78 - sysadmin stuff from user-writable stuff.
  79 etc.
  80
  81 ==============================================
  82 REGULAR EXPRESSIONS
  83
  84 There are multiple regular expression libraries supported. Currently, one (and
  85 only one) of the following files should be linked into a built:
  86   sys/share/cppregex.cpp
  87   sys/share/posixregex.c
  88   sys/share/pmatchregex.c
  89
  90 This provides a way to access different system regular expression libraries,
  91 or fall back onto pmatch() if none is available. cppregex.cpp uses the regular
  92 expression library in the C++11 standard, and is the default on Windows.
  93 posixregex.c uses the POSIX regular expression library, and is the default on
  94 POSIX. pmatchregex.c is the fallback.
  95
  96 Configuration files written using either of the two true regex engines are
  97 compatible with one another, as the regular expressions are both POSIX
  98 extended regular expressions. Configuration files written using the fallback
  99 engine are incompatible.
 100
 101 Additional regular expression implementations can be written. The full
 102 interface documentation is in sys/share/posixregex.c
 103
 104 =================== NEXT FEATURE ==========================
 105
 106
 107