Beginner Guide to Battlezone 98 Redux Modding

---

Section 1: Set Up Your BZ Files for Modding

Extract stock game files (ODFs, sounds, etc.)
You’ll need to unpack bzone.zfs to access all the stock files.

Method 1: Extract directly to Edit folder
⚠️ This will dump ~4000 files into the Edit folder. Not recommended unless it's empty!

Method 2: Extract into your own folder
1. Create a subfolder inside Edit, e.g. Edit\my_folder
2. Copy bzone.zfs into my_folder
3. Open CMD inside my_folder (tip: type in the Explorer address bar)
4. Run:
This keeps things organized. You can move the files elsewhere later if needed.

---

Launching the BZ Editor

Command prompt method:

Useful flags:
• /startedit — Launch directly into edit mode
• /edit — Enable toggling editor mode in mission
• /win — Must use for saving in windowed mode

Editor controls:
• Toggle Editor: Ctrl + A
• Terrain Paint Mode: Ctrl + E
• Save: Ctrl + S
• Top-down View: Shift + F9
• Radar View: Shift + F10

---

Create a Custom Unit

1. Open a stock ODF (e.g. svtank.odf)
2. Change the weapon slot (e.g. to use SP Stabber)
3. Add this line under GameObjectClass:
4. Save as a new ODF, like svtankcc.odf

---

Add Your Custom Unit to the Editor

1. Find a stock build menu ODF (e.g. b_amcmbt.odf)
2. Change an item to your custom unit (e.g. )
3. Save the modified file to the addon folder
4. Also place your svtankcc.odf in addon
5. Open the editor and place your new unit!

---

Section 2: Useful Tools for Modding

• Notepad++ for viewing and editing files, or scripting
  
• Command Prompt

• .VDF (Vehicle Definition File) - Defines complete vehicles with mass, collision, animations, GEO positions, and Level of Detail settings
  
• .SDF (Structure Definition File) - Same as VDF but for buildings/structures, uses only GEO collisions
  
• .GEO (Geometry) - Individual 3D model parts that combine to form complete vehicles/structures
  
• .MESH (OGRE Mesh) - Modern 3D geometry format using OGRE engine, contains vertices, faces, normals, UV coordinates
  
• .SKELETON - OGRE animation format with bone hierarchy, must match GEO naming for proper sync
  
• .MATERIAL - Defines surface properties, texture assignments, and shader properties for models

• .MAP - Legacy texture format (256x256 indexed color, various pixel formats)
  
• .DDS - DirectDraw Surface textures, modern format replacing MAP files
  
• .ACT/.PAL - Color palette files for indexed textures
  
• .TGA - Uncompressed image format for certain effects

• .HG2 - Height map data (updated version of original BZ98 .hgt format)
  
• .TRN - Terrain data including world info, sky settings, texture assignments, and map size
  
• .MAT - Material information for ground textures
  
• .BZN - Contains all game objects: units, buildings, people, powerups, scrap, spawnpoints, paths, and commands
  
• .LGT - Lighting data that must be regenerated after terrain changes

• .BMP - Preview image for multiplayer map selection
  
• .DES - Map description text
  
• .VXT - List of allowed player vehicles
  
• .INI - Configuration file for map metadata and Workshop settings

• .WAV - Uncompressed RIFF WAVE files for audio messages, sound effects, and voiceovers
  
• Must be uncompressed format for game compatibility

• .LUA - Lua 5.1 scripts for mission logic and AI behavior

• .ODF (Object Definition File) - Defines unit properties, weapons, behaviors, and metadata
  
• Must be 8 characters or less in filename
  
• Contains all gameplay parameters for units

• .ZFS - Compressed archive format using LZO compression
  
• bzone.zfs - Main game assets (models, textures, sounds, ODF files)
  
• bzone_en.zfs - Localized voiceovers

The game uses a hybrid system:

• Legacy formats (VDF/SDF/GEO/MAP/ODF) for physics, collision, and game logic
  
• Modern OGRE formats (MESH/SKELETON/MATERIAL/DDS) for visual rendering
  
• This dual system allows enhanced graphics while maintaining original game mechanics

Problem: Multiplayer shows "Not Ready" status and won't connect
Solution: Uncheck IPv6 in network adapter settings in Windows

Steps:
1. Open Control Panel → Network and Internet → Network Connections
2. Right-click your network adapter → Properties
3. Uncheck "Internet Protocol Version 6 (TCP/IPv6)"
4. Click OK and restart the game

Alternative Solution:
• Use Windows Network Reset: Settings → Network & Internet → Status → Network Reset
• This will reset all network adapters and may resolve IPv6 conflicts


The #1 cause of texture loading problems

Rule: TRN files MUST use CRLF (Windows line endings)
Cannot handle: CR (Mac line endings) or mixed line endings
Result of wrong endings: Textures won't load, terrain appears white/black

Symptoms:
• Map loads but textures don't appear
• Terrain appears completely white or black
• "Invalid TRN data" error messages
• Textures work in editor but not in game

Solutions:
• Use text editors that preserve CRLF line endings (Notepad++, Visual Studio Code)
• When copying TRN data between systems, verify line endings
• Convert line endings: LF → CRLF or CR → CRLF
• Avoid Mac-based text editors that default to CR line endings

Text Editor Line Ending Settings:
• Notepad++: Edit → EOL Conversion → Windows (CRLF)
• Visual Studio Code: Bottom status bar shows line ending type, click to change
• Sublime Text: View → Line Endings → Windows


Check these in order:
1. Verify all essential files present: .hg2, .trn, .mat, .bzn
2. Check TRN file line endings (must be CRLF)
3. Ensure map is in correct addon folder or subfolder with .ini file
4. Verify launch options syntax: mapname.bzn /startedit

Primary cause: TRN file line ending issues (see above)
Other causes:
• Missing or corrupted .mat file
• World TRN data not properly copied
• Size section accidentally removed from TRN file, or two sections duplicated
• Wrong texture file paths in TRN


• Check Cell Types view (yellow areas = AI cannot access)
• Terrain too steep for AI navigation (>45° slopes)
• Missing proper transition slopes between elevations
• Buildings placed on inaccessible terrain
• Use Slabs view to verify AI accessibility


• Missing spawnpoints (required for all multiplayer maps)
• Incorrect .ini file configuration
• Wrong mapType setting in .ini file

• Incorrect path naming format (should be: powerup_respawntime_number)
• Invalid ODF names in path names
• Paths placed in inaccessible locations
• Missing powerup ODF files

• Host and clients have different mod versions
• Network ports blocked (check firewall)
• IPv6 conflicts (see network troubleshooting above)
• Map files still present in addon that cause a conflict


• Missing preview image (.jpg format, same filename as map)
• Missing or incorrect .ini configuration file
• Files not in same folder
• Preview image not square format
• File size too large for Steam Workshop


• Always use CRLF line endings for TRN files
• Check file path separators when sharing (\\ vs /)
• Verify case sensitivity in filenames (Linux is case-sensitive)
• Test on target platform before publishing


When a map doesn't work, check these in order:
1. ✓ All required files present (.hg2, .trn, .mat, .bzn, .lgt)
2. ✓ TRN file uses CRLF line endings
3. ✓ Map in correct folder with .ini
4. ✓ Launch options correct
5. ✓ No special characters in filenames
6. ✓ Spawnpoints placed for multiplayer maps


When asking for help, include:
• Exact error messages
• Your operating system
• Game version (BZ98R Steam vs Gog etc.)
• Map type (SP, MP, DM, Strategy)
• Steps you've already tried
• Screenshots of errors when possible

Common Resources:
• Battlezone Discord servers
• GitHub repositories for tools

Running BZR on Linux:
- Recommended Distributions: Any modern distribution can easily run BZ, however there are more user-friendly options when first starting out. Listed in order of recommendation:
• New Users:
• PopOS!: As of July 2025 stick to 22.04 for a very stable X11 Linux gaming experience
• Mint: Good option (better than Ubuntu, but KDE is a horrible workflow)
• Bazzite
• Nobara
• CachyOS
• Most stable gaming experience with highest FPS:
• Arch (btw) w/ Hyprland
• Debian Trixie w/ KDE, Gnome (or i3)
- Dual Boot Setup: Using separate hard drives for a dual boot setup ensures a new user won't accidentally wipe their system (disconnect Windows drive during Linux installation)
- Nvidia Graphics: No longer an issue
- Proton Compatibility: Battlezone works very well with Steam's Proton
- Shared Storage: NTFS partitions can be shared between Windows and Linux for game files however this will slow down performance and some distros do not support NTFS

Welcome to the Moon, Commander!

Mapmaking is the art of creating singleplayer missions and multiplayer maps for Battlezone. They are the most common type of mod for the game. With a little bit of time and effort, you can create something for you and your comrades to enjoy!


Every map needs at least three essential files that are automatically generated when you begin the mapmaking process:

Core Terrain Files:
• .hg2 - The heightmap of your terrain (hills and valleys). Updated version of .hgt from original BZ98
• .trn - Stores terrain data including world, sky, and map size
• .mat - Material information for ground textures

Essential Game Files:
• .bzn - Units, buildings, people, powerups, scrap, spawnpoints, and all objects. Also stores paths and commands
• .lgt - Lighting data that needs regeneration after terrain changes

Optional Multiplayer Files:
• .bmp - Preview image displayed in multiplayer map list
• .des - Map description when selected
• .vxt - List of allowed player vehicles


Singleplayer Missions (Instant Actions/IAs):
• Range from simple one-objective skirmishes to complex dynamic scenarios
• Require AI setup and scripting

Multiplayer Maps:
• Deathmatch (DM): 8-player maps focused on combat and powerup collection
• Strategy (ST): 2-4 player base-building and destruction maps
• King Of The Hill (KOTH): Control point focused gameplay
• Multiplayer Instant (MPI): Instant action scenarios for multiple players
• Multiplayer Action (MPA): Action-focused multiplayer scenarios


Location: Found in Edit folder of Battlezone installation
Usage: Console program run via Command Prompt

Navigate to directory:

Basic command:

MakeTRN Parameters:
• /c - Creates new map
• /w=nnnn /h=nnnn - Width and height in meters (must be divisible by 1280)
• /p=ParameterFile - Autopainter tool for texture placement
• /e=EmptyElevation - Background terrain height

Common map sizes: 1280x1280, 2560x2560, 3840x3840, 5120x5120

Example:

Move files to Battlezone's addon folder
Select world by copying world .trn data from Edit/trn folder
Preserve Size section in your map's .trn file when copying world data
Set launch options in Steam: mapname.bzn /startedit

⚠️ CRITICAL: TRN File Line Endings

TRN files MUST use CRLF (Windows) line endings
Cannot handle CR (Mac) line endings
Mixed line endings will prevent texture loading
Use a text editor that preserves or allows setting CRLF line endings
Common issue when copying TRN data between different operating systems

Key Bindings:

Ctrl+A - Start/stop game simulation (pause/unpause)
Ctrl+E - Enter Terrain Editor
Shift+F9 - Enter Object Editor
Shift+F1 - Exit editors and return to normal view

Access with Ctrl+E for birds-eye view of map.
Navigation:

Arrow keys rotate viewpoint
Mouse to screen edges moves view
W switches between texture and height modes
Tab changes wireframe colors in height mode

Texture Types:

Solids - Basic textures (lava, rock, etc.)
Caps - Transitions between textures
Diags - Diagonal transitions between textures

Texture Tools:

Eyedropper - Copy texture for paintbrush
Rotate - Rotate textures (right-click for clockwise)
Vertical/Horizontal Flip - Flip textures (H key for horizontal)
Paintbrush - Place copied texture (P key)
Zoom - Zoom in/out (+/- keys)
Cycle Texture - Cycle through solids (S key)
Cap Texture - Cycle through caps (C key)
Diag Texture - Cycle through diags (D key)
Variant Texture - Cycle through variants (A key)

Height Editing Tools:

Eyedropper - Copy height for flatten tool
Incremental Area - Raise/lower terrain in selection area
Incremental Circle - Raise/lower in circle with bell curve
Flatten Area - Flatten to copied height
Bell Tool - Raise/lower in bell shape
Incremental Point - Modify single point
Set Width/Depth/Height/Bell Width - Adjust tool parameters
Set Increment - Adjust increment amount
Smooth Tool - Smooth single terrain point

Access with Shift+F9 for top-down technical view.
Control Modes (Press 1 + number):

Find Path - Calculate distances between points
Edit Path - Place AI paths (left click place, right click deselect)
Edit Task - Set object commands and tasks
Edit Objects - Move objects (drag) and rotate (right-click)

Draw Modes (Press 2 + number):

Slabs - AI accessibility (Blue=easy, Grey=steep, Yellow=impossible)
Goals - Strategic AI decisions
Priorities - Strategic AI priorities
Paths - Display placed paths
Surface - Ground textures
Height - Relative elevation (Blue=low, White=high)
Slope - Terrain steepness (Blue=flat, White=steep)
Cell Type - AI accessibility at all locations
Cell Region - AI reachable areas (Grey=accessible, Black=not)

Other Controls:

Edit Mode (3+1/2) - Toggle simulation like Ctrl+A
Resources - Add/subtract scrap and pilots for teams
Build Menu - Place objects by team
Team Setting - Set team for placed objects

All Multiplayer Maps Need:

Spawnpoints - Found in Buildings section of Build Menu

Strategy Maps Need:

Geysers - Resource generation points
Scrap - Collectible resources
Check AI accessibility with Cell Types/Slabs view

Deathmatch Maps Need:

Weapon/Powerup Spawns - Create paths with naming format:
• Replace powerup with ODF name (apstab, apammo, aprepa, etc.)
• Replace respawntime with seconds to respawn
• Replace number with spawn point number

Create configuration file with same name as map:

Saving BZN Files:

Save your BZN with /asciisave flag
You will need to change the mission type in the .BZN depending on map type

Mission Type Setting:

Valid Mission Types:

• Inst4XMission - Instant Action maps
  
• MultDMMission - Multiplayer Deathmatch maps
  
• MultSTMission - Multiplayer Strategy maps
  
• LuaMission - Lua-scripted missions

Prerequisites:

All map files in same folder
Square preview image (200x200+ pixels, .jpg format, same filename as map)
Configuration .ini file

Steps:

Open Steam Library → Tools
Launch "Battlezone 98 Redux - Uploader Tool"
Enter map name and description
Click "Create New Item"
Select map folder and preview image
Upload to Workshop

Generate Preview Image:

Use /shellmap launch flag to auto-generate .bmp preview
Image appears in Battlezone root directory

Strategy Maps:

Equal scrap distribution near all spawn points
Flat areas for base building near geysers
Strategic terrain features between spawn points
Consider early, mid, and late game scenarios

Deathmatch Maps:

Balanced powerup distribution relative to spawn points
Central areas typically see most combat
Varied terrain for tactical options
Fair respawn locations

Instant Action Maps:

Focus on mission objectives over balance
Create immersive environments appropriate to world
Consider AI pathing limitations on steep terrain

Technical Tips:

Use cap and diag textures for smooth texture transitions
Ensure AI can access intended areas (check Cell Types view)
Keep terrain relatively flat where AI needs to build or travel
Test map thoroughly before publishing
CRITICAL: Ensure TRN files use CRLF line endings

Background Terrain:
Fix ugly map edge dropoffs using:
Or use edge_path for manual boundary setting.

Battlezone's AI system is highly configurable through AIP files (Artificial Intelligence Personality files). These control how computer-controlled teams behave strategically - what they build, where they send troops, and how they react to different situations.


AIP files use C-style syntax with comments and are divided into several key sections:



threat_priority = 150
- Higher values make AI more aggressive toward enemy concentrations
- Typical range: 100-200

distance_priority = -3
- Negative values prefer closer objectives
- Positive values make AI willing to travel farther
- Typical range: -10 to 10

attack_enemy_base_priority = 75
- How much AI prioritizes attacking enemy buildings
- Higher = more base-focused attacks

persistence_priority = 30
- Prevents AI from constantly switching objectives
- Higher values create more focused, committed behavior


The BUCS controls what the AI builds through Accounts - separate budgets for different purposes:




NUMBER_TO_HAVE - Maintain specific count
- = Keep exactly 3 of this unit on map

NUMBER_TO_BUILD - Build specific amount once
- = Build 5 units then stop

RATIO_TO_BUILD - Continuous production in ratios
- = Build in 2:1:1 ratio with other RATIO units at same priority

RATIO_TO_HAVE - Maintain ratio, then continue production
- Checks current units, builds to correct ratio, then continues








Reference AIP files in your mission's setup to give computer opponents distinct personalities suited to your map's design and intended difficulty.

This comprehensive reference covers all available ODF class parameters for Battlezone 98 Redux modding. Each class inherits from base classes and adds specific functionality for different unit types.

---


Purpose: Ammunition pickup items

Purpose: Armored Personnel Carriers that deploy soldiers

Purpose: Base class for all vehicles and movable units

Scanning & Detection:

Pilot Ejection:

Voice Messages:

Purpose: Walking mechs with detailed movement physics

Grounded Movement (Run Mode):

Airborne Movement (Fly Mode):

Audio:

---


Purpose: Weapon upgrade buildings

Purpose: Pilot training facilities

Purpose: Base class for all structures

Purpose: Communication and radar buildings

Purpose: Vehicle repair facilities

Purpose: Resource storage buildings

Purpose: Defensive shield generators

Purpose: Ammunition resupply buildings

---


Purpose: Continuous beam weapons

Purpose: Lightning/electrical weapons

Purpose: Direct-fire projectile weapons

Purpose: Weapons that charge up before firing

Purpose: Rapid-fire projectile dispensers

Purpose: Remotely triggered explosive weapons

Purpose: Lock-on guided weapons

---


Purpose: Rockets that anchor/tether to targets

Purpose: Devastating explosive projectiles

Purpose: Self-propelled explosive projectiles

Purpose: Heat-seeking guided missiles

Purpose: Self-guided terrain-following projectiles

Purpose: Visual bullet trail effects

---


Purpose: Nav Beacons

Purpose: Special Assault Vehicles with flight capability

Purpose: Resource collection units

Purpose: Weapon that can change team allegiance

Purpose: Units that can tow/transport other units

Purpose: Deployable turret vehicles

---


Purpose: Flame thrower effects

Purpose: Area-effect spray weapons

Purpose: Building-mounted spray weapons

Purpose: Proximity-triggered explosive mines

Purpose: Weapon upgrade pickups

---


Purpose: Explosion effects and damage

Purpose: Seismic wave attacks

Purpose: Radar-guided projectile launchers

• Float values: Most parameters accept decimal numbers
  
• Integer values: Counts and indices typically use whole numbers
  
• String values: Sound files, class names, and messages use quoted strings
  
• Boolean values: Use
  true
  or
  false
  for on/off settings

DeleteObject() Behavior:
DeleteObject() makes all properties of that object inaccessible the moment a unit is flagged as destroyed. The only exception is the handle and objective name.

DisplayMessage and Command Limitations:
• DisplayMessage and /Command only work in Multiplayer
• They do NOT work in single player/offline
• For debugging: Always use print
• Status updates: DisplayMessage is acceptable for multiplayer use

Broken Functions:
• iterator ObjectiveObjects() is broken as an iterator and only returns the first result (engine bug)
• Recommendation: Do not use this function


Your basic Lua script has six essential components:

GetPlayerHandle Team Number Issue:
Passing a team number into GetPlayerHandle does not work properly and will always return nil instead of the remote player's handle.

Workaround: You get around it by collecting handles matched to teams on player join.

String Null Character Problem: Some Battlezone Lua functions return strings with invisible null characters that break string comparisons.

Affected Functions:

• GetOdf()
  
• GetPilotClass()
  
• GetWeaponClass()
  
• GetClassSig()
  
• GetBase()

Solution: Add this code at the top of your Lua script to automatically fix all affected functions:


What this does:

• Automatically strips null characters (\0) from function returns
  
• Maintains proper error handling with correct line numbers
  
• Works transparently - no changes needed to existing code
  
• Fixes string comparison issues that plague Battlezone modding

Usage: Simply paste this at the top of any mission script and all string comparisons with these functions will work correctly.

Custom campaigns allow you to create connected series of missions that tell a complete story. Unlike standalone maps, campaigns feature mission progression, cutscenes, custom briefings, and persistent narrative elements across multiple levels.
Core Campaign Files:

.ini - Campaign configuration file (defines mission order, settings, and metadata)
.bzn - Individual mission files for each level
.bmp - Campaign preview image displayed in custom campaign menu

Optional Enhancement Files:

.ogv - Cutscene videos played after missions
.png/.dds - Custom loading screens for missions
.wav - Custom voice files and audio
Custom world images or videos for planet selection screen

The campaign INI file controls the entire campaign structure and presentation:

missionName - Display name for the mission
missionBZN - Filename of the mission's BZN file
planet - Planet environment (moon, mars, venus, io, europa, titan)
missionBG - Background image for mission briefing


voice - Audio file for mission briefing narration
descColor - RGB color values for mission text (format: "R, G, B")
gift - Cutscene video played after mission completion
loadingBG - Custom loading screen image for the mission

⚠️ CRITICAL: BMP Image Specifications
The campaign preview image has strict requirements:

Format: BMP (bitmap) format only
Bit Depth: Must be saved as 24-bit
Color Space: Save with "Do not write color space information" option
Failure to follow these specs will crash the game

Image Guidelines:

Use clear, representative artwork for your campaign
Keep text readable at various sizes
Consider the campaign's theme and story
This image is separate from your Steam Workshop .jpg preview

Campaign cutscenes use the gift parameter and have strict technical requirements:
Format Specifications:

Container: OGV (Ogg Video) format only
Frame Rate: Exactly 30 FPS
Audio Codec: OggVorbis
Video Codec: Theora (standard for OGV)

Recommended Tools:

FFmpeg (command line)
VLC Media Player (can convert to OGV)

⚠️ IMPORTANT: Use ANSI Encoding

All text files must use ANSI/ASCII encoding
UTF-8 or Unicode encoding will cause wrong character display
Avoid special characters that aren't in standard ASCII
Test all text displays in-game

Text Scrolling Issues:

Keep briefing and debriefing text compact
Long text blocks may break the scrolling system
Text may not display properly if too lengthy
Test scrolling behavior with your content

You can customize the planet selection screen beyond the standard planets:
Custom World Images:

Replace default planet spinning animations
Use custom static images for unique worlds
Follow standard planet image formats

Custom World Videos:

Create custom .ogv videos for planet selection
Same technical requirements as cutscenes (30 FPS, OggVorbis)
Can show animated environments or custom worlds

Based on the "Rise of the Black Dogs" campaign:

Battlezone 98 Redux uses a modern terrain system with the following file types:

Core Files:
• .DDS - Texture atlas containing all terrain textures (DXT1 compression, 1024x1024 or larger)
• .CSV - Bridge file mapping texture names to atlas coordinates
• .TRN - World configuration file referencing texture names
• .material - Material definition linking DDS files


MAP File References (in TRN):
The .MAP filename structure determines texture usage:
• Planet Code (2 letters): EU, IO, VE, etc.
• Transition Code (2 digits):
• 00 = texture 0 to texture 0 (solid, non-transitional)
• 01 = texture 0 to texture 1 (transitional)
• 23 = texture 2 to texture 3 (transitional)
• Type Letter:
• S = Solid texture
• C = Cap (edge transition)
• D = Diagonal transition
• Variant Letter: A, B, C, D (texture variations)
• LOD Number: Always 0 for Redux

Examples:
• EU00SA0 = Europa solid texture 0, variant A
• EU01CA0 = Europa cap transition from texture 0 to 1, variant A
• EU23DA0 = Europa diagonal transition from texture 2 to 3, variant A
• EU33SA0 = Europa solid texture 3, variant A (use same digit for solids)


• Arrange texture squares in logical order (sand → dirt → rock)
• Use 2048x2048 or larger canvas
• Export as PNG first, then convert to DDS (DXT1 compression)



• Set atlas name under [Atlases] section
• Reference texture names in [TextureType] sections


Important: The .MAP files themselves are not needed in Redux - they're just references in the TRN file to coordinates in the CSV file, which point to the atlas image.


• Image editing software (Photoshop, GIMP, Paint Shop Pro)
• PEdit - Palette editor for ACT/PAL files


Solids: Homogenous textures that border with same-type textures or variants
Caps: Mostly solid with one edge blending to different texture
Diagonals: Equally divided between two textures along diagonal axis


Files:
• .MAP File - Original texture reference, not needed in Redux
• .DDS File - DXT1 compressed texture (1024x1024, 1 layer, sRGB)
• .Material File - References DDS and MAP (use stock ganymede file as template)
• TRN File - References the .MAP file
• Subfolder Structure - Place in addon with .ini file specifying it's a mod


Individual Sky Objects:

Full Sky Coverage:


Important Indexing Difference:
• PEdit: Starts at index 1
• BZ Game: Reads from index 0

Conversion Rule: To adjust index #223 in BZ, change #224 in PEdit

Format: byte [256][3] (color index → R G B)
Name: Read from .TRN [Color] Palette property

Color Index Assignments:
• Index #0-95: Objects
• Index #96-223: Planet-specific colors
• Index #224-255: Objects (secondary range)

Special Color Indices:
• Index #223: Controls sky color and sniperscope color
• Index #209: Fog color

Important Note: The fog color affects some sky coloring on certain planets, but other color files control the extent of fog color usage for sky rendering. Always use index #223 for sky color in all cases.

The autopainter automatically applies textures based on elevation and slope parameters, eliminating manual texture placement.

Create Shortcut:
Analyze Terrain:
• Enter terrain editor (Ctrl+E)
• Switch to texture view to identify existing textures
• Switch to height view (Z key) to record elevations
• Note slope angles (estimate visually or calculate)
Create INI File:
Name it uniquely (e.g., mapname.ini or custom_terrain.ini). You can actually use whatever file extension you want here, as long as it uses .ini formatting. So I will often use myworld.paint so it doesn't interfere with mod .ini definition files.

Material Numbers:

Correspond to [TextureType] order in TRN file
First texture = Material 0, second = Material 1, etc.
Independent of actual [TextureTypeX] numbers

Coverage Requirements:

All elevations and slopes must be covered
Gaps cause makeTRN to fail with "missing parameters" error
Overlaps cause similar errors
Use consecutive numbers (end one layer where next begins)

Success Indicators:

"Computing materials" message
"Writing out material file" confirmation
No error messages about missing coverage

Variant Ratios:
If you list the same variant multiple times in different Solid slots, maketrn will paint them in that ratio:
Results in 3:1 ratio of variant A to variant B.

Copy all .map files to working folder
Include planet.act palette file
Add makemap.exe to folder

Converts all MAP files ending in 0 to BMP format.

Use texture files ending in 0 (first mipmap)
Arrange in logical progression
Maintain 256x256 individual texture size

Color Index Guidelines:

Indices 0-95: Reserved for objects
Indices 96-223: Planet-specific colors
Indices 224-255: Object colors (secondary)
Index 223: Sky and sniperscope color
Index 209: Fog color

Best Practices:

Use common color schemes (browns, reds, etc.)
Reserve more colors for light/medium textures
Use fewer colors for dark textures
Test under different lighting conditions (Time = 900 vs 1200 in TRN)


Seamless Tiling: For moving skies, apply seamless tiling filter
Alpha Channels: Use for transparency effects in 16/32-bit textures
Size Considerations: Larger textures for better quality, but watch file sizes
Color Matching: Ensure sky color complements terrain palette

Working With Custom Sprite Tables

If you're adding new reticles, particle effects, or explosion animations to Battlezone 98 Redux, you can do so by using a custom sprite table file.

TL;DR: Just include a

spritea.sta

file in your mod folder. The game will load it automatically. It defines which sprite names point to what part of which texture, using pixel-based coordinates.

How Sprite Tables Work

Battlezone uses to define sprite frames used in the HUD, weapon reticles, effects, explosions, etc. Feel free to reference this stock file.

Each sprite entry tells the game:

• What the sprite is named (referenced in an ODF or effect),
  
• Which material it uses (links to a .material file),
  
• Where to find it on the texture (start X/Y, width/height),
  
• What the full image resolution is (ref width/height),
  
• And any flags for special rendering.

Basic Setup Steps

1. Include a file named
   spritea.sta
   in your mod's root folder.
   
2. Create one or more
   .material
   files that reference your texture files.
   
3. Use the sprite names in your ODFs or effect definitions (e.g.
   wpnReticle = gacidsta
   ).

Example Sprite Entry


This means:

• gacidsta is the sprite name used in-game (such as in an ODF)
  
• reticlesheet1 is the material file (must be named
  reticlesheet1.material
  )
• Starts at X=0 Y=0 on the image
  
• Uses a 256×256 pixel region
  
• The full image is 1024×1024 pixels
  
• Flags are
  0x00000000
  (no special behavior)

Material File Example

Your file should look like this:


You can change and depending on the look you want (e.g. for additive glowing effects).

Helpful Notes

• All coordinates and sizes are in pixels, not normalized UVs.
  
• Think of the image like a grid — a 1024×1024 texture divided into 4 rows × 4 columns = 256×256 blocks.
  
• Use GIMP, Photoshop, or paint.net to measure pixel positions.
  
• You can animate effects by naming frames like
  dust.0
  ,
  dust.1
  , etc.
  
• Don’t forget to include your material and texture files with your mod.

Working With Ogre Material Scripts in Battlezone 98 Redux

Battlezone Redux uses Ogre3D material scripts[wiki.ogre3d.org] to define how textures are rendered, including properties like glow, transparency, scrolling, and multi-pass effects.

Material scripts define how a texture looks in-game, including lighting, blending, emissive glow, and animation.


Material files use this general structure:



This material scrolls a diffuse texture vertically and adds a glowing (emissive) layer:


Key Features:

• scroll_anim 0.0 0.4
  → Scrolls the texture vertically over time
  
• emissiveMap
  → Adds a glow layer (usually for cockpit lights or effects)
  
• scene_blend add
  → Makes the glow additive
  
• depth_write off
  → Prevents Z-fighting on effects

Great for objects like leaves or smoke:


Key Features:

• alpha_blend
  → Uses the alpha channel for transparency
  
• cull_hardware none
  → Renders both sides of the mesh
  
• depth_write off
  → Optional; helps with layering

This setup is ideal for particle textures, banners, and foliage.


Battlezone Redux uses inheritance to simplify standard materials:


How It Works:

• import * from "BZBase.material"
  → Inherits from a common template
  
• set_texture_alias
  → Replaces the default texture used for each map
  
• $diffuse
  ,
  $glow
  , etc. tweak the lighting behavior

Use this format for most standard vehicles and buildings in Redux.

More Info
Full Ogre Material Scripting Reference:
https://wiki.ogre3d.org/Materials

Custom TRN Cubemaps (Skyboxes) in Battlezone 98 Redux
Updated process for using HDRI, PNG, or JPG equirectangular panoramas


Step 1: Get a Panorama
Your image must be either:

• 2:1 equirectangular (e.g. 4096×2048)
  
• 4:1 extended panoramas (e.g. 4096×1024 — see special notes below)

Acceptable formats: .png, .jpg, etc.

Step 2: Convert to Cubemap Faces
Use any standard cubemap generator to convert your 2:1 image into 6 cube faces:

Tools like “Panorama to Cubemap” or Blender + Bake Cubemap can do this.
Output resolution should be consistent (e.g. 1500×1500 each face).

Step 3: Create Material Files for Each Face
Each .map or .dds texture must be defined in a .material file like this:


Repeat for all six sides, naming the materials , , etc. to match the filenames.


Inside your .trn file, add the following section:


Adjust:

Size: the width of your cubemap faces

Radius: typically
Azimuth: sets direction for each face (0° = north)

Roll: used to align seams. 180° usually fixes top (PY) alignment

Important: You must put all .map, .material, and .png/.dds files into a subfolder in your directory for the game to load them properly.


You can convert a 4:1 aspect ratio image into a valid 2:1 panorama using this trick:

• Open the image in Photoshop, GIMP, or other editor
  
• Double the canvas height (make it 4:2) — leave bottom half blank or mirror the top so it blends naturally
  
• Export and convert to cubemap as usual

Tips:

Put visible text or a landmark in the empty bottom half — helps you identify which face may be flipped

You may need to flip or rotate some faces manually (e.g. swap pz ↔ nz, rotate side faces by 180°)

Need a Tool?
Try these options:

• Panorama to Cubemap (web tool)[jaxry.github.io]
  
• Blender with UV Projection and Bake to 6 faces
  
• Unity/Unreal cubemap generators

• Format: Microsoft WAVEX
• Bit Depth: 8-bit unsigned
• Sample Rate: 22050 Hz
• Existing Files: 8-bit mono 11025 Hz (system supports other rates/depths)
• Music: Only music system can use OGG files

• Place WAV files in addon/[yourmod]/ folder
• Reference in ODF files using relative paths
• Test audio files in-game to verify proper format

• Sounds not playing: Check file format (must be Microsoft WAVEX)
• Audio crackling: Sample rate too high, use 22050 Hz or lower
• File too large: Use 8-bit compression for smaller file sizes
• Wrong path: Verify file path in ODF matches actual file location



Sunlight Configuration:

• Ambient: Overall brightness level, affects shadows
• Diffuse: Main light color, affects object coloring
• Specular: Highlight color, affects shiny surface reflections
• Values: Range from 0.0 (black) to 1.0 (full brightness)
• Color balance: Adjust RGB ratios for different moods (red for Mars, blue for ice worlds)



Redux added new animation indices for pilots:
• idleParachute: index 9
• landParachute: index 10
• jump: index 11

Important: Pilot animation speeds are hardcoded in BZR. Looping animations and their speed are hardcoded depending on the name of the animation. Pilots are the only objects that do NOT use .VDF animation, and instead use Ogre's skeletal animation.

• .skeleton - Bone structure for animated models
• .mesh - 3D model with animation data

• Use existing skeleton files when possible
• Match bone names exactly to original models
• Test animations at different speeds
• Ensure looping animations seamlessly connect end-to-start


• draw_bolt - Lightning/electrical effects
• draw_emit - Particle emission effects
• draw_light - Light source effects
• draw_multi - Multiple layered effects
• draw_null - Invisible placeholder
• draw_planar - Flat sprite effects
• draw_shock - Shockwave/explosion rings
• draw_sphere - Spherical effects
• draw_sprite - 2D sprite effects
• draw_tracer - Bullet trail effects
• draw_twirl - Spinning/rotating effects
• draw_twirl_trail - Spinning trail effects





The game defines several global explosion classes that serve as defaults:



Building Death:
• Uses ODF explosion class if available
• Otherwise: xplBuilding if radius > 5m, xplVehicle if 2-5m, xplSecondary if ≤ 2m

Craft Death:
• Initial death: uses ODF class or xplVehicle
• Sniped pilots: uses xplSecondary if not set in ODF
• Dying explosions: uses xplSecondary if not set in ODF
• Final explosion: uses xplDetonate if not set in ODF
• Ground splash: uses xplGround

Person:
• Uses ODF class or xplSecondary

PowerUp:
• Uses ODF class or xplVehicle if radius > 3m, xplSecondary if ≤ 3m





Prerequisites:
• Kenshi IO Continued Blender Plugin
• Blender with basic knowledge
• Ogre Command Line Tools
• VDF/SDF Blender Plugin from Commando

Basic Process:
1. Create base object in Blender
2. Export as SDF
3. Add to map in hidden area
4. Configure BZN file
5. Import terrain for reference
6. Place and arrange props
7. Export final mesh

• Use Kenshi exporter with: tangents, apply transform, apply modifiers
• Enable "Apply Transform" and "Apply Modifiers"
• Run resulting .mesh through Ogre Mesh Upgrader
• Place final .mesh in mod folder

If you're working on a custom race/faction and want a fully custom HUD, you'll need the following components:


1. Letter Selection
• Choose a unique letter identifier
• Cannot use: a, s, b, c, or h (reserved for existing HUDs)
• This letter will be used in the material file naming

2. HUD Image
• Create your custom HUD image (e.g., RaceHUD.png)
• Standard HUD image format and dimensions
• Use existing HUD as template for sizing and layout

3. Material File
• Create a .material file that associates your HUD image to the race letter
• Filename: Must match your HUD image filename (e.g., RaceHUD.material)




1. Choose Race Letter: Select an unused letter (not a, s, b, c, or h)

2. Create Material File:
• Copy the template above
• Replace X in HUDcombX with your chosen race letter
• Replace RaceHUD.png with your actual HUD image filename
• Save as [YourHUDImageName].material

3. Important Notes:
• Keep the import line exactly as shown - it tells the game how to process the HUD
• The material file must have the same base filename as your HUD image
• Remove all comments (lines starting with //) from the final file
• Stock BZ already uses some prefixes, they include i, s, f, b, c, a.


For a custom race using letter z with HUD image MyCustomHUD.png:

File: MyCustomHUD.material


Image Specifications:
• Use standard HUD dimensions (typically power of 2)
• PNG format recommended for transparency support
• Consider different screen resolutions

Design Elements:
• Radar area (circular or rectangular)
• Weapon display areas
• Health/damage indicators
• Ammunition counters
• Mini-map space
• Status indicators

Color Schemes:
• Match your faction's theme colors
• Ensure good contrast for visibility
• Consider colorblind accessibility
• Test in different lighting conditions


1. Place files in addon folder
2. Set your units to use the custom race letter
3. Test in-game to verify HUD appears correctly
4. Check all HUD elements function properly
5. Test with different screen resolutions

The APCClass controls how Armored Personnel Carriers deploy and manage soldiers.


• soldierType must reference a valid soldier ODF file
• Higher soldierCount allows more deployments before reloading
• Lower soldierDelay creates faster deployment waves
• reloadRange determines how close APC must be to reload points
• Adjust reloadReset to balance deployment frequency


PersonClass controls how pilots and soldiers move and behave.





Movement Control:
• velocForward/Reverse/Strafe: Maximum movement speeds in each direction
• accelThrust: How quickly the unit accelerates to max speed
• velocJump: Upward velocity applied when jumping

Orientation Control:
• alphaDamp: How quickly rotation dampens to prevent overshooting
• alphaTrack: Torque strength for reaching target orientation
• alphaSteer: Yaw torque for turning left/right

Visual Effects:
• pitchPitch: Visual pitch when looking up/down
• pitchThrust: Visual pitch when moving forward/backward
• rollStrafe: Visual roll when strafing left/right

Turning:
• omegaSpin: Max yaw speed when standing still
• omegaTurn: Max yaw speed when moving


The true speed calculation for any unit:


This formula gives you the actual maximum velocity a unit can achieve, taking into account both the turbo multiplier and drag coefficient limitations.

• 2 * velocForward: Turbo speed (double normal max speed)
• sqrt(accelThrust / coeffDrag): Physics-limited max speed
• min(): The actual top speed is whichever is lower

• Increase accelThrust for faster acceleration AND higher top speed
• Decrease coeffDrag for higher top speed without affecting acceleration
• velocForward sets the turbo speed limit
• Balance all three for desired vehicle feel

Based on the original comprehensive guide by système, updated with Redux-specific parameters


Thus far, we have seen how to make a map, how to texture it, and how to import a customized model into the game. Yet, unless we want to make a utility unit or ram into the enemies until they explode, we have yet one fundamental element to craft: a weapon. Battlezone offers a plethora of assets to assist units in combat, no matter what their category is. These assets can range from the deadliest weapon to the friendliest helper. But can we choose with what we must equip our loyal steed? That is up to you. However, it is down to us to figure out precisely what every piece of our arsenal is capable of achieving.

---

Cannon is the most basic and versatile weapon class. You press the left button and an ordnance is summoned. Any ordnance can be launched by a cannon. AI is very skilled with cannons as they can aim and fire continuously. Used for AT-Stabber, SP-Stabber, Blast Cannon, and many more.

Redux Enhancement: Cannons now support advanced parameters for burst fire and accuracy control.



Machinegun's main difference is it plays firing sound continuously while firing, stopping when you release the trigger. Perfect for rapid-fire weapons like the Rave Gun with long audio files.



For continuous beam weapons like the Flash Cannon. Does not require shotDelay and calculates damage per second automatically. Only works with "beam" ordnance.



Allows multiple ordnances with the same weapon. Different ordnances fire based on how long you hold the trigger (like the MAG Cannon). Each charge level has different ordName.



Calculates trajectory arcs for indirect fire. Can hit targets behind cover using ballistic paths.



For manually detonated weapons like the MDM Mortar. Fire to launch, fire again to detonate all active projectiles.



Special mortar that deploys a secondary ordnance when it detects enemies. Complex weapon requiring fireAngle for proper arc calculation.


Tag-then-salvo system like the TAG Cannon. First shot tags target, subsequent shots fire guided missiles at the tagged location.



Three types for direct missile guidance without tagging:

• imagelauncher: Uses visual targeting (Shadower Missile)
  
• thermallauncher: Tracks heat signatures (Hornet Missile)
  
• launcher: Basic missile guidance (unused in stock game)

Launches objects (not ordnance) that seek radar signatures. Used by Comet Cruise Missile to deploy tracking objects.


Spawns any valid physical object in the game - mines, torpedoes, even units! Objects spawn with no initial velocity and may get stuck in the caster.



Does nothing but drain ammo automatically. Used for special effects that require possession indication without projectiles.

• terrainexpose: SITE Camera terrain scanning
  
• radardamper: RED Field radar jamming
  
• imagerefract: Phantom VIR cloaking

---

Simplest ordnance - displays flame sprites in sequence. Limited versatility, sprites don't loop.



Single sprite projectile with adjustable length and radius. Simple but effective for bullets and small projectiles.



Most versatile projectile with flame trail, flare effects, and smoke. Combines features of other classes.



Basic projectile used by cannon-type weapons like AT-Stabber. Simple and efficient.


Ballistic projectile affected by gravity. Shot speed determines initial velocity - higher speed = longer range but requires precise timing.



Bounces off surfaces and can be manually detonated. Used with detonator weapons. Only ordnance that explodes at end of lifespan.


Splits into multiple sub-munitions upon impact or expiration. Each fragment has its own trajectory and damage.


Instant-hit beam weapon. Creates segmented beam between firing point and target/maximum range.



Continuous damage beam for beamgun weapons. Damage applied per second rather than per hit.

Basic Missile: Guided projectile with turning capability
ImageMissile: Tracks visual signature of target
ThermalMissile: Follows heat signature within cone angle
Deploys secondary ordnance when enemies enter scan range. Complex behavior with multiple phases.
Creates earthquake effects and ground-based damage patterns. Used by Thumper and Day Wrecker.

---

• draw_null: No visual effect
  
• draw_bolt: Lightning zigzag trail
  
• draw_emit: Particle emitter
  
• draw_light: Dynamic light source
  
• draw_multi: Combines multiple renders
  
• draw_planar: Ground-projected texture
  
• draw_sphere: 3D sphere effect
  
• draw_sprite: 2D billboard
  
• draw_tracer: Straight line trail
  
• draw_trail: Projectile trail
  
• draw_twirl: Rotating sprite
  
• draw_twirl_trail: Trail of rotating sprites

• sim_null: Stationary particles
  
• sim_chunk: Bouncing debris
  
• sim_dust: Ground-spawned particles
  
• sim_ember: Falling sparks
  
• sim_spray: Collision-aware particles
  
• sim_smoke: Free-floating smoke

---

---

• Ordnance filenames:
  atstab_c.odf
  ✓
  
• shotGeometry:
  iostba00.geo
  ✓
  
• shotSound:
  weapon01.wav
  ✓
  
• xplGround/Vehicle/Building names:
  xstabgnd
  ✓

• Render names:
  atstab_c.BlueFlameTrail
• Texture names: Any length
  
• Material names: Any length

• Only ONE main header per file (e.g., one [ExplosionClass])
  
• Each render section needs unique names within file
  
• Headers like [Light], [Smoke] must be unique in same file

---

Shotgun Effect:
Burst Fire:
Use machinegun with mortar category for looped audio + advanced parameters:

---

Splinter bombs are complex dual-component weapons consisting of a bouncing ordnance (spraybomb) that transforms into a stationary turret (spraybuilding) upon landing. Here's the complete ODF structure and how to modify it:



Hidden/Special Parameters:

• Bounceratio = x - Controls bouncing behavior (0 = instant stop, 0.7 = default, 1+ = infinite bouncing)
  
• soundBounce = "filename.wav" - Sound when hitting ground (use NULL for silence)

Spraybomb (Mortar) Parameters:

• shotGeometry/shotSound - Model and sound of the flying projectile
  
• xplGround/Vehicle/Building - Explosion effects for different impact types
  
• ammoCost - Ammo consumed per shot (negative values give ammo back)
  
• lifeSpan - Set to 1e30 for effective immortality
  
• shotSpeed - Initial projectile velocity (affected by gravity simulation)
  
• damage[Ballistic/Concussion/Flame/Impact] - Damage values (negative = healing)
  
• Rocket parameters - flame, frame, smoke effects with texture, radius, and frame count

SprayBuilding (Turret) Parameters:

• payloadName - ODF of ordnance to fire (e.g., "splinter", "rocket")
  
• triggerDelay - Delay before firing starts (seconds)
  
• shotDelay - Time between individual shots (seconds)
  
• setAltitude - Height above ground (0 to infinity)
  
• omegaSpin - Rotation speed (0 = single direction, negative = reverse)
  
• anglePitch - Vertical firing angle (0 = flat disk, high values = sphere)
  
• maxAmmo - Total shots before self-destruction
  
• maxHeat - Heat resistance (useful against hornets)

IMPORTANT: Splinter effectiveness multiplies by player count in multiplayer! Each client spawns its own ordnances, so 2 players = 2x damage, 3 players = 3x damage, etc. Avoid self-replicating splinters as they create exponentially increasing lag.

Single-Shot Solution: Set ordnance ammoCost equal to spraybuilding maxAmmo to ensure exactly one shot per splinter.

• SprayBuildings can spawn ANY building type, not just ordnances - making them versatile for creative modding
  
• Unlike flares/mines, SprayBuildings are "forgettable objects" that can't be tracked via Lua but won't be auto-removed
  
• They're virtually immortal - health reaching 0 doesn't destroy them, only running out of ammo does
  
• Set lifeSpan to 1e30 (exceeds solar system lifespan) for practical immortality
  
• Use negative damage values to create healing ordnances
  
• Splinters rarely trigger XplBuilding events; they use XplGround instead when stuck on buildings

Master the splinter, sow chaos among your enemies!

What are Quake Blasts?
Quake Blasts are special explosions that spawn additional ordnance, or effects when they detonate. Perfect for cluster munitions, swarm missiles, fragmentation effects, and chain reactions.

Every quake blast needs two sections:

Critical Rules: ODF filename and quakeClass value must be 8 characters or less!


quakeCount - Number to spawn (1-50+, watch performance)
quakeClass - Which ODF file to spawn (must exist, ≤8 chars)


Basic Cluster Missile

Swarm System

Nuclear Radiation


Chain Reactions - Have spawned ordnance also be quake blasts
Directional Effects - Use different quakeClass values for patterns
Timed Sequences - Stagger with different quakeTime values
Mixed Spawning - Combine missiles, flames, debris, etc.

Basically anything that a typical weapon in a tank can fire. Not objects!

• Missiles (heat-seeking, guided, dumb-fire)
  
• Grenades (bouncing, proximity, timed)
  
• Flames (persistent fire effects)
  
• Radiation (area denial)
  
• Seismic effects (ground-shaking)
  
• Debris (visual fragments)

Optimization:

• Avoid infinite loops (quake blast spawning itself)
  
• Limit cascade depth
  
• Use efficient textures
  
• Balance visuals vs performance

• ❌ Names >8 characters → ✅ Keep ≤8 chars
  
• ❌ Missing referenced ODF files → ✅ Verify files exist
  
• ❌ Too many spawns → ✅ Start small, scale up
  
• ❌ Infinite loops → ✅ Linear progression A→B→C

• Start with quakeCount = 1
  
• Verify spawned ordnance works independently
  
• Gradually increase count
  
• Monitor performance impact
  
• Refine timing and effects

Connect to weapons via ordnance impact explosions:

• Weapons: Cluster bombs, MIRV missiles, shotgun spreads
  
• Area Denial: Minefields, radiation zones, flame barriers
  
• Visuals: Fireworks, debris clouds, energy cascades

• Start by modifying existing stock quake blasts
  
• Use clear, memorable 8-character names
  
• Always backup files before experimenting
  
• Test thoroughly in different scenarios
  
• Share creations with the community

Quake blasts unlock incredible weapon design possibilities in Battlezone. From simple clusters to complex multi-stage systems, they're essential for spectacular ordnance. Experiment safely and create devastating new battlefield weapons!

Remember: Always backup your files first!

What are Poppers?
Poppers are intelligent ordnance that act as proximity sensors, automatically launching other ordnance when enemies come within range. They're the Swiss Army knife of Battlezone modding - perfect for smart mines, auto-targeting systems, DOT effects, flak bursts, and complex multi-stage weapons.

Every popper needs these two sections:

Key Rules: All ODF filenames must be 8 characters or less!


scanRange - Detection radius in meters (10-500+ range)
launchXpl - Explosion effect when target detected (can be NULL)
launchOrd - Which ordnance to fire at target (≤8 characters)









Chain DOT Effects
Create multi-stage damage by chaining poppers:

Area Denial Fields
Multiple poppers create overlapping danger zones:

• Radiation fields with periodic damage
  
• Cryo zones that slow enemies

Staged Explosions
Combine with short lifeSpan for timed effects:


Defensive Systems

• Perimeter Mines: Standard proximity explosives
  
• Smart Barriers: Activate defenses when breached
  
• Automated Turrets: Fire at approaching enemies
  
• Warning Systems: Alert effects when area entered

Offensive Weapons

• Guided Warheads: Home in on nearby targets
  
• Flak Cannons: Explode near aircraft
  
• Cluster Bombs: Release submunitions over targets

Performance Considerations:

• Use appropriate lifeSpan to limit active time
  
• NULL explosions save rendering overhead

Design Guidelines:

• Match scanRange to intended use
  
• Short lifeSpan for temporary effects
  
• Long lifeSpan for persistent fields
  
• Consider shotSpeed for mobile poppers

Stationary (shotSpeed = 0):

• Proximity mines
  
• Area denial fields
  
• Defensive turrets
  
• Environmental triggers

Mobile (shotSpeed > 0):

• Guided warheads
  
• Seeking clusters
  
• Patrol systems
  
• Roving sensors

Timed (short lifeSpan):

• Delayed explosions
  
• Staged effects
  
• Flash-bang systems
  
• Temporary shields

Persistent (long lifeSpan):

• Radiation zones
  
• Monitoring systems
  
• Base defenses

With Weapons:

With Quake Blasts:

Chain Reactions:


Popper Not Triggering:

• Check scanRange isn't too small
  
• Verify lifeSpan gives enough time
  
• Ensure launchOrd file exists
  
• Test with visible render effects

Performance Issues:

• Reduce scanRange values
  
• Limit number of active poppers
  
• Use shorter lifeSpan values
  
• Remove unnecessary explosions

• Start with simple proximity mines before complex systems
  
• Use clear, descriptive 8-character names
  
• Test scanRange values thoroughly
  
• Combine with other systems for maximum effect
  
• Document complex chain reactions

Poppers are incredibly versatile tools that add intelligence to your weapons. From simple proximity mines to complex multi-stage DOT systems, they bring tactical depth and strategic gameplay to Battlezone. Experiment with different combinations to create unique and memorable battlefield experiences!

Remember: Poppers detect enemy units in range and only trigger on those units, not friendlies.

DOT (Damage Over Time) weapons in Battlezone work by creating a chain reaction of explosions and ordnance that continue to damage targets long after the initial impact. Unlike simple weapons that deal damage once, DOT weapons use Battlezone's QuakeBlast system to spawn additional ordnance that can bounce, persist, and explode multiple times.

• Primary Weapon: The initial weapon that fires the ordnance
  
• Primary Ordnance: The projectile that hits the target
  
• Chain Explosions: QuakeBlast explosions that spawn secondary ordnance
  
• Secondary Ordnance: Persistent damage dealers (napalm, fire puffs, etc.)
  
• Final Effects: Long-lasting area denial or continuous damage

---

The DOT system works through cascading file references:

• All ordnance files must be 8 characters or less
  
• Explosion names (xplGround, xplVehicle, etc.) must be 8 characters or less
  
• Only one Header per file (e.g., one
  [ExplosionClass]
  per explosion file)
  
• Render names can be longer than 8 characters

---

Let's trace through the complete gfirstab (Incendiary Stabber) weapon chain to understand how DOT weapons work:

---

The QuakeBlast system is the core of DOT weapons. It allows explosions to spawn additional ordnance:

⚠️ WARNING: This involves hex editing VDF files. Always backup your files before editing.

Requirements:
• HxD Hex Editor or similar
• VDF file with target geometry and a dummy geometry

Process:

1. Setup Dummy Geometry:
• In your VDF, add a dummy geo directly after the geo you want to spin
• Example: Main geo = ixx11bar, dummy geo = ixx11bat
• The dummy geo will not be used in the model/game

2. Locate and Modify Object Class:
• Open VDF in HxD hex editor
• Find first entry for your main geo (e.g., ixx11bar)
• Locate dummy geo name after it
• Find object class byte (3C/0F) - it's 8 bytes to the left of dummy geo's name
• Note: Parent name appears between main geo and dummy geo
• If exported as standard geo type 60, it will show as 3C
• Change 3C to 0F (which equals 15 - spinner geo type)

3. Configure Spin Axes:
• Overwrite first 4 bytes of dummy geo name
• Next 3 groups of 4 bytes control spin axes
• X-axis spin: Change first group to 1
• Z-axis spin: Change last group (useful for minigun barrels)
• Spinner rotates around vector's axis with angular speed equal to vector's magnitude in radians per second

4. Finalize:
• Save VDF file
• Test in game


Requirements:
• HxD Hex Editor
• Target VDF file

Process:

1. Locate Target Geometry:
• Open VDF in HxD
• Find geo name to scale (e.g., 1aa11je1 for jet 1)

2. Understand Transform Structure:
• Bytes after geo name control transform matrix
• Every 4 bytes = one component:
• Bytes 1-4: right_x
• Bytes 5-8: right_y
• Bytes 9-12: right_z
• Bytes 13-16: up_x
• Bytes 17-20: up_y
• Bytes 21-24: up_z
• Bytes 25-28: front_x
• Bytes 29-32: front_y
• Bytes 33-36: front_z
• Bytes 37-40: posit_x
• Bytes 41-44: posit_y
• Bytes 45-48: posit_z

3. Modify Scale Values:
• Transform data spans from geo name to parent name below it
• Example: To make jet longer along vehicle length: change right_z (3rd group of 4 bytes)
• Example: To make jet wider: change up_x
• Enter values as single float with little endian byte order

4. Testing Process:
• Count by groups of 4 bytes after geo name
• Change desired values
• Save file
• Boot game and test appearance
• Repeat adjustments as needed

Note: You can scale any geo like flames above, some give effects, others might not. Hardpoint scaling increases the knockback of the weapon fired out of them, and scaling production unit GS1 hardpoints can launch units out faster.

Tips:
• Different vehicles may require different axis adjustments
• Start with small changes and test incrementally
• Keep backups of working configurations


⚠️ Note: The following behaviors apply only to Multiplayer scripting.


1. MakeExplosion() - Fully Local
• 100% local effect (beneficial for environmental effects)
• Enables: water splashing, rain effects, fog interaction, visual speed lines
• Even damage-causing explosions won't harm opponents
• Only damages local objects

2. SetVelocity() - Fully Synced
• Completely synchronized across all players
• Can create speed/jump pads and teleporters for DM maps
• Velocity multipliers (e.g., ×12) visible to all players


3. Building Objects via Lua
• Objects created by host player are visible to all players
• Objects created by non-host players are not visible to others
• Non-host vehicles won't function (can't fire or lay mines)

4. Object Removal
• Deleting non-local objects causes them to "respawn"
• Proper method: Use SetLocal() first, then remove
• Result: Object disappears for initiating player, explodes for observers
• No scrap is left behind
• To avoid explosions: Move object far away before deletion


5. SetLocal() and AI Units
• Using SetLocal() on non-controlled AI units breaks their AI completely
• Opposing player's machine must build objects they control directly
• Buildings don't require this restriction

5.1. AI Control Workaround
• After SetLocal(): kill pilot with Lua
• Spawn new pilot on top of unit
• Gives proper control to target player


6. SetPosition() on Non-Local Objects
• Behaves identically to deletion attempts
• Same SetLocal() rules apply

7. SetName() Synchronization
• Only affects the executing machine
• Not visible to other players

8. Object Hiding
• Requires SetLocal() for proper function
• Both machines must execute command for true hiding
• Partial hiding effects:
• Vehicle invisible to both, but AI behaves as if visible for non-executing player
• Buildings remain visible but targetable with radar signature
• Note: SetLocal() not required for syncing controlling player's state
• Smart reticule still functions on hidden objects

9. SetTeam() Requirements
• Requires SetLocal() to affect other players' units


10. Building vs Vehicle Network Evaluation
• Buildings evaluate less frequently on network than vehicles
• For frame-by-frame movement: Use vehicles for better synchronization


11. Multiplayer Respawn Detection
• Method: Monitor CreateObject() callback
• Logic: If player object created at spawn point = player death/respawn
• Only applicable to multiplayer scenarios


12. Handing Off Units
• No smooth transfer method exists
• Process:
1. Record all vehicle properties
2. Delete original object
3. Message target player to recreate unit
4. Target player builds identical unit on their team
• Recommendation: Use MakeExplosion() effect on both sides for visual continuity


13. Objective Markers
• SetObjectiveOn(h) and similar functions not synced by default

14. Non-Host Unit Building
• Vehicle AI only works for the building player
• Required: Use SetLocal() after every build
• SetLocal() forces non-host vehicles to sync properly

15. DisplayMessage Variable Display
• Often fails unless values converted to string
• Shows <null> instead of variable values
• Solution: Always convert variables to strings before display

16. Save/Load Functions
• Never used or needed in multiplayer-only maps

Steps for Mesh Editing:
1. Import and Prepare:

Import pilot mesh (e.g., aspilo.mesh) using Kenshi IO Continued
Import new mesh data
Name UV map of new mesh same as existing pilot mesh UV map

2. Mesh Integration:

Position and scale new mesh next to pilot mesh
Join meshes, leaving space to select geometry separately
In edit mode: select vertex group, delete faces, assign new geometry to same vertex group

3. Adding Objects with Materials:

Join meshes and assign to vertex group
Separate vertices by material
Clear all modifier/vertex group data when copying from other objects
Copy only mesh/material data, nothing else

4. Export Settings:

Use Kenshi exporter with: tangents, apply transform, apply modifiers, export skeleton, export animation
Select entire pilot/gun when exporting
Run through OgreMeshUpgrader
Change skeleton reference to aspilo.skeleton unless using custom animations

Atlas Creation Process:
1. Extract Original Textures:
Converts all MAP files ending in 0 to BMP format.
2. Arrange Texture Atlas:

Create 2048x2048 (or larger) canvas
Arrange texture squares logically: sand → dirt → rock
Use first square as bright color to spot errors
Ensure no background showing between textures

3. Export Atlas:

Save as PNG first for editing
Export to DDS using GIMP:
• Compression: DXT1
• Generate Mipmaps: Yes
• Format: sRGB

Maps texture names to atlas coordinates:
Naming Convention:

First 2 letters: Planet identifier
00/01: Texture relationship (00=same, 01=transition 0→1)
S/C/D: Solid/Cap/Diagonal
A/B/C: Variation type
Last digit: Mipmap level (always 0 for Redux)

Additional Texture Types:

_N.dds - Normal maps (use SmartNormal2.0 tool)
_S.dds - Specular maps (desaturate and invert for reflections)
_E.dds - Emissive maps (black for non-glow, color for glow)

---


Heightmaps in Battlezone are grayscale data files that define the terrain elevation across your map. Each pixel represents a height value, with:

• Black (0): Lowest elevation
  
• White (255): Highest elevation
  
• Gray values: Intermediate elevations

• .hg2: Battlezone Redux heightmap format
  
• .hgt: Original Battlezone 98 heightmap format (legacy)
  
• .png/.bmp: Standard image formats for editing

---


Heightmap-to-Image Converter

• GitHub: https://github.com/arwassa/Heightmap-to-Image-converter
  
• Purpose: Converts between Battlezone heightmaps and standard image formats
  
• Supports: .hg2, .hgt input/output and .png, .bmp image formats

• Download the latest release from GitHub
  
• Extract to a convenient folder

---


Critical: Your heightmap image size must match this exact formula:

• Incorrect size: Will cause conversion errors or map corruption
  
• Exact match required: Battlezone expects precise heightmap dimensions
  
• Square images only: Width and height must be identical

---


---


Image Requirements:

• Format: PNG or BMP (PNG recommended)
  
• Color Mode: Grayscale (8-bit)
  
• Size: Must match exact formula above
  
• Content: Black = low, white = high elevation

• GIMP: Free, powerful tools for heightmap editing
  
• Photoshop: Professional editing with terrain brushes
  
• World Machine: Procedural terrain generation
  
• L3DT: Specialized terrain editing software

For Map Development:
• console - Enable console for debugging
• startedit - Launch directly into map editor
• shellmap - Generate preview images automatically

For Testing:
• nointro - Skip intro videos for faster testing
• asciisave - Save files in readable ASCII format
• nobodyhome - Disable certain AI behaviors for testing


1. Right-click Battlezone 98 Redux in Steam Library
2. Select "Properties"
3. In "General" tab, find "Launch Options"
4. Enter desired options (e.g., console startedit develop)
5. Click OK and launch game


The "develop" Flag:
• Enables drawcoll (collision visualization)
• Enables drawguns (weapon visualization)



Prerequisites:
1. All mod files in same folder
2. Square preview image (200x200+ pixels, .jpg format, same filename as map)
3. Configuration .ini file
4. Tested and working mod

Steps:
1. Open Steam Library → Tools
2. Launch "Battlezone 98 Redux - Uploader Tool"
3. Enter mod name and description
4. Click "Create New Item"
5. Select mod folder and preview image
6. Upload to Workshop


For Maps:

For General Mods:


⚠️ WARNING: Only bypass uploader if extensively tested. Could crash games or require reinstallation.

When to Use SteamCMD:
• Official uploader isn't working
• Need more control over upload process
• Uploading from automated build systems
• Beta testing private uploads

SteamCMD Process:
1. Download and run SteamCMD in its own folder
2. Place mod files in separate folder
3. Create upload.vdf file with proper configuration
4. Create preview image in mod directory
5. Login to SteamCMD with credentials
6. Execute: workshop_build_item "path\to\your\mod\upload.vdf"

Example upload.vdf:

SteamCMD Configuration Notes:
• publishedfileid: Set to 0 for new items, use existing ID to update
• visibility: 0 = public, 1 = friends only, 2 = hidden (recommended during development)
• appid: Use 301650 for BZR, change for BZCC if needed
• tags: Comma-separated list of relevant tags
• Leave out fields to not add/update them on the item

Battlezone 98 Redux utilizes a dual-model system where vehicles and structures have 2 different model files, a VDF/SDF that defines the collision, weapon placement, and animation, and an OGRE Mesh that defines the visual appearance of the object.


Battlezone 98 Redux uses a sophisticated dual-component system separating physics/gameplay logic from visual rendering:


VDF Files (Vehicle Definition Files)

• Purpose: Defines physics properties, collision detection, weapon hardpoints, and animation behavior for vehicles
  
• File Extension: .vdf
  
• Content: Vehicle-specific physics properties, collision meshes, hardpoint locations, animation sequences

SDF Files (Structure Definition Files)

• Purpose: Defines physics properties, collision detection, and animation behavior for structures
  
• File Extension: .sdf
  
• Content: Structure-specific physics properties, collision meshes, effect locations, animation sequences

GEO Files (Geometry Components)

• Purpose: Individual components of a VDF or SDF file
  
• File Extension: .geo
  
• Function: Define individual movable/animated parts within vehicles and structures

OGRE Mesh Files

• Purpose: Defines the visual appearance and rendering geometry
  
• File Extension: .mesh
  
• Engine: OGRE Xalafu 1.10
  
• Content: Vertices, faces, normals, UV coordinates, skinweights, tangents, vertex colors
  
• Tools: Utilities exist for modifying Mesh files here: Link[www.ogre3d.org]

OGRE Skeleton Files

• Purpose: Defines bone hierarchy and animations for visual components
  
• File Extension: .skeleton
  
• Critical Detail: Skeleton files use bones named the same as geos with the same orientation/pivot points so they behave exactly as the non-rendered geos do (e.g., a wing on a tank is actually following the invisible geo pivoting)
  
• Content: Bone hierarchy, animation sequences, bone transformations

Material Files

• Purpose: Define surface properties and texture assignments
  
• Content: Material definitions, texture references, shader properties
  
• Associated: Texture files for visual appearance

Battlezone 98 Redux stores most legacy game assets in ZFS (compressed archive) files:

Main Archives:

• bzone.zfs - Contains models, textures, sound effects, and ODF files
  
• bzone_en.zfs - Contains all the voiceovers (specifically the english ones)

Compression: Uses LZO compression


MakeZFS (Recommended)

• Location: Located in the Edit folder of your install
  
• Usage: Command-line tool accessed via terminal/command prompt
  
• Command: MakeZFS x bzone.zfs (to extract)

• Files under BZ_ASSETS are used for appearance in game
  
• VDFs and GEOs are still required, and are used for physics, collision and are also referenced in the .skeleton files

3ds Max

• Compatibility: Tools exist for older versions (Max 2016 and earlier)
  
• Plugins: Legacy plugins available but require porting to newer versions

Blender

• Status: There are up to date tools to handle both Ogre Mesh and VDF/SDF with Blender. See VDF/SDF Tool Section.

Command Line Tools

• OGRE CLI Tools : Command line tools to convert Ogre files to XML or back, or upgrade Meshes

• Engine Version: OGRE Xalafu 1.10
  
• Mesh Version Compatibility: MUST use Ogre Command Line Tools 1.11.6 for BZR compatibility

Skeleton-GEO Synchronization: The most important technical aspect of BZR's model system is that skeleton bones must be named identically to their corresponding GEO components and maintain the same orientation and pivot points. This ensures that:

• Visual animations perfectly match physics behavior
  
• Animated parts (turrets, wings, etc.) move in sync between visual and physics systems
  
• Collision detection remains accurate during animations

Model files in Battlezone 98 Redux are interconnected:

• VDF/SDF files contain GEO components for physics behavior
  
• Skeleton files must mirror GEO naming and pivot structure
  
• OGRE Mesh files provide visual geometry linked to skeleton bones
  
• Material files define surface properties for mesh rendering
  
• ODF (Object Definition Files) coordinate both visual and physics properties

High level, basic workflow I've used and recommend for max efficiency:

• Create your model
  
• Import it to Blender
  
• Make sure you have the VDF/SDF Blender Addon by Commando950 installed and enabled (link in final section of this guide)
  
• Export the model as VDF (vehicle), SDF (building) or GEO (single model component, like for shotGeometry)
  
• Drag that VDF, SDF or Geo onto the BZR Model Porter python script (link in final section of this guide)
  
• You now should have the legacy required files (VDF,SDF, or Geo) and the Redux files (Mesh, skeleton, DDS, material). Now just create an ODF, and you can add it to the game. Ensure your material file points to the correct texture names.
  
• NOTE: Commando950's plugin by default exports the model with incorrect normals for Battlezone 98 Redux. You can fix it with Ogre Command Line Tools (link in last section) and a python script.

The Ogre CLI tools are essential utilities for post-processing Battlezone 98 Redux models after they've been converted with port_models.py. These tools specifically address vertex normal issues that can cause lighting problems in-game, ensuring your models look correct under all lighting conditions.

• OgreXMLConverter.exe - Official Ogre tool for converting between .mesh and .xml formats
  
• recalculate_normals.py - Custom Python script for recalculating vertex normals
  
• ogre_normal_batch.bat - Automated batch processing script

• Python 3.x - For running recalculate_normals.py
  
• Ogre Command Line Tools 1.11.6 - Critical for BZR compatibility
  
• Windows Command Prompt - For running batch scripts

Use the Ogre CLI tools when your converted models have:

• Incorrect lighting - Models appear too dark or bright in certain areas
  
• Shading artifacts - Strange shadows or lighting discontinuities
  
• Faceted appearance - Models look angular when they should be smooth
  
• Normal vector issues - Detected during model validation

A specialized Python script that recalculates vertex normals from face geometry data in Ogre mesh XML files. This fixes lighting issues by ensuring normals point in the correct directions.

• Parses Ogre mesh XML files
  
• Calculates face normals using cross products of triangle edges
  
• Accumulates and averages normals for each vertex
  
• Normalizes vectors to unit length
  
• Updates the XML with corrected normal data

• Algorithm: Face-weighted normal averaging
  
• Precision: 6 decimal places for normal coordinates
  
• Validation: Handles degenerate triangles and invalid indices
  
• Fallback: Uses (0,1,0) up vector for vertices without faces

Automated batch processing script that processes all .mesh files in a directory, handling the complete workflow from mesh conversion to normal recalculation.

• Automatic backup - Creates backup/ directory with original files
  
• Batch processing - Handles all .mesh files in current directory
  
• Error handling - Continues processing even if individual files fail
  
• Progress tracking - Shows detailed status for each file
  
• File validation - Checks output file sizes for corruption
  
• Cleanup - Removes temporary .xml files after processing

• Place the script in the directory containing your .mesh files
  
• Ensure recalculate_normals.py is in the same directory
  
• Ensure OgreXMLConverter.exe is in your PATH or same directory
  
• Double-click the .bat file or run from command prompt

For each .mesh file, the script:

• Mesh Normal Correction
GrizzlyOne95's Github[github.com]

It's quite simple really. Follow these steps to import models and play animations for any .mesh model.

• Make sure you have Blender installed.
  
• Download Kindrad's addon (from the sources listed in guide).
  
• In Blender, go to:
  Edit > Preferences > Add-ons > Install…
  Select the addon .zip or .py file.
  
• Check the box next to the addon to activate it.

• Go to: File > Import > .mesh
  
• Navigate to the folder containing your model (e.g., avtank.mesh) and import it.
  
• This will bring in:
  
  • Mesh – the 3D model
    
  • Skeleton/Armature
    
  • Animations – if included in the skeleton file

• Switch to the Animation Workspace in Blender (top tabs).
  
• Open the Dope Sheet or Action Editor.
  
• In the dropdown menu, you should see a list of Actions — these are your animations (walk, idle, attack, etc.).

• Select the skeleton/armature in the 3D Viewport.
  
• In the Action Editor, pick the animation you want to preview.
  
• Press the Play button in the timeline (or spacebar) to see it in action.

• Change the frame start/end to match the length of the animation.
  
• Scrub the timeline to see individual frames.
  
• Loop the animation by enabling the loop option in the timeline.

Tip: If no animations appear, make sure the imported .mesh actually contains animation data. Some units may have separate .anm or .skeleton files that also need importing.

Based on the original workflow by système, simplified for Blender and modern tools

This guide explains what you need to know to make your 3D models compatible with Battlezone 98 Redux, especially if you’re modeling in something like Blender. Make sure to check out the following VDF/SDF/Geo tool sections for further info.

• Models must be broken into geos (sub-objects), each with an 8-character name limit.
  
• Geos must be parented correctly to form a hierarchy.
  
• The origin pivot and rotation of each geo matter for how the object appears and animates.
  
• Collision requires a special hidden geo for inner and outer collission

Geos follow a strict naming pattern:


Where:

= 3-letter unit name prefix

= Level and Type (e.g. 11bd = Level 1 Body)

= optional identifier (like for Gun Cannon 1)

Common Geo Types:

• bdN
  = Body
  
• txN / tyN
  = Turret rotation axes (up/down or left/right)
  
• gcN
  = Gun cannon
  
• pov
  = Player viewpoint inside cockpit

• Set pivots carefully; the pivot controls rotation and position in-game.
  
• Align internal geos’ (LOD 2) pivots with external counterparts (LOD 1) (e.g. cockpit with hull).
  
• View and edit hierarchy before export.

• Required for units only (not producers/buildings — those generate collision automatically).
  
• Use a geo called
  XXX1_col
  — import from another model and reshape. You can also use different names if using commando950's blender tool.
  
• This geo is invisible and doesn't render.

• Only position and rotation animations are supported.
  
• Ideal range: 10–20 frames per animation, 25 geos max.
  
• Loop animations (walk cycles, idle) must end on same pose as frame 0.
  
• Animated geos auto-affect child geos (e.g. moving an arm also moves its gun).
  
• Not all turrets need actual animation — turret geos (
  tx/ty
  ) rotate automatically.

New and old Battlezone players and modders can all remember the time we done without or had to make do with something. Maybe it was because of a lack of tools, support, or maybe just super inefficient tools.

With Battlezone models much has been mysterious and confusing. More importantly, its hard to really know everything there is about Battlezone much less modeling itself. Custom Battlezone models required an immense amount of knowledge and just completely unreasonable workflows that could involve 2-3 programs along with a bunch of files you need other external programs to generate.

Well lucky for you, this add-on is here to change that. In fact its not only here to add a new option for making models, it is here to change entirely how you make models for Battlezone and make your job a hell of a lot easier in the process!

Key Benefits:
• MakeOBJ is obsolete and not required when using this add-on
• No confusing .txt files or undocumented nonsense
• Import/Export GEO/VDF/SDF files with all their information including animations
• Collisions are as simple as making two boxes or clicking a button
• Many useful features that make life easier


• The correct version of Blender for the add-on of your choosing
• The add-on must be installed and activated
• You should have knowledge of Blender or at least willingness to learn
• If you have "done this before", you won't be doing it the same now at all

Important Changes from Old Workflow:
• Regular collision boxes are not supported at all - easier collision creation exists
• You do not need a .txt file for SDF/VDF properties
• SDF/VDF properties, animations, and GEO types are set inside Blender itself
• You do not need any external programs including the old MakeObj program
• You can set a separate texture per every material in Blender
• You can't and should not mix the new and old workflows


Battlezone has three formats directly related to its models. Battlezone's game engine was derived from Interstate 76 which used damage levels and level of detail to keep the game running smoothly.


GEO (Geometry):
• Is a single part of a vehicle/structure
• Many are used to make a single vehicle/structure
• Is a model with model data
• Keeps track of the texture of every face and flat texture colors for low detail

VDF (Vehicle Definition File):
• Keeps track of special information about vehicle mass, Level of Detail distance
• Keeps track of GEOs and their positions
• Keeps track of animations for all vehicle GEOs
• Collision data is stored in the VDF

SDF (Structure Definition File):
• Keeps track of special information about the structure
• Keeps track of GEOs and their positions
• Keeps track of animations for all structure GEOs
• Unlike vehicles, uses only GEO collisions



File > Import > GEO
• Import only one GEO instead of an entire VDF and its GEOs
• Useful for looking at individual parts

File > Import > VDF
• Import all of a Battlezone VDF including:
• VDF Properties
• VDF Animations
• VDF Animation Element Data
• All GEOs associated with the VDF
• Pretty much everything

⚠️ Warning: If you import a new VDF, all current animation elements and VDF properties are lost and replaced by the current VDF.

File > Import > SDF
• Import all of a Battlezone SDF including:
• SDF Properties
• SDF Animations
• SDF Animation Element Data
• All GEOs associated with the SDF
• Pretty much everything

⚠️ Warning: If you import a new SDF, all current animation elements and SDF properties are lost and replaced by the current SDF.


File > Export > GEO
• Only one model (the active one in the scene) will be exported
• By itself this .GEO is mostly useless but can replace existing unit GEOs

File > Export > VDF
• All VDF properties and all objects in the scene with correct naming will be converted
• Creates a complete Battlezone .VDF with all its models
• ⚠️ Warning: Will create TONS of GEO files and overwrite existing files without warning

File > Export > SDF
• All SDF properties and all objects in the scene with correct naming will be converted
• Creates a complete Battlezone .SDF with all its models
• ⚠️ Warning: Will create TONS of GEO files and overwrite existing files without warning


Battlezone GEOs are named in a very specific pattern and this add-on expects you to keep it that way.


Names must begin with a 3 letter prefix, followed by the level of detail, the number 1, and a suffix.

Format: ABC11XYZ

Prefix (ABC):
• Used for identifying the geo set
• AGR for example denotes American Grizzly
• Don't skip out and put only one or two letters - get the entire 3 letters

Level of Detail (1):
• 1 = Close up views of the model (maximum detail)
• 2 = Cockpit view aka first person
• 3 = Seeing the model from far away

⚠️ Warning: This add-on expects you to have the first level of detail for all level of detail 2/3 objects. If you are missing the level of detail 1 version of a GEO, it will NOT be exported! LOD 3 is not necessary.

Number 1:
• Likely a leftover from I76 damage system
• Just keep it as one

Suffix (XYZ):
• Can be from 0-3 letters
• Recommended to give it a three letter name
• Exceptions:
• Weapon hardpoints should use suffixes like gc1 or gc2
• Turrets should use tx1 or ty2 to define rotation direction

⚠️ Warning: Getting the naming wrong will result in it not exporting.



Click the scene icon in the properties tab. You'll find SDF/VDF Properties there. You can hover over the properties for more information.


Animation Elements control how animations will be used in game. They control:
• Index type of an animation
• What frame it starts on
• Length of the animation in frames
• Times it should loop
• Frame speed

Find the SDF/VDF Animations panel below the SDF/VDF Properties panel in the scene properties.


GEO Properties let you define things specifically for each GEO. The most important is GEO Type - this determines what a GEO is and how it acts.

Click the object icon in the properties tab after selecting an object to find GEO Properties.



There are three types of collisions for vehicles:

Outer Collision:
• What makes vehicles collide and get hit by projectiles
• Create with Add > Mesh > Cube
• Name it: outer_col, outercol, outer_collision, or outercollision

Inner Collision:
• Smaller than outer collisions
• Generally used for really hard clipping with the vehicle
• Create with Add > Mesh > Cube
• Name it: inner_col, innercol, inner_collision, or innercollision

Collision Creation Tips:
• You don't have to use perfect cubes - can use modified cubes, two points, or edges
• The system uses minimum and maximum positions from all points of the collision objects
• Never try to make inner/outer collisions into the same object

⚠️ Warning: If you do not use a correct object name for a collision object it will not be used.


⚠️ Warning: Structures DO NOT use inner or outer collision boxes like vehicles.

Both Vehicles and Structures can have GEO based collisions. These give much more realistic and natural feeling hitboxes.

Automatically Generating GEO Collisions:

By default "Automatically Generate Collisions" is enabled on every object
When you export, all collisions will be generated for you
All settings will be lost and overwritten on the GEO collision data

Manually Creating GEO Collisions:

Uncheck "Automatically Generate Collisions"
Click "Generate Collisions" for a good starting point
Modify GEO Center, Projectile Collision Box, and Sphere Radius manually

GEO Collision Properties:

GEO Center: Center of the GEO projectile hitbox (usually middle of the GEO)
GEO Projectile Collision Box: Sets the projectile box size based on GEO Center position
GEO Sphere Radius: Everything inside this radius can be collided with

⚠️ Remember: Y and Z are swapped to Battlezone. Y is height!
Textures are now set in materials separately from just using Material name.
Process:

Assign materials to faces in Blender
In the materials tab, scroll down to the Texture text field
Enter the name of the texture you'd like to use for each material
If you use avtank00.map for example, write avtank00 without the .map extension

⚠️ Warning: If you set a texture name that does not exist, it will result in Battlezone creating an error and lock up the game immediately.
Hint: It is totally fine to use more than one texture per object as you can assign a different material per every face in Blender.
Battlezone animations are used in buildings, turrets, walkers, howitzers, and constructors. Battlezone supports both location and rotation based animations, and both can be used at the same time.
⚠️ Warning: Text file configured animations and SDF/VDF Properties are not used at all in this Blender add-on. Everything regarding animations must be done inside Blender.

Animate your Battlezone unit - best to do this last after model/textures are finished
Create animation elements for each animation you will use
Find the Battlezone Animations panel by clicking the scene tab
Click New Element to create a new animation
Click Delete Element to remove one

Index:

Special property that determines what type of animation it is
See Animation Index Reference below

Start Frame:

What frame the animation begins in
Frame 0 in Blender = frame 0 for the element editor

Length:

How long the animation is
Determines when the animation ends and what direction it plays
Can be negative values to play animation in reverse

Loop Count:

How many times an animation should loop before stopping
Often set to 0 instead of 1
Setting to 0 will play the animation forever until it switches animations

Speed:

How fast an animation will play
Smaller number = slower animation
Larger number = faster animation

Battlezone has animation indexes unique to each classlabel. This list helps decide what each animation is used for.

Look at existing SDFs and VDFs for reference
Import existing Battlezone units to see examples of collisions and setup
Animate last after the unit is completely finished with model/textures
Experiment with animation settings, but check existing files for guidance


Object not exporting: Check naming convention
Textures not working: Verify texture names exist in game
Collisions not working: Check collision object naming
Animations not working: Verify animation index is correct for unit type


Keep backups before major changes
Export will overwrite existing files without warning
Test exported models in-game frequently
Use consistent naming conventions across your project


Create multiple versions of the same GEO for different detail levels
LOD 1: Full detail for close viewing
LOD 2: Simplified for cockpit view
LOD 3: Very simplified for distant viewing


Each material can have its own texture
Assign different materials to different faces
Allows for complex texture setups on single models


Use negative Length values to reverse animations
Saves time by reusing walking left animation for walking right
Many stock Battlezone units use this technique

port_models.py is a Python-based model porting utility for Battlezone 98 Redux that converts legacy Battlezone model formats (.vdf, .sdf, .geo, .map, .odf) to the newer .mesh format used by the Redux version. The tool handles geometry, textures, animations, and special features like headlights and sniper scopes. You can find a download for it in the last section of this guide. It saves a TON of time adding new models to Battlezone 98 Redux!


Python Packages Required:

• numpy - For managing large data arrays efficiently
  
• pillow - Python image library for creating DDS texture files

Install with:



You can drag and drop .vdf, .sdf, or .odf files directly onto the script for quick conversion.

Using .odf files is preferred because they contain metadata about whether the model is a pilot, turret, etc., which cannot be reliably detected from .vdf files alone.

• file [file ...] - Path to the file(s) you want to port
  
• Supported formats: .vdf, .sdf, .geo, .map, .odf

Note: Use --suffix "" for no material name suffix.


All model type flags support ternary values: Auto, True, False









Create a config.cfg file in the same directory as port_models.py or specify a custom path with --config.

• Line 1: Path to .act color palette file for indexed images
  
• Line 2+: Directory paths for asset search locations
  
• The script searches the target file's directory first, then these paths in order

• .vdf - Vehicle Definition Files (vehicles with cockpits)
  
• .sdf - Structure Definition Files (buildings, static objects)
  
• .geo - Geometry files
  
• .map - Map texture files
  
• .odf - Object Definition Files (preferred - contains metadata)

The tool generates multiple output files:

• .mesh - Main geometry file
  
• .material - Material definitions
  
• .skeleton - Animation skeleton (if applicable)
  
• .dds - Texture files

When using .odf files, the tool automatically detects:

• Person models: Automatically enables --person True and --turret False
  
• Turret models: Classes turret, turrettank, howitzer enable --turret True
  
• Pilots: Auto-detected when model name has 's' as second character (e.g., "bspilo")

• Use .odf files when possible - They contain the most metadata for automatic detection
  
• Set up config.cfg - Saves time by automatically finding required assets
  
• Use --onlyonce - Prevents re-processing models that already exist
  
• Test with --nowrite - Verify settings before actual conversion
  
• Organize output - Use --dest to keep converted files organized
  
• Suffix management - Use empty suffix (--suffix "") to avoid filename clutter

• Missing dependencies: Install numpy and pillow
  
• File not found: Check config.cfg paths and ensure all required assets are accessible
  
• Invalid file type: Only vdf/sdf/geo/map/odf files are supported
  
• Permission errors: Ensure write access to destination directory

Use --nowrite to test configurations without creating files.

• Models with the same name won't be re-ported if using --onlyonce
  
• Cockpit separation is determined by examining animation data
  
• Headlights create bones named "HLGT0_ff0000", "HLGT1_ff0000", etc.
  
• Scope geometry is automatically generated for non-geometry scope types
  
• File extensions are case-insensitive

Particle Renders are visual effects in Battlezone that create explosions, weapon effects, smoke, sparks, and other dynamic visuals. They're defined in ODF files and referenced by weapons, explosions, and other game objects.

• draw_bolt
  
• draw_emit
  
• draw_light
  
• draw_multi
  
• draw_null
  
• draw_planar
  
• draw_shock
  
• draw_sphere
  
• draw_sprite
  
• draw_tracer
  
• draw_twirl
  
• draw_twirl_trail

Most common particle type. Perfect for explosions, smoke, muzzle flashes, and sparks.
Muzzle Flash:
Smoke Puff:
Creates invisible effects. Useful for timing, positioning, or as containers for other effects.

Timing delays in complex effects
Invisible emitters for particles
Placeholder effects during development
Sound-only effects (with SimulateSoundEffect)

Spawns other particle effects. Creates complex systems by emitting multiple particles over time.

sim_null - No movement
sim_chunk - Falls and bounces
sim_dust - Ground-based particles
sim_ember - Falls, no rotation
sim_spray - Falls, respects collisions
sim_smoke - Free movement

Combines multiple effects simultaneously. Perfect for complex explosions or weapon effects.

Format: "Red Green Blue Alpha" (0-255 each)
Alpha: 0 = transparent, 255 = opaque
Example: "255 100 50 200" = bright orange, mostly opaque


startRadius/finishRadius - Size in world units
lifeTime - Total effect duration
animateTime - Time to transition from start to finish values
StartDelay - Delay before effect begins


maxCount - Limits simultaneous particles (draw_emit)
minLOD/maxLOD - Controls visibility at different detail levels
Keep values reasonable for good performance


Simple visual: draw_sprite
No visual: draw_null
Particle spawner: draw_emit (needs simulateBase on spawned particles)
Combined effects: draw_multi

Creates zigzagging electrical arcs. Perfect for lightning, energy weapons, and electrical effects.




Creates dynamic lighting. Use sparingly as lights are performance-expensive.


• Alpha in colors controls light intensity
• Radius controls light range
• Higher attenuation values = shorter range
• Lens flare size controlled by color alpha



Renders 3D spheres. Great for energy shields, force fields, and bubble effects.




Renders textures flat on the ground. Perfect for explosion rings, impact decals, and ground effects.




Creates expanding shockwave effects. Similar to draw_planar but optimized for shockwaves.



Creates linear projectile trails. Perfect for bullet paths, laser beams, and missile trails.




Creates rotating ground-based effects. Perfect for whirlwinds, dust devils, and portal effects.




Creates trails of spinning effects. Combines trail movement with twirl rotation.





• Additive ("srcalpha one add"): Bright effects like lightning, energy, muzzle flashes
• Alpha blend: Standard smoke, dust, debris
• Full additive: Very bright effects, lens flares

ExplosionClass creates instant damage with distance falloff, combined with particle effects. When an explosion occurs, it can spawn up to 16 different particle systems simultaneously.

Class Tree: Entity→Explosion

Description: ExplosionClass handles both the damage mechanics and visual particle effects of explosions in a single system.



1. Explosion occurs (from weapon, destroyed object, etc.)
2. Damage is applied to objects within damageRadius
3. Each particleClass is spawned simultaneously
4. Particles inherit explosion properties (position, velocity, etc.)




particleClass# = ""
• The Render Name for this Particle emitter
• References particle effects created with renderBase
• Example: "explosion.debris_emit" points to [debris_emit] render section

particlePosVar# = "0.0 0.0 0.0"
• Particle starting Position variance in X Y Z format
• Creates scatter around explosion center
• Example: "2.0 1.0 2.0" = ±2 units X/Z, ±1 unit Y

particleBias# = "0.0 0.0 0.0"
• Particle base Velocity in X Y Z format
• Constant velocity applied to all particles of this type
• Example: "0.0 10.0 0.0" = upward velocity

particleVeloc# = "0.0 0.0 0.0"
• Particle Velocity variance applied in addition to particleBias
• Random velocity within this range
• Example: "5.0 3.0 5.0" = random velocity up to ±5 X/Z, ±3 Y

particleInherit# = "0.0 0.0 0.0"
• Percent of inherited velocity applied (0.0 - 1.0 for each axis)
• 1.0 = 100% inheritance from explosion source
• Useful for moving explosions (missiles, etc.)









Moving Missile Explosion:

Stationary Building:

Partial Inheritance:


Tight Explosion:

Wide Scatter:

Ground-Level Only:


• Maximum 16 particle effects per explosion
• Each particle effect can spawn many individual particles
• Complex explosions can impact performance significantly

Core Concept
Battlezone's Lua environment still has access to Lua's built-in module system through package.path and package.cpath. You can manually modify these to enable DLL loading.

The Manual Process

1. Parse Current Paths
Extract the game directory from existing package paths:

2. Construct Workshop/Mod Directories
Build paths to where your DLLs are located:

3. Modify Package Paths
Add your directories to Lua's search paths:

4. Load Your DLL
Now require() will find your DLL:

Complete Minimal Example

What RequireFix Actually Does
RequireFix automates this process by:

• Auto-detecting paths: Handles Steam Workshop vs GOG installations automatically
  
• Multiple workshop support: Can add multiple mod directories at once
  
• Error handling: Graceful fallbacks when directories don't exist
  
• Cross-platform logic: Handles different installation patterns

Key Variables

• package.path - Where Lua looks for .lua files (semicolon-separated)
  
• package.cpath - Where Lua looks for .dll files (semicolon-separated)
  
• Path format: DirectoryPath\\?.extension where ? is replaced with module name

The Bottom Line
RequireFix is essentially a sophisticated wrapper around manual package.path and package.cpath modification that handles the complex directory detection and multiple-workshop scenarios automatically. RequireFix is available on the Steam Workshop.

Security Warning
Only load DLLs from trusted sources. Custom DLLs have full system access and can potentially harm your computer or compromise your data.

Alternative Method: DLL Proxying/Shimming

What is DLL Proxying?
Battlezone 98 Redux attempts to load winmm.dll (Windows Multimedia API), but this DLL isn't actually used by the game. This creates an opportunity for DLL injection through Windows' DLL search order.

How Windows DLL Loading Works
When an application requests a DLL, Windows searches in this order:

• The application's root directory
  
• System directories (System32, etc.)

The Proxy Method

• Place a custom winmm.dll in Battlezone's root directory
  
• Windows loads your DLL instead of the system one
  
• Your DLL can inject code and forward calls to the real winmm.dll
  
• Technically any DLL can work, but winmm.dll is confirmed to be a working and useful example

Advantages Over Package Path Method

• Automatic loading: No Lua code modifications needed
  
• Earlier injection: Loads before Lua environment starts
  
• Global access: Can hook any part of the application
  
• No workshop dependency: Works with any installation method

Implementation Example

File Placement
Place your custom winmm.dll in:

Comparison of Methods

Package Path Method:

• Requires Lua code changes
  
• Works within Lua environment only
  
• Easier to distribute via workshop
  
• More portable across installations

DLL Proxy Method:

• No Lua modifications needed
  
• Deeper system access
  
• Automatic loading
  
• Requires direct file placement

Security Considerations
IMPORTANT: DLL proxying gives complete system access and loads automatically. Only use DLLs from absolutely trusted sources. Malicious DLLs can:

• Access your entire computer
  
• Steal personal information
  
• Install malware
  
• Corrupt game files

Detection and Removal
To check if a proxy DLL is installed:

• Look for winmm.dll in Battlezone's root directory
  
• The real winmm.dll should only be in System32
  
• Delete the file from Battlezone's directory to remove

Which Method to Choose?

• Use Package Path for: Lua extensions, workshop mods, portable solutions
  
• Use DLL Proxy for: Deep system hooks, automatic loading, advanced modifications

For Developers: Creating Custom DLLs

Project Structure Requirements
Based on the ExtraUtilities source code, you need:

• Two Projects: Custom Lua library + Your DLL
  
• Lua5.1-BZR.vcxproj: Static library (.lib) for custom Lua
  
• YourDLL.vcxproj: Dynamic library (.dll) linking to custom Lua
  
• Target: 32-bit Windows (Win32 platform)
  
• Language: C++20 with C17 for Lua sources

Critical Build Configuration

Required Entry Point
Your DLL must export a specific function for Lua loading:

DllMain Template

Character Set Configuration Issue
IMPORTANT: There's a character set mismatch in ExtraUtilities:

• ExtraUtilities.vcxproj: Uses MultiByte character set
  
• Lua5.1-BZR.vcxproj: Uses Unicode character set

This mismatch exists in the actual codebase and appears to work, so follow this pattern exactly.

Project Dependencies & Naming
Your DLL project must:

• Link against the correctly named Lua library:
  
• Debug builds: Link to Lua5.1-BZR-debug.lib
  
• Release builds: Link to Lua5.1-BZR.lib
  
• Output to $(SolutionDir)\lib\ directory
  
• Use identical compiler settings as the original projects

Target Names

• ExtraUtilities outputs as: exu.dll (not ExtraUtilities.dll)
  
• Your DLL should output as: yourmodulename.dll

File Organization

Solution Configuration
The solution file should be configured for:

• Platforms: Debug|x86 and Release|x86 (NOT Win32 in solution)
  
• Project Dependencies: Your DLL depends on Lua5.1-BZR

Testing Your DLL

• Build both projects in same configuration
  
• Files output to lib/ directory automatically
  
• Copy yourmodulename.dll to workshop directory
  
• Test with RequireFix: local yourmod = require("yourmodulename")
  
• Verify functions work: yourmod.YourFunction("test", 123)
  
• Check debug console output in debug builds

Common Pitfalls

• Using { NULL, NULL } instead of { 0, 0 } for terminator
  
• Returning 1 instead of 0 from luaopen_ function
  
• Not matching the exact character set configuration (MultiByte vs Unicode)
  
• Wrong library names (missing -debug suffix for debug builds)
  
• 32-bit/64-bit mismatch (BZR is 32-bit only)
  
• Not using the custom Lua library
  
• Mixing Debug/Release runtimes causes heap corruption

IMPORTANT: Build From Source
Always compile the project yourself - do not use pre-built binaries!

• MSVC updates frequently and breaks binary compatibility
  
• Different compiler versions create incompatible runtime libraries
  
• Heap allocation compatibility requires matching build environments
  
• Custom Lua library must be compiled with same toolchain

Recommended Development Process

• Clone ExtraUtilities: https://github.com/VTrider/ExtraUtilities
  
• Copy the project structure as your starting template
  
• Use the same build configuration (compiler flags, runtime library, etc.)
  
• Compile everything from source with your current MSVC version
  
• Never mix binaries from different compiler versions

Why Source-Only Approach

• MSVC runtime library changes break compatibility
  
• Heap corruption from mismatched runtimes
  
• Custom Lua patches may not work with different builds
  
• Game engine expects specific ABI conventions
  
• Debug vs Release configurations must match usage

This section provides technical information about the Battlezone 98 Redux server communication protocol, enabling developers to create their own tools and interfaces that interact with the BZ98 multiplayer system.

• Non-secure: ws://battlezone98mp.webdev.rebellion.co.uk:1337/
  
• Secure: wss://battlezone98mp.webdev.rebellion.co.uk:1337/

The BZ98 server uses a hybrid approach:

• WebSocket: For lobby management, chat, and external tool communication
  
• P2P UDP: For actual game traffic during matches
  
• Centralized matchmaking: Server coordinates lobby creation and joining

• Standard WebSocket connection (RFC 6455)
  
• JSON message format
  
• No additional subprotocols required
  
• Supports both secure (WSS) and non-secure (WS) connections

• Establish WebSocket connection to server
  
• Send authentication message
  
• Receive authorization response
  
• Begin normal message exchange

Monitor WebSocket.readyState:

• 0 (CONNECTING): Connection being established
  
• 1 (OPEN): Connection ready for communication
  
• 2 (CLOSING): Connection being closed
  
• 3 (CLOSED): Connection closed

Send immediately after connection opens:



Important: Save the userId - this identifies your session and is used in subsequent operations.

• clientVersion: Should match current BZ98 version (2.2.301 as of writing)
  
• gameVersion: Must match server expectations
  
• displayName: 20 character limit

Note: Outgoing messages use "content", incoming use "data".

• All messages are JSON strings
  
• Send via WebSocket.send(JSON.stringify(message))
  
• Receive via WebSocket message event handler

Send Chat Message

Receive Chat Message

Note: Time format is "YYYY-MM-DD HH:MM:SS" in 24-hour format.


Create Lobby

Join Lobby

Exit Lobby

Lobby Updates


Disconnect

• Steam Users: 1234567890 (S + 64-bit Steam ID)
  
• Bots/System: B000000000 (B prefix)
  
• Other Platforms: Various prefixes depending on authentication method

Steam IDs can be converted to profile URLs:


The server supports different lobby purposes:

• Game Lobbies: For actual BZ98 matches
  
• Chat Lobbies: For community chat (often contain "~chat~" in name)

Lobbies contain various metadata fields:

• name: Display name
  
• userCount: Current user count
  
• memberLimit: Maximum users (typically 20000 for chat lobbies)
  
• isPrivate: Whether lobby is private
  
• isLocked: Whether lobby is locked to new joins
  
• owner: User ID of lobby creator

Track users in lobbies via the users object:


Based on game logs, BZ98 follows this startup pattern:


The game uses specific buffer configurations:

• Receive Buffer: 1,048,576 bytes (1MB)
  
• Send Buffer: 32,768 bytes (32KB)
  
• P2P Port: Dynamic assignment (e.g., port 49936)

BZ98 operates with two network layers:

• WebSocket Interface: Lobby management, chat, matchmaking
  
• P2P UDP: Direct game traffic during matches

• Always check WebSocket state before sending messages
  
• Implement reconnection logic for dropped connections
  
• Handle both secure and non-secure WebSocket variants
  
• Store user ID from authentication for session management

• Parse incoming JSON carefully - structure may vary
  
• Handle both "data" and "content" fields in responses
  
• Implement timeout handling for server responses
  
• Log unknown message types for debugging

When developing web-based tools:

• HTTPS pages cannot connect to ws:// (use wss://)
  
• Consider CORS restrictions for Steam API integration
  
• Some browsers may block mixed content scenarios

Common connection issues:

• Server unavailable (connection timeout)
  
• Version mismatch (authentication failure)
  
• Network firewall blocking WebSocket ports
  
• Mixed content security restrictions

• Display names limited to 20 characters
  
• Lobby member limits vary by type
  
• Message rate limiting may be enforced server-side
  
• Some message types may be game-version specific

• Protocol may evolve with game updates
  
• Version checking is enforced during authentication
  
• Monitor game logs for protocol changes in new releases

Protocol Version: BZ98 Redux 2.2.301
Last Updated: September 2025

Battlezone 98 Redux is a 32-bit application limited to 4GB of memory. This affects all modding decisions:

- Always use .DDS format for textures when possible
- DDS provides better compression and faster loading
- Reduces memory usage significantly compared to PNG/TGA
- Use DXT1 compression for textures without alpha
- Use DXT5 compression for textures with alpha channels
- Add mipmaps for help with optimization, though it does increase file size



Most BZR Models are between 2000 and 10000 tris. Try to stay on the lower end of that.



- Limit texture variety: Each unique texture uses memory
- Use texture atlases: Combine multiple textures into single files


Don't run expensive function calls in Update() like AllObjects() or AllCraft()
Instead, use timers to stagger out the calls if they are needed often.


- Use WAV format: 8-bit unsigned, 22050 Hz maximum
- Avoid large audio files: Keep under 1MB when possible
- Use compression: For music, OGG format supported
- Limit simultaneous sounds: Too many can cause stuttering


1. Monitor frame rate with large unit counts
2. Test on lower-end hardware when possible
3. Check memory usage during extended play
4. Verify loading times for maps and assets
5. Test multiplayer sync with multiple players

- Too many high-poly models visible simultaneously
- Excessive particle effects in combat
- Large uncompressed textures eating memory
- Complex Lua scripts running every frame
- Too many simultaneous audio sources

- Use .DDS for all textures when possible
- Compress textures to save on file space, if it doesn't affect visual quality too badly
- Ensure Lua scripts don't call things every frame in Update() when possible
- Keep models to a reasonable tri count like <10000

This is a comprehensive list of known bugs in Battlezone 98 Redux, compiled from community reports and testing. This list is intended to help players understand current issues and find workarounds where possible.
Description: Units with told to follow an allied unit causes instant game crash.
Workaround: Avoid setting weaponMask to all zeros when using follow commands.
Description: Having pilot hardpoints under craft class header in ODF files causes hard crash.
Workaround: Move hardpoints ABOVE craft class header in ODF files.
Description: When renderCount is nil or isn't read properly, leads to "invalid allocation size" crash in ParameterDB system.
Description: Game crashes seemingly at random, even in stock content. No errors given in log files.
Factors that increase crash frequency:

• Shadows on max setting
  
• Alt+Tab or Alt+Enter
  
• Non-fullscreen mode
  
• DX11 renderer
  
• Non-English localization

Description: Some BMP formats cause hard crash when launching Custom Campaigns.
Workaround: Use 24-bit BMP format with "do not write color space info" setting.
Description: Division by zero error in MagnetClass when the range is zero.
Description: First Ctrl+E works fine, but quitting to menu and launching again causes bugged state (empty minimap). 100% crash when trying to change tiles.
Workaround: Restart game completely.
Description: Cannot place objects in Shift+F10 mode in editor.
Workaround: Pause the game using keyboard Pause button first.
Description: Clicking on units in Shift+F9 "edit task" mode with mismatching class label and AI process crashes game.
Description: Severe lag problems with packet loss and connection drops. Much worse than BZ 1.5 netcode.
Factors: Large amounts of scrap, deploying multiple armory powerups simultaneously.
Partial Workaround: Use community workshop items that partially mitigate lag.
Description: When MPI host leaves, game becomes unstable.
Description: Freecam mode is possible in multiplayer, providing unfair advantage.
Description: Friend invites with password lobbies don't work - password isn't included in invite string.
Description: Map list refreshes every few seconds, making scrolling difficult.
Note: Steam Workshop auto-refresh issue. GOG version doesn't have this problem.
Description: Various multiplayer synchronization problems:

• Building objects via Lua only appears for hosting player when built by non-host
  
• Removing non-local objects causes them to "respawn"
  
• SetName() only affects the machine that executed it
  
• Objective markers not synced by default
  
• GetPlayerHandle with team number always returns nil
  
• Weapon changes require Send/Receive to sync properly

Description: WeaponMines attack allied ships when pilots hop out briefly.
Description: Minelayers only use their first hardpoint for "Lay Mines" command, regardless of weaponMask or Lua settings.

• Retaliation Bug: Howitzers fire undeployed at enemy pilots who snipe them while on follow/go orders
  
• Weapon Mask Bug: Howitzers only use first hardpoint regardless of weaponMask setting

Description: Cannot deploy soldiers when targeting allied unit while near enemies.
Workaround: Untarget the allied unit first.
Description: Neutral units attack you but you cannot order attacks on them (should be opposite).
Description: AI constructors can build structures from kilometers away after being killed and rebuilt.
Description: Tugs that start missions with cargo or load cargo after save/load cannot drop it.
Description: No weapon switch required to keep jumping, making hop sniping too easy compared to BZ 1.5.
Description: When mixing custom and stock units in custom producer, AI only builds custom units even when stock units are in AIP.
Workaround: Copy stock ODF files to make them "custom" or use Lua to force AI building.
Description: Very unstable, causes crashes or fails to render textures, especially custom ones.
Description: Terrain tile texture type 0 gets deformed differently based on orientation. Transitions between type 0 and others also appear deformed.
Description: Walker cockpits jitter when walking/jumping.
Workaround: Remove cockpit parent and parent to world (doesn't inherit movement but stops jitter).
Description: Various turret cockpits have wrong rotation. Redux cockpits inherit rotation from entire hierarchy.
Workaround: Add dummy bones or redo hierarchy.
Description: NSDF Razor material file makes the unit very dim.
Description: Missing image in stock files.
Description: Some units missing headlights or have mixed headlight models/lamp bones.
Description: Can see all objects via satellite even if not visible on radar (fog of war). This differs from BZ 1.5 behavior.
Description: Entering satellite/F9 view while targeting causes target camera to remain on screen but not follow target.
Description: Heightmap smoothing is ON by default, changing terrain and pathing including stock missions.

• Loop Bug: Some animations only play once even if VDF/skeleton has them set to loop
  
• Speed Bug: Animation speeds are hardcoded and don't respect VDF speed values or ODF animRate

Description: Door opening animation doesn't work on build.
Workaround: Fix skeleton.
Description: Saving or editing TRN files sometimes converts line feeds to wrong format. Game ignores text with incorrect line feed format.
Workaround: Convert TRN files to ANSI and force line feeds to CR LF format.
Description: Functions like , , , , and return strings with fixed character length including null characters.
Workaround: Use to handle properly.

Description: iterator is broken and only returns first result due to engine bug.

Description: Window loses focus and minimizes on end mission screen in custom campaigns.
Description: Various TRO missions have bugs that prevent completion.
Description: Briefing text gets cut off, requiring 10-15 line breaks for proper scroll display.
Description: Inst4XMission type crashes on save game loads frequently.
Description: Saves during earthquake/dayquake effects repeat those effects endlessly on load.
Description: Cinematic camera appears zoomed in incorrectly when triggered during satellite mode.

• Collision Bug: Violent collision with deployed sprayBuildingClass
  
• Undead Bug: Destroyed splinters persist until finishing all bullets
  
• Multiplayer Duplication: Splinters create multiple bullet copies for each player

Description: Some units (NSDF scout/bomber) have hardpoints tied to strafe geos that throw off aim.
Workaround: Remove hardpoints from moving geo parents.
Description: Cannon reticle doesn't match hardpoint due to VDF parenting causing sway during movement.
Description: Sniper occasionally misaligned with reticle after ejection.
Description: Terrain spire issues in multiplayer.
Description: Game loads ALL files from mods when entering menu, not just when launching. Duplicate material names cause crashes.
Description: Various armory glitches in multiplayer including double/triple day wrecker detonations.
Description: Non-host players can be hit by multiple day wrecker explosions for single launch.

This comprehensive Battlezone modding reference guide was compiled from numerous sources within the Battlezone community. The information contained here represents decades of collective knowledge, experimentation, and documentation by dedicated community members.


General BlackDragon's Steam Guides
bluebanana's Steam Guides
DeusExCeteri's Steam Guides and extensive testing
ssuer's Terrain Painting and Lua Scripting Guides
systeme's 3d Modeling and Terrain Painting Tutorial
Piercing's "BZR on Linux" Guide
Business Lawyer's extensive testing
VTRider's extensive testing
DivisionByZero's extensive testing
Janne/Mario's extensive testing
GoombaBZ's extensive testing


UltraKen
• Original developer insights and technical knowledge
• Advanced understanding of Battlezone's engine architecture
• Creator of essential modding tools including makemap
• Deep knowledge of texture systems and terrain generation
•Battlezone Lua Documentation[www.videoventure.org]


Official Tools (Included with BZ Install):
• MakeZFS - Archive creation and management utility
• MakeMAP - Terrain texture conversion and processing
• MakeTRN - Terrain file generation and world creation

Community-Created Tools:
• Business Lawyer's BZMAPIO - Blender Terrain Editor Addon for heightmap editing. See here as a starting point:• Kenshi IO Continued - Blender plugin for mesh editing and import/export
CodeBerg Link[codeberg.org]
• VDF/SDF Blender Plugin by Commando - Complete 3D model workflow integration
Commando's Site[commando950.neocities.org]
• DivisionByZero's VDF/SDF/Geo to Mesh Porting Script - Model conversion utilities
Available on Goomba's Site[bzmaps.net]
• PEdit - Palette editor for color management and ACT file editing
Available on Goomba's Site[bzmaps.net]
• Ogre Command Line Tools - Mesh processing and upgrader utilities
Available on Goomba's Site[bzmaps.net]
• Mesh Normal Correction
GrizzlyOne95's Github[github.com]


Other Tools:
• SmartNormal2.0 - Normal map generation tool[www.smart-page.net]
• HxD Hex Editor - For advanced VDF editing and spinner modifications[mh-nexus.de]
• Python - Needed for some tools and automation[www.python.org]
• Blender. Use 3.6 LTS for commando950's plugin and 4.1+ for Business Lawyer's Terrain Plugin.[www.blender.org]
• GIMP is a free image editing software that natively handles DDS[www.gimp.org]
• Audacity - Free Audio Editing/Conversion/Recording Tool[www.audacityteam.org]
• VLC - Can be used to convert to OGV video[www.videolan.org]



While every effort has been made to ensure the accuracy of the information in this guide, some details may be incomplete or subject to change. The Battlezone modding community continues to discover new techniques and refine existing knowledge.

Tool instructions and compatibility information were accurate at the time of compilation. Software updates, operating system changes, and hardware variations may affect functionality.



Community Contribution
• Share discoveries and techniques with the community
• Document your modding experiences and solutions
• Test and provide feedback on new tools and techniques
• Help newcomers learn modding skills

Knowledge Preservation
• Archive successful mod configurations
• Document troubleshooting solutions
• Maintain compatibility information
• Update guides with new discoveries


Community Channels
• Join Battlezone Discord servers for real-time discussion
• Participate in Steam Community discussions
• Share findings through Steam Guides
• Contribute to community wikis and resources


Special appreciation to the entire Battlezone modding community for their dedication to preserving and expanding this classic game. The collaborative spirit and willingness to share knowledge has made comprehensive guides like this possible.

The passion and creativity of the community continues to bring new life to Battlezone, creating content that extends far beyond what was originally envisioned. This guide represents the collective wisdom of that community effort.

This guide stands on the shoulders of every community member who has ever shared a tip, created a tool, documented a discovery, or helped a fellow modder solve a problem.

---

Last Updated: 2025
Community contributions ongoing