Introduction.

Xash3D is a Half-Life-compatible engine, so all its features are showcased with respect to GoldSource to
demonstrate how much better Xash3D is.
------------------------------------------------------------------------------------------------------------------

Basic limits.

Xash3D limits are not just higher than Half-Life ones, they're also can be tuned in gameinfo.txt file.
MAX_EDICTS is 600 - 4096 (versus 900 in Half-Life).
MAX_TEMPENTS is 300 - 2048 (vs. 500).
MAX_PARTICLES is 1024 - 8192 (vs. 4096).
MAX_BEAMS is 64 - 512 (vs. 64)
Careful limits reduction can save RAM in mods which don't need many edicts.
Also MAX_EDICTS parameter is broadcasted from server during a multiplayer session, it adjusts clients to new conditions automatically.

Other limits.

These limits are hardcoded into the engine and cannot be tuned by user.
MAX_VISIBLE_PACKET is 512 entities (256 in Half-Life).
MAX_MODELS is 2048 unique models (including sprites and bmodels)
MAX_SOUNDS is 2048
MAX_SENTENCES is 2048 (1534 in Half-Life)
MAX_USER_MESSAGES is 191 (128 in WON Half-Life)
MAX_TEXTURES is 4096 (2048 of them can be used for VGUI)
MAX_MESSAGES is 2048 (1024 in Half-Life) (quantity of messages in titles.txt)
Maximum size for indexed textures is 1024õ1024 (vs. 512õ512 in Half-Life)
Maximum size for true-color textures is 4096x4096.

Limits for BSP-models.

#define MAX_MAP_MODELS 1024 (256 in half-life)
#define MAX_MAP_LEAFS 32767 (8192 in half-life)
Note: other BSP-model limits are set in compiler and don't depend on the engine.

Studiomodel scaling support
Spirit Of Half-Life mod includes an interesting ability to tweak visible size of any studiomodel by the "scale" variable.
However, this ability doesn't affect physical boundaries of the scaled model.
Xash3D addresses this issue. You can toggle the scaling via the "sv_allow_studio_scaling" variable. This variable is saved in config.cfg and also broadcasted to all players during a multiplayer session.

Attachment angle receivement on server side.

As you might know, the GET_ATTACHMENT engine function doesn't return angles for attachment (this capability is absent
from both engine and model compiler). Xash3D partially allows to fix this by returning direction from bone to attachment, which is considered to be forward vector and completely matches the vector you see
in Half-Life Model Viewer (of any version) if you switch to attachment view.
This capability might be useful for implementation of things like headcrab that jumps off the killed zombie,
realistic laser sight position on viewmodel, and others where attachment angles are needed.
This option is turned off by default, you can turn it on by changing "sv_allow_studio_attachment_angles" variable to "1".
It is saved in config.cfg as the previous feature, but it doesn't affect the client.

Realisitic lighting values on server.

Xash3D allows to get more accurate value of current lighting level, because it considers lightstyles
and their current values. In next versions, entity brightness will be calculated for flashlights of every player
(e.g. in multiplayer). The player's lighting is taken directly from renderer and considers all lighting types,
including entity light and dynamic light.

Saveable camera (trigger_camera)

It is known that Half-Life doesn't restore a camera's state on save & load. This issue can interfere with
a proper gaming experience sometimes. It is successfully fixed in Xash3D. Now the state will be kept unchanged
after save & load.

Improved decal save

Half-Life supports decal save only on world surfaces and very rare on doors, elevators and other moving models.
Xash3D saves decals on every brush model.
Decal transition between levels is also maintained (implemented in Half-Life, but doesn't really work).

Entity patch technology support

This technology allows to load entities from external .ent script file.
This script can be produced by the external ripent.exe application or by engine's facilities by typing
the entpatch command. If the command is entered when a map is loaded, a new entity patch will be created.

Various map formats support

Xash3D supports following BSP-map formats: Quake 1, Half-Life, Half-Life Blue Shift. Besides, Quake 1 external
bmodels are supported (medikit and ammo models).
Note: it is recommended to play Quake 1 maps in Deathmatch Classic mod to prevent stuckness of player
because of the difference between hull's sizes of Half-Life and Quake. Besides, DMC supports all entities needed
for complete deatmatch experience on Q1 maps.

Hot resource precaching support

Xash3D allows to precache models "on the fly" that helps to avoid nasty PF_PRECACHE_ERROR. Also Xash3D doesn't crash
if a model or sound wasn't found.

Reliable message transmit from user to client

Xash3D doesn't crash, if user message exceeds the declared size, or if the size wasn't declared at all.
This message will not be sent and user will be notified via console. Also, the SVC_TEMPENTITY message is
completely safe, like user's ones.

Reliable changelevel.

Before switching to a next map Xash3D will analyze its state (without unloading the current map) and decides
whether correct changelevel procedure is possible. In case of any error in a next map the engine will signal about
it in the developer's console, and the changelevel will be aborted. The error message also contains troubleshoot tips
that can make level designer's life easier, because such errors are most difficult to diagnose and fix.
In some cases Xash3D can turn smooth changelevel off on one's own
and turn on the classic changelevel as in Quake. Respective error message will be printed in the console.

Built-in credits

To display credits and exit the game after, run the pfnEndSection command with oem_end_credits argument.
The credits code is placed in menu.dll and can be changed by user at his discretion.

Recursive search of visible entities.

Xash3D supports recursive search of visible entities on server, at their additon to visible-list for client.
You can see implementation's example of such search in SDK in SetupVisibility and AddToFullPack functions (client.cpp).

MOVETYPE_PUSH physics is more stable

Xash3D entities behave more stable on moving platforms and don't shift away on sharp turns.


New MOVETYPE_COMPOUND physics type

It allows to tie one entity to another, taking into account movement and rotation of the former entity. You can see an example in SDK - a crossbow bolt that correctly attaches itself to func_pushable, func_rotating, func_tracktrain and other brush models.

Time freeze

The engine has a capability to stop time using playersonly command (same as in Unreal Engine). This command freezes
both client and server physics excepting player.
It might be useful for taking screenshots or for physics stability testing and other debug operations.

Transparent filesystem

Xash3D ignores the "wad" field in map and doesn't crash if a wad file wasn't found.
GoldSrc could require wads without any check of their real use, so this annoying whim is now gone. Xash3D
can load textures from wad files via pfnLoadFileForMe function on server and COM_LoadFile on client and in the menu.
Just specify texture's name in wad file and the engine will find it. You can also specify needed
wad file in the path, if you want to load the texture specifically from this file. Example: "gfx.wad/conback".

Console autocomplete support

Xash3D has a powerful console autocomplete system that allows not just print command lists,
but also describe all of them during the search. For more comfort you can type
makehelp in the console, and the engine will generate help.txt that contains the list of all commands and variables with
short descriptions. Map, movie, background track, cfg script, save, weapon (give command), sound (play command), game directory names input is also assisted by the autocomplete feature.

No parent directory restriction

Most Quake engines are restricted to the parent directory with specific name, which doesn't matter
when you make mod, but very uncomfortable when you make total game conversion and therefore replace the parent directory. Xash3D doesn't restricted to specific folder, and the parent directory is defined by the launcher. This way you can make your
own game that doesn't depend on Half-Life.

Better console for dedicated server

Dedicated server has the autocomplete feature now, your command history can be saved.

Colored console messages

Xash3D supports color prefixes for console messages first featured in Quake 3.
The prefix system implies input of ^ symbol with a single digit from 0 to 7, where the digit denotes the color.
0 is black, 1 is red, 2 is green, 3 is yellow, 4 is blue, 5 is cyan, 6 is purple, 7 is white.
This color table is fully compatible with Quake 3 and works similarly - string will be colored until,
until carriage return or ^7 control code that cancels coloring. This system also works in the menu
and can be utilized to decorate player's nickname.
Note: VGUI support can be toggled by "vgui_colorstrings" "1" console variable.

Auto-levelshots system

The engine supports individual levelshots system for every level. To activate it, type "allow_levelshots" "1" in the console. Xash3D will make screenshots automatically, but you can replace them with your own, indeed.

Background maps support

Background map is a map to be displayed as a menu background. You could see them in Half-Life 2.
Xash has a simplier background map system - it doesn't depend on unlocked chapters (because original Half-Life has no chapters system) and it chooses the background map from the list.
This list file must be named as chapterbackgrounds.txt and placed in scripts directory (if you don't have such directory, then just make it). Every list's entry is separated by new line.
Example:

ñ1a1a
c2a1
c4a3
c2a5
c0a0

You can use any playable map as the background, but better don't use maps where player starts in a moving train,
because it won't look good.

Sprite interpolation

Turned on by default. It is supposed to make sprite animation smoother with texture and additive rendermodes.
You can toggle it via "r_sprite_lerping" variable.
Note: to ensure correct performance of this feature, server framerate must be 10 frames per second
(regardless of sprite's FPS in pev->framerate). This parameter is conditioned by think time of
sprite's frame change function in 0.1 sec and constant for most mods.

Lightstyle interpolation

Turned off by default. Doesn't work with short sequences like switching on and off the light.
It smooths light animation very well on long slow sequences like SlowStrobe or SlowPulse.
Note: FPS rate may suffer from this option.

luma glowing textures support (Quake-style)

You can see such textures in original quake maps as glowing fields on a texture.
Because this feature is caused by the Quake pallet's special features, the engine enables it
for textures that have Quake èëè Quake2 pallet. This pallet is saved well after the simple conversion
of wad2 files to wad3. As an example, this can be observed on Scrama's qstyle map.

Improved model and sprite lighting

Improved model lighting includes per-bone lighting from static and dynamic light sources,
and it also includes correct model lighting on every stage of long sequence execution, when model goes far enough from its real location. The best example is forklift.mdl Sprite lighting is a correct lighting of all sprites that is rendered in additive mode
and had "alphtest" during the compilation. For example, blood decals uses the world lighting and doesn't glow in darkness.
Both sprites and models don't just use the world lighting, but also consider lighting of the closest brush model
if there is one.
Note: if improved lighting doesn't work correctly in some games, you can turn it off
using "r_lighting_extended" "0" command.

Playlist for standard background tracks

Half-Life mp3 file names that replaced AudioCD-tracks are hardcoded in engine and cannot be changed.
Xash3D automatically makes playlist for such tracks and you can include your own tracks or
"blank" keyword if there is no track. The playlist is called audiocd.txt and placed in media folder.

Save-shots and demo-shots support

Save-shots and demo-shots are thumbnails of the game screen during the save or start of demo. You can see them in the
menu in appropriate sections.

Player model display in the menu

Instead of a usual player image you can see his 3D model in the menu and track all changes right on-the-spot.

Dynamic skybox change

You can change skybox during the game using "sv_skyname" command, for example by CVAR_SET_STRING.
This change would be kept after save & load. You can also change skybox via "skyname" command.
This command is similiar to "sv_skyname", but works only for local client so it can't be saved.

NPC flicker on trains and elevators

Xash3D doesn't have the GoldSource bug that cause NPC to flicker on moving elevators and trains.
This fix is compatible with all mods, including latest versions of SoHL:Custom Build.

More efficent hidden surface determination

Xash3D uses more efficent culling system that can increse FPS rate and decrease r_speeds.
Besides, you can use "r_lockcull" command instead of "r_lockpvs" to increse culling efficency. The engine supports so-called static brush system that makes every bmodel the part of the world so they are drawn alongside of world polygons, if the bmodel has normal rendermode, zero coordinates and zero rotation angles.
It improves performance on highly detail maps with use of func_wall (see Scrama's Dm-knot map for example).
Though this system might cause noticeable z-fighting for some old-fashion maps made in Worldcraft Editor or Valve Hammer
Editor, which use integer coordinates to describe object location. In such case it is recommended to switch off static brush
system via "gl_allow_static" "0" console command.

Loaded textures browser

You can browse loaded textures using the "r_showtextures" command. Argument of this command
defines different texture groups. 1 - system textures, generated by the engine automatically.
2 - HUD and menu textures. 3 - map textures. 4 - loaded sprites' frames.
5 - loaded studiomodels' textures. 6 - lightmaps. 7 - decals. 8 - VGUI textures.
9 - skybox textures.

Note: sometimes tab might contain too many textures to display them all at once. Try to increase screen resolution in this case.

Automatic sort of transparent surfaces

This method ensures that all transparent surfaces will be drawn in the right order, by distance from an observer.
This isn't guaranteed in Half-Life.

-------------------------------------------------------------------------------------------------------------------

Conclusion
This list will be extended when new features are implemented.