RenderSystem manual

RenderSystem (RS) is a powerful effect generation tool for level designers.
Typically it is used to emit particles, but is not limited to.
The main feature is the ability to customize its parameters using simple configuration text files.
These files are located in /scripts/rendersystem directory. You can find some examples there.
SoHL users, who may be familiar with the Aurora particle system, should get the idea.
But, in contrary to Aurora, RS is much faster, has much more features, has modular OOP design,
clean and heavily documented code. RS was used "in the code" for many years and proved its efficiency.
The next goal was to allow the use of simple text files without any loss in performance, features
or beauty, and it is now accomplished.


Instruction

To use RS, simply put env_rendersystem somewhere in your map and select script for it.

*NOTE*
 Please keep directories clean! Put your MAP systems into /scripts/rendersystem/mapname/ subdirectory, or,
 if you want to share systems across many maps, create common subdirectory for them (like "mycampaign").
 Players must be able to run your maps when all unrelated subdirectories are deleted.

Powerful feature of RS is that it can be used as a point entity where effect originates
or it may have TARGET field to move the effect to some other entity like monster or train.
It can also be tied to an "attachment point" of a studio model if the "Attachment" field is valid
(valid indexes are 0 to MAXSTUDIOATTACHMENTS).
RS can have ON/OFF state or it can be used for one-shot effects (per use).


Script file syntax

This file can contain several systems. They all are created and toggled/activated simultaneously.
Each system must start with class name and have all parameters enclosed in "{}" braces,
each key must have its proper value.
// C++-style single-line comments are allowed
[optional keywords] CPSCustom OptionalName
{
	"key" "value"
}

Optional keywords are:
virtual - system doesn't have anything to draw itself, but can be used by some other system, can never be activated
inactive - system won't be activated after creation, but after activation will be fully normal system
delayed(number) - system creation will be delayed by given number of seconds

Each system has a set of parameters, but most of them are common (like origin, color, etc.) because all systems obey OOP inheritance rules:
for example, CPSCustom includes all parameters of CParticleSystem, which includes those of CRenderSystem. In fact, all particle systems do.

*!!!WARNING!!!*
 Most of the systems were never tested with the script system! Try them at your own risk!
 Tested and approved systems are marked with '+'.
 NOTE: CPSCustom, while being the most flexible PS, is also the slowest one.

Possible class names are:
CRSBeam
CRSBeamStar
CRSCylinder
CRSDisk
CRSLight
CRSModel
CRSRadialBeams
-CRSSphere - undone
CRSSprite - a flat surface, parallel to viewport (sprite)
CRSTeleparts
CRenderSystem - a flat surface (non-rotating sprite)
+CParticleSystem - base particle system
CPSBeam
CPSBubbles
+CPSCustom - advanced particle system (made for scripts)
-CPSDrips - obsolete
-CPSFlameCone - obsolete
CPSFlatTrail
CPSSparks
CPSSpiralEffect

Unfortunately, there's no simple way to document all possible parameters here. There are have two ways to learn them:
look for example scripts or see the source code (key names can be found inside each system's ParseKeyValue() function).
And if that is not enough, RS allows level designer to override some values directly by adding them into entity! This is useful,
for example, to control amount of particles when using common script for many env_rendersystems. Add "fMaxParticlesK" key with
value "2.0" into your env_rendersystem and the final amount of particles will the be doubled number from its script.

*NOTE*
 Due to MAX_USER_MSG_DATA limit, maximum number of custom keys is 8. And that is still not guaranteed to work.

*HINT*
 Keys follow RS C++ naming notation, so first letters hint to the key type. For example: "iMaxParticles" is an integer - a decimal value,
 "fScaleMin" is a float - a decimal fractional value, "vStartMins" is a 3D vector - 3 floats separated with spaces. There are some exceptions
 though: "Color4b" indicates that color is encoded in 4 bytes "255 255 255 255", ColorDelta4f - in 4 floats (0...1) "1.0 1.0 1.0 1.0".

*NOTE*
 All systems are loaded from the file during the first use only (because it is somewhat slow process and
 there may be hundreds of systems activated on the map).

To test scripts there's a somewhat simple method: place your systems entities on a simple test map,
open scripts in some text editor, run the map. You can then ALT+TAB to the script and back. To apply changes,
simply restart the effect or the map. To do it quickly with one key: bind "F8" "restart"


Console commands

// Client-side:
listrs
searchrs
// Server-side: to toggle your system use
searchents targetname mysystem use 3

Example:
searchrs * - will list all systems
searchrs state 4 - will list all virtual systems


That's it.
Now you are ready to unleash the power of the RenderSystem!
Start creating, enjoy the result, share videos!