Import some documentation from the old wiki. Adjust formatting.

Still loads to do in terms of fixing the old links.

Documentation/Classes.md

@@ -16,6 +16,7 @@ If you desire additional functionality please reach out.
 These are the entity classes that you're generally encouraged to inherit to create your game:
 
 ### General purpose
+
 Most map entities will be based off one of these. The difference can be felt in memory usage, networking and rendering speed. So if you wanted only basic entity logic without any fancy rendering or concept of hit detection an NSEntity may be enough.
 However, if you want advanced rendering features, such as adjustable color, transparency and various other special effects you might want to start off with the NSRenderableEntity class as the basis for your entity.
 
@@ -25,6 +26,7 @@ However, if you want advanced rendering features, such as adjustable color, tran
 - NSPhysicsEntity
 
 ### Trigger templates
+
 These are templates for the two trigger types we currently support.
 Check their respective Init methods to initialize them properly.
 
@@ -32,7 +34,9 @@ Check their respective Init methods to initialize them properly.
 - NSPointTrigger
 
 ### NPCs/Monster/AI
+
 Currently there's two types of monsters. The primitive ones that may move around and the more advanced talking ones.
+
 - NSMonster
 - NSTalkMonster
 
@@ -41,16 +45,20 @@ Currently there's two types of monsters. The primitive ones that may move around
 Anything that doesn't specifically have to do with entities.
 
 ### Clients/Players
+
 You are generally expected to implement a class named `player` in your game.
 In most cases you will just want to inherit NSClientPlayer for that class.
 
 - NSClientPlayer
 
 ### Rules
+
 Depending on the gamemode set by you in the server's Game_InitRules function, it should spawn a variant of NSGameRules and set the global `g_grMode` reference to that class you've initialized.
 
 - NSGameRules
 
 ### Inventory
+
 This needs to be completed.
+
 - NSWeapon (incomplete)

Documentation/Contributing.md

@@ -8,13 +8,15 @@ There's just 2 very short requirements.
 The code must be yours.
 
 It's simple:
+
 - Do not take code that is by anyone else that is not you.
 
 
 ## Rule #2
+
 No submission or decompilation of third-party code. This is important if you want to recreate behaviour from another game.
 
-- We do not decompile - we reverse-engineer by trial and error.
+- We do not decompile. We reverse-engineer by trial and error.
 
 This is generally referred to as 'clean-room engineering'.
 Most of the behaviour is rather predictable, other is not.
@@ -23,6 +25,7 @@ This is why some of the parts of Nuclide, which emulate entities/frameworks
 from other games may feel a bit off. It's because it's all implemented by eye.
 
 # Other notes
+
 Game specific features need to be put into game-specific directories.
 
 Unless other games benefit from this, keep it seperate to one of the game
@@ -31,6 +34,7 @@ sub-directories. This usually means it'll be part of another git repository too.
 That's about it!
 
 # Saying Thanks
+
 If you want to solely say thanks, the main developer of Nuclide **loves** receiving E-Mail. You can contact him at <mailto:marco@vera-visions.com> and let him know your thoughts.
 
 If you'd like to donate to him via [PayPal](https://paypal.me/eukara) or [Patreon](https://www.patreon.com/eukara) you can do that too. That money pays for a lot of free services he provides that come with both [FTEQW](https://www.fteqw.org/) and **Nuclide**.

Documentation/Filesystem.md

@@ -12,6 +12,7 @@ is a manifest file the engine reads. It is updated occasionally.
 
 It defines which directories to mount in the virtual filesystem of the engine
 and has a document entirely dedicated to itself. For that please read:
+
 ```
 	src/engine/specs/fte_manifests.txt
 ```
@@ -19,6 +20,7 @@ and has a document entirely dedicated to itself. For that please read:
 ## Loading Games
 
 On its own, Nuclide launches the game directory `base/`, unless you tell it otherwise:
+
 ```
 ./nuclide -game mygame
 ```
@@ -64,6 +66,7 @@ It's advised that you do not pack **csprogs.dat** and **progs.dat** into a prote
 
 
 ## Nuclide specific formats
+
 Nuclide contains many custom definition files that are not engine specific.
 `.efx`, `.font`, `.sndshd` and `.way` to name a few.
 The game-logic mostly handles them and can thus be, in theory, extended by you.

Documentation/Launching.md

@@ -1,6 +1,7 @@
 # Launching
 
 ## For development...
+
 For development, use the `nuclide` launch script inside the root directory.
 
 ```

Documentation/Materials/MatCommands.md

@@ -1,4 +1,4 @@
 # Materials: Commands {#mat_commands}
 
 These are all the important material commands that affect the renderer in some shape or form.
-[For material commands that affect the compiling process, look over here.](MatVMap.md)
+[For material commands that affect the compiling process, look over here.](Documentation/Materials/MatVMap.md)

Documentation/Materials/MatGoldSrc.md

@@ -225,8 +225,6 @@ The **Material ID** is used via the `gamematerial` command inside **scripts/surf
 
 Be aware that a Source engine game may actually have more surface materials than this, these are *solely the IDs associated with impact effects*.
 
-In Nuclide, 
-
 ### Alien Swarm
 
 | Material ID       | Material Name       |

Documentation/Materials/MatShaders.md

@@ -1,12 +1,14 @@
 # Materials: Shaders
+
 Shaders are referring to GPU-oriented pieces of a program, performing shading and rendering related functions instead of letting the engine handle it. 
 
-In **FTEQW** you can specify a custom GLSL or HLSL shader using the [program](MatCommands.md) command inside a [Material](MatOverview.md).
+In **FTEQW** you can specify a custom GLSL or HLSL shader using the [program](Documentation/Materials/commands/program.md) command inside a [Material](Documentation/Materials/MatOverview.md).
 
 ## Example Shader
+
 This is a primitive shader file. It includes the vertex and fragment program.
 
-It will respond to the [diffusemap](MatCommands.md) only, which is loaded
+It will respond to the [diffusemap](Documentation/Materials/commands/diffusemap.md) only, which is loaded
 into the **d_f** variable. It can be modified from that point onwards.
 The commented out line will turn all of the output red.
 
@@ -46,7 +48,8 @@ void main ()
 ```
 
 ## Dissecting GLSL shaders
-When we pass `program <shadername>` in our [Material](MatOverview.md), the engine will load `glsl/<shadername>.glsl` to handle the material for us.
+
+When we pass `program <shadername>` in our Material, the engine will load `glsl/<shadername>.glsl` to handle the material for us.
 
 The shader in question needs to define a `main` function for both a vertex and a fragment shader. That's what the **ifdef**s are for in the above example.
 

Documentation/Particles.md

@@ -0,0 +1,531 @@
+# Particles
+
+**Particles**, part of a particle system, are sprites/models in 3D space
+that simulate impacts and other chemical reactions. They can be used for
+a variety of use cases - most commonly they're used for explosions,
+bullet impacts and smoke.
+
+The particle system in **FTEQW** is quite advanced with its
+use of a plaintext scripting format.
+
+Particles can be stored inside the default.cfg file of a game/mod, or
+into its own **./particles/default.cfg** file when the
+console variable **r_particledescr* is set to its
+default value and the console variable **r_particlesystem*
+is left to the default value **"script"**.
+
+## Syntax {#syntax}
+
+Particles are similar to **Materials** in the way
+they are written. However they can be injected into any config file and
+have a completely different set of commands.
+
+```
+r_part blah {
+texture textures/particles/myimage.tga
+tcoords 0 0 64 64 64
+die 2
+scalefactor 1
+scale 20
+alpha 0.5
+rgb 255 0 0
+rgbdelta 0 128 128
+spawnmode ball
+spawnorg 32
+}
+```
+
+The above example will give transparent (0.5) red particles that will
+fade to fully white when they go fully transparent 2 seconds later. They
+will spawn within a ball of 32 units radius.
+
+## Commands {#commands}
+
+Types: Always try to include a type. The engine will guess what your
+particle is meant to be otherwise, based on textures and other nonsense.
+That stuff is generally unreliable, and probably not what you want.
+
+Chaining: You can add multiple particle descriptions to a single effect.
+The first should be 'r_part foo', and the others should be 'r_part
++foo'. Particles without a + will reset the chain.
+
+Effect naming: Effects loaded by r_particledesc will be given an
+internal prefix, eg: foo.cfg. If the gamecode explicitly states foo.bar,
+your foo.cfg will automatically be executed, and will automatically use
+the bar effect from it. The effect can still be overriden from a custom
+config by explicitly naming the effect foo.bar - the effect bar in the
+config foo will not override this, but would override bar on its own.
+
+Scale: scale values are defined in 1/4th qu, for some reason.
+scalefactor typically needs to be explicitly set to 1. this value
+affects how the particle scales with distance from view, rather than the
+actual size of the particle.
+
+### texture <TEXTURENAME> {#texture}
+
+`   specifies to use an image named TEXTURENAME for this effect.`
+
+### shader \[shadername\] \[\n{\nshaderbody\n}\n\] {#shader_shadername_nnshaderbodynn}
+
+`   Specifies to use a named shader.`
+`   If shaderbody is included (as a nested block on the following line) then that shader text will be used to create the shader if it doesn't otherwise exist.`
+`   This overrides blendmodes, as no default shader will need to be created.`
+
+### tcoords <s1> <t1> <s2> <t2> \[tscale\] \[rsmax\] \[rsstep\] {#tcoords_tscale_rsmax_rsstep}
+
+`   specifies to use a subsection of the image.`
+`   if tscale is set, all units are divided by this. it is the virtual size of your texture. So a value of 1 means that your texture coords must be between 0 and 1. But if it properly matches your texture's size, the coords are in pixels.`
+`   if rsmax is present, each particle will use a random image. These images must be on a single row in your particle font.`
+`   rsstep specifies the stride (gap from one to the next) in your particle font, and is only needed if rsmax is present and greater than 1.`
+
+### atlas count_in_each_axis firstidx \[last\] {#atlas_count_in_each_axis_firstidx_last}
+
+`   An alternative to tcoords.`
+`   The specified texture (or shader) is to be considered as a grid of sprites (x*x, where x is specified in that first arg).`
+`   firstidx specifies the first image to use (horizontal THEN vertical).`
+`   last specifies the last image to use (inclusive). The engine will pick one at random. They should not span multiple rows.`
+
+### rotation <startmin> <startmax> <speedmin> <speedmax> {#rotation}
+
+`   the particle will start with a rotation rotated between startmin and startmax.`
+`   It will then rotate with some per-particle value randomly picked between the speedmin+speedmax values.`
+`   Should NOT be used on beam particles.`
+
+### beamtexstep <value> {#beamtexstep}
+
+`   only valid if the effect is a beam.`
+`   specifies the number of quake units per beam texture repitition.`
+
+### beamtexspeed <value> {#beamtexspeed}
+
+`   only valid if the effect is a beam.`
+`   controls how fast the texture scrolls on the beam.`
+
+### scale <min> \[max\] {#scale_max}
+
+`   particles will start with a diameter of this many quake units.`
+`   actual scale will be randomly chosen between min and max (max defaults to equal if min is missing)`
+
+### scalefactor <frac> {#scalefactor}
+
+`   controls how the particle scales with distance.`
+`   1 makes the particle scale the same as anything else`
+`   0 makes the particle not change size no matter how far it is`
+
+### stretchfactor <factor> {#stretchfactor}
+
+`   controls how spark particles stretch according to their velocity.`
+`   negative values give fixed length sparks.`
+
+### scaledelta <value> {#scaledelta}
+
+`   controls how the particle scales over time`
+`   specifies the change in the particle scale per second.`
+`   Due to technical reasons, any decal types are unable to use this parameter.`
+
+### step <min> <max> {#step}
+
+`   trails/beams only`
+`   specifies the distance between each particle in the trail (or beam).`
+
+### count <min> <max> {#count}
+
+`   point/box effects only (not trails or beams)`
+`   specifies how many particles are spawned per effect (some classic effects contain an extra scaler which is multiplied by the resulting value)`
+
+### alpha <value> {#alpha}
+
+`   specifies the initial alpha value of the effect`
+
+### alpharand <value> {#alpharand}
+
+`   specifies a randomized additonal value added to each particle's initial alpha.`
+
+### alphadelta <value> {#alphadelta}
+
+`   specifies how much the alpha value of the effect changes per second (subtracted)`
+
+### die <maximum age> <minimum age> {#die}
+
+`   specifies the maximum age of the particle`
+
+### randomvel <horiz> \[vert\] {#randomvel_vert}
+
+`   controls how fast the particle moves when it spawns (according to its spawn pattern). This works regardless of any requested velocities.`
+`   if vert is not specified, horiz is used instead.`
+
+### veladd <value> {#veladd}
+
+`   controls how much of the effect's spawn velocity is used, can be greater than 1, or negative.`
+
+### orgadd <value> {#orgadd}
+
+`   biases how much to add to the starting origin relative to the requested velocity.`
+
+### orgbias <x> <y> <z> {#orgbias}
+
+`   biases the particle's origin by this absolute worldspace vector, regardless of spawn mode.`
+
+### velbias <x> <y> <z> {#velbias}
+
+`   biases the particle's velocity by this absolute worldspace vector, regardless of spawn mode.`
+
+### orgwrand <x> <y> <z> {#orgwrand}
+
+`   randomised offset for the particle's origin, in worldspace.`
+
+### velwrand <x> <y> <z> {#velwrand}
+
+`   randomised offset for the particle's origin, in worldspace.`
+
+### friction &lt;<xyz>\|<xy> <z> \| <x> <y> <z>&gt; {#friction}
+
+`   Proportion of the particle's speed that should be lost from friction. Negative values are accepted.`
+
+### gravity <value> {#gravity}
+
+`   amount that the particle's velocity changes per second, in quake units.`
+
+### clipbounce <value> {#clipbounce}
+
+`   how much of the particle's velocity to use if the particle is clipped. See cliptype.`
+`   Defaults to 0.8`
+
+### cliptype <effectname> {#cliptype}
+
+`   Specifies which new effect to spawn when the particle hits something.`
+`   The origin and velocity of the particle are used to spawn the new effect.`
+`   The clipbounce value is used as a scaler for the reflected velocity.`
+`   If the effect named is the effect itself, the particle will merely bounce, instead of spawning a new effect.`
+`   FIXME: make default to bounce if clipbounce is set without cliptype.`
+
+### clipcount <count> {#clipcount}
+
+`   The scaler to use for the number of particles to spawn upon a clip event.`
+`   Only valid in conjunction with cliptype.`
+
+### assoc <effectname> {#assoc}
+
+`   Specifies another effect to spawn at the same time that this effect is spawned.`
+`   Thus allowing two sets of particles from one effect.`
+
+### notunderwater \[content names\] {#notunderwater_content_names}
+
+`   Specifies that this particle should ONLY be spawned when out of water.`
+`   The particle will not spawn under water (this does not affect assoc chains).`
+`   Content names are a space-separated list of: water slime lava sky solid fluid. Default is fluid if not specified.`
+`   The r_part_contentswitch cvar must be enabled for this to function correctly.`
+
+### underwater \[content names\] {#underwater_content_names}
+
+`   Specifies that this particle should ONLY be spawned when underwater.`
+`   The particle will not spawn if the spawn position is non-water (this does not affect assoc chains).`
+
+### citracer {#citracer}
+
+`   only valid if colorindex is set.`
+`   adds a palette index between 0 and 3, based on the particle index in the effect or trail.`
+
+### red <value> {#red}
+
+### green <value> {#green}
+
+### blue <value> {#blue}
+
+### rgb <red> <green> <blue> {#rgb}
+
+### rgb <value> {#rgb_1}
+
+### rgbf <red> <green> <blue> {#rgbf}
+
+`   Specifies the initial red, green, and/or blue values for each particle.`
+`   Fully opaque is 255 or above.`
+`   Values above 255 are valid, but will remain opaque until the value drops below 255 from the `
+
+colour deltas.
+
+`   The rgbf form takes values scaled by 1 instead of 255.`
+
+### redrand <value> {#redrand}
+
+### greenrand <value> {#greenrand}
+
+### bluerand <value> {#bluerand}
+
+### rgbrand <red> <green> <blue> {#rgbrand}
+
+### rgbrand <value> {#rgbrand_1}
+
+### rgbrandf <red> <green> <blue> {#rgbrandf}
+
+`   Specifies how much extra red, green, and/or blue there may be for particles.`
+`   The initial colour will be multiplied by this amount before addition.`
+`   Each componant is separately randomized. EG, red might  add nothing, while the full green is added, and only half the blue.`
+`   Fully opaque is 255 or above.`
+`   The rgbrandf form takes values scaled by 1 instead of 255.`
+
+### redrandsync <value> {#redrandsync}
+
+### greenrandsync <value> {#greenrandsync}
+
+### bluerandsync <value> {#bluerandsync}
+
+### rgbrandsync <red> <green> <blue> {#rgbrandsync}
+
+### rgbrandsync <value> {#rgbrandsync_1}
+
+`   Specifies how much extra red, green, and/or blue there may be for particles.`
+`   The initial colour will be multiplied by this amount before addition.`
+`   Componants are syncronised. EG, if the full amount of red is added, the full amount of green and blue will also be added.`
+`   Fully opaque is 255 or above.`
+
+### reddelta <value> {#reddelta}
+
+### greendelta <value> {#greendelta}
+
+### bluedelta <value> {#bluedelta}
+
+### rgbdelta <red> <green> <blue> {#rgbdelta}
+
+### rgbdelta <value> {#rgbdelta_1}
+
+### rgbdeltaf <red> <green> <blue> {#rgbdeltaf}
+
+`   Specifies how much the red, green, and/or blue values of each particle change over time.`
+`   The value 255 is the value required to go from opaque to invisible in 1 second.`
+
+### rgbdeltatime <value> {#rgbdeltatime}
+
+`   Specifies for how long the particle may change colours for. After this many seconds, the particle may no longer change colours (delta becomes 0).`
+
+### rampmode <mode> {#rampmode}
+
+`   mode may be one of:`
+`   none: uses rgb+rand+sync+delta+scale+scaledelta values.`
+`   nearest(or absolute): the ramp overrides all colour+scale values. The effect moves from one absolute ramp index to the next.`
+`   lerp: smoothly interpolates from one value to the next.`
+`   delta: uses rgb+rand+sync+scale, but not delta values. All delta values come from the colour ramp instead.`
+
+`   if not none, the ramp index used is based upon the particle's age, its lifetime, and how many ramp elements there are.`
+
+### rampindexlist <idx1> \[<idx2> \[idx3 ...\]\] {#rampindexlist_idx3_...}
+
+`   Scale used is the currently set scale value.`
+`   Specifies a set of palette index values to use for the effect as part of the effect's colour ramp.`
+
+### rampindex <idx> <scale> {#rampindex}
+
+`   Specifies an individual palette index value and particle scale to use for the effect as part of the effect's colour ramp`
+
+### ramp <red> <green> <blue> \[alpha\] \[scale\] {#ramp_alpha_scale}
+
+`   Specifies a ramp index in rgb terms, regardless of palette.`
+
+### stains <value> {#stains}
+
+`   How much the effect discolours the wall upon impact.`
+`   The stained colour is based upon the colour of the particle upon impact.`
+
+### blend <mode> {#blend}
+
+`   If the texture used is actually a shader then that shader's blend mode will take precidence.`
+`   As a general rule you should try to use only the premul blend modes (as well as atlasing).`
+`   mode may be one of:`
+
+-   adda
+-   addc
+-   subtract
+-   invmoda
+-   invmodc
+-   blendcolour
+-   blendalpha
+-   premul_subtract
+-   premul_add
+-   premul_blend
+-   rtsmoke
+
+### spawnmode <mode> \[arg1\] \[arg2\] {#spawnmode_arg1_arg2}
+
+`   This affects how particles are positioned when they first spawn, and their initial velocities.`
+`   for point effects, mode may be one of:`
+`       box: simple axially aligned box of particles.`
+`       circle: particles spawn within a ball with uniform distance from the center. none will appear in the middle.`
+`           arg1: percentage of the circle to cover. a value of 5 will go around the circle 5 separate times. this can be used for weird beam effects.`
+`           areaspread: the radius of the ball`
+`           areaspreadvert: the height of the ball. if 0, will be a flat circle`
+`       ball: particles spawn randomly within a ball.`
+`           areaspread: the radius of the ball`
+`           areaspreadvert: the height of the ball. if 0, will be a flat circle.`
+`       telebox: matches quake's telebox`
+`       lavasplash: like chthon's lava splash`
+`       uniformcircle: particles are spawned in a circle with uniform distance between and from the center. z=0.`
+`       syncfield: particles spawn at predictable locations based upon time within a rough sphere. Only useful for effects that are regenerated+replaced every frame.`
+`       distball:`
+`       *default*: regular box. particles are spawned inside an axially aligned box.`
+
+`   for trail effects, mode may be one of:`
+`       spiral: particles are given velocities perpendicular to the direction based on the distance moved.`
+`       tracer: particles spawn with alternating horizontal velocities (a wake effect).`
+`       *default*: particles spawn as a regular trail.`
+
+### type <mode> {#type}
+
+`   How the particles look.`
+`   mode may be:`
+
+-   beam: valid only for trails. Particles form a single textured beam
+    acting as nodes along it.
+-   spark: particles are lines, their length depending upon their speed.
+-   sparkfan: particles are non-planar triangle fans, their length
+    depending upon their speed.
+-   texturedspark: textured particles are aligned along their direction
+    of movement, their length depending upon their speed, width equal to
+    their scale.
+-   cdecal/decal: particles are spawned only upon bsp geometry. They are
+    clipped by it.
+-   udecal: unclipped decal. exact semantics are subject to change.
+-   normal/\*default\*: Particles are regular, rotating, 2d images.
+
+### clippeddecal <mask> \[match\] {#clippeddecal_match}
+
+`   implies 'type decal'.`
+`   The two extra args allow you to spawn these decals ONLY on surfaces with matching surfaceflags.`
+`   Separation of mask+match allows you to create many descrete surface types instead of being limited to 32 bits/types.`
+
+### spawntime <value> {#spawntime}
+
+### spawnchance <value> {#spawnchance}
+
+### emit <effectname> {#emit}
+
+`   Specifies the effect to periodically emit.`
+
+### emitinterval <min> {#emitinterval}
+
+`   Particles will not emit additional effects for this duration after emitting one.`
+
+### emitintervalrand <extra> {#emitintervalrand}
+
+`   FIXME: fold into emitinterval`
+`   `
+
+### emitstart <seconds> {#emitstart}
+
+`   Prevents the particle from emitting anything for this duration when it first spawns.`
+
+### viewspace \[frac\] {#viewspace_frac}
+
+`   Specifies that this particle type should move relative to the camera.`
+`   Not compatible with splitscreen.`
+`   Should not normally be used in combination with clipping/bouncing.`
+
+### perframe {#perframe}
+
+`   apply inverse frametime to count (causes emits to be per frame).`
+
+### averageout {#averageout}
+
+`   average trail points from start to end, useful with t_lightning, etc`
+
+### nostate {#nostate}
+
+`   Causes the particle system to ignore all state information.`
+
+### nospreadfirst {#nospreadfirst}
+
+`   don't randomize org/vel for first generated particle`
+
+### nospreadlast {#nospreadlast}
+
+`   don't randomize org/vel for last generated particle`
+
+### sound <soundname> <vol> <attenuation> \[pitch\] \[delay\] {#sound_pitch_delay}
+
+`   When the effect is first spawned, the named sound will play with the given volume and attenuation at the center point. This may not work with all spawn methods, as it will ignore any count scales.`
+
+### lightradius <radius> {#lightradius}
+
+`   Spawns a dlight when the effect is spawned.`
+`   dlight is removed when radius drops to 0 or the age is exceeded.`
+`   at this time it is not possible to override the corona/specular levels.`
+
+### lightradiusfade <radiuspersecond> {#lightradiusfade}
+
+`   how fast the light radius shrinks per second`
+
+### lightrgb <r> <g> <b> {#lightrgb}
+
+`   dlight rgb colours. 1=white. higher values can over-saturate.`
+
+### lightrgbfade <r/s> <g/s> <b/s> {#lightrgbfade}
+
+`   how fast lightrgb changes over time.`
+
+### lighttime <maxage> {#lighttime}
+
+`   Specifies the maximum lifetime of your dlight.`
+
+### lightcubemap <cubemapnum> {#lightcubemap}
+
+`   value 0 means no cubemap.`
+`   otherwise with eg cubemap 5, uses image files cubemaps/5ft.tga, cubemaps/5bk.tga, etc.`
+`   fixme: at the current time, the cubemap is world-aligned and cannot rotate.`
+
+lightscales <ambient> <diffuse> <specular>
+
+`   multipliers for the rtlight's various types of lighting`
+
+### lightshadows <castshadows> {#lightshadows}
+
+`   0 or 1, specifies whether the rtlight will cast shadows or not. Its faster if it doesn't.`
+
+### lightcorona <intensity> <scale> {#lightcorona}
+
+### model <name> \[options\] {#model_options}
+
+`   options are:`
+`       frame=`
+`       framestart=`
+`       framecount=`
+`       frameend=`
+`       frames=`
+`       framerate=`
+`       skin=`
+`       alpha=`
+`       scalemin=`
+`       scalemax=`
+`       trail=`
+`       orient`
+`       additive`
+`       transparent`
+`       fullbright`
+`       shadow`
+`       noshadow`
+`   spawns sprites or models that fly away with random angles and run through some frame sequence. handy for simple gib effects.`
+
+### sound <name> \[options\] {#sound_options}
+
+`   options are:`
+`       vol=`
+`       attn=`
+`       pitch=`
+`       delay=`
+`       weight=`
+`   Plays a sound when the effect is spawned. Only ONE sound will be used, picked randomly from the included sounds according to their weights.`
+
+### spawnstain <radius> <r> <g> <b> {#spawnstain}
+
+`   Controls whether a stain will be created at the same time as any particles (instead of depending upon impacts).`
+
+### rainfrequency <multiplier> {#rainfrequency}
+
+`   Specifies the interval between spawning new particle puffs on surfaces.`
+
+### flurry <magnitude> {#flurry}
+
+`   These particles will periodically all change their direction, in a vauge attempt to approximate snow flurries.`
+
+## Cvars {#cvars}
+
+-   [r_particledescr](/Cvar:_r_particledescr "wikilink")
+-   [r_particlesystem](/Cvar:_r_particlesystem "wikilink")

Documentation/Prop_data.md

@@ -23,30 +23,32 @@ and it contains structures for types and a separate section titled
 
 An example propdata.txt looks like this:
 
-` "PropData.txt"`
-` {`
-` `
-`   "sometype"`
-`   {`
-`     // .. key/field attributes`
-`     // e.g.`
-`     "health" "10"`
-`     "breakable_model" "somematerial"`
-`   }`
-` `
-`   "BreakableModels"`
-`   {`
-`     // completely unrelated to types defined in propdata.txt`
-`     // but somehow still part of it?`
-` `
-`     "somematerial"`
-`     {`
-`       // model path / fadeout time pair`
-`       // e.g.`
-`       "foo.vvm" "2.5"`
-`     }`
-`   }`
-` }`
+```
+ "PropData.txt"
+ {
+ 
+   "sometype"
+   {
+     // .. key/field attributes
+     // e.g.
+     "health" "10"
+     "breakable_model" "somematerial"
+   }
+ 
+   "BreakableModels"
+   {
+     // completely unrelated to types defined in propdata.txt
+     // but somehow still part of it?
+ 
+     "somematerial"
+     {
+       // model path / fadeout time pair
+       // e.g.
+       "foo.vvm" "2.5"
+     }
+   }
+ }
+```
 
 The idea is that props specify the type of prop they are ("sometype")
 and it defines a set of sensible defaults.
@@ -70,11 +72,13 @@ text definition alongside as mentioned above.
 An example for the example specification listed above would be a
 propdata key/value pair as part of the entity definition:
 
-` {`
-`   "classname" "func_wall"`
-`   "model"     "*42"`
-`   "propdata"  "sometype"`
-` }`
+```
+ {
+   "classname" "func_wall"
+   "model"     "*42"
+   "propdata"  "sometype"
+ }
+```
 
 ### Model propdata definition {#model_propdata_definition}
 
@@ -82,15 +86,17 @@ If you had a model, e.g. located at `models/foobar.vvm` then if you were
 to place a file named `models/foobar.vvm.propdata` alongside it with the
 following contents:
 
-` PropData.txt`
-` {`
-`   prop_data`
-`   {`
-`     "health" "30"`
-`     "breakable_model" "somematerial"`
-`     "breakable_count" "10"`
-`   }`
-` }`
+```
+ PropData.txt
+ {
+   prop_data
+   {
+     "health" "30"
+     "breakable_model" "somematerial"
+     "breakable_count" "10"
+   }
+ }
+```
 
 This registers an internal propdata definition with the name
 **models/foobar.vvm.propdata** that would correspond to the above

Documentation/Sentences.md

@@ -0,0 +1,63 @@
+Sentences are the voice-acting backbone of the sound system.
+
+The definitions for each games' voice acting are stored inside
+`sound/sentences.txt`.
+
+# Syntax {#syntax}
+
+Each line is a new sentence group.
+
+`GROUPNAME [PARAMETERS] SAMPLES`
+
+Real-world example:
+
+**`MALETEST`**` attention(p120) male/hello how are you`
+
+The above example lists 5 samples that'll get played.
+
+If a sample is not in a sub-directory, it'll be assumed to be part of
+the **vox** sub-directory, or the last valid path of a previous sample.
+For example
+
+`attention male/hello how are you`
+
+plays the following samples:
+
+**`vox`**`/attention.wav male/hello.wav male/how.wav male/are.wav male/you.wav`
+
+*When parameters are surrounded by spaces, this means they apply to all
+current samples.* They can be overwritten later down the parsing.
+
+When a parameter is attached to a sample, e.g.
+
+`attention(p120)`
+
+Then this parameter only applies to said keyword.
+
+Whereas...
+
+`(p120) attention everyone alive`
+
+Will apply the pitch effect to all three succeeding samples.
+
+## Parameters {#parameters}
+
+-   (pXX) = Pitch. Valid values are from 50 to 150.
+-   (vXX) = Volume. Valid values are from 0 to 100.
+-   (sXX) = Start point in %. E.g. 10 skips the first 10% of the sample.
+-   (eXX) = End point in %. E.g. 75 ends playback 75% into the sample.
+-   (tXX) = Time shift/compression in %. 100 is unaltered speed, wheras
+    50 plays the sample back in half the time.
+
+# Usage {#usage}
+
+When an entity, say, a **scripted_sentence** wants to play a sentence,
+it'll prefix it with an exclamation mark ( **!** ). For example:
+
+`"sentence" "!GM_SUIT"`
+
+Will play:
+
+`GM_SUIT gman/gman_suit`
+
+[Category: Nuclide Scripting](/Category:_Nuclide_Scripting "wikilink")

Documentation/Shaders/caustics.md

@@ -0,0 +1,3 @@
+# Shaders: Overview {#shader_overview}
+
+## caustics

Documentation/Shaders/caustics_a.md

@@ -0,0 +1,3 @@
+# Shaders: Overview {#shader_overview}
+
+## caustics_a

Documentation/Shaders/clutter.md

@@ -0,0 +1,3 @@
+# Shaders: Overview {#shader_overview}
+
+## clutter

Documentation/Shaders/decal.md

@@ -0,0 +1,3 @@
+# Shaders: Overview {#shader_overview}
+
+## decal

Documentation/Shaders/decal_reflectcube.md

@@ -0,0 +1,3 @@
+# Shaders: Overview {#shader_overview}
+
+## decal_reflectcube

Documentation/Shaders/default2d.md

@@ -0,0 +1,3 @@
+# Shaders: Overview {#shader_overview}
+
+## default2d

Documentation/Shaders/defaultadditivesprite.md

@@ -0,0 +1,3 @@
+# Shaders: Overview {#shader_overview}
+
+## defaultadditivesprite

Documentation/Shaders/defaultfill.md

@@ -0,0 +1,3 @@
+# Shaders: Overview {#shader_overview}
+
+## defaultfill

Documentation/Shaders/defaultskin.md

@@ -0,0 +1,3 @@
+# Shaders: Overview {#shader_overview}
+
+## defaultskin

Documentation/Shaders/defaultskybox.md

@@ -0,0 +1,3 @@
+# Shaders: Overview {#shader_overview}
+
+## defaultskybox

Documentation/Shaders/defaultsprite.md

@@ -0,0 +1,3 @@
+# Shaders: Overview {#shader_overview}
+
+## defaultsprite

Documentation/Shaders/defaultwall.md

@@ -0,0 +1,3 @@
+# Shaders: Overview {#shader_overview}
+
+## defaultwall

Documentation/Shaders/defaultwarp.md

@@ -0,0 +1,3 @@
+# Shaders: Overview {#shader_overview}
+
+## defaultwarp

Documentation/Shaders/depthonly.md

@@ -0,0 +1,3 @@
+# Shaders: Overview {#shader_overview}
+
+## depthonly

Documentation/Shaders/fade.md

@@ -0,0 +1,3 @@
+# Shaders: Overview {#shader_overview}
+
+## fade

Documentation/Shaders/fill.md

@@ -0,0 +1,3 @@
+# Shaders: Overview {#shader_overview}
+
+## fill

Documentation/Shaders/fullbright_reflect.md

@@ -0,0 +1,3 @@
+# Shaders: Overview {#shader_overview}
+
+## fullbright_reflect

Documentation/Shaders/lensflare.md

@@ -0,0 +1,3 @@
+# Shaders: Overview {#shader_overview}
+
+## lensflare

Documentation/Shaders/lightmapped.md

@@ -0,0 +1,3 @@
+# Shaders: Overview {#shader_overview}
+
+## lightmapped

Documentation/Shaders/lightmapped_reflect.md

@@ -0,0 +1,3 @@
+# Shaders: Overview {#shader_overview}
+
+## lightmapped_reflect

Documentation/Shaders/lightmapped_specular.md

@@ -0,0 +1,3 @@
+# Shaders: Overview {#shader_overview}
+
+## lightmapped_specular

Documentation/Shaders/pp_colorcorrect.md

@@ -0,0 +1,3 @@
+# Shaders: Overview {#shader_overview}
+
+## pp_colorcorrect

Documentation/Shaders/reflect.md

@@ -0,0 +1,3 @@
+# Shaders: Overview {#shader_overview}
+
+## reflect

Documentation/Shaders/refract.md

@@ -0,0 +1,3 @@
+# Shaders: Overview {#shader_overview}
+
+## refract

Documentation/Shaders/rtlight.md

@@ -0,0 +1,3 @@
+# Shaders: Overview {#shader_overview}
+
+## rtlight

Documentation/Shaders/skybox.md

@@ -0,0 +1,3 @@
+# Shaders: Overview {#shader_overview}
+
+## skybox

Documentation/Shaders/skybox_hdr.md

@@ -0,0 +1,3 @@
+# Shaders: Overview {#shader_overview}
+
+## skybox_hdr

Documentation/Shaders/skybox_parallax.md

@@ -0,0 +1,3 @@
+# Shaders: Overview {#shader_overview}
+
+## skybox_parallax

Documentation/Shaders/skybox_valley.md

@@ -0,0 +1,3 @@
+# Shaders: Overview {#shader_overview}
+
+## skybox_valley

Documentation/Shaders/sprite.md

@@ -0,0 +1,3 @@
+# Shaders: Overview {#shader_overview}
+
+## sprite

Documentation/Shaders/sprite_fixed.md

@@ -0,0 +1,3 @@
+# Shaders: Overview {#shader_overview}
+
+## sprite_fixed

Documentation/Shaders/sprite_vscroll.md

@@ -0,0 +1,3 @@
+# Shaders: Overview {#shader_overview}
+
+## sprite_vscroll

Documentation/Shaders/terrain.md

@@ -0,0 +1,3 @@
+# Shaders: Overview {#shader_overview}
+
+## terrain

Documentation/Shaders/terrain_alpha.md

@@ -0,0 +1,3 @@
+# Shaders: Overview {#shader_overview}
+
+## terrain_alpha

Documentation/Shaders/terrain_alpha_alt.md

@@ -0,0 +1,3 @@
+# Shaders: Overview {#shader_overview}
+
+## terrain_alpha_alt

Documentation/Shaders/terrain_mask.md

@@ -0,0 +1,3 @@
+# Shaders: Overview {#shader_overview}
+
+## terrain_mask

Documentation/Shaders/terrain_skybox.md

@@ -0,0 +1,3 @@
+# Shaders: Overview {#shader_overview}
+
+## terrain_skybox

Documentation/Shaders/terrain_valley.md

@@ -0,0 +1,3 @@
+# Shaders: Overview {#shader_overview}
+
+## terrain_valley

Documentation/Shaders/unlit.md

@@ -0,0 +1,3 @@
+# Shaders: Overview {#shader_overview}
+
+## unlit

Documentation/Shaders/vertexlit.md

@@ -0,0 +1,3 @@
+# Shaders: Overview {#shader_overview}
+
+## vertexlit

Documentation/Shaders/vertexlit_specular.md

@@ -0,0 +1,3 @@
+# Shaders: Overview {#shader_overview}
+
+## vertexlit_specular

Documentation/Shaders/vertexmap.md

@@ -0,0 +1,3 @@
+# Shaders: Overview {#shader_overview}
+
+## vertexmap

Documentation/Shaders/water.md

@@ -0,0 +1,3 @@
+# Shaders: Overview {#shader_overview}
+
+## water

Documentation/Shaders/water_dirty.md

@@ -0,0 +1,3 @@
+# Shaders: Overview {#shader_overview}
+
+## water_dirty

Documentation/Shaders/water_high.md

@@ -0,0 +1,3 @@
+# Shaders: Overview {#shader_overview}
+
+## water_high

Documentation/Shaders/water_sky.md

@@ -0,0 +1,3 @@
+# Shaders: Overview {#shader_overview}
+
+## water_sky

Documentation/Support.md

@@ -3,11 +3,12 @@
 If you require assistance that involves the internals of Nuclide itself (as in, you have already gotten it running) and need someone to talk to about it - there's a few places where we all gather and talk about this project as well as sub-projects and related projects.
 
 ## Matrix
+
 This is the default for us. [You can find a dedicated **Space** right here.](https://matrix.to/#/#nuclide:matrix.org)
 
 ## Internet Relay Chat
-This is our fallback. It is also bridged with the general room on Matrix.
 
+This is our fallback. It is also bridged with the general room on Matrix.
 You can connect to irc.libera.chat and join #nuclide.
 
 ## Commercial Support

Documentation/Surf_data.md

@@ -45,11 +45,9 @@ the object and the friction it deals with.
 So in Nuclide, there's a few options too as to how you're able to define
 what property anything is made of.
 
--   For the level geometry, a `surfaceparm` is used to
+-   For the level geometry, a surfaceprop is used to
     define what material properties to use. There are a lot of basic materials
     to choose from there.
--   For models, the `surfaceParm` command inside the .QC can be used to
-    define a surfaceparm.
 -   Entities can **specify** which entry from
     `scripts/surfaceproperties.txt` get's used. This is required for
     NSPhysicsEntity derived classes.
@@ -57,8 +55,8 @@ what property anything is made of.
     field to be the name of an entity listed inside the
     `surfaceproperties.txt` file.
 -   ...of course, the old way is supported as long as you're using a
-    legacy format that does not support **surfaceParms**. They'll get
-    mapped to a pair of pre-defined entries, which mods can override.
+    legacy format that does not support **surfaceprop**. They'll get
+    mapped to the IDs specified in the surfaceproperties.txt file.
 
 And instead of defining a single character defining the audio visual
 appearance, you can now tweak every aspect of it. See **Scripting**
@@ -93,6 +91,7 @@ Available keys are:
 
         "stepleft"      <string>    footstep left
         "stepright"     <string>    footstep right
+        "fx_bulletimpact"      <string>    particle effect to cast on impact
         "bulletimpact"      <string>    soundDef to play on impact
         "scraperough"       <string>    soundDef to play on rough scraping
         "scrapesmooth"      <string>    soundDef to play on smooth scraping

Documentation/VMap/Lighting Best Practices.md

@@ -0,0 +1,98 @@
+Here we'll run down the practices of lighting your map using
+[WorldSpawn](/WorldSpawn "wikilink") and [vmap](/vmap "wikilink").
+
+## Basic Rules {#basic_rules}
+
+-   Point lights are hard to maintain, use surface lights (either
+    [vmap_surfaceLight (Material
+    Command)](/vmap_surfaceLight_(Material_Command) "wikilink") or
+    [light_surface](/light_surface "wikilink"))
+-   [light_environment](/light_environment "wikilink") will do a bulk of
+    the world lighting, it should even be used in afternoon and dark
+    settings
+-   Avoid ambient lighting, unless you know exactly what you want, or
+    you're in a completely interior-only map
+
+## Global settings {#global_settings}
+
+[light_environment](/light_environment "wikilink") will do the bulk
+work. It emits light from any sky surface, such as `common/skyportal`.
+The amount of samples specify how many **passes** are done. This will be
+~evened~ out to match the desired **intensity**, so increasing samples
+does **not** make the map brighter.
+
+Using more than 1 sample is useful if you want less harsh-shadows. Even
+a value of 4 with a `sunspreadangle` of e.g. 5-10 degrees is sensible
+for day-time maps. It makes them look less artifacting too. The theory
+is, the cloudier the world is, the softer the shadows are - so we need
+more **samples** and a `sunspreadangle` that's wider to accommodate
+that.
+
+The `sunspreadangle` will determine how far apart the different samples
+will be spread. E.g. if you set it to '0' it will do nothing. Every
+light_environment sample will take place on the exact same spot, from
+the same angle. However if you set it to 360 (the maximum amount), each
+sample will spread out to get a full 360 coverage of the map. Resulting
+in a lightmap without any real contrasting shadows.
+
+## Which light_environment color to use? {#which_light_environment_color_to_use}
+
+99% of the time it's going to be white. Let `_ambient` inside your
+light_environment tint the shadows the color of the sky, let radiosity
+do its job. Radiosity can't do its job if the sun color is non-white.
+
+**The effects of radiosity will be barely visible using a non-white
+light_environment color.**
+
+## Ambient color? {#ambient_color}
+
+Set `_ambient` in your light_environment to whatever the color of the
+sky is set to. This determines the color of the shadows cast by the
+light_environment. **This does not create a minimum ambient intensity in
+the process**
+
+## Minimum light intensity {#minimum_light_intensity}
+
+A really ugly hack, only use it in the worst case scenario.
+
+In your [worldspawn (Entity)](/worldspawn_(Entity) "wikilink") keys, you
+can add a `_minlight` intensity value, as well as a `_minlight_color`
+value. This is not something you want to use for anything looking good.
+
+It raises the lighting level-wise, but keeps the light values of each
+entity/sky/shader intact. A much worse alternative is the worldspawn
+`_ambient` key.
+
+**You will never achieve truly black areas in your map after this. Be
+warned.**
+
+## What about the worldspawn **_ambient** key? {#what_about_the_worldspawn__ambient_key}
+
+The overall lighting level of the map is raised. This has the tendency
+to flatten the difference between light and shadow. The dynamic range is
+utterly destroyed.
+
+## What about the worldspawn **_floodlight** key? {#what_about_the_worldspawn__floodlight_key}
+
+With floodlight, light becomes darker in closed spaces and brighter in
+wide open spaces.
+
+The worldspawn key for that is `_floodlight`, with you specifying:
+
+` `**<red color>` `<blue color>` `<green color>` `<travel distance>` `<intensity>**
+
+The side effect is that it'll obviously act as a contrasting knob. It
+**does not fix spaces where light wasn't present to begin with**!
+
+There are very few artistic use cases for this. However, if your map is
+looking very dull/flat, it could help a lot.
+
+## Should I use radiosity? How many bounces? {#should_i_use_radiosity_how_many_bounces}
+
+Half-Life 2 compiled with a maximum of 8 bounces, that is sensible. You
+can even set it to 100 and it'll stop once photons lose their energy.
+
+**And of course yes you should use radiosity... Damn it, that fixes most
+lighting problems!**
+
+[Category: Level Design](/Category:_Level_Design "wikilink")

Doxyfile

@@ -886,6 +886,7 @@ INPUT                  = src/ \
                          Documentation/Materials/commands/ \
                          Documentation/Materials/MatShaders.md \
                          Documentation/Materials/MatGoldSrc.md \
+                         Documentation/Shaders/ \
                          Documentation/Surf_data.md \
                          Documentation/Prop_data.md \
                          Documentation/Sound/ \