*** DISCLAIMER ***
Trespasser, its conception or any variation of said game is under Copyright © 1998 - 2001 Dreamworks Interactive/EaGames, LLC with all right reserved. The End-User(s) assume(s) all risks and responsibility for possession and use of this software and any and all additions, edits or modifications made to it, legal or otherwise. Responsibilities include but are not limited to: legal ownership of any copyrighted or commercial materials used by or in conjunction with this software.
If the End-User(s) disagree(s) with any of these terms, please terminate all use of this software and discard it immediately.
*** END DISCLAIMER ***
Please note that the above is a rough representation of the contents of this document, and not a thorough table of contents. Sections may appear in a different order in the document than the order in which they are listed here. It's a work in progress.
This documentation is *still* a compilation of many previously separate text files, which included direct references and fixed formatting. Some of these extinct references may still exist in this text, along with syntax errors. I apologize for the inconvenience. There is also a good amount of accumulated redundancy that you will have to excuse.
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.
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.
Requirements
Notes relating to prior versions
Quick-Install Procedure
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.
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.
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.
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.
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).
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:
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.
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 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.
CameraFOVDegrees= ; This value can be used to override the default camera Field Of View when a level loads.
; It is in Euler angles (i.e., typically between 20.0 and 90.0 degrees). Levels may change
; this value for visual effects after it has been initially applied. The default game value
; for the applied CameraFOV is about (or exactly) 75.000000.
[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.
...
Please be aware of the following potentially serious concerns before running ATX:
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.
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).
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:
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.
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.
Here are various video- and rendering-related features that can help make the game look better.
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.
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.
ATX provides a few ways to make changing game options and accessing game features easier and more efficient.
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.
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):
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:
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.
(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.
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.
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.
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.
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).
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.
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)
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).
This toggles the experimental rain effect display, if the feature is currently enabled in ATXconfig.ini.
Resets the counter as shown by the TIME cheat to 0.
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 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.
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.
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.
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.
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.
Kills Anne by setting HitPoints to 0.000000.
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.
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.
Displays the current game speed value. The message will only disappear once you re-enter the cheat or exit the game.
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).
This toggles the HUD display on and off. The HUD feature must be enabled in ATXconfig.ini for this command to have any effect.
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.
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.
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...).
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:
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,
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".
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.
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.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:
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:
SaveMethod Settings (use as value for "SaveMethod" INI entry)
Notes:
"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:
* 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
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 320x240 to 640x480, 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:
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.
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).
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.
Displays Anne's current HitPoints and MaxHitPoints values.
Sets Anne's HitPoints and MaxHitPoints values to approximately 2 billion.
Resets Anne's HitPoints and MaxHitPoints values to their original quantities.
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
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.
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).
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.
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.
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.
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.).
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:
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.
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.
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).
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.
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.
* 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.
* 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 640x480 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 640x480 maximum resolution for SMK video files. All video files must still be encoded at 640x480 or lower resolution; they will simply be resized at playback by this feature to match the user's resolution.
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.000000Other 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.
* 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. |
| JumpAngle | Floating-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. |
| RepeatPeriod | INTEGER value, in milliseconds | This 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). |
| TendancyCheckPeriod | INTEGER 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:
|
* 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
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
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.
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.
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:
(* 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:
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:
OTHER NOTES:
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
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.
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:
NOTES:
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:
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 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
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.
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).
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.
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.
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).
*** 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.
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.
* 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).
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 800x600, you would have DefaultResizeXRes=800 and DefaultResizeYRes=600.
Notes:
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).
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.
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:
These keywords are used in the following files from the "MAPS\" folder:
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.
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.
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.
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=800x600, 1024x768, 7456x2343
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 7456x2343 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.
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) *:
* 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 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.
* 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.
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).
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.
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.
* 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:
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).
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.
group Action00 = {
int ActionType = 105
string Sample = [video filename as "menu\[videoname]" -> 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.
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.
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).
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.
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:
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.
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.
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.
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):
LoopCount values (mouse):
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.
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.
* 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.
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.
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.
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.
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).
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.
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).
* 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.
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.
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.
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).
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.
;========================================================
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
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
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.
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.
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
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).
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.
There have been many direct and indirect contributors to this mod. I should take this opportunity to thank everybody who supported me on writing this, as well as everybody who has helped and who will help with the testing and the tedious writing of INI files. Also, many of the features are based on ideas from various people, all of which deserve credit. This includes the Trescom team and many from the Trescom message board. Special thanks goes to Rebel for much help and info (*** special thanks for composing the original version of the disclaimer at the beginning of this file and for help rewording), Remdul, and madppiper.
Additional thanks:
Lastly, I have to point out that I sacrificed a lot more than I should have to work on this. So you better enjoy it!!!
EOF