ATX Readme

ATX is a modification for the PC game Trespasser, by DreamWorks Interactive, meant
to provide a slew of extra features to the game, including new cheats, dino options,
graphical optimizations, technical help, and mostly, level-design addons.
It consists of a DLL, a single executable hack, and few other essential files.
It has recently been revamped (versions 2.00+).

Particularily, ATX allows level designers to use supplemental ActionTypes in their
levels and combines many new features as well as a few older ones into a
single package. The new ActionType values are defined using an external
DLL that automatically detects the associated executable upon loading.
This system permits the update of the small DLL file without having to update
the executable more than once. New ActionTypes are programmed to use existent
T-Script entries and are recognized by Trespasser as valid functions. All other
features use self-modifying code to be applied from the DLL.

Full documentation of new ActionTypes, cheats, and other features is provided
as well as full FASM assembly source. Source is open for modification and may be
base for others to take credit as long as the end result is reasonably different
from the original code.

ATX has been generally tested to work with the following operating systems:
Windows ME, Windows 98 SE (with and without unofficial update), Windows
2000 Professional w/Service Pack 4, Windows XP Home, Windows XP Professional (w/SP1-SP3). However,
only Windows 2000 Professional w/SP4 (w/Update Rollup 1) is regularly used
to test all the new features. Later versions of ATX have also been known to
work on some versions of Linux (particularly WINE) (see FANSFAQ).

Please keep in mind that this is strictly a BETA-stage modification. There are
still many bugs/errors/crashes present, even though they may not be initially
obvious. It may perform differently depending on your system, and you may run
into problems. If this is the case, I would appreciate receiving notifications
of such problems via the Trescom message board or by e-mail; please include a
description of the problem, your executable type and operating system, error.log
and/or ATX_LOGFILE.txt log files, and screenshots if needed. However, please read
the Known Bugs list beforehand to avoid submitting previously-known bugs. Thank you.

WHAT’S NEW?

V2.13:
- public release version increment

V2.12:
– Updated assembler version used for ATYPEX and RECCOMPRESS to FASM 1.68 (others utilities don’t need re-releases at the moment).
– Added aspect ratio and FOV settings in ATXconfig.ini, under [Variables] (see FIELD OF VIEW SETTINGS)
– Reorganized parts of the ATYPEX source code into a nicer (standardlibrary, core, features) division.

V2.11:
– code cleanups and fixes

V2.10:
– public release version incremementation

V2.09 (DLL release only):
– re-packaged the separate ATX Executables package to include a demo EXE without CD verification along with
a generic ATX patcher (previously unreleased, supersedes the Demo-Only patcher), and added the ATX patcher
source code (previously unreleased) to the ATX source package
– updated ActionType 114 to include inner randomization of locations within a chosen group (requested by Drac)
– implemented SMK VIDEO PLAYBACK RESIZING for ActionType 105 (requested)
– tons of documentation cleanups, new table of contents
– a (very) few source code cleanups

V2.08 (DLL release only):
– added ESC key fix for in-game menu (see MENU KEYS FIX)

V2.07:
– added TN cheat (same as TNEXT cheat but does not erase cheat name from console after entry)
– additive TPAs: fixed bad cleanup code which caused crashes upon exit and level reload
– added file attribute override for SAVEDMAP.xxx when saving (i.e., read-only)
– updated RECCOMPRESS.exe utility to paint window properly after selecting file
– updated internal game state detection (i.e., menu, console, in-game) to coincide with game’s method of detection (more reliable)
– updated internal game time tracking to coincide with game’s tracking methods (more reliable)
– fixed default fog color being read from ATXconfig.ini even when override was disabled
– fixed AT105 (Play SMK) crashing in triggers with more than one ActionType (stack error)
– updated CANIMAL cheat to provide more display options and values
– added DUMP screen text capture cheat

V2.05:
– added HUD cheat to documentation (thanks to Draconisaurus for the heads-up)
Note: HUD can be toggled using the new hotkey system, as any other cheat
– fixed AT115 (Use Object/Fire Gun) crashing during level load
(caused by code rewrite typo and bad stack adjustments – thanks to Rebel for report/testing)
– added Name Hash (CRC32) info for CAnimal and OBJ/OBJN cheat displays
– added some general-purpose new ActionType logfile writing code (largely unused)
– new ActionType – 120 – Set Trigger FireCount and Probability
– fixed AT103 checking wrong variable for which weapons to reload
– fixed AT103 not accepting certain ammo values
– new ActionType – 121 – Reload Standalone Gun (similar to AT103)

V2.03:
– fixed AT118 crashes (due to faulty recording of texture swap changes)
(thanks to Slugger)
– added rudimentary CH in-game cheat listing

V2.01:
– added AT119, for some control over
the particle-based rain/snow feature (still very experimental)

V2.00:
– complete ATYPEX.dll source code rehaul: rearranged file/code/data distribution,
almost all global jump labels, On-ActBite MXT/ActJumpNew/Animal Projectile code,
new ActionType macros and VTables, etc.
– experimental particle-based snow/rain effect
– new C/C++/other external DLL plugin system
– added PLG cheat (sends commands/cheats/parameters to
installed plugins)
– fixed EnablePersistentParticleEffects option only working with fluid particles
(now works with solid/dust as well)
– fixed patcher EXE code not unloading ATYPEX.dll at proper time (major bug!)
– no more patching for full version! see Installation
– added automatic first-run ATXconfig.ini generation/maintenance code. File is no longer shipped
with ATX package.
– fixed AT114 broken in test versions

V1.63:
– updated some documentation (fast level restart disabling, actiontypes)
– discovered how to reference dino body parts by string (see
REFERENCING ANIMATE PHYSICS SUB-OBJECTS BY STRING
– added CPBCNT cheat (display CParticleBase count)
– moved EnablePersistentParticleEffects ATXconfig.ini option from [General] to new
[Particles] section
– added experimental OverrideMaxTotalActiveParticles option under [Particles]
(see PARTICLE OPTIONS)

V1.62:
– fixed ActionType 110 not recognizing Sample instance in some cases (either giving no effect
or causing crash)
– fixed erronous AT110 documentation – thanks to Slugger for bug report
– new ActionType – 117 – Initiate Particle Effect
– new ActionType – 118 – Swap Instance Texture
– updated installation notes and some misc. documentation
– some source cleanups
– added EnablePersistentParticleEffects option to ATXconfig.ini (under [General])

V1.61:
– reinstated KILL cheat (had accidentally been renamed to KILLDINO in 1.60)
– fixed ATX causing crash if level could not be loaded due to lack of HD space
– added SUICIDE cheat (take a wild guess)
– new ActionType – 116
– some closure for the now-officially-abandoned MaxActiveDinos hack
– tweaked ActJumpNew default settings for TendancyCheckPeriod
in *.ini files for instance-specific sections
– added 7 new ActJumpNew jump condition *.ini settings to limit/dictate jumping behaviour
(example settings) – includes a MaxDistance value which can be used
to allow spitting (and other) animals to jump and this only when within a certain
maximum distance away from their targets
– OBJ cheat (and related cheats) now displays the distance between object and player object.
– Note: The TEHG and Ollydbg plugin are included under “ATX_SOURCE\_ollydbgplugin\”

V1.60 (source re-included):
– fixed REC video recording SaveMethod 16 in software mode
(finally! – see VIDEO RECORDING)
– changed REC default SaveMethod to 16 in ATXconfig.ini
– fixed RECCOMPRESS.exe crashing at startup
– new path tracing system for 2D maps (see PATH TRACING).
– major source rewrites/cleanups (heavy use of FASM macros)
– experimental support for level-specific additive TPAs (see ALTERNATE LEVEL TPAS)
– new hotkey system for cheats (see HOTKEYS)
– new ActionType – 115
– updated documentation for Spitter code (see SPITTER/ANIMAL PROJECTILE SETUP)
– fixed slight inconsistency in Spitter code (the MinLaunchInterval would be renewed
immediately after the probability checks but before angle/misc checks, so it happened
that the interval would renew itself without an actual projectile launch if the
probability passed but the 3D checks didn’t) and relocated seed random call
– updated VTABLEID program and output files for demangled class names support via
MSVCRT.dll (see under “ATX_SOURCE\_vtableid\”)
– included experimental Ollydbg plugin for class name label registration for
Trespasser executables (see “ATX_SOURCE\_ollydbgplugin\”)

V1.59 (source code not included):
– default HUD is now included in package (courtesy of Trescom’s Slugger)
(see HUD)
– updated FASM compiler to version 1.66
– added instance options to AT103 script (see Actiontype 103)
– modified ATX_SOURCE\_vtableid extractor to provide demangled class names
(updated files will be included in later versions that will contain source)

V1.58 (unofficial):
– Updated OBJ/OBJF/OBJN cheats to display some basic mesh info (if available for instance)
– fixed some potential OBJ-based cheats crashes
– fixed AT103 holstered weapon reloading (why did nobody ever notice this?! It’s been this way for over a year!)
– basic HUD system implemented (see HUD)
– new INI entry: AlternateMenuTPA, under [TPAFiles]
(see TPA (MENU) FILE RELOCATION)
– added FLY mode in-game speed multiplier option (see FLY MODE)

V1.57 (source code not included):
– new AIM aimdot cheat and related OBJAIM cheat
(mainly for use with THIRDP – AIM can be toggled using a
character key as well -> default = n key)
– new randomized teleportation ActionType (114)
– moved some INI options into different sections, i.e., created new FogSettings
(see included ATXconfig.ini for reference)
*** These new locations will be final as of this version. These changes were
made in the spirit of readability and consistency. I apologize for any
temporary inconvenience/confusion it may cause.
– added game fog disabling tweaks in INI for FogPower and FogHalf values
(these may need to be tweaked in some cases, such as when software rendering
is used, in order to properly disable or diminish the fog effect)
– updated documentation for some features and INI entries
– tweaked some randomization code (for jumping dinos and AT114)
– documented the generally-useless-and-probably-not-fully-implemented LINST cheat
– added documentation for new HIGH-RESOLUTION PATCH entries
*** Thanks to RenderFred and -=CHE@TER=- for their help testing the
new video troubleshooting options.

V1.56 (unofficial, source code not included):
– updated FASM compiler version to 1.56.17 (for structure definition fix)
– fixed DisableGameFog default value problem
– added AimGunToggleKey INI entry for THIRDPerson cheat (default key = b)
– new FLYTELE cheat (for use with FLY mode)
– new [Troubleshooting] option in ATXconfig.ini to force resolutions
into the Video Options menu list of resolutions (can override detection problems)
– new CameraFOV INI entry under [Variables] in ATXconfig.ini (overrides
initial level-load values set by level scripts using ActionType 06)

V1.55 (source code not included):
– updated ATX_PATCHER.exe description and various bad references/issues
(thanks to -=CHE@TER=- for the heads up)
– added tweak for max resolution for high-resolution TSOrd hack in ATXconfig.ini
– tweaked Night Mode and object teleportation INI files
* Note: The assembly source was omitted from this release due to heavy development
and package size. It will be re-included in later releases (a.s.a.p.).

V1.54 (test):
– removed obsolete camera movement rate INI options for FOLLOWDINO and THIRDP
– added DisableGameFog ATXconfig.ini option (see FOG SETTINGS)
– added FogPower and FogHalf ATXconfig.ini tweaks for Night Mode
– rewrote menu options loading code; additions are now stored in supplemental
“MAPS\” folder DDF files (see NEW MENU OPTIONS)
– added object teleportation INI files for Night Mode (“MAPS\NMD\” folder)

V1.53 (test):
– New ActJumpNew jumping dinos jump probability option (TendancyCheckPeriod – see JUMPING DINOS (ON ACTBITE COMMAND))
(included in slightly modified default settings)
– fixed THIRDP and FOLLOWDINO cheats camera movement being updated one frame late
(camera is now updated on every CAnimations CMessageStep-response handler method, before
every render)
– spit system update

V1.52 (test):
– rewrote exe addresses code using FASM macros (_much_ cleaner)
– fixed potential FOLLOWDINO function crash
– quick-save can now be disabled if F9 key causes conflicts with other
programs
– new ActionTypes (110-113)
– spit system

V1.51:
– fixed major CAnimal issue, mainly in savegames with dinos active at level start (hangs, crashes)
– fixed “no bitmap” message for MAP cheat
– included new Quick Save key (F9) (see QUICK SAVE)

V1.50:
– new DisableFastRestart ini/menu option (see FAST LEVEL RESTART DISABLING)
– “ATX_DOCS\” documentation folder removed! All docs can now be found in ATX_README.htm
– dino randomizer is now object/instance randomizer! Will work with most instance types (see OBJECT RANDOMIZER)
– fixed randomizer limiting instance names to 49 bytes in length (now allows up to 199 bytes, though game limit unknown)
– fixed BUFSIZE cheat problem (stack memory overflow)
– added Jumping Dinos option under [ActJumpNew] in ATXconfig.ini to prevent any quadrupeds from jumping
– new optional 3DNow! optimizations (see ATXconfig.ini File Details)
– new FOLLOWDINO, OBJ, OBJN, OBJF, CDINO, and GSPD diagnostic cheats (see CONSOLE COMMANDS/CHEATS)
– new THIRDP[erson] cheat
– ALL functions that depend on time settings (Matrix Effect, TIME cheat, Jumping Dino intervals, etc.) should
now take into account time spent by user in in-game menu (as well as F1 hints, F12 key assignments)
HOWEVER, there is still no compensation done for time elapsed if the game is temporarily
exited via ALT+TAB or similar accelerator commands
– added Game Speed transition settings for Matrix Effect and ActionType 100,
rewrote much of their code, and modified some default settings and ActionType specs
– BIONICWOMAN cheat no longer interferes with Matrix Effect and ActionType 100,
but rather disables their effect while the cheat is enabled. BIONICWOMAN can
no longer be toggled while Matrix Effect or ActionType 100 are in effect
(whichever feature is enabled first has priority).
– new (trigger-dependent) ActionType : 109 (set default particle type colors)
– new Night Mode (toggle in ATXconfig.ini, under [NightMode] section – play with lights off)
– FLY cheat code rewrite
– fixed null-terminators being written to log file (thanks Metapad!)
– added option for REC cheat, removed some remnants of old recording system
– 2D map load code for savegames now saves entire BMP name buffer (80 bytes)
– ActionTypes 101 (change game speed) and 106 (set new hint) now save data
to SAVEDMAP.xxx (should now work with savegames)
Note: Game speed loading from ATX savegames can still be disable via ATXconfig.ini,
under the [Variables] section, if needed.
– ActionType 103 now properly checks to make sure objects held by player (to reload)
are in fact of type CGun
– F1 Hint fix: ATX now sets the “Where Am I?” hint (ID = 100) as the default
hint in case no hint is loaded or hint loading failed in user-made levels
(Trespasser did not set a default hint)
– TO LEVEL DESIGNERS: New ActionType Reference updated with important info;
some new ActionTypes’ behaviours refined
– Some FANSFAQ questions added, CAnimal class data updated (see Archive)
– ‘discovery’ of “System Memory” Trepasser registry/ini entry (documented in VIDEO RECORDING)
– included Chronzerg’s be.ini randomization file (simply use the batch files in
the “MAPS\” folder to copy randomization files as needed from now on)
– some major source code rewrites and cleanups (CAnimal names buffer replaced, eliminated
most large local variable buffers which lead to stack memory issues, etc.)
– Important note:
It has come to my attention that the “facing angles” used
throughout the source code and referred to in many files in this
package are actually (and obviously!!!) VECTOR components
and NOT angles. THUS, ALL MENTIONS OF “FACING ANGLE” VALUES SHOULD
BE INTERPRETED AS “FACING VECTOR” VALUES. I consider this the most
foolish mistake I have committed so far (DWI would have laughed at me).
Fortunately, only the FLY cheat was affected (fixed).

V1.40:
– fixed potential FLY cheat issue
– misc. code cleanups
– slight RECCOMPRESS.exe update
– new “LOAD” (level) cheat
– all documentation previously scattered throughout “MAPS\”
folder has been moved to “ATX_DOCS\” (all documentation updates
will thus be in the “ATX_DOCS\” folder if you are extracting
the package over a previous version)
– new level load background extension (see LEVEL-LOAD BACKGROUND EXTENSIONS)
– MaxActiveDinos highly experimental hack (see MAX ACTIVE DINOS)

V1.36:
– updated source of ATYPEX.DLL, ATX_PATCHER.EXE and RECCOMPRESS.EXE
for FASM version 1.64
– REC cheat updates (see VIDEO RECORDING)
– “SHOWDD” cheat added (could already be done; simply a convenience)
– some optimizations (FLY cheat, experimental EXE code modifications)
– experimental Dinosaur vocal T-Script value additions (see DINOSAUR VOCAL T-SCRIPT ADDITIONS)
– fixed cheat table lengths (did not cause problems for previous
versions due to lower amounts of cheats)
– fixed “DMAP.scx” file being created (did not cause problems; would
only replace “temp.scx”)
– fixed instance position modification code for dino randomizer
(would sometimes crash in demo, though usually run fine in full version)
-> code now uses standard teleportation method for instances
– fixed some stack overflows (dino randomizer, 2d map loading)
– new menu items updated (can be toggled via INI, now uses hotspots
for checkboxes, checkboxes should now always toggle properly)
– fixed some potential level restart issues
– temporary mainscreen.ddf and render.ddf files are now stored
in the “MAPS\” folder
– some misc. source cleanups

V1.35:
– experimental “REC” video(-only) capture cheat (see documentation)
– some simple new cheats: “PLAYERHEALTH” (re-implemented),
“SUPERHP”, “NORMALHP”, “FPS”

V1.34:
– new menu items (game difficulty, draw distance, etc.)
– minor patcher fix (v2.1)
– 2D map bugs fixed
– MapIndex.ini format slighty modified
– fixed some level restart problems
– dino rand. list files added for levels
as.scn
as2.scn
sum.scn
(all full-version levels now supported)

V1.33:
– ActJumpNew info in CANIMAL cheat
– some jump-related fixups
– included high resolution patch (enabled by default)
-> This patch differs slightly from the original in that it only
writes the 4 different bytes rather than the 10 bytes, 6 of which
remain the same. Also, for the record, the two instructions that
the original patch modifies are 6 bytes long each and would theoretically
require 12 bytes to change entirely, though the two extra bytes would remain
the same.

V1.32 (test, unreleased):
– fixed bad location values for default demo level 2D map
– experimental jumping dinos! see JUMPING DINOS (ON ACTBITE COMMAND)
and ATXconfig.ini

V1.31:
– new patcher (v2.0)
Note: Executables created with the previous command-line patcher
will still work with this version, the only difference in result
being the name of the copied/patched file.
– greatly regulated FLY cheat movement speed (especially for
slower computers)
– MatrixTres on ActBite is now only active when a dino is
at a certain (customizable) distance/radius from player
– Default MXT and BIONICWOMAN speed changed from 0.300000 to 0.400000
– ATXconfig.ini file rewritten (previous files are now incompatible with v1.31)
– new INI entries
– added dino randomization for the following default levels:
be.scn (for 1/4 of the 4 dinos, that is)
jr.scn
ij.scn
lab.scn
– added the following entries for dino rand. list files:
ForceWakeUp
ForceSleep
DisableActGetOut
– “ATX_DLLSOURCE” folder renamed to “ATX_SOURCE”, and “ATX_PATCHERSOURCE”
folder renamed and moved to “ATX_SOURCE\” (mentioned here as to not stem
confusion with previous versions)

– major source code cleanups and general fixes

V1.30:
– new cheats: “HEALDINO” (along the lines of “KILL”)
“CLOAK” (makes player invisible to dinos)
“FLY” (experimental fly mode)
-> see “New Cheats” for details
– fixed “KILL” cheat crashing game in empty levels
– 1 new ActionType (106) – Load New (F1) Hint (see New ActionType Reference)
– several cheats/functions can now be toggled using user-defined alphanumeric
keys (a-z, 1-9, all lowercase) via ATXconfig.ini
– draw distance can be set in real-time via specifiable keys in ATXconfig.ini
– added entries to the “CAnimal” cheat (“Fatigue”, “Anger”, “Pain”, etc.)
– sparse info about the general CAnimal and Player classes described
in the file CANIMAL CLASS INTERNAL STRUCTURES
– fixed potential in-game video memory leak (though hardly noticeable)

NOTES:
– The player’s AIType value can no longer be set via T-Scripts (always 5).
It can only be toggled via specific cheats (CLOAK, FLY).

– I am aware that default game videos, when played in-game, will only
play in a resolution of 640*480 even in higher resolutions (thus windowed).
This is normal and can currently not be fixed (due to the amount of problems
that changing resolutions while in play introduces).

V1.25:
– removed partial IT town map from download; a much better
version can be found in Rebel’s 2D map pack (see main
ATXTres web site)
– new dino function/browsing cheats (see “New cheats”):
“CANIMAL”, “B”, “N”, “KILL”, “MDINO”, “MSEL”
– new experimental list-based random dino locator (see OBJECT RANDOMIZER)
(note: this package only includes an example list for the town level)
– fixed problem (in most cases) where loading an empty level
(w/o dinos) after loading a populated level would crash the game

V1.24:
– added a few experimental INI entries (i.e.,”DSWP” to
disable swap/.swp file deletion; some AI control entries)
– general fixes (some memory leaks; better memory management)
– updated “Known Bugs” list (odd crashes)
– included general variable information in package
(“ATX_DOCS\ATX_OTHERINFO\” folder) and FAQ
– fixed ActionType count values (i.e., LoopCount, Frame)
not being reset upon level restart (in most cases)
* thanks to Rebel and Remdul for the initial info about
the AI-related strings (cheap hacks, but they work!)

V1.23:
(scrapped)

V1.22:
– LOC, MAP, and TIME cheats can now be used simultaneously
(LOC and TIME supersede MAP in display)
– fixed some ATXconfig.ini file issues

V1.21:
– added ATYPEX.DLL error logging via “ATX_LOGFILE.txt”
– removed two consecutive error messages
– more protection fixes (this version was successfully
_loaded_ on a copy of Windows XP Home Edition)

V1.2:
– fixed empty export table
– fixed some compatibility issues (for picky WinXP protection)
– DEMO_LEVEL_MAP.bmp’s resolution has been reduced

V1.1:
– added new ActionType: SMK video playback
-> IMPORTANT: READ NEW ACTIONTYPE REFERENCE FOR DETAILS
– added new cheat: counter (“TIME”,”RESET”)

*** Note: “test” versions refer to unreleased versions.

INSTALLATION

Requirements

- A legal, valid, full-version copy (CD) of Trespasser by Dreamworks Interactive

- Windows 98SE/ME/2000 SP4/XP SP1-SP3 or a compatible version of Linux (Windows Vista is NOT officially supported)

DirectX 6.1 or higher (preferably higher, i.e., 8.0+)
A Pentium or AMD K6 processor or higher (highly recommended: Pentium III, AMD Athlon, or higher)
A few hundred megabytes of free hard drive space at all times (highly recommended: a few gigabytes) and adequate virtual memory settings

Notes relating to prior versions

If you are upgrading from a version of ATX prior to 2.00, you MUST delete your old ATX-patched executable
and replace it with one of the pre-patched ATX 2.00+ executables.

Beginning with ATX 2.00, you no longer need to patch your full-version Trespasser installation
to run ATX. The small patch (1.1, or 1.0.117.0) is already applied to the distributed
ATX executable. The ATX_PATCHER is usually no longer necessary, unless you want to apply ATX to executables
already containing manual hacks, such as the original Trescom TC-Isle release. See the included README file
in the executables package for more details.

In ATX 2.09, the executables package has been updated to provide a demo executable and generic patcher without
forced CD verification. The full-version executables remain unchanged.

Quick-Install Procedure

1. Install Trespasser full-version (hard disk installation preferred)

1. Download the trespassATX2.zip package and (only) the latest atx2xx.zip package from the ATX website

1. Extract both packages into your Trespasser folder. By default, this is “C:\Program Files\DreamWorks Interactive\Trespasser\”

1. Go to that folder and run trespassATX2.exe

1. At the next ATX version update, download the latest atx2xx.zip package only and extract it to your Trespasser folder, overwriting everything.

Detailed Installation Procedure

If you are upgrading from an ATX version prior to 2.00, you do not need to make any
significant changes to your installation, though it is highly recommended that you delete
any old ATX Trespasser executables (such as “trespass_ATX.exe”, by default),
as these are incompatible with ATX 2.00 and higher.

If you are upgrading from an ATX version prior to 2.00 or installing a fresh copy
of ATX 2.00 or higher, you need to acquire the pre-patched ATX executable for
ATX 2.00+, available at the same location as the ATX package. This file is named
“trespassATX2.exe” and distributed as “trespassATX2.zip”. Simply extract the executable file in this archive
into your main full-version Trespasser directory (often “C:\Program Files\Dreamworks Interactive\Trespasser\”).
You do not need to extract anything else from the package unless you want to use a processor-optimized
version ** or need a demo version for standalone level design (ATX2DEMOPATCHER).

This file (trespassATX2.exe and variants) should be the same for all versions of ATX starting with 2.00; you do not
need to update it at every ATX 2.00+ release, unless explicitly stated otherwise.
Note: The new executables are incompatible with ATX versions prior to 2.00.

** The trespassATX2.zip package also contains sub-folders with different optimizations
of the Trespasser executable (trespassATX2K611.exe for AMD K6/K6-2/K6-3(+), trespassATX2P611.exe for
Pentium Pro/Pentium II and higher). You can use these instead of trespassATX2.exe by copying them into
your Trespasser folder and running them. It is highly recommended for Pentium Pro/Pentium II/AMD K6
processors to choose an appropriate optimized executable, even if the default one (trespassATX2.exe) will work with all processors.
As for newer processors, the AMD Athlon will function with any (use the P6 or K6, preferably the latter) and the Intel Pentium II/III and higher
will work best with the P6 version. There is no major functional difference between the three available EXEs from the ATX standpoint.

Extract all contents of the ATX package (atx###.zip) from its root
folder into your main full-version Trespasser directory. Make sure to preserve pathnames
while extracting and replace all existing files.

Read the Important Notes before you run ATX-modified Trespasser.

Go to your main Trespasser directory and run the file named “trespassATX2.exe” which you
extracted earlier *. This will be the file you will use to run the ATX-modified version of Trespasser
from now on. The first time you run ATX 2.00+, a file named ATXconfig.ini will be generated in your
Trespasser folder (it is no longer shipped with the package); you will use this file to tweak most
ATX settings, once you exit the game again. If you are upgrading from a previous version of ATX,
ATX will preserve your settings for all still-supported values, and add all new entries to it
(you no longer need to re-tweak the file at every release). In general, make sure to inspect
ATXconfig.ini after every first run of a new ATX version. ATX will delete all obsolete entries
and detected incoherent values, while saving your settings wherever possible.

For information on installing ATX plugins, please read Plugin System and Plugin Installation.

Errors and Other Info

If you run into trouble, ATX or the game may give you an error message. In the worst case,
the game will crash without proper error handling, resulting in those “memory could not be read/written”
messages. ATX issues are generally recorded in “ATX_LOGFILE.txt”, while Trespasser errors (and ATX
programming errors) often show up in “error.log” (either in your base Trespasser folder
or in your “tres cd” hard-drive installation folder).

All ATX documentation can now be found in this file (ATX_README.htm), with the exception
of the plugin system and source documents, which exist in the separate source package
(atx###source.zip). Simply follow the appropriate links to discover the new features,
FAQs, etc. You can also now download supplemental 2D maps (such as Rebel’s)
from the main ATX website.

Special note for Vista users:

At the current time, ATX has NOT been tested under Windows Vista by the author and is therefore
unsupported under this operating system. If you do run into problems attempting to run it
under Vista, please post publicly at the Trescom message board for help.
Successful execution under this OS has been reported by some users, failure by others. Should you be unable
to circumvent the issue, it is recommended that you continue to use Windows XP or earlier supported Windows version
to run Trespasser. Apologies for the inconvenience, but the author currently lacks a Vista installation
and has no plans to acquire one in the near future.

Plugin System and Plugin Installation

ATX 2.00 introduces a limited but functional plugin system that allows programmmers to create
standalone C/C++ dynamic link libraries (DLL) which can interact with ATYPEX.dll to extend ATX’s
functionality.

To install a third-party plugin, in general, you will simply need to place
the plugin’s main DLL file in your root Trespasser folder (where ATYPEX.dll is) and will also need
to create a new sub-folder under “MAPS\PLG\” with the same name as the DLL file, excluding extension (even if
the new folder is empty – ATX detects plugins using these folders). If the plugin already has an installer
or includes a “MAPS\PLG\” subfolder in its archive to be extracted, this may be done automatically. Further requirements
will depend on the plugins; please refer to their respective documentations.

For more information and programming documents, see the ATXPLUGIN_README.htm document
included in the ATX 2.00+ source package (atx###source.zip), under the folder “ATX_PLUGIN”.

Note: The PLG cheat can be used to send commands (cheats) to plugins which support it.

Packages, Files, and Locations

ATX Packages and Contents

The ATX 2.00+ distributions are divided into 3 packages. They are listed here below, along with their most important files and folders as they appear as of ATX 2.09. Please follow the provided links for more details about their contents and usage.

ATX main package (atx2XX.zip)
- - ATX_README.htm: This document
- - ATYPEX.dll ***: Main binary file for ATX, contains all of ATX’s code and functions.
- - MAPS ***: Folder containing almost all external files read by ATX and level makers, such as extra level-specific data, custom menu DDF files, and randomization files. Files are organized by feature into mandatory sub-folders. Any level customizations using ATX-specific features should be placed somewhere within this folder or within its sub-folders. The name is a bit misleading, as it contains much more than just “maps”.
- - RECCOMPRESS.exe: Standalone utility that can be used to compress video dumps created by the REC cheat.

ATX executables package (trespassATX2.zip)
- - trespassATX2.exe ***: This is the standard, unoptimized, pre-patched ATX 2 executable for the full version of Trespasser. Typically, this is the only file you need from this package, and you never need to update it.
- ATX_EXEUTILS: This folder contains alternate pre-patched ATX Executables with different optimizations, patching utilities, and other executable-related utilities, all found in the separate sub-folders listed below.
  - - ATX EXE – Demo: Contains a pre-patched ATX 2 executable for the demo version of Trespasser.
  - - ATX EXE – AMD K6: Contains a pre-patched ATX 2 executable for the AMD K6 (3DNow!)-optimized full version of Trespasser (use this for AMD K6-2 or K6-3 systems).
  - - ATX EXE – Pentium Pro P6: Contains a pre-patched ATX 2 executable for the Pentium Pro-optimized full version of Trespasser (use this for hacking the game using utilities from the ATX source package).
  - - ATX EXE Patcher: Contains the ATX patcher utility used to create the ATX 2 pre-patched executables. It is generally only necessary if patching manually-hacked executables for use with ATX. See contained README.txt.

ATX source package (atx2XXsource.zip)
- - ATX_SOURCE: This folder contains full FASM assembly source used to produce the main ATX binary, ATYPEX.dll, as well as the various utilities found throughout the ATX packages.
- - ATX_PLUGIN: This folder contains the C language header and accessory files needed to create DLL plugins for ATX’s custom plugin system.
- - ATX_TEHG: This folder contains the Trespasser Executable Hacking Guide documentation, related debugging utilities (Ollydbg plugin(s)), and a database of labeled Trespasser executable code and data addresses.

Above, the minimum required files and folders to get ATX to run on a full version copy of Trespasser are marked with *** (folders marked should include all sub-folders and folder structure as they exist in the package). These files must be present in (extracted to) your root Trespasser folder. Files not marked are optional and may be removed.

ATX-Generated Files

ATX also generates some extra files in Trespasser’s root folder after the first or subsequent executions. They are listed below.

- ATXconfig.ini: This is the main configuration file for all ATX releases. ATX uses it to store menu settings and other data, and users can edit it manually while the game is not running. It should only be opened while the game is not running.

- ATX_LOGFILE.txt: This is the main log file used by ATX. ATX uses it to output initialization information, errors, plugin info, and level data that can be useful to level builders. It should only be opened while the game is not running.

- SAVEDMAP.XXX: These files are created by ATX whenever Trespasser’s savegame feature is used to save the current game. The file’s extension (XXX) is numbered to correspond to the Trespaser SAVEGAME.XXX file it was saved along with. If you are moving or distributing savegames, you should always include both the Trespasser SAVEGAME.XXX file and the accompanying ATX SAVEDMAP.XXX file, unless you are certain that no ATX features were used for/by/during the level.

Commonly Used Files

Typically, after extracting the main and executable ATX packages as described in the installation instructions and then executing ATX at least once, your root Trespasser should contain the files and folders below (unnecessary files and folders removed for clarity).

- MAPS (and all required sub-folders; required)

- ATYPEX.dll (required)

- trespassATX2.exe (or variant; may be renamed; required)

- ATXconfig.ini (optional, but necessary to customize ATX)

- ATX_LOGFILE.txt (optional, but gets recreated all the time)

“MAPS\” and sub-folders

The “MAPS\” folder is a folder used for all ATX-based features that require initialization
files, bitmaps, and anything else that would otherwise clog up your Trespasser folder (which
does not include ATXconfig.ini, savegame additions, or REC cheat video dumps). Its name is slightly
misleading; it does not necessarily have anything to do with maps in general. It may
contain any and all externally-implemented ATX files and data of any type. The name is a remnant
of the first versions of ATX, which originally used this folder for the 2D map cheat.
The dependancy on this folder has become regular enough that I not could justify renaming it at this stage.

In order to run the ATX version of Trespasser properly, it is essential that the “MAPS\” folder,
as well as each of its following sub-folders, be present in the root directory of your Trepasser installation,
be it full-version or demo-based:

- “MAPS\HUD\” (used to store images and location settings for HUD display)

- “MAPS\JMP\” (used by the Jumping Dinos routines for level-specific *.ini files)

- “MAPS\LBG\” (used to store new level-load background images (*.tga))

- “MAPS\LVL\” (used for misc. level-specific data, including alternate TPAs)

- “MAPS\NMD\” (used for alternate locations for objects in levels when in Night Mode)

- “MAPS\PLG\” (used by plugin system to keep track of installed plugins and for plugins to store data)

- “MAPS\RAN\” (used by the Object/Instance Randomizer for level-specific *.ini files)

- “MAPS\RNE\” (used by experimental rain effect for miscellaneous purposes)

- “MAPS\SPT\” (used to store level-specific animal projectile/spitter INI data)

These should not be deleted under any circumstances (i.e., not even if the folders are empty).
The following files, with paths respective to the “MAPS\” folder, are also essential to
ATX and should not be deleted under any circumstances:

(currently none; here for future reference)

Any other sub-folders or files not named in either of
the lists above and found in the “MAPS\” folder may be deleted
without causing any harm towards the execution of ATX. A more detailed
approach to each of their functions can generally be found in
the documentations of their parent features. This note
is mainly directed towards those organizing any form of custom
redistribution of the ATX package.

ATX SOURCE CODE (“ATX_SOURCE\” folder)

The ATYPEX.dll file used by ATX Trespasser and most ATX-related
utilities are written in assembly and assembled using the FASM compiler
(Windows version). The last used FASM version is noted in the
“ATX_SOURCE\SOURCE_README.txt” file, in the atx###source.zip package.
In some cases, mainly due to syntax
changes, previous or newer versions of FASM may not be able to compile
the ATX source.

The source code for ATX is hereby released into the public domain. Anybody
is free to change, recompile the source at will, and redistribute it as long
as the changes and authors are clearly noted. However, I reserve the right
to modify existing code at any time without explicit notification to other
developers.

The “ATX_SOURCE\” folder itself can be deleted from your Trespasser
directory at any time; ATX does not make use of this folder at all once
it has been compiled.

ATXCONFIG.INI ATX CONFIGURATION FILE INFO

ATXconfig.ini is the file used to enable/disable features
and change ATYPEX.DLL’s default values. Generally, for
enabling/disabling functions, 0 = false and 1 = true.
YOU SHOULD NEVER ATTEMPT TO MODIFY THIS FILE WHILE THE GAME IS OPEN.

Unlike previous ATX versions, unless otherwise specified,
leaving values to 0 will NOT load specified default values
(default values are loaded if no valid entry is found or if file
is absent). All values which include decimals are necessarily
floating-point values (the opposite is not true).

In the example INI below, some values have been omitted. For
a list of default values, simply backup your current ATXconfig.ini
file, deleted the copy in your root Trespasser folder, run ATX once,
exit the game, and open the re-created ATXconfig.ini in the root folder.
It will contain all default ATX values for the version you are using. This
assumes you are using ATX 2.00+.

Any values that begin with “0x” are hexadecimal values and
should only contain 8 characters (excluding “x”) ranging between
“0” to “9” and “A” to “F”. i.e., 0x1209ABDF.

The high resolutions hack is the “property” of Mark Grant, a.k.a.
MrLaggy, and the sadly deceased TSOrd. I do not take any credit
for their work; it is only provided here for convenience and as
a tribute to those members. If this does not conform with the
authors’ wishes for any reason, it will be removed A.S.A.P.

Note: For all floating-point values, the value 0.000000, with
any number of zero decimals, is equivalent to the value 0, both
in magnitude and in general use (i.e., when 0 can be used to
disable a feature or use a default in a floating-point value, you
could also use 0.000000 instead).

[General]
EnableTimedTresStrDbg=			; See TRESSTRDBG. Also display interval in milliseconds (non-zero to enable).
EnableWindowedMode=			; See WINDOWED MODE (SEMI-). SOFTWARE MODE ONLY. Will crash with Direct3D enabled.
DisableDemoExitScreen=			; See DEMO VERSION EXIT SCREEN REMOVAL
EnableInstanceRandomizer=		; See OBJECT RANDOMIZER. ONLY for levels with existing list files
EnableHighResolutions=			; See HIGH-RESOLUTION PATCH
GameDifficulty= 			; See DIFFICULTY SETTINGS
EnableNewMenuItems=			; see NEW MENU OPTIONS
NewDinoSoundTypesCount= 		; See DINOSAUR VOCAL T-SCRIPT ADDITIONS
MaxActiveDinos= 			; See MAX ACTIVE DINOS
EnableNewLevelLoadBGs=			; See LEVEL-LOAD BACKGROUND EXTENSIONS
DisableFastRestart=			; See FAST LEVEL RESTART DISABLING
EnableATX3DNowOptimizations=		; See 3DNOW! OPTIMIZATIONS. ONLY for AMD processors
UseOldVirtualProtect=			; For testing purposes. Uses VirtualProtect instead of VirtualProtectEx.
UseHUD= 				; See HUD
EnableATXScreenTextDumper=		; See DUMP console command.

[Variables] ; For this section, 0 = use value from exe. See
ObjectClarityDrawDistance= ; EXE default = 15.000000. See DRAW DISTANCE AND GAME SPEED VARIABLES
Gravity= ; EXE default = 10.000000
NormalGameSpeed= ; EXE default = 1.000000
OverrideSaveGameSpeed= ; As of ATX 1.50 and later, game speed is saved for specific levels; thus, changing
; NormalGameSpeed will have no effect on savegames. In order to bypass this behavior,
; set OverrideSaveGameSpeed=1 and the value for NormalGameSpeed will be used for savegames.
; To be precise, game speed values will still be saved to ATX-based savegames (to prevent
; compatiblity problems), but they will not be loaded from these savegames.
MatchAspectWithResolution= ; See FIELD OF VIEW SETTINGS.
AspectRatio=0:0 ; See above.
SyncFOVWithAspectRatio= ; See above.
CameraFOVDegrees= ; See above.

[FlyCheat] ; See FLY
InputAutoRepeatDelay= ; Minimum delay for keyboard autorepeat, in milliseconds.
PlayerMovementSpeed= ; Every keystroke will move player by this distance.

[MatrixTres] ; See MATRIX EFFECT
EnableMXTOnActBite= ; Matrix effect for dino attacks (based on biting behavior).
MinMXTSlowdownDuration= ; Minimum duration of Matrix effect, in milliseconds – INTEGER
BIONICWOMANMXTSlowdownSpeed= ; Game speed used for Matrix effect and BIONICWOMAN cheat.
ActBitePlayerDinoRadius= ; Maximum player-dino radius in which can be launched the Matrix effect.
MXTEnterTransitionInterval= ; (Integer) Duration of linear game speed transition at start of effect
MXTExitTransitionInterval= ; (Integer) Duration of linear game speed transition at end of effect

[HotKeys] ; See HOTKEYS
ToggleNewKeys= ; Note: This key will be intrusive.
DecreaseDrawDistance= ; Message showing new value will be shown upon keypress.
IncreaseDrawDistance=
ExitATXDRVMode= ; ignore.
LINSTCycleLeft= ; ignore.
LINSTCycleRight= ; ignore.
LINSTCyclePrevious= ; ignore.

[AISettings] ; See AI HACKS
AllowDinosInBuildings=
ForceNoStayNearTarget=
ForceNoStayAwayTarget=
AddHitPointsToAllDinos=
AddFreezeDistanceToAllDinos=

[Troubleshooting]
DisableA3DdllDetection= ; See SOUND PROBLEM FIX (A3D.DLL).
; Enable this to fix some audio problems and general errors
OutputDirectDrawVidModeEnum= ; See HIGH-RESOLUTION PATCH
ForcedVideoModesList= ; See HIGH-RESOLUTION PATCH
OverrideMaxResolutionX= ; See HIGH-RESOLUTION PATCH
UseClassOutputter= ; DO NOT USE.
DisableSwapFileDeletion= ; Removes limit on amount of *.SWP files that can be created (for faster loading). Ensure
; sufficient hard drive space before enabling.
UseMenuKeysFix= ; See MENU KEYS FIX.
DisableATXSMKEffects= ; See SMK VIDEO PLAYBACK RESIZING.

[ActJumpNewSettings] ; See JUMPING DINOS
DisableActJumpNew=
DisableJumpingQuadrupeds= ; This will cause all Trikes, Stegs, Brachis and other possible
; quadrupeds NOT to jump, while leaving all other dino physics types jumping.
DefaultPush= ; Float value (force)
DefaultJumpAngle= ; Float value (Euler angle, 0 – 90). Higher value will give more “vertical” jumping”
DefaultJumpTendancy= ; Integer value (0 – 100).
DefaultRepeatPeriod= ; Integer value (milliseconds). Minimum elapsed time between a single dino’s jumps.
DefaultTendancyCheckPeriod= ; Integer value (milliseconds). Interval used for jump probability. Should be equal to or below DefaultRepeatPeriod.
DefaultMaxBodyTargetDirAngle= ; These are the defaults for the similarly-named (only omitting the “Default” prefix) values described under JUMPING DINOS.
DefaultMaxHeadTargetDirAngle=
DefaultMinTotalVelocity=
DefaultMinDirectionalVelocity=
DefaultMaxDirVelocityAngle=
DefaultMinTargetDistance=
DefaultMaxTargetDistance=

[VideoRecording] ; see VIDEO RECORDING for entries and descriptions for this section.
…

[FollowDinoCheat] ; See FOLLOWDINO
MouseSensitivity= ; Higher will give faster camera movement
MaxKeyInputRate= ; Affects only input “framerate” for distance change between camera and dino – FLOAT *****
DefaultDistanceFromDino= ; …
DistanceChangeSpeed= ; Speed at which movement the above distance will change (mostly independent of framerate)
VerticalMouseMvtMultiplier= ; set to -1.000000 to invert mouse for vertical movement
; (to invert horizontal movement, use negative values for MouseSensitivity)

[ThirdPersonCheat] ; See THIRDP
MaxKeyInputRate= ; (same as FollowDinoCheat) *****
ZoomInKey= ; Character key (i.e, ZoomInKey=m for “m” key), ‘a’ to ‘z’ only
ZoomOutKey=
ZoomResetKey=
CameraUpKey=
CameraDownKey=
AimGunKey=
AimGunToggleKey=
AIMdotToggleKey=
DefaultZoomDistance=
ZoomChangeSpeed= ; (floats/millisecond)
CameraRotateSpeed= ; (Euler angles per millisecond)
CameraHeightDisplacement=
CameraAngleDefault= ; (Euler angles, -85.000000 to 85.000000)

[GameSaving]
EnableATXQuickSave=
QuickSaveCurrentFileName= ; Filename for “ATX Quick Save” (you should generally let ATX manage this, unless you move your savegames)

;***** Setting these values to lower settings (minimum 5.000000, practical minimum 20.000000)
; may help framerate on slower systems

[NightMode] ; See NIGHT MODE
EnableNightMode=
FogNearValue= ; Overrides all level-specific values set by ActionType 13. Used mainly to hide sky in software mode.
FogFarValue= ; Overrides all level-specific values set by ActionType 13. Used mainly to hide sky in software mode.
FogColor= ; Fog color. format: 0x00RRGGBB
; Note: There is a bug in Trespasser that causes fog color to be updated one level load late when
; modified via ActionType 05 in hardware mode (on my video card). I do not know if it is driver/video device dependent,
; but it does imply that Night Mode can certainly not be toggled by a menu option.
CParticlesColorMax= ; Defines the maximum color value for the default particle types, that is, only the currently-supported default
; particle types. All default particle type colors will be resized proportionally to this value. format: 0x00RRGGBB
CParticlesTypes=31 ; Specifies which of the 6 default particle types to substract color from.
; See “ATX_SOURCE\Data\constants.inc” for definitions; simply add the constants
; for the respective types that need to be affected and store the result here.
DefaultGlobalClutStart= ; Overrides all level-specific default global clut values.
DefaultGlobalClutStop=
FixedAmbientLight= ; Overrides all level-specific AmbientLight values set by ActionType 06.
; Use -1.0 to not use this value (note: any other negative values will crash the game).
SkyHeight= ; Set sky height. A very high value is used to hide the sky in hardware mode (may or may not be driver-dependent).
; Some credit for the night feature goes to Rebel for the ‘dark demo’ level, as well
; as whoever else might have contributed to its creation, and also Andres, of course,
; for the T-Script reference.
FogPower= ; Fog setting. Set to -1.000000 to use levels’ values.
FogHalf= ; Fog setting. Set to -1.000000 to use levels’ values.

[FogSettings] ; See FOG SETTINGS
DefaultGameFogColor=
OverrideGameFogValues= ; This entry was previously named “DisableGameFog”.
FogPowerForcedValue=
FogHalfForcedValue=

[TPAFiles] ; See TPA (MENU) FILE RELOCATION
AlternateMenuTPA= ; * should not contain “” characters. To not use this entry, simply set to 0.
DisableAlternateLevelTPAs= ; Set this to 1 to disable use of level-specific in-game alternate TPA sound files (“pack” files).
; Can be used for troubleshooting.

[PathTracing]
EnablePathTracing= ; Set to 1 to enable feature globally, 0 to disable.
UpdateInterval= ; In milliseconds (Integer value only). Minimum time between two recorded positions/cursors.
MaxPositions= ; Maximum number of cursors/recorded positions (Integer value only).
DisplayTimePerPosition= ; In milliseconds (Integer value only). Total display time for a single recorded position/cursor.
FadeDelay= ; In milliseconds (Integer value only). Time before a cursor starts to fade out, from the time it first appeared.
MinPositionRadius= ; In-game distance value (Float value). Minimum distance between two cursors for the newest one to be recorded and displayed.
CursorColor= ; 24-bit RGB value (Hexadecimal value). Color of cursor, blended with the map’s colors (using OR logic). format: 0x00BBGGRR

[Particles] ; See PARTICLE OPTIONS.
EnablePersistentParticleEffects= ; Set this to 1 to let the particle renderer display effects that have started or fallen out of camera field-of-view.
OverrideMaxTotalActiveParticles= ; Set this to a number (integer) above 0 to limit the maximum number of active particles (fixed game default = 300)

[RainEffect] ; See PARTICLE-BASED RAIN/SNOW EFFECT (EXPERIMENTAL).
…

[CAnimalDisplay] ; See CANIMAL.
…

IMPORTANT NOTES BEFORE USING AND THINGS TO AVOID

Please be aware of the following potentially serious concerns before running ATX:

- Ensure sufficient free hard drive space before running. ATX (and sometimes Trespasser) does NOT check for free space limitations.

- DO NOT ALT-TAB out of the game during an important game. It sometimes causes trouble for ATX (and even Trespasser).

- DO NOT change video driver, resolution, or video quality while in-game (draw distance excepted). This event is currently UNSUPPORTED by ATX and may cause synchronization issues or memory leaks. Please only alter such video settings from the main menu and then restart the level or game. If you must change these settings in-game, don’t do it during an important game and restart Trespasser as soon as possible afterwards.

- DO NOT delete the “MAPS” folder or any of its original sub-folders from your Trespasser folder.

Disable anti-virus and third-party memory-management software. ATX uses uncommon programming techniques often associated with malware and may be mistaken as such.
DO NOT mix EXE and DLL files from ATX 2.00+ with those from older series of ATX versions (1.62-).
For hackers: DO NOT try to manually change the file size of the ATX or Trespasser executables. ATX can co-exist with manual hex-edits of the Trespasser EXE, but its size must always remain the same for ATX to recognize it properly.
Remember: To run ATX-enabled Trespasser, launch the ATX executable, and NOT the usual Trespasser start menu items.

COMMON ISSUES

Here are some of the most common Trespasser/ATX issues with easy fixes:

Game setup or Trespasser/ATX executable crashing on startup

-> In Windows XP, right-click the executable (either setup95.exe on the Trespasser CD, trespass.exe, the ATX Trespasser executable, or whichever EXE is crashing), select Properties, select the Compatibility tab, check “Run this program in compatibility mode for:”, select Windows 95 or Windows 98 from the drop-down menu, click OK. This is also possible in Windows 2000 with a few extra steps (search MSDN for Windows 2000 compatibility mode).

Intro video playing too fast, broken sound, fatal error when launching the ATX or game executable

-> For this, ATX needs to be downloaded and extracted, and you must have tried to run it at least once. Open ATXconfig.ini (in Notepad), find the section [Troubleshooting], set DisableA3DdllDetection=1 instead of 0, and save the file. This error is caused by the presence of an incompatible A3D.dll file in your system folder. This fix simply disables its detection by Trespasser. Note: This disables 3D sound.

Missing or unable to find ATXconfig.ini configuration file

-> Run the ATX executable once, then exit the game. ATX generates this file only on first run (this makes updating easier).

What files does ATX need to run?

-> At bare minimum, in your Trespasser folder, you should have the files ATYPEX.dll, trespassATX2.exe (or another ATX-patched executable), and a MAPS folder (with all the content from the latest atx2XX.zip package). There should also be a ATXconfig.ini generated after the first launch (when absent, ATX uses the default configuration).

User-made level is messed up after restarting, loading a saved game from the same level, or after selecting “Restart Level”

-> Check the ATX “Disable Fast Restart” option checkbox at the main game menu. This helps fix some problems with scene files and savegames not reloading properly. Note: A few levels with specific issues (such as broken terrain) don’t work properly with this feature.

Game crashing randomly when there are lots of things on screen or right after a level finished loading

-> You might have set the Draw Distance value too high. Go back to the video options menu, and slide it all the way to the left. Also, try enabling hardware rendering if you haven’t (using the “Select New Video Driver” button); some levels don’t work properly in software mode.

Nothing working under Windows Vista or Windows 7

-> Sorry, ATX hasn’t been tested to work under Windows Vista or Windows 7.

KNOWN BUGS

Here is a partial list of known problems with ATX and Trespasser. Some bugs are documented only in the documentation sections of the specific features they concern (there are just too many quirks to keep track of).

- On some systems, the text and graphics displayed by any cheat or drawing function (“LOC”, “TIME”, “MAP”, etc.)
  flickers constantly. This seems to happen mostly on newer systems and is common to Trespasser in general.
  Usually, restarting the game or the computer (one or more times) eliminates this.

- If you attempt to load a level and get a Trespasser message saying
  that you are out of hard drive space to load the level, you should
  exit the game before attempting to load any other levels (and, of course,
  tweak your tpass.ini or registry settings to allow more space to be
  allocated, or free up some hard drive space)

- Using the AIM function/cheat in the North Pole Chaos level may
  crash the game (thanks to GigaY2k). It seems to cause memory
  errors and occurs mainly when the aimdot ray intersects with the terrain.
  Not sure whether error occurs due to simple lack of memory (generated by CFastHeap)
  or due to terrain structure itself.

- Changing video drivers (SOFTWARE/DIRECT3D) while a game is running
  can cause problems and is greatly discouraged. Typically, doing so will
  cause Trespasser to re-initialize a level, which will cause ATX to treat it
  as a new level load. Some features may behave unexpectedly.
  Please change video modes only when doing so from the Main Menu screen.

- The Video Options menu Draw Distance slider value is not
  affected by the menu’s OK and CANCEL buttons. The draw distance
  is set as soon as the slider is moved.

- The in-game draw distance hotkeys do not save the draw distance
  after the game is exited.

- Player coordinates on the map are dependent on the accuracy
  of the custom map’s settings. The example bitmap(s) provided
  in this package are not accurate.

- Setting the game speed higher than 1.000000 _may_ cause crashes under
  some circumstances (more likely when in software mode).

- TresStrDbg may occasionally not display output properly
  (i.e., white text on white background). Reboot your computer
  to fix this.

- If the level files in your “Patch” folder do not match
  the ones from the “Tres CD” directory, some features may
  not work properly upon level restart (this typically applies
  to those who installed the large 1.1 Trespasser patch).

- Some user-made levels have occasional problems using Trespasser’s software
  mode. Because of this, using the windowed mode (which requires software mode)
  may cause crashes and/or lockups and is not recommended for any level
  that is meant to run in hardware video mode.

- All cheats that manipulate camera movement are prone to errors/crashes/general
  misbehavior. Please read their respective documentations in the cheat documentation
  section of this file. Also, some of these cheats may produce sudden bursts of movement
  upon keypress when encountering framerate slowdowns at the same moment. This is
  due to the custom input system; no fix will be attempted.

- All interval and time-based values are constant and will not be modified
  to reflect game speed changes. As a result, any ATX-based feature that relies
  on time values will not be affected by changes in the game speed variable.

- In some cases, after restarting a level, Trespasser does not re-initialize
  the dino instances properly, causing them to ‘forget’ certain actions. One
  of these is the “ActBite” behavior. The dino jump code relies on the latter and
  will not work if it does not. You may need to restart the game to fix this
  (or try the “Disable Fast Restart” option in the main menu).

- In-game videos require that the “NoVideo” registry entry (for full game version)
  or INI file entry (for demo) be set to 0 or be absent. If its value is set to 1,
  all videos, including those summoned by ActionType 105, will be dismissed.

- Windowed Trespasser and TresStrDbg may not function properly depending on your video
  card drivers and operating system. These are provided for testing purposes only.

- Some display-related features don’t function or display properly in resolutions lower than 640*480.

- The Disable Fast Level Restart feature, and any other feature which uses it (including Night Mode), is known
  to cause crashes during level reloading with the Four Towers extended level (new lab.scn).
  Exact cause is unknown (may be related to level’s terrain).

- The SMK video resizing feature exclusive to ATX may cause problems for older video cards with limited
  DirectX (DirectDraw 6) support. It can be disabled in the configuration file if needed
  (see SMK VIDEO PLAYBACK RESIZING).

FREQUENTLY AND NOT-SO-FREQUENTLY ASKED QUESTIONS

This is a collection of old questions and answers that haven’t been updated in a while
but that may still be relevant and thus remain here for the sake of completeness. Some answers
may be out of date or relate to ATX versions prior to 2.00 (but may also still apply).

Q. How do I install and run ATX with the new features?

A. Please read the Installation section.
Once installed, make sure you run the game from
the newly-created ATX Trespasser executable in your main
Trespasser folder (usually “trespass_ATX.exe”), and not
from your start menu or other shorcuts. Once again, you
do not have to run the ATX Patcher more than once; when
you upgrade your version of ATX, all versions share
the same executable patch. You only need to overwrite
ATYPEX.dll, ATXconfig.ini, and any files in the “MAPS\” folder.

Q. Is gameplay paused during in-game video playback?

A. Yes, it should be. When the user presses a key other
than ESCAPE (or if the video ends), the video will terminate
and gameplay will continue where it left off.

Misc. note: All videos will play in a resolution
of 640*480, regardless of current video resolution.
Thus, if you are using a lower resolution, you will
be missing portions of the displayed video.

Q. How do I change the draw distance/blocky 2D rendering?

A. *** As of version 1.34 BETA, the draw distance can be
modified as expected in the video options menu
(note: “OK” and “Cancel” buttons have no effect on the Draw
Distance slider; the new value is set as soon as the slider
is moved).

The draw distance variable and others can be set by changing
values in the ATXconfig.ini file, under the section “Variables”.
Simply open the INI file, look up the appropriate entry,
and enter a new value (no spaces) after the “=”. The default value
is 15.00000; if your computer is fast enough, try setting it to
100.00000 or higher (make sure to save your changes afterwards).

You can also assign hotkeys via the ATXconfig.ini file under the
“HotKeys” section to increase and/or decrease the draw distance
while the game is being played.

The draw distance can also be changed for the normal Trespasser executables
by modifying their default values with a hex editor at specific addresses.
See DRAW DISTANCE VARIABLE ADDRESSES for details.

Q. Can I set the draw distance higher than what the new slider allows?

A. Yes. The Video Options ATX draw distance slider has a value range
of 15.000000 to 315.000000. You can set a higher value in ATXconfig.ini
by looking up the section [Variables] and setting ObjectClarityDrawDistance
to a higher value. This will not cause any conflicts with the slider;
as soon as you move it again, the draw distance will revert back to
a value within the slider’s range.

Q. How do I enable random dinosaur start positions?

A. For the full-version of Trespasser, it can be toggled
using the appropriate checkbox in the main menu screen
of the game or in ATXconfig.ini. Demo level users may
enable it via ATXconfig.ini (only), but it will have no effect
unless a corresponding list file is written for the level
(which will not function easily as dinos are teleported via triggers
in the default level).

This feature is only available for certain levels. As
of version 1.34 BETA, all default full-version Trespasser
levels are supported. Support for other levels (user-made)
depends on the willingness of their authors to write
list files for these. The demo level of Trespasser is
not supported by default.

Q. What about the high-resolution patch? Will it work
with ATX?

A. As of version 1.34 BETA, the high-resolution patch is
included in the package, with respect to its original
authors. If you had already applied it to executable
before patching using ATX (or after), the patch will
work fine, but you will not be able to toggle it
on/off via ATXconfig.ini (always enabled).

See HIGH-RESOLUTION PATCH for details.

Q. Ever since installing ATX, every time I save a game,
a second file named “SAVEDMAP.xxx” appears. What is it?

A. SAVEDMAP.xxx are files used by ATX to save your game data
that wasn’t included in the Trespasser-generated
savegame. It typically includes info about the
new ActionTypes incorporated in ATX, which are exclusive.

Q. How can I make the raptors jump better?

A. ATX 1.61 has a few settings that can help a little bit.
The global defaults can be set in ATXconfig.ini under
[ActJumpNew]. They are described in the ActJumpNew
text, with a few example settings.

Q. Does ATX work with my savegames or with new savegames?

A. Although a lot of effort has been put into attempting to
make features compatible with savegames, some may
unfortunately not work properly under some circumstances
or even not at all. As a general rule, you should be
able to load savegames without any major issues, but
when you save new games under ATX, I can give no guarantee that
the state of all new features enabled at save time will be preserved when
you next load them.

Q. Can I run ATX under Linux?

A. Although ATX has never been officially author-tested
to work with Linux, it has reportedly been run successfully
by some users under some versions of this operating system,
particularly WINE.

While not all features are guaranteed to work and
may be prone to lockups/bugs/crashes, under the right
conditions and default settings ATX should generally
run as far as the game goes. However, in order to get
the mod to load properly, you may have to apply the
following setting in ATXconfig.ini:

[General]
UseOldVirtualProtect=1

(keep all other values present and tweak as you wish)
This setting instructs ATX to use a different API
call before applying hacks in real-time. It can
counteract an unfinished Linux implementation of
the standard Windows VirtualProtectEx call by
using a call to VirtualProtect instead.

* Note: For more information on running Trespasser/ATX
under Linux, I would suggest looking up the Linux
section of the Trescom.org forum. Thanks to Dapper Dan
and other members for testing ATX under this operating system.

Q. The game crashes during loading or while in play. ?

A. This may be due to several factors, including (but not
limited to) bad MapIndex.ini entries, bad ATXconfig.ini
entries, or a general flaw. Please keep in mind that
ATX will always be a BET

A. If you do run into crashes
or unexplainable game behaviour, please e-mail a
description of the problem at whatever address may currently
be posted on my website, along with any “error.log” or “ATX_LOGFILE.txt” files
created in your main Trespasser directory. If the problem
is visual in nature, I would appreciate screenshots
as well. Also, please specify your executable type/processor,
the version of ATX you are using, and your operating system.

Q. Why is video recording so unbearably slow?

A. The biggest problem is that screen capture is done by
copying “screenshots” directly from video memory to standard
memory. Reading large amounts of data from video memory
is generally slow. The only alternative I know of is
to intercept “screenshots” before they are written to
video memory; but, without the Trespasser source, this
is virtually impossible to accomplish.
Update: The ATX v1.50 Video Recording (REC) cheat
documentation now describes a “System Memory” key that
can be used to increase raw framerate when recording.

The encoding process is also extremely lengthy, but fortunately
can be left at the end of the recording in order to not
impede on framerate. Note that the routine used by ATX may be
poor compared to the ones of other programs due to compatibility
issues with the Video For Windows AVIFile API functions.

Q. Will ATX diminish game performance?

A. It may, but the difference is hardly noticeable on
most fairly recent computers (edit: and even on old ones)
At its worst, it will consume
a few extra megabytes of RAM and will slightly diminish
framerate, but this is the case mainly when many features
are enabled at once or when large 2D maps are displayed
in high resolutions. There may be a few seconds
added to general loading time and some increased disk
activity during loading, depending on the speed of
your computer/hard drive and the amount of RAM in the system.

(As of ATX 1.50) If you have an older AMD processor,
such as a K6-2 or K6-3, you may want to enable the
ATX-based 3DNow! optimizations via ATXconfig.ini. They
may increase performance for some specific features.

Q. How do I verify which version of ATX I am using?

A. Right-click on the ATYPEX.dll file where you extracted
it and select “Properties”. Then, select the “Version”
tab. The current version will be displayed beside
“File version:”.

* As of version 1.34 BETA, the version number is
displayed in the top-right corner of the main menu screen,
as long as the new ATX menus are not disabled.

Q. What is the “MAPS\” folder for?

A. As you may have noticed, naming things isn’t quite my forte.
See the “MAPS\” folder and sub-folders portion
of this file for a more detailed explanation.

Q. How do I enable maps for specific levels?

A. See TOP-VIEW 2D MAPS.

Q. This thing you call “TresStrDbg” locks up as soon as
I run the game. What gives?

A. If the wrong values are used in the ATXconfig.ini file,
the program may stall for a good while (but not indefinitely)
at a certain string display. You will need to learn how
to use the keyboard commands to use this feature. Please
read TRESSTRDBG for more details.

Q. Windowed mode crashes! And why doesn’t it have a frame?

A. The windowed mode is a very basic hack meant to trick
the video driver into drawing to a smaller screen. It does
not manage a typical window.

Windowed mode will not work on all systems, but here
are a few pointers that may help:

- Run in software mode

- Set your desktop color settings to 16-bit

- Use a standard 4:3 desktop resolution (i.e., not widescreen)

- Switch video drivers

See WINDOWED MODE (SEMI-)
for more details.

Q. How do I enable specific features (MatrixTres, etc.)?

A. By setting values in the ATXconfig.ini file provided
in this package. Most entries are described in
ATXconfig.ini File Details.

Q. Can you make a stegosaurus wear medieval armor and shoot laser beams?

A. No. If I could I would have! But, animations and graphics
in general are out of my league. This includes Anne riding cars,
dinos riding cars, cars riding dinos, etc.

Q. Why is ATX written in assembly? Couldn’t it have
been done in a high-level language such as C or C++?

A. The ATYPEX.dll file could have been written easily
in another language for the most part. However, the
bulk of my programming experience is in the assembly
department and I feel more comfortable using that language.
Some parts of the DLL would have ultimately required some
assembly anyway, mainly for code pertaining to
executable modification.

Q. Why do some of the new ActionTypes and/or values
do what could already be done using existing T-Scripts?

A. Testing purposes, and… general ignorance.

Q. Why are 2D maps only assigned to levels in a single
*.ini file, MapIndex.ini? Won’t it be annoying to have
to copy/paste into that file when installing new maps
with top-view 2D map support?

A. MapIndex.ini was designed solely for use with existing
Trespasser levels. New levels do not have to use
this file to incorporate 2D maps; it is highly
recommended that new levels use ActionType 102 to
load maps at level start instead (see New ActionType Reference).

It would possible to easily add ActionType 102 support to existing
levels, but this would lead to having to upload and
download these maps as a separate package.

Q. I would like to hack Trespasser. Where should I start?

A. You will need to know assembly programming for this. There
are plenty of tutorials on-line, as well as good books.
The “Art of Assembly” (Copyright 1996 by Randall Hyde)
is a great starting point; I highly suggest looking into the
Win32 programming editorial from the same author as well. You will
also need basic Win32 programming knowledge; Iczelion’s MASM32 tutorials at
http://win32asm.cjb.net are very good. I recommend downloading
the “WIN32HLP” documentation for a standard Win32 API reference,
as well as the Intel 386 (or later) Programmer’s Reference for a standard list
of integer-based CPU instructions.

As for tools, there are many available. I use FASM (flat assembler)
for assembling code, W32DASM v8.93 for disassembling executable files,
WinHack 2.00 to edit memory on-the-fly, and XVI32 as a hex
editor. I highly recommend XVI32 and FASM. I also recommend learning
the MASM syntax, which differs from FASM’s, as many of the online
tutorials are written using this format.

[Edit: I also highly recommend using the OllyDbg 1.10 disassembler
if you are running Windows 2000 or XP. It provides much more flexibility
for data analysis and for setting breakpoints.]

Once you have sufficient knowledge, it all comes down to finding
portions of code that relate to certain aspects of the game. This
is the difficult part that can only be described as VERY tedious
hours of debugging. What follows is the actual code modification,
which is just as involved but can be tricky. It can be done by
compiling code using an assembly (i.e., FASM) and copying this
code via a hex editor into the executable, or by using DLL-based
self-modifying code as is used in ATYPEX.DLL.

I will not be writing an essays on the matter; this would take
time that would be better spent hacking. You will have to figure out
the specifics on your own. However, feel free to ask questions
about specific EXE addresses or such; I’ll answer as long as I don’t
have to write an entire tutorial about it ;).

Q. How do I set breakpoints with my debugger when running
a Trespasser executable?

A. If you’re really asking this question, you’ve probably
noticed that loading a Trespasser executable into your
debugger and setting a breakpoint at a code location
known to be run will lock up the game. That’s because
Trespasser runs in DirectDraw Exclusive cooperative mode,
and keyboard commands (such as ALT-TAB) are ignored.
Generally, your debugger will run into the breakpoint,
but you’ll be unable to access your debugger’s interface.

First of all, few debuggers seem to work with Trespasser.
The game already has an error handler and manages a few
threads at a time, and some debuggers seem to go haywire
if you try to use them at all. The only one I’ve bothered
to try to use extensively is W32Dasm v8.93, by URSoft.
All you need to do is get yourself a legal copy, disassemble
the ATX-modified version of the Trespasser executable, enable
windowed mode in ATXconfig.ini, set an adequate resolution
in tpass.ini or in the registry (640*480, 800*600, or anything
smaller than your desktop size), and you’re set for setting
breakpoints (you’ll maybe need to use ALT-TAB to access
the interface once the breakpoint is reached).

Q. How do I disable videos?

A. For the full Trespasser game, this can be done by
creating a registry entry in the main Trespasser registry
key (HKEY_LOCAL_MACHINE\SOFTWARE\DreamWorks Interactive\Trespasser)
with the name “NoVideo” and of type “DWORD”. Setting
the entry to a value of “1” will disable all videos,
including in-game videos set off using ATXTres’s
ActionType 105.

For the demo, the same can be done by adding a “NoVideo”
entry with a value of “1” in the “tpass.ini” file in the
demo folder.

Q. How do I use the cheats/cheat-enabled features?

A. During the game, press CTRL+F11 and enter the appropriate
cheat/feature’s name in the console. Then, press Enter.
Use the ESCape key to exit the console afterwards.

Q. I get an error message upon loading Trespasser and
I have recently installed new sound drivers. Why?

A. Some sound card drivers ship with a file named
“A3D.dll”. Trespasser normally uses this file in
the windows system directory to play 3D sounds.
However, some sound cards use the file of the
same name for other purposes; as a result, when
Trespasser tries to use it, it does not function
properly. Try removing this file temporarily
from your Windows “System\” folder; in some cases,
this may allow the game to run with the original
game executables. However, the better alternative
is to read GENERAL SOUND PROBLEM FIX (A3D.DLL)
and use the ATX feature to do this (it will not
apply to the original game executables, unfortunately).

It is possible that the ‘A3D.dll’ file be source of
other problems as well [such as having no sound or
corrupted video playback].

Q. I get horrible flickering whenever I run Trespasser
in software mode in the menus and in some parts
of the screen during the game. I am using a 3dfx Voodoo 3/4/5 card.
What’s going on?

A. I have noticed this problem to be frequent when using
numerous third-party video drivers. I highly recommend
re-installing the official 1.05.00 or 1.07.00 drivers
(for Win9x/ME).

Q. Why do objects flicker when I run the game in
hardware mode?

A. This problem has been around for awhile. Although there
is no definite answer, using older drivers for your
video card is generally suggested as a solution.
If you have a Geforce 3 card running under Win98SE/ME,
try getting a hold of the 40.72 WHQL-certified driver
package from Nvidia.

Q. Why are there many different Trespasser executables of
the same version?

A. There are three versions of the Trespasser executable
per executable version. Each is optimized for certain
types of processors. You can identify these by
right-clicking on the files, selecting “Properties”, and choosing
the “Version” tab. The proper file is detected, selected, and copied
upon installation of the game; all three can be found on
the Trespasser CD, under the “Setup\” folder (though
they may not exactly match your current executable if you
have applied a patch to the game).

The standard executable is of type Pentium (P5) and works with
all supported processors, including AMD. However, it is only
used if your processor is a fifth-generation Pentium or Pentium
with MMX technology. Then comes a Pentium Pro (P6) type
file which is designed for sixth-generation and latter pentiums
(PPro, P2, P3, P4, Celeron, etc.). It will also work on AMD Athlon
processors. Lastly exists an AMD K6-optimized version that will only
work on AMD K6 or better processors. This executable is optimized
using 3DNow! and MMX instructions (though not thoroughly). Oddly enough,
there do not appear to be any MMX optimizations available for Intel processors
in Trespasser.

The Trespasser demo executable is a file of the same type as
the 1.1-patched Pentium (P5) full version exe.

Q. Are you a real hacker, as in do you have my credit card number?

A. No, don’t worry; that’s not my thing. I haven’t been “hacking”
for all that very long either. All I have “hacked” are programs
which I paid for in full but that did not do justice to the money I had
paid for them (Buy four new Homeworld CDs just for LAN play? No thanks!).

Obviously, reverse engineering a game like Trespasser might bring up
some legal issues, but who’s rights am I infringing on if there’s really
no company left to sue me? Who has anything to lose from this?

And wait; wouldn’t this have _helped_ their product, anyway?

Q. … And It All Comes Down To This: What does ATXTres stand for?

A. Not much, really. Originally, it stood for
something like “eXtra ActionTypes Trespasser” or
“Trespasser ActionTypes X”, because it was made mainly
for the new T-Script ActionType values. I don’t really
remember what the actual wording was; it just sort of
all merged into one acronym. I guess now I’m kind of hoping
it’ll just make a new word out of itself.

TECHNICAL BUG FIXES AND ENHANCEMENTS

One of the main reasons ATX has for existing is getting around some of Trespasser’s quirks. Here
are some of the most useful fixes, workarounds, and optimizations.
</P?

- 3DNOW! OPTIMIZATIONS

- DEMO VERSION EXIT SCREEN REMOVAL

- FAST LEVEL RESTART DISABLING

- MENU KEYS FIX

- SOUND PROBLEM FIX (A3D.DLL)

VIDEO AND RENDERING ENHANCEMENTS

Here are various video- and rendering-related features that can help make the game look better.

- DRAW DISTANCE AND GAME SPEED VARIABLES

- HIGH-RESOLUTION PATCH

- WINDOWED MODE (SEMI-)

- VIDEO RECORDING

- SMK VIDEO PLAYBACK RESIZING

- FIELD OF VIEW SETTINGS

GAME ENHANCEMENTS

These features permit the user to alter game behaviour in ways that might radically later game experience,
or simply add a few useful transparent tools.

- AI HACKS

- DIFFICULTY SETTINGS

- HEADS-UP DISPLAY (HUD)

- JUMPING DINOS (ON ACTBITE COMMAND)

- MAPS (TOP-VIEW, 2D)

- MATRIX EFFECT

- NIGHT MODE

- PARTICLE-BASED RAIN/SNOW EFFECT (EXPERIMENTAL)

- PATH TRACING

- OBJECT LOCATION RANDOMIZER

The following features are either incomplete or have been abandoned.
Not all abandoned features will be documented here, but rather only
some of the ones that are kept part of the ATX package as reference.

- MAX ACTIVE DINOS

KEYBOARD AND MENU ENHANCEMENTS

ATX provides a few ways to make changing game options and accessing game features easier and more efficient.

HOTKEYS
NEW MENU OPTIONS
QUICK SAVE

Special note about character sets and keyboards

In any area where hotkeys and text may be inputted, ATX and Trespasser generally assume a standard ASCII
character set. Use of international characters can cause unpredictable results. Particularly, please refrain
from using non-ASCII characters in ATXconfig.ini or on the command line.

NEW CONSOLE COMMANDS/CHEATS

While many of the original Trespasser cheats were not included
in the official releases, they have been almost entirely restored
in ATX for all four supported executables (including the demo).
This includes the INVUL, DINOS, BIONICWOMAN, and WOO cheats. The
DINOS and WOO cheats function exactly as the originals, while
additional changes had to be made to the two other cheats (see list).

There have also been numerous new cheats implemented into the game.
These are individually documented below.

To bring up the console in-game, simply press and hold CTRL and F11
at the same time. To exit the console, do the same or press ESC. As
a general rule (though not necessarily for all cheats or new cheats),
you enable cheats by entering their command once, and disable them
by re-entering the same command at the console. As of version 1.60,
ATX provides an easy way to toggle most cheats using hotkeys, avoiding
this entire process; see HOTKEYS for an updated description.

* As of ATX 2.02, you may use the CH cheat at the console
to display a rudimentary in-game cheat name listing.

Note that some cheats require a parameter to enable; please read their descriptions carefully and
avoid entering cheats randomly. In some cases doing so may crash the game or cause unexpected behaviour.

Here is the list of all new or modified Trespasser console commands
included in ATX (as you would type them at the prompt, excluding
possible parameters):

- AIM

- B & N

- BIONICWOMAN

- BUFSIZE

- CANIMAL

- CDINO

- CH

- CLOAK

- CPBCNT

- DUMP

- FLY

- FLYTELE

- FOLLOWDINO

- FPS

- GSPD

- HEALDINO

- HUD

- INVUL

- LINST

- LOAD

- MAP

- MDINO

- MSEL

- NORMALHP

- OBJ

- OBJAIM

- OBJN

- OBJF

- PLAYERHEALTH

- PLG

- REC (video recording)

- RESET

- SHOWDD

- SUICIDE

- SUPERHP

- TRACES

- TELEDINO

- THIRDP

- TIME

- TN

- TOGGLERAIN

Special Note for “FOLLOWDINO”, “THIRDP”, and “FLY” cheats

These cheats have NOT been optimized, nor checked for all possible inconsistencies
in their 3D programming. They may be CPU-intensive; you should check ATXconfig.ini
for fraterate or input interval values. Generally, these values are set to provide
smooth controls and may be overkill for systems that go nowhere near the full 60 fps mark.
As well:

- YOU CANNOT USE THESE CHEATS AT THE SAME TIME

- CHEATS MAY BE DISABLED UPON LEVEL LOAD/RESTART TO ELIMINATE POTENTIAL MEMORY-RELATED CRASHES

- THESE CHEATS DO NOT CHECK FOR BAD CAMERA PLACEMENT/CAMERA-OBJECT COLLISION/OCCLUSION

- THESE CHEATS MAY INTERFERE WITH THE MENU AND EVEN CERTAIN LEVELS.

Other notes

Not all new cheats are necessarily documented. Some may be too incomplete
for official use or may work only partially and have been left out of
this text for these reasons. The full list can be found in the ATX source code.
If you use any undocumented new cheats, you do so at your own risk (like anything else, really).
They may cause errors/crashes/freezes.

This lists the names of all cheats currently and directly recognized by the Trespasser console.
These include standard Trespasser cheats and ATX cheats (but not possible Plugin cheats). Note
that the list may cut off at lower screen resolutions. Remember: some cheats require
parameters to function and may even crash if they are omitted.

AIM

(New in ATX 1.57) This cheat was designed to add better weapon precision when using the THIRDPerson cheat.
The feature can also be toggled using a character key as noted in the THIRDP cheat description.
When enabled, when Anne is holding a gun, an aimdot of varying size will be projected
onto the screen, giving a precise location for the next shot, regardless of type of weapon used.
It will also work in first-person mode. Unfortunately, the cheat suffers from the same problem
as the BONES cheat: it does not fully take into account depth of objects in a scene and thus may
project the aimdot where it should have been hidden from camera view by a closer object. It is also
less useful at long range than it is at medium and short range.

This feature uses a RayCast Trespasser function used when calculating gunshot trajectories. Such
paths are displayed by the BONES cheat as grey lines, and only one at any given time. Because of this
last point, enabling both AIM and BONES at the same time will cause the BONES cheat to report
the grey RayCast line used by AIM as if it were a typical gunshot, even though it is not. This has no
effect on gameplay.

OBJAIM

This cheat works in coordination with the OBJ and AIM cheats. When AIM
is enabled and OBJAIM is as well (OBJ need not be), ATX will display an OBJ cheat-type information listing
about the object currently pointed to by the AIM aimdot. Due to depth sorting issues discussed
in the AIM cheat description, in some cases, the dot will appear where it should not and may
give misleading information about which object is currently designated.

INVUL

This cheat toggles invulnerability. It will also prevent the grey overlay
effect used when Anne is hurt. However, it will not work in all situations,
such as level-scripted “death” areas. You should combine this with the SUPERHP cheat
for complete protection.

LINST

This function displays info about the current instance from one of Trespasser’s
internal instance ‘trees’. Every time this cheat is toggled, the current instance
will be set to the one at the root of the tree. To cycle through the tree nodes,
custom key entries are provided in ATXconfig.ini, under [HotKeys]:
LINSTCycleLeft (jumps to ‘left’ tree node from current if existing, which should hold an instance
with an Instance ID of lower value than that of the current instance), LINSTCycleRight
(same, but for ‘right’ tree node with higher Instance ID), and LINSTCyclePrevious (goes
to ‘previous’ tree node). The tree is standard: nodes going to the ‘left’ contain
lower values (in this case, lower Instance IDs) than the current node, while nodes
going to the ‘right’ contain higher values than the current node. This particular
tree is used by Trespasser to fetch instance addresses from instance IDs. *** Note:
This cheat is detailed for experimental purposes only. I can not guarantee that it
makes proper use of the tree at this time.

BIONICWOMAN

-> BACK TO CONSOLE COMMANDS
-> BACK TO CONTENTS

This toggles slow/fast game speed. However, unlike the original cheat,
it will use the custom speed settings from the MatrixTres feature defined
in ATXconfig.ini, under the [MatrixTres] section (see ATXconfig.ini description).

MAP

This cheat will display a 2D map of the current level if existing.
This will give you a real-time map view with a cursor indicating
your position if the map’s settings were set correctly. If you
are not within the specified map coordinates, the cursor will
be ‘inverted’ and follow your position at the edge of the map,
indicating your general direction. This cheat supersedes the
“LOC” cheat, but functions similarly.

Here is the documentation regarding the defining and usage of 2D maps.

MAPS

IMPORTANT NOTE: ALL BITMAP NAME STRINGS MUST SPECIFY _ONLY_
THE BITMAP’S NAME WHICH IS TO BE FOUND IN THE “MAPS\” FOLDER. BITMAP
NAMES CAN BE NO LONGER THAN 79 BYTES, INCLUDING “.BMP” EXTENSION.
FAILURE TO FOLLOW THESE GUIDELINES MAY RESULT IN GAME CRASHING.

AS OF VERSION 1.34, THE FORMAT OF THE MAPINDEX.INI ENTRIES HAS
CHANGED TO ACCOMODATE SOURCE CODE CLEANUPS AND BUG FIXES.

Maps are the most potent feature of ATYPEX.DLL. They are top-view
2D representations that can be loaded and associated with certain
levels, or changed in real-time within a certain level via
T-Scripts.

The view the currently active map, bring up the console using
CTRL+F11 and type the word “MAP” (press escape to exit console).
This will give you a real-time map view with a cursor indicating
your position if the map’s settings were set correctly. If you
are not within the specified map coordinates, the cursor will
be ‘inverted’ and follow your position at the edge of the map,
indicating your general direction. This cheat supersedes the
“LOC” cheat, but functions similarly.

If no map is present at loading, a message will be displayed
instead. There are a few default maps for a few specific levels
for demonstrative purposes, but these have not been made with care.

There are two initial ways to load (a) map(s) for a certain level.
The first is via ActionType 102 (Load New Bitmap). This method uses
a level’s T-Script to specify a certain map. It is described in
New ActionType Reference. This permits loading maps at any time during a
level and is highly recommended over the next method for user-made
levels.

The second method is to use the “MapIndex.ini” file situated in the
“MAPS\” folder to assign maps to specific levels. The values needed
to do this are the same as in AT102. This file will only assign a
bitmap at loading time, but permits using maps with pre-existing levels
without having to modify their scripts. The syntax for the entries
is described in the INI file and is fairly straightforward.

In both cases, the only information needed besides the bitmap’s file
name are the player positions (X,Y) at the upper-left and lower-right
corners of the map. Maps can ONLY be aligned with the level’s X
and Y axises.

The last feature worth mentionning is the ability to associate certain
maps to savegames. Using ATYPEX.DLL, when you save a game, a second
save file will automatically be created (i.e., “SAVEDMAP.XXX”) and
will hold information describing the active bitmap at the time of
save. The information will be loaded along with the savegame later,
so you will re-enter the game with the proper map. This permits
level designers to incorporate more than one map in their levels via
ActionType 102 without having to worry whether the right maps will
be loaded when games are saved in different locations. If there is
no currently loaded bitmap, no secondary file will be created.

If a savegame does not have a secondary save file, the game will
load a bitmap from the MapIndex.ini file if an entry for the savegame’s
specified level exists.

If a bitmap cannot be loaded for any reason, the previous map will
be kept instead. If no map was loaded beforehand, a
“NO BITMAP LOADED FOR MAP” or similar message will be displayed.

Note that there is no bitmap “stretching” performed (this kind of
resizing can be CPU-intensive); as a result, I recommend using a
maximum resolution (for the bitmap) that corresponds to the game’s
minimum resolution.

MapIndex.ini file

This file allows association of bitmap maps in the ‘MAPS\’ folder with
specific level files. They will be used as default maps for these levels,
but can be overridden by T-Script level entries and savegames created
by the hacked executables’ DLL.

The file also allows custom positions for customized map regions and
scales, which can also be overridden in the same fashion.

- ALL ENTRIES ARE SENSITIVE TO ORDER AND SPACE/TAB CHARACTERS. IMPROPER
  ORDER AND/OR STRUCTURING OF VALUES MAY CAUSE GAME TO CRASH.

- ONLY ASSOCIATE ONE BITMAP PER LEVEL.

- ONLY SPECIFY DIRECT BITMAP FILENAMES, AND THESE CAN BE NO LONGER
  THAN 79 BYTES INCLUDING EXTENSION.

- NO PATHS; ALL BITMAPS SHOULD BE PLACED IN “MAPS” DIRECTORY.

- MAPS MUST BE ALIGNED WITH THE LEVEL’S X AND Y AXISES,
  THE X AXIS REPRESENTED HORIZONTALLY AND THE Y AXIS REPRESENTED
  VERTICALLY ON-SCREEN.

- PLEASE FOLLOW EXACT SYNTAX.

EXAMPLE ENTRY

[LevelName.scn] 	; SCN level name
Bitmap=BitmapName.bmp	; name of bitmap to load from 'MAPS\' folder, with extension
X1=XXXX.XXXXXX		; X position at upper-left map corner (float)
Y1=XXXX.XXXXXX		; Y position at upper-left map corner (float)
X2=XXXX.XXXXXX		; X position at bottom-right map corner (float)
Y2=XXXX.XXXXXX		; Y position at bottom-right map corner (float)

TIME

Displays the elapsed time from level start (hours:minutes:seconds).

Teleports player to next stratetic location in map. Same as Trespasser’s TNEXT cheat, but does not erase the command from command line after it has moved player (user request).

TOGGLERAIN

This toggles the experimental rain effect display, if the feature
is currently enabled in ATXconfig.ini.

RESET

Resets the counter as shown by the TIME cheat to 0.

TRACES

This cheat/feature (new from ATX 1.60) can display a series of cursors on a 2D map activated by the MAP
cheat that represent some of the last positions the player has visited in the level.
If there is no 2D map for the current level, this cheat will not produce any output.
For this cheat to function, you must first open ATXconfig.ini, find the [PathTracing]
section, and set EnablePathTracing to 1. Entering the TRACES cheat will not toggle
the feature, but only whether or not it is currently being displayed on the 2D map.
When you first start the game, TRACES display is disabled by default.
The other values in the [PathTracing] section affect the display characteristics (cursor color, duration, etc.). See
ATXconfig.ini File Details for brief descriptions of
these value.

Note: Player paths recorded using this function are NOT preserved in savegames
or across level restarts/loads.

CANIMAL

* CANIMAL has been updated in ATX 2.07

This console command displays the currently selected (active) dinosaur
from the complete list of CAnimal instances and related
information from the current level, if the level has
dinosaurs. It works in conjunction with other cheats
(N, B, etc.).

ATX 2.07 adds new values from the CAnimal class which can be displayed by this cheat. By default,
only the most necessary/active will be shown. You can get access to more values by specifying
them under ATXconfig.ini. Simply browse to the [CAnimalDisplay] section and add any combination of these lines:

[CAnimalDisplay]
InstanceName=1
BaseAddress=1
NameHash=1
Location=1
HitPoints=1
MaxHitPoints=1
ActJumpNewInfo=1
Sleep=1
WakeUp=1
Bravery=1
Fear=1
Love=1
Anger=1
Curiosity=1
Hunger=1
Thirst=1
Fatigue=1
Pain=1
Solidity=1
HumanFear=1
HumanLove=1
HumanAnger=1
HumanCuriosity=1
HumanHunger=1
HumanThirst=1
HumanFatigue=1
HumanPain=1
HumanSolidity=1
DamageFear=1
DamageLove=1
DamageAnger=1
DamageCuriosity=1
DamageHunger=1
DamageThirst=1
DamageFatigue=1
DamagePain=1
DamageSolidity=1

Each of these lines will enable the on-screen display of a specific value stored in the currently selected CAnimal instance, the nature of which
can be guessed by their names in this list. Many are related loosely to their similar T-Script counterparts.

These values are boolean. The value “1” assigned to a key name means it should be enabled in the CANIMAL cheat display. The value “0”
signifies the value will be excluded. “0” is equivalent to omitting the key name from the [CAnimalDisplay] section entirely.
The order in which values appear on-screen is predefined. Also note that oscreen space is often limited, so
take care not to enable too many.

ATX 2.07 also allows you to toggle the display of each of these values while in-game (although these changes are temporary). To
activate or deactivate the display of any one of these values, simply open the console, and give the value’s corresponding key name
from the above list as parameter to the CANIMAL cheat (the display will not disappear if you enter a parameter).

For example,
typing “CANIMAL HitPoints” + ENTER at the console will hide the current animal’s health from being displayed, or add the value
to the list of values displayed if it was not.

NOTE: This cheat was conceived to work within a resolution of 640*480 or higher.

CDINO

This cheat works in conjunction with the CANIMAL, B, and N cheats. It will
select the CAnimal dino instance that is currently closest to the player.
If two dinos are at the same distance, the first one in the list will
be selected.

DUMP

This cheat collects all text information that ATX is displaying in-game and on-screen at the
time of command entry, and saves it to ATX’s ATX_LOGFILE.txt. You can later open the log file to
retrieve the saved data. If you want a time indicator for each save attempt, simply enable the
TIME cheat to print the time to screen. As usual, it is NOT recommended to alt-tab out of the
game to read ATX_LOGFILE.txt as this may lead to synchronization problems.

Like all cheats, DUMP can easily be associated with a hotkey using ATXconfig.ini. Please note
that DUMP, although enabled by default, does add a tiny constant overhead to the game. You can disable
the feature altogether by setting “EnableATXScreenTextDumper” to 0 in ATXconfig.ini,
under the [General] section (set to 1 to enable – default).

After you’ve exited the game, remember to get your saved data from ATX_LOGFILE.txt before the
next time you launch the game; otherwise, it will be erased! (The log file is cleared at every
game launch)

Note: This cheat can only capture text display produced by ATX, such as the outputs of TIME, CANIMAL, OBJ, etc. For example, it will NOT capture
the “LOC” Trespasser cheat.

B & N

These single-character console commands cycle through the list of active animals in the
currently loaded level, as used by the CANIMAL cheat.
These cheats can also be assigned character keys via
ATXconfig.ini for efficiency.

KILL

This kills the currently selected CAnimal instance by setting its
health to 0. The dino’s health value may continue to decrease
until it reaches its “ReallyDie” value afterwards.

SUICIDE

Kills Anne by setting HitPoints to 0.000000.

MDINO

Displays all animals within coordinates on the 2D map (if present), including
non-visible instances (i.e., dinos in the ‘basement’), as
red cursors. As a result, depending on the level, some
dots may not actually represent dinosaurs, though this
does not happen often in the original game levels.

MSEL

Displays the currently selected CAnimal instance as a blue cursor on
the map (change instance using “B” and “N” cheats). If it does not
show up on the map, then the dinosaur is not within map coordinates.

GSPD

Displays the current game speed value. The message will only disappear
once you re-enter the cheat or exit the game.

HEALDINO

This works in the same fashion as the “KILL” cheat. It will
set the selected dino’s HitPoints value (health) to the value of
its MaxHitPoints entry, thereby healing the dino up to full health.
If dino was already dead, it may be revived but may not behave properly (if the dino’s
body was turned on its side or up-side down, its legs will not orient as they should; this
is a Trespasser bug that is also noticeable in the Test Scene level via the “Summon();” button).

HUD

This toggles the HUD display on and off. The HUD feature must be enabled in ATXconfig.ini
for this command to have any effect.

CLOAK

Makes player invisible to dinos by setting the player’s AIType values
to 0 (in-game). If a dino was already biting Anne at the time the cheat was
entered (if the player doesn’t move), it may keep on attacking Anne for a while.
It should be noted that the incorporation of this cheat has the side-effect of
not being able to change the player’s AIType value via T-Scripts.

CPBCNT

This displays in real-time the total number of current single particles being
treated by the engine; more precisely, this means the total count of CParticleBase
instances created and not yet extinguished.

TELEDINO

This will teleport the currently selected dino from the “CANIMAL” list
to the specified location (defined by three floating-point values; same as the
“TELE” cheat). Failing to enter proper/insufficient values may teleport dino out of bounds
and possibly crash game. Note that dead dinos may be teleported, but may not
be affected by gravity once transported

Edit: This cheat is generally unreliable and should not have been documented (but
since it’s here…).

FLY

This cheat activates the “CLOAK” and “INVUL” cheats and allows the player to
access fly-mode. This cheat may be unstable, but usually works.
You can set the movement speed in ATXconfig.ini. Controls will be
the same as the normal player movement keys. The run key (default = “w”) will
double the normal fly speed/distance and will increase speed even more when
combined with the walk key (default = “s”); this gives a total of three speed
settings. Speed/input settings for this feature are available in ATXconfig.ini.
Generally, lower values will smooth input but _may_ diminish overall performance if your processor is slow.

This cheat MAY crash the game under certain circumstances. Also, the player can still
die even in FLY mode, again, depending on circumstances. Refrain
from using this cheat when standing on slanted rooftops, as the “invisible”
part of the player will remain and may interact physically with the environment
at the location at which the “FLY” cheat was first entered. However, the player
at the “camera” position (flying) will not contribute to any health damage except
when collision problems occur. The (flying) player will set off triggers and voiceovers, though.

When the cheat is disabled, the player will return to the position from the time
at which the cheat was enabled (the “invisible” player’s position).

Known bugs/recommendations for this cheat:

- DROP ALL GUNS/OBJECTS before enabling (may otherwise cause oddities).

- You should not try to save or load games while fly mode is enabled (always turn off first)

- The “CLOAK” cheat may interfere with this cheat.

- Passing through or rubbing against objects/terrain may cause Anne to die (even with INVUL)

- If Anne dies while in fly mode, the player may still be able to move Anne’s body (only the visible part).

Lastly, please note that this cheat was entirely homemade and may not work
under certain undocumented circumstances. The keyboard input handler and 3D movement code
were completely rewritten for this cheat alone.

Misc. note: The reason why it is impossible to make the player’s position entirely
movable (i.e., no invisible portions left behind) is that the high-level function that
the game provides via the “TELE” cheat does not prevent gravity from being applied after
teleportation, and this can currently cannot be prevented (resulting in “bouncing” tendancies). The workaround
is to move only the player object whose function can be intercepted to discard gravity (as there are at least
two objects, possibly more). This is a real gamble to implement but, luckily, works (this object in particular,
which seems to define mainly Anne’s body and chest, has a function that is called automatically by the game
before every frame; all that is thankfully required is to overwrite all location values passed to that function,
these values being based on previous user input).

* New in ATX 1.58 is the option of specifying a movement speed multiplier at
the cheat entry prompt. You may specify a float value after the “FLY” cheat
when entered that will act as a multiplier for the player movement distance,
that is, for the value of “PlayerMovementSpeed” under ATXconfig.ini ([FlyCheat] section).
The command follows the following format:

FLY [multiplier]

(without brackets) For example,

- FLY 2

- FLY 10.3333

- FLY 0.50000

- FLY 1.0

You can specify a multiplier when first enabling the cheat or while you are
already in FLY mode. If you are already in FLY mode, the FLY command will not
disable the mode, only set a different speed; otherwise, typing “FLY” without
parameters will disable the feature. The multiplier is always applied only
to the original speed value found in ATXconfig.ini, and not to the current speed
value. Thus, to reset speed, simply enter “FLY 1”.

FLYTELE

-> BACK TO CONSOLE COMMANDS
-> BACK TO CONTENTS

When in FLY mode, this cheat will disable FLY mode and teleport the
player to the position where FLY mode left off. HOWEVER, it will have
no effect on the invulnerability state set by the FLY cheat. By default,
FLY enables invulnerability, so if you teleport with FLYTELE, invulnerability
will stay enabled. This is mainly to prevent accidents when teleporting
the player to unsafe heights. You will need to use the INVUL cheat if you
wish to disable invulnerability thereafter. Note: FLYTELE will have no effect
if FLY mode is not enabled.

REC (video recording)

The REC cheat starts and ends video recording. Here is the documentation
regarding the usage of this cheat as well as the RECCOMPRESS.EXE video-compression
utility provided with ATX (that compresses videos recorded using this
cheat, from the ATX format to a standard AVI video format). You should
keep in mind that this cheat and the compressor are mainly programming
experiments, rather than full-blown features.

REC Cheat – Video Recorder

* Important note (05/08/2006): DO NOT attempt to set recording
resolutions with odd numbers. ATX unfortunately does not take
into account a few particularities about the bitmap format,
but these will have no effect as long as you use Width and
Height values that are a multiple of 2.

Updates (includes REC cheat and compression utility updates)

V1.52 (RECCOMPRESS update):
- Updated compiler version.

V1.4 (RECCOMPRESS and REC cheat updates update):
– fixed startup crash
– fixed SaveMethod 16 not working in software mode
– changed default INI savemethod to 16

V1.3 (REC cheat update only):
– added REC cheat option (UseWriteThroughToDisk)
– new “System Memory” key performance tweak info (see “SaveMethod Settings”)

V1.3:
– slight fix

v1.1:
– New frame saving methods (see options section)
– Shortened frame buffer for RECCOMPRESS.EXE (problems with some
older systems)
– In-game recording statistics simplified (for performance)
– It was previously noted that there would be no difference in
quality between 16 and 24-bit videos due to Trespasser using
a 16-bit color depth in-game. However, there is a very slight loss
in 16-bit due to the game usually using a 5-6-5 bit pixel format and
the 16-bit RGB bitmap using a 5-5-5 pixel format. In a 16-bit
video, the least significant bit of the Green color field is
scrapped, while in a 24-bit video, it should be preserved
(at least in the algorithms used by the included utility).
This slight bit loss applies to all REC 16-bit encodings but
is hardly noticeable (given the already significant quality
loss during most encodings).

REC Cheat

* IMPORTANT NOTES:

- If you experience problems recording with the new default values,
  try setting SaveMethod to 33 (24-bit) or 32 (16-bit) to tell ATX
  to use the old frame-save methods.

- ALWAYS ENTER RECORDING RESOLUTIONS THAT ARE A MULTIPLE OF 2 (EVEN NUMBER).
  Not all savemethods have been written to take into account some
  of the alignments required in the bitmap image format, but this is
  of no important as long as you use even numbers to X and Y resolution values
  when recording.

This cheat starts and ends a REC file video dump of in-game screens.
It initially accepts one parameter specifying a REC video filename to which a *.rec
extension will automatically be added (i.e., “REC tresvideo” + ENTER).
The recording must be stopped by re-entering the “REC” cheat at the console,
but without parameters. The resulting file will be placed in your root Trespasser
or Trespasser demo folder.

During recording will be displayed the total video time, current and maximum frames
saved, and number of repeated frames (“rep”). This display will not be included
in the output video. The “rep” count is incremented every time the in-game framerate
drops below the fixed video framerate. It determines the amount of frames that
are doubled, tripled, etc. in order to compensate for low framerates. HOWEVER,
the compensation is not guaranteed to be accurate and may introduce some latency
in the final product; you should ensure as much as possible that the game’s framerate
remains higher than the video’s fixed framerate (i.e., decrement video detail or draw
distance). [Update: Low framerate compensation can now be disabled]

Recording will end ONLY when you bring up the console and enter the REC
cheat once more. If the maximum number of saved frames is reached before,
frames will no longer be saved, but the video will not be fully complete until
the cheat is re-entered. DO NOT exit the game or change resolutions before
recording has ended.

Options

Some options are available in ATXconfig.ini under the [VideoRecording] section.
Unless you have a fast system and much memory, I recommend keeping the default values and
setting your screen resolution to 320*240 for the duration of the recording process.

[VideoRecording]
Width=320		; Width of video (in pixels, from top-left corner) ***
Height=240		; Height of video (in pixels, from top-left corner) ***
Framerate=20		; Fixed/maximum capture framerate (integer value, frames per second)
MaxFrameCount=2500	; Maximum number of frames to save. It limits video
			; size and length to avoid errors. If this number
			; is too high or if you do not have enough available space,
			; the recording will contain errors.

SaveMethod=16 ; This option tells ATX which method to use to store
; the bitmap data. This includes all old and new methods.
; The new save methods use assembly optimizations to
; boost recording framerate by a decent amount (20+ fps on my
; Athlon 900Mhz in an empty level). All new save methods require
; an MMX-compatible processor. See further below for settings.

InvertAtComp=0 ; This value is used only by the compression utility (ATXconfig.ini
; must be placed in the same folder as the executable for the utility
; for this value to be recognized). This will invert the final video
; image if set to 1 for any and all 16-bit videos (top-down only),
; preceding compression. It is relative to the image inversion
; performed by the save method used to record the video, which may vary.
; It will have effect neither on videos created prior to version 1.1 nor on
; 24-bit videos. Some methods automatically flip videos accordingly before the
; utility is run. In general, you will probably only use this value if your videos
; all turn out upside-down for a given save method.
; Note: The “To be inverted” text in RECCOMPRESS.exe directly determines if the explicit
; software algorithm used to flip the image up-down will be used during encoding. This
; algorithm will slow down encoding but is required by some of the encoding methods, as
; they do not flip images automatically when copying from video memory. The
; algorithm requires an MMX-compatible processor in any case (Pentium MMX/AMD K6-2 3DNow! or higher).

NoLowFPSCompensation=0 ; Final video will omit frame repetitions caused by low framerates. Video will appear
; smoother, but may seem “sped up”, depending on original framerate. If your in-game
; framerate is always higher than the fixed video framerate, this setting will have no effect.

MCIAudioCapture=0 ; Enables EXPERIMENTAL/PARTIAL audio capture using the standard MCI device
; interface. In order for this to work, you MUST specify a recording device
; in the standard Windows “Volume Control” window (double-click on the speaker icon in
; your taskbar). Typically, you will have to “Adjust Volume” for “Recording”
; and select or enable a recording source such as “Stereo Mix” or “Wave” (and adjust/un-mute
; the actual volume as well). Different sound cards will provide device sources (you may use
; other and/or multiple sources, depending on your system). You may have to
; experiment with different sources to find the desired recording input. THE ABILITY TO RECORD
; IN-GAME SOUND DEPENDS SOLELY ON YOUR SOUND CARD FEATURES AND INSTALLED DRIVERS.
; This feature will have an impact on framerate and disk activity.
;
; The default audio output format is a *.WAV file (by default, 22050Hz, 2 channels, 16 bits,
; and 88200-byte buffer size stamp**). The filename (excluding extension)
; will be the same as the REC video file created (i.e., if you entered “REC aaaa”, the result will be
; “aaaa.rec” + “aaaa.wav”). The WAV file will NOT be combined or compressed in any way with the video file
; at recording time or in the compression utility. You will have to use a third-party program to add
; the sound file to the AVI video-only file created by the utility.
; !!! AUDIO MAY NOT NECESSARILY BE SYNCHRONIZED WITH VIDEO. Again, this feature is experimental
; and very simple in nature; it does not attempt any type of coordination between the two, which
; are recorded completely separately. You may want to edit sound/video samples via a third-party video
; editing utility and ensure that your framerate is maxed out before recording to minimize
; the gravity of the sync issue. It is important to note that it is virtually impossible to
; keep video rate intact when recording from the original source and thus impossible to keep
; synchronized at 100% with the audio track. Standard AVI video files use a fixed framerate upon which
; it is very difficult to exactly imprint a video sequence with a source varying constantly in framerate.
; Frame rate compensation is also inaccurate and contributes to the miscoordination. Furthermore,
; the ATX functions were written by someone with very limited video and audio knowledge and may
; not be entirely adequate (and yes, that someone would be me; you get what you pay for, right?).
; !!! I GIVE NO GUARANTEE THAT THE FINAL PRODUCT WILL BE FREE OF AUDIO ARTIFACTS (sound card dependent).
; -> The feature may add CPU usage during and particularly at the end of a recording (when “REC”
; is re-entered, you should expect a delay before return to prompt, with length depending on quality/video time)
; -> If the feature is enabled and SaveMethod is set to 64, only audio will be captured. No visual
; cues will be displayed until the REC cheat is re-entered at the prompt.
; -> Pressing ESC to open the in-game menu does NOT pause audio recording as it instinctively
; does for videos.

MCIxxxxxxx=(various) ; These entries describe the output sound format for the feature described above. If
; MCISamplesPerSec=44100 (Hz, others=defaults), using a value of 172000 for MCIBytesPerSec may eliminate some
; of the sound artifacts, but may cause compatibility issues with some programs.
; In general, the value of MCIBytesPerSec should be calculated based on the other
; values as follows:
; MCIBytesPerSec = (MCIBitsPerSample/8)*MCIChannelCount*MCISamplesPerSec
; This value should represent the average number of bytes per second of audio. It
; is provided explicitly and not automatically calculated for experimental purposes.
; The standard block alignment is calculated automatically by ATX (as (MCIBitsPerSample/8)*MCIChannelCount).
UseWriteThroughToDisk=0 ; (set to 1 to enable) This option instructs Windows to “write through any intermediate cache and go directly to disk” (as quoted
; from the Microsoft CreateFile API call documentation). It will generally decrease framerate and
; increase disk activity, but can reduce the usual sporadic framerate variations associated
; with write operations flushed in batches. Faster hard drives (SCSI) may benefit from this
; features, while others may not support it at all. Note that some Microsoft Windows operating
; system (Windows NT, older version of Windows 2000) have a bug associated with this feature (in
; the operating systems themselves).

The following INI entries are now obsolete:

- EnableVideoRecording

- BitsPerPixel

SaveMethod Settings (use as value for “SaveMethod” INI entry)

- Old save methods
  - - 32 – 16 bpp, standard Windows blitting functions
  - - 33 – 24 bpp, standard Windows blitting functions
  - - 64 – No video save (if MCIAudioCapture is set to 1, will record audio only)

- New save methods, all save in 16 bpp format (all require MMX support for compression utility)
  - - 0 – standard 32-bit code (slightly faster than old save methods)
  - - 1 – MMX-optimized (recommended if method 16 is unavailable)
  - - 2 – FPU-optimized
  - - 16 – DirectX-optimized (recommended for D3D mode; may be hardware-accelerated; may slow down encoding in utility)

- UNTESTED new save methods, 16 bpp (require MMX for compression utility)
  - - 3 – SSE-optimized (requires Pentium 3 or higher)
  - - 4 – SSE2-optimized (requires Pentium 4 or higher)

Notes:

- All 16 bpp modes save or eventually encode video bitmap data to 15 bpp

- All methods are software-based unless otherwise noted.

- On a technical note, for the new save methods, the Width value
  must be a multiple of 4 (for the MMX/FPU instructions), 2 (for the standard
  32-bit code), or 8 (for all SSE-based instructions).

- ATX does NOT attempt to detect if your processor supports a certain instruction
  set. It will basically crash if it tries to execute an unsupported instruction.
  Use at your own risk.

“SYSTEM MEMORY” PERFORMANCE TWEAK

Trespasser supports an registry/ini option to determine whether video
buffers (for double/triple buffering or such) are to be stored in video
memory or in system memory.

For the full version of the game, you must specify a DWORD registry entry in the key
HKEY_LOCAL_MACHINE\Software\DreamWorks Interactive\Trespasser
with the name “System Memory”. For the demo version, you must specify
an ini entry in “tpass.ini” under the [Settings] section and have
an entry named “System Memory”.

To force Trespasser to generate video buffers in System Memory, set
the “System Memory” entry to 1. By default, this is disabled. In
all general circumstances, using system memory for this purpose
is slower. However, for the REC cheat, if you are using a SaveMethod
other than the DirectX-optimized 16, setting “System Memory” to 1 may
increase REC cheat recording performance, because the software algorithms
will perform faster if they read from system memory instead of video
memory (as reading from video memory with software algorithms is always
very slow).

Miscellaneous Notes

*** You MUST ensure that the specified resolution values are both valid for
your current video adapter/drivers and are equal or lower to the ones of the in-game
resolution. Failure to do so will lead to unpredictable results.

Maximum recording time can be calculated by dividing the
MaxFrameCount value by the Framerate value. As such, the default
maximum length is 2500/20 = 125 seconds.

I do not recommend recording videos larger than 4 gigabytes in total
file size. I do not guarantee that the REC cheat will function properly
with such files.

WARNING

This cheat will SEVERELY affect framerate on many systems. I strongly recommend
using it only on computers running 1Ghz or faster processors with fast hard drives.
I also highly recommend setting the in-game screen resolution to 320*240 before
using. Due to poor performance, video capture does NOT resize the final images
to fit the desired video resolution. If the video resolution is set to 320*240 (default)
and the in-game screen resolution is set to a higher value, only a portion of
the screen will be recorded [Update: “Portion” may refer to different parts
of the image depending on save method used].

The cheat itself does not require massive amounts of RAM, but due to
its constant disk access, it is recommended to have at least 256 MB RAM
(6400000 MB RAM for Windows XP) to ensure that Trespasser does
not slow down the recording process needlessly with further disk writes.

Please ensure that you have AT LEAST a few hundred megabytes of free space on
your hard drive before using. Videos recorded in real-time are NOT compressed
in real-time due to an even higher performance hit. This will require MUCH hard
drive space. Video dumps can be compressed later using the “RECCOMPRESS.EXE” utility.

I do not guarantee that this cheat will work on all systems. I have only tested
it on an Athlon 900Mhz w/256 MB RAM and Windows ME, and on a Celeron 1.7Ghz w/128 MB RAM
and Windows XP Home Edition (the latter ran very poorly).

RECCOMPRESS.EXE Utility

Once you have successfully recorded a REC video dump, you can open
the file named RECCOMPRESS.EXE to compress the file to a standard
AVI file. You need only to select a *.REC dump file to compress
using the “Select File” button and browser. Once you have selected
a valid file, you will be presented with a “Compression Options”
dialog box, which will permit you to select a CODEC to encode the
final AVI file. The list shows all of the CODECs available on your system;
however, NOT ALL CODECS WILL WORK PROPERLY. Some may target specific
image formats and may not accept the REC image dumps.

The following is a list of CODECs that have been successfully tested
with the last version of the utility in 16 bpp mode:

- Cinepak Codec by Radius (very slow)

- Microsoft Windows Media Video

- Intel video 5.04

- XviD MPEG-4 codec (will compress to AVI) *

- [Note: DivX codec version 5.2.1 would only compress 24-bit RGB videos]

* I recommend downloading and installing the XviD MPEG-4 codec, especially if you do
not plan on editing/recompressing your videos after converting them to AVI. It works
very well, and supports 16-bit recordings. It is free, compresses quickly and thoroughly,
and sports many options.

Others may work as well. You can also select a “FULL FRAMES” option
that will not compress the video. This will result in a very large video that may only
work with certain desktop BPP color values, but that will not show any quality loss.
This is the equivalent of directly converting a *.REC file to an *.AVI file without
encryption.

Some codecs will not work with the native 16-bit RGB bitmap format (15-bit to be precise)
used by the REC data files.

Once you have selected a codec and data rate, press OK to begin compression.
You will be supplied with encryption progress and general file info. If you receive
the message “Unable to set compressed stream format” or a similar stream-related
message, the CODEC you have chosen most likely does not support the input video
format (BPP value and/or other).

Note: Some CODECs (such as XviD) will display intermediate windows while encoding.
You will have to refer to their separate documentation for more information
regarding these (for XviD, you can disable the “Display encoding status” window
option in the advanced options).

When encoding terminates, a file with the same name but different extension
as the source file (*.rec -> *.avi) will be created, usually in the same folder.
Cancelling encoding before completion will not delete the target file. The latter may
still be partially encoded and valid after cancellation.

Notes

- RECCOMPRESS.EXE requires an OS which incorporates the VFW (Video for Windows) system.

- Ensure MUCH hard drive space and sufficient swap file space.

- Do not reboot your computer while the video is being encoded (may be long).

- Do not exit the game without terminating the recording manually.

- All standard cheat displays (excluding video information, FPS cheat, and LOC cheat)

- If an error occurs during capture, displayed values may be inexact.

- Do not quit to the menu while capturing video or audio.

- Do not change screen resolution, video driver, or any other option while recording.

- For optimum disk performance, defrag your hard drive prior to recording a sequence.

Background Information

Video recording is slow because ATX must copy every frame directly
from video memory and then save it directly to the hard drive. It is a
known fact that reading any data from video memory (even with faster cards)
is a slow process that should be avoided whenever possible. However, because
the source code to Trespasser is not available, it is almost impossible to
intercept frames before they are drawn to VRAM; they must thus be captured using software
algorithms (MMX, Windows API, etc.) from the back buffer. Some of the new saving methods,
however, can make use of hardware blitting using DirectX (such as method 16), under some circumstances.

Writing every frame to the hard drive is also slow, but generally inevitable.
Attempting to compress frames to save memory and HD cycles is possible, but robs
many CPU cycles. The method used by ATX for these writes is decent, though not
necessarily optimal. There is no buffering; each frame is written directly. Writing
frames in batches may causes even more uneven framerates and would require unwanted
overhead. There is also NO asynchronous disk operation done by ATX. This could improve
performance under some versions of Windows, but would not function in Windows 9x/ME
(thanks to Win32Asm community board members for this info).

High resolutions are very difficult to attain because they affect both
video memory reads and disk writes exponentially. For example, doubling
the recording resolution (from 320×240 to 640×480, for say) will quadruple
the required memory to store a single frame, and thus (theoretically) quadruple
the bandwidth required to copy it from vidmem and then to disk. Using a
hardware-accelerated save method can render the first part feasible, but
the disk access needed for frame storage will still be demanding.

RECCOMPRESS.exe Known Bugs

30/08/2005:

- Using XviD for 24-bit recordings (SaveMethod=33) seems to crash after the first
  batch of frames read from the dump file. According to my debuggers,
  this error may lie within the XviD DLL itself (from package
  XviD-1.1.0-Beta2-04042005.zip). It would be assumed to be amongst
  a flurry of MMX code that appears to read 24-bit bitmap data
  aligned to 3 bytes. The problem would be that a 32-bit movd instruction
  would be used to fetch every 24-bit color pixel. This would work
  with all pixels in such an image, but would access one extra byte
  after the end of the image when reading its last pixel (though disregarded).
  If the buffer used to store the image would not be at least one byte
  longer than the size required by the image itself, this would result
  in a memory access violation error. I have not attempted to work
  around this issue, as the other codecs do not seem to have this problem.

Thanks

Many thanks go to the Win32Asm community board members for their help
(http://win32asm.cjb.net/), as well as to Ray Mercer and his own thanked
for the much-needed Shrinkwrap AVIFile (Video For Windows) Tutorial
(http://www.shrinkwrapvb.com/). Also, thanks to Agner Fog for his extensive
pentium optimization documentation.

FPS

Shows an approximate in-game framerate. This implementation is
not the same as the original FPS patch. I do not guarantee accuracy
(nor do I guarantee anything else, for that matter).

PLG

This command sends the text message/parameter(s) following the “PLG ” command to all plugins
currently registered with ATX. Plugins can use these arguments to
implement their own cheats/console command features.

To use the cheat, simply type “PLG” at the console, followed by a single space
character, and then whatever extra commands you wish to send to the installed
plugin(s), i.e., “PLG SuperPluginCheat”, or “PLG SuperPluginCheat 10.0”, where 10.0
is some parameter for the command “SuperPluginCheat” implemented by some plugin.
It is up to the plugin makers to decide what kind of commands their
plugins will respond to and what they will do.

Plugins have no choice but to depend on this system to receive console commands/cheat
toggles by the user, because it prevents conflicts with the standard game and ATX cheats.
It is also more versatile this way. Note that it is very possible that two or more plugins respond
to the same commands; therefore, it is recommended that plugin designers keep their commands
as unique as possible and describe them accurately.

PLAYERHEALTH

Displays Anne’s current HitPoints and MaxHitPoints values.

SUPERHP

Sets Anne’s HitPoints and MaxHitPoints values to approximately 2 billion.

NORMALHP

Resets Anne’s HitPoints and MaxHitPoints values to their original quantities.

SHOWDD

Temporarily shows the current Draw Distance variable’s current exact value.
This can also be triggered by HotKeys that can be set in ATXconfig.ini

LOAD

This command followed by a valid *.scn filename (including extension)
will load the specified level. Once the level is loaded, you will
need to press the ESC key to get rid of console input.

BUFSIZE

This shows the size (in bytes) of some of ATX’s internal buffers. These
values are only valid if there were no errors during initialization. The
map buffer is only valid if the current level has a 2D map, or it will
otherwise hold the value for the last successfully or non-successfully-loaded
map (from a previous level). The CAnimal buffers are only valid for levels
with one or more CAnimal instances (or may otherwise hold data from previously-loaded
levels).

OBJ

This cheat, when accompanied by one parameter, a memory location in hex format (may be preceeded by “0x” or not)
designating the base address of an instance, will give general information about the
specified instance. Unless you are debugging or hacking Trespasser, this is generally
not useful. You should use the “OBJN” cheats instead. Example: “OBJ 2526233” will access the instance with
a base address of 0x02526233. This cheat will also attempt to retrieve the object’s class/VTable type
from the “?.AVCxxxxxxxxxx@@” list of strings in the Trespasser executables. To turn off the info
display, simply type “OBJ” at the console without any parameters.
It is VERY important to note that this cheat is not 100% fool-proof and may lead
to crashes if you enter random addresses.

OBJN

This works in conjunction with the OBJ cheat, but is generally more useful.
It will display the same information, but instead of accepting an address
as parameter, it will take an instance’s name as found in the level’s T-Script.
For example, typing “OBJN RaptorB” will display info about that specific
instance (for a level which has a RaptorB-named instance). This cheat is mingled
with the OBJ cheat, and they may turn each other off if used alternatively.
It is also prone to the same problems as the OBJ cheat, so you should not enter
random strings as parameters. Note that the strings are case-sensitive and
may be sensitive to extra space characters (before and/or after). This applies
to both the OBJN and the OBJ cheats.

OBJF

This cheat will give camera focus to the object last set by the OBJ or OBJN cheats.
You will not be able to disable camera focus unless you re-enter the “OBJF” cheat at the prompt.
This uses the same camera and controls as the FOLLOWDINO cheat and shares
the same ATXconfig.ini values. This cheat will have no effect if you have
not selected a valid instance with the OBJ or OBJN cheats since the beginning
of a level load. If you wish to view a specific instance without having the
instance’s info displayed on-screen, simply use OBJN to set an instance, turn
off the OBJN at the prompt (by typing “OBJN”+enter), and then enable OBJF.

FOLLOWDINO

This cheat works in conjunction with the “N” and “B” cheats (which can
also be assigned keys in ATXconfig.ini for faster access). It will kill
all keyboard and mouse input to the player object and allow the camera
to follow the dinosaur instance (CAnimal) that is currently selected with
the aforementioned cheats. Some options are provided in the *.ini (under
[FollowDinoCheat] section). You can decrease the distance between camera
and dino with the “move forward slow” key, and move the camera further
back with the “move backward” key. The “move forward fast” key will reset
the distance between the two to its default value. This cheat does NOT
protect the player while enabled, so use carefully. You will not be able
to enable this cheat if any other camera-controlling cheats are enabled
(i.e., FLY, OBJF, etc.).

THIRDP

Do I really have to explain this…? It’ll enable a chase-cam mode.
The camera behaviour can be modified via ATXconfig.ini, under
[ThirdPersonCheat]. In-game up-down camera movement keys can also
be defined, though they are generally restricted to character keys (‘a’ through ‘z’).
The default keys are as follows:

- i – zoom in

- k – zoom out

- o – camera up

- l – camera down

- u – reset zoom and camera orientation

- v – gun-follow mode (hold to use)

- b – gun-follow mode (toggle to use)

- n – toggle AIMdot (see AIM cheat description)

If you regularly use these keys for other game functions, you will want to
change these in ATXconfig.ini. They are non-destructive (will not replace
whatever other functions they may be assigned to externally).

NOTE: There is a bug with improperly-assembled *.scn files that will completely
mess up the game if the level is restarted while the player is both dead
and third-person mode has been enabled. You should always turn it off
when exiting to the menu or starting a new level with these types of files.

DEVELOPER- AND LEVEL-SPECIFIC FEATURES

The following is a list of ATX features that are relevant almost exclusively to level builders or
hardcore tweakers. Please be aware that many of the features listed in the contents as being “for players”
also contain developer- and level-specific components that you should be aware of as well; please look
over them carefully.

- ALTERNATE LEVEL TPAS

- BACKGROUND IMAGE EXTENSIONS FOR LEVEL LOADS

- DINOSAUR VOCAL T-SCRIPT ADDITIONS

- FOG SETTINGS

- PARTICLE OPTIONS

- SPITTER/ANIMAL PROJECTILE SETUP

- TPA (MENU) FILE RELOCATION

- TRESSTRDBG

GAME DIFFICULTY SETTINGS

The new menu components included in ATX provide a game difficulty
slider, which can increase game difficulty by diminishing or increasing
the player’s and each of the dinosaurs’ health points. This option can also
be set in ATXconfig.ini, under the [General] section, as the
GameDifficulty key.

There are five difficulty levels, from 0 to 4 (very easy to very hard),
which are the values that you would use for the GameDifficulty key. The following
describes the health multipliers for each difficulty setting:

Difficulty Setting	Multiplier For Dino Health	Multiplier for Player Health
0	0.250000	2.000000
1	0.750000	1.300000
2	1.000000	1.000000
3	1.500000	0.700000
4	2.000000	0.400000

It should be noted that this feature is always enabled in ATX. If you wish
to use the original or closest-to-original game settings, use difficulty
setting 2 (Normal, which is the default).

This feature has been found to be non-destructive. It does not replace
the values Trespasser uses to reset Hitpoints, only the current ones.
It will NOT apply the difficulty settings if you load from a savegame
(or any other file that does not end with the extension *.scn or *.SCN),
but they will apply whenever you load a level via the Quick Load menu
(or quick-load cheat), via the New Game button, or whenever you restart
a level, even from a savegame. However, the new Hitpoints values will
be saved to savegames (but non-destructively).

In short, the only
particular behaviour is that if you load a savegame that was saved
with a certain difficulty setting and you choose to “Restart Level”
from within that same game, the difficulty setting that it will use
upon level restart will not be the original difficulty setting for
that game, but rather the one that is currently set in the main
menu (with the slider), or in ATXconfig.ini (if you disabled the menus).

MATRIX EFFECT

MatrixTres is a Trespasser hack “designed” to add a little
spice to the game. It features a Matrix-style slowdown whenever
a dinosaur exhibits a “biting” behavior, courtesy of the game
speed variable. This behavior is only done around prey (most
importantly the player), so the game will slow down by a factor
of 0.40000 (customizable) around crucial action sequences. Only
dinosaurs that exhibit biting behavior (TRex, raptors, etc.) will
trigger this. However, in this version, it is possible to
trigger MXT via T-Script entries in level files, via ActionTypes 100
and 101. This can only be enabled via T-Scripts.

The default MatrixTres values can be changed via the ATXconfig.ini
file, under the section “MatrixTres”. The minimum interval in milliseconds,
the slowdown speed, and the max dino-player radius can all be set.
The feature is also to be enabled/disabled via the INI file.
The dino-player radius is the maximum distance that dinos can
be from the player to be able to set off slowdowns. This prevents
far-away dino battles from causing spontaneous slowdowns.

New in ATX 1.50 are game speed transition settings, to ease
the stuttery effect of game speed changes. They can be set
in ATXconfig.ini. The game speeds used in transition are calculated
from the normal and slowdown speeds, along with the interval
and time settings. The changes are linear. These settings can
be set to 0 to disable transitions (to emulate the old system).
They are more clearly explained under ActionType 100 – MatrixTres effect.

MatrixTres works generally well, but you might run into some
instances where a dinosaur will be close enough to damage you
and no Matrix-effect will be shown. This is due to the fact that
only the ActBite AI command is used to set off this behavior, and
from time to time, a dinosaur will attack you without displaying it
(this is more frequent when loading saved games). There is nothing
I can currently do to address this; it is more of a Trespasser bug
than anything else (it also tends to apprea.

The following is an issue found only in ATXTres versions prior to
1.31:
“The other problem you might run into is the game
slowing down suddenly, without any dinosaurs chasing you. This is
because the dinosaurs exhibit the Bite command while attacking each
other as well, and thus set off the Matrix scene from a distance
(the slowdown will stop once one of the dinosaurs is killed). Despite
these inconveniences, so far, the ActBite command still remains the
best code location for the main MatrixTres calling code that has been
found.”

Note: This feature was originally created as a separate (non-ATX)
executable hack. However, the last release (and all previous releases)
of that hack contained a fatal flaw that has been fixed in the ATX version.

GENERAL SOUND PROBLEM FIX (A3D.DLL)

A common source of many sound and even video issues in Trespasser
has been found to be the A3D.dll file often found in the Windows “System”
folder. Although Trespasser assumes this file to be used for 3D sound
management, many sound drivers provide a file of the same name for
other or even similar purposes (for example, that poor-quality 3D-stereo emulation
many low-end sound card drivers provide). Trespasser doesn’t seem
to check thoroughly the authenticity of this file, which will to its
improper use and thus sound and even video problems. In some cases
(i.e., with some SiS 7012 drivers), the game will not even load at all.

Fortunately, there is an easy fix for this in ATX. It is done
by opening ATXconfig.ini with any standard word editor and locating
the section named [Troubleshooting]. From there, the DisableA3DdllDetection
only needs to be set to 1. The next time Trespasser is run with the ATX executable,
the game will treat the file as if it did not exist in the system.

You can also find the A3D.dll file yourself and remove it from your
system folder. In some cases, there may be more than one and in more than
one folder. However, this may lead to problems with other programs and
possibly your sound drivers.

MENU KEYS FIX

* New in ATX 2.08

This feature provides a rudimentary fix for the problematic in-game menu key detection of Trespasser.
This problem was a bug in the original game that could be witnessed when pressing the ESC key to access
the menu during gameplay. The menu would typically quickly appear then quickly disappear.
This feature fixes the problem by causing the menu windows to ignore any and all key releases for the ESC and ENTER
keys that are generated before the first key press since the window’s creation.

It is important to note that this fix
applies to ALL game menu dialogs, not only the in-game menu; it could potentially introduce
odd behaviour in untested scenarios. For this reason, it is possible to disable this feature
by setting “UseMenuKeysFix” to 0 in ATXconfig.ini, under [Troubleshooting].

This bug was caused by the original behaviour of the key handler used by all Trespasser dialog menus (a function
defined by the CUIDlg class and inherited by CInGameOptionsDlg, COptionsDlg, etc.). The handler would
close the window as soon as a “key up” (WM_KEYUP) message was received for the ESC key (it also treated the ENTER
key in a similar way, which this fix also addresses, although this may not be noticeable). This meant that,
if a menu dialog was opened while the ESC key was pressed, as soon as the key was released, the menu
would exit. This caused problems during gameplay, because the key that brings up the menu on key press (WM_KEYDOWN)
is the same key that exits the menu. On older systems, for reasons I ignore, the “key up” message would often
be lost or differently ordered after the key down message, so this behavior would never manifest itself.
On newer Windows systems, however, the Windows input subsystem usually generates the “key up” message properly,
which unfortunately exposes the logic flaw in the Trespasser input handler.

SMK VIDEO PLAYBACK RESIZING

* New in ATX 2.09

This special workaround was introduced in ATX 2.09 to allow full-screen resizing of SMK videos at any screen resolution,
particularly during gameplay (or potentially from any location in the game). It is mostly used for user levels exploiting ATX’s
ActionType 105. Traditionally, in-game SMK videos would simply be outputted to the upper-left corner of the screen,
regardless of resolution. This was due to Trespasser’s hardcoded 640×480 video window assumption.

This feature is now enabled by default. It is possible that some video drivers or older systems may experience problems with it. If
you experience constant crashing at the beginning of or during video playback, you can disable the feature by opening ATXconfig.ini,
finding the [Troubleshooting] section, and setting the entry “DisableATXSMKEffects” to 1.

This workaround is somewhat inefficient (it needs to process an extra frame or data at every video frame, not to mention
the resizing performed by DirectDraw itself), but the performance hit shouldn’t be very noticeable on today’s machines.

To level designers: Please note that this feature is functionally independent from ActionType 105 and cannot be controlled
via T-Scripts due to its generic and potentially system-dependent nature. Also note that this feature does NOT remove
Trespasser’s inherent 640×480 maximum resolution for SMK video files. All video files must still be encoded at 640×480 or lower
resolution; they will simply be resized at playback by this feature to match the user’s resolution.

FIELD OF VIEW SETTINGS

* These settings were introduced in ATX 2.12, except the CameraFOVDegrees setting
which previously existed on its own. Credit goes to machf for the aspect ratio variable.

Default game field-of-view settings can be overridden in ATXconfig.ini, under the [Variables]
section. They are described below. Can be used for widescreen monitors, pretending you’re a fish, etc.

Warning: These are experimental (no guarantees this will look right) and will not work properly
for levels which override field of view settings. These *might* not work as expected if running in windowed
mode.

MatchAspectWithResolution

Setting this to 1 (i.e., “MatchAspectWithResolution=1”) sets the game’s default aspect ratio variable
to the same proportions as the current screen resolution. Really only useful if you use a resolution
proportional to your monitor’s aspect. This overrides the AspectRatio setting (below). By default,
this is 0 (meaning, use AspectRatio setting or game default).

AspectRatio

Setting this to a value in the format “x:x” (i.e., “AspectRatio=4:3”, “AspectRatio=16:9”) sets the game’s
default aspect ratio variable to the specified proportion. By default, this is 0:0, which is ignored and
the game’s default (4:3) is unchanged. This setting has no effect if MatchAspectWithResolution is set to 1.

Aspect ratio for Tres controls roughly how much vertical viewing space there is in the viewing volume (but don’t
quote me on that).

SyncFOVWithAspectRatio

Setting this to 1 (i.e., “SyncFOVWithAspectRatio=1”) sets the game’s default camera field of view
to correspond with the current aspect ratio variable as specified in the above settings. This is based on a multiple
of the game’s default camera FOV. It overrides the CameraFOVDegrees setting. By default, this is 0
(meaning, use CameraFOVDegrees or game default). If you use this value, you should also specify
one of the above aspect ratio settings.

CameraFOVDegrees

Setting this to a real number of degrees in Euler angles (i.e., “CameraFOVDegrees=75.0”) sets the game’s default horizontal camera
field of view to the specified value. By default, this is 0, which is ignored and the game’s default (75.0)
is unchanged. This setting has no effect if SyncFOVWithAspectRatio is set to 1.

Please note that some levels are known to override the camera FOV, and behavior of this setting is undefined
for these levels (even though it probably won’t cause serious crashes).

Examples

To use Tres with a widescreen monitor and resolution, the easiest way is to first set the widescreen resolution
in the video options to one that matches your monitor’s aspect, i.e., 1200×800, and use the boolean settings only:

MatchAspectWithResolution=1
AspectRatio=0:0
SyncFOVWithAspectRatio=1
CameraFOVDegrees=0.000000

SPITTER/ANIMAL PROJECTILE SETUP

In ATX 1.52 (unreleased) appeared an INI file-based system for projectile
launching from animals, essentially allowing such effects as a spitting dino.
The proper operation of a spitter requires more than the system described below,
but this is necessary to begin with.

The spit-system is level- and animal-specific. Similarly to other features,
it requires you to place in the “MAPS\SPT\” folder an *.ini file named
after your level’s *.scn filename. For example, for the demo level, this
would be “MAPS\SPT\demo.ini”, since the demo level is named demo.scn. Once you
have created this file, you may open it with a text editor.

The *.ini file can be set to contain as many sections as there are projectile-spitting animals
in your level. The sections are named after the CAnimal instance names and can
each hold the following key entries (described in comments) that will apply to the animal
instances designated by their respective sections:

[CAnimalInstanceName]
ProjectileName1=		;Name of instance to use as first projectile (case/space/tab-sensitive)
ProjectileName2=
ProjectileName3=
ProjectileName4=
ProjectileName5=
ProjectileName6=
ProjectileName7=
ProjectileName8=		;Name of last projectile (will cycle 1 to 8, one at every launch).
				;Can have any number between 1 and 8 projectiles. Different dinos (thus
				;different sections) can share the same projectiles and use different
				;launching parameters for these same projectiles.
MinDistance=			;Minimum absolute distance between target and dino for launch to happen.
				;Must be greater (at least slightly) than MinDistanceHoriz.
				;Maximum Distance should be set via T-Script value BiteTargetDistance.
				;-> float value
MinDistanceHoriz=		;Similar to MinDistance, but calculated strictly horizontally.
				;Must be greater than ForwardDistanceFromHead.
				;-> float value
ForwardDistanceFromHead=	;Offset from dino's head (strictly forward), where to first teleport projectile upon launch.
				;Must ensure does not touch head, or might trigger CCollisionTrigger and/or wound/kill dino.
				;If you've paid attention, you know these three last values are dependent
				;of each other and need to be valid, as well as greater than zero.
				;-> float value
ProjectileSpeed=		;Speed to use for ActionType 110 and 10. Should be below 100.00000; game
				;does not respond well to high values.
				;-> float value
LaunchProbability=		;Integer - between 0 and 100 (same as ActJumpNew). Calculated randomly.
MinLaunchInterval=		;Integer, milliseconds - minimum time between projectile launches (same as ActJumpNew).
ProbabilityInterval=		;Integer, milliseconds - This is the equivalent of the ActJumpNew TendancyCheckPeriod interval.
				;It is used in conjunction with LaunchProbability and should always be equal to or lesser than
				;MinLaunchInterval. It can increase launch randomness. See ATX_README.htm under the ActJumpNew
				;documentation for the description of TendancyCheckPeriod. It does the same but for dino jumps
				;instead of projectile launches. You may omit this value (if omitted, it will be set to the same
				;value as MinLaunchInterval, which acts as if this feature was disabled).
AnimalViewAngle=		;Euler angle - target must be within this angle from dino's head orientation (horizontally only)
				;on each side, or will not set off launch. Should be between 0.000000 and 90.000000 (exclusively).
				;-> float value
UseHorizontalAutoAim=		;Set to 1 to enable, 0 to disable.
UseVerticalAutoAim=		;Set to 1 to enable, 0 to disable. Currently, both vertical and horizontal aiming should
				;be enabled if auto-aim is to be used at all, or the projectile may not
				;orient properly.
ProjectileZSpeedAdjust= 	;Set to 1 to enable, 0 to disable. Will only be used if UseVerticalAutoAim is enabled.
				;It represents a height aiming adjustment for the vertical aiming system.
				;A positive value will cause dino to always shoot higher. It is calculated
				;from the dino's target location (which is usually at center of target).
ProjectileExtinguishTime=	;Integer, milliseconds - timeout interval for fixed-speed mode. It represents
				;the maximum time during which the projectile will be assigned a fixed speed.
				;After this time, the projectile's physics speed manipulation will be surrendered
				;to the game. This value should always be used in case a projectile is fired
				;into the sky.

* Some of the entries provided here resemble the entries used by the
Jumping Dinos
feature; you may want to consider those descriptions for further reading.

** ALWAYS INCLUDE EVERY ONE OF THESE VALUES UNDER EVERY SECTION (default value selection
does not mimic the ActJumpNew tendancies). This does not
apply to ProbabilityInterval (only). There are no default values for any of these
(except ProbabilityInterval), resulting in unpredictable results if omitted.

The ProjectileName# values are strings that should hold the name of valid CInstances
from the level. These are the projectiles that will be launched by the animal. You can
have up to 8 of these, but you must at least have one. If you have more than one, the
projectile launch will simply rotate between these instances (in order) after every launch (for variety).
These instances can be shared between animals, but know that if an animal launches a projectile
and another animal launches right after, the instance will be teleported right out of the air
for use by the second animal, so only share instances if there is little of chance of having
two launches at once.

MinDistance is a float value giving the minimum distance between the spitting animal
and its target for the spitter to launch a projectile. It is important to keep a certain
minimum so that the spitter doesn’t launch items “through” its targets. MinDistanceHoriz
is the same as MinDistance except that it is calculated purely horizontally (on the X-Y plane),
so that this distance will be respected regardless of the height difference between
the animal and its target.

BiteTargetDistance is NOT a value that you set in the *.ini file. It is a float
T-Script value that you set within a CAnimal dino’s script. In this context, increasing
the animal’s BiteTargetDistance emulates the distance at which a dino will starting
“biting at” and thus launching projectiles at its target. It acts as a complement
to the MinDistance value (i.e., as a “MaxDistance” value).

ForwardDistanceFromHead is the distance from the dino’s head from which the projectile
will first appear when launched. It is VERY IMPORTANT to find an appropriate minimum
value for this distance; if it is too low and/or the projectile/dino head is too large,
the projectile might be teleported “into” the dino’s head, both killing him and potentially
causing level crashes. Of course, having values much too high will cause the projectile
to appear too far from the dino’s head and possible “into” other objects, so it is
important to find an appropriate value (also for realism, of course).

ProjectileSpeed is a float value that should be below 100.000000. This speed
will be giving and kept applied to the projectile once it is launched by the animal.
Note that the game engine cannot handle very high values. This is why a fixed-speed mode
is required, otherwise the projectile decelerates too quickly and drops prematurely.

LaunchProbability is an int value between 0 and 100 that gives in percentage
the probability of the animal launching its projectile every time it has a chance.
Of course, this should practically always be above 0, unless testing.

MinLaunchInterval is the minimum time between two projectile launches by a one animal. This
is not considered through save games and different level loads. Thus, it also dictates the minimum
time from the loading of the level/last savegame from which a launch will be allowed (i.e., setting
it to 12000 milliseconds will mean the animal will never spit 12 seconds before the last level/savegame
load). ProbabilityInterval is a similar value that is used in conjunction with LaunchProbability
and MinLaunchInterval. It should be lower than or equal to MinLaunchInterval to have any effect.
Usually, when launching a projectile, the dino will give a MinLaunchInterval period of time between its attempts
at launching a projectile, whether they are launched or not. This limits the spitting intervals
to multiples of the MinLaunchInterval only (assuming a constant in-range scenario).
With ProbabilityInterval, whenever a projectile launches does not happen after a
MinLaunchInterval period of time, the animal will only wait a ProbabilityInterval amount
of time until the second next attempt instead of waiting an entire MinLaunchInterval cycle.
Basically, if you decrease LaunchProbability and ProbabilityInterval at the same time with
certain proportions, you can randomize the spitting patterns, or keep ProbabilityInterval
similar to MinLaunchInterval and a higher LaunchProbability value to have more regular launching.
* Please note that these intervals are currently NOT recorded in savegames (very high values
should be avoided).

AnimalViewAngle is the minimum angle between the current orientation of the dino’s head
and the position of its target (via its own position) for a launch to happen. It basically
keeps the animal from launching projectiles from the back of its head. This is only
considered horizontally. This value should be between 0.000000 and 90.000000, exclusively.

UseHorizontalAutoAim and UseVerticalAutoAim control the auto-aim for the projectile
launching when the dino has a specific target. Due to current arrangements,
you can either set both of these values to 1 or both of them to 0. Do not set them to different values.

ProjectileZSpeedAdjust is a simple distance value that is added to the target’s
position when the dino is performing and “calculating” a launch. Increase this value
so that it aims more towards the head, or decrease so that it aims more towards the feet.

ProjectileExtinguishTime gives the time-out value for the projectile. It does
not control the disappearance of the object, only the time after which it starts
to lose its speed. This value is a consequence of the fixed-speed setting used
for the spitter code.

Here is an example entry (taken from the original Trescom Enhanced Spitter):

[FrillSpitter]
ProjectileName1=DiloSpit
MinDistance=2.500000
MinDistanceHoriz=2.250000
ForwardDistanceFromHead=2.00000
ProjectileSpeed=45.000000
LaunchProbability=100
MinLaunchInterval=12000
AnimalViewAngle=60
UseHorizontalAutoAim=1
UseVerticalAutoAim=1
ProjectileExtinguishTime=2000
ProjectileZSpeedAdjust=0.50000
AnimalViewAngle=90.000000

Other Considerations

As demonstrated by the Trescom Enhanced Spitter, you need a lot more than the above
INI script to successfully implement a spitting dino. First of all, you
may want to explicitly disable jumping for the dino you are choosing
for spitting. You can do this by including an INI for (and named after) your level
in the folder “MAPS\JMP\”, including a section for that animal in particular,
and setting its JumpTendancy to 0. See see JUMPING DINOS (ON ACTBITE COMMAND)
for more details. Second, DO NOT FORGET to set the BiteTargetDistance
under your animal’s T-Script to control spitting distance, but make sure
it is not set too high as you may run into behavioral issues.

UPDATE (ATX 1.61): The ActJumpNew scripts now allow you to set a MaxDistance
value to limit the range at which a dino may jump. It is thus now possible to
tweak the spitter/actjumpnew distance settings to allow the animal to spit
at longer range and jump at closer range without having both systems interfere.

Third, you should modify the T-Scripts for the instances you plan
on using as projectiles, particularly values such as Mass and Damage.
These will control the damage dealt to targets and objects when
the animal spits accurately (or not).

Fourth, and MOST IMPORTANT, is that you ABSOLUTELY NEED a CCollisionTrigger
to control impact between the projectile and, well, anything. The spit system
DOES NOT manage collisions, it only launches the projectile and stops updating
its position after a certain time. In fact, the spit system uses
ActionType 110
just as described in this documentation to keep speeds, so in order for the
projectile to stop receiving speed injections when it hits anything, you
ABSOLUTELY MUST include a call to
ActionType 111
with the projectile’s name as Sample value in your CCollisionTrigger. In your script, you may
also want to include a call to ActionType 18 to teleport your projectile
out of sight after it hits anything, as well as a call to ActionType 10
to freeze it after. ALWAYS make the call to ActionType 111 the first
in the list of calls in your CCollisionTrigger, or it might nullify
the calls to the two other ones (18 and 10). For a example on applying
this, see the Trescom spitter.

Of course, none of this has anything to do with an animation such
as an unfurling frill on a dilo. In general, you can control such
animations by including a CLocationTrigger in your level that
holds your projectile whenever it is not being launched. That way,
whenever the projectile is teleported out of the trigger volume,
you can set a script value (ObjectLeaveTrigger) to detect the event and launch a set
of ActionTypes, including the ones required for texture animations.
Of course, you will then tweak your CCollision trigger to teleport
your projectile back into the CLocationTrigger for later launching.
You may also have to have a start trigger at the beginning of your
level to first teleport the projectile into your CLocationTrigger,
because if the projectile starts inside the CLocationTrigger,
the latter may not fire properly upon the very first projectile launch
during play.

Again, please see the Trescom Enhanced Spitter for examples and
further details. This spitter was developed by the Trescom TC-Ops.

JUMPING DINOS (ON ACTBITE COMMAND)

* This feature and its documentation have been updated in ATX v1.53 and v1.61.

This new feature can be used to allow jumping dinosaurs whenever a dino exhibits the ‘biting’ behavior, in the
same tradition as the MatrixTres mod. The feature as a whole can be enabled/disabled
in the ATXconfig.ini file (via [ActJumpNew] section, with the DisableActJumpNew key,
the feature itself being enabled by default), as well as via the ATX menu option. It causes
dinos to receive an impulse from an invisible object, which emulates a jump. The default
jump settings can be set under the [ActJumpNew] section of ATXconfig.ini (they are the entries
who’s names start with “Default”); these settings will be used for any levels/animals that do not
have level- and animal-specific settings (described later).

ATX v1.50 also includes an option to ensure that quadrupeds such as Trikes, Stegs,
and Brachis do not jump as a result of this. However, it is DISABLED by default.
This is not to impede on level designer territory, because it is a global setting,
and by default, the jumping dinos setting applies to all dinosaurs. If you are like
me and find jumping quadrupeds a little distracting in some of the user-made levels,
simply open ATXconfig.ini, find the [ActJumpNew] section, and set the
DisableJumpingQuadrupeds key to 1. Thanks to Tatu for posting the “jumping triceratops”
screenshot which led to the development of this option.

ATX v1.53 includes an option called TendancyCheckPeriod. It can be set under an ini file’s
[General] or [InstanceName] sections like all the other values. It is described further below.
It has a corresponding entry for its default value in ATXconfig.ini (DefaultTendancyCheckPeriod).
However, this usage of the ATXconfig.ini default value differs from the others to maintain
backwards compatibility with older ATX versions and *.ini files. This is also described further below.

A good deal of credit goes to the Trescom team for the TC-Isle
“jumping raptor”, which I based myself upon to derive this.

Dino jumping behavior can be level-customized using the *.ini files found in the
“MAPS\JMP\” folder. Filenames must reflect the levels’ scn filenames, in the same way
as the dino randomization list files. For example, for the town level, “IT.scn”,
the file used for jump data should be named “IT.ini”.

Please feel free to write and distribute your own *.ini files, whether
it be for the default levels or for user-made levels.

There are four different values that can be tweaked generally or for
specific dino instances under their respective sections:

[General] AND/OR [FullDinoInstanceName]
Push=
JumpAngle=
JumpTendancy=
RepeatPeriod=
TendancyCheckPeriod=	      (new in ATX 1.53)
MaxBodyTargetDirAngle=	      (new in ATX 1.61...)
MaxHeadTargetDirAngle=
MinTotalVelocity=
MinDirectionalVelocity=
MaxDirVelocityAngle=
MinTargetDistance=
MaxTargetDistance=

If these values are placed within a section named [General] in the INI, the specified values
will become the defaults for all instances of that level (* subject to additional conditions).
If no [General] section exists, the DLL’s default values will be used OR the overall defaults
specified in ATXconfig.ini. HOWEVER, if you use at least one instance-specific section in your
file, it is highly recommended that you have a [General] section as well at the beginning of
the file (or the default values for the other dinos will be fetched from ATXconfig.ini).
If the values are placed under a section whose name reflects a valid
CAnimal instance from that level (i.e., [RaptorB02-00]), they will
be assigned to that instance alone, regardless of default or general section values. Not all
four entries need to be present under a certain section, but assigned values must be valid,
or the game may crash.

*** If you plan on using these level-specific settings, it is recommended that you explicitly
include every one of the aforementioned entries (i.e., not just one or two), because the user is free to modify
his own ATXconfig.ini defaults. These default values will be used for your level if you do not
override them yourself with level-specific settings, either in your [General] section
or in instance-specific sections (if you include all of them in your [General] section, however,
then it is not necessary to have all of them in each of your instance-specific sections, because they
will now use the values from [General] by default).

Below is a description of each value’s significance and data type:

Push

Floating-point value

This is the equivalent of the T-Script value of the same name.
It determines the amount of force to be applied to the dino to cause a jump,
in the direction determined by the dino’s orientation (forward and up/down) and the
JumpAngle entry. Evidently, higher values will lead to higher jumps, but may cause
oddities and/or hilarious gameplay.

One thing to remember is that dinos of different masses and shapes will naturally
react differently (less or more) to the Push value. This is mainly why it is necessary
to have INI files for all levels and animals.

JumpAngleFloating-point Euler angle (0 to 90)This modifies the direction in which the Push force
will be applied to the dino. This angle adds to the dino’s Z or up/down facing value (preserving X-Y orientation)
and uses the result for the new direction. Higher values will cause more vertical jumping,
and lower values will tend to project horizontally forward.

JumpTendancy
INTEGER value (no decimals!) from 0 to 100
This controls the dino’s probability of jumping
when exhibiting biting behavior in the form of a percentage (do not include a % sign after the
value). This value is based on random number generation, so it will not determine
whether it is ‘smart’ for a dino to jump at a certain moment based on his surroundings.
If this value is set to 0, the dino will never jump (use to contradict General section values
for specific animals); setting to 100 will ensure that the dino jumps whenever possible (limited
by biting tendancy and RepeatPeriod). Theoretically, a value of 50 would make a dino jump about half
of the time, but this depends on random results and may not always project an accurate statement.

RepeatPeriodINTEGER value, in millisecondsThis determines the minimum interval between
a dino’s jumps, in milliseconds. Despite naming, do not confuse with the T-Script value
which has the same function but is used as a floating-point number. Beware of using very low
values, because the applied force may cause a dino to jump more than once before it hits the
ground, which would greatly dampen atmosphere. NOTE: The RepeatPeriod values found in [General]
sections and in ATXconfig.ini affect individual dinos and not overall jumping behavior (i.e., there may
be more than one jump performed within this period, but only if they are done so by different animals).

TendancyCheckPeriodINTEGER value, in milliseconds

This value should always be equal to or lesser
than RepeatPeriod. It works in conjunction with JumpTendancy in the following fashion:
The absolute minimum time between dino jumps is determined by RepeatPeriod. Once the RepeatPeriod
time expires, another attempt at a jump can be initialized by ActBite. Previously, without TendancyCheckPeriod,
when this attempt would take place, ATX would check for JumpTendancy, and if the random value did not pass the tendancy,
the dino would not jump and the RepeatPeriod time would be reset. Then, the dino would have to wait
a whole other RepeatPeriod time for its next chance to randomly check for jumping time.

TendancyCheckPeriod is the solution. Using this value, if a dino does not jump because the JumpTendancy was
not met, instead of waiting a RepeatPeriod time for the next chance to jump, it will
wait a TendancyCheckPeriod time. As such, there will always be at least RepeatPeriod milliseconds
between jumps, but you can set TendancyCheckPeriod to a lower value than RepeatPeriod so
that there are more occasions for the dino to evaluate its JumpTendancy once the RepeatPeriod time
has expired. In short, you can achieve more random jumping by using this value. Typically, you would
add this value to an existing ActJumpNew script by setting it to a value lower than RepeatPeriod and also
diminishing the affected instance’s JumpTendancy value. Note that if you only set TendancyCheckPeriod without
changing JumpTendancy, the dino will be prone to jumping more often. By keeping a certain proportion between
TendancyCheckPeriod and JumpTendancy, you can increase randomness of jumps without necessarily increasing
jump counts.

To maintain backwards compatibility with older files, the default value for TendancyCheckPeriod is fetched as follows:

- If a “JMP\*.ini” file has neither a RepeatPeriod nor a TendancyCheckPeriod in its [General] section,
  the default value for TendancyCheckPeriod for the level will be the value found in ATXconfig.ini (DefaultTendancyCheckPeriod).
  Thus, DefaultTendancyCheckPeriod will become the value for all dinos that do not have instance-specific sections
  or TendancyCheckPeriod values in their instance-specific sections.

- If a “JMP\*.ini” file has a TendancyCheckPeriod in its [General] section (not matter if RepeatPeriod is present or not),
  it will automatically be the default value for the level (as you would expect, and same as the other values).

- If a “JMP\*.ini” file has a RepeatPeriod but NOT a TendancyCheckPeriod in its [General] section,
  the default value for TendancyCheckPeriod for the level will be the value of RepeatPeriod. This is
  what maintains backwards-compatibility (for the most part).

- * New in ATX 1.61:
  If a “JMP\*.ini” file has a section for a specific dino with a RepeatPeriod value but not a TendancyCheckPeriod
  value, the TendancyCheckPeriod value will be set to the RepeatPeriod value. If both values are absent, the default
  value for TendancyCheckPeriod for this dino will be the default value for the current level and
  is determined by the above conditions.

* The following 7 values are new to ATX 1.61. They are all float values and are used in limiting dino jumps to
certain conditions. If they are set to 0 or any other value of 0 (i.e., 0.0, 0.000000), they will not be used
(individually). This is the default value (i.e., if you do not specify them and the user hasn’t specified
new defaults in ATXconfig.ini, they will not be used). You can thus choose which conditions to enable by setting
those you do not wish to use to 0 and the others to valid floating-point values. All angle values are in Euler
angles and should range between 0 and 90, exclusively.

MaxBodyTargetDirAngle	Euler angle value	This is the maximum angle of view on either side of the dino’s body from which the target (player or animal) can fall within to allow the jump. This is analogous to the animal projectile (spitter) AnimalViewAngle value, but using the dino’s current body direction instead of its head. For example, if the dino is to jump only when the target is in front of the dino within a 120 degree view from the body’s direction, you will set MaxBodyTargetDirAngle=60.
MaxHeadTargetDirAngle	Euler angle value	This is the exact same as MaxBodyTargetDirAngle, but uses the dino’s head for the view span instead of its body. It can be useful to set both values to ensure that the dino’s body and head are always facing the target when it jumps, and not have situations where the body faces the player but the head faces away and the animal jumps anyway.
MinTotalVelocity	Speed value	This is the minimum velocity the dino must have to allow a jump. In contrary to some other values, the maximum velocity is calculated in 3D, i.e., including the dino’s current vertical velocity. It must be a positive value.
MinDirectionalVelocity	Speed value	This is the minimum velocity the dino must have in the direction in which its body is facing to allow a jump. This value should be typically lower than MinTotalVelocity if both are present (or it will have no meaning) and is also calculated in 3D (not just on the horizontal x-y plane, but including the vertical z component – this simplifies a few of the calculations).
MaxDirVelocityAngle	Euler angle value	This is similar to MaxBodyTargetDirAngle in function, but uses the dino’s current speed and direction instead of the distance with the target. It limits jumping by comparing the direction in which the dino is moving compared to the current orientation of its body. If the direction in which it is moving compared to the orientation of the body makes an angle greater than the MaxDirVelocityAngle, no jump will occur. Thus, this value also represents half of a “view angle” from the dino’s body. You can set this value so that the dino doesn’t jump while it’s moving sideways or backwards. You should only use this value if you use at least one of the other minimum-speed values (i.e., at least one of them is greater than 0).
MinTargetDistance	Distance value	Minimum distance between dino and target to allow jump. You can measure distances using TresEd or, if you are unsure of where the central location is based in the dino mesh, you can use the OBJN cheat in-game; it now displays this distance.
MaxTargetDistance	Distance value	Maximum distance between dino and target to allow jump within. This value was introduced mainly to allow spitter-type animals to keep their jumping behaviour at closer range while being able to launch their projectiles at longer range (animal projectile behaviour must be tweaked to achieve this as well).

While this new set of values is fully implemented in ATX 1.61, they have all been kept to the default
of 0 in ATXconfig.ini as to preserve compatibility with level files which do not set these new values. This means
that these settings won’t be used unless you set them in ATXconfig.ini or in level-specific files.

EXAMPLE SETTINGS

Below are a few recommended settings that you can use to improve jumping behaviour in ATX 1.61+.
Simply overwrite all corresponding entries in ATXconfig.ini under the [ActJumpNew] section.

* Default settings (for ATX 1.59-1.60 behaviour)

[ActJumpNewSettings]
DisableActJumpNew=0
DisableJumpingQuadrupeds=0
DefaultPush=65.000000
DefaultJumpAngle=65.000000
DefaultJumpTendancy=75
DefaultRepeatPeriod=8000
DefaultTendancyCheckPeriod=6000
DefaultMaxBodyTargetDirAngle=0
DefaultMaxHeadTargetDirAngle=0
DefaultMinTotalVelocity=0
DefaultMinDirectionalVelocity=0
DefaultMaxDirVelocityAngle=0
DefaultMinTargetDistance=0
DefaultMaxTargetDistance=0

* Increased frequency and precision of raptor jumping.

[ActJumpNewSettings]
DisableActJumpNew=0
DisableJumpingQuadrupeds=1
DefaultPush=65.000000
DefaultJumpAngle=65.000000
DefaultJumpTendancy=100
DefaultRepeatPeriod=3000
DefaultTendancyCheckPeriod=1000
DefaultMaxBodyTargetDirAngle=45.0
DefaultMaxHeadTargetDirAngle=30.0
DefaultMinTotalVelocity=0
DefaultMinDirectionalVelocity=1.5
DefaultMaxDirVelocityAngle=30.0
DefaultMinTargetDistance=3.0
DefaultMaxTargetDistance=6.0

* Slightly longer-range jumping, more random, ‘straighter’

[ActJumpNewSettings]
DisableActJumpNew=0
DisableJumpingQuadrupeds=1
DefaultPush=70.000000
DefaultJumpAngle=65.000000
DefaultJumpTendancy=50
DefaultRepeatPeriod=2000
DefaultTendancyCheckPeriod=1000
DefaultMaxBodyTargetDirAngle=20.0
DefaultMaxHeadTargetDirAngle=20.0
DefaultMinTotalVelocity=0
DefaultMinDirectionalVelocity=0.5
DefaultMaxDirVelocityAngle=20.0
DefaultMinTargetDistance=4.0
DefaultMaxTargetDistance=8.0

Feel free to experiment with any of these settings. Just remember that angles must be between
0 and 90 exclusively and are in Euler angles, and that time values are integer-only (no decimals).
Also, if the level you’re using has its own jump settings, the values you set in ATXconfig.ini
will have no effect.

NOTES

Jumping, by default, will be performed by any dino capable of exhibiting the ActBite AI command.
This includes raptors, albertosaurs, and Rexes (some user-made levels also have Trikes and others
perform this action). You will have to explicitly disable jumping
using JumpTendancy=0 in the levels’ INI files to ground a T-Rex or such dino.

The force that causes jumping can still be applied if the dino has not yet landed from a previous
jump or if it is already in-air. To prevent this from being a problem, disable jumping for dinos
in level areas that are prone to cause falling and/or set RepeatPeriod to higher values. There may still
be some situations where dinos will jump twice before touching ground, despite prevention.

The base scripting/coding for the entire jump behavior uses equivalent ActionType 10 (Physics) settings
to the jumping raptor in TC-Isle. The “Impulse” script value is always set to “true”, and the
“Emitter” object is always located directly below the “Target” instance, its orientation depending
completely on the latter’s, and on the JumpAngle setting. No velocity script entries are used, only
the force applied by the “Push” control.

Obviously, though easily overlooked, a dino must have the T-Script bool ActBite set to “true” for it
to jump (“bool ActBite = true”). If the boolean is set to “false” or missing, it will not jump.

For diagnostic purposes, the CANIMAL cheat now includes ActJumpNew info. The five displayed
values are, respectively, the Push, JumpAngle (in radians), JumpTendancy, and RepeatPeriod values, followed
by the last recorded tick count used by the RepeatPeriod code.

Tip: Diminishing the values of both JumpTendancy and RepeatPeriod
will produce less predictable jumping patterns. Increasing both (which is
nearer to the default values) will ensure more regular interval
between jumps.

Example INI file for jump settings (example.ini)

[General]
Push=65.000000
JumpAngle=40.03
JumpTendancy=70
RepeatPeriod=12000

; (any instances not listed below and present in the level will use values
; from the General section above)

[RaptorA09-01]
Push=40.000
JumpAngle=75.77
RepeatPeriod=10000
JumpTendancy=43

[TRexX01-00]
JumpTendancy=0 ; (no jumping for this T-Rex)

[RaptorB05-300] ; (this raptor will use the RepeatPeriod from the General section)
Push=65.000
JumpAngle=33
JumpTendancy=100

LEVEL-LOAD BACKGROUND IMAGE EXTENSIONS

This simple feature allows load-time background images to be easily
added to levels. The feature itself can be toggled
in ATXconfig.ini, via the EnableNewLevelLoadBGs option
under the [General] section (enabled by default).

To assign a *.tga file to a certain level, simply place
the image file in the “[Trespasser folder]\MAPS\LBG\” folder
and rename the file to reflect the SCN level name, excluding
extension. For example, for the level “be.scn”, you would
have “[Trespasser folder]\MAPS\LBG\be.tga”.

There can also be a file named “default.tga” in the “LBG\”
folder. This file will be a substitute for the default
background used by Trespasser for levels without background
images (by default, this applies to all non-default-named
game levels).

The files placed in the “LBG\” folder have priority over
any and all default background files used by Trespasser
(defined directy in the executable).

Thanks to Slugger for requesting this feature.

WINDOWED MODE (SEMI-)

This is a hack to provide semi-windowed support in
software mode. It does not have an actual ‘window’, but draws
on a smaller part of the screen. It has only been tested on Windows ME,
2000, and XP. The hack is done by setting the main DirectDraw
SetCooperativeLevel with a parameter of DDSCL_NORMAL instead
of FULLSCREEN | EXCLUSIVE and removing the main call to
SetDisplayMode. Despite the presence of a “Full Screen” registry
key that is used by the executable, the game cannot normally be
run in a window, partly because the game doesn’t even use or manage
a standard window (the handle returned by the CreateWindowEx call
is discarded).

To enable this feature, simply set the appropriate entry in ATXconfig.ini
to 1, or 0 to disable. This feature is also required for TresStrDbg.

This will only work in software mode. Make sure you set software
mode with the normal Trespasser exe before running this one,
preferably in 640*480 resolution. Also, you MUST set your desktop
to 16-bit color and I recommend a minimum resolution of 800*600
(or else it will fill the screen). The game menu is always drawn
as a 640*480 window, while the actual game can run at a user-defined
resolution. You may run into re-drawing problems with the menu if
the game is not in 640*480 as well, however.

Also, DO NOT try to set the game resolution using this hack.
The game will end up crashing.

Note that the “greying” effect that takes place when Anne is hurt
is not displayed in windowed mode. I believe Trespasser uses DirectX
functions to accomplish this effect; these would be unusable in a
forced window mode.

WDASM

This windowed hack permits the usage of the WDASM disassembler’s
breakpoint system without hanging the game. Other debuggers may
not seize window control properly and may run into problems when
a breakpoint is reached (i.e, OllyDbg). You should be able to use
most of WDASM’s standard functions, such as (auto) single-stepping
after a breakpoint. However, the “Pause” function does not seem to
work properly and will crash Trespasser.

To return to Tres after a break, make sure you press the “Run”
command (F9) and THEN return to Trespasser using ALT-TAB or by
clicking on the game’s taskbar entry (as you would normally);
failure to do this can result in mouse problems. Do NOT attempt to
return to Trespasser simply by clicking inside the window.

You may, however, run into problems with WDASM’s window re-drawing;
Trespasser’s lack of a window forces DirectDraw to draw over the
desktop and other windows. One way to go around this is to set the
game resolution to 640*480 while setting your desktop resolution
much higher; you should be able to put WDASM or a good part of it
in the unused part of the screen. Also, beware of the mouse problem
that surfaces from time to time; when using breakpoints, even though
the debugger may take control, the mouse movement will be limited to
the game’s window. To get rid of this restraint, use ALT-TAB or drag
around one of the debugger’s windows.

OBJECT RANDOMIZER

UPDATE

As of ATX v1.50, the dino randomizer has been replaced
by the instance randomizer! The file format remains the same,
the only difference being that instances of types other than
CAnimal can be used. HOWEVER, the following entries will
ONLY have effect on CAnimal-type instances:

- DisableActGetOut

- ForceStayNearMax

- ForceStayNearOK

- ForceSleep *

- ForceWakeUp *

(* Even though most instances have these values, the INI
entries will only work with those of the CAnimal class
because the locations of these values in each class varies)

The randomizer will ignore these values if they are
assigned in any fashion to instances not of the CAnimal class.
Also, note that there are types of instances which
you should not attempt to randomize. While I do not currently
have a comprehensive list, it is known that you should not try
to move triggers (misc. problems) or CInstances not marked
as moveable (as the changes will not be recorded in savegames).
Other objects, such as guns and boxes for example, should
behave properly, or at least as well as the dinosaurs do.

Also included in ATX v1.50 are custom randomization files (by people
other than me). In order to use these custom randomization files,
simply go into the “MAPS\” folder and double-click on the
batch file (*.bat, icon looks like an MS-DOS program) that goes
with the files you would like to use. They are named “InstRandxxxxxx.bat”,
where xxxxxx is the pseudo-name of the pack to use. For example,
opening “InstRandOriginals.bat” will apply the default ATX randomization
files to the “RAN\” folder. They will simply copy the available files from
the other sub-folders (under “RAN\”) to the main “RAN\” folder, overriding the current ones.
Credit is due and goes to any and all contributors of these files. I should
note that the original ATX files, although originally lengthy to write, were and are imperfect;
you may have a better experience with the randomizer if you use
the custom files that were graciously supplied to me.

Note: You can delete the “RAN\RANxxxxx\” sub-folders, but this will cause
the batch files to have no effect (so you would then delete these as well).
The “RAN\”, folder, however, should always be present. Deleting this folder
may cause ATX to misbehave.

ORIGINAL DOCUMENTATION

This feature allows random selection of instance locations
from pre-written lists specific to certain level files. These
lists can be found/created/edited as INI files in the “MAPS\RAN\”
folder; the INI filename must reflect the level’s SCN name (for
example, the town level, “IT.SCN”, will have an INI name of
“IT.INI”). Selection is randomized upon all level restarts, new games,
and games loaded from the Quick Load menu (quick-load cheat).

To enable random selection (provided a list exists for the level
you are playing), open the “ATXconfig.ini” file and set the
“RAND” entry to 1 (assign 0 to disable).

Please feel free to write and distribute your own randomization
seed files, whether it be for the default levels or for user-made levels.

The selection process is fairly powerful; it allows the randomizing
of locations for specific instances and the limitation of certain
locations to certain instances.

Included in this package are randomization files for all default
full version game levels. You can use the “MAP” and “MDINO” cheats to
examine the changes in positions upon level restart.

Note: Random instance locator will not affect saved games in any way
(and games saved from a randomized level load should save
properly). However, if you load a game from a savegame that
was saved with the randomizer enabled, but restart the level
with the randomizer disabled, the dino positions may not be
the same positions that were present at first randomization,
but most likely the level’s default instance positions.

Note 2: The randomization routine used is the one used by the MSVCRT
C standard library and is only as random as that routine may be.

LIST FILE DETAILS

Note: A “section” refers to an INI file entry that is enclosed
in square brackets []. A “key” refers to a member of that section
which can be identified by its following “=” character (which is
then followed by a value/string).

The INI file starts with an “Instances” section, which
holds all of the instance names which will be assigned random
positions. These names should be specific to the loaded level.
Instances are defined via consecutive “Instance#” keys (Instance1,
Instance2, Instance3, etc.). Order is not important as long as
the numbering is consecutive (i.e., bad: 1,2,3,5; good: 1,4,2,3).
Also in the “Instances” section are found keys named
“NumberOfENTRYSections” (required) and “Reserve#” (optional). These
will be discussed shortly.

The core of the list lies in the other sections. There are two types
of sections: random selection sections, named “ENTRY#”, and instance-reserved
sections, named anything but “ENTRY#” (naming such a section “ENTRY#”
may cause crashes or faulty behaviour).

Random selection sections are assigned (only once each) to
random “Instance#” key instances in the “Instances” main
section, at the exception of “Instance#” instances which have
an extra “Reserve#” section of the same numbering. Like “Instance#”,
the naming/numbering of the sections MUST be consecutive (though not
in appearance in the file). For example, if there
are three such sections, they should be named ENTRY1, ENTRY2, and ENTRY3.
Like all other values, these names are assumed to be CASE-SENSITIVE.

* The number of such sections MUST be declared in the “Instances”
section using the key “NumberOfENTRYSections”.

Once a random section is assigned to a certain instance,
a certain random “Location#” value from that section is finally
assigned to the instance. The other “Location#” keys from the section
will not be used following this (if there are any). The “Location#”
keys MUST each hold three floating-point values, structured as follows:

Location#=X, Y, Z

If values are missing or if the space characters between the values
are absent, the game may crash upon loading. Make sure to NOT add
extra space characters.

* There MUST be an “Entries” key somewhere in the section
that defines the number of “Location#” keys in the section.

* If there are not enough “ENTRY#” sections for the instances defined,
some instances will use their default level spawn locations.

* There are also optional values that can be used within the sections:

- ForceStayNearMax

- ForceStayNearOK

- ForceWakeUp

- ForceSleep

- DisableActGetOut (set to 1 to disable ActGetOut)

Instance-reserved sections are sections which can be referred to
in the “Instances” section. If an “Instance#” entry has a “Reserve#”
entry of the same numbering in the “Instances” section, the name
pointed to by the “Reserve#” key will define the instance-reserved
section to assign explicitly to the instance defined by the “Instance#”
key. Neither the section nor the instance will be used in random
section selection; it will be proper to the specified instance.

The instance’s start location will then be randomly selected from the “Location#”
keys under the specific section in the same way as the random selection
sections (also using the “Entries” value).

Note that you can use this feature to give an instance a non-random starting
location without having to modify the level’s script: simply
assign a specific section to an instance using “Reserve#”
and only put one “Location#” entry in the section.

IMPORTANT NOTES:

- Almost all names/values are CASE-SENSITIVE.

- Many values are SPACE/TAB-SENSITIVE.

- DO NOT add extra 0’s before a number in a key/section name
  (i.e., BAD: “ENTRY000022”; GOOD: “ENTRY22”)

- For location values, strings must follow the exact format:
  [X Position],[SPACE CHARACTER][Y Position],[SPACE CHARACTER][Z Position]

- Instance names must NOT be longer than 49 characters.

- Section names MUST BE UNIQUE.

- Non-random selection section CANNOT be named “ENTRY#”.

- In some cases, setting WakeUp/Sleep values different from the originals
  may cause lockups and/or other problems (especially if the original script
  defines only one of the two or if they are both absent)

OTHER NOTES:

- I’ve noticed that abusing the “DisableActGetOut” setting and allowing
  too many dinos into the same buildings may crash the game. Use sparingly.

- I’ve experienced lockups (in the lab level) when setting the “ForceStayNearOK/Max”
  values to 5 or lower, as well as culling problems. I am uncertain as to whether
  the lockup pertains to these values directly, but I have not experienced those problems
  under any other circumstances.

Below is an example of a random location list INI file.

EXAMPLE INI LIST FILE (exclude comments)

[Instances]			; Main section
NumberOfENTRYSections=3 	; Number of ENTRY# sections
Instance1=RaptorA00-00		; CAnimal instances
Instance2=RaptorB00-02
Instance3=RaptorC01-08
Reserve3=ExtraSection		; Reserves/assigns locations section "ExtraSection"
				; to dino "RaptorC01-08".

[ENTRY1] ; First random section of locations
Entries=2 ; 2 location entries in this section
Location1=-99.33, 100.33, 93333.43 ; possible spawn location
Location2=346436.24234, 234, 5235.444 ; possible spawn location
ForceWakeUp=100.89 ; selected dino will wake up at this distance from player

[ENTRY2] ; Second random section of locations
Entries=4
ForceStayNearMax=135.00 ; force the StayNear values for the
ForceStayNearOK=125.00 ; instance assigned to this section
Location1=23235.435, 4545646, -324.77
Location2=444, 6456, 666
Location3=-5, -8, -5.8
Location4=55.55, 55.55, 55.55

[ENTRY3] ; Third random section of locations
Entries=1
Location1=-34, 6, -9
ForceSleep=46 ; selected dino will freeze at this distance from player

[ExtraSection] ; Section devoted to RaptorC01-08
Entries=3
Location1=2342342342, 456, 567
Location2=-435, 345.456, 74666
Location3=9999, 4534, -455
DisableActGetOut=1 ; disables ActGetOut for this dino
ForceStayNearMax=135.00 ; force StayNearMax value for RaptorC01-08

DINOSAUR VOCAL T-SCRIPT ADDITIONS

This experimental feature can let level makers define
additional ‘Dinosaur’ types for audio. As far as could
be noticed, the Dinosaur Integer T-Script value originally ranged
from 0 to 6, leaving no room for more than 7 different types
of audio compilations for different behaviours. Using higher
values would often crash the game.

As far as I can discern, these crashes were simply the result
of Trespasser allocating a fixed amount of memory for the 7
possible values, and then using the values as indexes into
that memory without checking for reads past the allocated buffer
(the total amount of allocated memory is not known, but the
raw amount required for 7 values can be calculated).

The procedure responsible for this problem has been intercepted
in ATX 1.36. ATX can thus be instructed to allocate a separate
buffer to hold data from successive Dinosaur T-Script values (this
is done when the game is started, not during level load). This
enables level designers to assign sets of Vocal Boxes (AI Command
class) to their new dinos (CAnimal class).

By default, ATX will allocate memory for 23 extra Dinosaur values.
This gives a total of 30 values, ranging for 0 to 29. This amount
can be modified using the ATXconfig.ini entry, NewDinoSoundTypesCount.
This count does not include the original 7 values. If set to 0, no
extra Dinosaur values will be supplied, and the feature will be
disabled completely (no limit checking, old EXE code only).

This quantity must be regulated, because every additional value
costs 1680 bytes of memory. For 23 values, this means 38 640 bytes. This
is very reasonable, but close to the size of ATX 1.36 itself; it
probably means nothing to you, but it is a sin to any assembly
programmer. Nevertheless, as previously stated, this value can
be increased if needed (i.e., if ATX is included in a separate mod
or level pack).

It is important to note that every Dinosaur value can be assigned
a maximum of 14 Vocal values for the Vocal Boxes (0 to 13). The
Trespasser executable reserves 120 bytes for each Vocal value,
but by default does not check whether or not the memory index
calculated from the Vocal values surpasses 120 bytes. Depending
on the combination of Vocal and Dinosaur values used, this could
lead the game to use inappropriate data from the albeit valid
Dinosaur buffer, without signaling an error.

The new ATX procedure has been written to check for Vocal values
higher than 13 and Dinosaur values higher than (NewDinoSoundTypesCount+6).
If any are detected during level load or in-game, ATX will ‘safely’ crash
the game (with an easily handleable error); if this happens, check
‘ATX_LOGFILE.txt’ to see if any of these two possible errors were
detected. The value in question will be indicated, though in
hexadecimal (use the Windows calculator for conversion).

For examples on using Dinosaur and Vocal T-Script values, simply
open a level using TresEd and use the “Hacking” menu to dump
the data to a text file (“levelname_values.txt”). Search for
“int Dinosaur” or “int Vocal” to see and compare their usage.

Thanks to MikeTheRaptor and JPDS for requesting this feature
and providing info.

TRESSTRDBG

WARNING: I CANNOT GUARANTEE THIS WILL WORK ON EVERYONE’S COMPUTER.
USE AT YOUR OWN RISK.

TresStrDbg Debug String Displayer – DLL-based version

TresStrDbg is a hacked Trespasser executable coded to display
various debug strings in real-time during the game as they are
referenced by the program. During game development, programmers
will use these strings to track and debug parts of their code.
This technique was used in Trespasser, and the proof of this is
the presence of many unused strings inside the executable. The
actual code that was used to display these strings was removed
before release. The game still references these strings very often
during execution, however, but they are passed as parameters to a
single empty function, that has remained empty until now.

This new DLL version sports a few important changes:

- Can be enabled/disabled via the ATXconfig.ini file. Set the
  appropriate entry to a non-zero value to enable (read next).

- Time-based string display. It will cycle through displayed strings
  at a certain rate, separately from keyboard commands. The amount
  of time spent per display can be set via the INI entry
  This interval is in milliseconds. If this value is not 0,
  TresStrDbg will be enabled, provided the next condition is met.

- ONLY runs in windowed mode. To run TresStrDbg, the windowed mode entry
  in ATXconfig.ini must be set to 1. This permits more efficient
  drawing code by using only the windows GDI functions to display
  the strings. Also, if the game crashes or becomes unstable, it can
  be terminated using CTRL-ALT-DEL. It is important to note that you
  still cannot switch processes even in windowed mode. This is due
  to the fact that TresStrDbg will constantly attempt to gain input
  focus from the user (this feature prevents input problems when
  other windows are open). All conditions for running the game in
  windowed mode thus apply (i.e., 16-bit desktop color…).

- NEW INPUT CONTROL. Because of Windows’ use of of the function keys,
  the control keys had to be changed. They are now all keys on the
  numeric keypad. See KEYBOARD COMMANDS for further details.

- Support for four different executables, including the Demo.

NOTES:

- I still highly recommend closing all windows before running
  TresStrDbg. Refresh your desktop to clear garbage pixels.

- Make sure “NUM LOCK” is enabled on your keyboard LEDs.

- If text appears corrupted or appears as white (on white background),
  try restarting your computer. This especially applies if the game
  experienced errors prior to running TresStrDbg.

- Make sure to read the text file on “windowed” Trespasser.

STRING DISPLAY

When you run the program, consecutive strings will be displayed in
the top-left corner of the screen. Below each string will be the
return address to the procedure which called the previously-empty
function. This can be used to track the calls back into the executable
with a disassembler.

If you have open windows upon running TresStrDbg (which can corrupt text
display) or notice strings not appearing for any reason, you will at
least be able to save the strings to a file in order to examine them
properly using the numpad1 key (described later).

KEYBOARD COMMANDS

TresStrDbg now uses numpad keys 1,5,8,9 to handle debug strings.
They are [still] slightly cumbersome, but you’ll get the hang of it after
awhile ;). It is [still] possible that they interfere slightly with Windows
commands before the main screen is loaded, but not severely.

As stated before, make sure “NUM LOCK” is ENABLED on your keyboard prior
to running TresStrDbg.

Here is a list of the keys and their functions:

NUMPAD 5 – This is the PAUSE key. As TresStrDbg cycles through strings,
you can press and hold this key to pause the game and the display
indefinitely. As soon as you release the key, the next string will
be displayed (assuming there is one). This key can also be used if
pressed quickly to cycle quicker through strings if the timed interval
is long.

NUMPAD 8 – This is the pass-through key. It will cycle quickly through
all passing strings. Speeds depend on your computer. It is ‘slightly’
cumbersome when it comes to moving around in the game, but a fun
challenge ;). When no longer pressed, the game will go back to displaying
strings at a certain interval.

NUMPAD 9 – This is the EMERGENCY EXIT key. I do not recommend constant
usage of this key, especially during loading, because it aborts the
program safely but without unloading any files (it only calls
ExitProcess). A simple touch of this key will cause an exit. Use with
care.

NUMPAD 1 – This key dumps the current string info to a file. The current
string info is APPENDED to the file (and its order inverted), which
is created if non-existing. This key ONLY works when used with
keys NUMPAD 5 and 8; it does not while the game cycles strings automatically.

The output file is “SDBG_DUMP.txt” and is placed in your root “C:\”
directory. If the file is not created, you may have run out of disk
space or have run into some other random problem.

To save a single string, use NUMPAD 5 to pause display, and simply press
NUMPAD 1 once. The info will only be saved once per string, despite
excess key presses.

To save a batch of strings, hold NUMPAD 8 and 9 at the same time.
As soon as either is depressed, the string storing will halt. Use this
feature cautiously, as the dump file can grow largely and very quickly.

OTHER IMPORTANT MENTIONS

TresStrDbg is by NO MEANS perfect, and should not be used to provide
exact debugging info. It is mostly only an example of how Trespasser
runs and loads (as well as the excess of useless code). I would say
that it is exact about 75% of the time.

The main obstacle is that the empty function which is called every
time these strings are referenced is also called by every other
piece of code that calls an empty function (which happens to mean
thousands of extra calls per execution). As a result, the only way
to verify whether the calling code is doing so in reference to a
string is by verifying the two first parameters for a valid string
address (in some areas, the string is passed as the first parameter,
and in others, the second). But there are problems with this.

The first is that, to avoid displaying hundreds (if not thousands)
of excess strings, the address parameter must be verified and limited
to a certain range. The range used here is that of the executable’s
data section. However, it is possible and even very probable that
the program passes valid strings out of this address range (in the
stack, for example), causing TresStrDbg to dismiss these strings
completely. Thankfully, however, there aren’t too many of these.
Previous versions of the program that allowed stack addresses did
not report huge differences in shown strings with this one (but
they reported way too many wrong strings).

The second problem is that it is still possible to have bogus
strings show up. For example, if you use the Quick Load
(see trescom.org) menu and load a level, there will be a string
displayed that shows the file(s) for a completely different level.
In fact, after having checked the code for this, the value passed
to the function is valid but has nothing to do with the caller’s
current execution. The value passed is the result of the caller
saving a register onto the stack (which passes values) before
running, and, coincidently, this value being the address of a
valid string. There are only a few of these throughout the exe,
again thankfully, but there is no clear way to distinguish them
from real calls.

The last problem is more or less Trespasser’s own fault. You
might notice, from time to time, that TresStrDbg will output
a string which will seem to introduce another string that ends
up missing. Examples of this include “Terrain shadow buffers:”
and “Terrain textures:” that are printed once the game is loaded.
I looked at some of the code for these strings; the problem lied
in the fact that Trespasser simply didn’t include code to display
a second string, skips to the next one instead. This simply can’t
be remedied.

NIGHT MODE

* Night Mode has been updated in ATX v1.57.

This feature, introduced in ATX v1.50, allows you to play
almost any Trespasser level at night, or at least as closest
to a night setting as I could make it. It can be enabled
in ATXconfig.ini, under the [NightMode] section, with
the EnableNightMode key (set to 1). There are many color
options that can be specified as well (see ATXconfig.ini File Details). Custom settings may be desirable if you find
the default settings too dark, or if you don’t share my tastes.

The feature can unfortunately not be toggled once the
game is loaded. This is due to many problems imposed by
the game system as well as bugs in the game itself. You will have to exit,
toggle the feature, and re-enter the game to successfully
turn it on/off.

Generally, it should function adequately with savegames,
with the exception being that games saved while Night Mode
is activated will not run properly if they are then loaded
in another game session with Night Mode disabled.

There is a chance that the feature does not work properly
with some video cards and drivers. This is an issue with
the fog color and sky height properties. However, it should
almost always work in software mode, according to my tests.

The hack itself works by changing the Default Global CLUT
settings at every level start (see Andres’s T-Script Reference),
along with fog color, some fog properties (for software mode),
sky height (for hardware mode), some default particle colors,
and ambient light (though this has a negligeable effect).
The Global CLUT settings were taken from Rebel’s “Dark Demo”
level, which deserves credit for parts of this feature. It
should be noted that most of the time spent on this went into creating the
feature itself, so I in no way promise that the other default
colors are aesthetically correct.

Note that some objects will not be darkened by this mode.
This especially applies to translucency effects, which will
not be affected at all. I did not even attempt to cover
these up, because it would nullify all potential for
flashlights (which some levels, such as the great TC-Isle, have).
Also, not all particle effects are covered, only the most
essential ones, which do not include gun shot particles. The
muzzle flash effects and animated textures are also not explicitly affected.

New in ATX 1.55 are two options available in ATXconfig.ini
to tweak the fog settings in Night Mode (FogHalf and FogPower).
They have the same definitions as their ActionType 05 counterparts.

Also new in ATX 1.55 is an *.ini system that can be used to
give alternate locations to objects in a level when in Night Mode.
The *.ini files should be placed under “MAPS\NMD\” and named
after their related levels’ *.scn filenames, but with an *.ini extension
instead of *.scn (i.e., be.scn -> be.ini). These files contain
a single [General] section and under it, three possible entries
for every instance to teleport when in Night Mode (or in normal mode,
or in both): InstanceX, NormalModeLocX, and NightModeLocX, where X
is a number between 1 and the total count of instances to teleport.

InstanceX designates the name of the instance to teleport, while NormalModeLocX
and NightModeLocX designate the positions to use for the instance
for normal mode and and Night Mode, respectively. These positions use
the standard position format: X, Y, Z. The numbers are used to relate
instances and positions. For example, Instance1=SomeInstance will use
the position NormalModeLoc1=xxx.xx, xxx.xx, xxx.xx when Night Mode is
disabled, and the position NightModeLocX=xxx.xx, xxx.xx, xxx.xx when
Night Mode is enabled. Any or both of the positions can be specified
(both can be used at the same time to avoid modifying a level’s files).
If either of the values is not to be used (i.e., to use the object’s default position
from the level), simply omit the entry altogether or set it to
=none (“none” is case-sensitive). Any values other than full location
values, the none keyword, or omittance of entries will cause errors.

You can have any number of instances (supported by the INI format)
as long as the entry names are consecutive. ATX will stop recognizing
entries as soon as an InstanceX instance name is not found, where X
starts from 1 up to 4 billion. So if you have an Instance1, an Instance2,
and an Instance5, regardless of other values, only Instance1 and Instance2
will be detected for teleportation.

An example file is provided. See “MAPS\NMD\example.ini”.

* The default Night Mode settings in ATXconfig.ini have been changed in ATX 1.57, tweaks
provided by Chupacabra from Trescom forums. The settings are yet darker, but
also more realistic. In case you find those settings inappropriate for certain levels,
you may use your own settings or try the settings provided below:

ATX 1.55 Default Night Mode Settings:
[NightMode]
EnableNightMode=1
FogNearValue=-2.0
FogFarValue=-1.0
FogColor=0x00080818
CParticlesColorMax=0x002D2D2D
CParticlesTypes=31
DefaultGlobalClutStart=0x00101010
DefaultGlobalClutStop=0x003A3A3A
FixedAmbientLight=0.001000
SkyHeight=10000000.0
FogPower=0.6
FogHalf=0.5

Chupacabra’s Settings (default for ATX 1.57+):
[NightMode]
EnableNightMode=0
FogNearValue=-2.0
FogFarValue=-1.0
FogColor=0x00000000
CParticlesColorMax=0x002D2D2D
CParticlesTypes=31
DefaultGlobalClutStart=0x00101010
DefaultGlobalClutStop=0x003A3A3A
FixedAmbientLight=0.001000
SkyHeight=10000000.0
FogPower=1.0
FogHalf=0.03

Alternate Settings:
[NightMode]
EnableNightMode=0
FogNearValue=-2.000000
FogFarValue=-1.000000
FogColor=0x00080818
CParticlesColorMax=0x002D2D2D
CParticlesTypes=31
DefaultGlobalClutStart=0x000F0F0F
DefaultGlobalClutStop=0x00373737
FixedAmbientLight=0.000000
SkyHeight=100000000.000000
FogPower=-1.000000
FogHalf=-1.000000

PARTICLE OPTIONS

A few particle effect options have been added in ATX 1.62-1.63. They
are now found under the [Particles] section of ATXconfig.ini. They all
pertain to Trespasser’s software-based particle rendering system, which
is responsible for all blood squirt, dust, and spark effects demonstrated
by the game.

The first option is EnablePersistentParticleEffects. Setting this to 1
will cause Trespasser to keep in memory particles that have fallen out
of the camera field-of-view or that had their origin location out of view.
This is much more realistic, but could have performance impacts on slower
systems. Because it is a hack in the most litteral sense, it should be
considered experimental.

Another option is OverrideMaxTotalActiveParticles, which is even
more experimental than the first. This entry accepts a number (integer, above 0)
that will force the maximum total number of
active single particle effects the game may have in memory at any one given time.
The game’s default fixed maximum is 300 (set OverrideMaxTotalActiveParticles to
0 or 300 to not use). It is NOT known whether Trespasser assumes a memory
constraint on this maximum, so values over 300 should be considered
experimental and *could* produce problems for the engine. Single particles
from general particle effects can accumulate very quickly during gameplay
(they will go beyond their intended default even in the original game levels
if set higher). Use the CPBCNT cheat to display and verify their total count.

PARTICLE-BASED RAIN/SNOW EFFECT (EXPERIMENTAL)

This purely experimental feature, first tested in ATX 1.63, uses Trespasser’s particle
system to generate basic, slightly cartoonish precipitation effects. It uses the same CParticles
class as T-Scripts to generate these, except using instances stored entirely within ATX (currently).

There are two major drawbacks: 1) particles have no collision detection and go “through” roofs, houses, etc.,
and 2) a huge framerate hit (mainly due to the rendering of the individual particles itself).
It is unimaginable to even attempt to code a collision system due to the enormous
amount of CPU work that it would add to an already processor-demanding feature, not to mention the absence
of such physics functions in ATX.

To test out this effect, you must first set the following settings in ATXconfig.ini, under [Particles]:

[Particles]

EnablePersistentParticleEffects=1

OverrideMaxTotalActiveParticles=8000

These settings allow the particles to be spawned out of camera view and to allow them in greater numbers,
respectively.

You must also find the [RainEffect] section in ATXconfig.ini and set “FeatureEnabled=1” and “ToggledOn=1” to enable the feature
itself. This should be enough for ATX to create its default constant rain effect in-game. It can be toggled (though
not entirely disabled) using the TOGGLERAIN cheat.

You can then use the remaining [RainEffect] section options to modify basic rain-spawning behaviour. The “DefaultParam7”
value, in particular, is usually 1.000000 and should generally be set to 1.000000; it seems to control some sort of density
setting, though that is unclear. The others are fairly self-explanatory. As for the
qualities of the rain particles themselves, i.e., with respects to their CParticles instances, these can be tweaked
using the file “MAPS\RNE\default.ini”. The available options loosely correspond by name to the ones found in the T-Script
class CParticles. Note: The “RNE” sub-folder currently does not contain or support any data other than the “default.ini” file, contrary
to the sub-folders of other features. Use ActionType 119 to set/toggle rain in user-made levels.

To evaluate the number of particles being displayed at one time during gameplay, use the
CPBCNT cheat. USE SETTINGS CAREFULLY AND DO SO AT YOUR OWN RISK. Applying improper values may cause ATX to generate too many
particles, and thus crashes or unpredictable behavior. Remember, the game had an original cap of 300 individual
particles for any given moment, so it is already quite astonishing to see it support them when numbered in the
lower thousands (though how officially that support is kept is unclear).

QUICK SAVE

You can now use the F9 function key to initiate a quick-save
of the game state. The file will appear in the “Load Level” dialog
under the name “ATX Quick Save”. Depending on the exact moment
at which the game was saved, there might or might not be a
snapshot to go along with the save file.

ATX records the name
of the current quick save file in ATXconfig.ini, under [GameSaving],
via the QuickSaveCurrentFileName key. Make sure you don’t have
ATXconfig.ini open before you launch the game, or this key will
not be written to properly. You DO NOT need to use ATXconfig.ini
to enable this feature. Pressing F9 will do this automatically. In general,
you should not change the contents of the QuickSaveCurrentFileName key
unless you are sure that you know what you are doing (as a general rule,
the file indicated by that key will be deleted and re-created at
some point, possibly under a different name, so putting another name
might erase one of your savegames if the filenames match).

Update (1.52): If the F9 key causes conflicts with other programs
running on your system, you can disable the ATX Quick Save function
in ATXconfig.ini, under [GameSaving], by setting EnableATXQuickSave to 0.

DRAW DISTANCE AND GAME SPEED VARIABLES

These variables are used thoroughly by ATX and throughout. The new
defaults for both can be set in ATXconfig.ini, under the [Variables] section.
They are both floating-point values. If they are set to 0, they will keep
their default values as stated in the executable. They can also be set
manually using a hex editor at their respective addresses, which are
enumerated in another part of this document.

The Draw Distance can more easily be set using the new ATX menu
slider, which by default shows up in the game’s Video Options menu.
While its values are not noted on the slider, they range from
15.000000 (far left – default) to 315.0000000 (far right). It can also be set in
real-time using hotkeys found in ATXconfig.ini (DecreaseDrawDistance and
IncreaseDrawDistance). The SHOWDD cheat can be used to display it in-game.
Note that while increasing the Draw Distance will generally make graphics
look much better (i.e., by diminishing the 2D-ization of objects past certain
distances), it can have a severe effect on framerate if not used moderately.

The game speed variable is a bit more involved. It is used by
the BIONICWOMAN cheat, the Matrix effect, and even level-based scripts
from the new ActionTypes. As a general rule, levels that customize
the game speed variable have priority over most other features. It
is strongly discouraged to use more than one feature that exploits the game
speed variable at once.

You should note that game speeds are by default saved in savegames
explicitly by ATX. This is to make sure levels that use the new Actiontype 101
to modify game speed do not lose their effect when games are saved and
reloaded. However, this has the side effect of causing all game speeds
to be saved in savegames, regardless of what feature set it. If you
would rather override this feature and force ATX to use your game
speed setting, you should set the OverrideSaveGameSpeed key in ATXconfig.ini
under the [Variables] section to 1. This will not prevent the saving
of game speeds to save games, but will keep ATX from applying them
when the savegames are loaded.

DEMO VERSION EXIT SCREEN REMOVAL

DISCLAIMER: BY USING THIS FEATURE, YOU CONFIRM THAT YOU OWN AND HAVE
PURCHASED A LEGAL COPY OF THE PC GAME TRESPASSER BY DREAMWORKS INTERACTIVE.
IF YOU DO NOT OWN NOR PLAN TO OWN A COPY IN THE NEAR FUTURE, PLEASE DISCONTINUE USAGE OF
THIS FEATURE IMMEDIATELY.

This hack (though not new) can be applied via ATXconfig.ini, under the
[General] section, using the DisableDemoExitScreen key. It will remove the
game exit advertisement screen if set to 1 (which is the default value).

HOTKEYS

*** ATX 1.60 introduces a new hotkey system for all in-game cheats. Some of
the old key entries under the [Hotkeys] section in ATXconfig.ini are now obsolete, will
have no effect, and thus have been removed from the default listing.

Some ATX features provide quick-access HotKeys for increased efficiency
or necessary controls. Many can be set in ATXconfig.ini, under the [Hotkeys]
section. You should only specify lowercase alphanumeric characters, without
spaces. This implies the ‘a’ to ‘z’ and ‘0’ to ‘9’ keyboard characters.
For example, “SomeFunction=m” will make the ‘m’ key toggle or use the SomeFunction
function. Notice the lowercase character and the lack of spaces or tabs.

The key input rate may depend on your keyboard repeat rate as set in the Windows Control Panel.
In general, all hotkeys are non-intrusive (will not
replace existing functions for those keys, only add to them), except for “ToggleNewKeys”,
which you may be required to use when activating the console to prevent
hotkeys from triggering functions as you type text. Note, however, that you can not
have two hotkeys sharing the same key, because they are based on the same input system,
despite not interfering with the standard Trespasser controls (since this one uses
a different input system). *** Some ATX features such as THIRDP have their own set
of hotkeys and some of these do use the same system as the ones from [Hotkeys]; you will
not be able to use these keys unless you reassign them. For example, THIRDP uses
the “n” and “b” keys to toggle some aiming features, so these keys will not work
as [Hotkeys] entries unless you disable them under the THIRDP settings.

ATX 1.60 allows you to assign hotkeys to any and all existing cheats for Trespasser,
both original and ATX-based. In fact, ATX places no restrictions on what cheats
you may want to try to toggle using these new hotkey entries, so *BE WARNED*:
if a specific cheat requires parameters to function properly or to prevent crashing,
ATX will not prevent you from toggling the cheat anyway. Use at your own risk, and have fun.

The default ATXconfig.ini ships with a few default key entries, notably ToggleNewKeys
and keys for setting a temporary draw distance. To use the new ATX 1.60 cheat hotkeys,
you simply need to add entries labeled with the same name as the cheats you want to use,
and then assign a key after the equality symbol as usual. The format is as follows:

[Hotkeys]
CHEAT1NAME=x
CHEAT2NAME=x
CHEAT3NAME=x
...

… where CHEATNAME is the cheat’s name as you would type it at the console, and x is
the key you want to assign it, different for every cheat (following the usual rules for valid hotkeys).
Here’s an example:

[Hotkeys]
ToggleNewKeys=y
MAP=m
LOC=l
FLY=i
CANIMAL=u
N=o
B=p

Again, do not forget that you cannot use the same key twice, and some keys
are by default reserved for other function such as THIRDP (aim gun keys).

Note: Features can also have customized input systems which are not defined using
HotKeys in the [HotKeys] section. These systems are defined separately for
their parent features.

TPA (MENU) FILE RELOCATION

This simple option allows you to change the location
of the Menu.tpa file to a folder within the user’s root
Trespasser folder. To enable this, simply place your
alternate Menu.tpa file within the Trespasser folder
(i.e., C:\Program Files\Dreamworks Interactive\Trespasser\ by default)
or any folder within that folder, and rename Menu.tpa
to whatever you wish. Then, open ATXconfig.ini, locate
[TPAFiles] section, put your tpa’s sub-folder and filename
as the value for the entry AlternateMenuTPA. For example, for
you place it directly in the main folder and name it asdf.tpa,
you should have something like AlternateMenuTPA=asdf.tpa. If you
place it in a sub-folder such as MAPS\, you would have something
like AlternateMenuTPA=maps\asdf.tpa.

Filenames and paths are not case-sensitive. They should not contain
apostrophes (“”). If you no longer wish to use the feature, simply set
the appropriate entry to 0.

ALTERNATE LEVEL TPAS

* This feature is currently experimental. This documentation applies mainly
on a theoretical level and may not behave as expected.

Note: In this description and its descriptees, the term “alternate” is
loosely interchanged with the term “additive” when referring to the new optional
level-specific TPAs.

ATX 1.60 allows level makers to use additive TPAs with their levels via the MAPS
folder, enabling sounds to be added without having to modify the users’ existing
TPAs and the level’s T-Script. These TPAs are simply extensions to the usual Stream.tpa, Effects.tpa, and
ambient.tpa sound files, with the files being potentially portable between
levels as well as unique between the levels if necessary. They are loaded into memory
only when a new level is loaded, and are released from memory as soon as a different level
is loaded or when the game exits ***. The TPAs themselves
can be modified using Andres James’s TPAAdd command-line utility.

You can specify up to 3 additive TPA files for your level, each mimicking
one of the original TPA file types (Stream, effects, ambient). Instead of adding
sounds to the user’s TPAs using TPAAdd after level download, you can put all of
your sounds inside the additive files and distribute these with your level instead.
When ATX detects that a level is using an additive TPA, it will load the file
atop the already-loaded original game TPA files, and everytime a T-Script is set
to play a sound from one of the original files, it will first scan its respective
additive file. If the sound is found in the additive, it will be played immediately.
If not, ATX will let the game process the sound in the original TPA as usual. This way,
you do not have to modify your T-Scripts to accomodate a new sound system; it is
all done externally and automatically. An added bonus is that you can replace the
original Trespasser sounds simply by adding them with the same name in the additive
TPAs, since the additives are scanned first in real-time (the original sounds
in the original TPAs will be ignored if sounds with the same names are found
in the additive TPAs).

Which sounds you put in which additive TPA will matter. i.e., if you are using a sound
that you would normally add to Stream.tpa, you will put it in its own associated
additive file. You can designate the files by including an *.ini file
in the “MAPS\LVL\” folder that now comes with ATX; the *.ini file, as usual,
must be named after your level’s SCN filename (i.e., it.scn -> it.ini). Inside
the *.ini you will have to place the following section and keys:

[AdditiveTPAFilenames]
Stream=
Effects=
Ambient=

Each of the above keys (Steam, Effects, Ambient) can be assigned
a filename for its additive TPA file, with extension and partial path.
You can specify any or all of the above; those with keys not included in the *.ini
will only use the original Trespasser TPA files.
In turn, you can put the additive TPA files themselves either directly
in the “MAPS\LVL\” folder or in a subfolder of this folder which you will have to
designate in the key values. If there is only a filename (no path),
the files will be taken from the LVL folder, otherwise from whichever
subfolder is included in the filename. You must separate subfolders
using the backslash “\” character. THE PATH CANNOT CONTAIN SPACES
OR APOSTROPHE CHARACTERS. Here is an example (do not include comments):

[AdditiveTPAFilenames]
Stream=mysupersubfolder\addStream.tpa	     ;-> "[Tres folder]\MAPS\LVL\mysupersubfolder\addStream.tpa"
Effects=myeffects.tpa			     ;-> "[Tres folder]\MAPS\LVL\myeffects.tpa"
					     ;-> (Ambient key omitted) do not use an alternate ambient file, use original Ambient.tpa only

The possibility of using *.ini files to designate your filenames allows you
to re-use the same files for multiple levels; all you need is an INI for each
level name, with keys pointing to the same files.

Three empty TPA which you can use as additive files have been provided
in the folder “MAPS\LVL\ExampleTPAs\”, with an example INI in the preceding
LVL folder. These files were graciously provided by Rebel of Trescom (many thanks).
They have the same names as the original TPAs, but with an “alt”
prefix. In general, although it is not necessary, I would recommend giving
unique names to either your sub-folder containing your additive TPAs or to
the TPAs themselves. This will prevent users from accidentally overwriting
essential level files when installing levels.

For diagnostic purposes, you can disable the entire feature in ATXconfig.ini,
under [TPAFiles], via the DisableAlternateLevelTPAs key (set to 1). This does
not affect the alternate Menu.tpa feature.

* IMPORTANT NOTE: While Stream and Ambient additive TPAs have been tested
to work properly, support for the additive Effects.tpa is still very experimental.
This TPA is different from the others in that its original contains a “foley table”,
as noted in the Trespasser File Formats reference. This table is responsible for
assigning which sounds to play when different SoundMaterials collide. It is
“built-into” the file and cannot be managed by ATX. As a result, you may
experience problems with sounds originating from collisions; please notify
me if you run into such issues (or any other, for that matter).

*** TPA files are loaded into memory at every new GRF file load. If the “Disable
Fast Restart” option is checked, they will be reloaded at every level restart of
the same level (the time required to load these files is not very significant, however).

HEADS-UP DISPLAY

ATX 1.58-1.59 showcases a basic HUD system capable of displaying a few
common game items such as player health and ammo. You can enable the HUD
in ATXconfig.ini, under [General], by setting UseHUD=1. This setting
will instruct ATX to use the images and settings found under
the “MAPS\HUD\” folder for screen display. You can also toggle the HUD
in-game with the “HUD” cheat; however, this does not remove the
files from memory as does the INI entry when set to 0. You must restart
the game to completely toggle the feature with the INI entry.

The default HUD images and configurations for ATX 1.58-1.59 were designed
and provided by Slugger of Trescom, who also spawned the idea for this feature (as it is).

The HUD is customizable. It can be modified by changing the files found
in the “MAPS\HUD\” sub-folder of ATX. The file “ImagesLocations.ini”
contains the settings and required info. Other files present in this
folder should include 24-bit bitmaps (i.e., from MSPaint).

ImagesLocation.ini

ImagesLocations.ini contains 4 possible section: [ImageFilenames],
[PlayerHealthCountBG], [PrimaryAmmoCountBG], and [SecondaryAmmoCountBG].

[ImageFilenames] contains a series of key entries that define the bitmap
filenames to use as images for the HUD, including *.bmp extension. These bitmaps should be found
in the HUD folder and follow the 24-bit uncompressed RGB format. For every
bitmap, the color for the top-left pixel defines the color-key for transparency
when displaying the image. For example, if this pixel is white, then any other
white pixel in the image will appear as transparent and will not be shown.
It is important to note that Trespasser uses 16-bit display, so there will
be some color loss in your 24-bit bitmaps. It is recommended that you keep a simple or contrasting
color-key such as white, green, blue, etc. if you use many shades of the same color(s) in
your images, to avoid possible transparency problems during pixel conversions.

There are 13 possible image entries: PlayerHealthCountBG, PrimaryAmmoCountBG,
SecondaryAmmoCountBG, and Digit0Image-Digit9Image. PlayerHealthCountBG
is the background image for player health display, PrimaryAmmoCountBG
is the background image for the ammo value for the gun the player
is currently holding (if any), and SecondaryAmmoCountBG is the background
image for the ammo value for the gun the player currently has holstered (if any).
Digit0Image-Digit9Image are 10 different bitmaps that will be used
to display the numerical values for ammo, health, etc., starting from
digit 0 to digit 9, respectively. Simply put, instead of using default fonts
to display numbers, you must store the digits in images. This is a little
more work, but provides extra flexability.

If any of the 3 background images is not specified or is invalid, it
will not be displayed in the HUD, along with its related numerical
values. For example, if you do not want a display or values for secondary weapon ammo (holstered),
you can simply omit the SecondaryAmmoCountBG INI entry. For the 10
digit bitmaps, you should always have all 10 bitmaps valid and specified,
and preferably have all of them share the same width and height attributes,
though this last point is not required.

The next sections, [PlayerHealthCountBG], [PrimaryAmmoCountBG], and
[SecondaryAmmoCountBG], are generally optional, but considered required
if their corresponding entries under [ImagesFilenames] are present.
Each of these sections holds the same entries, but applies them to
the different displayed values. Each of the 3 possible sets of values
(health, primary ammo, secondary ammo) can display up to 3 things:
a background image (to ‘hold’ the values), a current value (i.e.,
current health, current ammo), and a maximum value (i.e., an ‘out of’
value, such as max health, max ammo). The following entries define
how these are displayed:

AlignmentX=
AlignmentY=
DisplacementX=
DisplacementY=
DigitsOffsetX=
DigitsOffsetY=
Digits2OffsetX=
Digits2OffsetY=
UseDigitPadding=
UseResizing=
DefaultResizeXRes=
DefaultResizeYRes=
UseDisplayMaxValue=
* All of these values are integer (int) values.

AlignmentX and AlignmentY specify the general area on-screen where
to place the main background image. For AlignmentX, a value of 0
indicates left of screen, 1 is center, and 2 is right. For AlignmentY,
0 indicates top, 1 is center, and 2 is bottom. So, for example, to
have an image placed at center-right of screen, you should have
AlignmentX=2 and AlignmentY=1. Alignment is implicitly calculated
from the image’s width and height.

DisplacementX= and DisplacementY= are offsets applied to the
image’s position on-screen after alignment has been done. If
UseResizing (explained later) is set to 0, these values are
always absolute pixel position values, while if UseResizing
is set to 1, these values will follow screen resolution accordingly.
Setting DisplacementX to a positive value will move the image
toward the right of the screen while a negative value will move
it left. Setting DisplacementY to a positive value will move
the image downward, while a negative value will move it upward.
* BE CAREFUL when using these values. If any part of your
image (even one scanline) is thrown out of screen as a result
of offsetting its position with displacement values, DirectDraw
will not output the image at all.

DigitsOffsetX and DigitsOffsetY respectively define the horizontal and vertical offsets from the
top-left corner of the background image where the first (current)
numeric value associated with the image will be displayed
(DigitsOffsets should be positive values). i.e, player health, ammo remaining, etc.
If UseResizing is set,
these values will be adjusted depending on resolution so that
the numeric values are printed at the same location even
with image resizing. If not, these are absolute pixel offsets.
The displaying of the individual digits for the number will
begin at this offset but be done automatically by ATX. The number
may consist of up to 3 digits, which will be positioned adjacently.
By default, there will be no extra spacing between the digits; they will
simply be separated by width. In cases where digits are omitted, spaces
reflecting the width of the omitted digit will be added. Values are
constrained to being between 0 and 999, naturally, and any value out of bounds
will be represented by 0 or 999.

Digits2OffsetX and Digits2OffsetY have the exact same behaviour
as DigitsOffsetX and DigitsOffsetY but give the offset for the second
(max) numeric value to be printed. i.e., max player health, max ammo gun can hold, etc.
UseDisplayMaxValue defines
whether the second number is to be printed in the first place. If set to 1, it will be
displayed and Digits2OffsetX/Digits2OffsetY will take effect, and if set to 0,
it will not be shown and Digits2OffsetX/Digits2OffsetY will have no effect.

UseDigitPadding applies to the display of any number that does
not take up 3 digits, i.e, 1, 2, 99, etc. If set to 1, when either
of the first or second numbers are printed over the background image,
numbers will be padded to the left with 0’s, i.e., 1 -> 001, 99 -> 099.
If set to 0, when printing occurs, no 0’s will be printed, but spaces
(of size determined by the width of the omitted 0 digit image bitmap)
will be placed to the left instead.

UseResizing determines whether to use DirectDraw-based image resizing
whenever the user uses the HUD in a screen resolution other than the ideal
resolution for this specific HUD. If set to 1, all images’ widths and heights
as well as some of the offset values described above will be resized according
to screen resolution. If set to 0, no resizing will be performed, so all
images will be displayed on-screen with their original pixel sizes, and
all offset values will represent absolute pixel values, all regardless
of the resolution the user has chosen. Although disabling resizing is
faster and avoids image distortion, you may run into problems in
lower resolutions if your images are too large (i.e., out-of-screen
coordinates – which causes the image to disappear entirely, or
screen crowding).

If UseResizing is enabled, you MUST specify the values
DefaultResizeXRes and DefaultResizeYRes (must be greater than 0).
These define the optimal resolution for the HUD and thus which
proportions to keep when the user chooses a different resolution.
For example, if your HUD looks good in or is meant for 800×600, you would
have DefaultResizeXRes=800 and DefaultResizeYRes=600.

Notes:

- The ATX HUD system uses DirectX’s DirectDraw. Some older video
  cards may not implement all functions properly.

- All tests have been performed using video cards capable of
  displaying 16-bit 5-6-5 RGB video. While 16-bit 5-5-5 RGB video
  is theoretically supported, it has never been tested and you
  may run into problems with some video cards.

- The ATX bitmap-loading code has not been tested to load anything
  other than 24-bit MSPaint-generated bitmaps. If you run into problems
  creating compatible bitmaps, I would suggest designing them from
  whichever software and copy-pasting the result into MSPaint and
  saving it to a *.bmp from that program.

- If your images do not appear on-screen, make sure that:
  - - Your images are uncompressed 24-bit RGB bitmaps
  - - The images are stored directly in the “MAPS\HUD\” folder
  - - The ImagesLocations.ini file contains the proper filenames
      under the [ImagesFilenames] section
  - - The ImagesLocations.ini file does not contain offset values
      that might throw any part of your image off-screen (if so,
      the entire image would not be shown)
  - - Your images are not larger than typical screen resolutions
      (if they are most likely to be larger than some resolutions,
      you should consider enabling image resizing)

AI HACKS

Some AI options are available in ATX via ATXconfig.ini, under the
[AISettings] section. They include allowing dinos in buildings,
adding or substracting health from dinos, removing limits on dinosaur
movement, and increasing their ‘activation’ distance (from the player).
These are generally experimental.

The AddFreezeDistanceToAllDinos setting (floating-point value)
is more specifically prone to causing crashes. It also causes dinos
to ‘freeze’ in areas with more than 3 or 4 dinos active at once. You should
not set this setting very high. It is mostly useful in levels where few
dinos will encounter the player at any given time. It will apply to all
savegames, all level restarts, all new levels, etc. However, changes
are not saved in savegames, so this value can be changed for existing
savegames.

The AllowDinosInBuildings, ForceNoStayNearTarget, and ForceNoStayAwayTarget
are very simple hacks that simply remove animal-bounding features from
the game altogether. Their applications were originally suggested to me by Rebel and Remdul
of Trescom. Set them to 1 to enable each individually. Although they generally
do not cause major problems, they may result in oddities, such as dinos leaping
off cliffs, dinos freezing, dinos not recognizing and running into objects,
and dinos being very out of place (in short, nothing really new).

AddHitPointsToAllDinos is a floating-point value. It will add the specified amount
of hitpoints to every dino in every level. Although it was originally conceived
to increase game difficulty, the implementation of the new game difficulty settings
renders this setting rather obsolete. It is still implemented, though, and will
work under the same conditions as the Game Difficulty settings (i.e., at same
new level/restart level/save game patterns).

FAST LEVEL RESTART DISABLING

This feature has been included in ATX v1.50. It can be set in ATXconfig.ini,
under the [General] section, with the DisableFastRestart option. A menu option
is also provided for this feature.

Setting the option to 1 will simply instruct Trespasser to treat every
level restart/savegame load as if it were loading a different level. This will
cause the loader thread to re-load the GRF file associated with the level and
re-set all possible values. It will not, however, cause the re-creation of swap
files (*.swp), which is only necessary for level designers.

While it does increase loading time for level restarts and savegame loads
within same levels, it also ensures that the game re-loads all instances
properly. The game has been known to exhibit bugs at level restart time.
More importantly, it causes all user-made (TresEd-compiled) levels that
were distributed without proper scene files (*.scn) to restart as they should.

I will note in advance that future and present ATX features may use
this feature implicitly. It ensures reliability and simplifies the programming
of some. It is generally recommended to use this feature, though slower
system may find it less attractive.

Please also take note of the fact that some levels have been known to crash
upon reload with this feature. I would highly recommend level designers
to test their levels for restarting/savegame loading with this enabled,
because the problem usually lies in the level itself and can expose issues.
Some errors seem to be related to terrain, though it’s difficult to pinpoint
the exact cause.

NEW MENU OPTIONS

ATX now makes use of some new menu options incorporated into the
game’s menu system at run-time, using the *.ddf file format (thanks
to madppiper of Trescom for the tutorial and specifications). They
are fully enabled by default, but can be turned off entirely or
partially in ATXconfig.ini, under the [General] section, using
the EnableNewMenuItems key. 1 indicates full integration, 0
indicates the feature is disable completely, and 2 tells ATX
to display only the Draw Distance slider in the Video Options
menu.

It should be noted that this feature, along with many others,
relies on the presence of the “MAPS\” folder in the root
Trespasser or Trespasser demo directory (not the “tres cd”
directory) for proper function.

*** As of ATX 1.54, all ATX menu
script additions are implemented in the form of editable DDF files
in the “MAPS\” folder. These are enumerated and commented on further below.

The following
note is directed to and should be read by anyone implementing
custom menus alongside a redistribution of the ATX package:

NOTE FOR MENU EDITING

ATX uses the following IDs to identify some of its
menu objects. These must remain unique across ALL DDF
files used by a copy of Trespasser, not only the DDF in which
their respective definitions are to be found. Unless
you plan to disable the new ATX menu items, DO NOT
USE THESE IDs.

SLIDER_GAME_DIFFICULY_ID	equ	1956
SLIDER_DRAW_DISTANCE_ID 	equ	1794
CHECKBOX_MATRIX_ID		equ	1869
CHECKBOX_JUMP_DINOS_ID		equ	1868
CHECKBOX_RANDOM_INST_ID 	equ	1867
CHECKBOX_FAST_RESTART_ID	equ	1866
HOTSPOT_MATRIX_ID		equ	1669
HOTSPOT_JUMP_DINOS_ID		equ	1668
HOTSPOT_RANDOM_DINOS_ID 	equ	1667
HOTSPOT_FAST_RESTART_ID 	equ	1666

ATX 1.54 also uses the following 4-character case-sensitive
keywords to identify and modify parts of the DDF files upon loading:

- GDIF (mainscreen.ddf – replaced with initial game difficulty value for slider)

- ATXV (mainscreen.ddf – replaced with ATX version indicator)

- DCUT (mainscreen.ddf – when loading the demo executable, anything after this will be cut from file)

- DDST (render.ddf – replaced with initial value of draw distance for slider)

These keywords are used in the following files from the “MAPS\” folder:

- atx_mainscreen_ext.ddf

- atx_render_ext.ddf

You may edit these files at will, but keep in mind that every occurrence
of the above keywords in these files will be replaced with their
corresponding values, whether in comments or in general text. This may
cause errors if there is misuse.

In general, when editing the ATX menu options, you should leave all of the
above keywords and IDs as they are. You may modify other values, such
as item positions, without any major problems, provided you move checkboxes
and their associated hotspots together, for example.

It is also strongly recommended that you leave extra spaces and carriage returns (empty lines)
at the end of *.DDF files in general. In some cases, the Trespasser *.DDF
handler will omit values at the end of these files if they are not padded
this way (this is why the ATX DDF extension files have “; EOF” at the end,
that is, to discourage accidental deletion of this padding).

For EnableNewMenuItems entry in ATXconfig.ini:

Set to 0 to disable _all_ ATX integrated new menu items,
including draw distance option. All values can still be toggled
via ATXconfig.ini. Set to 2 to disable all new ATX-related
mainscreen.ddf menu items, while preserving new render.ddf items
(draw distance slider).

Misc. source code note: The checkbox method is never called if the checkbox area is
overlapped with a hotspot-defined area. Only the hotspot
method is called. This applies to the default “audio.ddf” checkbox
items.

ATX 3DNOW! OPTIMIZATIONS

This feature must be enabled explicitly in ATXconfig.ini,
under the [General] section, using the EnableNewLevelLoadBGs
key (set to 1). It is only valid for the AMD K6-2 and newer AMD
processors which support 3DNow! instructions. If you enable
this for Intel processors, the game will crash at some point, because
no processor-detection algorithm has been implemented.

Despite expectations, this feature can be set for any of
the four ATX-supported Trespasser executables, and not just
the AMD K6 1.1 version. But, again, this requires an AMD processor.
I did not restrain this feature to the AMD K6 executable, because
it could be useful for the demo version.

I in no way promise large (edit: or any) performance gains, and the degree
of optimization is left at my discretion. Only ATX features
will be optimized, with the possible exception of a few Trespasser
functions, again all at my discretion. The feature should be
more noticeable on AMD K6-2 and K6-3 processors, though it can
be seen occasionally on my Athlon as well, in more detailed scenes,
using some features.

DEFAULT GAME FOG SETTINGS

The game’s default fog color can be overridden in ATXconfig.ini,
under the [FogSettings] section, via the DefaultGameFogColor key. It
is a hexadecimal value. It is stored as a 24-bit color, under the
format 0x00RRGGBB, where R = Red, G = Green, and B = Blue. It
will be loaded for levels that do not set fog color via the level
script ActionType 05 or in cases where the fog color is not set
properly.

You will most likely not notice the effect of this value in
software mode. Most levels do use ActionType 05, and in software
mode, setting fog color this way for a specific level always works.
However, there appears to be a bug in hardware mode that causes
fog colors to be set one level-load late (one GRF-load late, to
be precise), and in some other circumstances as well. One way
around this bug is to use a single fog color across all levels
to be designed, and use DefaultGameFogColor to set it, indicating
to the user not to load other levels in-between.

Added in ATX v1.54-1.57 is an option to disable/modify fog for all levels.
It can also be found under the [FogSettings] section, as OverrideGameFogValues
(previously known as DisableGameFog under the [General] section).
Set to 1 to enable. The feature works by setting the ActionType 05 FogPower and
FogHalf settings to specific values at/for every level load, bypassing the
level settings. It will override the Night Mode settings. Under the same section,
you will find FogPowerForcedValue and FogHalfForcedValue INI entries. By default,
these have the value 0.000000 (0). When OverrideGameFogValues is enabled, these
are the floating-point values that will be used to modify fog appearance as described.
Using their default values (0), they will generally disable fog when using hardware rendering.
In some cases (often under software rendering), the default values may not properly
disable fog or produce visual anomalies. These settings are thus provided to tweak fog Power and Half (~density, distance,
and similar aspects) when fog is disabled/modified, if needed. These have the same definitions and behaviours
as the T-Script ActionType 5 FogPower and FogHalf values. As such, they may be used
to remove fog completely or simply tweak its density/distance globally.

HIGH RESOLUTION PATCH

This hack, originally created by TSOrd and Mark Grant, to which
all credit for this feature should be diverted to, is enabled by
default in ATX. It can be disabled if needed in ATXconfig.ini,
under the [General] section, via the EnableHighResolutions key
(set to 0). It has been included in ATX for ease of use, but also
to commemorate the sadly-deceased TSOrd, whom I unfortunately never
had a chance to communicate with.

ATX 1.55 has an extra setting in ATXconfig.ini (under [Troubleshooting])
to override the maximum detectable resolution (OverrideMaxResolutionX).
By default, it uses 2048 (x portion of the resolution), which is the value
used by the original hack. Depending on video drivers, you may get different
results by tweaking this value.

There have been observations that different executables can report
different lists of available resolutions on the same system. This has
been clearly shown in one case with the P5 1.1 and P6 1.1 executables.
The cause is unknown, but you may use this result to attain higher
resolutions by trying different executables.

ATX 1.56-1.57 add a few INI entries in the [Troubleshooting] section of ATXconfig.ini
relating to video mode enumeration issues. The first is
OutputDirectDrawVidModeEnum. Setting this value to 1 will cause ATX
to print to ATX_LOGFILE.txt all of the DirectX-enumerated resolutions when visiting
the game’s Video Options menu. These printouts only include the values enumerated
by DirectX itself, and not the ones that may be forced into the resolutions list
using other INI entries. To effectively use this function, you should set the INI
entry to 1, open the game, open the Video Options menu once and once only, exit the
menu immediately by clicking “CANCEL”, and then exit the game. This will append
two lists of resolutions at the end of ATX_LOGFILE.txt which describe the game’s
two main enumeration procedures. These may be of some help for diagnostic purposes.

The second new entry is named ForcedVideoModesList. You may use this value
to force resolutions into the list found in the game’s Video Options menu which you
may then select in the menu to use as in-game resolution (as usual). In some
cases, DirectDraw will not properly enumerate all resolutions that you hardware
may support. If you are 100% certain that your hardware supports a certain resolution
in 16-bit color, you can specify it via the ForcedVideoModesList key. You may
include up to 9 or 10 resolutions to add to the menu options by using the key in this fashion:

ForcedVideoModesList=800×600, 1024×768, 7456×2343

As seen above, you simply need to specify resolutions using the WIDTHxHEIGHT format
(“x” is case-sensitive, and no extra spaces) for each resolution and separate
each different resolution with a comma and a space character. Failure to follow
this format may lead to unpredictable results. If you no longer wish to use
this feature, simply set the value:

ForcedVideoModesList=0

WARNING: As you may have noticed in the above example, you can enter a ridiculous/non-supported
resolution such as 7456×2343 into the list. It will appear into the Video Options list
and the game will attempt to use it WITHOUT checking for its validity. If your hardware does not
support such video modes, this may lead to grave errors including blank screens, crashes, flickering, etc.
(ALT-TABing out of the game may or may not work, depending on the severity of the error).
In short, DO NOT ATTEMPT TO FORCE A RESOLUTION INTO THE LIST UNLESS YOU ARE 100% SURE THAT IT IS
SUPPORTED BY YOUR GRAPHICS CARD/MONITOR/OPERATING SYSTEM/DRIVERS.

MAX ACTIVE DINOS

UPDATE (26/08/2006)

It has recently been discovered that
the Trespasser physics engine has a built-in fixed limit
of 8 total active animate instances at one time, which
means 1 player and 7 dinosaurs at the very most. Beyond
this, instances will freeze, warp, and do really weird
stuff nobody wants. Also, one of the game’s major
physics buffers that holds active boundary boxes is
capped at a hardcoded 50 boxes. So, if you have 7
active raptops with 5 boundary boxes each and a
player with 3, you effectively fill up 38 of those
50 slots and leave few for gameplay.

The bottom line is that even though it *might* be possible
to increase the limit of active animates within the physics
system to go over 8, such as has been painstakingly done
with the AI system hardcodings, there would then be the
even bigger problem of busting the physics engine limitations
on active physics boxes. You could argue that the same could
then be done with the box buffer to go over 50, but unfortunately
this buffer is even more hardcoded than the AI or
other physics list and is probably accompanied by a whole slew
of other buffers. Basically, you would end up spending a year
finding every little hardcoded address in assembly and probably break the
engine in the process.

As a result of this, I will officially NOT be continuing
the MaxActiveDinos hack. What this information does provide,
however, is the max number of dinos the current MaxActiveDinos
INI entry can be set to: 7 dinosaurs. THIS ASSUMES
THAT THE PLAYER WILL NEVER BE PUT IN A SITUATION WHERE HE/SHE
MAY ENCOUNTER MORE THAN 7 DINOSAURS AT ONCE. The reason for
this is that, as already discussed, the AI system has a possible
bug that causes it to ‘blur the line’ by plus/minus 1 or 2 the max
number of active dinos. So if you put MaxActiveDinos to 7 and
the player encounters 8 or 9 dinos, things may go horribly awry
physics-wise. Of course, don’t put MaxActiveDinos to over 7, either;
that’ll make it even worse. To play on the safe side, I would
recommend keeping it at 5 or 6 if you can’t control how many dinos
the player encounters. Theoretically, you should be fine
setting it to 6, but I have seen a few cases where the number was
busted by two, and you simply don’t want to go past 7 active dinos,
physically.

However, because of that possible AI bug, for any number you set
MaxActiveDinos to, you’ll want to keep the max possible encounter-able
dinos to that number or less, for best experience. And so, the bottom line is
that 7 dinos will work as long as you set MaxActiveDinos=7
and never, ever have more than 7 dinos active at once.

The End

ORIGINAL DOCUMENTATION

This hack attempts to trick Trespasser into increasing
the amount of dinos allowed to be active at a single time.
This can prevent the “frozen dinos” effect that appears
when too many are active, and even fix some odd dino
behaviours when the limit is reached (simply by setting
the value to one higher than the max possible value within
a level).

To active it, set the MaxActiveDinos value in ATXconfig.ini
(under the [General] section) to the desired value (i.e., 8).
There is some discordance in the way the game treats this
value; it is unclear whether the default value is 3 or 4 ***,
because it varies in different parts of code. I do not know
if this is a bug or if it is intentional ****. Either way, ATX does not
attempt to work around this issue for compatibility reasons.
As such, you should generally add 1 to the MaxActiveDinos value
you wish to set, or experiment if you are trying to set a
fixed limit. Setting MaxActiveDinos to 0 (default) disables
this feature and uses the original code and values instead.

If you choose to use this hack, keep in mind that it is
HIGHLY EXPERIMENTAL and has not been thoroughly tested (mainly
because there’s no way to know what to test in the first place).
It is a _very_ extensive project compared to other hacks. This
means that it was not created by modifying some isolated variable,
but rather by modifying dozens of code instructions throughout
every one (over 30 addresses for each of the 4). The exact constraints
and workings of the code are not known, and for that reason,
the hack may not be entirely stable. In fact, IT IS NOT KNOWN
IF THE HACK IS COMPLETE. I STRONGLY ADVISE LEVEL DESIGNERS NOT TO RELY
ON THIS HACK FOR LEVEL DEVELOPMENT. It is provided for testing purposes
only. You’re swimming with the sharks, my friend.

Known bugs (partial list) *:

- Some crashes

- The MaxActiveDinos value itself can be set very high, but
  the game may not be able to handle this value at run-time if this many
  dinos are activated at once in a level (see next point).

- Currently will not allow more than 4-6 dinos truly active (others will
  appear frozen and intangible, often distorted when they get out of WakeUp/Sleep range).
  Inactive dinos do not have a “physical” presence.

* There is no way of knowing definitely if these problems are directly
related to this hack.

*** As the true number of maximum active dinos can be noticed in-game,
the question about the values mentioned here does not necessarily
refer to the actual number of maximum active dinos, but rather
to the way it treats the active dino instances. For the MaxActiveDinos
value set in ATXconfig.ini, the direct value corresponds to the default
value of 3 used by the game, while the value of (MaxActiveDinos+1)
corresponds to the value of 4 used by the game. This means, that, in
theory (not taking into account the extra code changes), setting MaxActiveDinos
to 3 should have the same effect as disabling the hack (whether
the end result is 3 or 4 max active dinos at once). Note: After a
few tests, it becomes evident that the MaxActiveDinos value corresponds
to the true value of max active dinos PLUS the one “bogus” dino (explained below).

**** A more detailed explanation of the problem would be as follows:
The active dino instances recognized by the main AI System method
are found as fixed members of the AI System main class at a
high offset (which allowed the dozens of references to be tracked
down and encoded in ATX). According to some parts of the executables,
mainly the initialization functions, by default, there are indeed 4 slots
reserved for dino instances and 4 extra slots for instances which may
or may not be related to these (but which are taken into account by ATX
for compatibility reasons). However, other parts of code, including
the main AI System method, only scan in the last 3 slots. Using data
tracked down in real-time, I have found that the first slot is used
under some circumstances, but generally randomly. Now, taking into
account the fact that Trespasser often has one “bogus” dino when there are
4 active dinos of the same kind (i.e., spins in circle, walks toward infinity, etc.),
it would be only natural to assume that the mistreatment of the first slot
could be the cause of this bogus behaviour. However, I have tried
“forcing” all scan values to 4, but this results in crashes to desktop
without error.log, which is the kind of crash that’s not worth trying
to mess with. This is all conjecture, however, and has not been proven
despite all likelyhood (the bug does indeed exist, but it is not 100% certain that
this possibly misused slot is the cause). Currently, the only way to truly bypass
this bug is to set MaxActiveDinos to a higher value and design levels so that this value
minus one can never be reached. However, using this feature as a base
for level development is discouraged due to possible instability.
So the answer?… Just don’t. Yes, in a way, I wrote all of this
for nothing. But then you don’t expect me to just delete it, do you?
I mean, this took time for me to write. And if I wrote it, it’s because in
some way someone was meant to read it, no? Alright, enough.

NEW ACTIONTYPE REFERENCE

New ActionTypes are values that can be used in Trespasser levels
using T-Scripts, and typically, via Andres’s TresEd level editor.
ActionTypes are integer values specified in trigger instances
that are rigged to perform certains actions, often using secondary script
values defining the ActionType’s behaviour. The new ActionTypes
provided by ATX start at number 100 and generally work with most
trigger types, except where noted differently.

Because of the limited availability of T-Script entry names,
the nature of these names may not relate to the nature of the actions
or values. Also, the types of data used for certain entries may differ
from the types used for the same entries in the default level files.
This has no effect on compatibility.

ON OCCASION, the value names used by these new ActionTypes
will happen to be the same as the ones used by their parent triggers themselves
(for example, ‘string A00’ is used both by ActionType 118 and CCreatureTrigger,
and do not have the same meaning).
In these cases, you MUST put different ActionType calls with
their respective values in separate Action00, Action01, etc. groups. As a general rule,
it is a good idea to put ALL ActionType calls in separate groups with their values, because it can be
hard to pinpoint bugs related to script value mixups in triggers.

Unless otherwise specified, all T-Script values other than the ActionType ID integer
are optional.

Please refrain from using ActionTypes without valid parameters.
If the ActionType values dictate no real-time action upon
call, space will still be allocated for the ActionType object.
This is often of no impedance to general gameplay, but will simply waste
memory.

Lastly, all new ActionTypes and values will conserve the current
T-Script entry names and values throughout all DLL updates.
ActionTypes and values may be added, but none of the existing
ones will be modified (though recommendations may be made relating
to functionality and also changed periodically). So far, the only
exception to this has been a modification of the default “LoopCount”
value for AT105 in ATX v1.50 (changed from true to false).

Note: Do not include brackets.

- ActionType 100 – MatrixTres effect with Timer

- ActionType 101 – Set new game speed

- ActionType 102 – Set New Map (for all map displays henceforth)

- ActionType 103 – Reload Anne’s currently active gun(s) (no animation)

- ActionType 104 – Modify Anne’s health (no voiceovers)

- ActionType 105 – SMK Video Playback

- ActionType 106 – Load New Hint (viewable via F1 key)

- ActionType 109 – Set CParticles Colors (CStartTrigger only)

- ActionType 110 – Set Object Fixed Speed

- ActionType 111 – End Object Fixed Speed

- ActionType 112 – Set Mouse/Keyboard Input State

- ActionType 113 – Set Player AIType

- ActionType 114 – Randomized Instance Teleport

- ActionType 115 – Use Object (a.k.a. Fire Gun)

- ActionType 116 – Force Dino Jump

- ActionType 117 – Initiate Particle Effect

- ActionType 118 – Swap Instance Texture

- ActionType 119 – Set Rain Effect (Experimental)

- ActionType 120 – Set Trigger FireCount and Probability

- ActionType 121 – Reload Standalone Gun

* See REFERENCING ANIMATE PHYSICS SUB-OBJECTS BY STRING
for info on how to reference specific animal parts by name in T-Scripts, such
as when trying to attach CEntityAttached instances to them.

!!!! IMPORTANT NOTE FOR CStartTriggers !!!!

(does not apply to ActionType 109)

*** For those of you who would rather not read this text, the
basic message is: do not use these ActionTypes in CStartTriggers.
Use other types of triggers that can run at level start instead.

Unfortunately, CStartTriggers will only run once per level, that is,
only at the very first level load of the original scene file.
Savegames renamed as *.scn do NOT count as “original scene files”
in this case. Thus, if you load a TresEd-generated scene file,
save a game at level start and then replace the first scene file
with the renamed saved game, CStartTriggers will NEVER be run
in your level. CStartTriggers will also NEVER run when a user chooses
the “Restart Level” menu option (whether the base scene file
was an original or not). However, this does not necessarily
affect the original game level settings, as explained later.

In order to have a trigger _truly_ run at level start and at every
level restart successfully (excluding the loading of a savegame where the
player does not start at the start area), you should use CLocationTriggers
instead of CStartTriggers. Simply place such a trigger directly
around the player’s start position (with the player inside
the trigger at level start) and make sure to specify
the following script values in the trigger’s script:

{
string Class = "CLocationTrigger"
int FireCount = -1
bool PlayerInTrigger = true	(do not use PlayerEnterTrigger)
...
}

If set up in this fashion, the trigger will run everytime the
player steps inside it, so you should be careful as to make
sure the changes you make will not cause problems if the player
decides to step back into the start area included in the trigger’s
geometry. Any other type of trigger that can be set up to run
at every level start and restart will also do just fine.

Trespasser will save most of its internal values to its
savegames, and for the most part, values set by CStartTriggers
in the original levels will be re-applied when the savegame
is loaded. This includes sky data, fog data, etc.
Because of this behaviour, there are few cases where not having
CStartTriggers run at level restart/savegame load will cause problems if you
consider only the original game levels and settings.

However, as described, the ActionTypes functions themselves will not be called when
loading such savegames, only the predefined values that they
set that had been saved will be applied.
Because of this system, most of the new ATX ActionTypes
found below will not work properly with CStartTriggers, because
they will only run once, and never for savegames or *.scn files
recompiled as savegames. As such, the effects of these ActionTypes are not saved in
Trespasser’s savegame system (despite near-perfect integration). For these,
it is STRONGLY RECOMMENDED to use CLocationTriggers as described above
or some other variant (perhaps CTimerTriggers, as was suggested to me).
In fact, IF YOU USE ANY ONE OF THE DESIGNATED NEW ACTIONTYPES AT LEAST ONCE IN YOUR
LEVEL, YOU SHOULD SET AN INITIAL VALUES WITH A CLocationTrigger or equivalent trigger.

As for savegames, because the state of these ActionTypes is not included in the normal
Trespasser savegames, they must be saved explicitly by ATX using
a second saving system. However, not all can be saved; those
that are recorded are designated in their respective descriptions
below. Some are explicitly marked as impossible to save. Others
are undefined or untested.

On a last note, it should be noted that you should always use
the FireCount setting of the new ActionType’s parent trigger
to designate how many times the trigger and ActionType should
be run. By contrast, several of the new ActionTypes below provide a run-count
setting. I failed to mention that these were mostly provided
for testing purposes and would not always record properly in savegames
or in specific circumstances. I apologize for the inconvenience
this (as well as the CStartTrigger issue) may have caused.

ActionType 100 – MatrixTres effect with Timer

group Action00 = {
int ActionType = 100
int Interval   = [duration of MXT effect, in milliseconds]*
float Speed    = [speed to use during timed MX effect]**
bool Frame     = [should this action type be run only once for this entry?]***
int X	       = [duration of linear transition at start of MXT effect, in milliseconds]****
int Y	       = [duration of linear transition at end of MXT effect, in milliseconds]*****
}
* default  = 4500 (not affected by ATXconfig.ini)
** default = 0.300000 (not affected by ATXconfig.ini)
*** default = false (Note: the parent trigger's FireCount setting should be used instead)
**** default = 0 (no transition)
***** default = 0 (no transition)

This ActionType slows the game to a certain speed for a certain amount
of time determined by the Interval parameter. It has the same effect
as the actual “MatrixTres” hacked executable. Once the interval is
done, the game will revert back to the game speed that was before the
call to this ActionType, which is the normal game speed value that
can be defined using ActionType 101.

As of ATX 1.50, this ActionType accepts two extra values, X and Y. These
are integer time values that determine the duration of the game speed
variation transitions at the beginning and/or at the end of the slowdown
effect. These values are equivalent to the ATXconfig.ini entries
MXTEnterTransitionInterval and MXTExitTransitionInterval, respectively.
In short, they will provide a smooth or smoother transition between
the two game speeds by calculating in a linear fashion and applying
intermediate game speeds using the specified time settings.

It should be noted that the X and Y settings were optimized mostly for
use with the Matrix Effect ATX feature, that is, with constant settings
across many ActionType 100 calls. If you intend to use this feature in
a level, it will work properly, but you should ensure that it is not
possible for the user to trigger an ActionType 100-based trigger while
another is already in effect. Game speed changes may otherwise not
be smooth as expected.

This state if this ActionType can not and thus will not be saved in savegames.
It will also unfortunately not distinguish whether the user is in-game
or browsing the game menu, which will cause time counters to run even
when the user is not momently playing.

Note: Game speed changes do NOT apply to any ATX-based features which rely
on time values. Use carefully when mixing with other time-dependent features.

-> This action can also be set to be used internally on ActBite (via ATXconfig.ini entry MXTB).

ActionType 101 – Set new game speed

group Action00 = {
int ActionType = 101
float Speed    = [new game speed to use (absolute)] *
bool Frame     = [should this actiontype be run only once for this entry?] **
}
* default = 0.300000 (can be changed via INI file)
** default = false (Note: the parent trigger's FireCount setting should be used instead)

This simply sets the game speed to a certain value, which becomes the
‘normal’ game speed until it is modified again using this function.
This ActionType can be used to slow down the game inside a specific
location, for example, using boolean values “PlayerEnterTrigger” and
“PlayerLeaveTrigger” in CLocation triggers. As explained above, this
function also dictates the return speed value for ActionType 100, as
well as the normal “BIONICWOMAN” cheat return speed.

Note: Although the game speed is changed globally, when a new level
is loaded or if the current level is re-loaded, the original game speed
(as defined in the EXE or in ATXconfig.ini) is reset by ATX. Also,
this ActionType has priority over the NormalGameSpeed setting found
in ATXconfig.ini, as well as the EXE’s default game speed.

As of ATX 1.50, game speed changes affected by this AT will be saved
in ATX-based savegames. This behaviour can be overridden in ATXconfig.ini
(by preventing game speeds from being loaded from the savegames).

Note: Game speed changes do NOT apply to any ATX-based features which rely
on time values. Use carefully when mixing with other time-dependent features.

ActionType 102 – Set New Map (for all map displays henceforth)

group Action00 = {
int ActionType	= 102
string Sample	= [specifies a bitmap (*.bmp) file to use as
		   map to display player location]*
float XPos	= [X position for top-left corner of map]**
float YPos	= [Y position for top-left corner of map]**
float X 	= [X position for bottom-right corner of map]**
float Y 	= [Y position for bottom-right corner of map]**
}
* default	= (none)
** default	= 0 (no use to specify)

This will load a bitmap-format map to later be displayed by the
MAP cheat. It automatically replaces any previously loaded map
for viewing. It can be used to load a map for a certain level at
start, and/or change this map once the player reaches a certain
point in the level*.

The bitmap’s resolution/size is customizable. Location values will
be calculated in real-time and converted in proportion to the file’s
size and anchor values. The horizontal lines of the BMP relate to the
player’s X position, while the vertical parts relate to the player’s
Y position. The function assumes that the map is aligned with the
level’s/game’s X axis and Y axis. The function will not work properly
with maps that do not follow this rule. It is the designer’s
responsibility to ensure that his or her map is properly oriented and
is proportioned to the XPos, YPos, X, and Y values.

The bitmap’s file name can, theoretically, be a maximum of 79 bytes,
including extension.

If the bitmap cannot be loaded due to memory contraints or other
reasons, a “no bitmap” message will be displayed. I have only tested
24-bit color BMPs that were created using MSPaint to work with this
function, but any program that can save the same types of bitmaps
should work.

* IMPORTANT: DO NOT INCLUDE PATHS. ALL BITMAPS SHOULD BE REFERENCED
DIRECTLY AND PLACED IN THE “MAPS\” FOLDER.

If you are switching maps in a level, one general tactic is to use CLocationTrigger “walls”
for every portion of the level that requires a new map, each with unlimited Firecounts,
and a more geometric trigger for the initial map-set location trigger of the level (at level start).
This way, if the played decides to go back in the level or restart, he
will inevitably have to pass through the last “wall” and reload the previous
map; or, if he restarts the level, he will enter the initial trigger and load
the initial 2D map.

This ActionType’s effects are preserved in ATX-based savegames.

ActionType 103 – Reload Anne’s currently active gun(s) (no animation)

* This AT has been updated in ATX 1.59.

group Action00 = {
int ActionType	 = 103
int Ammo	 = [force number of rounds for current gun]*
int AltAmmoCount = [number of rounds to substract from MaxAmmo
		    before reloading]**
int LoopCount	 = [how many times should this same ActionType be run?]***
int Frame	 = [which weapon to apply ALL above settings to]****
string A00	 = [if present, only apply reload if gun instance matches this name or
		    any of the following names specified in the consecutive Axx strings]*****
string A01	 = [see above]*****
...
string Axx	 = [see above]*****
}
* default	 = (unused)
** default	 = (0 if Ammo unused)
*** default	 = -1 (no limit) (Note: the parent trigger's FireCount setting should be used instead)
**** default	 = 1 -> apply only to primary 'hand' weapon
 other values:	   2 -> apply to secondary weapon only
		   3 -> apply to both weapons
***** default	 = none (apply reload to any instances)

This will reload Anne’s currently active gun(s) using the gun’s/guns’
“MaxAmmo” value. If the extra entries are used, this value can
be overridden. The Ammo value supersedes the AltAmmoCount value.
Note that the AltAmmoCount can be a negative value that will instead
add to the “MaxAmmo” value (though not necessarily recommended in all
situations). Changes are only made to guns in the ‘hand’ and/or
holstered states that are present upon call. These values can also
be used to add more ammo than the gun’s original clip size would allow.

Naturally, however, there is no reloading animation, but the used
trigger could be programmed to play a voiceover as the reloading
is done. This action could be used to create “reload points” from
within a level, provided the level’s gun objects are properly set
(see below).

Note: The “Ammo” T-Script entry (not the one above) only appears to be
used in “CGun” classes where the “MaxAmmo” entry is not present. If
the latter is present, its value will overwrite the “Ammo” value.

However, if only the “Ammo” entry is present, the unused “MaxAmmo”
setting will still be present in the initialized class and WILL BE
SET TO 100. As a result, if this particular gun is reloaded with this
ActionType, it will contain 100 rounds and the voiceovers may not work
properly depending on the gun and other settings. Some default Trespasser
levels’ guns do not have the “MaxAmmo” value, and, as a result, should be
updated to use the “MaxAmmo” setting instead to ensure compatibility
with ActionType 103.

* ATX 1.59 adds A00, A01,…, Axx entries to this AT that allow you
to specify CGun instances to limit which weapon instances can be
reloaded by this triggered AT103 instance. If no Axx strings are
specified (the default setting), AT103 will reload any weapon the
player may be carrying. To restrict which gun instances may be reloaded
when the ActionType is fired, simply put their names after the Axx strings, such as:

- string A00 = “MyCGun01-00”

- string A01 = “Boom02-44”

- string A02 = “Bam09-36”

You may put as many of these instances as there are Axx strings (about 200).
The only restrictions are that the first instance must start with the A00 entry
and all the others (if any) must use Axx entries that are numbering consecutively.
ATX will stop scanning for instances as soon as it reaches a Axx number that
does not have an instance name. If you specify invalid instances, they will
be disregarded by ATX (no crash, but if not one of your instances is valid,
the ActionType will never reload).

ActionType 104 – Modify Anne’s health (no voiceovers)

group Action00 = {
int ActionType	 = 104
float Frame	 = [hit points to substract from Anne's current health]*
bool LoopCount	 = [should this action type be run only once for this entry?]**
}
* default = 0 (restore full health)
** default = false (Note: the parent trigger's FireCount setting should be used instead)

This ActionType will substract the specified number of hit points
from Anne’s health. If this value is negative, the hit points will
be added instead (obviously). If the specified number is 0, the
function will restore Anne’s full health.

This ActionType does not play any voiceovers. These would have
to be added separately using T-Script entries.

ActionType 105 – SMK Video Playback

group Action00 = {
int ActionType	 = 105
string Sample	 =

" -> NO EXTENSION OR BRACKETS]*
bool LoopCount	 = [should this actiontype be run only once for this entry?]**
}
* default = -1 (none)
** default = false (UPDATED: ATX 1.50, Dec 8, 2005)
	     (Note: the parent trigger's FireCount setting should be used instead)

This ActionType will play the specified SMK video in the
same fashion as the default game videos. It will halt gameplay
for the duration of play and end as soon as user input is
received. The emulated calls appear to work in all standard
video modes.

The only particularity is the video’s filename. The file MUST be placed
in the player’s “[TRES CD]\data” directory, preferably in
the “menu\” folder (if it is placed here, make sure to include
the directory in the path under the “Sample” string value as above).
It is also important that there be NO FILE EXTENSION added
to the “Sample” string and that the actual file ends with the
“*.SMK” extension.

If the demo executable is used, the video needs only to be placed
in the demo directory’s “data\” folder, again, preferably in the
“menu\” sub-folder.

Note: If the registry/INI entry “NoVideo” is set to 1, videos
called by this ActionType will NOT be played, along with any
other intro or in-game videos.

You should not attempt to use this trigger in a CStartTrigger (at all).

Note: The output of this ActionType is indirectly affected by the SMK VIDEO PLAYBACK RESIZING feature.

ActionType 106 – Load New Hint (viewable via F1 key)

group Action00 = {
int ActionType	 = 106
string Sample	 = "[starting string to display as new hint]" *
string Frame	 = "[string to append to first string]" *
}
* default = (none)

This ActionType will load the specified string as the new “hint”
which is displayed when the player presses the F1 key. Carriage
returns are done automatically. String length is not that much of
an issue, but it is not recommended to store more than 3-5
lines of text in a single hint. The Sample entry must be present to
show the new cheat. The optional Frame string, if present, will be
appended to the Sample string. The latter is provided to
counter a possible bug in TresEd when entering longer strings. There
is no difference in the display of either string other than order.

Note that the game’s internal string buffer can hold up to 1023 bytes
of text, but it is not recommended to use that much lettering. Also,
an extra space character will be placed between the Sample and Frame
strings (if applicable).

Note: In order to avoid compatibility problems and erronous text display,
if you use this ActionType in a level, you should not use the old ActionType
to set hints.

As of ATX 1.50, the currently displayed hint as set by AT106 will be
saved in ATX-based savegames.

ActionType 107 – ATXDRV Mode Start

group Action00 = {
int ActionType	 = 107
string Target	 = "[target instance or instance to affect - object must exist]" *
}
* default = (none)

Reserved for author testing. Do not use.

Author’s note to self: Target object’s front should be aligned with/facing toward the
positive end of the Y axis (facing “0.0, 1.0, 0.0”) when it is imported
(TresEd-based rotation can then be performed without affecting this).

ActionType 108 – ATXDRV Mode Stop

group Action00 = {
int ActionType	 = 108
(no other values may be specified for this ActionType)
}

Reserved for author testing. Do not use.

Author’s note to self: Can also be stopped by user via [HotKeys] in ATXconfig.ini.

ActionType 109 – Set CParticles Colors (CStartTrigger only)

group Action00 = {
int ActionType	 = 109
string Sample	 = [specifies name of particle type to update color] ***
int R		 = [red intensity of color to set; 0 to 255] *
int G		 = [green intensity of color to set; 0 to 255] *
int B		 = [blue intensity of color to set; 0 to 255] *
}
* default = 0 (zero intensity for this component)
*** default = none (no action)

This ActionType will set the particle type referenced by the
Sample string to the 24-bit color specified by the R, G, and B
values. The particle type string will typically be one of the following:

- * “Blood”

- * “Bleed”

- * “Water”

- * “Terrain”

- * “Terrain – Sand”

- “Animate”

- “Terrain – Concrete”

- * “Metal Hard 1”

- “Metal Dull 2”

- “Oil Barrel 1”

- “Terrain – Metal”

The types marked with an asterix (*) compose the 6 default particle
types initialized by the game. You should make sure the names are
exactly as written above, with the the capitalization and not adding
extra spaces. Failure to do so will cause the game to (most likely)
allocate new useless instances that will waste memory. I should note
that the game disregards capitalization internally for all particle
names (note that this is confirmed only for particle names), though you
should follow capitalization as above to stay on the safe side.

IMPORTANT NOTE

In order to avoid savegame and level restart issues, this ActionType
was designed SOLELY to cooperate with CStartTriggers. This ActionType will
always launch upon level load (it is “hacked” CStartTrigger-dependent AT).
You should not try to have more than one color assignment
per CParticle type per level, simply because there is no point to this.
Simply use this ActionType as if you were specifying a new CParticles class,
but in a CStartTrigger encapsulation and with the script entries described above.

ActionType 110 – Set Object Fixed Speed

This ActionType has been updated in ATX 2.00.

group Action00 = {
int ActionType	 = 110
string Sample	 = [specifies instance to apply fixed speed to] *
float X 	 = [X-component of speed to use] **
float Y 	 = [Y-component of speed to use] **
float Z 	 = [Z-component of speed to use] **
int Interval	 = [time during which to keep applying fixed speed, in milliseconds] ***
bool Frame	 = [determines behavior if object was already in fixed-speed mode upon call] ****
string TeleportDestObjectName = [optional; name of instance who's orientation is to be direction of speed] *****
float Speed		      = [optional; total speed to use if TeleportDestObjectName instance is specified] ******
}
* default = none
** default = 0.000000
*** default = -1 (no time limit)
**** default = true (always force new settings)
***** default = none (always use specified X, Y, Z values)
****** default = none/0.0 (always use specified X, Y, Z values if no instance/use 0.0 if instance found)

ActionType 110 is a variation of ActionType 10. In fact, it has almost the
same effect as calling ActionType 10 with bool Impulse = false,
bool Frozen = false, and the X,Y,Z speed settings set (as float values). The difference is
that ActionType 110 will reset the object’s speed as specified at every
frame for the period of time defined by Interval (or indefinitely if set to -1).
This will prevent the game from applying gravity to the object, which is the
main purpose, and also generally remove physics interaction for the object.

The ActionType will stop renewing the object’s speed once the time limit is
reached or when ActionType 111 is called. No collision detection will be
performed, so if the instance is not destined to follow a planned path,
its collision response will need to be managed with CCollisionTriggers
and ActionType 111.

The Frame boolean is used when ActionType 110 is called for an object that
was already in fixed speed mode when the function was set off once more. If
set to true, the new speed and interval values will immediately replace the
previous ones. If set to false, the function will have no effect and the
previous fixed speed mode will continue for the specified object.

ATX 2.00 introduces two extra optional parameters: TeleportDestObjectName
and Speed. These parameters replace the X, Y, and Z float settings if
declared. Instead of using a fixed direction for the velocity given
to the Sample instance, AT110 uses the orientation (facing) of the instance designated
by TeleportDestObjectName multiplied by the total speed value of Speed.
The source instance’s orientation is fetched in real-time at the time of the
AT114 call, so the assigned velocity will change (in direction only)
if the object is rotated during gameplay. However, assigned total Speed will
remain constant.

The state of this ActionType is saved in ATX 1.52 and higher-based savegames.

ActionType 111 – End Object Fixed Speed

group Action00 = {
int ActionType	 = 111
string Sample	 = [instance that is to stop receiving speed updates] *
}
* default = none

This ActionType is the conclusion to ActionType 110. It will cause the specified
object to lose its fixed speed and be treated as a standard unfrozen object
as before. It will not freeze or set the instance’s speed to zero.
For example, an flying object given a horizontal speed by AT110 and then targetted
by AT111 will not stop suddenly in flight, but will be affected by gravity once more
and interact properly with the physics engine (it will behave as if ActionType 10
had just been called on the object with the speed settings previously specified
in AT110). In short, when AT111 is called, it marks the final speed-set performed by AT110.

If you want the object to stop immediately after the end of the fixed speed
state, you should call ActionType 10 and specify the Target object as well as
bool Frozen = true and/or float X = 0.000000, float Y = 0.000000, float Z = 0.000000.

You would typically call this ActionType to mark the end of an object’s
fixed-speed trajectory or in a CCollisionTrigger upon collision with any object.
The latter is particularly important, because AT110 does not attempt to detect
collisions nor coordinate with the physics engine.

ActionType 112 – Set Mouse/Keyboard Input State

group Action00 = {
int ActionType	 = 112
int Frame	 = [specifies keyboard state to use] *
int LoopCount	 = [specifies mouse state to use] *
}
* default = -1 (not used/do not modify state)

ActionType 112 will set the state of in-game keyboard and mouse input. It
will not affect console input, menu controls, or any other feature-specific
input commands. It can, however, interfere with the FLY cheat and similar
cheats that disable keyboard commands and/or mouse input.

The value of the Frame integer determines the specific keyboard state to set,
while LoopCount does the same for mouse movement. Mouse clicks are included
in the Frame value as keyboard input and are not related to the LoopCount
setting. You can specify either or both settings in a single call to this ActionType.

Frame values (keyboard/mouse clicks):

- int Frame = 0 -> Disables all player keys and mouse clicks

- int Frame = 1 -> Enables all player keys and mouse clicks

- int Frame = 2 -> Enables all keys and mouse clicks, but disables movement keys (move and jump)

- int Frame = -1 -> No change to keyboard state or mouse clicks

LoopCount values (mouse):

- int LoopCount = 0 -> Disables in-game mouse movement

- int LoopCount = 1 -> Enables in-game mouse movement

- int LoopCount = -1 -> No change to mouse movement state

If you use this ActionType in your level, it is strongly recommended that you warn the user not
to enable cheats such as FOLLOWDINO, THIRDP, or FLY while the game is in play, or specify
the locations in which not to engage in the use of these.

The state of this ActionType is saved in ATX 1.52 and higher-based savegames.

ActionType 113 – Set Player AIType

group Action00 = {
int ActionType	 = 113
int Frame	 = [integer value to use for the player instance's AIType value] *
}
* default = 5 (standard player AIType)

This sets the AIType for the current player instance. You will typically set this
to 0 or 5, the first value being to hide the player’s AI presence, and the second to
restore it to a visible default. It is recommended that the user be warned not to use the
CLOAK or FLY cheats where this ActionType is used.

The state of this ActionType is saved in ATX 1.52 and higher-based savegames.

ActionType 114 – Randomized Instance Teleport

* This ActionType has been updated in ATX 2.09 (see near end of this section for added functionality usage).

Note: This ActionType is mainly functional, but still undergoing tests. Please
report any problems you run into (taking into account you’ve read this text).

group Action00 = {

int ActionType = 114

group A00 = { = MAIN GROUP. Declares instances to be teleported and basic info (REQUIRED)
int Frame = [number of A01…Axx LOCATION GROUPs to be used. Value must be between 1 and 199, inclusively] (REQUIRED)
int Sample = [number of instances to potentially teleport. Value must be between 1 and 199, inclusively] (REQUIRED)
string A01 = [first instance to teleport] (REQUIRED)
string A02 = [second instance to teleport] (MAY BE REQUIRED – DEPENDS ON Sample VALUE)
…
string Axx = [last instance to teleport, where xx = (int Sample value)] (MAY BE REQUIRED – DEPENDS ON Sample VALUE)
}

group A01 = { = LOCATION GROUP 1. first A01…Axx group containing possible locations for instances
int LoopCount = [probability of this group being selected during randomization when teleporting] (default = 0 = never use this group)
bool R = [if true, randomize the SUB-GROUP-to-instance assignments within this location group only, if and after this group is chosen]***

group A01 = { = SUB-GROUP 1. If LOCATION GROUP 1 is selected by randomization,
this A01 sub-group will give the position for the A01 instance defined in the MAIN GROUP.
string TeleportDestObjectName = [name of object of which to use position/orientation] **
float X = [if TeleportDestObjectName is omitted, use this value as instance’s X position] **
float Y = [if TeleportDestObjectName is omitted, use this value as instance’s Y position] **
float Z = [if TeleportDestObjectName is omitted, use this value as instance’s Z position] **
float XFree = [if TeleportDestObjectName is omitted, use this value as instance’s X orientation, in Euler angles] **
float YFree = [if TeleportDestObjectName is omitted, use this value as instance’s Y orientation, in Euler angles] **
float ZFree = [if TeleportDestObjectName is omitted, use this value as instance’s Z orientation, in Euler angles] **
bool SetPosition = [if true, use position values when affecting instance, either from TeleportDestObjectName or from X, Y, and Z values] *
bool SetOrientation = [if true, use orientation values when affecting instance, either from TeleportDestObjectName or from XFree, YFree, and ZFree values] *
bool OnTerrain = [if true, teleport instance on terrain] *
bool HeightRelative = [also same as ActionType 18] *
}

group A02 = { = SUB-GROUP 2. This is the same as SUB-GROUP 1, but the values used
here will give the position for the A02 instance defined in the MAIN GROUP.
(…)
}

(…)

group Axx = SUB-GROUP xx. This is the same as the above SUB-GROUPs, but will assign
a position to whatever instance is referred to by the Axx name in the MAIN GROUP.
(…) The value of xx should be between 01 and the value defined by the Sample entry in the MAIN GROUP.
}

}

group A02 = { = LOCATION GROUP 2. This is the exact same as LOCATION GROUP 1, but
may contain different sets of positions so that if the randomizer
selects this group, different positions will be given to the same instances from MAIN GROUP.
(…)
}

(…)

group Axx = { = LOCATION GROUP xx. This is simply another LOCATION GROUP. There can be as many
LOCATION GROUPs as the number defined by the Frame value in the MAIN GROUP. Thus,
the value of xx in this case must be between 01 and the value of the Frame entry, inclusively.
(…)
}

}

* default = true (same as ActionType 18)
Note: Default ActionType 18 values for these booleans for all 1.1-patched Trespasser
executables are set to TRUE, and not to FALSE, as might have been believed.
If SetPosition and SetOrientation are both set to false, the entire SUB-GROUP will be ignored.
** default = Checks for presence of TeleportDestObjectName object. If the entry is omitted
or if the object does not exist, checks for and uses X, Y, Z, XFree, YFree, and/or ZFree values
for position/orientation, depending on which boolean values are enabled.
TeleportDestObjectName is never used at the same time as the aforementioned position/orientation
values within the same SUB-GROUP.
If TeleportDestObjectName is not found AND if at least one of the required position/orientation
entries is not found (also depending on set boolean values), the entire SUB-GROUP
will be ignored. Thus, if boolean value SetPosition is set and one of the X, Y, and Z values
is absent as well as TeleportDestObjectName, the group will be ignored. The same goes
for SetOrientation and XFree, YFree, and ZFree.
For example, in order to teleport an object using only position values, you must
omit TeleportDestObjectName, explicitly set SetOrientation to false, and ensure
that the X, Y, and Z values are present and valid (leaving XFree, YFree, and ZFree present
will have no effect). This is only true because the default value of
SetPosition is true.
*** default = false (use standard AT114 behavior with numbered SUB-GROUP-to-instance assignments)

* Note: Axx named strings range between A00 and A199 (inclusively). Names with numbered labels
lower than 100 must have at least two characters (padded with 0 to the left if necessary, i.e., A01),
and names with over 100 must have exactly three characters.

This ActionType is a variation of ActionType 18, “Teleport Instance”. It uses almost
the same basic parameters, but can also teleport multiple instances (up to 200) as well
as randomly select from sets of destination locations (up to 200 sets, which each
set containing up to 200 locations, one for each instance). Randomized locations
are grouped into these sets so that randomized teleportation will be done in patterns,
contrary to the ATX Instance Randomizer, which selects random values for each instance
individually (regardless of where other instances are teleported).

The definition for ActionType 114 starts off with a group labeled A00, placed
in the same group as the “int ActionType = 114” entry. This group is the MAIN GROUP;
it determines the instances that are to be teleported and the number of location
sets to use. Within this MAIN GROUP are Frame and Sample values which determine
the number of location sets (LOCATION GROUPs) and the number of instances to
teleport, respectively. Following these values should be a series of consecutively-named
strings, A01, A02, A03, etc. (A00 is unused) These strings define the names of
the instances to teleport. There should be exactly as many strings/instances as
the number you define with the Sample value, and the instances must exist.
The order in which the instances are named (i.e., which Axx string they are
each associated with) will later determine which locations to assign to which instance.

Following the MAIN GROUP are a series of consecutively-named LOCATION GROUPs,
A01, A02, A03, etc. (A00 is the MAIN GROUP). These are in the same group as
the definition for the MAIN GROUP and the line “int ActionType = 114”. While
it is not strictly required, you should always have the same number of these
groups as the value you defined with the Frame value in the MAIN GROUP.
Each LOCATION GROUP group can hold a LoopCount value and a variable number
of Axx SUB-GROUPs, up to as many of these as there are instances defined
in the MAIN GROUP.

In this context, a LoopCount value is an int that defines the probability
that this specific LOCATION GROUP will be chosen when the ActionType goes off,
out of all the LOCATION GROUPs that have these values defined.
Its default value is 0, which means ‘never choose this group’. Thus, if
you do not include a LoopCount entry with a value above 0, this entire LOCATION GROUP
will appear as non-existent.

The total probability value from which a certain group-associated LoopCount value will be selected
is calculated by adding the LoopCount values of every defined LOCATION GROUP.
This way, you can set the total and proportions for these probabilities manually.
For example, if you have four LOCATION GROUPs, A01, A02, A03, and A04, you could
define the values for each of their LoopCount entries as 4, 7, 1, and 3, respectively.
In this case, the total probability value will be (4+7+1+3) = 15.
This value is calculated implicitly, i.e., you do not have to set it anywhere.
With a total value of 15, the LoopCount value 7 has the most importance, and thus
LOCATION GROUP A02 will have the best chance of being picked, while the LoopCount
value 1 (which is the minimum allowed value other than 0) gives LOCATION GROUP A03
the least chance of being picked. If you set the values to 1, 1, 1, and 1 or
2, 2, 2, and 2 (or some other set of equal values), then all LOCATION GROUPs have
the same chances for selection when AT114 is triggered. According to your preferences,
you could even simply put the total out of 100, i.e., set values 25, 25, 25, and 25, and
start adjusting from there. In practice, all LoopCount values should be between
1 and the total probability value you’re adding up to, inclusively. You may use
the value 0 for diagnostic purposes (i.e., for disabling groups to test specific
sets of position values).

You could also simply use AT114 to teleport many instances but without randomization.
In this case, you would need only one LOCATION GROUP (A01) and assign it a LoopCount
value of 1 (or higher – will make no difference).

Every LOCATION GROUP can then hold (as mentioned) a variable number
of Axx SUB-GROUPs, up to as many of these as there are instances defined in the MAIN GROUP.
SUB-GROUPs hold the position/orientation values, destination objects, and teleportation
settings for certain instances, in the same fashion as ActionType 18.
Every SUB-GROUP and its position values, within this LOCATION GROUP, are assigned to a
certain instance defined in the MAIN GROUP: the MAIN GROUP instance with the entry name
of A01 is assigned to SUB-GROUP A01, instance string A02 is assigned to SUB-GROUP A02, etc.,
all the way to the last instance’s entry number.

For example, if you have the following entries defined in your MAIN GROUP:

int Sample = 2
string A01 = "MyInstance00-00"
string A02 = "MyInstance00-01"
Your LOCATION GROUP(s) could look like this (where xx = LOCATION GROUP number):
group Axx {
      int LoopCount = 1
      group A01 = {
	    (position values for MyInstance00-00)
      }
      group A02 = {
	    (position values for MyInstance00-01)
      }
}

SUB-GROUPs are completely optional. If there is no SUB-GROUP for a certain instance
in a certain LOCATION GROUP, if this LOCATION GROUP is selected at run-time, the
instance will simply not be teleported. For example, you could simply leave a
LOCATION GROUP without any SUB-GROUPs, and when selected, no instances would be
teleported. This can be useful if you have a scenario where you want to teleport
instances but, say, only 50% of the time. In such a case, you could have one
LOCATION GROUP with valid destination positions and a LoopCount of 50, and then
have a second LOCATION GROUP holding only a LoopCount value of 50. If the first
group is selected, the corresponding SUB-GROUPs and their positions will be applied
to the instances, and if the second is selected, no instances will be teleported.

SUB-GROUPs themselves hold values similar to ActionType 18 (AT18), but also add the possibility
of inputting position/orientation values directly, without having to specify
a destination object. First, as in AT18, you can specify the bool values
SetPosition, SetOrientation, OnTerrain, and HeightRelative. It is important to
note that these values are TRUE by default. If you do not wish to use one of
them, you must explicitly set it to FALSE. Also, ATX requires that either
SetPosition, SetOrientation, or both be set to TRUE for every SUB-GROUP, or an
error will be generated. As for the four values’ usage, if you use a
destination object, then these have the exact same meaning as if they had been set
by AT18. If you use raw position/orientation values instead of a destination object,
you must explicitly set the SetPosition and SetOrientation bools according to the
values you have supplied (discussed next).

In order to use a destination object for the destination location of an instance,
you simply need to specify the name of the object in the SUB-GROUP such as:
string TeleportDestObjectName = “MyDestObject00-00”
It will generally behave in the same way as if it has been specified using
the AT18 TeleportDestObjectName entry. There is, however, one difference:
while the game fetches the destination object’s position during level load,
ATX does this in real-time. This would imply that if you specified a destination
object with AT114 and it had moved during gameplay, the teleported instance would
also teleport to a different location than if it had been specified using AT18.
In practice, however, destination objects never move in a level, which discards any
noticeable difference.

If you omit the TeleportDestObjectName, then you must specify all three values
for at least one of the following groups of float entries:

X, Y, and Z or

XFree, YFree, and ZFree

Here, floats X, Y, and Z are direct position values. These are the same coordinates
that you would specify using “Instance Properties” in TresEd or with the Instance
Randomizer.

Floats XFree, YFree, and ZFree are a more recent addition. These hold the
Euler angle rotation values to set for the teleported instance. These are the same
as the angles you would specify under “Instance Properties” in TresEd when
rotating an object.

As noted, if you use the X, Y, and Z or XFree, YFree, and ZFree entries, you
absolutely must set the SetPosition and SetOrientation booleans accordingly.
For example, if you use only X, Y, and Z, you must explicitly set:

bool SetOrientation = false

Because all four booleans are TRUE by default, if you attempt to use only X, Y, and Z
without setting SetOrientation to FALSE, ATX will assume TRUE and look for
the XFree, YFree, and ZFree entries, eventually failing and causing an error.
The same goes for setting only the XFree, YFree, and ZFree entries. Note, however,
that there is no harm in setting extra values. For diagnostic purposes, you
may want to disable orientation forcing but still leave all 6 floats in your
SUB-GROUP as to not have to delete them. In this case, you can simply
specify SetOrientation = false without removing any values.

In general, using X, Y, Z, XFree, YFree, and ZFree values is more efficient
than using a TeleportDestObjectName object, because the game then has one
less object to manage. In practice, however, it might not always be tempting
to copy-paste location and orientation values, and so TeleportDestObjectName
is still fully implemented into AT114.

ActionType 114 has a built-in partial error checker. While it will not detect
invalid destination values or all possible issues, it will try to find
basic errors that may prevent AT114 from working properly. If the game
crashes during level load, make sure to check ATX_LOGFILE.txt to see
if there may be any AT114-related details. AT114 can also crash in-game (upon trigger).
If one of the TeleportDestObjectName objects is invalid, a message will
be printed to ATX_LOGFILE.txt. However, if one of the source instances from
the MAIN GROUP is invalid, you will not get an error message, because
ActionType 18 is internally used to process these in real-time.

The following is an example of an ActionType 114 instance incorporated
inside a CLocationTrigger. The example is commented; anything in a
line that comes after (and including) “//” is not part of the script and
should not be included.

group Trig_MyLocationTrigger = {
    string Class = "CLocationTrigger"
    int BoundVol = 1
    int FireCount = -1
    int AlphaChannel = 0
    group Action00 = {
	int ActionType = 34
	string OverlayText = "Oh no, ambush!"
    }
    group Action01 = {
	int ActionType = 114

group A00 = { // MAIN GROUP
int Frame = 5 // 5 LOCATION GROUPs to choose from, 5 possible sets of location values
int Sample = 4 // 4 instances to teleport, potentially
string A01 = “MyInstance00-01” // names of instances to teleport (case-sensitive, as always)
string A02 = “MyInstance00-02”
string A03 = “MyInstance00-03”
string A04 = “MyInstance00-04”
}

// note: total probability count here is: 20+15+40+20+5 = 100

group A01 = {
int LoopCount = 20
// this LOCATION GROUP, if selected, will teleport
// all 4 instances to different locations using different methods.
group A01 = { // this SUB-GROUP is assigned to “MyInstance00-01”
string TeleportDestObjectName = “MyDest1ForInstance00-01”
bool OnTerrain = false // all other bools will be true
bool SetOrientation = false
}
group A02 = { // this SUB-GROUP is assigned to “MyInstance00-02”
string TeleportDestObjectName = “MyDest1ForInstance00-02”
}
group A03 = { // this SUB-GROUP is assigned to “MyInstance00-03”
float X = 234.000000 // teleports directly to this position, but keeps instance’s orientation
float Y = -3.000000
float Z = 0.400000
bool OnTerrain = false
bool HeightRelative = false
bool SetOrientation = false // this is required, since no XFree/YFree/ZFree
}
group A04 = { // this SUB-GROUP is assigned to “MyInstance00-04”
float X = 3435.000000 // teleports to this position with OnTerrain setting (since default = true)
float Y = 5555.000000
float Z = -9.00000
float XFree = -20.000000 // uses these angle orientation values when teleporting instance
float YFree = 87.000000
float ZFree = -0.770000
}
}

group A02 = {
int LoopCount = 15
// this group, if selected, will only teleport “MyInstance00-04”
group A04 = { // this SUB-GROUP is assigned to “MyInstance00-04”
string TeleportDestObjectName = “MyDest2ForInstance00-04”
bool SetOrientation = false
bool SetPosition = true // not necessary since default is TRUE, but does no harm
}
}

group A03 = {
int LoopCount = 40
// this group, if selected, will only teleport the first two instances
group A01 = { // this SUB-GROUP is assigned to “MyInstance00-01”
float X = -333.000000
float Y = 55.000000
float Z = -6.00000
float XFree = 120.000000
float YFree = 0.000000
float ZFree = 0.000000
bool OnTerrain = false
bool HeightRelative = false
}
group A02 = { // this SUB-GROUP is assigned to “MyInstance00-02”
string TeleportDestObjectName = “MyDest2ForInstance00-02”
}
}

group A04 = {
int LoopCount = 20
// this LOCATION GROUP has no SUB-GROUPs. If it is selected
// by the randomizer, none of the “MyInstance00-0x” instances
// will be teleported. Since LoopCount is 20 and total is 100,
// when the ActionType is triggered, there will thus be
// a 20% chance that no instances will be teleported.
}

group A05 = {
int LoopCount = 5
// this is a variation of LOCATION GROUP A01, but doesn’t teleport second instance
// the destination locations for the two last instances are the sameas LOCATION GROUP A01
group A01 = { // this SUB-GROUP is assigned to “MyInstance00-01”
string TeleportDestObjectName = “MyDest2ForInstance00-01”
bool OnTerrain = true
bool HeightRelative = true
bool SetOrientation = true
bool SetPosition = true // none of these are necessary, but again, may help keep script clear and readable
}
group A03 = { // this SUB-GROUP is assigned to “MyInstance00-03”
float X = 234.000000 // teleports directly to this position, but keeps instance’s orientation
float Y = -3.000000
float Z = 0.400000
bool OnTerrain = false
bool HeightRelative = false
bool SetOrientation = false // this is required, since no XFree/YFree/ZFree
}
group A04 = { // this SUB-GROUP is assigned to “MyInstance00-04”
float X = 3435.000000 // teleports to this position with OnTerrain setting (since default = true)
float Y = 5555.000000
float Z = -9.00000
float XFree = -20.000000 // uses these angle orientation values when teleporting instance
float YFree = 87.000000
float ZFree = -0.770000
}
}

}
}

*** In ATX 2.09, an extra boolean R value has been added directly inside the LOCATION GROUPs. If set to true, when the randomizer
selects this LOCATION GROUP to assign SUB-GROUPS (locations) to the instances, it will NOT assign its SUB-GROUPs to the instances
with the same corresponding AXX name indices (i.e., not the same order of appearance). Instead, it will assign each instance
to a random SUB-GROUP within the LOCATION GROUP and apply this SUB-GROUP’s parameters to it (i.e., teleport it to the placeholder object, to the specified
X, Y, Z, or do nothing if it does not exist). Each instance is guaranteed to receive a different SUB-GROUP. This allows using AT114 to
teleport a number of objects to a same (or lesser) number of locations while randomizing these locations each time. Without this option,
you would be forced to manually create a number of pseudo-random location patterns (tons of LOCATION GROUPs) to simulate
this sort of many-to-many random selection. Also noteworthy is that the boolean R is found inside the LOCATION GROUP definition,
so you can have some LOCATION GROUPs internally randomized and others not, and use these two levels of randomization to create
extra un-predictability.

ActionType 115 – Use Object (a.k.a. Fire Gun)

group Action00 = {
int ActionType	     = 115
string Target	     = [Name of instance to 'use']
bool Sample	     = [if true, do not automatically decrease ammo and no voiceovers if CGun instance] *
bool LoopCount	     = [if true, decrease ammo 'manually' at each AT115 launch if CGun instance] *
bool Interval	     = [if true and LoopCount is true, omit gun 'click' when out of ammo]
bool Frame	     = [if true, do not send CMessageUse message for each AT115 launch] *
}
* default = false

This AT will simply call the “Use” method for the instance specified in the Target
string. Different objects will handle this method differently. For CGun instances,
this means effectively firing the gun and decreasing the ammo count. Recoil and
other factors will be applied by the game.

There is one annoyance related to firing a gun with this AT: the game always treats
it as if it was fired by Anne. That means that it WILL play voiceovers for ammo count
and will also naturally decrease ammo count. To overcome this, you can set bool Sample = true,
which will toggle a quasi-WOO cheat temporarily for this function, which will nullify
both of these factors. If you still want ammo count to decrease but without voiceovers,
then you must also set bool LoopCount = true. If LoopCount is set to true, you
can also set bool Interval = true to disable the gun ‘click’ when it is out of
ammo. You cannot use the Interval boolean if LoopCount is not enabled, and it is
not recommended to use LoopCount = true if bool Sample is not set to true.

The last setting is the Frame bool. If set to true, the function will omit sending
the CMessageUse setting and incrementing the message count when AT115 is launched,
that is after performing the main ‘use’ method on the instance. This is a simple
technical source-level issue that may however cause the game to respond differently.
It is currently unknown whether sending this message is required for any or all
instances, so you may have to experiment with this setting if you experience
problems.

ActionType 116 – Force Dino Jump

group Action00 = {
int ActionType	     = 116
string Target	     = [Name of dino to induce jump upon]
float Push	     = [Force to give dino as jump push] *
float Frame	     = [Jump angle for dino] *
}
* default = 0.000000

A very simple ActionType. Will immediately force the dino to jump upon
launch, unconditionally. You must specify a valid CAnimal instance via
the Target script, as well as valid Push and Frame (angle) values, or
no action will be performed. The Push and Frame values are the equivalents
of the ActJumpNew Push and JumpAngle values, respectively.

This ActionType will not affect the dino’s regular jumping behaviour,
so it is possible that normal jumping coincides with jumps initiated
by this AT. Also note that this AT will launch regardless of whether
or not jumping dinos are disabled globally in user settings, and regardless
of any possible ActJumpNew settings, effectively bypassing any values
that may be set in the same dino’s *.ini settings.

ActionType 117 – Initiate Particle Effect

group Action00 = {
int ActionType	     = 117
string A00	     = [Name of particle type to display] *
string Sample	     = [Name of object of which to use location and orientation for particle effect] *
float Frame	     = [Misc. parameter] **
float Threshold      = [Threshold to use for effect display] ***
}
* default = none
** default = 1.000000
*** default = 0.500000

This AT can initiate a particle effect, of the same sort as the dust, blood, zap spark, and
other particle types the game usually emits automatically (upon collisions). It will work with any of the
game’s default effects, and of course with any custom CParticle effects you may define in
your level.

The A00 string should be set to the name of the particle effect to be used. This is the name
that is usually defined using ‘string A00 = “…”‘ in CParticles classes, i.e., “Default”,
“Terrain”, “Cattle Prod”, etc. It can be the name of your own CParticles object’s name string with your
own set of defined values, or one of the game defaults such as blood or dust. The full
list of names for the defaults can be found in the AT109 documentation.

The Sample string should designate the name of a valid instance in your level. Its center position will
be used as origin for the particle effect, and the direction of its Y axis (green in TresEd) will give the
direction for the effect in general. Note that some particle effects (such as dust) aren’t easily
influenced by direction. While it can be any valid instance, you would usually use a dummy object
similar to a teleport destination object (i.e., empty, untextured). ATX will fetch
the position and orientation values in real-time, so if your object moves (i.e., CEntityAttached),
the particle effect will follow it and always use its center location as origin.

The Frame and Threshold values are extra float parameters used internally. I am unsure about the exact nature
of the Frame value, but it is usually 1.000000 and it seems to control particle ‘density’ (more precisely,
it appears to be a multiple in the function’s calculation of how many single particles to generate). The
Threshold value is the Threshold that is passed to the particle display method in real-time by
the game. You can set this to whatever you please, as long as it falls within your particle
effect’s min and max settings for it. Some of the default game particle types seem to have their
min Thresholds set at 0.300000, so if you’re using one of those you might have to experiment
with slightly higher settings (this is why I set the default to 0.500000, though I’m not 100% certain
what the most adequate would be).

You can easily use triggers to create “fountain” effects with particles. A CLocationTrigger
with PlayerInTrigger = true, FireCount = -1, RepeatPeriod = (…), and ActionType 117 will
loop the particle display quite effectively.

Unfortunately, there are strong limitations to the particle system used by the game. For one,
particles effects don’t perform collision detection and will go “through” other object.

There’s also the major drawback that the renderer completely refuses to display these effects if their
point of origin (center location) isn’t within the camera’s FOV. Because of this, it is difficult
to create a large effect, since as soon as its source location is out of view, the entire effect
is neglected. This would of course have been instigated to help framerate, and the team probably never
expected these effects would grow larger than the typical blood squirts. It also happens that
as soon as an individual particle ‘strand’ in a particle effect exits the camera field-of-view, it
is deleted immediately, regardless of whether or not it may have been in a position to come back
into view at some point. These limitations can be ‘fixed’ by enabling the “EnablePersistentParticleEffects” option
in ATXconfig.ini under [Particles] (set to 1), but it is left to be toggled at the user’s discretion
and is considered experimental.

Moreover, the max number of individual particles of all CParticles effects being displayed
at one time combined is 300. If this number is exceeded, any new particle effects initiated by this AT
or any other medium will not be displayed (blood, dust, sparks, etc.). The safest way to stay below
this limit is a keep a low max Number value for the CParticles instances you are using and trigger
them in specific locations (where other particle effects are less likely to appear). Otherwise, you
may have to assume the possibility that your effect will not be rendered, depending on circumstances.

ActionType 118 – Swap Instance Texture

group Action00 = {
int ActionType	     = 118
string A00	     = [Name of instance who's master mesh is to be modified] *
int Sample	     = [Index of texture material to replace in mesh (starting with 1)] **
int Frame	     = [Number of AnimXX texture to use as replacement (starting with 0)] ***
bool LoopCount	     = [Should the level allow level restart without resetting mesh data, and omit savegame data?]****
}
* default = none
** default = 1
*** default = 0
**** default = false

This is a very strict ActionType that will allow you to swap textures on animating meshes.
You must specify the name of the instance who’s mesh will be modifed via the A00 string value.
The instance MUST contain at least one AnimXX script entry (i.e., Anim00, Anim01) in its
group script (see Trescom Spitter for example) and thus must be recognized as a “texture
animating” instance by the game (technically, it needs to have a CMeshAnimating-compatible mesh).
This may or may not require it to have a AnimSubMaterial value set in its script as well, all this
regardless of whether or not it will be animated with anything other than this ActionType.

The int Sample value is the equivalent of the int AnimSubMaterial value that is sometimes
included in instance scripts. It designates the index (number) of the texture material
to replace in the instance’s mesh. It starts at value 1. You can usually find this number
by looking over the mesh’s TPM file with a text editor and identifying the corresponding
*.matXX material, where XX is the number in question (for the Trescom Spitter’s frill, for
example, you would have int Sample = 8).

The int Frame value has the same meaning and function as ActionType 21’s Frame value.
It will select the new replacement texture by number of its AnimXX script texture names
found the instance’s group script (i.e., string Anim00 = “SomeTexture00.bmp”, string
Anim01 = “SomeTexture01.bmp”, etc.). It starts at 0. For example, to select the texture named
via Anim00, you will set int Frame = 0, for Anim01, you will set int Frame = 1, etc.
(note: Trespasser seems to provide Anim entries from 00 to 29, though the maximum
is disputable)

In short, this ActionType is very similar to ActionType 21, but allows you to
specify which texture to replace in the target mesh instead of relying on the instance’s
fixed AnimSubMaterial value. While it has no time or track settings as AT 21 does,
you can use the Delay ActionType along with a series of ActionXX groups within a trigger to
create simple animations and have more than one animating texture per mesh. See the
Trescom Spitter frill animation scripted by Rebel for an example (you can effectively replace all AT21
calls with AT118 calls simply by specifying an extra “int Sample = 8” setting).

**** If you have at least one valid instance of ActionType 118 somewhere in
your level, ATX will force the “Disable Fast Restart” level-load GRF reload option for
the level by default, that is, for all level restarts and savegame loads. This is to force
the game to rebuild all mesh instances; otherwise, it does not, and any texture swaps performed
will be permanent across subsequent reloads. This feature will noticeably slow down level restarts
and savegame loads for large levels. However, if you include a “bool LoopCount = true”
value in any one of your working ActionType 118 instances anywhere in your level, you will instruct
ATX to let the game perform level/savegame restarts as it normally does (faster), and also prevent
ATX from saving the state of the swapped textures to its savegames. Of course,
ONLY use this if your level script already takes this problem under account or if you are
using it for trivial animations (i.e., that will not significantly affect gameplay, only provide
short visual effects or such, and won’t have much impact if they are ported across level reloads).
Note that setting the LoopCount boolean does not prevent the user from selecting “Disable Fast Restart”
from the menu or the same feature being potentially activated by other ATX features.

!!! Please note before using this ActionType in any level that it will modify the master
mesh for the instance in-game, meaning any other instance using the same mesh will
suffer the same texture changes. You may be forced to create copies of your meshes
and rescript your instances if you fear they may be animated while all in the
player’s presence. This is behaviour as exhibited by ActionType 21.

!!! DO NOT use ActionType 118 to modify textures in a mesh if ActionType 21
is also used on the same textures (they can be combined when used on different textures in the
same mesh).

!!! Like most other new ActionTypes, do not under any circumstance use AT118 in
a CStartTrigger. Use a CLocationTrigger or other type to simulate its function.

The state of this ActionType is saved in ATX 1.62-based savegames and higher (as long
as bool LoopCount is set to false or omitted).

ActionType 119 – Set Rain Effect (Experimental)

group Action00 = {
int ActionType	     = 119
int Frame	     = [enable (1)/disable (0) rain effect (current state)] *
string Sample	     = [name of CParticles instance to use for individual rain particles] **
float Radius	     = [if Sample is specified, radius of effect around player] ***
float ZFree	     = [if Sample is specified, minimum ceiling for rain particles] ***
float ZTFree	     = [if Sample is specified, maximum ceiling for rain particles] ***
int Interval	     = [if Sample is specified, interval between creation of new rain drops] ***
int Number	     = [if Sample is specified, number of rain particles generated per interval, at once] ***
float Threshold      = [if Sample is specified, strength to apply to generated particles] ***
float Density	     = [if Sample is specified, float for unknown parameter 7] ***
}
* default = none (no change)
** default = none (no change)
*** default = none (MUST SPECIFY ALL IF Sample IS SPECIFIED)

Note: See RAIN EFFECT for more info.

This ActionType toggles the experimental particle-based rain effect and/or changes the current particle
effect qualities. This entirely depends on whether or not the user has the feature properly enabled and
set up in ATXconfig.ini.

Specify the Frame value to turn rain on (value of 1) or off (value of 0), or omit to leave at current state.
This does virtually the same thing as the TOGGLERAIN cheat.

Specify the Sample string name to that of a valid CParticles instance to use as model to change the current particle effect
properties. The CParticles instance will be used to generate the individual rain particles of the effect.
The remaining values (Radius, ZFree, ZTFree, etc.) are used to control the area and happening of the rain
effect as a whole and correspond loosely to the ones provided in ATXconfig.ini (note: “Density” ~ “DefaultParam7”).
You MUST specify all 7 values if the Sample string name is specified. They will be ignored if Sample is not present.

Threshold should be within your CParticles instance’s own Threshold min and max values, and Density is usually 1.000000.
The others you will have to experiment with and perhaps compare to the example ATX values in ATXconfig.ini. For the CParticles
instance’s required settings, see “MAPS\RNE\default.ini” for a decent example (remember that Number should always be 1 for
min and max, and do not confuse with Number from an AT119 instance, as with Threshold).

Note that you can toggle rain on or off without changing the rain consistency and vice versa. Simply omit
and include the appropriate Frame and Sample values (where the other 7 values should always accompany Sample).

The state of this ActionType is saved in ATX 2.01-based savegames and higher.

ActionType 120 – Set Trigger FireCount and Probability

group Action00 = {
int ActionType	     = 120
string A00	     = [name of trigger instance to which to apply changes - REQUIRED] *
int Sample	     = [new FireCount value for designated trigger - REQUIRED] **
int LoopCount	     = [new Probability value for designated trigger - MAY BE REQUIRED] ***
bool Frame	     = [apply new FireCount value for all count loops for trigger using FireAtZero/ResetFire settings] ****
}
* default = none (AT has no effect)
** default = none (AT has no effect)
*** default = 100 (NOTE: does NOT preserve trigger's original probability value!)
**** default = false (will only affect the current countdown before the next automatic fire count reset for trigger)

This ActionType can be used to reset a given trigger’s running FireCount countdown value on-the-fly. You must designate
a trigger using the A00 string to specify the trigger’s instance name. You must also specify a new fire count for
the trigger using the Sample int value, even if you only wish to reset the trigger to its original fire count (this
is due to a particularity with trigger instances which prevents ATX from knowing the original FireCount value for
the trigger).

If you specified a Probability value for the original trigger, you MUST re-specify it in this AT using the LoopCount
value. If you omit LoopCount, the trigger’s probability will be set to 100 automatically (always launch), even if
this was not its original value (this is also due to a particularity with trigger instances which prevents ATX
from knowing the original Probability value for the trigger).

In short, this ActionType will ALWAYS modify both the FireCount and Probability for the designated trigger. To set
only one of these values, please ensure that the other is specified and set to the original value for the trigger, or
you may end up with unwanted results. The only exception to this case is when your trigger did not have a Probability
value, in which case its original probability was 100, which happens to be the default for this ActionType’s
LoopCount value.

The Frame boolean applies only to triggers which had the original FireAtZero and ResetFire flags set to true.
In this case, if Frame is set to true, every new iteration of the trigger’s fire count countdown will use the
new fire count specified with the Sample value. If Frame is kept false, the Sample value fire count will only
update the current countdown for the trigger, and the trigger will return to its original FireCount value once
this countdown reaches zero and resets (due to ResetFire).

ActionType 121 – Reload Standalone Gun

* New in ATX 2.05

group Action00 = {
int ActionType	 = 121
int Ammo	 = [force number of rounds for each listed gun]*
int AltAmmoCount = [number of rounds to substract from MaxAmmo
		    before reloading]**
string A00	 = [name of first CGun instance to apply reload to]***
string A01	 = [name of second CGun instance to apply reload to]****
...
string Axx	 = [name of last CGun instance to apply reload to]****
}
* default	 = (unused)
** default	 = (0 if Ammo is unused)
*** default	 = none, but required
**** default	  = none (apply to A00 only)

This ActionType reloads each gun in the list of CGun instances specified with the A00…Axx
strings using one of the specified Ammo or AltAmmoCount values. The numbered Axx scripts must
be consecutive, or any instances following a break in the numbering will be dismissed. There
must be at least one instance, specified using A00.

This has the same reload effect as ActionType 103, but applies to any gun instances directly,
whether Anne is carrying it or not. Specifying the Ammo value gives an absolute new ammo count
for each gun reloaded, while AltAmmoCount is applied by substracting its value from each gun’s
individual MaxAmmoCount value (in the CGun instance’s script), and setting the result as the current new ammo value
(so setting AltAmmoCount to 0 will effectively reload every gun in the list to their full clips). At
least one of these two values must be specified. Only one will work at any given time, and Ammo
has priority if both exist. AltAmmoCount may be negative, as describe in ActionType 103.

REFERENCING ANIMATE PHYSICS SUB-OBJECTS BY STRING

It turns out it’s very possible to reference animal and player sub-objects using Trespasser’s
standard string-based instance recognition after all.

To get the name of the specific body part you need, simply combine the string name of the physics
sub-object with the instance’s string name as follows:

“SubObjectName+NameOfInstance”

NameOfInstance is the string name of the specific instance to which the body part belongs,
for example “RaptorB300-00” or “FrillSpitter”. Do not confuse with the name of the master
instance, unless it’s active in your level for some reason.

SubObjectName is the full string name of one of the physics sub-objects as defined in the
instance’s T-Script group, for example “$RaptorBBody-00” or “$RaptorBTail-00”. These are the
string values that show up with the script names “Hand”, “Foot”, “Body”, “Head”, “Tail”, etc.
They’re usually found in both the instance’s group and the instance’s master instance’s group
(i.e., would be both under RaptorB300-00 and RaptorB). You must include all characters, i.e.,
including “$”, “-“, numbers, and any others. Note that these sub-objects usually have the same
names for all instances of the same master instance (i.e., ‘string Head = “$RaptorBHead-00″‘
could be found in both “RaptorB300-00” and “RaptorB300-01”). However, if you follow the above
formula it’s not a problem, because the instance name following the “+” character ensures you’re
generating a unique string.

In particular, this means that you can attach CEntityAttached instances to animal body parts.
Say you have a raptor, RaptorB300-00, who’s group script is:

group RaptorB300-00 = {
 string Class = "CAnimal"
 string Physics = "RaptorB"
 string Mesh = "RaptorB"
 string Type = "Raptor"
 string Head = "$RaptorBHead-00"
 string Body = "$RaptorBBody-00"
 string Tail = "$RaptorBTail-00"
 ...
}

(we assume Head, Body, and Tail are the same for the master instance, RaptorB)

You also have some object which you want to attach to the dino’s head, first positioning it at the
proper location* using TresEd, to keep its relative position and orientation to the head at all
times. All you need to do is specify the dino’s head instance string name as the Target instance
as described above:

group MyAttachedObjectA00-00 {
 string Class = "CEntityAttached"
 string Target = "$RaptorBHead-00+RaptorB300-00"
 bool Moveable = true
}

That’s it. It should work for most T-Script string entries used to reference instances such as
ActionTypes as well (i.e., wherever you see “Target” and it is logical to specify a body part).
If you had a strong urge to do something ridiculous, you could even attach something to Anne’s
hand using “$AnneHand+Anne” (assuming your level uses an “Anne” instance group and her hand’s
box goes by the name “$AnneHand”).

The only limitation is that you cannot use this method to attach anything to Anne’s head,
apparently. If you look in Anne’s group script in level, you won’t see a “Head” sub-object
value at all. I believe this is because her head isn’t considered by the game as a separate
object, but rather blended with the main player object using obscure values and highly
dependent on user input. There is unfortunately no apparent solution to this.

* Contrary to TresEd, Trespasser does not position animate physics sub-objects in their
respective locations on meshes until the instances are first activated in-game. Instead,
it first keeps all physics boxes for an animal at its center location, which is usually
the center of the body (to verify this, activate the DINOS and BONES cheats and walk up
to a not-previously-activated dino). Because CEntityAttached evaluates the initial position
of the Target instance at load-time (in order to preserve the relative position when it moves)
and the sub-objects are at the middle of the dino’s body at that time, you must place your
CEntityAttached instance in TresEd nearer to (or further from) the dino’s body to compensate
for the added distance (or substracted distance, depending on desired position). It can take
a little trial-and-error to find the right location. Basically, simply imagine the animal’s
sub-object body part as if it were level at the middle of its body (with the body’s orientation),
and position/orient your CEntityAttached according to that, instead of to where it looks like
it should be in TresEd.

ARCHIVE

This section holds miscellaneous information regarding variable
addresses, internal class structures, and anything else that has
to do with the modding of the game. These documents are especially
provided ‘as-is’ and may be changed without notice, or never
updated at all.

Please note: much of the information here is now out of date and is kept for
archival purposes only. Please refer to the ATX 2.00+ source for updated specifics on
internal Trespasser classes, variable addresses, etc.

- ACTIONTYPE CLASSES INTERNAL STRUCTURES

- ACTIONTYPE OFFICIAL CLASS NAMES

- CANIMAL CLASS INTERNAL STRUCTURES

- DRAW DISTANCE VARIABLE ADDRESSES

- ERROR.LOG PARTIAL DESCRIPTION

- GAME SPEED VARIABLE ADDRESSES

- GRAVITY VARIABLE ADDRESSES

- REGISTRY ENTRIES

- SCRIPT NAMES NOTE

ACTIONTYPE CLASSES INTERNAL STRUCTURES

These describe some ActionTypes’ classes as they appear
in memory. All values are assumed 32-bit (DWORD) unless otherwise
specified. Booleans are usually addressed as BYTEs and set in
bit 0 of a byte. Only known entries are documented.
For every VTable, the following members are as follows:

[VTable+08h] = Main ActionType function (called upon trigger)
[VTable+14h] = Function called upon (re-)initialization, usually at level load

;========================================================
ACTIONTYPE 10 (PHYSICS) CLASS (total size = 40h bytes)
;========================================================

[AT10+00h] = VTable
[AT10+04h] = Ref count
[AT10+08h] = X velocity
[AT10+0Ch] = Y velocity
[AT10+10h] = Z velocity
[AT10+14h] = Frozen boolean (BYTE)
[AT10+18h] = Target instance memory pointer (not instance name)
[AT10+1Ch] = Impulse boolean (BYTE)
[AT10+2Ch] = X facing value, default = 0.000000 (???)
[AT10+30h] = Y facing value, default = may be 1.000000 (???)
[AT10+34h] = Z facing value, default = (???)
[AT10+38h] = Push value
[AT10+3Ch] = Emitter instance memory pointer (not instance name)

;========================================================
ACTIONTYPE 16 (LOAD LEVEL) CLASS (total size = 24h bytes)
;========================================================

[AT16+00h] = VTable
[AT16+04h] = Ref count
[AT16+08h] = Level name string length (not including null-terminator)
-> should be 15 or lower if found in AT16 instance
[AT16+0Ch] = Always 00000010h (at initialization)
[AT16+10h] = Level name string (*.scn, including extension, null-terminated)
-> only 16 bytes in total for string here
-> may be elsewhere in memory (but usually here by default)
[AT16+20h] = Pointer to level name string (usually AT10+10h)

;========================================================
ACTIONTYPE 18 (TELEPORT) CLASS (total size = 2Ch bytes)
;========================================================
-> Uses same teleportation method as TELE cheat.
-> All booleans are TRUE by default.

[AT18+00h] = VTable
[AT18+04h] = Ref count
[AT18+08h] = Instance to teleport *
[AT18+0Ch] = X position of target instance (destination)
[AT18+10h] = Y position of target instance
[AT18+14h] = Z position of target instance
[AT18+18h] = Rotation value w (of quaternion) of target instance
[AT18+1Ch] = Rotation value x (of quaternion) of target instance
[AT18+20h] = Rotation value y (of quaternion) of target instance
[AT18+24h] = Rotation value z (of quaternion) of target instance
[AT18+28h] = HeightRelative boolean (BYTE)
[AT18+29h] = OnTerrain boolean (BYTE)
[AT18+2Ah] = SetPosition boolean (BYTE)
[AT18+2Bh] = SetOrientation boolean (BYTE)

* This member is not a direct pointer to the instance in memory
(contrary to most other cases, such as ActionType 10). It
is an indirect value used internally by Trespasser and retrieved
using only the instance’s name (during level load).

ACTIONTYPE OFFICIAL CLASS NAMES

These are the names of the 36 default Trespasser ActionTypes
as they would have appeared in the Trespasser source. They
are, in truth, the names of the classes of each ActionType.

- AT00 – CVoiceOverAction

- AT01 – CAmbientAction

- AT02 – CMusicAction

- AT03 – CFadeMusicAction

- AT04 – CShowOverlayAction

- AT05 – CSetFogAction

- AT06 – CSetRendererAction

- AT07 – CSetTerrainAction

- AT08 – CSetImageCacheAction

- AT09 – CSetAIAction

- AT10 – CSetPhysicsAction

- AT11 – CSubstituteMeshAction

- AT12 – CSetSortAction

- AT13 – CSetSkyAction

- AT14 – CSetAlphaWaterAction

- AT15 – CWaterOnOffAction

- AT16 – CLoadLevelAction

- AT17 – CSetAnimatePropertiesAction

- AT18 – CTeleportAction

- AT19 – CSaveLevelAction

- AT20 – CMagnetAction

- AT21 – CAnimateTextureAction

- AT22 – CHideShowAction

- AT23 – CSoundEffectAction

- AT24 – CWakeAIAction

- AT25 – CDelayAction

- AT26 – CScriptedAnimationAction

- AT27 – CSetVariableTriggerAction

- AT28 – CSetHintAction

- AT29 – CAudioEnvironmentAction

- AT30 – CSubstituteAIAction

- AT31 – CEndGameAction

- AT32 – CControlPlayerAction

- AT33 – CAISystemAction

- AT34 – CTextAction

- AT35 – CWaterDisturbanceAction

CANIMAL CLASS INTERNAL STRUCTURES

;========================================================
CANIMAL CLASS AND SUB-CLASS DEFINITIONS (PARTIAL)
;========================================================
;Note:  All values/member are considered DWORDs (32-bit) unless otherwise specified.
;Note2: Many of the members found in this structure are the same
;       for the "Player" class. The Player class is not necessarily
;       the holder of all player-related values (such as the camera's facing values).
;Note3: All members described here are assumed to be valid for the CAnimal class only,
;       despite resemblance to Player class(es).
;Note4: I do not guarantee that all known members and values will be
;       kept up to date.
;Note5: The symbol "h" following a series of characters designates a HEXadecimal
;       number/address/offset. It is the usual assembly equivalent to the "0x" notation preceding
;       such a number.
;Note6: "CANIMAL" class should have been written as "CAnimal".
;Note7: Sub-classes described further belowmay vary and should only
;       be assumed valid in specified structure for CAnimal references.

Maximum CAnimal class size: 888 bytes (222 members)
Theoretical CAnimal class size: 224 bytes (56 members) (excludes sub-classes included in
total allocated memory (888 bytes) of CAnimal class which are also directly
referred to by CAnimal class members or sub-class members; ONLY includes first
224 bytes of data in class; does not include possible valid members later in
total allocated size)

;========================================================
CAnimal (main)
;========================================================
[CANIMAL+000h] = VTable
METHODS (AS POINTERS):
-> PARAMS are in C-calling convention (1 = [esp+4], 2 = [esp+8], 3 = [esp+12], etc.)
[VTable+010h] = Get Current Location
PARAMS: 1: pointer to structure to fill (32 bytes)
NOTES: – The executable overcomplicates and misuses this method
– Also valid for Player class
– Filled structure is same as 32 consecutive bytes starting at [CANIMAL+030h]

[VTable+038h] = Set New Location/Orientation
PARAMS: 1: modified new location structure returned from Get Current Location
2: usually NULL
NOTES: – Also valid for Player class
– This method is used constantly by the EXE. If it is removed/diverted,
the player’s position and orientation become fixed.

[VTable+20Ch] = alter dino’s “pain” value (this method is not yet documented properly)
Params: 1: (float value of unknown significance)
2: usually NULL
3: usually NULL

[CANIMAL+028h] = Pointer to CInfo class
[CANIMAL+030h] = X position (read-only)
[CANIMAL+034h] = Y position (read-only)
[CANIMAL+038h] = Z position (read-only)
[CANIMAL+03Ch-048h] = w,x,y,z format quaternion determining the object’s current orientation
(“Facing” VECTOR values are calculated from these)

[CANIMAL+050h] = Current health (Hitpoints) (can be modified)
[CANIMAL+054h] = Max health (MaxHitpoints) (can be modified)

[CANIMAL+094h] = (not a pointer to) Start of CBoundVolBox class (CBoundVolBox class VTable pointer)

[CANIMAL+0ACh-0C0h] = various pointers (some may be absent depending on dino type) to
CBoundaryBox classes that hold values and info about the dino’s different parts.
For example, the two first classes in the “Player” class (+0ACh, +0B0h) are used by the new
“CLOAK” cheat to track down and modify Anne’s ‘AIType’ values a few
sub-classes into the hierarchy (the third one might have been important
as well, but the final address is the same as the second one).
[CANIMAL+0ACh] = root dino BODY object (usually)
[CANIMAL+0B8h] = root dino HEAD object
[CANIMAL+0BCh] = root dino TAIL object
The following is usually valid for all three objects (referred to as OBJ):
[OBJ+28h] = sub-object pointer (SUBOBJ1), usually in higher memory
[SUBOBJ1+0Ch] = sub-object pointer (SUBOBJ2), usually lower in memory,
object holding some of the physics objects’ values
[SUBOBJ2+0Ch] = Damage T-Script value
[SUBOBJ2+10h] = Armour T-Script value
*** It might have been possible that, at some point, there were other
objects as there is space for them between and after the ones
incorporated in the CAnimal class, and it is hinted to by some
T-Script values (i.e., “Neck”). Space may also have been reserved for
differences between animal types and the player class.

[CANIMAL+0DCh] = Pointer to CBrain class (for AI system)
-> Main AI sub-class containing pointers to the main instance’s
Actxxxxxxx AI classes and other AI-related values

[CANIMAL+0E0h] = (It appears that the CBoundaryBox classes pointed to earlier than this
point are stored here in the CAnimal class itself, depending on assumed class size).

;========================================================
CBrain
;========================================================

Maximum CBrain class size (assumed): 896 bytes (224 members)

[CBrain+000h] = VTable
[CBrain+004h] = Pointer to CMentalState class
[CBrain+008h] = Pointer to CWorldView class

[CBrain+010h] = Pointer to CActivityCompound class
[CBrain+014h] = Pointer to CActivityEat class
[CBrain+018h] = Pointer to CActivityBite class
[CBrain+01Ch] = Pointer to CActivityFeint class
[CBrain+020h] = Pointer to CActivityRam class
[CBrain+024h] = Pointer to CActivityDrink class
[CBrain+028h] = Pointer to CActivity class (“Not implemented” – type activity)
[CBrain+02Ch] = Pointer to CActivity class
[CBrain+030h] = Pointer to CActivityTailSwipe class
[CBrain+034h] = Pointer to CActivity class
[CBrain+038h] = Pointer to CActivity class
[CBrain+03Ch] = Pointer to CActivity class
[CBrain+040h] = Pointer to CActivityVocalSnarl class
[CBrain+044h] = Pointer to CActivityVocalCroon class
[CBrain+048h] = Pointer to CActivity class
[CBrain+04Ch] = Pointer to CActivityMoveCommandToward class
[CBrain+050h] = Pointer to CActivity class
[CBrain+054h] = Pointer to CActivity class
[CBrain+058h] = Pointer to CActivity class
[CBrain+05Ch] = Pointer to CActivityMoveHintWander class
[CBrain+060h] = Pointer to CActivity class
[CBrain+064h] = Pointer to CActivity class
[CBrain+068h] = Pointer to CActivityMoveCommandStayNear class
[CBrain+06Ch] = Pointer to CActivityMoveCommandStayAway class
[CBrain+070h] = Pointer to CActivityFlee class
[CBrain+074h] = Pointer to CActivityPursue class
[CBrain+078h] = Pointer to CActivityJumpBack class
[CBrain+07Ch] = Pointer to CActivityGetOut class
[CBrain+080h] = Pointer to CActivityApproach class
[CBrain+084h] = Pointer to CActivity class
[CBrain+088h] = Pointer to CActivityMoveBy class
[CBrain+08Ch] = Pointer to CActivity class
[CBrain+090h] = Pointer to CActivity class
[CBrain+094h] = Pointer to CActivitySniffTarget class
[CBrain+098h] = Pointer to CActivityCockHead class
[CBrain+09Ch] = Pointer to CActivityRearBack class
[CBrain+0A0h] = Pointer to CActivity class
[CBrain+0A4h] = Pointer to CActivityCower class
[CBrain+0A8h] = Pointer to CActivityGlare class
[CBrain+0ACh] = Pointer to CActivitySniffAir class
[CBrain+0B0h] = Pointer to CActivityLookAround class
[CBrain+0B4h] = Pointer to CActivityNothing class
[CBrain+0B8h] = Pointer to CActivity class
[CBrain+0BCh] = Pointer to CActivity class
[CBrain+0C0h] = Pointer to CActivity class
[CBrain+0C4h] = Pointer to CActivity class
[CBrain+0C8h] = Pointer to CActivity class
[CBrain+0CCh] = Pointer to CActivityDOSubBrain class
[CBrain+0D0h] = Pointer to CActivityDOSubBrain class
[CBrain+0D4h] = Pointer to CActivityDOSubBrain class
[CBrain+0D8h] = Pointer to CActivityDOSubBrain class
* for all CActivityxxxxxx classes, bit 2 of member
[CActivityxxxxxxx+34h] is boolean for enable/disable act (instance-specific)

[CBrain+0E0h] = Pointer to CSynthesizer class
[CBrain+11Ch] = Pointer to CAnimal class (parent class?)
[CBrain+128h] = (not pointer to) start of CMessagePhysicsReq sub-class (CMessagePhysicsReq VTable)
[CBrain+130h] = Pointer to CAnimal class (parent class?)
[CBrain+140h] = Name of Master instance for parent instance (string) (i.e., RaptorB for instance RaptorB00-00)
-> Often true, but not always the case
[CBrain+1E8h] = Pointer to CValueTable class
[CBrain+1ECh] = Pointer to CObjectValue class
[CBrain+220h] = Name of parent instance (string) (i.e., RaptorB00-00 for instance RaptorB00-00)

[CBrain+264h] = “Bravery” value
[CBrain+340h] = “WakeUp” value
[CBrain+344h] = “Sleep” value

;========================================================
CMentalState
;========================================================

[CMentalState+000h] = VTable
[CMentalState+004h] = “Fear” value
[CMentalState+008h] = “Love” value
[CMentalState+00Ch] = “Anger” value
[CMentalState+010h] = “Curiosity” value
[CMentalState+014h] = “Hunger” value
[CMentalState+018h] = “Thirst” value
[CMentalState+01Ch] = “Fatigue” value

;========================================================
CInfo
;========================================================

[CInfo+000h] = VTable
[CInfo+00Ch] = Pointer to CPhysicsInfoBiped or similar class (depends
on dino’s “Type” name)
[CInfo+010h] = Pointer to CAIInfo class

DRAW DISTANCE VARIABLE ADDRESSES

The variable for the draw distance in Trespasser is found in
the main executable’s ‘rdata’ section. It is a 32-bit single-
precision floating-point value which is, by default, 15.000000
(in the same units used for object positions and player location
in the levels). The hex string for this float is [00 00 70 41].
This value can be incremented to increase draw distance of all
objects in-game. The following addresses indicate the variable’s
location from the start of the executable file and its offset in
memory once loaded.

In every executable, there is also a single direct reference where
this value is accessed, which can be examined using a disassembler
(disassembler used was URSoft W32Dasm V.8.93). The address of this
line of code is indicated as it is seen in memory (not by file
offset). It is possible that this value is accessed at other points
in the file, but this would only be verifiable at run-time.

NOTE: If you are unsure of the executable version you are using,
go into the game’s main directory, right-click on “Trespass.exe”,
select properties, and then the “Version” tab.

CAUTION: Using very high values will severely degrade game performance.

------------- PATCHED EXECUTABLES -------------

EXECUTABLE VERSION: Pentium Pro (P6) build 1.0.117.0 (w/Patch v1.1)
Offset in file: 0x0024A760
Address in memory: 0x0064A760
Referenced by code at address: 0x00527B08

EXECUTABLE VERSION: Pentium (P5) build 1.0.117.0 (w/Patch v1.1)
Offset in file: 0x00250774
Address in memory: 0x00650774
Referenced by code at address: 0x00528EA2

EXECUTABLE VERSION: K6-2 build 1.0.117.0 (w/Patch v1.1)
Offset in file: 0x00218774
Address in memory: 0x00618774
Referenced by code at address: 0x005211A2

————- ORIGINAL GAME EXECUTABLES (ON CD) ————-

EXECUTABLE VERSION: Pentium Pro (P6) build 1.0.116.0 (original)
Offset in file: 0x0024E458
Address in memory: 0x0064E458
Referenced by code at address: 0x00543948

EXECUTABLE VERSION: Pentium (P5) build 1.0.116.0 (original)
Offset in file: 0x0025446C
Address in memory: 0x0065446C
Referenced by code at address: 0x005451E2

EXECUTABLE VERSION: K6-2 build 1.0.116.0 (original)
Offset in file: 0x0021D47C
Address in memory: 0x0061D47C
Referenced by code at address: 0x0053D372

———— TRESPASSER DEMO ————

EXECUTABLE VERSION: Pentium build 1.0.117.0
Offset in file: 0x00254334
Address in memory: 0x00654334
Referenced by code at address: 0x00527732

ERROR.LOG PARTIAL DESCRIPTION

This file is created anytime Trespasser encounters a handle-able
error/exception. Through trial and error and a good amount of
disassembly, I’ve been able to find the meaning of part of the
Context Record. The following is an example of an ERROR.LOG file
with all currently known and possible descriptions.

Trespasser Build: 1, 0, 117
Trespasser Fault: Sun Dec 19 08:28:37 2004

Exception Record
—————-
Code : 0xC0000005
Flags : 0x00000000
Address: 0x006059FD
Info 0: 0x00000000
Info 1: 0xFFFFFFFF

Context Record
————–
0: 0x0001001F, 0x00000000 ; unknown…
2: 0x00000000, 0x00000000
4: 0x00000000, 0x00000000
6: 0x00000000, 0xFFFF027F
8: 0xFFFF0220, 0xFFFFFFFF
10: 0x00000000, 0x00000000
12: 0x00000000, 0xFFFF0000
14: 0x00000000, 0x00000000
16: 0x00000000, 0x00000000
18: 0x00000000, 0x00000000
20: 0x00000000, 0x00000000
22: 0x00000000, 0x00000000
24: 0x00000000, 0x80000000
26: 0xF8003FFF, 0x1ACC0433
28: 0x3FF9A646, 0x252D0000
30: 0x9107B1F4, 0xC0003FFC
32: 0xDAA22168, 0x3FFEC90F
34: 0x0000000A, 0x00000000
36: 0x00002A37, 0x00000177 ; DWORD fs(?), DWORD ds/es/ss(?)
38: 0x00000177, 0x0094FC80 ; DWORD ds/es/ss(?), edi
40: 0x00400000, 0x00400000 ; esi, ebx
42: 0x00000000, 0x0094FB08 ; edx, ecx
44: 0x0000000A, 0xBFF67B08 ; eax, ebp
46: 0x006059FD, 0x0000016F ; eip, DWORD cs(?)
48: 0x00250212, 0x0094FAD0 ; ?, ?
50: 0x00000177, 0x00000000 ; DWORD ds/es/ss(?), [esp-16] *
52: 0x0094FB08, 0x00400000 ; [esp-12], [esp-8]
54: 0x0000000A, 0x0040E3F3 ; [esp-4], [esp]
56: 0x00000000, 0x0062B69C
58: 0x0094FB08, 0x90080000
60: 0x00000000, 0x00000000
62: 0x00000280, 0x000001E0
64: 0x00000000, 0x00000000
66: 0x00400000, 0x00000000
68: 0x0062B80C, 0x73657254
70: 0x73736170, 0x37007265
72: 0x13E20000, 0x016FBFF6
74: 0x424A0000, 0xED04BFF6
76: 0xED040001, 0x2FB50001
78: 0x0022BFF4, 0x00080000
80: 0x06940000, 0x0000358F
82: 0x37270000, 0x00002FEF
84: 0x0000073E, 0x00000000
86: 0x00002E7F, 0x80006E78
88: 0x00000000, 0x0B3B8B6C
90: 0x00208040, 0x00030000
92: 0x0A6F002C, 0x00000000
94: 0x0094FD8C, 0xBFF6269C
96: 0xBFF42FA2, 0x00947000
98: 0xBFF41315, 0x0094FBEC
100: 0x00000001, 0x00620430
102: 0x0094FC80, 0x00000000
104: 0x00400000, 0x0094FBD4
106: 0x0094FC80, 0x00000010
108: 0xBFF6BB26, 0x8194F13C
110: 0x00000010, 0x78001DE8
112: 0x7803B600, 0x0094FBF4
114: 0x7800CD1B, 0x00000009
116: 0x7800CD04, 0x0094FC80
118: 0x0062B80C, 0x00400000
120: 0xBFF67B08, 0x00B800B0
122: 0x0094FBE4, 0x0062B80C
124: 0x0094FD8C, 0x7800F56A
126: 0x78033238, 0xFFFFFFFF
128: 0xBFF67B08, 0x78001026
130: 0x00000010, 0x780021F9
132: 0x00000010, 0x0040DD23
134: 0x00400000, 0x00000001
136: 0x00000000, 0x8194F969
138: 0x0094FD9C, 0x00000000
140: 0x00000001, 0x0094FC68
142: 0x000CAE48, 0x00AA40D8
144: 0x000010E4, 0xBFF6A501
146: 0x00A70000, 0x00AA51BC
148: 0x000CAE48, 0x00000000
150: 0x00A7000C, 0x00A70000
152: 0x00AA40D8, 0x00000000
154: 0x545C3A43, 0x20534552
156: 0x645C4443, 0x5C617461
158: 0x756E656D, 0x6170745C
160: 0x6E697373, 0x2E6F7274
162: 0x006B6D73, 0x8194F969
164: 0x00000000, 0xBFF613EE
166: 0x0000016F, 0xBFF6A444
168: 0x00000AA7, 0x0094FCD8
170: 0x000C8E50, 0x00AA61B0
172: 0x00001004, 0xBFF6A501
174: 0x00A70000, 0x00AA71B4
176: 0x000C8E50, 0x81943BE4
178: 0x00000000 ; **

* = start of stack dump
** = end of stack dump
(?) = uncertain
Note: The value of esp should be the one from the time at which
the exception occured.
Note 2: The Trespasser error handler is not perfect and does not
always report all values properly. It cannot handle all values of
esp (stack pointer) properly and may lock up if its value is out
of range. It also does not handle misuse of segment registers very
well.
Note 3: The error handler seems based from or in MSVCRT.dll.

Note that this dump was retrieved after running the K6 1.0.117
Build (patched at 1.1), and results may vary with a different
executable (though this would not be practical). Within the same
executable (and possibly amongst others), the line number associated
with a description should remain the same for every error encountered
and every log file created.

GAME SPEED VARIABLE ADDRESSES

Unsurprisingly, there is a game speed variable inside each
executable, at different addresses in each. Like the draw distance,
it is stored as a 32-bit floating point value; it has a default
value of 1.000000. This variable is modified in-game by the
“BIONICWOMAN” cheat; it sets this value to about 0.300000, which
slows down the game by a factor of approximately 3 (this cheat may
vary between executables). This value can be greater than 1 (making
the game faster) or between 0 and 1 (making the game slower). Like
the draw distance, I do not recommend setting this to a negative
value. And now, here are the addresses of this variable for each
executable:

————- PATCHED EXECUTABLES ————-

EXECUTABLE VERSION: Pentium Pro (P6) build 1.0.117.0 (w/Patch v1.1)
Offset in file: 0x0026678C
Address in memory: 0x0066678C

EXECUTABLE VERSION: Pentium (P5) build 1.0.117.0 (w/Patch v1.1)
Offset in file: 0x0026C77C
Address in memory: 0x0066C77C

EXECUTABLE VERSION: K6-2 build 1.0.117.0 (w/Patch v1.1)
Offset in file: 0x002347EC
Address in memory: 0x006347EC

————- ORIGINAL GAME EXECUTABLES (ON CD) ————-

EXECUTABLE VERSION: Pentium Pro (P6) build 1.0.116.0 (original)
Offset in file: 0x0026B6FC
Address in memory: 0x0066B6FC

EXECUTABLE VERSION: Pentium (P5) build 1.0.116.0 (original)
Offset in file: 0x0027168C
Address in memory: 0x0067168C

EXECUTABLE VERSION: K6-2 build 1.0.116.0 (original)
Offset in file: 0x0023A734
Address in memory: 0x0063A734

———— TRESPASSER DEMO ————

EXECUTABLE VERSION: Pentium build 1.0.117.0
Offset in file: 0x00271864
Address in memory: 0x00671864

NOTE: Using the [original] “BIONICWOMAN” cheat will effectively put a value of
0.300000 as the speed variable. Turning off the cheat will reset it
to 1.000000, not the value you will have set it to (you will have to
restart the game to undo this). This could be fixed by modifying the
“BIONICWOMAN” cheat function, but that might not be worth the effort.

GRAVITY VARIABLE ADDRESSES

Even though there are useable gravity control script entries that can
be used through level files, there also happens to be a variable that
controls the overall gravity (which I assume is valid unless
overwritten by the program). Like the other variables, it is a
32-bit floating-point value. The default value is of 10.000000
(N/kg, I assume), which is represented by the string [00 00 20 41]
in hex notation.

Even though it does affect gravity adequately when modified,
setting this variable to a lower value can have very odd and
frustrating effects. For example, if you set it to 1.00000, there’s
a good chance your character (and camera) will immediately start
spinning wildly in the air, along with the dinosaurs, and your
character will lose her gun and it will start “running away”. Some
of this behavior might be explained by a lack of friction, which
would be partly realistic since most friction is a result of gravity.
It might also be possible (but not necessarily probable) that the
gravity variable is used as a constant for other physics code as well
(but there are many other floats valued at 10.00000 in the data
section, so it is not all that likely). Also note that this problem
is not present when the gravity is increased. As well, I don’t
recommend setting it to a negative value; this causes Anne and
objects/dinos to “fall into the sky”, usually while spinning wildly
out of control. Lastly, because of the lowered friction, your
character will possibly walk more slowly.

------------- PATCHED EXECUTABLES -------------

EXECUTABLE VERSION: Pentium Pro (P6) build 1.0.117.0 (w/Patch v1.1)
Offset in file: 0x00245CAC
Address in memory: 0x00645CAC

EXECUTABLE VERSION: Pentium (P5) build 1.0.117.0 (w/Patch v1.1)
Offset in file: 0x0024BCAC
Address in memory: 0x0064BCAC

EXECUTABLE VERSION: K6-2 build 1.0.117.0 (w/Patch v1.1)
Offset in file: 0x00213CAC
Address in memory: 0x00613CAC

————- ORIGINAL GAME EXECUTABLES (ON CD) ————-

EXECUTABLE VERSION: Pentium Pro (P6) build 1.0.116.0 (original)
Offset in file: 0x00247750
Address in memory: 0x00647750

EXECUTABLE VERSION: Pentium (P5) build 1.0.116.0 (original)
Offset in file: 0x0024D750
Address in memory: 0x0064D750

EXECUTABLE VERSION: K6-2 build 1.0.116.0 (original)
Offset in file: 0x00216754
Address in memory: 0x00616754

———— TRESPASSER DEMO ————

EXECUTABLE VERSION: Pentium build 1.0.117.0
Offset in file: 0x0024FDA4
Address in memory: 0x0064FDA4

REGISTRY ENTRIES

For the full version, these keys can be found
in the Windows registry via:

HKEY_LOCAL_MACHINE\Software\DreamWorks Interactive\Trespasser

For the demo version, they are stored in tpass.ini in
the main folder, under the [Settings] section (generally the
only section).

This list is a rough sketch; I promise in no way that I will keep it updated.

“NoVideo”

This is a boolean value (as DWORD). Set to 1 to disable all game videos.

“System Memory”

This is a boolean value (as DWORD). Exact usage is unknown, but seems
almost definitely to determine whether video buffers are stored
in video memory (faster) or in system memory (slower). The effect
appears to apply in-game (not just in menu).

SCRIPT NAMES NOTE

Update: 29/08/2005

It has come to my attention that the game does NOT
necessarily use T-Script value names (“Target”, “Sample”, etc.)
strictly as labels during loading. For quite some time,
it had seemed as if the game’s script value fetch function
would simply fetch the appropriate values and data type IDs
from the level files. These would then be passed
to the caller, which would deal with the raw data accordingly
(process strings, convert floats, set defaults, etc.).

However, it has become obvious that the game pre-processes
some of the values based on their names. Any entry that
is used to refer to specific instances (“Target”, “Emitter”, etc.)
can be used via the ATX-supplied Trespasser EXE-based
GetInstanceFromString function to retrieve any instance within
a level. On the other hand, trying to use other script names
to retrieve instances (such as “Sample”) that were not recognized
for this function or that were recognized for another function
CANNOT be used by the EXE-based function to retrieve any instance
within a level. It has been witnessed, for example, that attempting
to acquire instances using [string Sample = “SomeInstance-01”]
will only work with some instances (mainly master instances).
Using “Target” instead would usually work for all instances.

It was also previously noted (but disregarded) that using
instance-referring script names for other string-related
purposes would often cause problems or crashes during initialization.

In conclusion, instance-referral T-Script values should be
used instead of other general values whenever instance retrieval
is required; it should also be ensured that they be used solely
for their intended purpose. It is currently not known whether
or not this applies to script names with different intial purposes.

Credits