Brethren asked if there was a listing of new features.

Misc notes for modders / content creators
=========================================

Table of contents
-----------------

* Changed Limits/Limitations
* Image Type Priorities
* LG.INI
* Materials
* Gamesys and Mission DML Patching/Modding
* Cubemaps
* DXT Texture Compression
* 8-bit Anti-Aliased Fonts
* Additions to Books/Readables (T2)
* Script Service Updates
* OSM Author Notes
* FM Author Notes
* General DromEd Notes
* HW Rendering in DromEd
* Updates to DARKDLGS.DLL
* DromEd Texture Palette
* Build Dialog
* Loading Textured Group (.vbr)
* Exporting Terrain Mesh
* Fog Zones
* Ambient Light Zones
* Max View Distance
* New Texture Align Mode "AlignExt"
* UV Mapping a Cylinder
* Stripped Mission Reconstruction
* Changed Prop: Script->"Trap Control Flags" (SS2)
* Changed Prop: Weather->"Local Weather"
* Changed Prop: Renderer->"Bitmap Worldspace"
* Changed Prop: Renderer->"Anim Light"
* Changed Prop: Renderer->"Corona"
* Changed Prop: Renderer->"Render Type"
* Changed Prop: Physics->Model->"Attributes" (OBB)
* Changed Prop: Receptron Effect "Poke Object"
* Changed Prop: SFX->"Particles"
* Changed Prop: AI->"Efficiency settings"
* Changed Prop: Tweq
* New Prop: Renderer->"Alpha Blend Mode"
* New Prop: Renderer->"Alpha Test Threshold"
* New Prop: Renderer->"Render Order"
* New Prop: Renderer->"Camera Overlay"
* New Prop: Renderer->"Light-based transparency"
* New Prop: Renderer->"Force Static Shadow"
* New Prop: Renderer->"Distance Alpha"
* New Prop: Renderer->"Bitmap Color"
* New Prop: Door->"Static Light Pos"
* New Prop: Creature->"Creature Scale"
* New Prop: Creature->"Disable Head Track"
* New Prop: Inventory->"Block Frob?" (T2)
* New Prop: Difficulty->"Remove Properties"
* New Prop: Editor->"Design Note" (SS2)
* New Prop: Editor->"Editor Comments"
* New Link: "DetailAttachement"


Changed Limits/Limitations
--------------------------

Note that not all limits imply that it's possible to push as far as the limit suggests, because other parts of the
engine might hit another limit first. For example the max brush limit might be hit before the max regions limit,
or vice versa.

Max concrete object IDs: 8192 (from 4096)
Max visible objects: 1280 (from 128)
Max texture dimension: 4096 (from 1024)
Max texture animation frames: 99 (from 20)
Max drawn terrain polys: 20480 (from 1024)
Max ambient sound objects: 1024 (from 256)
Max cells for bounding sphere spatial queries: 1024 (from 512)
Max cells a dynamic light can reach: 1024 (from 512)
Max portal clip regions: 20480 (from 2048)
Max characters per cfg-file line: 8192 (from 80)
Max display resolution: <unlimited>x4800 (actual limit depends on HW) DX9 / 2048x2048 DX6 (from 1024x768)

Max brushes: 16384 (from 7068)
Max regions (/ worldrep (WR) cells): 32760 (from 28672)
Max rooms: 4096 (from 1024)
Max AI path cells: 131070 (from 65534)
Max texture families: 32 (from 16)
Max family textures: 1024-ish (from 256-ish)
Max static lights: 2016 (from 736)
Max cells a static/anim light can reach: 8192 (from 512)
Max anim light to cell pairings: 49152 (from 16384)
Max brush faces/sides: 28 (from 12)
Max decals per page on Thief maps: 256 (from 64)

New image formats: PNG, DDS, PCX 32-bit, BMP 24/32-bit, TGA RLE

Full 32-bit rendering pipeline support, from 32-bit textures to 32-bit render surfaces.


Image Type Priorities
---------------------

Aside from the new image formats, the priority (which type can override another) has been slightly adjusted.
The priority order is as follows, where the first has the highest override priority:

.DDS
.PNG
.TGA
.BMP
.PCX
.GIF
.CEL

Another change, to make texture overrides work seamlessly with objects and meshes, is that the image type specified
in the object/mesh files is disregarded. For example if object ARROW.BIN uses a texture named ARROW.GIF, the game
will search for any image named ARROW, starting with ARROW.DDS, then ARROW.PNG etc. until it finds an existing
file. Consequently it's a bad idea to create another object (usually for an FM), that uses a different image with
the same name but different image type. For example if you create a new object that uses an image called ARROW.PNG,
then the original arrow object will use that image too instead of ARROW.GIF.


LG.INI
------

The optional LG.INI file, for low level configuration, must now be located in the installation directory (usually
the same as where the EXE file is located). Any .INI file located in the Windows directory will NOT be read.


Materials
---------

Terrain and object textures can have a material file associated with them, that can control various render settings
and add effects for the texture. See separate material documentation "material-format.txt" for more information.


Gamesys and Mission DML Patching/Modding
----------------------------------------

It's possible to mod/patch object and archetype properties or mission parameters in a non-permanent fashion by
using the added dbmod system. This is done through DML files, which are text based "scripts" to modify properties
and parameter values without requiring the .mis or .gam files to be permanently modified. See separate dbmod
documentation "dbmod-sample.dml" for more information.


Cubemaps
--------

Cubemaps are supported through DDS files and require the game to run in DX9 mode, otherwise it will only load
the X+ cubemap face and treat it as a regular 2D texture.

Cubemaps can currently only be used for environment mapped material layers. Attempting to use them in any other
place will either result in only the X+ face being used as a regular 2D texture, artifacts or possibly a crash.
Mipmaps will not be automatically generated for cubemaps, the DDS file must contain them if they are desired.

It's possible to generate a cubemap of a location in a mission, using the command "envbox" in DromEd's game mode.
This works like the old "skybox" command, except it renders the entire scene from the player's current position,
instead of only the sky. The 6 resulting textures are the same as for "skybox", in fact the textures could be
used as an old sky.

When creating a DDS cubemap from the 6 files (north, south, east, west, top and bottom), the sides map as follows:

cube
face envbox/skybox side
---------------------------
X+ West
X- East
Y+ Top, rotate 90 CW
Y- Bottom, rotate 90 CCW
Z+ South
Z- North

With the nVidia DDS saver plugin for Photoshop you would create an image that has all 6 faces side by side like
this:

+-------+-------+-------+-------+-------+-------+
| W | E | T | B | S | N |
| | | 90° | 90° | | |
| | | CW | CCW | | |
+-------+-------+-------+-------+-------+-------+

For Direct3D documentation see http://msdn.microsoft.com/en-us/library/windows/desktop/bb204881%28v=vs.85%29.aspx


DXT Texture Compression
-----------------------

DXT textures can NOT be used for any components that are rendered/drawn in software, such as menu/UI/HUD graphics
or object textures that can appear in Thief's loadout screen. Automatic mipmap generation and edge padding for
transparent textures does not work with DXT textures. If necessary, edge padding must be applied offline, on the
original texture, and the DDS should always contain mipmaps.

DXT1 textures are treated as opaque, unless material param "force_full_alpha" or "force_alpha_key" is set.

When running DromEd all DXT textures are decompressed to 32-bit RGB textures on load, because certain editor
elements use software rendering/drawing functions which can't handle DXT.


8-bit Anti-Aliased Fonts
------------------------

A font format, that uses the full 8 bits (for 256 shades), for anti-aliased fonts was added. For better quality,
especially with 32-bit rendering, where the old 16 shades might be too limited. The file format/type value is 2,
otherwise they work like format/type 1 AA fonts.


Additions to Books/Readables (T2)
---------------------------------

Books can now have images on specific pages and locations, up to 32 images (aka decals) per page. The decals are
specified in the same .STR files as the book text, using the format:

page_<pnum>_decal_<dnum>: "<over text> <X> <Y> <image name>"

<pnum> - page number, same as the one used for page text
<dnum> - decal number, starts at 0 up to 31 (all decals on a page must use consecutive numbers, no gaps)
<over text> - 0 = text will be visible over the decal, 1 = decal will cover any text under it
<X> - X position of top-left corner of image (the entire book screen is 640x480)
<Y> - X position of top-left corner of image
<image name> - name of image file, must be located in "Books\" or a sub-directory of it (backslash characters
must be written as double backslash "\\" because "\" is an escape character)

For example to display a decal "Books\decals\inksplat.tga", over text on page_2, it would look something like:

page_2_decal_0: "1 100 230 decals\\inksplat"

Decals should always be true-color images to ensure that they are correctly displayed even 32-bit textures aren't
enabled. Using palette based images may result in incorrect palette being used unless the image uses the same
palette as the book art. If the decal image contains an alpha channel it will automatically be drawn with alpha
blending, allowing decals to nicely blend with the book background. When drawing text over a decal it's highly
recommended to use an AA font, otherwise there will often be ugly artifacts. Using AA fonts will improve quality
in general, even if not using decals, as they blend correctly with the background.

Book texts and decals can be edited while the game is running and the .STR file will be reloaded every time the
book is brought up, by using the "test_book_ex" command or by enabling auto-reload with "toggle_book_autoreload".
It does require closing and opening the book/readable, but beats having to restart the game.

Text color for books (when using font types that allow custom text color, i.e. AA or 1-bit fonts) can be defined
with a config var per book art. For "Books\pbook" that would be done like this, "color_books_pbook 100 30 220". In
addition each book .STR can set a custom text color by defining "text_color", which overrides any config var. For
example:

text_color: "120 55 206"

The book .STR may also specify a custom font with "font". This also allows having a collection of AA fonts in single
directory, instead of multiple copies of a font in each book art directory that wants to use it. A font is specified
with a resource base path ("intrface", "books" etc.) and the font name with any sub-dir. Examples:

font: "books fonts\\handwrite1"
font: "intrface fontaa12"

Support for leading whitespaces, in order to for example center a page title, has also been added but is not enabled
by default in order to not break any existing content. It has to be enabled for each book .STR that wants to use it
by adding a "no_trim" value like this:

no_trim: "1"


Script Service Updates
----------------------

A couple of new script services have been added, and a few additions to existing ones (new marked with *):

DarkGame, DarkOverlay(*), Debug, Engine(*), Object, Physics, ShockOverlay(*), Version(*)

See "script_services.txt" and other script related documentation for details.


OSM Author Notes
----------------

An OSM can use the new Version script service to determine the game version. To avoid problems when someone
tries to use an OSM with and older version of the game, the OSM can check if the Version script service is
available or not first. If a service isn't available the engine will return the Null script service as usual.

Custom OSMs that access files directly have to ensure that they work correctly with the new native FM system, or
the FMs that use them will fail (unless they're installed the old fashioned way, bypassing the native FM system).
When an FM is active, an OSM that wants to access a file must first look for the file in the FM's dir, and then
the current working dir. There are two ways to deal with this:

A) Search for a file in paths defined by a config var (such as "resname_base" or "script_module_path"). This
is done through the FindFileInPath function in the new Engine script service. The benefit of using that is
that it's fully compliant with FM and mod paths, without the caller having to deal with any of that. It
searches for the file in all the relevant paths in correct priority order.

B) Manually look for the file in the FM's dir, if an FM is active, by using the FM support functions in the
new Version script service. To check if an FM is active you can call the GetCurrentFM or GetCurrentFMPath
functions and see if the return value is S_OK. If it is, you can the use the return path or use
FMizeRelativePath to generate a filename for the file located in the FM dir. Note that it's important to
first look for the file in the FM dir before falling back to the current working dir, otherwise it would
break the defined dir priority order.

OSMs that only call LoadLibrary should still work correctly, although it wouldn't hurt if they resolved the path
with one of the two methods mentioned above (preferably method A and "script_module_path").


FM Author Notes
---------------

Even if you, as an FM author, don't use the FM Selector (fmsel.dll) yourself, it's strongly suggested that you
include an "fm.ini" when creating FMs from now on, and a "fmthumb.jpg" would also be preferable. These are
standardized files with information about the FM, such as release date, author(s) or description. Currently only
the FM Selector uses them, but standardized conventions will aid other potential future uses. Such as making the
job easier for web based FM databases, other potential FM selector implementations or loader/mod manager updates.

Although an "fm.ini" could be created manually in a text editor, the preferable method is to create/export it from
the FM Selector. That ensures that formatting and content is correct.

The "fmthumb.jpg" file is an (optional) image that's used to make the FM information presentation look more
appealing. It can be a JPG version of the main/logo image in Thief's main menu, or it can be something fancier.
In the FM Selector it's displayed at the top of the "View Summary" window. Potential future web based FM databases
may do something similar. The width of the image should be at most 500 pixels, and the height should be kept under
200 pixels. The logo image on Thief's main menu is 300 x 168, which is a good guideline to go by.

The "fm.ini" and "fmthumb.jpg" files have to be located in the root directory of the FM.

DO NOT USE MP3!
It's strongly suggested that you avoid using MP3 files in FMs. There are patent/licensing issues tied to that
format, which may put your FM in troublesome position but even more so FM selectors/loaders. Instead of MP3,
use the OGG format (http://www.xiph.org/ogg/). There's nothing gained by using MP3 over OGG.


General DromEd Notes
--------------------

Do NOT try to load a file saved with new DromEd into an old DromEd version. It will likely crash during load and
if it doesn't, bad things will probably still happen under the hood.

The editor Death Stage 12 bug and campaign data/vars modification after returning from game mode should be fixed,
so it's recommended to disable the automatic workaround/fixes in the DromEd Toolkit / ShockEd Toolkit (the most
commonly used editor distributions). Especially the automatic DS12 fix because there are instances, at least in
original missions, where the Death Stage property has been intentionally added, and the toolkit deletes those too.

The commands "light_bright" and "lit_obj_toggle" are deprecated and will not work properly and consistently in
all situations. Use the new command "toggle_lighting" instead.

Aside from the original 15/16-bit lightmaps, there is now support for 32-bit lightmaps. 32-bit lightmaps can also
be used in a 2X mode, which allows overbrighting. For further details see the "enable_32bit_lightmaps" config var
in "new_config_vars.txt". Lightmapping can now also be enabled for water surfaces.

The mouse wheel can be used on all value controls in the editor main window (like the X Y Z controls or brush Op).

In solo-view for a 2D viewport, the context menu has a new "scroll here" command which can be used to pan around
like with "teleport camera" in un-solo mode, except it doesn't affect the camera position.

Holding down CTRL while clicking in a 2D viewport will use an alternative selection mode (aka precision-selection).
In this mode you have to click ON a brush edge to select it, and if multiple brushes are overlapping on a point,
clicking multiple times will cycle through each brush in that point. This allows easier selection in dense
locations without having to resort to filters or cumbersome cycle_near functionality. There are config vars to
configure the pixel tolerance of what constitutes ON an edge ("selection_pixel_margin"), and to make precision-
selection the default selection mode ("precision_select_default).

When assigning textures to surfaces in a solid view 3D viewport (while the texture palette is open), holding down
SHIFT will assign a -1 texture id to the surface, so the brush default texture is used.

A native mono console window can be enabled with the config var "mono_console". There are optional parameters
to specify size and position of the window, see "new_config_vars.txt" for details.

There's an "lcolor_picker" command which opens a color picker dialog that outputs hue/saturation vals, that can be
used to set light color. For brush lights it's also possible to directly pick a color from the dialog by clicking
on the "Type:Omni" button.

Loading a mission that was previously lit with the new version of DromEd, will restore the lighting settings used.
For example if a mission is lit with objcast and 32-bit lightmaps, then lighting mode will be switched to objcast
and 32-bit as the mission is loaded. This ensures that a mission can be relit with the same settings as it was
previously relit, without having to remember or guess which settings were used. When loading missions from previous
DromEd versions, the lighting mode remains unchanged though.


HW Rendering in DromEd
----------------------

It's possible to enable hardware rendering for editor viewports when running with DX9 ("use_d3d_display"). This is
done with the config var "editor_disable_gdi", preferably in "dromed.cfg". It's recommended to also use a 32-bit
bit color depth in combination with HW rendering, "edit_screen_depth 32". Software only supports 16-bit color so
that's the default. HW rendering enables the use of z-buffering, texture filtering and colored object lighting
in solid view.

Even if multisampling is enabled for the game ("multisampletype"), it isn't enabled in edit mode by default. It can
be enabled there too with "d3d_disp_hw2d_msaa", but if you experience any problems or don't think it's necessary
then it's better to leave it off.

Although it should normally not be necessary, there might be some rare occasions (after device loss) where the
editor window doesn't get properly redrawn so the window is black. The command "redraw_all" will fix that.

These are HW related editor commands that may be of interest:

set_2d_tex_filter - Enable/disable texture filtering, default is enabled.
toggle_wire_zbuffer - Toggle the use of z-buffer when rendering wireframe debug visuals like show_phys_models,
default is disabled. When enabled wireframes won't be visible through walls, which can
be helpful to make the screen less messy. Only works if z-buffering hasn't been disabled.
toggle_2d_zbuffer - Toggle z-buffering.
editor_water_alpha - Set alpha used to render water surfaces in solid view, default is 0.5. The editor doesn't
use the actual alpha as seen in-game, because it's more useful to be able to see all level
geometry. This can also be set as a config var with the same name.


Updates to DARKDLGS.DLL
-----------------------

DARKDLGS.DLL provides most dialog windows in DromEd, such as the hierarchy window, properties editors etc.. Some
of those have additional features and adjustments.

The icons displayed next to properties have received two additions, to be able to distinguish between certain
property types. The first new icon is the /\ shaped one, three black dots connected with two lines (looks almost
like a pair of cherries). This is used for non-inheriting properties. These are properties that are automatically
instanced on concrete objects, but if absent, won't inherit their value from the parent object. The second new icon
looks like the standard black dot but is semi-transparent. This icon is used for transient properties. These are
properties that aren't saved. Usually they aren't edited in DromEd, they're mainly there for inspection / debugging.

Object Hierarchy dialog
-----------------------
Query - List all abstracts and concretes that have the chosen property assigned. The query will be performed
on the archetype currently selected in the list, and all its abstract and concrete descendants.
In the query results dialog you can edit the objects, properties and save the query results as a text
file. The result list displays abstract objects in bold and concrete objects normally (archetypes
which don't have the property but have to be included to display the hierarchy are also non-bold).
The query function is very useful in various situations. It's highly recommended that you play around
with it, to get to know it.
Export - Export the entire or parts of the object hierarchy to a text file. "Export Selected" will export
the archetype currently selected in the list and all of its descendants, including concrete objects
if there are any created. If you only want to export gamesys objects then do so before loading any
mission.
Filter - Filter on object names. The filter syntax is largely identical to the one in "DromEd Texture Palette".

Object Properties dialog
-------------------------
Copy/Paste - Copy/Paste properties between objects. Doesn't work for links or sources/receptrons. Copying
a property will also copy it in text form to the Windows clipboard, however the paste operation
doesn't use the Window clipboard.
Filter - Filter on property names. The filter syntax is largely identical to the one in "DromEd Texture
Palette".
Hierarchy Op - Replicate or delete selected (in list) property from descendants of the object. This can be
useful, for example, to clean up redundantly added properties from descendants, or to retrofit
all concretes in a mission with a non-inheriting property. Before performing any hierarchy
operations, it's recommended to inspect the relevant objects and property with the Query
function in the Object Hierarchy dialog, to make sure no unwanted changes will be made.

Operation:
Copy Property - Copy property to dest object, overwriting if already set.
Copy Property If Not Set - Copy property to dest object only if it isn't set.
Delete Property - Delete property from dest object.
Delete Property If Same Value - Delete property from dest object only if it has the same
value(s) as the source object/property.
Scope:
All Descendants - All abstract and concrete descendants are processed.
Abstract Descendants - Only abstract descendant are processed.
Direct Concrete Descendants - Only concrete descendants that inherit directly from the
source object are processed. If for example the source
object has an abstract descendant, which in turn has
concrete descendants, then these are NOT processed.

Links dialog
------------
Deleting ParticleAttachement (and the new DetailAttachement) links from the links dialog will now only delete
the link, and NOT the attached particle(/detail) object.

Other changes include smaller tweaks like dialog sizes, added list columns in some cases or usability like the
Add Link dialog not listing return/inverse links (instead it has a toggle ~ button for those) or confirmation
dialogs before deleting objects/properties.

The new texture palette is also provided by darkdlgs, but has its own section "DromEd Texture Palette" below.


DromEd Texture Palette
----------------------

There's a new, dialog based, texture palette in DromEd that replaces the old built-in one. It can handle more than
the old 256 entries, and has a number of enhancements. The basic functionality is still the same, while the palette
is open, textures are painted on surfaces in the solid 3D viewport. Here's a list of usage info and tips:

* The texture entries in the list window have different color codings to convey some extra information about them.
The slightly cyan colored ones mean that the texture is a family loaded texture, a texture that was loaded by
"add_family". Other entries (single loaded, sky or Jorge) are light gray. There can be a couple of dark gray
entries which cannot be selected, those are special textures which can't be used to map surfaces but are
part of the texture palette. Currently that should only happen for the default water textures.

* A texture entry may display one or more attribute flags, in the form of a white letter on a black square.
There are following attributes:

A - animated texture
T - transparent (image with explicit alpha, 8-bit image that uses pal index 0 or material flags forces alpha)
M - texture has a material file

* Water textures have an icon in the top left corner, identifying it as a water texture and also showing if it's
the texture seen when looking in to or out of the water.

* Right-clicking on a texture in the list brings up a context menu with a number of commands.

* Double-clicking on a texture is the same as Assign to Face in the context menu, it assigns the texture to the
currently selected brush face.

* A handful of texturing related DromEd hotkeys should work also when the texture palette dialog is the active
window, for the rest the DromEd window has to be in focus.

* The "Filter" control allows to only display textures that match the filter rules, the drop-list contains filter
presets for unfiltered (*), all loaded family names, non-zero usage count (>0) and 0 usage count (<1).

- Wildcard characters * (zero or more characters) and ? (a single character) are supported. A filter rule
implicitly ends with a * so it's not necessary to add one at the end manually.
Examples: "*wood*frame", "*wall?1".

- The filter string starts matching from the first character so the filter "wall" (which is the same as "wall*")
would only find textures that begin with "wall". To search for textures that contain the sub-string "wall"
you have to use the filter "*wall".

- To filter on family name the family portion of the filter has to end with a slash (/) or back-slash (\).
For example "mech/" would display textures that are part of the "mech" family. Wildcards can be used on family
names, like "*deco*/".

- A filter rule can filter on both family and texture name. For example "*deco*/*wall*" will show all textures
that contain the sub-string "wall" in any family that contains the sub-string "deco".

- A filter can be inverted (logical NOT) by prefixing with an exclamation mark (!). For example "!mech/" would
display textures from all families except "mech".

- To filter on usage count (number of worldrep surface or brush faces, depending on setting, the texture is used
on) use less-than (<) or greater-than (>) followed by a number. For example "<5" would display all textures
that are used on less than 5, or ">100" would display all textures that are used on more than 100.

- The filter string can consist of multiple ORed rules separated by semi-colon. For example "mech/;ArtDeco/"
would display all textures from either "mech" or "ArtDeco" families.

* The dialog title bar displays the current number of textures visible in the list, if there are filtered textures
it displays two numbers in the form "(num_visible_textures / total_num_textures)"

* The dialog can be closed with the Escape key, but DromEd's toggle texture palette hotkey also works, as well as
other standard methods of closing a window.

The "View Material" command opens a material file in Windows Notepad. If the material file resides inside a CRF
file, it's extracted to a temp file which is then opened in Notepad. It's possible to use a custom viewer by
adding something like following to LG.INI:

[Editor]
MaterialViewer=C:\Notepad++\Notepad++.exe


Build Dialog
------------

A one-stop build dialog has been added, which is invoked with the command "build_dlg". It provides configuration
options for worldrep optimization and various lightmap options. Using the build dialog is recommended as it removes
the requirement if knowing in which order to run the different processing stages, or executing a handful of commands
to configure the lighting settings.

The checkboxes are the different processing stages which can be enabled/disabled. Some stages implicitly also
process another, like for example processing the world rep will also relight even if lighting was unchecked.

* "World Rep (+ Lighting)" - Portalize.
"WR Quality" - Select optimized or draft portalization (unlike with the regular commands, it's
possible to switch back and forth using the build dialog).

* "Lighting" - Process lighting.
"Shadow Type" - Light tracing/casting modes (correspond to Quick, Raycast, Objcast).
"Shadow Softness" - Light sampling mode. "Standard" is the normal mode of previous DromEd versions.
The other modes work as if quad lighting was enable on all light source (object
and brush lights). The different sampling modes determine the sample pattern,
which affects the softness/blurriness of shadows. "High (4-pt avg)" corresponds
to how quad lit object lights worked (except that with this option, quad lit
would be applied to all lights, whether they are explicitly quad lit or not),
which isn't particularly good quality. Using "High (9-pt wghtd avg)" or one of
"Medium (5-pt wghtd avg)"/"Medium (9-pt wghtd avg)" are probably the best ones
because they produce the least possible lightmap blockiness. The former is
blurrier/softer, the latter two are less blurry. Which mode to use is an
aesthetic choice of the mission author.
The modes correspond to modes 0 to 7 of the "quad_lighting" command.
"5-/9-point Center Weight" - When using any of the 5 or 9 point sample modes, this value is used to define
the weighting value of the center sample. Increasing the weight will reduce
softness. For evenly distributed averaging the value should be 1.0/numSamples.
So for 5 point sampling a weight of 0.2 (=1.0/5) will make all 5 samples
contribute equally to the final result. For 9 point sampling the value would
be 0.11 (roughly =1.0/9). A center weight of 1.0 would result in only the
center sample being used, i.e. no softness at all. (Can also be changed with the
command "quad_lighting_cweight".)
"Lightmap Type" - Bit depth (and 32-bit LM mode) of lightmaps.
"Lightmapped Water" - Enable/disable lightmapping on water surfaces (can also be changed with the
"set_lightmapped_water" command).

* "Rooms" - Build room db (same as Compile rooms).
* "Pathfinding" - Build pathfind db.

"Brush Filtering" - Disabling brush filtering will include all brushes in processing even when
they're not visible because they're disabled by "Filter". (Can also be changed
with the command "set_ignore_filters".)


Loading Textured Group (.vbr)
-----------------------------

It's possible to load a saved group / virtual brush (.vbr) with preserved textures by using the "load_group_ex"
command. However it requires the group to have been saved with the new DromEd so that the vbr file contains texture
information. If the loaded group uses a texture that is currently not loaded in the texture palette, it will
normally add the entire family of that texture. If it for some reason can't add the family, such as max number of
families already loaded, it will attempt to load the texture(s) as single-loaded.


Exporting Terrain Mesh
----------------------

The worldrep (WR) mesh can be exported to OBJ (WaveFront format) files, with the command "wr_export_obj". OBJ
files can be imported in most 3D applications. The exporter creates an OBJ and a MTL file and exports texture
coordinates and texture filenames with full path so that OBJ file can be viewed with textures in a 3D app. This
however requires the family textures to be extracted, since 3D apps can't access CRF files.

The exporter dialog has two options, to export the mesh as triangles only and to include all portal polygons.
Using a professional 3D application can provide an easier way to inspect the worldrep and see what's going on,
if there are any problematic locations.


Fog Zones
---------

It's possible to have different fog settings in different areas of a mission by using fog zones. There can be up
to 8 fog zones additionally to the normal/global fog. A fog zone is essentially a fog preset and is selected in
the "Local Weather" property on room brushes, which instead of a simple checkbox now has a drop-list where you
can select Global Fog (normal fog) or one of the 8 fog zones. To configure fog parameters for zones, open
"Fog Zones" in "Mission Parameters..." (edit_file_vars).

Global fog can also be configured in the "Fog Zones" dialog, but the the original console commands also work. There
is however one new thing to note when using the console commands to change settings. When changing global fog
setting in game mode, those will be reset when returning to edit mode and have to be re-applied there if desired.
This is the result of global fog settings now supporting script control, so it has to be able to save the fog state
to savegame data and restore it.

The normal building rules and limitations for fog also apply to fog zones, so for example if you're standing inside
a fog zone cell and look into another non-fogged cell, then that cell will receive the same fog. Fog zones are
applied to the worldrep in the same fashion as normal fog, which is during room compile or portalization, so
changing settings on the "Local Weather" property by a script will have no effect. The fog configuration for fog
zones and global fog may be modified by a script though, so that the fog color and/or intensity can change while
playing.

IMPORTANT: Fog zones have one limitation, they do not work on sky surfaces. Due to how the sky is rendered, only
global fog settings will apply to sky components (that have Enable Fog set). That means that fog zones
should be contained to areas where you cannot see the sky from or through a fog zone region.


Ambient Light Zones
-------------------

Very similar to fog zones, it's possible to have up to 8 alternative ambient light settings in a mission. The zone
selection is also done in the "Local Weather" property on room brushes. The ambient light zones are configured in
"Rendering Parameters" under "Mission Parameters..." (edit_file_vars).

After changing the zone in "Local Weather" rooms have to be re-compiled and the mission re-lit (portalization would
also achieve this) for the changes to have full effect. After only changing the zone light levels the mission has
to at least be re-lit.

One thing to keep in mind is that objects between two ambient zones, like a door with two different ambient
zones on each side, will only receive one type of ambient lighting, that will be seen from both the front and
back. A little extra care may be needed if two ambient zones differ largely, possibly requiring a third ambient
zone with a light level in between, that is used on the doorway cell as a transition.

Each ambient light zone (including global ambient) also have an additional ambient light level parameter, used when
calculating an object's light level as seen by AI ("AI Vis Bias"). This allows having a bright daylight mission, or
bright parts of a mission with higher ambient level, where the AI light level (as also seen on the light gem) won't
go entirely black in locations where no brush/object lights reach.


Max View Distance
-----------------

The max view distance (beyond which z-buffering will not work and objects will visible through terrain and other
issues) is by default 256 units in the engine. When using the provided "cam_ext.cfg" it changes it to 512. However,
regardless of what user setting the max view distance is, a mission author may set a mission specific minimum view
distance required to correctly render the mission. It would be appropriate to do so for any mission that requires
more than engine default 256 units.

For example if you have mission where you have a large open area where the player can be positioned such that he
could see other parts nearly 400 units away, then setting the minimum required view distance to 400 would ensure
that everything always renders correctly, even if the user happens to have a shorter max view distance set. While
it certainly doesn't have to be precise, haphazardly setting excessively large values isn't recommended as it would
unnecessarily reduce Z precision.

The setting can be found in "Rendering Parameters" under "Mission Parameters..." (edit_file_vars), and is called
"Required View Dist". The default is 0 which means the mission works fine with the engine default (256).


New Texture Align Mode "AlignExt"
---------------------------------

Additionally to the already present modes AlignNorm and AlignBr, there's a new mode called AlignExt. It provides
more control by having separate U and V scaling (known as "S" and "T") values that can be non-integer values, and
even negative to mirror the texture. AlignExt also locks the texture to the brush face, so when the brush is moved
and/or rotated, the mapping still looks the same (with the exception of potential deformations due to grid
snapping). Although it's possible to have vastly differing U and V scales, note that it will also make lightmap
pixels non-square, which might not be desirable.


UV Mapping a Cylinder
---------------------

For easy UV mapping of a cylinder brush, where the texture will seamlessly wrap around the cylinder (or a portion
of it), there's a new command "uvmap_cylinder". The cylinder mapped faces will use the new AlignExt mode. While
it's possible to specify all the mapping params on the command-line, we'll stick with the dialog based variant
here. To map a cylinder brush, select a side of the brush (not top or bottom) where you want the texture to start.
Then assign the texture you want to use to that face, if it isn't already. Now run the "uvmap_cylinder" command
without any arguments. The dialog parameters are as follows:

"Num U Tiles" - Number of times the texture repeats around the cylinder (or faces if "Limit # Faces" is set).
"Num V Tiles" - Number of times the texture repeats from bottom to top of the cylinder.
"U Offset" - U offset, works like the "U" control.
"V Offset" - V offset, works like the "V" control.
"Limit # Faces" - If 0 the cylinder is mapped all the way around, otherwise it only maps the specified number
of consecutive faces, starting from the currently selected one. For example if "Nbr U Tiles"
is 2 and we limit mapping to 2 faces, then texture will repeat twice over the currently
selected face and the next one. The other faces will remain unaffected.
"Rotate 90°" - When this is checked the texture is rotated 90 degrees, so that it's sideways.


Stripped Mission Reconstruction
-------------------------------

It's possible to reconstruct room and light brushes in stripped missions, with the commands "reconstruct_rooms"
and "reconstruct_lights". Having the room and light brushes allows stripped missions to be relit and tweaked a
bit. The commands should only be ran once, or it will create duplicates, so for example if you run
reconstruct_rooms twice, or on a mission that already has rooms brushes, then you'll end up with duplicate
room brushes everywhere.

This functionality is a bit experimental so no guarantees are made on how accurate or successful reconstruction is,
however so far no immediate problems have been noticed.


Changed Prop: Script->"Trap Control Flags" (SS2)
------------------------------------------------

The property that was originally named "Trap Control Flags" in Shock, is now known as "Trip Control Flags". This
to avoid confusion with another dark property named the same, which was introduced to the engine after Shock.
The reason the Shock one was renamed is because it was inappropriately named to begin with, all internal names
and code related to the property, refer to it as "Trip Flags".


Changed Prop: Weather->"Local Weather"
--------------------------------------

The "fog" checkbox has been changed to a drop-list to allow fog zone selection. For more information about fog
zones see the "Fog Zones" section above. The equivalent of an unchecked box is now "Disabled" and for a checked
box "Global Fog".

An "ambient lighting" param has been added to select ambient light zone, see section "Ambient Light Zones" above.
The default(/original) behavior is "Global Ambient".


Changed Prop: Renderer->"Bitmap Worldspace"
-------------------------------------------

New param "Flags" was added, with following flags:

"Double sided" - Bitmap is visible from both sides (the backside will appear mirrored).
"Flip backside UV" - Mirror texture coordinates on backside of a "Double sided" bitmap (text would be
readable).
"Lit" - Apply object lighting to bitmap object.
"Face camera (axial)" - Bitmap always faces camera while rotating around the image's Y axis.
"No UV Tiling" - Disable UV tiling (not visible in editor, only in-game).

New param "Axial Fade" that enables alpha fade out when the viewer gets closer to being parallel with the axis of
rotation on a "Face camera (axial)" bitmap. Useful for certain effects, like light beams, to make the bitmap
invisible when the viewer is at an angle where the flatness and face-the-camera effect would become too jarring.
When "Axial Fade" is 0 the fade effect is disabled. Increasing the value, up to 1.0, increases the angle (from the
axis) at which fade out begins.


Changed Prop: Renderer->"Anim Light"
------------------------------------

The property can now be used to animate a dynamic light, instead of a regular immobile anim light. This is done
by checking the "Dynamic Light" checkbox. Radius and quad lit parameters are ignored for dynamic lights.


Changed Prop: Renderer->"Corona"
--------------------------------

There are following new parameters:

"flags" - see below
"color" - Color to multiply the corona texture with, white will result in the texture to appear
in original color (so for example when using a grayscale texture it be used to create
coronas of any color, not requiring one texture for each color).
"spot angle scale" - When flag "Use Spotlight Cone" is set, the spotlight cone angles are multiplied with this
factor, allow to adjust the angle visibility of the corona.

Following flags can be set:

"Blend Add" - Render the corona using additive blending.
"Use Spotlight Cone" - Apply spotlight cone (from the Spotlight property) to the visibility of the corona,
so that it fades out towards the outer cone angle.
"Track Moving Object" - Update the corona position along with the object (used on moving objects)
"Detail Attached Proxy" - Use the Anim Light / Spotlight properties of the object that this object is attached
to with a DetailAttachement link. Allows attaching multiple coronas to a single
light object.


Changed Prop: Renderer->"Render Type"
-------------------------------------

Additional "Corona Only" render type. When this is set on an object, the object itself will not be rendered, but
if it does have Corona set, the corona will still be visible. This render type provides a clean way (no invisible
polys/objects being rendered) to create corona only objects. The best way to do that is to create a bitmap object,
using some small dummy bitmap (like "snow") which will not be visible anyway, set the render type to "Corona Only"
and add the Corona property. The size of the object should be changed to match the corona max size, so that it
doesn't prematurely disappear from view.


Changed Prop: Physics->Model->"Attributes" (OBB)
------------------------------------------------

The "Is Edge Trigger" checkbox in OBB physics attributes has been changed into "Flags" and some new flags have
been added. The new flags are:

"Apply Platform Friction" - When "Apply Platform Friction" is set, friction will be applied when the player
is standing on it. For example if it's used on an object based staircase (with an
OBB shape), the player can stand still on it where he normally would slide down.
"Pushing Vator Attachments" - Moving terrain objects with Collision Type None now have a slightly different
movement handling, to ensure their movement is framerate independent. (Previously
there were problems with slow moving camvators moving at noticeably different
speeds depending on framerate.) This doesn't work well if the vator pushes other
phys objects, like an elevator does. Normally not a problem since the Collision
Type is None, but in the rare case that a non-colliding vator has physics
attachments which are supposed to collide, setting this flag could help (at the
expense of not being entirely framerate independent anymore).
Ideally all movement should be framerate independent, but for technical reasons a
small portion of movement is normally affected by framerate.


Changed Prop: Receptron Effect "Poke Object"
--------------------------------------------

The effect has been corrected to work as originally intended, to "Spoof Damage to an object. 'Tickle' it, so it
takes no damage, but acts as if it had taken damage", by generating a damage event with 0 damage. Previous behavior
was incorrectly identical to "Damage Object". The "Damage Object" specific parameter values have been removed
in the process.


Changed Prop: SFX->"Particles"
------------------------------

The particle type "Bitmap disk" has been added. It works like a "Single-colored disk" with enhancements, but
instead of using an internal disk image, it uses a user specified bitmap, like "Scaled bitmap" particles also do.
However unlike "Scale bitmap" particles, if the bitmap is animated and animation is enabled, each particle will
play the animation. Another difference to other particle types is that the "Transparency (alpha)" property
(and "Distance Alpha") affects them. The following "Bitmap disk" specific parameters are available:

"bm-disk flags"
---------------
"Use Lighting" - Apply object lighting to particle group (only a single lighting value at the
origin is calculated so it may not be suitable for large particle groups).
"Fade-in at Birth" - Fade in alpha from 0 to "alpha" during birth phase.
"Grow-in at Birth" - Grow particle from (near) 0 size to "size of particle" during birth phase.
"Random Start Frame" - Randomize start frame per-particle for animated bitmaps, if animation is disabled
this will select a random frame for each particle.
"Play Ani Once" - Play an animated bitmap once and stop on the last frame.
"Use RGB Colors" - Use alternative RGB color param(s) instead of the normal palette based color(s)
"Fade RGB->2nd" - Enable color fading from primary RGB to 2nd (requires "Use RGB Colors")
"Fade RGB->2nd->3rd" - Enable color fading from primary RGB to 2nd to 3rd (requires "Use RGB Colors")

"bm-disk birth time"
--------------------
Duration of birth phase, if 0 there is no birth phase, make sure that birth time isn't too long so it
interferes with "particle fade time".

"bm-disk rot (vel, offs, rand)"
-------------------------------
Rotate particle texture. It doesn't rotate the actual particle, only the UV coordinates, so the bitmap's
contents should fit a disc-shaped area to avoid the poly edges from becoming apparent. There are three
rotation params, 'vel' is the rotation speed, 'offs' is how much each particle's start rotation is offset
from the previously launched particle, 'rand' is the amount of random rot speed variation to apply.

"bm-disk ani frame time"
------------------------
Controls the rate at which animated bitmaps animate, if the value is 0 then animation is disabled.
Be aware of that using animated textures may degrade performance because rendering of the particles
can be split up a lot when switching textures back and forth, so it may be a good idea to not have
an excessive amount of particles in such cases, or only use the effect in areas that aren't performance
heavy.

"bm-disk grow speed"
--------------------
The speed at which particles grow after the birth phase, defined as percentage of "size of particle".

For easier selection of palette index for particle colors there's a "pcolor_picker" command, which opens a color
picker dialog that will output a palette index with a color that is the closest match for the picked color.


Changed Prop: AI->"Efficiency settings"
---------------------------------------

There's a new "Flags" parameter, with following flags:

"Allow Effic. While Visible" - Allow AI to enter/stay in efficiency modes even if it's visible on screen. By
enabling this option the AI "skating" bug re-activates. This option is required
on metaproperty M-ZombiePossum in order for zombie resurrection to work.
The option is effective regardless of whether "Enabled" is checked or not.
"Allow Effic. While Combat" - Allow AI to enter efficiency modes while in combat. By enabling this option the
bug where AIs can freeze during combat, when the player moves far away, and then
stay frozen even if the player comes close again, is reactivated. This option is
required on metaproperty M-ZombiePossum in order for zombie resurrection to work.
The option is effective regardless of whether "Enabled" is checked or not.


Changed Prop: Tweq
------------------

Tweqs have two new "CurveC" flags:

"Pendulum(/BounceHi)" - This provides a sinusoidal curve between "low" and "high" limits, like a pendulum. When
it's set the "NoLimit" AnimC flag has no effect. The "rate" is defined as swings per
second, where a swing is from low to high or from high to low, so a rate of 1.0 on a
rotating joint tweq would swing with the same timing as a pendulum in a grandfather
clock. When "Bounce" is set this flag will have a different meaning, it tells the bounce
to occur at the high limit instead of the low limit.
"Bounce" - Essentially identical to "Pendulum" except that one side of the swinging motion will
abruptly change direction like a bounce. By default the bounce occurs at the low limit
but also setting the "Pendulum(/BounceHi)" flag will make it bounce at the high limit
instead (it can't bounce at both high and low).


New Prop: Renderer->"Alpha Blend Mode"
--------------------------------------

Select custom alpha blending mode for transparent objects. Most useful is the "Add" blend mode for effects that
in reality emit light in some form, like for example fire and explosions, to make the effects less dull. The
blend mode presets correspond to following blend mode pairs (as also used in materials):

"Normal" - [SRC_ALPHA, INV_SRC_ALPHA]
"Add" - [SRC_ALPHA, ONE]
"Multiply Dest" - [DST_COLOR, ZERO]
"Multiply Dest and Add" - [DST_COLOR, ONE]
"Multiply Inv Dest" - [INV_DST_COLOR, ZERO]
"Multiply Inv Dest and Add" - [INV_DST_COLOR, ONE]
"Multiply Dest 2X" - [DST_COLOR, SRC_COLOR]


New Prop: Renderer->"Alpha Test Threshold"
------------------------------------------

Set custom reference value for alpha test operations. Alpha tested pixels that have an alpha value below this
threshold won't get rendered. Only has any effect if the object has any surfaces that are rendered with alpha
testing. The value range is 0.0 to 1.0, where 1.0 corresponds to a 255 alpha value.


New Prop: Renderer->"Render Order"
----------------------------------

The default render order of objects is

1. Render opaque (that don't have Renderer->"Transparency (alpha)") objects, the order in which they are
rendered is undetermined.
2. Render transparent objects sorted by viewing distance.

With the "Render Order" property there are a few more steps available for opaque objects, that allows some control
over which objects are rendered before or after others, which can be used to solve render order problems in
certain cases. For example if there are transparent decal objects, which are only placed on terrain surfaces, one
could configure those to be rendered prior to any other objects, thus avoiding alpha sorting problems if such are
present.

The extended render order is

1. Pre Opaque 1
2. Pre Opaque 2
3. Pre Opaque 3
4. Pre Opaque 4
5. Render standard opaque objects (which don't have any "Render Order" set)
6. Post Opaque 1
7. Post Opaque 2
8. Post Opaque 3
9. Post Opaque 4
10. Render transparent objects

The property also has the option to render the object without updating the z-buffer. Which could help avoid
z-fighting or a decal sticking through other objects, if the object is known to be (or should appear) flat against
a terrain surface.


New Prop: Renderer->"Camera Overlay"
------------------------------------

The property can be assigned to objects that have, or can have, a camera attached to have a custom camera overlay
rendered while the camera is attached to it. The object could be the player, or for example a scouting orb. If
the "Camera Overlay" is active it will override any default overlay of the game. In other words if a custom overlay
is set on scouting orb, it will be used instead of the default overlay effects for it.

An overlay can either be a color tint on the entire screen, like the coloring when the player is under water, or
a bitmap. For example a black bitmap with two holes "cut out" in the alpha channel to get a viewing-through-
binoculars effect.

The bitmap is loaded from the "BITMAP\" dir, like with bitmap particles, except it can either be a single texture
with one image file in "BITMAP\" or it can be an animated bitmap with numbered files in "BITMAP\txt" or "txt16".

In order to deal with different display aspect ratios when using a bitmap overlay, there are following scale modes:

"Scale to fit screen" - Bitmap is scaled to cover the entire screen, shapes will look stretched/squished
depending on if viewed on 16:9 or 4:3.
"Fit 4:3, mask w. color" - The bitmap is treated as a 4:3 image (regardless of its actual dimensions) and
is scaled to fit screen while maintaining the 4:3 ratio, the empty areas on the
sides on widescreen displays will be filled using the specified "Mask color".
"Fit 4:3, mask w. edge" - Same as above except that instead of filling the sides with the mask color, it
uses the edge pixels of the bitmap and stretches them outward.
"Crop 16:9, mask w. color" - The bitmap is treated as a 16:9 image, and if the display aspect ratio is
narrower the image will be cropped, down to 4:3 at most (the bitmap should be
created so that it looks ok when cropped to 4:3, but giving 16:9 user a little
extra fluff). In the unlikely event that masking is required, it's done the
same way as "Fit 4:3, mask w. color".
"Crop 16:9, mask w. edge" - Same as above except masking is done like "Fit 4:3, mask w. edge".

If the bitmap object has multiple frames the animation rate is set with "Ani frame time (ms)" as the duration, in
milliseconds, per frame. A value of 0 disables animation.

The "Filter color" is multiplied with the bitmap, so if the bitmap is black it has no effect, if it's white it will
end up using the filter color as is. If no bitmap is used, the filter color is used as the tint color for the entire
screen.

"Alpha" sets the overall transparency, including any masking areas. Setting alpha to 0 will skip overlay drawing
and can be used if you want to disable a native overlay without wasting any rendering time.


New Prop: Renderer->"Light-based transparency"
----------------------------------------------

This property can be set on AI objects and uses the AI's visibility value to continually update the
Renderer->"Transparency (alpha)" on the object, so that they become more or less transparent depending on how
much light they receive. Whether they become more transparent in light or less transparent can be controlled
by setting the "Light level" params accordingly.


New Prop: Renderer->"Force Static Shadow"
-----------------------------------------

When this property is set on objects that are NOT immobile (Object System->Immobile), they will cast shadows
on lightmaps anyway (when doing objcast lighting). This can be useful for example so symmetrical rotating
machinery can cast shadows.


New Prop: Renderer->"Distance Alpha"
------------------------------------

Distance based object alpha/transparency. This is used to make object transparency change, based on distance from
the viewer, to either become more or less transparent when the viewer moves away. There available parameters are:

"Near Alpha" - Alpha value to use when viewer is at a distance of "Near Distance" or closer.
"Far Alpha" - Alpha value to use when viewer is at a distance of "Far Distance" or further away.
"Near Distance" - Distance from object where alpha will be "Near Alpha", must not be larger than "Far Distance".
"Far Distance" - Distance from object where alpha will be "Far Alpha"
"Falloff Type" - Controls the curve that the alpha will fade based on distance:
"Linear" - Changes at a constant rate.
"Smoother at Near" - Levels out as viewer gets closer.
"Smoother at Far" - Levels out as viewer moves away.
"Anim Light" - Optional concrete object id of an object with the "Anim Light" property, where the brightness
of the animated light is used to control alpha. This is useful when a bitmap object is used
for light cone effects so that the light cone animates along with the light.
It can also be set to "-1" to let it use the object connected through a "DetailAttachement"
link as the anim light object. Especially useful when creating archetypes of anim light
objects that have linked light cone effects.

In order for this property to have any effect, the object also has to have the "Transparency (alpha)" property set.
The Distance Alpha alpha value is multiplied with the alpha from the Transparency property.


New Prop: Renderer->"Bitmap Color"
----------------------------------

Optional color to multiply bitmap objects with. Especially useful when used in combination with grayscale bitmaps,
allowing a single bitmap to be used to produce bitmap objects of any color.


New Prop: Door->"Static Light Pos"
----------------------------------

When enabled, the lighting calculations for the door will use the door's closed position to find which lights are
reaching the door. It's a hack/workaround to avoid lights instantly flipping on or off when a door opens/closes.
Especially noticeable with sliding doors in SS2, where the lights often get obstructed by the wall as the doors
slides into it and the door suddenly turning nearly black, or vice versa.


New Prop: Creature->"Creature Scale"
------------------------------------

Scale a creature object, a value of 1.0 means original size. Physics models are not scaled in size, but their
position is adjusted correctly. Keep in mind that reducing the size of an AI will not magically allow it to
move through smaller doors/openings, because pathfinding can't support it.


New Prop: Creature->"Disable Head Track"
----------------------------------------

Disable head tracking for a creature object.


New Prop: Inventory->"Block Frob?" (T2)
---------------------------------------

Same as the SS2 counterpart, made available to T2. Allows objects, like windows, to block frobbing through them.


New Prop: Difficulty->"Remove Properties"
-----------------------------------------

Similar to the "Destroy" property, but instead of destroying the object it removes one or more properties from
it. It has two difficulty sets, the alternative set can be used by prefixing a property name with a "!". The
property names are the internal names, which can be listed to file (proplist.txt) with the "dump_props" command.
When specifying several properties they must be separated by commas and no spaces in between.

Ex:
quest var values 0, 1
alt quest var values 2, 3, 4, 5
Properties PickCfg,!KeyDst

Will remove the PickCfg property on difficulty levels 0 and 1, and will remove the KeyDst property on 2 - 5.


New Prop: Editor->"Design Note" (SS2)
-------------------------------------

Same as the T2 counterpart. Note that custom OSMs in SS2 use another property for user script parameters, those
will NOT use Design Note unless they are updated.


New Prop: Editor->"Editor Comments"
-----------------------------------

This property provides what "Design Note" was originally intended for, a property where mission authors can put
notes about an object. The comments can include line breaks. This property is only available in DromEd and not
in the game exe.


New Link: "DetailAttachement"
-----------------------------

This link type can be used to attach non-physical objects, aka detail objects, to other objects. It more or less
works just like "ParticleAttachement" links but also allows specifying an offset transform and attaching to
sub-objects (like for example a door handle). Just like particle attachments, archetypes may contain detail
attachments. When creating a concrete from such an archetype, the attached objects will automatically be created
and linked too, and when the object is deleted the attached objects are deleted along with it.

The command "dattach_link" can be used to create or update a DetailAttachement link between two (concrete) objects.
The relative pos/rot of the created/updated link is automatically calculated so that that the current world
location of the detail object remains unchanged. That allows visually placing and aligning a detail object where
you want it, and then create the link with the correct vals.

There's a special type "Transparent Decal" that attaches to an object like the "Object" type, but it's a special
purpose link type that can be used to attach transparent decal objects to a transparent object. For example if you
have a blood decal that uses full alpha that you want to place onto a window object, it will most likely cause
alpha sorting problems (it will be on top of the window from certain view positions and below from others). This
can be solved by detail attaching the decal to the window with the "Transparent Decal" type. In order for this
link type to work the decal object must have "Has Refs" set to FALSE/unchecked. Using the "dattach_link" command
it will automatically add the "Has Refs" property with the correct value.

The "Transparent Decal" link type makes use of two additional params "decal plane norm" and "decal plane dist",
which define the plane (in object space) onto which the decal is placed. For example for the top surface of a
cube shaped object with dimension 2, the normal would be [0 0 1] and the plane dist 1, the bottom surface would
be [0 0 -1] and dist 1. When the transparent object is rendered it can then determine if it's behind or in front
of that plane to know if the decal should be rendered in front of behind. For box/OBB shaped objects like windows
and doors, you can usually avoid dealing with the plane parameters if you use the "dattach_link" command, it will
try to automatically determine the plane.