# Subversion Repositorieseduke32

Rev
Lunatic User Manual
===================
Helixhorned <contact: Duke4.net forums>
:max-width: 56em
:numbered:
:icons:
:toc:
:toclevels: 3

:language: lua

[red]*DRAFT DRAFT DRAFT*

Lunatic is in preview stage. Modifications or TCs may be started, but must not
be released. The interfaces (including constants, functions, methods *and
structure members*) described in this document may be assumed to not change
significantly until release, but *undocumented API may change without further
notice*.

[red]*DRAFT DRAFT DRAFT*

Introduction
------------

Language
--------
:Lua51: http://www.lua.org/about.html
:Lua51Ref: http://www.lua.org/manual/5.1/
:PiL: http://www.lua.org/docs.html

:LuaJIT: http://luajit.org
:LuaJIText: http://luajit.org/extensions.html

The base language for writing Lunatic user code is {Lua51}[Lua 5.1].  It is
extensively documented in a {Lua51Ref}[Reference Manual], as well as described
more broadly and accessibly in the {PiL}[Programming in Lua] books.
// TODO: describe Lua a bit

Because Lunatic is implemented using {LuaJIT}[LuaJIT], a just-in-time compiler
for the Lua language, some {LuaJIText}[extensions] to the core language are
automatically available. They may be used if no compatibility with Rio Lua 5.1
is desired.footnote:[Not all extensions from LuaJIT are available, since some
like the FFI are targeted at C programmers rather than scripting coders.]

NOTE: The length operator (#) for table arguments should be taken to be
defined by the http://www.lua.org/manual/5.2/manual.html#3.4.6[stricter wording
of Lua 5.2].


Environment and Usage
---------------------

Lunatic aims to provide a _safe_ scripting environment for EDuke32. Thus, not
all of Lua's functionality is available in Lunatic, and some is slightly
altered to play well with being embedded into a game, or to prevent commonly
occurring mistakes.

.Differences from default Lua environment
- Creating new variables in the global environment is forbidden.
- Referencing a non-existent variable (i.e. one that has value *nil*) is an
  error.

EDuke32 can load multiple Lunatic _modules_ when starting up. This is always
done after translating CON code to Lua and loading it. Such modules must reside
in files named *.lua (case-sensitive) and should be passed directly, without
any option letters, at the command line. Directory separators must be forward
slashes.

The command-line option -Lopts=strict enables errors on certain conditions
that may indicate problems in user Lua or CON code. Currently, strict mode
checks for

* Accesses to <<sprite,sprites>> not in the game world
* Indexing the tables returned by <<require,require("DEFS")>> and the like
  with nonexistent keys. This may indicate a missing file from a bundle
  belonging together.

.Invocation example
====================
eduke32 -nologo MYTC.CON -mx addition.con test.lua weapons/nuke.lua -v1 -l1
====================

If the OS environment variable LUNATIC_TIMING_BASEFN is defined, EDuke32 will
write out aggregate timing results for actors and events in a comma-separated
value format, obtained by suffixing the base name with .actors.csv'' and
.events.csv''.


Global Environment
------------------

When a Lua module is loaded, its global environment contains both selected
functions from core Lua, as well as Lunatic's own pre-defined variables.
These allow access and manipulation of EDuke32 engine and game data.

[icon="din_w_explosive.png"]
CAUTION: If an attempt is made to create a new variable in the global
environment or to assign any value to an existing variable, the behavior is
undefined.

For convenience of debugging from the command line (using the lua OSD
command), the global environment contains a table d which is initially
empty. It should only be used to temporarily store values of interest in a
debugging session and should never be referenced from actual script code.

Lua functions
~~~~~~~~~~~~~

The following base Lua functions are available in Lunatic's global environment:

assert, *error*, ipairs, pairs, pcall, *print*, *module*, next,
*require*, select, tostring, tonumber, type, unpack, xpcall.

The bold ones add functionality or behave slightly differently, described below.
Additionally, printf is provided for convenience.

[[error]] *error(message [, level])*::
In Lunatic, errors also print to the on-screen display (OSD) and are written to
the log (unless a maximum error count is exceeded). These also have a
_backtrace_ added. Additionally, errors not caught by a pcall result a
permanent message to appear on the screen, containing the source file name and
line number.

*print(str)*::
Prints a single message to the OSD and the log. Color codes available in
EDuke32 (e.g. ^10 for dark red) are interpreted. Overriding tostring has no
effect on Lunatic's print as it uses the initial, built-in tostring
function instead of looking it up in the global environment.

*printf(fmt, ...)*::
Calls print with the result of string.format(fmt, ...).

[[modules]]
Writing and using modules
~~~~~~~~~~~~~~~~~~~~~~~~~

In Lunatic, like in Lua, a _module_ is a conceptually a sort of package that
unites related bits of functionality. Language-wise, it is simply a Lua
table holding its contents, as described and motivated at length in
_Programming in Lua_ (second edition).

The creation'' and usage'' sides of the modularity concept are reflected in
two functions known from Lua 5.1, module and require. The former is a
convenient way of separating the _import_, potential _gamevar_, and main body
sections when writing a package. It is not required to use module, but it is
the only way to declare _game variables_, that is, variables that EDuke32
stores within savegames, recreating their values when they are loaded.

The other side of the coin, require, is also used like in Lua: including''
a named module is requested by passing its name to require. This searches for
a matching module, loading and running it if the request happens for the first
time.

[[require]]
==== The function require(modname, ...)

Attempts to find a Lua or Lunatic module named modname. The name can refer to
a _built-in_ module, of which the following ones are allowed:

* The http://bitop.luajit.org/[bit] module for bitwise operations
* math, string and table, base modules from Lua
* Lua's os module, containing a single function, clock. Like the
  <<timing_funcs,timing functions>>, it should only be used to profile bits of
  code.
* Modules provided by Lunatic, which are described in <<ext_api,their own
  section>>.

If modname does not designate a built-in module, Lunatic first replaces every
dot contained in it with a directory separator. Then, it looks for a file with
that base name suffixed with .lua in the EDuke32 search path (virtual file
system, GRP, ZIP). Using directory separators directly is not allowed.

The loaded module is protected so that write accesses to its table yield
errors. Unlike in Lua, our require does not return *true* when a module is
requested that has not yet finished loading (that is, the inclusion chain
contains a loop). Instead, an error is raised.

Lunatic's require allows passing additional arguments to the module to load.
On the module side, they can be obtained by examining the vararg expression
++\...++'' at file scope. Given a definition of args as {...}, its first
element args[1] would contain modname and the following entries the values
passed in addition to require. This feature is useful for parametrizing a
module: for example, the module could provide a way alter the starting tile
number of an actor it defines.

Issuing require for some special names listed below has a predefined meaning
that cannot be overridden by the user.

* CON.DEFS: returns a table mapping labels ++define++d from CON to their
values. Values pre-defined by the system are not included.

* CON.ACTION: returns a table mapping labels of ++action++s defined from CON
  to immutable <<con_action,con.action>> objects.

* CON.MOVE: returns a table mapping labels of ++move++s defined from CON
  to immutable <<con_move,con.move>> objects.

* CON.AI: returns a table mapping labels of ++ai++s defined from CON
  to immutable <<con_ai,con.ai>> objects.

* end_gamevars: used to mark the end of a gamevar block, described below.


==== The module() function

Initiates a _module_ environment by creating a new empty table and setting it
as the global environment of the chunk. Subsequently creating global variables
will place them into this hidden'' table. Assuming no subsequent *return*
is placed at file scope, this table will be the one obtained by a require for
the module at the client side.

[source]
.Example file using using module
----------
-- Import section: cache everything the module needs into locals
local print = print
local gameactor = gameactor
local MYDEFS = require("MyEnemyDefs", 1200)  -- see next example

-- After this, the global environment will be swept clean!
module(...)

-- Our enemy at last
gameactor{ MYDEFS.tilenum, strength=MYDEFS.strength,
    function(aci)
        print("My tilenum is "..sprite[aci].picnum.." and I "
              ..(MYDEFS.canfly and "can" or "can't").." fly")
    end
}
----------

Unlike Lua 5.1, our module takes neither a name argument nor option''
varargs. A Lunatic file may have at most one call to module, which (if there
is one) *must* be called at file scope.

If the Lua file doesn't need to register any game variables, it is also
possible to return its table directly instead of using module. However, due
to the way modules are loaded, a trailing *return* statement must be wrapped
in a *do*...*end* block, like this:

.Example module MyEnemyDefs.lua explicitly returning a table
[source]
----------
local args = { ... }
do return {
   tilenum = args[1] or 1000,
   strength = 100,
   canfly = true,
}
end
----------

===== Game variables

Lunatic has a special mechanism to mark variables that represent persistent
state and whose values should be stored in savegames. If such variables are
desired, they must be initialized between the module call in a Lua file and a
closing require("end_gamevars").footnote:[The reason that the initialization
has to happen between the module and the require('end_gamevars') is that on
savegame loading, gamevars are restored from the latter.] These variables may
also be *local*.

Game variables may take on only values of types that Lunatic knows how to
serialize into savegames. These are the following:

* Booleans, numbers, and strings, collectively called the _basic types_
* Custom Lunatic types that are labeled _serializable_ in their documentation
* Tables, but with the following restrictions on their contents:
** A table key may only be of basic type.
** A table value may be (a reference to) any serializable object, but tables
    or Lunatic objects that are so referenced *must* have originated in the
    gamevar section of the same module. Beyond that, there are no restrictions
    on the table topology.

[icon="din_w_collapse.png"]
CAUTION: If a gamevar contains a value that is not serializable at any point
in the execution, the behavior is undefined. Note that in particular, gamevars
are not allowed to take on the value *nil*.

// TODO: example?

// TODO: the rest

[[gv]]
The gv variable
~~~~~~~~~~~~~~~~~~~

Some constants, global C variables, and miscellaneous functions and structures
are accessible via the global gv variable.

Constants
^^^^^^^^^
gv.MAXSECTORS, gv.MAXWALLS, gv.MAXSPRITES::
The hard engine limits on the number of sectors, walls, and sprites. These
constants *must* be used instead of any literal numeric values because they
can change depending on how EDuke32 was configured and built.

gv.CEILING, gv.FLOOR, gv.BOTH_CF::
Constants permissible to the <<sectorsofbunch_1,sectorsofbunch>> iterator.

//////////
gv.MAXSTATUS, gv.MAXTILES, gv.MAXSPRITESONSCREEN::
TODO

gv.MAXBUNCHES::
TODO
//////////

gv.CLIPMASK0::
A clipping (collision detection) mask specifying to consider only _blocking_
walls and sprites.

gv.CLIPMASK1::
A clipping (collision detection) mask specifying to consider only _hitscan
sensitive_ walls and sprites. The set bits of CLIPMASK1 and CLIPMASK0 are
disjoint.

[[gv_REND]] gv.REND::
A mapping of names to values representing rendering modes: CLASSIC,
POLYMOST, POLYMER.

// Game-side
[[gv_GTICSPERSEC]] gv.GTICSPERSEC::
The number of times in a second each actor executes its code and updates its
position (game tics'').

[[gv_GET]] gv.GET::
A mapping of names to inventory indices: STEROIDS, SHIELD, SCUBA,
HOLODUKE, JETPACK, DUMMY1, ACCESS, HEATS, DUMMY2, FIRSTAID,
BOOTS.

gv.GET_MAX::
The maximum permissible inventory index plus one.

[[gv_WEAPON]] gv.WEAPON::
A mapping of names to weapon indices: KNEE, PISTOL, SHOTGUN, CHAINGUN,
RPG, HANDBOMB, SHRINKER, DEVISTATOR, TRIPBOMB, FREEZE,
HANDREMOTE, GROW. Note that DEVISTATOR'' is misspelled.

gv.MAX_WEAPONS::
The maximum permissible weapon index plus one.

//////////
gv.MAXPLAYERS::
TODO
//////////

gv.LUNATIC_CLIENT::

A constant indicating which program Lua is embedded into. It can be compared
for (in)equality with:
+
* gv.LUNATIC_CLIENT_EDUKE32
* gv.LUNATIC_CLIENT_MAPSTER32
+
(Mapster32 supports a subset of Lunatic that is not documented and subject to
change at any time.)

Variables
^^^^^^^^^

gv.numsectors (read-only)::
The total number of sectors in the currently loaded map.

gv.numwalls (read-only)::
The total number of walls in the currently loaded map.

[[totalclock]] gv.totalclock (read-only)::
The current value of the engine timer that increments at a rate of 120 per
second under default settings. (Thus, one game tic corresponds to four
totalclock increments.) When staying within one mode'' such as in-menu or
in-game, it is guaranteed to not decrease. However, going from one mode to
another may produce discontinuities.

gv.gametic (read-only)::
The number of <<gv_GTICSPERSEC,game tics>> that have elapsed since starting the
current level. This value is guaranteed to not decrease during a game, and is
restored from savegames.

gv.screenpeek (read-only)::
The player index of the player from whose position the scene is being displayed.

gv.rendmode (read-only)::
The current rendering mode as a value that can be compared against those in
<<gv_REND,gv.REND>>.

gv.hudweap::
A structure containing information about the currently displayed HUD weapon.
Contains the following members, which are set from C before entering
EVENT_DISPLAYWEAPONS: cur, count, gunposx, gunposy, lookhalfang,
lookhoriz, shade.
// TODO: describe

gv.cam::
A structure that, prior to entering EVENT_DISPLAYROOMS, is populated with the
position and orientation of the camera'' from which the scene would be drawn.
Contains the following members: pos, dist, clock, ang, horiz, sect.
// TODO: describe

// TODO: g_logoFlags?

[[gv_RETURN]] gv.RETURN::
A special variable that is used by the game to pass specific values to game
events, or to examine values passed back from events and act upon them
accordingly. Refer to <<Appendix_event_RETURN,Appendix B>> for a list of how the various
events interpret this variable.

Functions
^^^^^^^^^

gv.getangle(x, y)::
Returns an approximation of the angle between the line segments (0,0)->(1,0)
and (0,0)->(x,y) in BUILD angle units in the range [0 .. 2047].

[[krand]] gv.krand()::
Returns one value from the global engine-side pseudo-random number generator
in the integer range [0{nbsp}..{nbsp}65535].

[[timing_funcs]] gv.getticks(), gv.gethiticks()::
Each of these functions return a number that increases at a rate of 1 per
millisecond. Their only intended application is to profile bits of code; they
should not be used to control the game world. The two functions differ in their
precision: getticks() always returns integral values, while the result of
gethiticks() also has an unspecified precision in the fractional part. (It
can be expected to give a time precision of at least one microsecond.)

gv.doQuake(gametics [, snd])::
Requests from the game to perform the quake'' effect that shakes the screen
etc. for the next gametics game tics. If a sound index snd is passed, also
start playing that sound.
// TODO: Play sound how? ("globalsound")

gv.currentEpisode()::
Returns the one-based number of the episode currently being played.

gv.currentLevel()::
Returns the one-based number of the level currently being played.

[[Lunatic_structures]]
Lunatic structures
~~~~~~~~~~~~~~~~~~

The primary means of effecting game state in Lunatic is via _composite
variables_ defined in the global environment. These provide direct, but
restricted, access to C _structure arrays_ of the EDuke32 engine or game.

[icon="din_w_toxic.png"]
CAUTION: If an attempt is made to access any composite variable outside of
event or actor code, the behavior is undefined.

Composite variables can be used in various ways. All of them allow indexing
with an integer value from 0 to some maximum (sometimes the size of the array
minus one, but occasionally less). For example, the code snippet
[source]
----------
local sec = sector[0]
----------
gets a _reference_ to the first sector of the loaded map into the local sec.
This reference can then be used to both read and write its members.

Various structures also provide _methods_ in Lunatic to modify their state,
usable with Lua's v:func(args...) syntax. Building on the previous example,
[source]
----------
local cz = sec:ceilingzat(wall[sec.wallptr])
----------
would get into cz the ceiling z position at the first sector's first
wall-point.

Finally, some composite variables offer _static data_, which can contain
functions or tables of constants. These are accessed using the dot notation on
the composite variable, *not* its constituents. For instance, the following can
be used to change the sector number of the sprite with index i manually:
[source]
----------
sprite.changesect(i, sectnum)
----------


Type of structure members
^^^^^^^^^^^^^^^^^^^^^^^^^

In the following, some structure members will be annotated with their _integer
type_, for example _i16_ or _u8_. The letter _i_ denotes a _signed_
integer whereas a _u_ designates an _unsigned_ one. The number following that
letter indicates the _bit width_ of that integer.

.Representable values
* A member of signed integer type and bit width _B_ can contain any whole
number from --2^_B_--1^ to 2^_B_--1^--1. +

* A member of unsigned integer type and bit width _B_ can contain any whole
number from 0 to 2^_B_^--1.

[[int_assignment]]
.Assignment
1. If an assignment to a member having signed integer type is made, the
   right-hand side'' value must be a number in the closed interval
   [--2^31^ .. 2^31^--1].

2. If an assignment to a member having unsigned integer type and bit width _B_
   is made, the right-hand side'' value must be in the closed interval
   [--2^31^ .. 2^31^--1] if _B_ is less than 32, or in [0 .. 2^32^--1] otherwise.

3. If the appropriate requirements hold, an assignment from a Lua number to a
   member having integer type begins by discarding the fractional part
   (truncation'').  Otherwise, the behavior is undefined. +

4. If the truncated value is outside the range of representable values for the
   corresponding integer type of bit width _B_, the final value is obtained by
   successively adding or subtracting 2^B^, until the value falls inside that
   range.

//////////
NOTE to self: this is stricter than C99 (which has first truncation, then range
check). Also, it may be tempting to assign 0x80000000 to an int32_t to mean
INT32_MIN, but this is wrong because it's out of range.
Also see:
http://lua-users.org/lists/lua-l/2011-09/msg00534.html
//////////

.Examples
1. Assignments to _u8_ member visibility
* sec.visibility=3.94159 results the member to contain the integer 3
* sec.visibility=1/0 is undefined (attempt to assign an infinity)
* sec.visibility=-1 results the member to contain the integer 255

2. Assignments to _i16_ member lotag
* sec.lotag=32768 results the member to contain -32768
* sec.lotag=2^32 is undefined

[[bit_fields]]
Bit fields
^^^^^^^^^^

Some structures contain members that represent a collection of _flags_, for
example sprite[].cstat or actor[].flags. These flags can be toggled by
setting or clearing their respective _bits_ (integer numbers that are powers of
two).

For convenience, Lunatic provides alternative names for some of these members,
together with methods to examine or modify any number of bits of such a member
in one expression.  Whenever there is such an alternative name available, it is
declared as having type _bitfield_ in the listings of the structure members.

===== methods of the _bitfield_ type

bf:set(bits)::
_Sets_ (toggles to an on'' state in a boolean sense) those bits of bf
that are set in bits.

bf:clear(bits)::
_Clears_ (toggles to an off'' state in a boolean sense) those bits of bf
that are set in bits.

bf:flip(bits)::
_Flips_ those bits of bf that are set in bits, that is, reverses their
boolean state.

bf:test(bits)::
Returns a boolean that indicates whether bf has *any* of the bits set in
bits set.

bf:mask(bits)::
Returns a number containing the bits of bf bitwise ANDed with those in
bits.

.Examples
==========
After the lines setting sprite i to 33% translucent and blocking,
[source]
----------
local CS = sprite.CSTAT
local spr = sprite[i]
spr.cstat = CS.TRANS1 + CS.BLOCK
----------
one could proceed as follows for the sake of example:

[source]
----------
spr.cstatbits:set(CS.TRANS2)  -- make the sprite 66% translucent now
spr.cstatbits:flip(CS.BLOCK + CS.HITSCAN)  -- make it hitscan-sensitive and non-blocking
local isflipped = spr.cstatbits:test(CS.FLIP_BITMASK)  -- is it x- or y-flipped? (no)
----------
==========

Engine-side composites
^^^^^^^^^^^^^^^^^^^^^^

The composite variables described in this subsection provide access to
engine-side structures. The first three, sector, wall, and sprite,
are part of a BUILD map saved to disk. The other ones only exist when
running the game.

===== sector
Accessible from 0 to gv.numsectors-1. Each element has the following
members:

wallptr, wallnum (read-only)::
The index of the sector's first wall and the number of walls in the sector,
respectively.

_u8_ visibility::
Determines the amount of distance fading. The sector visibility member is
biased: linear visibility is determined from it by adding 16 and taking the
result mod 16. This linear visibility's interpretation is that larger values
correspond to a steeper darkening'' (or fogging) attenuation with
distance. Linear visibility 0 -- corresponding to sector[].visibility of 240
-- means no attenuation with distance.

_u8_ fogpal::
In the OpenGL modes that don't use per-pixel shade table lookups, setting
fogpal to a non-zero value overrides the fog color of the sector to that of
the corresponding pal number. These are either expected to have been defined
using DEF tokens fogpal or makepalookup, or created by EDuke32 at startup.

_i16_ lotag, hitag, extra::
General-purpose tags'' provided for game programming. They may be used by
various EDuke32 sector effects, so it is not recommended to use them in
scripting code.

In addition to the members described above, each sector has two sets of members
for its ceiling and floor. A sector reference can be indexed with the strings
ceiling or floor to get references to the respective parts'', or one can
access the consituent members by prefixing ceiling or floor to the base
member names given below.

.Different ways of accessing the same member
==========
After the code lines
[source]
----------
local sec = sector[0]
local ceil = sec.ceiling
----------
the following expressions all denote the same location, both if read or written
to: sec.ceilingheinum, ceil.heinum, sector[0].ceiling.heinum,
sector[0].ceilingheinum.
==========

In the following, cf will stand for a ceiling or floor reference, while sec
will label a sector reference.

cf.picnum (read-only)::
The tile number of the ceiling or floor.

[[cf_stat]] _u16_ cf.stat, {nbsp} _bitfield_ cf.statbits::
A bit field holding various flags about how the ceiling or floor should be
displayed, how collision detection should be handled, etc.
The <<sector_STAT,sector.STAT>>
object should be used to obtain the values for applicable flags.

_i16_ cf.heinum::
If cf.stat has bit sector.STAT.SLOPE set, the tangent of the slope angle,
multiplied by 4096.  Positive values make the ceiling or floor slope towards
the floor, negative ones slope upward.

[[cf_z]] _i32_ cf.z::
The BUILD z coordinate (scaled by 16 compared to the x and y directions) of the
pivoting line of the ceiling or floor.

cf.bunch (read-only)::
The bunch'' number of the ceiling or floor used for True Room over Room. One
bunch comprises _N_ ceilings and _M_ floors (_N_ &ge; 1, _M_ &ge; 1) such that
each set covers the same planar, connected area.

_i8_ cf.shade::
The shade of the ceiling or floor. Larger values mean a more darker appearance.

_u8_ cf.pal::
The palette swap'' index of the ceiling or floor.

_u8_ cf.xpanning, cf.ypanning::
The panning values of the ceiling or floor. One full cycle is covered by values
from 0 to 255.

===== ceiling-or-floor methods

cf:set_picnum(tilenum)::
Set the tile number of the ceiling-or-floor cf.

===== sector methods

sec:set_ceilingpicnum(tilenum), {nbsp} sec:set_floorpicnum(tilenum)::
Set the tile number of the ceiling or the floor.

[[sec_cfz_at]] sec:ceilingzat(pos), {nbsp} sec:floorzat(pos)::
Return the z coordinate of sector sec's ceiling or floor at position pos,
which can be anything indexable with the strings x and y.

sec:zrangeat(pos, walldist, clipmask) -> hit::

Given a starting point pos assumed to be contained in the sector, calculate
the z coordinates of the objects that would be first hit by a quadratic,
floor-aligned sprite pointing parallel to the grid and having side length
2*walldist, when travelling in a straight line up- and downwards.
+
The argument clipmask is a number specifying which objects should be checked
for collision: its least significant 16 bits are bitwise-ANDed with
wall[].cstat values, while the high 16 bits are ANDed with
sprite[].cstat. Whenever the so masked values are non-zero, the objects are
considered for collision.
+
The method returns an immutable structure hit, containing the sub-structures
c and f (for movement upwards and downwards, respectively) with the
following members:
+
* spritep: a boolean signifying whether a sprite was hit
* num: if spritep is true, the index of the hit sprite, otherwise the index
  of the hit ceiling/floor's sector
* z: the z coordinate of where the sprite would end up on collision

===== sector static data

[[sector_STAT]] sector.STAT::
Provides a mapping of symbolic names to values applicable to
<<cf_stat,cf.stat>>.  These name single bits:
PARALLAX, SLOPE, SWAPXY, SMOOSH, FLIPX, FLIPY, RELATIVE, MASK,
TRANS1, TRANS2, BLOCK, HITSCAN, while the following denote _bit masks_:
FLIP_BITMASK, ORIENT_BITMASK, TRANS_BITMASK.

[[sector_UPDATE_FLAGS]] sector.UPDATE_FLAGS::
Contains flags permissible to <<updatesector,updatesector>> and other sector
updating functions. BREADTH, Z.

'''
[[wall]]
===== wall
Accessible from 0 to gv.numwalls-1. Each element has the following
members:

_i32_ x, y::
The 2D coordinates or this wall point. Should not be set directly.

z (read-only)::
Always yields 0. The primary purpose of this field is to make wall references
permissible as arguments to <<vector_types,xmath vector>> operations.

point2 (read-only)::
The index of the second wall point.

[[nextwall]] nextwall, nextsector (read-only)::
If the wall is white'', these members equal -1. For red'' walls, they
contain the wall and sector indices (respectively) of the wall on the other side.

upwall, dnwall (read-only)::
For walls constrained by TROR extension, the upper and lower neighbor walls,
respectively. Any of them may be -1, meaning that the wall is not attached to
a neighbor in this direction.

[[wall_cstat]] _u16_ cstat, {nbsp} _bitfield_ cstatbits::
A bit field holding various flags about how the wall should be
displayed, how collision detection should be handled, etc.
The <<wall_CSTAT,wall.CSTAT>>
object should be used to obtain the values for applicable flags.

[[wall_picnum]]picnum (read-only)::
The tile number of the non-masked portion of the wall. If
wall.CSTAT.BOTTOMSWAP is set on this wall's .cstat, it is only displayed in
the upper portion. (The lower portion takes it from this wall's .nextwall
then; this will be labeled _use-other-bottom_ in the following.)

overpicnum (read-only)::
The tile number of the masked portion of the wall, i.e. that which is drawn if
this wall's .cstat has bit wall.CSTAT.MASK or wall.CSTAT.ONEWAY set.

_i8_ shade (<<wall_picnum,_use-other-bottom_>>)::
The shade of the wall for both non-masked and masked portions. Larger values
mean a more darker appearance.

_u8_ pal (<<wall_picnum,_use-other-bottom_>>)::
The palette swap'' index of the wall.

_u8_ xrepeat, yrepeat::
Values that are proportional to the number of times that the wall's texture
repeats in each direction per given wall length/height. A value of 8 renders
64 texels across a length of 1024 x/y map units or a height of 16384 z units.

_u8_ xpanning, ypanning (<<wall_picnum,_use-other-bottom_>>)::
The panning values of both masked and non-masked portions of the wall. One full
cycle is covered by values from 0 to 255.

_i16_ lotag, hitag, extra::
General-purpose tags'' provided for game programming. They may be used by
various EDuke32 effects internally, so it is advised to do some research before
claiming them for oneself.

===== wall methods

wal:set_picnum(tilenum), wal:set_overpicnum(tilenum)::
Set the tile number of the wall or its masked portion.

===== wall static functions

wall.dragto(i, pos)::
Set the position of the point of the wall with index i to pos, which can be
anything indexable with x and y. This function is the preferred way of
changing wall coordinates, since it takes care to reposition dependent wall
points, too.

===== wall static data

[[wall_CSTAT]] wall.CSTAT::
Provides a mapping of symbolic names to values applicable to
<<wall_cstat,wall[i].cstat>>.  These name single bits:
BLOCK, BOTTOMSWAP, ALIGNBOTTOM, FLIPX, MASK, ONEWAY, HITSCAN,
TRANS1, FLIPY, TRANS2,
while the following denote _bit masks_:
FLIP_BITMASK, TRANS_BITMASK.

'''
[[sprite]]
===== sprite

The sprite composite is accessible with indices from 0 to
gv.MAXSPRITES-1, but accesses to sprites that do not exist in the game world
have no meaning. Each element has the following members:

_i32_ x, y, z::
The BUILD coordinates of the sprite. It is not advisable to set these directly.

//////////
_i16_ ang::
TODO (make set_ang() out of that which always ANDs with 2047?)
//////////

[[sprite_cstat]] _u16_ cstat, {nbsp} _bitfield_ cstatbits::
A bit field holding various flags about how the sprite should be
displayed, how collision detection should be handled, etc.
The <<sprite_CSTAT,sprite.CSTAT>>
object should be used to obtain the values for applicable flags.

picnum (read-only)::
The tile number of the sprite, also used to determine which actor code is run
if this sprite has a statnum of actor.STAT.ACTOR.

_i8_ shade::
The shade of the sprite. This may not be the shade that this sprite is
ultimately drawn with, though.

_u8_ pal::
The palette swap'' index of the sprite. This may not be the palette swap that
this sprite is ultimately drawn with, though.

_u8_ blend::
The blending table index of the sprite. See
<<blending_table_interfaces,Blending table interfaces>> for more details.

_u8_ clipdist::
In the engine, this member is used in the clipmove() function: it controls
the distance at which another moving object is considered to be in collision
with this *view-aligned* and *stationary* sprite.footnote:[The clipmove()
function is called for the moving object. The stationary one is a candidate for
collision out of potentially many.] It does *not* control the inverse case: the
distance at which the moving object is considered in collision with the
stationary one is determined by the walldist argument to clipmove(). +
More precisely, it designates half the side-length of the bounding square
divided by 4. Thus, a value of 255 keeps moving objects away from this one at
a max-norm distance footnote:[The max-norm distance between points
_p_~1~=(x~1~, y~1~) and _p_~2~=(x~2~, y~2~) is defined as max(abs(x~2~ --
x~1~), abs(y~2~ -- y~1~)).]  of at least 1020 BUILD x/y units.
+
In the Duke3D game code, it is also used to determine said walldist argument
for certain clipmove() calls, i.e. to control (1/8^th^ of) the base side
length of the moving sprite's clipping cuboid: this is the case for
+
* user actors declared as actor.FLAGS.enemy or actor.FLAGS.enemystayput in
  the Lua gameactor call (or which were provided the corresponsing flags for
  CON's useractor) having an xrepeat less than or equal to 60, or
* non-enemies that are either not projectiles, or projectiles that have a
  certain projectile bit set (*TODO*; these are not yet documented.)

// ^ XXX: clipshapes? Also, clipdist is effective for moving sprites (A_MoveSprite()).

_u8_ xrepeat, yrepeat::
The size of the sprite in each dimension. For wall- and floor- aligned sprites,
a value of 64 means a width of 16 x/y BUILD units or a height of 256 z BUILD
units per texel.

sectnum (read-only)::
The index of the sector that this sprite is currently contained in.

[[sprite_statnum]] statnum (read-only)::
The current _status number_ of this sprite. Applicable values are contained in
<<actor_STAT,actor.STAT>>.

owner (read-only)::
The index of the sprite from which this sprite was spawned. If this sprite is
not a child'' of another one, then owner is the index of this sprite itself.
//Occasionally, game effects may use this member for their particular purposes,
//so research is recommended before claiming it for oneself.

_i16_ xvel, zvel::
For actors and other moving sprite kinds, the horizontal and vertical
components of the current velocity. See the description of
<<con_move,con.move>> for more details.

_i16_ yvel (read-only)::
A member used for different purposes by Duke3D. Setting it is only allowed
through the set_yvel method.

_i16_ lotag, hitag, extra::
General-purpose tags'' provided for game programming. They may be used by
hard-coded actors internally, so it is advised to do some research before
claiming them for oneself.

===== sprite methods

spr:set_picnum(tilenum)::
Sets the tile number of sprite spr to tilenum. It is disallowed to issue
set_picnum on an APLAYER sprite or change the tile number of a sprite to
APLAYER.

spr:set_yvel(yvel)::
Sets the yvel member of sprite spr to yvel. It is disallowed to issue
set_yvel on an APLAYER sprite. Further restrictions are reserved.

spr:getheightofs() -> height, offset::
Returns the height and z offset of sprite spr in BUILD z units. Adding the
offset to spr.z yields the z coordinate at the bottom of the
sprite. Subtracting from that the height results the z coordinate at its
top. However, the per-tile z offset is not taken into account.

spr:setpos(pos [, newsect])::
Unconditionally sets the position of spr to pos, which can be anything
indexable with x, y and z. Thus, in effect a shorthand for
+
[source]
----------
spr.x, spr.y, spr.z = pos.x, pos.y, pos.z
----------
+
If newsect is passed, additionally calls spr:changesect(newsect). +
Returns spr.

spr:changesect(sectnum)::
An alternative way to call
+<<sprite_changesect,sprite.changesect>>(_index_of_spr_, sectnum)+, where
_index_of_spr_ is the sprite index corresponding to spr.  This method is
provided for convenience, but may be slower than the static function
changesect.

spr:updatesect([flags])::
An alternative way to call
+<<sprite_updatesect,sprite.updatesect>>(_index_of_spr_, flags)+, where
_index_of_spr_ is the sprite index corresponding to spr.  This method is
provided for convenience, but may be slower than the static function
updatesect.

===== sprite iterators

+*for* i *in* sprite.all()+::
Iterates over all sprites currently in the game world.

===== sprite static functions

sprite.changestat(i, statnum)::
Allows to manually change the status number of the sprite with index i to
statnum. If i is an invalid sprite index or the index of a sprite not in
the game world, or statnum is an invalid status number, an error is thrown.

[[sprite_changesect]] sprite.changesect(i, sectnum)::
Allows to manually change the sector number of the sprite with index i to
sectnum. If i is an invalid sprite index or the index of a sprite not in
the game world, or sectnum is an invalid sector index, an error is thrown.

[[sprite_updatesect]] sprite.updatesect(i [, flags])::
Updates the sector number of the sprite with index i, in effect setting
sprite[i]'s sector number to the result of
+
[source]
----------
updatesector(sprite[i].pos, sprite[i].sectnum, flags)
----------
+
If the <<updatesector,updatesector>> call returns -1, the sprite's sector
number remains unchanged. +
Returns the result of the updatesector call.

===== sprite overridden operators

[[sprite_power]] spr^zofs::
Returns an <<vector_types,xmath.ivec3>> object that contains the position of
this sprite, diminished by zofs in the z direction. Because in BUILD, z
coordinates increase toward the floor, the ^ can be thought of as raise the
sprite by zofs units''.

===== sprite static data

[[sprite_CSTAT]] sprite.CSTAT::
Provides a mapping of symbolic names to values applicable to
<<sprite_cstat,sprite[i].cstat>>.  These name single bits:
BLOCK, TRANS1, XFLIP, YFLIP, ALIGNWALL, ALIGNFLOOR, ONESIDE,
CENTER, HITSCAN, TRANS2, INVISIBLE,
while the following denote _bit masks_: ALIGN_BITMASK, TRANS_BITMASK.

===== spriteext

Accessible with the same indices and with the same restrictions as
<<sprite,sprite>>.

//angoff::
//The BUILD angle that is added to that of a drawn voxel or model.

// XXX: needs better wording to express this: tspr->ang + spriteext[tspr->owner].angoff


Game-side composites
^^^^^^^^^^^^^^^^^^^^

[[actor]]
===== actor

The actor composite holds various run-time data about a sprite.  Like
<<sprite,sprite>>, it is accessible with indices from 0 to
gv.MAXSPRITES-1, but accesses to actors that do not exist in the game world
have no meaning. Each element has the following members:

_u16_ movflags, {nbsp} _bitfield_ movflagsbits::
The actor's current <<actor_MOVFLAGS,movement flags>>.

[[actor_methods]]
===== actor methods

The following methods query or set properties related to
<<actions_moves_ais,actor behavior>>.

a:set_action(act)::
Sets the action of actor a to act, which may be either an object returned
by <<con_action,con.action>> or a number 0 or 1. Resets the actor's _action
count_ and current frame offset to 0.

a:has_action(act)::
Returns a boolean of whether the current action of actor a is act, which
can be any value permissible to a:set_action(). For composite action objects,
equality is established using its hidden ID, not the public members. Refer to
<<actions_moves_ais,Actions&#44; moves and AIs>> for further details.

a:set_action_delay()::
Overrides the <<action_delay,delay>> of the current action of actor a
without changing the action's ID.

a:set_count(count)::
Sets the actor's _execution count_ to count. The execution count of an actor
increments after each time its <<gameactor,callback function>> has run once.

a:get_count()::
Returns the actor's execution count.

a:reset_acount()::
Resets the _action count_ of the actor to 0. The action count is incremented on
each frame advance of the actor's current action. Also see the
<<action_delay,delay>> argument to con.action.

a:get_acount()::
Returns the actor's action count.

a:set_move(mov [, movflags])::
Sets the move of actor a to mov, which may be either an object returned by
<<con_move,con.move>> or a number 0 or 1. See the <<gameactor_move,move>>
argument to gameactor for further details. If <<actor_MOVFLAGS,movflags>>
is omitted, it defaults to 0.
+
The set_move method resets the actor's execution count. Also, if moveflags
has bit <<actor_MOVFLAGS,actor.MOVFLAGS.randomangle>> set and the actor is
not an enemy or a live enemy, its sprite[].ang value is set to a random''
value using <<krand,gv.krand>>.

a:has_move(mov)::
Returns a boolean of whether the current move of actor a is mov, which can
be any value permissible to a:set_move(). Like with a:has_action(),
equality is established using the move ID in case a composite one is passed.

a:set_hvel(hvel)::
Overrides the <<con_move,horizontal velocity>> of the actor's current move to
hvel without changing its ID.

a:set_vvel(vvel)::
Overrides the <<con_move,vertical velocity>> of the actor's current move to
vvel without changing its ID.

a:set_ai(ai)::
Sets the AI of actor a to ai, which must be an object returned by
<<con_ai,con.ai>>. In addition to setting the current AI ID of the actor,
a:set_ai(ai) is equivalent to the sequence
+
[source]
----------
a:set_action(ai.act)
a:set_move(ai.mov, ai.movflags)
----------

a:has_ai(ai)::
Returns a boolean of whether the current AI of actor a is ai.

Various methods query whether the last movement step of the actor made it
collide with another object, or allow getting this object's index then.

a:checkhit()::
Returns a boolean of whether the actor hit any object in the world, including
ceilings and floors.
// TODO: This needs verification:
// Staying motionless on the ground is considered as hitting'' it, too.

a:checkbump()::
Returns a boolean of whether the actor bumped into another actor or a wall.

a:hitwall()::
If the actor hit a wall with the last movement, returns that wall's
index. Otherwise, returns *nil*.

a:hitsprite()::
If the actor hit a sprite with the last movement, returns that sprite's
index. Otherwise, returns *nil*.

// TODO: set_picnum, set_owner?

[[actor_static_functions]]
===== actor static functions

actor.fall(i)::
Causes the actor with index i to fall in a hard-coded'', not further
specified fashion.

[[actor_static_data]]
===== actor static data

[[actor_STAT]]
actor.STAT::
Provides a mapping of symbolic names to values applicable as sprite
<<sprite_statnum,status numbers>>. +
DEFAULT, ACTOR, ZOMBIEACTOR, EFFECTOR, PROJECTILE, MISC,
STANDABLE, LOCATOR, ACTIVATOR, TRANSPORT, PLAYER, FX, FALLER,
DUMMYPLAYER, LIGHT.

[[actor_FLAGS]] actor.FLAGS::
Contains symbolic names of values applicable to <<gameactor,gameactor>>'s
flags input argument, most of which are described there. +
SHADOW, NVG, NOSHADE, NOPAL, NOEVENTS, NOLIGHT,
USEACTIVATOR, NOCLIP, SMOOTHMOVE, NOTELEPORT, NODAMAGEPUSH.

//BADGUY,

[[actor_MOVFLAGS]] actor.MOVFLAGS::
Contains symbolic names of values applicable <<gameactor,gameactor>>'s
movflags input argument, actor[]:set_move(), and the like. +
* faceplayer, geth, getv, randomangle, faceplayerslow, spin,
  faceplayersmart, fleeenemy, seekplayer, furthestdir,
  dodgebullet, all naming single bits
* jumptoplayer_bits: the bitwise-OR of *two* bits, one of which is faceplayer
* jumptoplayer_only: the same as jumptoplayer_bits, but without the faceplayer bit set
* jumptoplayer: [red]*deprecated*

'''
[[player]]
===== player

Accessible with the index 0 and any nonnegative pli index passed to a
<<gameactor,game actor>> or event callback function.

.Arrays with named elements
The structures obtained by indexing player contain arrays whose elements may
be referred to either by index of by a particular name. Thus, the array can be
thought to be overlaid with a structure containing as many members as the array
has elements, all having the element's type.

Currently, there are with two kinds of names: weapon names and inventory
names. They will be marked using notation like this:

==========
_i16_ +ammo_amount[_weapon_]+

means that the structure member ammo_amount is an array with named elements,
themselves being of signed 16-bit integer type. The array can be indexed with
valid weapon numbers, or weapon names. In the following (constructed) example,
the first player's current pistol ammo count is set to that of the currently
selected weapon:
[source]
----------
local ps = player[0]
ps.ammo_amount.PISTOL = ps.ammo_amount[ps.curr_weapon]
----------
==========

The inventory names are the same as the keys of <<gv_GET,gv.GET>>, those for
the weapons coincide with the keys of <<gv_WEAPON,gv.WEAPON>>.

.Boolean members

Player members marked _bool_ in the listing below yield Lua true or false on
reading and expect one of these values when assigned to.


[[player_members]]
===== player members

<<vector_types,_xmath.ivec3_>> vel::
The vector of the player's current velocity, accounted each time a player's
input is processed. The x and y components are in BUILD x/y units per game tic,
scaled by 2^14^. The z component is given in BUILD z units per game
tic. Processing a player's input and other EDuke32 game code may change vel
behind a user's back'' in a further unspecified fashion.

_i32_ runspeed::
The factor, scaled by 2^16^, with which the player's current horizontal
velocity is multiplied before calculating its new position. On various
occasions, the ultimate scaled factor is the difference of runspeed and at
most 8192.

curr_weapon::
The index of the player's currently selected weapon.

_u16_ gotweapon, {nbsp} _bitfield_ gotweaponbits::

Indicates whether each weapon is in the possession of the player. If bit 2^w^
is set for a <<gv_WEAPON,weapon index>> w, the player has got this
weapon. The player methods has_weapon, give_weapon and take_weapon can be
used to query or modify this member.

_i16_ +ammo_amount[_weapon_]+::

The current ammo amount for each weapon.

_i16_ +max_ammo_amount[_weapon_]+::

The maximum ammo amount for each weapon. Because ammo_amount amount and
max_ammo_amount are writable without restriction, it is the user's
responsibility to make sure that the former never exceeds the latter and that
both are non-negative at all times. Otherwise, erratic behavior may ensue.

_bool_ jetpack_on, {nbsp} scuba_on, {nbsp} heat_on::

Whether the player currently has the jetpack, scuba gear, or night vision
goggles activated, respectively.

:wiki_predef_gamevars: http://wiki.eduke32.com/wiki/Category:Pre-defined_gamevars

_weapondata_t_ +weapon[_weapon_]+::

A struct containing information about the behavior each of weapon for this
player. In CON, these are available as separate gamevars named
{wiki_predef_gamevars}[WEAPONx_*] for weapon indices x and members *.

[float]
==== _weapondata_t_ members

In Lunatic, some members of the _weapondata_t_ structure are checked when
being assigned to and issue an error on attempting to set them to an invalid
value. All these members assume *zero* to mean the neutral/no-op value (instead
of --1, as would seem more logical), and consequently, Lunatic only allows
values greater or equal zero to be assigned to them.

// TODO: workslike + flags

* clip
* reload
* firedelay
* totaltime
* holddelay
* flags
* shoots (checked)
* spawntime
* spawn (checked)
* shotsperburst
* initialsound (checked)
* firesound (checked)
* sound2time  [gray]#// This is a time number, not a sound number#
* sound2sound (checked)
* reloadsound1 (checked)
* reloadsound2 (checked)
* selectsound (checked)
* flashcolor

[[player_methods]]
===== player methods

ps:has_weapon(widx)::
Returns a boolean of whether player ps has got the weapon with index widx.

ps:give_weapon(widx)::
Adds the weapon given by index widx to player ps's possession without
changing the currently held one.

ps:take_weapon(widx)::
Removes the weapon given by index widx from player ps's possession. If an
attempt is made to remove the currently selected weapon, the behavior is
undefined.

ps:fadecol(fadefrac, r, g, b [, speed [, prio]])::

Initiates a tinting that linearly fades over time and is blended with the whole
screen contents whenever player ps's view is displayed.footnote:[The behavior
is unspecified should more than one player's view be displayed at one time.]
The first argument fadefrac specifies the starting blending coefficient; r,
g and b specify the intensities of the red, green and blue color
components, respectively.
+
Both fadefrac and the component intensities are first clamped to the range
[0.0 .. 1.0]. The resulting values are interpreted as a proportion, 0.0 meaning
no blending/no color and 1.0 meaning full blending/full
color.footnote:[Currently, for implementation reasons, a value of 1.0 results
in only _almost_ full blending or presence of the specified color component.]
+
The fourth, optional argument speed controls the rate at which the tinting
diminishes. At a value of 1 (the default), a tint with a fadefrac of 0.5
finishes in approximately one second.
+
The last, optional argument prio must be an integer in the range [-128
.. 127], the default being 0. When a fadecol is issued in the presence of
another tint fading in progress, and the prio given by the arriving fadecol
is greater or equal than the prio of the ongoing one, the latter is canceled
and the arriving fading is initiated in its place. (There is no support for
tint fades that overlap in time.)
+
[icon="din_w_crushing.png"]
CAUTION: If Lunatic code that uses fadecol is loaded together with CON code
that writes to the player's pals members directly at any point, the behavior
is undefined.

[[player_iterators]]
===== player iterators

+*for* i *in* player.all()+::
Iterates over the indices of all active players.

// ===== projectile

===== g_tile

An array of size gv.MAXTILES. Currently, access with numeric indices by the
user is [red]#disallowed# for g_tile and its elements have [red]#no public
members#.

===== g_tile static data

g_tile.sizx, {nbsp} g_tile.sizy::
Arrays indexable with tile numbers [0 .. gv.MAXTILES-1] that hold the
horizontal and vertical texel sizes of each tile.


Lunatic functions
~~~~~~~~~~~~~~~~~

[[engine_iterators]]
Engine-side iterators
^^^^^^^^^^^^^^^^^^^^^

+*for* w *in* wallsofsect(sectnum)+::
Iterates over the indices of all walls of the sector with index sectnum.

+*for* s *in* spritesofstat(statnum [, maydelete])+::
Iterates over the indices of all sprites with status number statnum. If
maydelete is omitted or false, there must be no deletion of any sprite while
the loop is active. If maydelete is true, deleting sprites inside the loop is
allowed. Inserting sprites is always allowed.

+*for* s *in* spritesofsect(sectnum [, maydelete])+::
Iterates over the indices of all sprites contained in the sector with index
sectnum with the same meaning for maydelete as with spritesofstat.

[[sectorsofbunch_1]] +*for* s *in* sectorsofbunch(bunchnum, cf)+::

Iterates over the indices of the sectors whose ceiling's or floor's bunch
equals bunchnum, selected by passing gv.CEILING or gv.FLOOR
(respectively) to cf.

[[sectorsofbunch_2]] +*for* s, what *in* sectorsofbunch(bunchnum, gv.BOTH_CF)+::
Iterates over the indices of the sectors whose ceiling's and floor's bunch
equals bunchnum.  On each iteration, what is one of the strings 'ceiling'
or 'floor', denoting whether it's the ceiling or floor of sector s that has
the given bunch number.

Sector containment functions
^^^^^^^^^^^^^^^^^^^^^^^^^^^^

inside(pos, sectnum)::
Returns a boolean of whether the position pos (which can be anything
indexable with x and y) is considered inside the sector with number
sectnum, which must be valid. The z component is not taken into account.

===== Sector updating

A number of engine functions take a position pos and a starting sector number
sectnum and try to find a sector that contains pos, assuming it started out
in sectnum.footnote:[Note that this is different from CON's updatesector,
which takes the starting sector to be the one of the _current sprite_.]

If a valid sector numeric is passed for sectnum, these functions first check
whether that sector already contains pos (i.e. the position stays in the same
sector) and then attempt to search neighboring sectors. Unless breadth-first
search is requested (see below), if the passed sectnum is -1, all sectors
are searched in an unspecified order.

On success, these functions return the sector number of the updated'' sector,
otherwise -1.

[[updatesector]]
updatesector(pos, sectnum [, flags])::

Searches for a sector containing pos, which can be anything indexable with
x and y. Thus, the z component is not taken into account. If sectnum is
a valid sector number, first all its neighboring walls
(<<nextwall,wall[].nextwall>>, red wall links'') are searched, falling back
to a linear search on failure.
+
However, this strategy can be problematic if the position passes multiple thin
sectors that overlap another, potentially unrelated sector (for example, in a
TROR or sector-over-sector construction). If such a sector is passed without an
updatesector call ever made when it contains the position, the next call may
not find the real sector (as it is now two nextwall links away from the initial
one), and wrongly suggest the overlapping one instead.
+
For this reason, the optional argument flags accepts
<<sector_UPDATE_FLAGS,sector.UPDATE_FLAGS.BREADTH>>, instructing
updatesector to look for matching sectors in a _breadth-first_ search
starting from sectnum, and following all nextwall links. With this strategy,
there is *no* fallback to a linear search if no matching sector is found.
+
Passing sector.UPDATE_FLAGS.Z to flags makes the sector updating behave as
if updatesectorz was called. This is mainly useful if updatesector is
called via the <<sprite_updatesect,sector updating functions>> of sprites.

updatesectorz(pos, sectnum)::

Searches for a sector containing pos, which can be any value indexable with
x, y and z. Thus, it additionally takes the z component into account by
checking against the bounds that would be returned using a sector's
<<sec_cfz_at,ceilingzat/floorzat>> methods.
+
The updatesectorz function first checks the initial sector for containment of
pos, then it tries any TROR neighbors of sectnum. Finally, it proceeds like
updatesector as far as the searching order is concerned.

===== Collision detection and related functions

[[hitscan]]
hitscan(pos, sectnum, ray, clipmask)::

Starting from the position pos (which is assumed to be contained in
sectnum), the hitscan function determines the object that would be first
hit by a ray emanating from pos into the direction given by ray. Both pos
and ray may be any object indexable with x, y and z, but the components
are <<int_assignment,converted>> to signed 32-bit integers prior to being
passed to the actual engine function. Note that ray is interpreted in BUILD
scaling: the z component has 16 times the precision for a given game-world
length compared to x or y.
+
The clipmask argument determines what objects are considered being hittable
by the ray and is expected to be an integral number. It is interpreted as two
separate bit masks: the low 16 bits for walls and the high 16 bits for
sprites. Each time there is a potential collision, the respective mask is ANDed
with the cstat member of the object, and if the result is non-zero, the ray
is considered having hit the object.
+
The hitscan function returns an object with information about the hit object
(if any) as well as the position of its intersection with the ray. It contains
the following members:
+
* sector: The sector number of the hit object, or -1 if no object was
  hit. Thus, testing it for being greater or equal to zero is a quick way of
  finding out whether any object (ceiling/floor, wall, or sprite) was hit at
  all.footnote:[It is recommended to carry out this check for the sake of
  cautiousness: while proper hitscan invocations should always hit something,
  the function may come up empty in certain corner cases (such as a starting
  position outside of the designated sector).]
* wall: If a wall was hit, its index. Otherwise, -1.
* sprite: If a sprite was hit, its index. Otherwise, -1.
* pos: The position that is the intersection of the emanated ray with the hit
   object, indexable with x, y and z. Undefined if no object was hit.

//////////
cansee
hitscan
neartag
sectorsofbunch
//////////

Customizing the game
^^^^^^^^^^^^^^^^^^^^

In Lunatic, there are two main ways of customizing the game's behavior. Both
involve the user providing functions that are _called back_ at certain points
in the execution of EDuke32. Game _actors_ are simply sprites that run a
particular piece of code based on their tile number each game tic, unless they
are in a dormant'' state. Game _events_ are invoked at predetermined points
in the program flow.

To register custom actor and event code with the game (and define additional
actor information), Lunatic provides two functions in the global environment,
gameactor and gameevent. As their sole argument, they take a table
containing the appropriate data.

[[gameactor]]
===== The function gameactor{tilenum [, ...], func}

:Lua51_FunctionCalls: http://www.lua.org/manual/5.1/manual.html#2.5.8

Registers custom code for the actor given by tile number tilenum. For each
non-sleeping actor, the function func is called every game tic with three
input arguments: func(aci, pli, dist).

* aci: the sprite number of the actor invoking func
* pli: the index of the player that is nearest to this actor
* dist: the 3D Manhattan distance
  footnoteref:[mhdist_def,The Manhattan distance between points
  _p_~1~=(x~1~&#44; y~1~&#44; z~1~) and _p_~2~=(x~2~&#44; y~2~&#44; z~2~) is
  defined as abs(x~2~ -- x~1~) + abs(y~2~ -- y~1~) + abs(z~2~ -- z~1~).]
  between actor aci and player pli

// NOTE: &#44; is the comma; the footnote would be truncated at it otherwise.
// For a related issue, see
// http://www.methods.co.nz/asciidoc/faq.html#_why_am_i_having_trouble_getting_nested_macros_to_work

Additionally, gameactor accepts optional input arguments. They can be
specified positionally by following tilenum, or be given as values to string
keys of the argument table. Each such input argument may be provided in at most
one of these two forms. Furthermore, func may be provided as value to the
key 'func' as well.

[[gameactor_flags]]
[2] flags::
A number that controls both certain aspects of the gameactor call as well as
the run-time behavior of the actor itself. A couple of bits for the latter type
are listed in <<actor_FLAGS,actor.FLAGS>>, abbreviated AF in the following.
+
These values describe the type'' of the actor: AF.enemy, AF.enemystayput
and AF.rotfixed. Except for enemystayput, they name single bits
(enemystayput implies enemy).
+
In Lunatic, game actors can be _chained_, that is, a callback function can be
either appended to the end of an already registered one, or prefixed at its
front. In this case, a previous gameactor call must have taken place for that
actor (this may have happened from a CON useractor block, which gets
translated to gameactor). Moreover, this mechanism allows to add run-time
flags to the actor in question.
+
Chaining two callback functions is achieved by creating a new one that calls
the first one, followed by a {Lua51_FunctionCalls}[tail call] of the second
one. This has certain implications if control is transferred non-locally, for
example by using <<nlcf,con.longjmp>>.
+
Several flags in AF are provided to control how a gameactor invocation
handles chaining. In all cases, the actor tile flags are bitwise-ORed with the
existing ones.
+
* AF.replace: Replace the callback function. This is the way CON's
  useractor behaves and is also the Lunatic default.
* AF.replace_soft: deprecated alias for AF.replace
* AF.replace_hard: [red]*deprecated*
* AF.chain_beg: Prepend the provided func to the existing callback function.
* AF.chain_end: Append the provided func to the existing callback function.
+
The following members all default to 0 if omitted.
+
[3] strength::
The initial strength or health of the actor.

[4] action::
The initial action of the actor. May be either an object returned by
<<con_action,con.action>>, or the numbers 0 or 1. Both represent actions with
that ID, but all public members set to 0.

[[gameactor_move]] [5] move::
The initial move of the actor. May be either an object returned by
<<con_move,con.move>>, or the numbers 0 or 1. Both represent moves with that
ID, but all public members set to 0. A move of 0 disables the usual actor
movement, even if its hvel or vvel subsequently get overridden (and the
corresponding movflags set).

[6] movflags::
The actor's initial movement flags. Applicable bits are available in the
<<actor_MOVFLAGS,actor.MOVFLAGS>> object.

===== The function gameevent{evtlabel [, flags], func}

:wiki: http://wiki.eduke32.com
:wiki_eventlist: http://wiki.eduke32.com/wiki/EDuke32_event_list

Registers custom code to be run at specific points in the program.  The first
argument evtlabel should be a string naming the event. A complete
{wiki_eventlist}[list of events] can be found at the {wiki}[EDuke32 wiki]. The
label may be stripped of the leading EVENT_'', so that e.g. EVENT_JUMP
and simply JUMP denote the same event.

The arguments flags and func can alternatively be passed as values to the
same-named keys of the input argument table to gameevent. Like with
gameactor, each may be provided in at most one of the two forms.

The callback func is invoked with the same arguments and meaning as for
<<gameactor,gameactor>>, but certain events are run in contexts where no
meaningful aci and/or pli value can be assigned. In this case, func
receives -1 for the respective input arguments.

Like with actors, game events may be chained or replaced by passing an
appropriate flags value. However, it is not necessary for an event to be
already defined when chaining is requested. In that case, it is simply
registered initially.  Permissible values for these flags are provided in
actor.FLAGS as well (abbreviated AF here):

* AF.replace: Replace any previously defined event code with the given one.
* AF.chain_beg: Prepend the provided func to the existing callback
  function. This is the behavior of CON's onevent.
* AF.chain_end: Append the provided func to the existing callback
  function. This is the default.

// TODO: RETURN handling...


[[ext_api]]
Extended API (Lunatic modules)
------------------------------

The xmath module
~~~~~~~~~~~~~~~~~~

Mathematical functions
^^^^^^^^^^^^^^^^^^^^^^

:BitOpUndefined: http://bitop.luajit.org/semantics.html#undefined

Lunatic, being a Lua-based scripting system, provides the user with a single
numeric data type that variables can contain on the Lua side --
double-precision floating point.footnote:[In LuaJIT, variables additionally can
take on boxed'' 64-bit integer numeric types, but these should not be used
for numeric calculations.]  However, since BUILD, and in turn, EDuke32, almost
exclusively use integer types to represent quantities such as angles or carry
out e.g. trigonometrical calculations, there is a need for convenient
interoperability between the two worlds''.

Two pairs of functions calculate the trigonometric sine and cosine, both
accepting a BUILD angle as input argument, but differing in the scaling of
their result. Using these functions is recommended over Lua's math.sin or
math.cos in cases where the argument is a BUILD angle in the first place, for
example because it is read from an engine or game structure. The computation is
both faster (because it is essentially only a bitwise-AND operation followed by
a table lookup) and the results have the symmetry expected from the
mathematical counterparts.

xmath.sinb(bang), {nbsp} xmath.cosb(bang)::
Returns the sine/cosine of the given BUILD angle bang, which can be any whole
number in [--2^31^{nbsp}..{nbsp}2^31^--1].footnote:[Passing fractional values
is possible, but discouraged. See the relevant {BitOpUndefined}[subsection] of
the BitOp documentation for more details.] In BUILD, one full cycle is covered
by values from 0 to 2047; in other words, an angle of 2048 corresponds to 360
degrees.
+
The sinb and cosb functions return values in the range [--1 .. 1], just
like their mathematical counterparts.
+
The following guarantees are made for sinb whenever its argument expression
is permissible:
+
* sinb(-a) == -sinb(a) (point symmetry around the origin)
* sinb(a + i*2048) == sinb(a), where i is any whole number (periodicity)
* sinb(1024 - a) == sinb(a) (mirror symmetry around a=512)
* sinb(a - 1024) == -sinb(a) (point symmetry around a=1024)
* The value for cosb(a) is derived as sinb(a + 512).

xmath.ksin(bang), {nbsp} xmath.kcos(bang)::
Returns the sine/cosine of the given BUILD angle bang, multiplied with 16384
and rounded towards zero. The same guarantees as for the sinb/cosb pair
apply.

xmath.angvec(ang)::
Returns a <<vector_types,vec3>> with the components math.cos(ang),
math.sin(ang) and 0 for x, y and z, respectively.

xmath.bangvec(bang)::
Returns a <<vector_types,vec3>> with the components xmath.cosb(bang),
xmath.sinb(bang) and 0 for x, y and z, respectively.

xmath.kangvec(bang [, z])::
Returns an <<vector_types,ivec3>> with the components xmath.kcos(bang),
xmath.ksin(bang) for x and y, respectively. The z component can be passed in
the optional argument z, which defaults to 0 if omitted.

xmath.dist(pos1, pos2)::
Returns an approximation of the 3D Euclidean distance between points pos1 and
pos2, both of which can be any object indexable with x, y and z.
<<cf_z,BUILD z units>> are assumed.

xmath.ldist(pos1, pos2)::
Returns an approximation of the 2D Euclidean distance between points pos1 and
pos2, both of which can be any object indexable with x and y.

[[xmath_rotate]] xmath.rotate(point, bang [, pivot])::
Returns as an <<vector_types,xmath.vec3>> the position of point rotated
around the line parallel to the z axis going through pivot by bang BUILD
angle units in the mathematically negative (clockwise) direction. The arguments
point and pivot can be anything indexable with x, y and z. The z
component of the result is the difference between that of point and
pivot. If pivot is omitted, it defaults to the origin vector containing
zeros for all components.

[[vector_types]]
The types xmath.vec3 and xmath.ivec3 [_serializable_]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Another purpose of the xmath module is to provide _vector_ types that allow
writing concise and clear code involving geometrical calculations. There are
two types, both containing three components (x, y and z), but differing
in their numeric type. For the most part, vec3 should be used, whose
components are Lua numbers, i.e. floating point. The other type, ivec3, is
part of some game structures, and consequently uses 32-bit integers for its
components. With minor differences, the vec3 and ivec3 types share the same
operations and methods.

The constructors of the vector types can be called in several ways. In the
following, they are only described for vec3. The conventions for ivec3 are
completely analogous, but since their creation involves a number type
conversion, the rules about <<int_assignment,assignment to integer types>>
apply.

v = xmath.vec3([x [, y [, z]]])::
Create a 3-element vector v by passing the x, y and z components
separately. Trailing components can be omitted, in which case they are
initialized to 0.

v = xmath.vec3(t)::
Create a 3-element vector v by passing t, which can be any variable
indexable with the strings x, y and z (and yielding numbers for these
lookups). For example, t can be another (i)vec3, a sprite or even
<<wall,wall>> reference, as each of them can be indexed with these three
keys.

Since the vector types are compound objects, they are always passed around by
reference. For example, consider executing
[source]
----------
v = xmath.vec3(0, 10)
w = v
w.y = 20
----------
After this code, the expression v.y yields 20 instead of the initial value
10.

===== Operations for vec3 and ivec3

In the following, v denotes a vec3 or ivec3 object reference while t
denotes any object indexable with x, y and z. Note that for binary
operations, Lua looks for overridden operators in the left operand first and
the right one next.  So, where t appears on the left hand side of an
arithmetic expression, it is assumed that t's type does not overload the
corresponding operation or provides the same semantics. Arithmetic operations
always return a (reference to a) new vec3 object, even if any or both of the
operands have ivec3 type.

v + t, {nbsp} t + v::
Returns a new vec3 object whose components are the sum of the respective
components of v and t.

v - t, {nbsp} t - v::
Returns a new vec3 object whose components are the difference of the
respective components of v and t (in the first case) or t and v (in the
second case).

-v::
Returns a new vec3 object with the components of v negated.

a*v, {nbsp} v*a::
For a scalar number a, returns a new vec3 object whose components are those
of v multiplied with a.

v/a::
For a scalar number a, returns a new vec3 object whose components are those
of v divided by a.

v^zofs::
Returns an object of the same type as v and with the same components, except
that v.z is diminished by zofs. Also see the <<sprite_power,power
operation>> for sprite objects.

tostring(v)::
Returns a string representation of v for display purposes: vec3'' or
ivec3'', followed by the components of v in parentheses.

===== Methods for vec3 and ivec3

v:len()::
Returns the Euclidean length of v in three dimensions.

v:lensq()::
Returns the squared Euclidean length of v in three dimensions.

v:len2()::
Returns the Euclidean length of v, taking only the x and y components
into account.

v:len2sq()::
Returns the squared Euclidean length of v, taking only the x and y
components into account.

v:mhlen()::
Returns the length of v calculated using the Manhattan distance
footnoteref:[mhdist_def] in three dimensions between the origin and the
endpoint.

v:toivec3()::
Returns a new ivec3 object with the same components as v, but converted
<<int_assignment,to integers>>.

v:touniform()::
Returns a new vector of the same type as v which has the same x and y
components as v, but the z element divided by 16 (if v is a vec3) or
arithmetically right-shifted by 4 (if v is an
ivec3).footnote:[Right-shifting by 4 can be seen as a division by 16 with
subsequent rounding to an integer towards negative infinity.] Also see the
description of the ceiling/floor <<cf_z,z member>>.

v:tobuild()::
Returns a new vector of the same type as v which has the same x and y
components as v, but the z element multiplied with 16.

v:rotate(bang [, pivot])::
Equivalent to +<<xmath_rotate,xmath.rotate>>(v, bang [, pivot])+.


The con module -- game control
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The con module on one hand provides functionality to control certain aspects
of the game, such as defining game-side animations for actors. On the other
hand, it hosts various functions that are familiar from CON, although sometimes
under a different name.

[[actions_moves_ais]]
Actions, moves and AIs -- customizing actor behavior
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

In CON, three aspects of an actor can changed using a mechanism that is
syntactically similar for each. _Actions_ carry information about a particular
animation for an actor, such as how many frames it contains. _Moves_ define the
potential motion characteristics of an actor. Finally, _AIs_ are aggregates of
an action and a move, plus _movement flags_ that toggle certain movement
aspects.

At file scope, one first defines each of these composites using directives such
as action, and inside code blocks to be executed at game time, one instructs
the game to use a particular composite by passing the chosen label to the
same-named command (i.e. action for our example).

Lunatic provides a similar mechanism, but the main difference from CON is that
the definition functions merely return the composite structures, without
registering them under any particular name. Thus, it is up to the user to
organize them, for example by storing those for each class in a separate table
indexed by chosen names. Similar to CON, the creation functions may only be
called when the game is not yet running.

Actor behavior composites contain an additional hidden'' ID. Each invocation
of a creation function such as con.action returns a composite with a unique
ID per composite type. This ID is used to compare for equality in actor methods
such as actor[]:has_action(). All returned composites are immutable.

[[con_action]]
===== The function con.action{ ... }

:wiki_action: http://wiki.eduke32.com/wiki/Action
:Lua51_TableConstructors: http://www.lua.org/manual/5.1/manual.html#2.5.7

Returns a new _action_ composite created with the given values. The
con.action function expects a single table as input argument, each of whose
keys denote an action member. Each member may be provided by an index in the
table or its name, but not both. Members may be omitted, in which case they
default to either 0 or 1.

Refer to the {Lua51_TableConstructors}[Table Constructors] subsection of the
Lua 5.1 Reference Manual for the syntax and semantics of table initialization.

[1] startframe::
The offset of the starting frame of the animation, relative to the
sprite[].picnum of an actor (i.e. the tile number, selecting which actor code
is run).

[2] numframes (default: 1)::
The total number of frames in the animation.

[3] viewtype (default: 1)::
The number of consecutive tiles used to construct one frame of the animation,
as viewed from different angles. Valid values are 1, 3, 5, 7 and 8. In
addition, -5 and -7 are allowed, which behave like the corresponding positive
++viewtype++s, but effectively mirror the actor around the vertical axis. This
can be useful if tile data is available that has the opposite orientation of
what EDuke32 uses.  See the {wiki_action}[Action entry] in the EDuke32 wiki for
how the views are constructed for different viewtype values.

[4] incval (default: 1)::
The value to add the actor's _current frame_ on each frame advance. May be --1,
0, or 1.
// In the wild, sometimes other values, too.

[[action_delay]] [5] delay::
Roughly, the number of <<totalclock,gv.totalclock>> time units (120 per
second) after which a frame is advanced, at a granularity of one game tic (30
per second, corresponding to a delay difference of 4).footnote:[The reason
for the granularity is due to the implementation: each execution of an actor's
code increments its hidden action tics'' counter by four (= 120/30).]

// TODO: the above can be more precise. State in terms of floor(delay/4).

.Equivalent action definitions
==========
Each of the following calls return an action with the same public members:
[source]
----------
con.action{0, 4, delay=20}
con.action{0, 4, 1, 1, 20}
con.action{startframe=0, numframes=4, viewtype=1, incval=1, delay=20}
----------
==========

[[con_move]]
===== The function con.move{ ... }

Returns a new _move_ composite created with the given values, expecting a
single table as input argument. The same conventions as with con.action apply
for the following members:

[1] hvel::
The (most often) doubled horizontal velocity of the actor, in BUILD x/y units
per game tic. An actor's sprite[].xvel will approach this value in an
exponential'' fashion, halving the difference between the current velocity
and this goal velocity each movement update from the actor execution loop. For
most objects, sprite[].xvel is then further halved to yield the ultimate
velocity. Only effective when the actor's movflags has
<<actor_MOVFLAGS,actor.MOVFLAGS.geth>> is set.

[2] vvel::
The (most often) doubled horizontal velocity of the actor, in BUILD x/y (*not*
z) units per game tic. An actor's sprite[].zvel will approach 16 times this
value in an exponential'' fashion. For most objects, sprite[].zvel is then
further halved to yield the ultimate velocity.  Only effective when the actor's
movflags has <<actor_MOVFLAGS,actor.MOVFLAGS.getv>> is set.

[[con_ai]]
===== The function con.ai([action [, move [, movflags]]])

The con.ai function differs from con.action and con.move in that it is of
second order'', i.e. it accepts two composites as input arguments, returning
an _AI_ object containing these. Also, it is called with three positional,
optional arguments. Like for <<gameactor,gameactor>>, the numbers 0 and 1 are
permissible for action and move. Applicable bits for movflags are
available in the <<actor_MOVFLAGS,actor.MOVFLAGS>> object.

[[nlcf]]
Non-local control flow
^^^^^^^^^^^^^^^^^^^^^^

Two functions in the con module make the executed function abort early,
jumping directly to the end of the innermost event or actor callback
block''. They are used to implement among others CON's killit and
(confusingly named) return commands. If these functions are used when none of
the mentioned callback functions are active, the behavior is undefined.

con.longjmp()::
Silently transfers control to the end of the innermost actor or event callback
block, to the same point an error() call would do. Note that since callback
<<gameactor_flags,chaining>> is achieved by creating a new function for each
function pair, calling both unprotected, issuing a con.longjmp() inside any
part'' of a chain aborts the whole block -- functions in the chain that are
called later will not be reached. In contrast, returning from one function
transfers control to the beginning of the next in the chain if it exists.
+
.con.longjmp with chained events
==========
The following two chained EVENT_JUMP definitions,
[source]
----------
gameevent{"JUMP", function(_, pli)
    print("jump:first")
    if (player[pli].curr_weapon==gv.WEAPON.PISTOL) then
        return
    end
    print("aborting")
    con.longjmp()
end}

gameevent{"JUMP", function()  -- second function in EVENT_JUMP chain
    print("jump:second")
end}
----------
would print jump:first'' and jump:second'' when holding a
pistol. Otherwise, jump:first'' and aborting'' would be printed and the
second chained callback function would not be reached.
==========

con.killit()::
Silently transfers control to the end of the active actor callback block,
notifying the game to delete the executing actor's sprite. If con.killit is
called while no execution of actor code is active, the behavior is undefined.

Per-actor variables
^^^^^^^^^^^^^^^^^^^

// XXX: this text is too implementation-centric

Since in EDuke32, sprites in general exist in the world only for a limited
duration, it is wasteful to allocate an array of fixed size gv.MAXSPRITES for
the purpose of a variable that holds a value for each actor sprite. On the Lua
side, one could use a plain table, but for actors that are created and
destroyed during the course of a game, this would accumulate garbage'' --
values for sprites that have been deleted. Moreover, per-actor variables tend
to be topical'', one such variable being potentially only used for a very
specific actor tile. For this reason, per-actor variables are implemented in a
sparse'' fashion in Lunatic, but provide to the user the illusion of having a
value for every sprite index. They are also cleaned'' at unspecified
intervals.

[[con_actorvar]]
===== The type con.actorvar(defaultval) [_serializable_]

Creates and returns a new per-actor variable with default value defaultval
which can be indexed for reading or assignment in the range
[0{nbsp}..{nbsp}gv.MAXSPRITES-1], but access to it is subject to the same
restrictions as to <<sprite,sprite>> and other per-sprite structures.

When a sprite is created using con.insertsprite or con.spawn, its value at
the index of this new sprite is cleared (reset to defaultval). After a sprite
has been deleted, the value of a per-actor variable is indeterminate -- it may
be cleared by Lunatic at any point.

Per-actor variables may contain values of any permitted type, which currently
are boolean and number. Mixing values of different types is allowed: per-actor
variables are heterogenous containers.

Sprite insertion
^^^^^^^^^^^^^^^^

In Lunatic, there are two functions that insert a sprite into the game world.
They mainly differ in how they are used, and to which extent they imply
hard-coded'' behavior.

===== The function con.insertsprite{tilenum, pos, sectnum [, statnum [, owner]] [key=val...]}

Inserts a new sprite into the game with the properties given as input
arguments. If the world already contains the maximum number of sprites
(<<gv,gv.MAXSPRITES>>), currently the game is aborted and EDuke32
exits.footnote:[This is subject to change and must not be relied on.]
Otherwise, relevant per-sprite data for the newly inserted sprite is
cleared. No additional hard-wired'' C code is run.

Returns the index of the inserted sprite.

The function con.insertsprite can be used in one of two forms:

* In the table-call form specified above, a single table is passed whose
values are taken as the actual arguments. The first three, tilenum, pos and
sectnum, are passed positionally. All other input arguments are passed as
key-value pairs, but owner and statnum may be provided either positionally
or as key/value pair.

* Passing only the three to five positional arguments is also directly
  possible. For example, all of the following calls are equivalent:
+
[source]
----------
local i = con.insertsprite(tile, pos, sect, stat, ow)  -- direct-call
local i = con.insertsprite{tile, pos, sect, stat, ow}  -- table-call
local i = con.insertsprite{tile, pos, sect, statnum=stat, owner=ow}  -- table-call with 2 k/v args
local i = con.insertsprite{tile, pos, sect, stat, owner=ow}  -- table-call with one k/v arg
----------

The five main arguments are as follows:

[1] (tilenum)::
The tile number of the sprite to insert.

[2] (pos)::
The position at which to insert the sprite (anything indexable with x, y and z).

[3] (sectnum)::
The index of the sector in which to insert the sprite.

[4] statnum (default: actor.STAT.DEFAULT)::
The initial status number of the inserted sprite.

[5] owner (default: see below)::
The index of the sprite that is in some sense the parent'' of the newly
created one. If omitted, it is set to the index of the newly spawned sprite.

These keys are permissible as optional input arguments in the table-call form,
corresponding to the same-named <<sprite,sprite>> members:

* shade, ang, xvel, zvel (default: 0)
* xrepeat and yrepeat (default: 48)

===== The function con.spawn(tilenum, parentspritenum)

Spawns a new sprite with tile number tilenum from a given parent'' sprite
with index parentspritenum, which must be valid. The sprite is spawned at the
same position as its parent and its owner member is set to
parentspritenum. Additional hard-wired'' code dependent on tilenum may be
run afterwards, possibly modifying the sprite.

Returns the index of the spawned sprite on success.

===== The function con.shoot(tilenum, parentspritenum [, zvel])

Attempts to shoot a projectile with tile number tilenum from the sprite with
index parentspritenum. The z velocity can be overridden by passing zvel.

// TODO: document how zvel is interpreted

Returns the index of the spawned sprite on success, or --1 otherwise.


The engine module
~~~~~~~~~~~~~~~~~~~

Base palette interfaces
^^^^^^^^^^^^^^^^^^^^^^^

The 8-bit (classic'') Build renderer operates in indexed-color mode: the
pixels of the frame buffer do not contain red/green/blue values themselves, but
only indexes into a color table with 256 entries, the _base palette_.
**********
latexmath:[$\mathrm{ColorComponent} := \mathbb{N}_{64}$] {nbsp}
[gray]#// Build's base palettes have 6 bits of precision per color component# +
latexmath:[$\mathrm{ColorIndex} := \mathbb{N}_{256}$] +
latexmath:[$\mathrm{basepal}: \: \mathrm{ColorIndex} \rightarrow \mathrm{ColorComponent}^3$] +
**********

The following functions provide a bridge between color indices and their
corresponding color components.

r, g, b = engine.getrgb(i)::
Returns the red, green and blue color components of the default base palette
for color index i. The color components are in the range [0 .. 63].
+
If i is 255, r, g and b are all returned as 0, even if the actual base
palette may contain different values for that index.

i = engine.nearcolor(r, g, b [, lastokcol])::

Given the red, green and blue components r, g and b of a query color,
returns the color index i whose color in the default base palette is closest
to the query color. Closeness'' is established using an Euclidean distance
with a weighting on the color components.
+
The optional argument lastokcol can be used to restrict the range of color
indices to search: the returned color index is guaranteed to be in the range
[0{nbsp}..{nbsp}lastokcol]. It defaults 255, so that all colors are
searched.footnote:[For example, it may be desirable to omit fullbright''
colors from being returned. The shade table loaded from Duke3D's PALETTE.DAT
makes color indices 240--254 fullbright, so passing 239 to lastokcol achieves
the mentioned filtering.]

[[shade_table_interfaces]]
Shade table interfaces
^^^^^^^^^^^^^^^^^^^^^^

To implement shading and visibility attenuation, Build maintains tables mapping
pairs of a color index and a shade level (Duke3D's table uses 32 such
gradients) to a color index representing the darkness-faded color. Each such
table is called shade or _palookup_ table.
**********
latexmath:[$\mathrm{ShadeLevel} := \mathbb{N}_{\mathrm{Numshades}}$] +
latexmath:[$\mathrm{palookup}: \: \mathrm{ShadeLevel} \times  \mathrm{ColorIndex} \rightarrow \mathrm{ColorIndex}$]
**********

When a pixel is about to be drawn, a palookup table chosen depending on the
object's pal is consulted to determine its ultimate color index (in the
absence of blending with the translucency table or see-through texels). Given a
texel's color index as latexmath:[$i_{\mathrm{in}}$], the resulting pixel's one
latexmath:[$i_{\mathrm{out}}$] is computed as

==========
latexmath:[$s_1 = \mathrm{shade} + C \cdot \mathrm{visdist}$] +
latexmath:[$s_2 = \mathrm{clamp}(s_1, \: 0, \: \mathrm{Numshades}-1)$] +
latexmath:[$\mathrm{shade_index} = \mathrm{round}(s_2)$] +
latexmath:[$i_{\mathrm{out}} = \mathrm{palookup}(\mathrm{shade_index}, i_{\mathrm{in}})$] {nbsp}
[gray]#// This is only a table lookup, palookup[shade_index][latexmath:[$i_{\mathrm{in}}$]]# +
==========

Here, latexmath:[$C$] is a positive constant and
latexmath:[$\mathrm{visdist}$] is the product of a. the distance of an object's
sampled pixel to the view plane with b. the object's
visibility''.footnote:[Visibility would be more appropriately called
anti-visibility'' or co-visibility'': greater values make objects appear
more faded for the same distance. Also, the visibility that is meant here has
the origin at 0, unlike sector[].visibility.] Thus, shade and visibility are
inherently confounded in the 8-bit mode and the ultimate shade_index is bounded
below by (the minimum of latexmath:[$\mathrm{Numshades}-1$] and) the shade of
the object.

===== Examples of effects using shade tables

While palookup tables are primarily used for shading and visibility
attenuation, they can be set up in other ways to yield different effects with
respect to how pixels of objects farther away are drawn. For example:

* Distance fading with fog. For a fog color latexmath:[$\mathbf{c} = (c_r, c_g,  c_b)$], the table is set up so that for a source color index latexmath:[$i$]
  and a shade level sh, palookup[sh][latexmath:[$i$]] contains a color index
  whose color is close to that of latexmath:[$i$] blended with
  latexmath:[$\mathbf{c}$], +
  +
  {nbsp} latexmath:[$\frac{\mathrm{sh} + 0.5}{\mathrm{Numshades}} \cdot  \mathrm{basepal}(i) +  \frac{\mathrm{Numshades}-\mathrm{sh}+0.5}{\mathrm{Numshades}} \cdot  \mathbf{c}$]. +
  +
  Note that distance fading to black can be seen as a special case of this
  fogging effect. However, Duke3D's base shade table (i.e. the table for pal
  0) is *not* constructed in this way.

* Color index remapping. Given a mapping latexmath:[$m: \: \mathrm{ColorIndex}  \rightarrow \mathrm{ColorIndex}$], the table is set up so that for each shade
  level sh, the 256 color indices are selected or reordered in the same way:
  for all color indices latexmath:[$i$],
  palookup[sh][latexmath:[$i$]]{nbsp}={nbsp}original_palookup[sh][latexmath:[$m(i)$]]. +
  For example, pal 21 remaps the fifth and sixth blocks of consecutive
  16-tuples of color indices (a ramp of blue colors) to the fourth and 14^th^
  such blocks (red colors, the first one part of a 32-color ramp).

* Fullbright'' colors -- those that aren't affected by distance -- with index
  latexmath:[$i$] are achieved by setting palookup[sh][latexmath:[$i$]] to
  palookup[0][latexmath:[$i$]] for each shade sh.

===== Shade table functions

sht = engine.shadetab()::

Creates and returns a new shade table object sht with all entries initialized
to zero. This object can be indexed once with a shade index from 0 to 31,
yielding a reference to an array of 256 8-bit unsigned integers. Thus, shade
table objects can be used just as indicated in the notation above: sht[sh][i]
is the resulting color index for shade sh and input color index i.

sht = engine.getshadetab(palnum)::

Returns a new shade table object sht containing the values for the palookup
table of pal palnum, provided it is not an alias for the default one (see
below). Modifying the returned sht does not alter the actual engine-side
shade table. An unspecified number of pal indices are reserved from the end of
the hard limit 255; attempting to retrieve a shade table for a reserved pal
raises as error.
+
At engine initialization, the shade tables for all non-zero pal numbers are
aliased to the default pal 0 one. Subsequently, custom palookup tables are
either loaded from LOOKUP.DAT, created by appropriate DEF directives (fogpal
or makepalookup), or assigned using engine.setshadetab. If the table for
pal palnum is aliased to the default one when getshadetab is called, *nil*
is returned.

[[engine_setshadetab]] engine.setshadetab(palnum, sht)::

Copies the shade table sht to the engine-side palookup table for pal
palnum. An error is issued if an attempt is made to copy to a reserved
palnum.
+
When running in EDuke32, there are additional restrictions:
+
* A palnum for which a shade table has already been registered (that is, one
  which is *not* aliased to the default one) cannot be re-assigned to.
+
* setshadetab may only be called at first initialization time, that is, when
  the value of LUNATIC_FIRST_TIME is *true*. (LUNATIC_FIRST_TIME is a
  variable in the global environment that indicates whether the Lua game state
  is created for the very first time and the game is not yet running.)

===== Shade table methods

newsht = sht:remap16(tab)::

Returns a new shade table with consecutive runs of 16 values of every 256-tuple
of sht remapped as specified by tab. Specifically, tab must be a table
whose keys in [0 .. 15] may be set to values in [0 .. 15]. For a shade index
sh and a color index i, the returned shade table newsht then has
+
==========
newsht[sh][i] = sht[sh][newi],
==========
+
where
+
==========
newi = 16*tab[math.floor(i/16)] + i%16 {nbsp} [gray]#// if tab[math.floor(i/16)] is non-*nil*# +
newi = i {nbsp} [gray]#// otherwise#
==========
+
.Example
[source]
----------
-- Creates a shade table with the same remapping as pal 21 (blue -> red) and
-- registers it under pal 22, overwriting its previous contents.
local newsht = engine.getshadetab(0):remap16({[4]=13, [5]=8})
engine.setshadetab(22, newsht)
----------

[[blending_table_interfaces]]
Blending table interfaces
^^^^^^^^^^^^^^^^^^^^^^^^^

EDuke32 supports installing multiple blending tables used by the 8-bit
renderer. A blending (or translucency) table is used whenever an object with
the translucent'' bit set is drawn, and maps pairs of color indices to a
blended color index.
**********
latexmath:[$\mathrm{transluc}: \: \mathrm{ColorIndex} \times  \mathrm{ColorIndex} \rightarrow \mathrm{ColorIndex}$]
**********

Given a background color index bi and a color index of an incoming foreground
fragment fi (usually obtained by looking up a shade table), when fi is
different from 255, the resulting color index is
==========
transluc[bi][fi]
==========
if the reverse translucency'' bit is clear, and
==========
transluc[fi][bi]
==========
if reverse tranlucency is set. If the fragment sampled from the foreground
object has color index 255, it is discarded: translucent rendering is always
masking''.

Currently, only sprites support rendering with custom blending tables, by
setting their .blend member to the number of a blending table.


===== Blending table functions

tab = engine.blendtab()::

Creates and returns a new blending table object tab with all entries initialized
to zero. This object can be indexed once with a color index from 0 to 255,
yielding a reference to an array of 256 8-bit unsigned integers. Thus, blending
table objects can be used just as indicated in the notation above: tab[i][j]
is the blended color index for input color indices i and j.

tab = engine.getblendtab(blendnum)::

Returns a new blending table object tab containing the values for the
engine-side translucency table numbered blendnum, or *nil* if no blending
table with that number is registered. Modifying the returned tab does not
alter the actual engine-side blending table.
//+
//At engine initialization, the default translucency table (with number 0) is
//loaded from PALETTE.DAT.

engine.setblendtab(blendnum, tab)::

Copies the blending table tab to the engine-side translucency table with
number blendnum.
+
Similar to <<engine_setshadetab,engine.setshadetab>>, there are certain
restrictions when running in EDuke32:
+
* A blendnum for which a table has already been registered cannot be
  re-assigned to.
+
* setblendtab may only be called at first initialization time, that is, when
  the value of LUNATIC_FIRST_TIME is *true*.

Mapster32-only functions
^^^^^^^^^^^^^^^^^^^^^^^^

===== engine.savePaletteDat(filename [, palnum [, blendnum [, moreblends]]]) -> ok, errmsg

Writes out a full PALETTE.DAT-formatted file named filename with the base
shade table numbered palnum and the base translucency table numbered
blendnum, both defaulting to 0.

Passing moreblends allows to specify additional blending tables to store in
EDuke32's extended PALETTE.DAT format. These must have previously been
registered with engine.setblendtab. The moreblends argument must be a
sequence table with each element being either

* a blending table number in the range [1{nbsp}..{nbsp}255]
* a table t containing a pair of such numbers, in which case it is taken to
  mean the inclusive range [t[1]{nbsp}..{nbsp}t[2]]

There must be no duplicate blending table numbers.

The function returns a status ok which is *true* on success and *nil* on
failure. In the latter case, errmsg is a diagnostic error message.

===== engine.saveLookupDat(filename, lookups) -> ok, errmsg

Writes out a LOOKUP.DAT-formatted file named filename with the lookup tables
specified by lookups at the beginning and the five additional base palettes
at the end.

The lookups argument is interpreted analogously to the moreblends argument
of engine.savePaletteDat (with the numbers being palookup numbers instead of
blending table numbers) and the return values ok and errmsg have the same
meaning as well.


The fs module -- virtual file system facilities
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[float]
==== files = fs.listpath(path, mask)

Returns a sequence table files of file names that can be found in a directory
constructed as concatenation of any directory in the search path with path,
and matching the wildcard mask. Currently, neither ZIP nor GRP files
registered as file containers with EDuke32 are searched.

The path argument must separate directories by forward slashes (/). If no
suffix is desired (i.e. the directories in the search path themselves are to be
searched), '/' should be passed.

The file name mask is applied case-insensitively for the 26 characters of the
basic Latin alphabet. It may contain the following meta-characters which are
interpreted in a special way:

* a * matches any (potentially empty) sequence of characters
* a ? matches any single character

While the match with mask proceeds case-insensitively, file names are
returned named exactly like on the file system. However, names differing only
in case appear exactly once in the output list.

NOTE: For portability, it is crucial that path is specified with the same
case as the actual directory on the file system.

.Example

Suppose the search path contains two directories foo and bar with the
following file listing:
----------
foo/
  myhouse1.MAP
  myhouse2.map

bar/
  MYHOUSE1.map
  MYHOUSE10.MAP
  README.txt
----------

Then a query with
[source]
----------
fs.listpath("/", "myhouse?.map")
----------
will return a table with
these strings:

* myhouse1.MAP or MYHOUSE1.map, but not both
* myhouse2.map


/////////////////
APPENDICES FOLLOW
/////////////////

:numbered!:

[appendix]
[[Appendix_Howto_read_PIL]]
How to read _Programming in Lua_
--------------------------------

:PiL50: http://www.lua.org/pil/contents.html

On the Lua homepage, the first edition of _Programming in Lua_ is
{PiL50}[available] online. While targeting Lua 5.0, it still remains applicable
to Lua 5.1 to a large extent. This section gives hints for reading it when
learning to code for Lunatic.

[float]
==== http://www.lua.org/pil/p1.html[Preface]

May be interesting to get an idea of the philosophy behind Lua.
http://www.lua.org/pil/p1.3.html[A Few Typographical Conventions] should be
read to be familiar with them.

[float]
==== http://www.lua.org/pil/1.html[1 -- Getting Started]

Mentions the stand-alone Lua interpreter. When none is available, a LuaJIT
stand-alone binary can be used for experimentation as well.

[float]
==== http://www.lua.org/pil/1.1.html[1.1 -- Chunks]

Introduces chunks as the basic blocks'' of Lua code and notes how whitespace
is treated. Mentions dofile, which is not available in Lunatic
(<<require,require>> is preferred).

[float]
==== http://www.lua.org/pil/1.2.html[1.2 -- Global Variables]

Section may be read, but usage of *local* variables is strongly recommended
whenever possible. Also, trying to read a non-existent global or to write any
value to the global environment gives an error in Lunatic (except that global
writes are allowed in in <<modules,module>> context, i.e. after module(...)).

[float]
==== http://www.lua.org/pil/1.3.html[_1.3 -- Some Lexical Conventions_]

Must read.

[float]
==== http://www.lua.org/pil/2.html[_2 -- Types and Values_]

Must read, also subsections. However, 2.7 -- Userdata and Threads'' is
not relevant.

[float]
==== http://www.lua.org/pil/3.html[_3 -- Expressions_]

Must read, also all subsections.

[float]
==== http://www.lua.org/pil/4.html[_4 -- Statements_]

Must read, also all subsections.

[float]
==== http://www.lua.org/pil/5.htmlhttp://www.lua.org/pil/5.html[_5 -- Functions_]

Must read, also all subsections. Subsection 5.2 mentions io.write, which is
not available in Lunatic.

[float]
==== http://www.lua.org/pil/6.html[6 -- More about Functions]

May be read (subsections as well) for a more complete understanding of
functions in Lua, as well as the utility of lexical scoping.

[float]
==== http://www.lua.org/pil/7.html[_7 -- Iterators and the Generic_ for]

May be read (subsections as well), but for basic programming, the knowledge of
how to merely use (as opposed to write) iterators such as
<<engine_iterators,spritesofsect>> suffices.

[float]
==== http://www.lua.org/pil/8.3.html[8.3 -- Errors]

May be read. Provides guidelines on how to write error handling (status code
vs. error).

[float]
==== http://www.lua.org/pil/8.4.html[8.4 -- Error Handling and Exceptions]

May be read. Discusses protected calls, which should be used sparingly.

[float]
==== http://www.lua.org/pil/11.html[_11 -- Data Structures_]

May be read, also subsections. The most relevant subsections are
http://www.lua.org/pil/11.1.html[11.1 -- Arrays],
http://www.lua.org/pil/11.5.html[11.5 -- Sets and Bags] and to some extent,
http://www.lua.org/pil/11.6.html[11.6 -- String Buffers]. The way 11.2 --
Matrices and Multi-Dimensional Arrays'' suggests to construct matrices is
rather memory-intensive; also it and 11.3 -- Linked Lists'' and 11.4 --
Queues and Double Queues'' are not relevant to simple Lunatic coding.

[float]
==== http://www.lua.org/pil/15.html[15 -- Packages]

Lua package system received various additions in 5.1, so the PiL first
edition's section is out-of-sync. For Lunatic, the <<modules,modules>> section
of this manual should be consulted.
 +
 +
(The rest of Part II deals with advanced concepts not needed for simple Lunatic
coding.)

[float]
==== http://www.lua.org/pil/19.3.html[19.3 -- Sort]

May be read if needed.

[float]
==== http://www.lua.org/pil/20.html[20 -- The String Library]

May be skimmed (also subsections), though ultimately the Lua Reference should
be consulted for the exact semantics.

[appendix]
[[Appendix_event_RETURN]]
Game event RETURN usage
-------------------------

The following list notes how the special <<gv_RETURN,gv.RETURN>> variable
(known simply as RETURN from CON) is treated for the various events. The game
may either pass some value to a particular event as additional information, or
it can examine RETURN after the event has finished, invoking some behavior
conditional on its value. If an event is not listed here, its usage of RETURN
is unspecified.

[float]
Receives zero, checks for non-zero
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

These events get passed a value of 0 for RETURN, and after finishing, check
it for being non-zero, in which case some hard-coded behavior is suppressed:

AIMDOWN, AIMUP, CROUCH, DISPLAYSBAR, DISPLAYWEAPON, DOFIRE,
DRAWWEAPON, FIRE, HOLODUKEOFF, HOLODUKEON, HOLSTER, INCURDAMAGE,
INVENTORY, JUMP, LOOKDOWN, LOOKLEFT, LOOKRIGHT, LOOKUP,
QUICKKICK, RETURNTOCENTER, SOARDOWN, SOARUP, SWIMDOWN, SWIMUP,
TURNAROUND, USEJETPACK, USEMEDKIT, USENIGHTVISION, USESTEROIDS.

KILLIT (deprecated from Lua)::
    If non-zero, the pending sprite deletion is aborted.

DISPLAYROOMS::
    Don't draw scene if RETURN is 1. Values other than 0 and 1 are
    reserved.

PRESSEDFIRE, USE::
    If non-zero, the fire'' or use'' shared key bits are cleared
    (respectively).

[float]
Game considers post-event RETURN an index
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

For some events, the game examines RETURN after they have finished, and
potentially uses its value as some kind of index.

CHANGEMENU (deprecated from Lua)::
    Receives and examines RETURN as a menu index to change to.

DISPLAYCROSSHAIR::
    Receives 0. If the post-event RETURN equals 1, no crosshair is drawn. If
    it is greater than one, RETURN is the tile index of the crosshair to be
    displayed. The value 0 makes it draw using the CROSSHAIR tile.

GETLOADTILE::
    Receives and examines RETURN as a background tile for the loading screen.
    A negative value suppresses drawing it and running the subsequent
    EVENT_DISPLAYLOADINGSCREEN entirely.

GETMENUTILE::
    Receives and examines RETURN as a background tile for the menu.

SOUND::
    Receives and examines RETURN as an index of a sound to start playing.

[float]
Cheat events
~~~~~~~~~~~~
The cheat events receive a hard-coded, item-dependent target amount in
RETURN. It can be overridden to a different value to make the respective
cheat give a different full'' amount. A negative value is ignored.

CHEATGETSTEROIDS, CHEATGETHEAT, CHEATGETBOOT, CHEATGETSHIELD,
CHEATGETSCUBA, CHEATGETHOLODUKE, CHEATGETJETPACK, CHEATGETFIRSTAID.

[float]
EVENT_DAMAGEHPLANE
~~~~~~~~~~~~~~~~~~~~

Triggered when a ceiling or a floor (collectively called hplane'') is
determined as being damaged. The event receives RETURN in the variable
gv.RETURN as well as the third, dist argument to the event
<<gameactor,callback function>>.footnote:[Passing RETURN in the dist
argument serves the possibility to create chained callbacks for
EVENT_DAMAGEHPLANE. Otherwise, once gv.RETURN were assigned to, there would
be no way to obtain its original value in subsequent chained callbacks.] This
value can be decoded into two parts by passing it to
sector.damagehplane_whatsect:

[source]
----------
function(aci, pli, RETURN)
   local what, sectnum = sector.damagehplane_whatsect(RETURN)
   -- (...)
----------
Then,

* what is one of the strings 'ceiling' or 'floor' and
* sectnum is the sector whose hplane is considered to be damaged.

When EVENT_DAMAGEHPLANE is left, gv.RETURN is examined to determine the
further action. It may be one of three values given by sector.DAMAGEHPLANE
(abbreviated DHP in the following):

* DHP.SUPPRESS: the hard-wired code that would subsequently be run is
  suppressed entirely

* DHP.DEFAULT: The default code for hplane damaging is run. For floors, it
  does nothing. For ceilings, it checks whether it has a tile number in a
  hard-coded set of values depicting a breakable light. In that case, the tile
  number is changed to the broken'' version and a glass breaking'' effect
  consisting of playing a sound and spawning glass sprites is started. Also,
  certain code related to SE3 and SE12 effects is run.

* DHP.GLASSBREAK: The light-breaking effect described above is run
  unconditionally, but *without* changing the hplane's tile number, which is
  assumed to have been done by the event.

If value last assigned to RETURN is not one in the above-mentioned set when
EVENT_DAMAGEHPLANE is left, the behavior is undefined.


[float]
TODO
~~~~
CHANGEWEAPON, CHECKFLOORDAMAGE, CHECKTOUCHDAMAGE, NEXTWEAPON,
PREVIOUSWEAPON, SELECTWEAPON, WEAPKEY*.