PsychoFred's Mod Tools Documentation--When Modding, read this first!

Started by Led, June 11, 2012, 05:13:47 AM

Previous topic - Next topic
Below are the items from the documentation folder of the mod tools. 

If you are new modder, read these first.

If you are an experienced modder, read these again.

Credits to PsychoFred for making this documentation and so much else for the game.

Here is the index.  When I have time, I will use this to link you to the proper post:
Guides
Getting Started -Not the most useful one, but still may have valuable information.
General Overview
Game Overview
Editing New Worlds
DATATemplate and Compiling
Zeroeditor
Mod1 Tutorial - Useful beginner one.
Mission LUA Guide
ODF Guide
Art Design Guide
Animation Guide
Editing The Sky
Fly-through Movie Making
Quote from: Abraham Lincoln. on November 04, 1971, 12:34:40 PM
Don't believe everything you read on the internet

June 11, 2012, 05:14:20 AM #1 Last Edit: June 19, 2012, 08:35:16 PM by SleepKiller
MESH & ANIMATION EXPORTING
Mesh
Place meshes zeroed in world, XZ plane is floor.
Freeze all transforms, (Zeroing out transform pivot point).
Assign a material, (either Lambert or Phong), to each mesh.
Assign a texture, (only one for enveloped objects), to each mesh.
Freeze the geometry, (collapse stack, delete construction history, whatever you like to call it).

Bones
Place bones with hierarchy as children of mesh. Bones can be Skeleton 2D/3D chain bones or nulls. (Bones can be geometry as well but shouldn't be used in the mesh.)
Place a traversing bone, (usually a null), as parent of the mesh. (just called "dummyroot") This bone defines the mesh traversing along the ground.
All bones mush have a direct parent/child relation. (Chain bone effectors must be linked to the last bone in IK chain.)
Place a world bone, (usually a null), as a parent to the traverse bone, (just called "grounddummy"), This will allow you to offset the animation starting point in the world.
Place hardpoints, (usually nulls or simple geometry), wherever needed. Hardpoints are simply bones that have the prefix "hp_". They are used as transform nodes that can be used as reference points for placing weapons, event hot spots, etc.

Rig
Rig nodes should not be in the hierarchy of the skeleton. Rig elements could be regarded as bones or offset child bone transforms otherwise. Use rig controllers to drive IK effectors and up vectors. Bones can be animated with IK or FK depending on the situation.

Enveloping
Most meshes require rigid enveloping meaning only one bone influence for each vertex, (this is mostly for soldiers & vehicles). Otherwise, you could have up to 3 bones influence each vertex but you must define it as "-softskin" in the meshes .option file, (I hope .option files are covered elsewhere). ;)

Animation
Do not animate the mesh, skeleton 2D/3D chain bone roots or effectors. It will offset child bones transforms. The traverse bone must start at the world bone, (it will zero the traverse bone transforms.) This is good for if you have multiple animations in a scene with different starting locations. The traverse bone must have only two keyframes from the beginning of the animation to the end of the animation sequence with only linear interpolation, (you could use spine interpolation to normalize certain overextended motions).

Exporting The Mesh
The enveloped mesh with the skeleton mush be exported as the in-game object name and the skeleton itself must be exported individually as a basepose, (called "basepose.msh").

Exporting The Animations
Remove all meshes from the skeleton hierarchy.
Set the start and end frame in the playback timeline boxes.
Branch select the traverse bone.
Export the mesh the using the exporter plugin. Be sure to have "Export Selected Models Only", "Export Animations" & "Export FK Animation" selected.

Quote from: Abraham Lincoln. on November 04, 1971, 12:34:40 PM
Don't believe everything you read on the internet

June 11, 2012, 05:14:42 AM #2 Last Edit: June 19, 2012, 08:35:51 PM by SleepKiller
ART DESIGN GUIDE

General walk-thru for creating objects for SW Battlefront

Models created in XSI can be put directly into the SW Battlefront engine with the proprietary exporter and by following a few simple rules.

Polygon Count Limits (general guidelines):

Props - 0 - 500 polys
Buildings - 200 - 3000 polys (the higher end of this spectrum represents large buildings with large interiors)
Vehicles - 1500 - 2000 polys
Characters - 1500 - 2000 polys


Every object will need a low resolution version of the mesh for LOD purposes. Those should be approximately 1/3rd of the original model's poly count, and a child of the model's root node. You must declare it a LOD mesh by appending "_lowrez" to its object name.

Every model also requires collision objects and shadowvolumes to be inserted into the hierarchy. See appendices b and c.

Textures are required to be scaled in powers of 2, with 512 x 512 being the standard used in the PC version. They all should be 24 bit .tga's, unless there is an alpha channel, then it will be a 32 bit file.

Steps to creating a basic prop:
1. Construct a fairly low-poly mesh (again, 0-500 polys for a prop) in XSI with the center of the root node with a translation of (0,0,0) in the scene. Try to minimize the number of actual objects in the prop by merging them. If it is not possible, just make sure all objects belong in one hierarchy, because if you don't, not all of them will be exported. Clusters are ok, but there can be only one set of textures coordinates. If you want to use a texture with an alpha channel, see Appendix A.
2. Create a shadowvolume. See Appendix B.
3. Create collision objects. See Appendix C.
4. Export the mesh. See Appendix D.



CREATING TERRAIN CUTTING OBJECTS

Each object that cuts terrain must:
Contain an object that is named "terraincutter"
Must be a child of an object.. not hidden on export.
Then after it is placed in the world through Zeroeditor it must be saved so the terrain file is overwritten.
After updating the world and TER file, there should be a hole in game.
At this point the cutter can be hidden on the object,(or for that matter removed?)
If its position or size changes it must be rexported and the terrain updated/saved again.
terraincutter object can not be concave. Multiples must be used to accomplish that.

if you have multiple terrain cutters they must be named
terraincutter1
terraincutter2
terraincutter3
" " no underscore between # terraincutter_2


Appendix A
Guide to using Transparency Maps

Follow these steps to create objects that use transparency maps.

1. Create a texture with an alpha channel and save it as a 32 bit TGA.
2. Apply it to the model.
3. Select all polygons that will be affected by the transparency map and run the EDIT FLAGS script.
4. A dialogue box will appear. Select either single or double sided transparency depending on your need or preference. Say OK.
5. If done correctly, you should notice an orange property box in the explorer under the newly flagged object. You can also edit the applied property box by clicking on the orange square itself anytime after the initial application. But, if you want to add additional polygons into the transparency flag, it is best just to delete the property, select all the polygons you want, and re-run the script.

Appendix B
Shadowvolumes

Shadowvolumes are special meshes that are created to mimic the model in shape and profile to cast shadows onto terrain and other objects. It can also be used for self-shadowing. Follow these steps to create a shadowvolume:

1. Create a low-poly mesh that is slightly smaller in scale than the original model's mesh. When both the original mesh and the shadowvolume are unhidden, you should not see any of the shadowvolume sticking out of the original model. Try to keep it as low-poly as possible, but pay special attention to the profile from the top down view or whatever angle the sun will be at in relation to the model. The silhouette is what needs the most attention, because this is what gets cast onto other objects. Also, the mesh must be completely closed without any open ends or polygons, and its global center is 0,0,0.
2. Once created, name the shadowvolume mesh "shadowvolume". If there is more than one, name them "shadowvolume", "shadowvolume1", "shadowvolume2", etc.
3. Make the shadowvolume mesh a child of the actual mesh to which it is related. This is especially important when there are multiple shadowvolumes and bones and animated parts in the model. If the original mesh is skinned, then the shadowvolumes should be children of their respected bones. Otherwise, they should just be children of the individual objects.
4. Select the shadowvolume mesh.
5. In the Animate menu, select Create -> Parameter -> New Custom Parameter.
6. In the dialogue box, rename the Parameter Name to shadowvolume. Uncheck the Animatable Characteristic Button.
7. Hide the shadowvolume mesh before export

Appendix C
Collision Meshes

Collision meshes are simple low-poly meshes that are used by the game engine to calculate when and how objects collide with each other. There are 2 types of collision meshes used in SW BattleFront: collision meshes and collision primitives.

Collision Mesh
1. This is usually a low-poly yet fairly conforming version of the original mesh. It is most often used for soldier and ordnance collision since those are most obvious ways to see collision mesh correctness. For example, you can see the ordnance collision on an object by shooting at it with any weapon. If the collision is sloppy and covers gaps or is not correctly aligned with the original mesh, then you will see the laser blasts hit empty space or inside the actual geometry of the model. The collision mesh has to be named "collision", or if there are more than one, "collision", "collision1", "collision2", etc. Multiple collision meshes will all get merged into one when munged. This is very important when considering rule #3. Do make the collision mesh a child of the root node or its corresponding node, and make sure its global center is at 0,0,0.

2. Enabling the Collision Mesh: if the vehicle .MSH file has a corresponding .OPTION file, then it might contain the argument "-nocollision". This is to prevent generation of a default collision mesh using the model's full geometry. If you have specified a collision mesh in XSI, you will need to remove this argument from the .OPTION file.

3. Collision meshes can NOT be used on moving parts (turrets, bones etc). When the vehicle is munged, all collision mesh nodes are merged into a single non-articulated collision mesh. If a moving part on a vehicle requires collision, it will have to be specified with a primitive.

4. If a vehicle has a collision mesh, it will automatically be used when colliding with soldiers and ordnance. Collision meshes (on vehicles) are not used for any other type of collision. Primitives must be used when vehicles collide with terrain, buildings, and other vehicles. Collision Primitives
--- Collision Primitives are a cheaper and faster way of computing collision for the game engine. It is also the only way to have collision on moving parts such as turrets or bones. Collision primitives can be either cubes, cylinders, or spheres. Cubes can be scaled in x,y, and/or z to better fit the geometry they are conforming to. It is best to leave the original size of 8 units as is and scale the cube from there. On the other hand, cylinders and spheres CANNOT be scaled. Instead, use the polygon properties such as radius and length to control the size of those 2 primitives. Also very important, primitive collision pieces CANNOT be frozen or lose their primitive properties. This information is taken directly into the game engine and if it is lost, the engine will most likely ignore the primitive collision. Lastly, DO NOT move the center of primitive collision either or else the proper information will be lost as well.

---There is a limit of 32 collision primitives per model (or 31 primitives + 1 collision mesh).

---Colliding with buildings (including bridges, stairways, etc) is a little tricky with primitives. It is best to use spheres and cylinders on the vehicle for building collision. Boxes just get converted to spheres in the code so long skinny boxes end up colliding as if they were large spheres. ***Note: if you must use boxes for the vehicle, you can instead create primitives for the building msh. In the building's odf file, you can then specify to use these primitives for VehicleCollision***

******** Specifying Collision in ODF file ********
---For any game object (true for vehicles and buildings), you can specify which collision primitives will be used when colliding with another object. For example, the AAT ODF file has the following:

TerrainCollision = "p_base"

VehicleCollision = "p_base"
VehicleCollision = "p_tank"
VehicleCollision = "p_barrell"
VehicleCollision = "p_turrett"

SoldierCollision = "p_base"
SoldierCollision = "p_tank"
SoldierCollision = "p_barrell"
SoldierCollision = "p_turrett"

BuildingCollision = "p_ball1"
BuildingCollision = "p_ball2"
BuildingCollision = "p_ball3"
BuildingCollision = "p_ball4"
BuildingCollision = "p_ball5"
BuildingCollision = "p_ball6"
BuildingCollision = "p_guns"
BuildingCollision = "p_turrett"
BuildingCollision = "p_barrell"


If you wanted to, you could also use OrdnanceCollision = "p_whatever" to specify what primitives to use when ordnance collide with the object.

---Finally, if
1. a vehicle has a collision mesh, AND
2. SoldierCollision and/or OrdnanceCollision is specified in its ODF file,

then the primitives specified in the ODF file will be used (for SoldierCollision and OrdnanceCollision) as well as the collision mesh. In this way, you can create a collision mesh for the non-moving parts of the vehicle, and add collision primitives for the moving parts, and use them both when colliding with soldiers or ordnance.

Appendix D
Mesh Exporting

The Mesh Exporter is a program/script that takes geometry models created in XSI and converts them into a .msh file that the SW Battlefront engine can understand and use in the game. Here are the steps needed to export a model:

1. Make sure the root node is centered in the XSI world at 0,0,0. If this is not so, you may get an unexpected center or position of the exported model in the game.
2. Branch select the object(s) you want to export.
3. Run the XSI2Mesh Exporter script.
4. This opens a dialogue box. In this you:
        a. In the Path box, browse or put in the correct path that you would like the .msh to be exported into. Also type in the filename in the filename box.
        b. Check the first box "Export Selected Models Only"
        c. Check the "Export Animations" box. ONLY if the model is animated and has a .zaabin or .zaafin file
        d. Check the "Export Textures" box if the texture is not in the target location of the .msh file.
5. Another pop-up box will show the progress of the export, once this closes, your export is complete.

Quote from: Abraham Lincoln. on November 04, 1971, 12:34:40 PM
Don't believe everything you read on the internet

June 11, 2012, 05:15:17 AM #3 Last Edit: June 19, 2012, 08:36:51 PM by SleepKiller
The Mod Add On Build File Structure
Included in the toolkit are sample mods set up with common assets that shipped with the game as working examples for reference. The mod tools working directory is outlined below.

Detailed Description of Files

/BFBuilder - main working directory
    /AddOn - created upon first munge, copy your compiled mods from here to your SWBF Addon folder
    /Assets - Folders of assets used to create worlds that shipped with game, XSI Addon, SPTEST.exe
    /Data - directory of common assets from shipped game, needed for munge
    /DataMod1 - Sample mod working directory
    /DataMod2 - Sample mod working directory
    /Documentation - Help files
    /ToolsFL - Executables required to munge and compile.

/DataTEMPLATE

    /_BUILD_PC/ - munged and precompiled files, also where munge and clean are executed
    /_LVL_PC/ - compiled files game ready which are copied to /Data/Addon for copying to game folder
    /_SOURCE_PC/ - files required by munge for localization and movie data that plays when level is selected
    /addme/ - The addme.lua script which adds the mission to the mission list
    /Build/ - Zeroedit files
    /Common/ - where supplemental common assets reside
    /Shell/ - where add on movie files are stored
    /Sides/ - where supplemental sides assets are stored
    /Sound/ - where supplemental sound assets are stored and configured
    /Worlds/ - where world folders are stored
            /ModWorldName/ - where individual world assets are stored
            /Effects/ - where world-specific particle effects are stored
            /MSH/ - where object mesh files are stored
            /munged/ - where pre-munged assets such as animations are stored
            /ODF/ - where world-specific ODFs are stored
            /World1/ - where the Zeroedit saved files are stored
    /config.ini - editor config file
    /edit_pc_addon_localize.bat - launches localization tool for add on level
    /soundmunge.bat - used to compile sound
    /soundmungedir.bat - used to compile sound
    /Zeroeditor.exe - the level editor

It is important to understand how the worlds are built so they may be debugged, so this section will provide an overview on the location of assets and how they are assembled into a functional world.

Process Overview
Functional worlds typically consist of a vertex heightmap terrain, object models, command post objects, unit spawn points, vehicle spawn pads, barriers, regions, ai path plans, map boundaries, and in some cases invisible collision objects.

Objects
Models are built with Softimage XSI and exported using a proprietary Add On that provides additional functionality such as shadow collision, transparent and animated textures. The models are exported to mesh (MSH) files that are reference by text files called Object Definition Files. Object definition files define all of the properties of an object so that it functions properly in game as well as in the map editor.

Map Editor
Zeroedit is the map editor which manipulates level objects. Once models have been properly prepared they can imported into a world and positioned accordingly. When a world is saved, different objects are saved in different files in the WORLD folder.

Munge and Compile
All of the assets and the text files defining how they are used are compiled in a two step process that is collectively called a MUNGE. When a mod is munged numerous batch files are executed in order and compile the assets into the _BUILD_PC folder. The _BUILD_PC folder does not contain the final compiled binaries, but rather pre-compiled assets that are not the raw assets. These precompiled raw assets are needed to build one another, so when all of the pre-compiled assets have been created they are finally compiled into the LVL files that are used by the game. The _LVL_PC directory structure is where the final data is stored to be used by the game as an Add On.

To compile a world, simply run MUNGE.BAT located in the _Build_PC folder for the add on. When the munge is complete, the compiled files will be copied to BFBuilder/Addon/Mod# where mod# is the name specified for the new world. Before every munge it is a good idea to "do a clean" by running CLEAN.BAT. This will delete all of the munged files in _Build_PC and _LVL_PC to ensure they are rebuilt.
Quote from: Abraham Lincoln. on November 04, 1971, 12:34:40 PM
Don't believe everything you read on the internet

June 11, 2012, 05:15:39 AM #4 Last Edit: June 19, 2012, 08:37:28 PM by SleepKiller
Game Overview
At it's core each level consists of a minimum of two opposing teams each owning at least one command post from which their units spawn. Each command post can be captured by the enemy if a unit enters a capture region linked to the command post and holds it's position for long enough. When a command post is captured the spawn path attached to it is taken over by the capturing team and it's units will spawn from that command post. When all of the command posts are owned by one team or a team runs out of reinforcements the game is over.
The game itself is made up of levels created with a terrain editor consisting of objects created with Softimage XSI and exported using a special add on that outputs a mesh file. The models are recognized by the editor by way of an Object Definition File, a text file that defines an object and all of it's properties. The ODF files define the properties of objects not just for the game but also for the editor. Once a model is exported an ODF file must be manually created first before it can be used in the editor.

The terrain editor is a heightmap editor and object layout application that allows for generation and manipulation of a textured vertex heightmap as terrain as well as opening models exported from XSI. In addition to manipulation of objects and terrain the editor also has modes for creating unit spawn paths and vehicle spawns, AI paths and barriers, invisible capture, control, sound, and shadow regions, and map boundaries. Files saved by the editor are used by the munge compiler in a two step process to prepare assets for use in the game as an add on.

Level Requirements
Each level requires some type of terrain or object on which to play, two command posts and two teams. Teams capture enemy command posts or eliminate enemy reinforcements in order to win a victory on a level. As long as a team holds more than zero command posts and has reinforcements the victory/defeat clock will not start.

Terrain
Each level must have a terrain or object on which the players can spawn. If a vertex map terrain is not created then models imported into the world can serve as the battle platform. Units can only be spawned from fixed positions, meaning units cannot spawn inside vehicles so some type of fixed object is required.

Teams
Each team on a level consists of up to 5 Unit Classes and 1 Hero Class. The Hero Class units on a level are always non-playable characters. Each Unit Class is defined as a specific unit type whose in game count can be set manually while only one hero per team can be in play at a time. Units are spawned into the world from Spawn Paths that are attached to team-owned command posts.

Command Posts
Command posts are buildings or objects that can be owned or captured by a team. Each command post is assigned a value to each team in a given mission. Enemy units attack command posts based on their value and proximity. AI will target the nearest command post first, and if more than one is an equal distance away the one of highest value will be targeted first. Each command post also has a Bleed Value, which is taken into account to determine the rate at which a team’s reinforcement count degrades throughout the mission. Command posts are typically attached to a Spawn Path, a Capture Region, and a Control Region.

Spawn Paths
Spawn Paths are invisible objects from which units spawn into the game. Spawn Paths must be attached to command posts to function. Each spawn path has a unique name that is attached to the command post and an unlimited number of spawn nodes that acts as points from which units spawn. While a command post may exist in one place, the spawn points associated with it can be scattered across a map.

Capture Regions A Capture Region is attached to a command post instance and acts as a zone that when occupied by an enemy unit triggers the capture of a command post. It is the center of the capture region that the AI units flock to in order to capture a command post.

Control Regions
Control Regions can also be attached to command posts. A control region is used to control whatever is within it when the command post it belongs to is owned by a particular team. The most common use for control regions is to act as zones where vehicles can be spawned and remain intact without degrading. Once a vehicle leaves a team’s control zone it is considered "in the field" and if abandoned will begin degrading. A Vehicle Spawn point must also be located within a control region in order to spawn vehicles.

Barriers
Objects on a level are not recognized by the AI when it plans it’s course to a command post. Barriers are placed around objects the AI can collide with so they will plot a course around the object. Barriers act as invisible boxes that the AI recognize and calculate the area of in order to plot a course around objects. Each barrier also has a set of filters that determine what AI types can pass through them. AI cannot chart a course to a command post that is within a barrier filtering out that AI type.

Planning Paths
Planning Paths are made up of Hubs and Connections forming a Connectivity Graph that defines routes taken by AI as they plot a course to a command post. When an AI unit plans a path to a command post it looks for the closest command post that is not owned by it’s team and charts a course. By default, the AI will take the most direct course from it’s starting point, a straight line. When a connectivity graph is present the AI looks first for the nearest command post, then the nearest connectivity hub and sets whichever is closer as it’s destination.

Hint Nodes
To further control AI behavior, Hint Nodes can be used. Hint Nodes are hotspots with properties that designate AI behavior on those spots. These include Snipe, Patrol, Jet Jump, Mine, Cover, Access, and Land. These node types also have additional properties such as attack/defend, standing, prone or crouch. When an AI comes into proximity with a Hint Node they will occupy it and take the specified action if applicable. If after a certain amount of time the unit encounters no enemy units it will leave that node and plot a course to the nearest command post not owned by it’s team. Gun turrets do not require hint nodes for AI to occupy them, technically the turrets are vehicles but are treated like Hint Nodes by the AI.

Boundaries
Each map has at least one Boundary that when crossed triggers a countdown to death and a message that the unit is leaving the battlefield. Boundaries are required not just to define the playable area on a map but also to control the aesthetic appearance of the battlefield. If a unit moves too close to the edge of the map, the edge of the terrain or sky can become visible.

Vehicle Spawns
A Vehicle Spawn is in an invisible object that when placed in the control region of a command post can spawn a vehicle for the team that owns the command post. Vehicle spawns can spawn different vehicles for each team or no vehicles at all.

Common Objects
There are numerous common objects in the game that provide functionality to maps. These include Weapon Recharge Droids, Health Recharge Droids, Vehicle Recharge Droids, and Gun Turrets. These objects are not team or world specific.

Add On Functionality
When the game is executed after the 1.11 (Jabba's Palace) patch has been installed, the game looks for the Add On folder and any folders beneath it. TAT3 is there by default. It looks at each folder in the Add On folder in order for an addme.script file and appends the in game mission list with new map names one by one.

Compiled add on maps also make use of assets shipped with the game, so even though they are not beneath the add on folder, the maps require the intact assets of the shipped version of the game.

Files required to run an Add Ons are created first building a new map and compiling a new map. This can be done with BFBuilder.hta in an automated fashion or by using the manual instructions provided in the tutorial. While this is not difficult, there are manual steps that must be taken and a solid understanding of how the game is built will be required. Mod Templates have been provided as examples for reference as well as starting points. Each Mod Template can be loaded and saved to a new folder under a new name and then edited manually so it will run.
Quote from: Abraham Lincoln. on November 04, 1971, 12:34:40 PM
Don't believe everything you read on the internet

June 11, 2012, 05:16:12 AM #5 Last Edit: June 19, 2012, 08:40:51 PM by SleepKiller
SWBF MOD Toolkit
Introduction
This kit will allow users to create their own levels for Star Wars Battlefront. These tools are unofficial and are not officially supported by Lucasarts or Pandemic Studios. Any support received from employees of either company is unofficial and neither company is obligated to respond to requests for support. Use them at your own risk.

Guides
Game Overview
DATATemplate and Compiling
Zeroeditor
Getting Started
Mod1 Tutorial
Mission LUA Guide
ODF Guide
Art Design Guide
Animation Guide


The Star Wars Battlefront mod tool kit consists of the applications, assets, and documentation required to build, test and run new maps.

Also included in this tool kit is a special add on for Softimage XSI 4.2 or greater that allows for the creation of new models for use in Star Wars Battlefront.

This tool kit consists of the following:
- Zeroedit, the map editor created by Pandemic Studios
- PartcleEditor, the application used to create particle effects
- XSI2MSHExporter, the XSI Add On for exporting models
- Munge compiler, a collection of applications that compile the game assets


Also included in the Star Wars Battlefront tool kit are the pre-compiled assets used to create the missions, sides, and maps in the shipped version of Star Wars Battlefront. These precompiled assets consist of model files exported using the proprietary exporter, texture files typically created with Adobe Photoshop, binary and text files created by the map editor, and text files used to control the properties of everything in the game. These text files come in two forms, config files of various types and script files. The script files use a scripting language called LUA, but knowledge of LUA is unnecessary for making changes to the existing game.

SWBF Patch 1.11
The tool kit is designed for use with Star Wars Battlefront version 1.11. The 1.11 update is required for the game to make use of Add Ons, such as Jabba's Palace and any additional maps or assets added to the game after it shipped. Once installed the patch creates a folder in the same location as the Star Wars Battlefront executable called AddOn. Each new map needs to be placed in it's own folder in the AddOn folder for version 1.11 to detect it and add it to the mission list so it is playable.

Kit Contents
Included in this kit are two template mods; Mod1 and Mod2, as well as a directory entitled DATATEMPLATE. The creation of Mod1 is outlined in a tutorial, and the DATATEMPLATE directory is a blank folder structure specially prepared for duplication, renaming, and modifcation in order to create new levels. Zeroeditor, the level editor is also included as part of the DataTEMPLATE, and it's use is detailed in the included documentation.

Assets for worlds and sides that shipped with the game are included in the assets folder to be copied into world folders as needed. Also included in the assets folder are the Pandemic XSI Addon which allows new models to be exported for use in mods and SPTEST.exe, a special game executable that provides a console for displaying information used in building levels. The assets folder also contains the DATATAT3 folder which contains the precompiled Jabba's Palace addon. This is a good reference for Add Ons since it was the first add on and makes use of assets that shipped with the game as well as shipped separately. It also includes a third team, the Gammorreans, which serve as a reference for setting up a third side in an add on level.

Documentation assembled and written by Chris Fusco aka psych0fred
Special thanks to Paul Baker, Chris McGee, and Juan Sanchez for their contribution to the documentation
Kudos to Mike Zaimont for his awesome work on the editor and XSI plugin, Nathan Mates for building the invaluable SPTEST.exe, and Carey Chico for providing his valuable knowledge and support.

Quote from: Abraham Lincoln. on November 04, 1971, 12:34:40 PM
Don't believe everything you read on the internet

June 11, 2012, 05:16:35 AM #6 Last Edit: June 19, 2012, 08:41:33 PM by SleepKiller
MISSION LUA GUIDE

In this guide two LUAs will be gone over, first explaining the sections and then explaining the individual lines and their arguments.

Mission LUA scripts define all the of the global properties for a level and are required for each mission. Typically there are two missions per map, 1 Clone Wars Era mission and one Galactic Civil War Era mission. These mission lua scripts are named using the three letter and number level naming convention with a letter added to the end to denote the attacking team. In the case of Mod1, the lua scripts are named Mod1a.lua and Mod1c.lua. They could just as easily be Mod1i and Mod1r as long as the contents of each file define the attacker correctly.

Below is a line by line breakdown of Mod1a.lua with a brief explanation of what each section does. Comments about each line are prefaced with >>

Originally there 4 maps per world minimum, one with each team attacking and different vehicle loadouts, unit loadouts, and strategies for each. This meant each world had four mission lua script plus one for the historical campaign denoted with an _h in the name as in mod1a_h.lua

A Word About Luas, Reqs, and Lvls
These file types are intertwined. Reqs are requirements files and define assets required for a mission or object. Every REQ generates an LVL when munged. Munging is the what the compile process is called. During the munge req files are read and the assets compiled into LVLs that are then compiled inside other LVLs. These LVLs and sub-lvls are loaded and referenced in the mission lua script as it relates to loading assets for a given level. This same structure with added file types applies to art and sound in the game.


mod1a.lua Start
>>
>> Note about Mission lua naming conventions:
>> The mission luas must always following the three-letter, 1 number, 1 letter naming convention.
>> COmments always appear prefaced by --

---------------------------------------------------------------------------
-- FUNCTION:    ScriptInit
-- PURPOSE:     This function is only run once
-- INPUT:
-- OUTPUT:
-- NOTES:       The name, 'ScriptInit' is a chosen convention, and each
--              mission script must contain a version of this function, as
--              it is called from C to start the mission.
---------------------------------------------------------------------------

function ScriptInit()
--  Empire Attacking (attacker is always #1)
    local ALL = 1
    local IMP = 2
--  These variables do not change
    local ATT = 1
    local DEF = 2
>>
>> The above section defines the script and the two teams and which is declared as the attacker.
>> The attacker on a map is always team 1, and the name of the mission lua script reflects the
>> attacker. In this case the Alliance is the attacker but it could just as easily be the Empire.
>>


    AddMissionObjective(IMP, "red", "level.mod1.objectives.1");
    AddMissionObjective(IMP, "orange", "level.mod1.objectives.2");
    AddMissionObjective(IMP, "orange", "level.mod1.objectives.3");
    AddMissionObjective(ALL, "red", "level.mod1.objectives.1");
    AddMissionObjective(ALL, "orange", "level.mod1.objectives.2");
    AddMissionObjective(ALL, "orange", "level.mod1.objectives.3");

>>
>> The above section defines the localization strings for mission objectives.
>> These are localization strings that are stored in the localization file which references
>> the actual text that appears in the game. See the localization guide for more details.
>>

    ReadDataFile("sound\\tat.lvl;tat1gcw")
    ReadDataFile("SIDE\\all.lvl",
    "all_inf_basicdesert",
    "all_inf_lukeskywalker",
        "all_inf_smuggler");

    ReadDataFile("SIDE\\imp.lvl",
        "imp_inf_basic_tie",
    "imp_inf_darthvader",
        "imp_inf_dark_trooper");

   -- ReadDataFile("dc:SIDE\\gam.lvl",
   --     "gam_inf_gamorreanguard")


>>
>> All ReadDataFile lines reference LVL files that contain assets that need to be loaded and
>> the specific assets to be loaded by the level. First the sound.lvl is loaded and the sound assets
>> for the specific era. In mods, for legal reasons the sound lvls that shipped with the game cannot
>> be distributed, but if you would like to add sounds to the game functionality has been provided to
>> build your own sound lvls in order to put sounds into your levels.

    SetAttackingTeam(ATT);

>>
>> The SetAttacking Team line denotes which team is the attacker.SetDefendingTeam(DEF); may also
>> be called.
>>

--      Alliance Stats
    SetTeamName(ALL, "Alliance")
    SetTeamIcon(ALL, "all_icon")
    AddUnitClass(ALL, "all_inf_soldierdesert",10)
    AddUnitClass(ALL, "all_inf_vanguard",1)
    AddUnitClass(ALL, "all_inf_pilot",2)
    AddUnitClass(ALL, "all_inf_marksman",2)
    AddUnitClass(ALL, "all_inf_smuggler",1)
    SetHeroClass(ALL, "all_inf_lukeskywalker")

--      Imperial Stats
    SetTeamName(IMP, "Empire")
    SetTeamIcon(IMP, "imp_icon")
    AddUnitClass(IMP, "imp_inf_storm_trooper",10)
    AddUnitClass(IMP, "imp_inf_shock_trooper",1)
    AddUnitClass(IMP, "imp_inf_pilottie",2)
    AddUnitClass(IMP, "imp_inf_scout_trooper",2)
    AddUnitClass(IMP, "imp_inf_dark_trooper",1)
    SetHeroClass(IMP, "imp_inf_darthvader")


>>
>> The team stats define the team names, team icon, unit hero classes and their loadouts.
>>

--  Attacker Stats
    SetUnitCount(ATT, 16)
    SetReinforcementCount(ATT, 200)
--    AddBleedThreshold(ATT, 31, 0.0)
--    AddBleedThreshold(ATT, 21, 0.75)
    AddBleedThreshold(ATT, 11, 0.75)
    AddBleedThreshold(ATT, 10, 1.5)
    AddBleedThreshold(ATT, 1, 3.0)

--  Defender Stats
    SetUnitCount(DEF, 16)
    SetReinforcementCount(DEF, 200)
--    AddBleedThreshold(DEF, 31, 0.0)
--    AddBleedThreshold(DEF, 21, 0.75)
    AddBleedThreshold(DEF, 11, 0.75)
    AddBleedThreshold(DEF, 10, 1.5)
    AddBleedThreshold(DEF, 1, 3.0)

>>
>> The attacker and defender stats set the team total units counts, the bleed thresholds and their triggers
>>


--  Local Stats
--   SetTeamName(3, "locals")
--   AddUnitClass(3, "gam_inf_gamorreanguard",3)
--   SetUnitCount(3, 3)
--   SetTeamAsEnemy(3, ATT)
--   SetTeamAsEnemy(3, DEF)

>>
>> Local stats sets up the 3 team on maps where there is an NPC team.
>>

--  Level Stats
    ClearWalkers()
    AddWalkerType(0, 0)
-- AddWalkerType(1, 4)
    AddWalkerType(2, 0)
--SetMemoryPoolSize("EntityHover", 12)
--SetMemoryPoolSize("EntityFlyer", 5)
--  SetMemoryPoolSize("EntityBuildingArmedDynamic", 16)
--  SetMemoryPoolSize("EntityTauntaun", 0)
--  SetMemoryPoolSize("MountedTurret", 22)
    SetMemoryPoolSize("PowerupItem", 60)
--    SetMemoryPoolSize("SoundSpaceRegion", 85)
    SetMemoryPoolSize("EntityMine", 40)
    --SetMemoryPoolSize("Aimer", 200)
--    SetMemoryPoolSize("Obstacle", 725)
    --SetMemoryPoolSize("EntityLight", 150)
    SetSpawnDelay(10.0, 0.25)
    ReadDataFile("dc:MOD\\mod1.lvl")
    SetDenseEnvironment("false")
    --AddDeathRegion("Sarlac01")
  --  SetMaxFlyHeight(90)
  --  SetMaxPlayerFlyHeight(90)

>>
>> Level stats declare various memory pools settings that need to be adjusted on
>> an as needed basis as indicated by debug errors.
>> Walker type memory allocations are declared in this section as well.
>> The level world lvl to be loaded for a world is declared in this section as well
>> as level-specific properties that need declaring such as the addition of a death
>> region and the type of combat environment.
>>


--  Sound Stats
    OpenAudioStream("sound\\tat.lvl",  "tatgcw_music");
   -- OpenAudioStream("dc:sound\\mod.lvl",  "mod1");
   -- OpenAudioStream("dc:sound\\mod.lvl",  "mod1");
    OpenAudioStream("sound\\gcw.lvl",  "gcw_vo");
    OpenAudioStream("sound\\gcw.lvl",  "gcw_tac_vo");
   --  OpenAudioStream("dc:sound\\mod.lvl",  "mod1_emt");
   --OpenAudioStream("dc:sound\\tat.lvl",  "tat3_emt");

    SetBleedingVoiceOver(ALL, ALL, "all_off_com_report_us_overwhelmed", 1);
    SetBleedingVoiceOver(ALL, IMP, "all_off_com_report_enemy_losing",   1);
    SetBleedingVoiceOver(IMP, ALL, "imp_off_com_report_enemy_losing",   1);
    SetBleedingVoiceOver(IMP, IMP, "imp_off_com_report_us_overwhelmed", 1);

    SetLowReinforcementsVoiceOver(ALL, ALL, "all_off_defeat_im", .1, 1);
    SetLowReinforcementsVoiceOver(ALL, IMP, "all_off_victory_im", .1, 1);
    SetLowReinforcementsVoiceOver(IMP, IMP, "imp_off_defeat_im", .1, 1);
    SetLowReinforcementsVoiceOver(IMP, ALL, "imp_off_victory_im", .1, 1);

    SetOutOfBoundsVoiceOver(2, "Allleaving");
    SetOutOfBoundsVoiceOver(1, "Impleaving");

    SetAmbientMusic(ALL, 1.0, "all_tat_amb_start",  0,1);
    SetAmbientMusic(ALL, 0.99, "all_tat_amb_middle", 1,1);
    SetAmbientMusic(ALL, 0.1,"all_tat_amb_end",    2,1);
    SetAmbientMusic(IMP, 1.0, "imp_tat_amb_start",  0,1);
    SetAmbientMusic(IMP, 0.99, "imp_tat_amb_middle", 1,1);
    SetAmbientMusic(IMP, 0.1,"imp_tat_amb_end",    2,1);

    SetVictoryMusic(ALL, "all_tat_amb_victory");
    SetDefeatMusic (ALL, "all_tat_amb_defeat");
    SetVictoryMusic(IMP, "imp_tat_amb_victory");
    SetDefeatMusic (IMP, "imp_tat_amb_defeat");



    SetSoundEffect("ScopeDisplayZoomIn",  "binocularzoomin");
    SetSoundEffect("ScopeDisplayZoomOut", "binocularzoomout");
    --SetSoundEffect("WeaponUnableSelect",  "com_weap_inf_weaponchange_null");
    --SetSoundEffect("WeaponModeUnableSelect",  "com_weap_inf_modechange_null");
    SetSoundEffect("SpawnDisplayUnitChange",       "shell_select_unit");
    SetSoundEffect("SpawnDisplayUnitAccept",       "shell_menu_enter");
    SetSoundEffect("SpawnDisplaySpawnPointChange", "shell_select_change");
    SetSoundEffect("SpawnDisplaySpawnPointAccept", "shell_menu_enter");
    SetSoundEffect("SpawnDisplayBack",             "shell_menu_exit");

    --SetPlanetaryBonusVoiceOver(IMP, IMP, 0, "imp_bonus_imp_medical");
    --SetPlanetaryBonusVoiceOver(IMP, ALL, 0, "imp_bonus_all_medical");
    --SetPlanetaryBonusVoiceOver(IMP, IMP, 1, "");
    --SetPlanetaryBonusVoiceOver(IMP, ALL, 1, "");
    --SetPlanetaryBonusVoiceOver(IMP, IMP, 2, "imp_bonus_imp_sensors");
    --SetPlanetaryBonusVoiceOver(IMP, ALL, 2, "imp_bonus_all_sensors");
    SetPlanetaryBonusVoiceOver(IMP, IMP, 3, "imp_bonus_imp_hero");
    SetPlanetaryBonusVoiceOver(IMP, ALL, 3, "imp_bonus_all_hero");
    --SetPlanetaryBonusVoiceOver(IMP, IMP, 4, "imp_bonus_imp_reserves");
    --SetPlanetaryBonusVoiceOver(IMP, ALL, 4, "imp_bonus_all_reserves");
    --SetPlanetaryBonusVoiceOver(IMP, IMP, 5, "imp_bonus_imp_sabotage");--sabotage
    --SetPlanetaryBonusVoiceOver(IMP, ALL, 5, "imp_bonus_all_sabotage");
    --SetPlanetaryBonusVoiceOver(IMP, IMP, 6, "");
    --SetPlanetaryBonusVoiceOver(IMP, ALL, 6, "");
    --SetPlanetaryBonusVoiceOver(IMP, IMP, 7, "imp_bonus_imp_training");--advanced training
    --SetPlanetaryBonusVoiceOver(IMP, ALL, 7, "imp_bonus_all_training");--advanced training

    --SetPlanetaryBonusVoiceOver(ALL, ALL, 0, "all_bonus_all_medical");
    --SetPlanetaryBonusVoiceOver(ALL, IMP, 0, "all_bonus_imp_medical");
    --SetPlanetaryBonusVoiceOver(ALL, ALL, 1, "");
    --SetPlanetaryBonusVoiceOver(ALL, IMP, 1, "");
    --SetPlanetaryBonusVoiceOver(ALL, ALL, 2, "all_bonus_all_sensors");
    --SetPlanetaryBonusVoiceOver(ALL, IMP, 2, "all_bonus_imp_sensors");
    SetPlanetaryBonusVoiceOver(ALL, ALL, 3, "all_bonus_all_hero");
    SetPlanetaryBonusVoiceOver(ALL, IMP, 3, "all_bonus_imp_hero");
    --SetPlanetaryBonusVoiceOver(ALL, ALL, 4, "all_bonus_all_reserves");
    --SetPlanetaryBonusVoiceOver(ALL, IMP, 4, "all_bonus_imp_reserves");
    --SetPlanetaryBonusVoiceOver(ALL, ALL, 5, "all_bonus_all_sabotage");--sabotage
    --SetPlanetaryBonusVoiceOver(ALL, IMP, 5, "all_bonus_imp_sabotage");
    --SetPlanetaryBonusVoiceOver(ALL, ALL, 6, "");
    --SetPlanetaryBonusVoiceOver(ALL, IMP, 6, "");
    --SetPlanetaryBonusVoiceOver(ALL, ALL, 7, "all_bonus_all_training");--advanced training
    --SetPlanetaryBonusVoiceOver(ALL, IMP, 7, "all_bonus_imp_training");--advanced training

>>
>> Sound stats declares all of the sound assets loaded for a level as well as mission-specific
>> sound properties. It addresses first sound type meaning stream or static effects, then begins
>> pointing to assets within those streams and LVLs. This includes victory and defeat tracks, global
>> sound effects, amibient streams, ambient emitters, command post voiceovers, bleed rate voiceovers,
>> planetary bonus voiceovers for galactic conquest and for multiplayer heros.
>>
>> The global sounds and music are called as it relates to the mission and the sounds assets were
>> built for each level and mesured to fit into memory. On the PC there should be an excess of free
>> memory to add sounds and if these streams are not called the call can be replaced with one to a
>> stream or static lvl you have created. Each command post can have specific voiceovers or common
>> ones can be used.
>>
>> For legal reasons the sounds and music that shipped with the game cannot be used in mods without
>> the mods being licensed so artists get paid for their work, and this includes all sounds that
>> shipped with the game. Keep in mind sounds added to mods must also abide by the licensing
>> agreement attached to the mod tools. Questions regarding usage can forwarded to the address in
>> the agreement.
>>



--  Camera Stats
--Tat 3 - Jabbas' Palace
    AddCameraShot(0.685601, -0.253606, -0.639994, -0.236735, -65.939224, -0.176558, 127.400444);
    AddCameraShot(0.786944, 0.050288, -0.613719, 0.039218, -80.626396, 1.175180, 133.205551);
    AddCameraShot(0.997982, 0.061865, -0.014249, 0.000883, -65.227898, 1.322798, 123.976990);
    AddCameraShot(-0.367869, -0.027819, -0.926815, 0.070087, -19.548307, -5.736280, 163.360519);
    AddCameraShot(0.773980, -0.100127, -0.620077, -0.080217, -61.123989, -0.629283, 176.066025);
    AddCameraShot(0.978189, 0.012077, 0.207350, -0.002560, -88.388947, 5.674968, 153.745255);
    AddCameraShot(-0.144606, -0.010301, -0.986935, 0.070304, -106.872772, 2.066469, 102.783096);
    AddCameraShot(0.926756, -0.228578, -0.289446, -0.071390, -60.819584, -2.117482, 96.400620);
    AddCameraShot(0.873080, 0.134285, 0.463274, -0.071254, -52.071609, -8.430746, 67.122437);
    AddCameraShot(0.773398, -0.022789, -0.633236, -0.018659, -32.738083, -7.379394, 81.508003);
    AddCameraShot(0.090190, 0.005601, -0.993994, 0.061733, -15.379695, -9.939115, 72.110054);
    AddCameraShot(0.971737, -0.118739, -0.202524, -0.024747, -16.591295, -1.371236, 147.933029);
    AddCameraShot(0.894918, 0.098682, -0.432560, 0.047698, -20.577391, -10.683214, 128.752563);

>>
>> The Camera stats section defines the coordinate for the screenshots that appear in the game using
>> in game coordinates. Using free cam mode in the SPTEST.exe supplied, modders can navigate to a spot
>> and dump the coordinates to a file called cameracoordinates.txt by typing dumpcamera in the console.
>>


end

>>
>> The end of the lua function
>>
End of Mod1a.lua script

This next lua was from Geonosis which had an active third team, the Geonosians. It also had every vehicle class and serves as a good sample to go through line by line. This script is geo1r.lua


---------------------------------------------------------------------------
-- FUNCTION:    ScriptInit
-- PURPOSE:     This function is only run once
-- INPUT:
-- OUTPUT:
-- NOTES:       The name, 'ScriptInit' is a chosen convention, and each
--              mission script must contain a version of this function, as
--              it is called from C to start the mission.
---------------------------------------------------------------------------

>> The header comments are self explanatory



function ScriptInit()
--  REP Attacking (attacker is always #1)
    local REP = 1
    local CIS = 2
--  These variables do not change
    local ATT = 1
    local DEF = 2


>> The script is initialized and the teams defined. On geo the Republic was the
>> attacker.

        AddMissionObjective(CIS, "orange", "level.geo1.objectives.1r");
    AddMissionObjective(CIS, "red", "level.geo1.objectives.2r");
    AddMissionObjective(CIS, "red", "level.geo1.objectives.3r");
    AddMissionObjective(REP, "orange", "level.geo1.objectives.1r");
    AddMissionObjective(REP, "red", "level.geo1.objectives.4r");
    AddMissionObjective(REP, "red", "level.geo1.objectives.5r");

>> Mission objective strings serve as markers to the actual text to be used in
>> game which resides in a localization file that is prepped for each language.
>> If there is no info in the localization file that matches the strings in the
>> lua, what you see above will be displayed in game. The argument itself sets
>> the objects per team, color, and string. Use the multilanguage tool that
>> shipped with the tools by doubleclicking edit_pc_addon_localize.bat in the datamod/
>> directory to use the tool. The scopes and keys in the sample should provide enough
>> information to rename or add new scopes for your mods.


SetTeamAggressiveness(CIS, 1.0)
SetTeamAggressiveness(REP, 1.0)

>> SetTeamAgressiveness is obsolete and is unused. Difficulty is determined in code
>> using the difficulty settings in game or on a server.
>>


    ReadDataFile("sound\\geo.lvl;geo1cw");

>> ReadDataFile loads the geo.lvl sound file in the path specified and then loads just
>> the geo1cw segment. This line loads the static sound effects for the game. In mods
>> the addon directory is always referenced as DC: something which stands for downloadable
>> content and tells the game to look in the addon folder path under the mod directory.
>> The path for new sounds would be ReadDataFile("dc:sound\\mod.lvl") (or whatever three letter
>> abbreviation exists for your world.
>>

    ReadDataFile("SIDE\\rep.lvl",
        "rep_bldg_forwardcenter",
        "rep_fly_assault_dome",
        "rep_fly_gunship",
        "rep_fly_gunship_dome",
        "rep_fly_jedifighter_dome",
        "rep_inf_basic",
        "rep_inf_jet_trooper",
        "rep_inf_macewindu",
        "rep_walk_atte")
    ReadDataFile("SIDE\\cis.lvl",
        "cis_fly_droidfighter_dome",
        "cis_fly_fedcoreship_dome",
        "cis_fly_geofighter",
        "cis_fly_techounion_dome",
        "cis_inf_basic",
        "cis_inf_countdooku",
        "cis_inf_droideka",
        "cis_tread_hailfire",
        "cis_walk_spider")
    ReadDataFile("SIDE\\geo.lvl",
        "gen_inf_geonosian")

>>
>> These ReadDataFiles segments load the side-speciifc assets for all three teams.
>> the assets being referenced relate to the geometry of the units.


--  Level Stats

    ClearWalkers()
    SetMemoryPoolSize("EntityWalker", -2)
    AddWalkerType(0, 8) -- 8 droidekas (special case: 0 leg pairs)
    AddWalkerType(2, 2) -- 2 spider walkers with 2 leg pairs each
    AddWalkerType(3, 2) -- 2 attes with 3 leg pairs each
    SetMemoryPoolSize("CommandWalker", 2)
    SetMemoryPoolSize("EntityFlyer", 5)
    SetMemoryPoolSize("EntityHover", 3)
--  SetMemoryPoolSize("EntityCarrier", 2)
--  SetMemoryPoolSize("EntityTauntaun", 0)
--  SetMemoryPoolSize("CommandBuildingArmed", 2)
    SetMemoryPoolSize("PowerupItem", 25)
    SetMemoryPoolSize("MountedTurret", 50)
    SetMemoryPoolSize("Aimer", 200)
    SetSpawnDelay(10.0, 0.25)


>> Level stats define memory pools when necessary as indicated by messages genereated
>> in the SPTEST.exe console or log file. Walkers are a special case and need to be
>> handled carefully because they are memory muncher.
>> The SetMemoryPoolSize("EntityWalker", -2) line may be obsolete, but it used to be called
>> as a flag requirement for the command walkers, in this case the ATTE.
>> The AddWalkerType argument first declares the walker class by leg pairs, where 0 is a
>> special class for droideka, which are actually vehicles.
>> The memory pool classes are numerous and if they are not set or not set high enough
>> messages will be generated in the console or log.
>> Carrier class applies to the Gunship, TaunTaun to the TaunTauns and Kaadu class.
>> Aimers apply to anything with an aimer, vehicles, weapons, units, turrets, etc.
>> The things that aim, the more memory required.
>> SetSpawnDelay is the spawn delay and deviation.


--    Republic Stats
    SetTeamName(REP, "Republic")
    SetTeamIcon(REP, "rep_icon")
    AddUnitClass(REP, "rep_inf_clone_trooper",14)
    AddUnitClass(REP, "rep_inf_arc_trooper",4)
    AddUnitClass(REP, "rep_inf_clone_pilot",5)
    AddUnitClass(REP, "rep_inf_clone_sharpshooter",5)
    AddUnitClass(REP, "rep_inf_macewindu",4)
    SetHeroClass(REP, "rep_inf_macewindu")
--  SetCarrierClass(REP, "rep_fly_vtrans")

--  CIS Stats
    SetTeamName(CIS, "CIS")
    SetTeamIcon(CIS, "cis_icon")
    AddUnitClass(CIS, "cis_inf_battledroid",11)
    AddUnitClass(CIS, "cis_inf_assault",3)
    AddUnitClass(CIS, "cis_inf_pilotdroid",4)
    AddUnitClass(CIS, "cis_inf_assassindroid",4)
    AddUnitClass(CIS, "cis_inf_droideka",3)
    SetHeroClass(CIS, "cis_inf_countdooku")


>> The team stats declares the unit loadouts per class as well as call the team icon and
>> set the team name. The unit loadout counts must add up to the total counts in the SetUnitCount
>> arguments below. Each mission can have a maximum of five unit classes and one hero class unit.

--  Attacker Stats
    SetUnitCount(ATT, 32)
    SetReinforcementCount(ATT, 250)
    AddBleedThreshold(ATT, 31, 0.0)
    AddBleedThreshold(ATT, 21, 0.75)
    AddBleedThreshold(ATT, 11, 2.25)
    AddBleedThreshold(ATT, 1, 3.0)
    SetTeamAsEnemy(ATT,3)

--  Defender Stats
    SetUnitCount(DEF, 25)
    SetReinforcementCount(DEF, 250)
    AddBleedThreshold(DEF, 31, 0.0)
    AddBleedThreshold(DEF, 21, 0.75)
    AddBleedThreshold(DEF, 11, 2.25)
    AddBleedThreshold(DEF, 1, 3.0)
    SetTeamAsFriend(DEF,3)

--  Local Stats
    SetTeamName(3, "locals")
    AddUnitClass(3, "geo_inf_geonosian", 7)
    SetUnitCount(3, 7)
    SetTeamAsFriend(3, DEF)


>> Attacker and defender stats define the overall unit count per team. For singleplayer missions
>> you could even have hundreds of units on the field.
>> The bleed thresholds are based on the sum of the command post values owned by each team. If
>> the bleed threshold is breached, the team begins to bleed reinforcements at the rate in seconds
>> specified. Also in this section are declarations for who is freindly and who is foe. In this
>> case the Republic is the attacker so the locals (team 3) are being declared as the enemy. The
>> locals in this case the Geonosians. AI will not attack friends and will attack enemies as long
>> the relationship is declared.


    ReadDataFile("GEO\\geo1.lvl")

    SetDenseEnvironment("false")
    SetMinFlyHeight(-65)
    SetMaxFlyHeight(50)
    SetMaxPlayerFlyHeight(50)


>> ReadDataFile here is calling the world.lvl and it's assets here.
>> SetDenseEnvironment affects AI behavior so they are tuned for urban
>> or open combat. SetMinFlyHeight declarations are in meters and you should always
>> make sure your values meet your terrain heights.


--  Birdies
    --SetNumBirdTypes(1)
    --SetBirdType(0.0,10.0,"dragon")
    --SetBirdFlockMinHeight(90.0)

>> If birds are on a level this is where they would be set up.
>> Look at the assets for Kashyyyk as an example of how to implement birds, which req files
>> to include th references in, where to store the assets and configure their properties.


--  Sound
    OpenAudioStream("sound\\geo.lvl",  "geocw_music");
    OpenAudioStream("sound\\cw.lvl",  "cw_vo");
    OpenAudioStream("sound\\cw.lvl",  "cw_tac_vo");
    OpenAudioStream("sound\\geo.lvl",  "geo1cw");
    OpenAudioStream("sound\\geo.lvl",  "geo1cw");

>> These lines open audio streams in the sound levels loaded previously. In the above case
>> the music is opened first. then the voiceovers, then the tactical voiceovers which are in a
>> separate stream so there is less lag in hearing the VO when many sounds are being triggered,
>> then two streams are opened for ambient environment streams because in geo there are two and in
>> an case where you have more than one ambient environment stream two streams need to be opened
>> so both can be heard at the same time if the player ever encounters them at the same time.


    SetBleedingVoiceOver(REP, REP, "rep_off_com_report_us_overwhelmed", 1)
    SetBleedingVoiceOver(REP, CIS, "rep_off_com_report_enemy_losing",   1)
    SetBleedingVoiceOver(CIS, REP, "cis_off_com_report_enemy_losing",   1)
    SetBleedingVoiceOver(CIS, CIS, "cis_off_com_report_us_overwhelmed", 1)

>> These lines set the voiceover calls for each team and circumstance. In the first line
>> the REP is saying the REP are losing reinforcements, as denoted by REP, REP. The
>> "rep_off_com_report_us_overwhelmed" calls a soundstreamproperty in a config file (cw_vo.snd)
>> which plays a sound included in cw_vo.sfx. In the case of addons, all new files are added using
>> .asfx files rather than ,sfx files. See the TAT3 assets as a the best reference for mods.

    SetOutOfBoundsVoiceOver(1, "repleaving");
    SetOutOfBoundsVoiceOver(2, "cisleaving");

>> These lines call the sound property for when a unit crosses the boundary and hence leaves the
>> battlefield. The numbers represent team number.

    SetAmbientMusic(REP, 1.0, "rep_GEO_amb_start",  0,1)
    SetAmbientMusic(REP, 0.99, "rep_GEO_amb_middle", 1,1)
    SetAmbientMusic(REP, 0.1,"rep_GEO_amb_end",    2,1)
    SetAmbientMusic(CIS, 1.0, "cis_GEO_amb_start",  0,1)
    SetAmbientMusic(CIS, 0.99, "cis_GEO_amb_middle", 1,1)
    SetAmbientMusic(CIS, 0.1,"cis_GEO_amb_end",    2,1)

>> These lines set the repeating music that is played throughout the game and the trigger
>> for when the different subset of tracks is called. First the team that hears is declared,
>> then the reinforcement count as a percent. So above the first lines plays start music
>> according to the interval defined in the soundstreamproperty in geocw_music.snd The music will
>> repeat until the next threshold is breached, in this case the middle music begins at 99%
>> reinforcements. The next argument sets to 1 to assign a started bleeding sound set
>> to 0 to assign a stopped bleeding sound. The final argument flags the declaration to look
>> for the first argument as a percentage, if set to zero it will look for an explicit count.


    SetVictoryMusic(REP, "rep_geo_amb_victory")
    SetDefeatMusic (REP, "rep_geo_amb_defeat")
    SetVictoryMusic(CIS, "cis_geo_amb_victory")
    SetDefeatMusic (CIS, "cis_geo_amb_defeat")

>> These lines set the victory and defeat music for each team

    SetSoundEffect("ScopeDisplayZoomIn",  "binocularzoomin");
    SetSoundEffect("ScopeDisplayZoomOut", "binocularzoomout");
    --SetSoundEffect("WeaponUnableSelect",  "com_weap_inf_weaponchange_null");
    --SetSoundEffect("WeaponModeUnableSelect",  "com_weap_inf_modechange_null");
    SetSoundEffect("SpawnDisplayUnitChange",       "shell_select_unit");
    SetSoundEffect("SpawnDisplayUnitAccept",       "shell_menu_enter");
    SetSoundEffect("SpawnDisplaySpawnPointChange", "shell_select_change");
    SetSoundEffect("SpawnDisplaySpawnPointAccept", "shell_menu_enter");
    SetSoundEffect("SpawnDisplayBack",             "shell_menu_exit");

>> These lines call global sound properties for zooming and shell sounds


    SetPlanetaryBonusVoiceOver(CIS, CIS, 0, "CIS_bonus_CIS_medical");
    SetPlanetaryBonusVoiceOver(CIS, REP, 0, "CIS_bonus_REP_medical");
    SetPlanetaryBonusVoiceOver(CIS, CIS, 1, "");
    SetPlanetaryBonusVoiceOver(CIS, REP, 1, "");
    SetPlanetaryBonusVoiceOver(CIS, CIS, 2, "CIS_bonus_CIS_sensors");
    SetPlanetaryBonusVoiceOver(CIS, REP, 2, "CIS_bonus_REP_sensors");
    SetPlanetaryBonusVoiceOver(CIS, CIS, 3, "CIS_bonus_CIS_hero");
    SetPlanetaryBonusVoiceOver(CIS, REP, 3, "CIS_bonus_REP_hero");
    SetPlanetaryBonusVoiceOver(CIS, CIS, 4, "CIS_bonus_CIS_reserves");
    SetPlanetaryBonusVoiceOver(CIS, REP, 4, "CIS_bonus_REP_reserves");
    SetPlanetaryBonusVoiceOver(CIS, CIS, 5, "CIS_bonus_CIS_sabotage");--sabotage
    SetPlanetaryBonusVoiceOver(CIS, REP, 5, "CIS_bonus_REP_sabotage");
    SetPlanetaryBonusVoiceOver(CIS, CIS, 6, "");
    SetPlanetaryBonusVoiceOver(CIS, REP, 6, "");
    SetPlanetaryBonusVoiceOver(CIS, CIS, 7, "CIS_bonus_CIS_training");--advanced training
    SetPlanetaryBonusVoiceOver(CIS, REP, 7, "CIS_bonus_REP_training");--advanced training

    SetPlanetaryBonusVoiceOver(REP, REP, 0, "REP_bonus_REP_medical");
    SetPlanetaryBonusVoiceOver(REP, CIS, 0, "REP_bonus_CIS_medical");
    SetPlanetaryBonusVoiceOver(REP, REP, 1, "");
    SetPlanetaryBonusVoiceOver(REP, CIS, 1, "");
    SetPlanetaryBonusVoiceOver(REP, REP, 2, "REP_bonus_REP_sensors");
    SetPlanetaryBonusVoiceOver(REP, CIS, 2, "REP_bonus_CIS_sensors");
    SetPlanetaryBonusVoiceOver(REP, REP, 3, "REP_bonus_REP_hero");
    SetPlanetaryBonusVoiceOver(REP, CIS, 3, "REP_bonus_CIS_hero");
    SetPlanetaryBonusVoiceOver(REP, REP, 4, "REP_bonus_REP_reserves");
    SetPlanetaryBonusVoiceOver(REP, CIS, 4, "REP_bonus_CIS_reserves");
    SetPlanetaryBonusVoiceOver(REP, REP, 5, "REP_bonus_REP_sabotage");--sabotage
    SetPlanetaryBonusVoiceOver(REP, CIS, 5, "REP_bonus_CIS_sabotage");
    SetPlanetaryBonusVoiceOver(REP, REP, 6, "");
    SetPlanetaryBonusVoiceOver(REP, CIS, 6, "");
    SetPlanetaryBonusVoiceOver(REP, REP, 7, "REP_bonus_REP_training");--advanced training
    SetPlanetaryBonusVoiceOver(REP, CIS, 7, "REP_bonus_CIS_training");--advanced training

>> The above lines set the calls to the voiceovers for the planetary bonuses in
>> Galactic Conquest. They are triggered when the bonus is activated in game or if
>> forced by using the comment lines below. The arguments above are as follows:
>> SetPlanetaryBonusVoiceOver(playerTeam,bonusNum,streamSoundName);

    --ActivateBonus(CIS, "SNEAK_ATTACK")
    --ActivateBonus(REP, "SNEAK_ATTACK")

    SetAttackingTeam(ATT)

--Opening Satalite Shot
--Geo
--Mountain
AddCameraShot(0.996091, 0.085528, -0.022005, 0.001889, -6.942698, -59.197201, 26.136919);
--Wrecked Ship
AddCameraShot(0.906778, 0.081875, -0.411906, 0.037192, 26.373968, -59.937874, 122.553581);
--War Room
AddCameraShot(0.994219, 0.074374, 0.077228, -0.005777, 90.939568, -49.293945, -69.571136);
end

>> The above lines were explained previously with mod1a.

The game assets were provided with the tools for the creation of new maps with the exception of sounds for size as well as licensing reasons. These levels will not run as is using the add on functionality but you may look at them as examples for reference. This will be especially useful when it comes to mission luas.
Quote from: Abraham Lincoln. on November 04, 1971, 12:34:40 PM
Don't believe everything you read on the internet

June 11, 2012, 05:16:56 AM #7 Last Edit: June 19, 2012, 08:42:41 PM by SleepKiller
MOD1 TUTORIAL
PLEASE NOTE: MOD1 was created manually. Worlds can now be created in seconds using BFBuilder.hta.

MOD1 SAMPLE MAP
Mod1 was the first map created as a sample that utilizes the minimum assets required for a functional world. The Mod1 sample map was created by first building the DATATEMPLATE directory and file structure so modders had a template that could be modified to accommodate new worlds. For other mods, the DATATEMPLATE directory can be copied and renamed to match the world name. For example DATATEMPLATE could be renamed to DATADan1 for Dantooine, or in the case of the Mod1 sample DATAMod1 for Modification1. Once the template has been copied and the folder renamed, individual files required to compile the level need to be changed to reflect the new level name and folder names.

Below is a list of the files and folders to be changed. Those prefaced with a (+) are mandatory, the rest are optional.


\BFBuilder\DataTEMPLATE\ - copy and rename folder
\BFBuilder\Data%COPY%\soundmunge.bat - edit mod references if necessary
\BFBuilder\Data%COPY%\_BUILD_PC\clean.bat - edit mod reference if necessary
+\BFBuilder\Data%COPY%\_BUILD_PC\munge.bat - edit mod and mod1 references (mod1 defines addon folder name)
\BFBuilder\Data%COPY%\_BUILD_PC\sound\clean.bat - edit mod reference if necessary
\BFBuilder\Data%COPY%\_BUILD_PC\Worlds\clean.bat - edit mod reference if necessary
\BFBuilder\Data%COPY%\_BUILD_PC\Worlds\MOD\ - rename folder if necessary
+\BFBuilder\Data%COPY%\_BUILD_PC\uninstall_from_pc.bat - edit mod1 references (mod1 defines addon folder name)
\BFBuilder\Data%COPY%\_BUILD_PC\Worlds\MOD\ - rename folder if necessary
\BFBuilder\Data%COPY%\_BUILD_PC\Worlds\MOD\munge.bat - edit Modification and mod references if necessary
\BFBuilder\Data%COPY%\_LVL_PC\MOD\ - rename folder if necessary
\BFBuilder\Data%COPY%\_LVL_PC\Movies\mod1.mvs - replace file and rename if necessary
+\BFBuilder\Data%COPY%\_SOURCE_PC\Shell\Movies\mod1.mlst rename file (must) and edit mod1 ref if necessary
+\BFBuilder\Data%COPY%\addme\addme.lua - edit mod1 references and map name for maplist
+\BFBuilder\Data%COPY%\Common\mission.req - edit mod1 references
+\BFBuilder\Data%COPY%\Common\Mission\mod1a.req - rename file and edit mod1 references
+\BFBuilder\Data%COPY%\Common\Mission\mod1c.req - rename file and edit mod1 references
\BFBuilder\Data%COPY%\Common\Scripts\MOD\ - rename folder if necessary
+\BFBuilder\Data%COPY%\Common\Scripts\MOD\mod1a.lua - rename file, edit mod1 references
+\BFBuilder\Data%COPY%\Common\Scripts\MOD\mod1c.lua - rename file, edit mod1 references
+\BFBuilder\Data%COPY%\Shell\Movies\mod1.mcfg - rename file (must) and edit mod1 references if necessary
\BFBuilder\Data%COPY%\Sound\worlds\mod\mod.req - rename folder and file if necessary
+\BFBuilder\Data%COPY%\Sound\worlds\mod\mod1.asfx - rename file
+\BFBuilder\Data%COPY%\Sound\worlds\mod\mod1cw.req - rename file
+\BFBuilder\Data%COPY%\Sound\worlds\mod\mod1gcw.req - rename file
\BFBuilder\Data%COPY%\Worlds\Modification\ - rename folder
+\BFBuilder\Data%COPY%\Worlds\Modification\mod1.req - rename file and edit mod1 references

When all of the changes have been made a new world can be saved within the folder Data%COPY%/Worlds/Modification/World1, where TEMPLATE and Modification are reflective of the new world name such as DataDAN1/Worlds/Dantooine/World1. To save a new world into this folder, an existing world can be opened and saved under a new name or a new world can be created and saved without first opening an existing world. When creating the DATAMOD1 sample Mod1, the world was created from scratch.

LAUNCHING ZERO EDIT
To create a world without first opening an existing world, run the copy of Zeroeditor.exe that resides in the Data%COPY% directory where the new world is to reside. At runtime Zeroeditor creates an index of all files that reside beneath it's current directory and uses that index when opening or using files. As a result, editor launch times can be slow when the editor has to index multiple world assets so each Data directory (including DATATEMPLATE) has it's own copy of the editor that is duplicated with the template.

CREATING A WORLD FROM SCRATCH
Once Zeroedit has been launched, select TERRAIN from the ADVANCED menu in the top right corner of the editor. A window will pop up that will allow the new terrain size to be specified before selecting the CREATE button to actually generate the terrain. Once the terrain has been created, simply save the world to the new directory under DataDan1\Worlds\Dantooine\World1\. All of the files saved by Zeroedit are saved in the World1 folder, and when a world is saved for the first time the world file name must include the .WLD extension, such as Dan1.wld. The length of the world file name is not limited.

WORLD FILE TYPES
When the world is saved many files are saved with names that correspond to those specified in DataDan1\Worlds\Dantooine\Dan1.req. This .REQ file is known as the world req, and among other properties it declares the name of the world file (WLD) and it's associated files such those required for paths (PTH), props (PRP), boundaries (BND), connectivity graph (path plans) (PLN), and environment effects (FX). If the names in the world req do not correspond to the names of the files in the world directory, the level will not compile properly.

SKY TEMPLATE
While the DATATemplate directory does not contain any world or object files, it does contain the textures and meshes that make up the Geonosis sky which is used as a default template for the sky file when a world is created from scratch. For this reason when a world is created using the TERRAIN/CREATE button and subsequently saved, it will automatically save a working sky file. It is also for this reason that when creating a world from scratch Zeroedit should be closed and the world reopened to access the newly saved data.

MINIMUM REQUIREMENTS
After reopening the world file, the minimum requirements for a world to compile and run can be added.
They are:
2 Command Posts, one owned by each team
2 Capture regions, one for each command post
2 Control regions, one for each command post
2 Unit Spawn Paths, one for each command post
1 Properly configured mission lua script for each era (2 luas)


COMMON OBJECTS
All game objects and their properties are defined by an Object Definition File (ODF file). Common objects are located in the DATATEMPLATE/Common/ODF folder for each world. Do not change the contents of this folder. It contains ODFs only so objects that shipped with the game can appear in the editor while editing. After compiling, any common objects contained in a world are pulled from the assets that shipped with the game rather those compiled in a mod.

ADDING OBJECTS
Command posts are common objects located in the DATATEMPLATE/Common/ODF folder. To add a command post to Mod1 Zeroedit was changed to OBJECT EDIT MODE and from the EDIT OBJECT TOOLS the BROWSE button under ODF FILE was selected. This launches a file explorer window to specify the ODF file to import into the world as an object.

COMMAND POSTS
The two most common command post types are Major and Minor Command Posts. Major Command Posts are large and take longer to capture while Minor Command Posts are smaller and take less time to capture. Major Command Posts are defined by the ODF called com_bldg_major_controlzone.odf while Minor Command Posts are defined by the ODF called com_bldg_controlzone.odf. Two minor command posts were added to Mod1.

PLACING OBJECTS
Once an ODF file is selected from the file explorer the EDIT OBJECT ACTION mode must be set to PLACE. After selecting PLACE the object being placed in the world can be seen attached to the end of the mouse cursor. To place the object simply left click on the terrain where it should go.

SELECTING OBJECTS
Once an instance of an object is placed the EDIT OBJECT ACTION mode can be changed to SELECT and the object can be clicked on in the world with the left mouse button to select it. When this is done it's INSTANCE PROPERTIES are exposed for defining in the toolbars on the left and right side of the editor.

OBJECT INSTANCE PROPERTIES
Command Post objects have object instance properties that can be configured for each instance of an object on a level. In the case of command posts required object instance properties are NAME, LABEL, TEAM, CAPTURE REGION, CONTROL REGION, and SPAWN PATH.

NAME is used internally to reference the command post.
LABEL sets a flag that is referenced by the Multi-Language tool used for localization.
TEAM can be either 0, 1, 2, or 3, where 0 is neutral and 3 is a third team if present.
CAPTURE REGION is the name of the Capture Region attached to the command post.
CONTROL REGION is the name of the Control Region attached to the command post.
SPAWN PATH is the name of the unit spawn path attached to the command post.


NAMING CONVENTIONS
For ease of use command posts are typically name by number such as CP1, CP2, etc. This name and number is then used as the prefix to reference all of the instance properties. Label becomes CP1Label, CaptureRegion is CP1Capture, ControlRegion is CP1Control, and SpawnPath is CP1Spawn.

TEAM
Since each map must have at least one command post owned by each playable team CP1 is typically assigned to Team 1, which is always the attacker as defined by the mission lua script. In the case of Mod1, the attackers are the Alliance and the CIS.

SELECT AND ADD
After placing and filling in the input fields defining an object's instance properties, the EDIT OBJECT ACTION mode can be changed back to PLACE into order to place additional instances of the same object. Just as before the object to be placed appears at the tip of the mouse cursor until the terrain is selected with the left mouse button. When an additional instance of an object is placed and the new instance selected, the NAME, LABEL, and TEAM definitions are carried over from the previous instance. The number at the end of the name field is incremented 1 for each new instance because each command post must have a unique name, and it's one less field that needs to be changed when defining the new instance properties. Two minor command posts were added to Mod1 and their instance properties filled out according to the naming convention described above. The second command post was assigned to team 2.

COMMAND POST REGIONS
Once command posts have been setup they must be attached to CAPTURE and CONTROL REGIONs. A CAPTURE REGION is a zone that when entered by an enemy unit triggers the capture of a command post. A CONTROL REGION is a zone attached to a command post that defines the area under influence of a command post. Typically this is only used to define an area where VEHICLE SPAWNs are placed in order to protect the vehicles from degradation while they are within the control region. Capture and Control regions attached to a command post are typically located on top of or very near to the command post, but they can be located anywhere on the map.

ADDING REGIONS
Regions are added to a world by changing Zeroedit to REGIONS EDIT mode and selecting NEW GROUP. Once NEW GROUP is selected the region to be placed will appear as a wireframe box at the end of the mouse cursor to be placed like an object. To change the shape of the region, a different shape can be selected from the EDIT REGIONS SHAPE toolbar. Capture and control regions can be any shape.

SPHERE was selected as the shape for CP1's capture region and it was placed on top of the command post. After placing the first region the EDIT REGIONS ACTION mode was changed to SELECT and the region selected for editing. The region was resized and it's position adjusted using the left mouse button and the Z and C keys. Upon selection the region's ID and properties are exposed at the top of the screen for defining. For Mod1 the RegionID for CP1's capture region was labelled CP1Sphere to indicate it's shape. The RegionID is arbitrary and is used to track individual regions in the editor and nothing more. What is more important is the region's properties, which is the field that specifies the name referenced by a command post. In the case of Mod1 CP1's capture region properties were defined as CP1Capture, which was the name defined in the command post instance properties under CaptureRegion. This was repeated for CP2's capture region, following the same naming convention as referenced by CP2's instance properties.

BOX was chosen as the shape for a new group to define as the ControlRegion for each command post. The same process that was followed for defining the capture regions is used to define the properties for the control regions. Normally control regions need to be adjusted and scaled to envelope VEHICLE SPAWNs under their influence, but in the case of Mod1 there are no vehicles so the regions were not adjusted and the control regions are only present as a requirement of the command posts.

UNIT SPAWN PATHS
With regions attached to command posts all that is required in the world for it to be functional are SPAWN PATHS that allow playable units to enter the game. SPAWN PATHS are added using PATH EDIT mode. In PATH EDIT mode a new path is created by first selecting NEW PATH from the SPAWN PATH ACTION mode menu. In NEW PATH mode when the terrain is clicked on with the left mouse button a SPAWN NODE will be placed. Each time the terrain is clicked another node will be added to the path, each representing a point where a unit spawns. After clicking the terrain in an arc around a CP, the terrain was clicked with the right mouse button to deselect the path and change the SPAWN PATH ACTION mode to MOVE. The path was then adjusted by right clicking on it while holding the button down until it was positioned properly.

The PATH NAME field is selected once a path has been placed in order to name it. In the case of Mod1 the name specified in the command post instance properties was used as the PATH NAME, following the naming convention established. CP1Spawn was defined and the process repeated for CP2Spawn which was placed around CP2. Having defined the spawn paths, all that is left to make the world functional is setting up the mission lua scripts and making sure all of the appropriate files and folders have been edited in order for the level to compile. At this point the level can be saved and Zeroeditor closed because the remainder of the work takes place using a text editor.

MISSION LUAS
Mission LUA scripts define all the of the global properties for a level and are required for each mission. Typically there are two missions per map, 1 Clone Wars Era mission and one Galactic Civil War Era mission. These mission lua scripts are named using the three letter and number level naming convention with a letter added to the end to denote the attacking team. In the case of Mod1, the lua scripts are named Mod1a.lua and Mod1c.lua. They could just as easily be Mod1i and Mod1r as long as the contents of each file define the attacker correctly.

Below is a line by line breakdown of Mod1a.lua with a brief explanation of what each section does. Comments about each line are prefaced with >>


mod1a.lua Start
>>
>> Note about Mission lua naming conventions:
>> The mission luas must always following the three-letter, 1 number, 1 letter naming convention.
>> COmments always appear prefaced by --

---------------------------------------------------------------------------
-- FUNCTION:    ScriptInit
-- PURPOSE:     This function is only run once
-- INPUT:
-- OUTPUT:
-- NOTES:       The name, 'ScriptInit' is a chosen convention, and each
--              mission script must contain a version of this function, as
--              it is called from C to start the mission.
---------------------------------------------------------------------------

function ScriptInit()
--  Empire Attacking (attacker is always #1)
    local ALL = 1
    local IMP = 2
--  These variables do not change
    local ATT = 1
    local DEF = 2
>>
>> The above section defines the two teams and which is declared as the attacker.
>> The attacker on a map is always team 1, and the name of the mission lua script reflects the attacker.
>>

(mod1a means that Alliance is the attacker).
    AddMissionObjective(IMP, "red", "level.mod1.objectives.1");
    AddMissionObjective(IMP, "orange", "level.mod1.objectives.2");
    AddMissionObjective(IMP, "orange", "level.mod1.objectives.3");
    AddMissionObjective(ALL, "red", "level.mod1.objectives.1");
    AddMissionObjective(ALL, "orange", "level.mod1.objectives.2");
    AddMissionObjective(ALL, "orange", "level.mod1.objectives.3");

>>
>> The above section defines the localization strings for mission objectives.
>> These are localization strings that are stored in the localization file which references
>> the actual text that appears in the game. See the localization guide for more details.
>>

    ReadDataFile("sound\\tat.lvl;tat1gcw")
    ReadDataFile("SIDE\\all.lvl",
        "all_inf_basicdesert",
    "all_inf_lukeskywalker",
        "all_inf_smuggler");

    ReadDataFile("SIDE\\imp.lvl",
        "imp_inf_basic_tie",
    "imp_inf_darthvader",
        "imp_inf_dark_trooper");

   -- ReadDataFile("dc:SIDE\\gam.lvl",
   --     "gam_inf_gamorreanguard")


>>
>> All ReadDataFile lines reference LVL files that contain assets that need to be loaded and
>> the specific assets to be loaded by the level.
>>

    SetAttackingTeam(ATT);

>>
>> The SetAttacking Team line denotes which team is the attacker and which is the defender
>>

--      Alliance Stats
    SetTeamName(ALL, "Alliance")
    SetTeamIcon(ALL, "all_icon")
    AddUnitClass(ALL, "all_inf_soldierdesert",10)
    AddUnitClass(ALL, "all_inf_vanguard",1)
    AddUnitClass(ALL, "all_inf_pilot",2)
    AddUnitClass(ALL, "all_inf_marksman",2)
    AddUnitClass(ALL, "all_inf_smuggler",1)
    SetHeroClass(ALL, "all_inf_lukeskywalker")

--      Imperial Stats
    SetTeamName(IMP, "Empire")
    SetTeamIcon(IMP, "imp_icon")
    AddUnitClass(IMP, "imp_inf_storm_trooper",10)
    AddUnitClass(IMP, "imp_inf_shock_trooper",1)
    AddUnitClass(IMP, "imp_inf_pilottie",2)
    AddUnitClass(IMP, "imp_inf_scout_trooper",2)
    AddUnitClass(IMP, "imp_inf_dark_trooper",1)
    SetHeroClass(IMP, "imp_inf_darthvader")


>>
>> The attacker and defender stats define the team names, team icon, unit hero classes and their loadouts.
>>

--  Attacker Stats
    SetUnitCount(ATT, 16)
    SetReinforcementCount(ATT, 200)
--    AddBleedThreshold(ATT, 31, 0.0)
--    AddBleedThreshold(ATT, 21, 0.75)
    AddBleedThreshold(ATT, 11, 0.75)
    AddBleedThreshold(ATT, 10, 1.5)
    AddBleedThreshold(ATT, 1, 3.0)

--  Defender Stats
    SetUnitCount(DEF, 16)
    SetReinforcementCount(DEF, 200)
--    AddBleedThreshold(DEF, 31, 0.0)
--    AddBleedThreshold(DEF, 21, 0.75)
    AddBleedThreshold(DEF, 11, 0.75)
    AddBleedThreshold(DEF, 10, 1.5)
    AddBleedThreshold(DEF, 1, 3.0)

>>
>> The attacker and defender stats set the team total units counts, the bleed thresholds and their triggers
>>


--  Local Stats
--   SetTeamName(3, "locals")
--   AddUnitClass(3, "gam_inf_gamorreanguard",3)
--   SetUnitCount(3, 3)
--   SetTeamAsEnemy(3, ATT)
--   SetTeamAsEnemy(3, DEF)

>>
>> Local stats sets up the 3 team on maps where there is an NPC team.
>>

--  Level Stats
    ClearWalkers()
    AddWalkerType(0, 0)
   -- AddWalkerType(1, 4)
    AddWalkerType(2, 0)
    --SetMemoryPoolSize("EntityHover", 12)
    --SetMemoryPoolSize("EntityFlyer", 5)
--  SetMemoryPoolSize("EntityBuildingArmedDynamic", 16)
--  SetMemoryPoolSize("EntityTauntaun", 0)
--  SetMemoryPoolSize("MountedTurret", 22)
    SetMemoryPoolSize("PowerupItem", 60)
--    SetMemoryPoolSize("SoundSpaceRegion", 85)
    SetMemoryPoolSize("EntityMine", 40)
    --SetMemoryPoolSize("Aimer", 200)
--    SetMemoryPoolSize("Obstacle", 725)
    --SetMemoryPoolSize("EntityLight", 150)
    SetSpawnDelay(10.0, 0.25)
    ReadDataFile("dc:MOD\\mod1.lvl")
    SetDenseEnvironment("false")
    --AddDeathRegion("Sarlac01")
  --  SetMaxFlyHeight(90)
  --  SetMaxPlayerFlyHeight(90)

>>
>> Level stats declare various memory pools settings that need to be adjusted on
>> an as needed basis as indicated by debug errors.
>> Walker type memory allocations are declared in this section as well.
>> The level world lvl to be loaded for a world is declared in this section as well
>> as level-specific properties that need declaring such as the addition of a death
>> region and the type of combat environment.
>>



--  Sound Stats
    OpenAudioStream("sound\\tat.lvl",  "tatgcw_music");
   -- OpenAudioStream("dc:sound\\mod.lvl",  "mod1");
   -- OpenAudioStream("dc:sound\\mod.lvl",  "mod1");
    OpenAudioStream("sound\\gcw.lvl",  "gcw_vo");
    OpenAudioStream("sound\\gcw.lvl",  "gcw_tac_vo");
   --  OpenAudioStream("dc:sound\\mod.lvl",  "mod1_emt");
   --OpenAudioStream("dc:sound\\tat.lvl",  "tat3_emt");

    SetBleedingVoiceOver(ALL, ALL, "all_off_com_report_us_overwhelmed", 1);
    SetBleedingVoiceOver(ALL, IMP, "all_off_com_report_enemy_losing",   1);
    SetBleedingVoiceOver(IMP, ALL, "imp_off_com_report_enemy_losing",   1);
    SetBleedingVoiceOver(IMP, IMP, "imp_off_com_report_us_overwhelmed", 1);

    SetLowReinforcementsVoiceOver(ALL, ALL, "all_off_defeat_im", .1, 1);
    SetLowReinforcementsVoiceOver(ALL, IMP, "all_off_victory_im", .1, 1);
    SetLowReinforcementsVoiceOver(IMP, IMP, "imp_off_defeat_im", .1, 1);
    SetLowReinforcementsVoiceOver(IMP, ALL, "imp_off_victory_im", .1, 1);

    SetOutOfBoundsVoiceOver(2, "Allleaving");
    SetOutOfBoundsVoiceOver(1, "Impleaving");

    SetAmbientMusic(ALL, 1.0, "all_tat_amb_start",  0,1);
    SetAmbientMusic(ALL, 0.99, "all_tat_amb_middle", 1,1);
    SetAmbientMusic(ALL, 0.1,"all_tat_amb_end",    2,1);
    SetAmbientMusic(IMP, 1.0, "imp_tat_amb_start",  0,1);
    SetAmbientMusic(IMP, 0.99, "imp_tat_amb_middle", 1,1);
    SetAmbientMusic(IMP, 0.1,"imp_tat_amb_end",    2,1);

    SetVictoryMusic(ALL, "all_tat_amb_victory");
    SetDefeatMusic (ALL, "all_tat_amb_defeat");
    SetVictoryMusic(IMP, "imp_tat_amb_victory");
    SetDefeatMusic (IMP, "imp_tat_amb_defeat");



    SetSoundEffect("ScopeDisplayZoomIn",  "binocularzoomin");
    SetSoundEffect("ScopeDisplayZoomOut", "binocularzoomout");
    --SetSoundEffect("WeaponUnableSelect",  "com_weap_inf_weaponchange_null");
    --SetSoundEffect("WeaponModeUnableSelect",  "com_weap_inf_modechange_null");
    SetSoundEffect("SpawnDisplayUnitChange",       "shell_select_unit");
    SetSoundEffect("SpawnDisplayUnitAccept",       "shell_menu_enter");
    SetSoundEffect("SpawnDisplaySpawnPointChange", "shell_select_change");
    SetSoundEffect("SpawnDisplaySpawnPointAccept", "shell_menu_enter");
    SetSoundEffect("SpawnDisplayBack",             "shell_menu_exit");

    --SetPlanetaryBonusVoiceOver(IMP, IMP, 0, "imp_bonus_imp_medical");
    --SetPlanetaryBonusVoiceOver(IMP, ALL, 0, "imp_bonus_all_medical");
    --SetPlanetaryBonusVoiceOver(IMP, IMP, 1, "");
    --SetPlanetaryBonusVoiceOver(IMP, ALL, 1, "");
    --SetPlanetaryBonusVoiceOver(IMP, IMP, 2, "imp_bonus_imp_sensors");
    --SetPlanetaryBonusVoiceOver(IMP, ALL, 2, "imp_bonus_all_sensors");
    SetPlanetaryBonusVoiceOver(IMP, IMP, 3, "imp_bonus_imp_hero");
    SetPlanetaryBonusVoiceOver(IMP, ALL, 3, "imp_bonus_all_hero");
    --SetPlanetaryBonusVoiceOver(IMP, IMP, 4, "imp_bonus_imp_reserves");
    --SetPlanetaryBonusVoiceOver(IMP, ALL, 4, "imp_bonus_all_reserves");
    --SetPlanetaryBonusVoiceOver(IMP, IMP, 5, "imp_bonus_imp_sabotage");--sabotage
    --SetPlanetaryBonusVoiceOver(IMP, ALL, 5, "imp_bonus_all_sabotage");
    --SetPlanetaryBonusVoiceOver(IMP, IMP, 6, "");
    --SetPlanetaryBonusVoiceOver(IMP, ALL, 6, "");
    --SetPlanetaryBonusVoiceOver(IMP, IMP, 7, "imp_bonus_imp_training");--advanced training
    --SetPlanetaryBonusVoiceOver(IMP, ALL, 7, "imp_bonus_all_training");--advanced training

    --SetPlanetaryBonusVoiceOver(ALL, ALL, 0, "all_bonus_all_medical");
    --SetPlanetaryBonusVoiceOver(ALL, IMP, 0, "all_bonus_imp_medical");
    --SetPlanetaryBonusVoiceOver(ALL, ALL, 1, "");
    --SetPlanetaryBonusVoiceOver(ALL, IMP, 1, "");
    --SetPlanetaryBonusVoiceOver(ALL, ALL, 2, "all_bonus_all_sensors");
    --SetPlanetaryBonusVoiceOver(ALL, IMP, 2, "all_bonus_imp_sensors");
    SetPlanetaryBonusVoiceOver(ALL, ALL, 3, "all_bonus_all_hero");
    SetPlanetaryBonusVoiceOver(ALL, IMP, 3, "all_bonus_imp_hero");
    --SetPlanetaryBonusVoiceOver(ALL, ALL, 4, "all_bonus_all_reserves");
    --SetPlanetaryBonusVoiceOver(ALL, IMP, 4, "all_bonus_imp_reserves");
    --SetPlanetaryBonusVoiceOver(ALL, ALL, 5, "all_bonus_all_sabotage");--sabotage
    --SetPlanetaryBonusVoiceOver(ALL, IMP, 5, "all_bonus_imp_sabotage");
    --SetPlanetaryBonusVoiceOver(ALL, ALL, 6, "");
    --SetPlanetaryBonusVoiceOver(ALL, IMP, 6, "");
    --SetPlanetaryBonusVoiceOver(ALL, ALL, 7, "all_bonus_all_training");--advanced training
    --SetPlanetaryBonusVoiceOver(ALL, IMP, 7, "all_bonus_imp_training");--advanced training

>>
>> Sound stats declares all of the sound assets loaded for a level as well as mission-specific
>> sound properties.
>>



--  Camera Stats
--Tat 3 - Jabbas' Palace
    AddCameraShot(0.685601, -0.253606, -0.639994, -0.236735, -65.939224, -0.176558, 127.400444);
    AddCameraShot(0.786944, 0.050288, -0.613719, 0.039218, -80.626396, 1.175180, 133.205551);
    AddCameraShot(0.997982, 0.061865, -0.014249, 0.000883, -65.227898, 1.322798, 123.976990);
    AddCameraShot(-0.367869, -0.027819, -0.926815, 0.070087, -19.548307, -5.736280, 163.360519);
    AddCameraShot(0.773980, -0.100127, -0.620077, -0.080217, -61.123989, -0.629283, 176.066025);
    AddCameraShot(0.978189, 0.012077, 0.207350, -0.002560, -88.388947, 5.674968, 153.745255);
    AddCameraShot(-0.144606, -0.010301, -0.986935, 0.070304, -106.872772, 2.066469, 102.783096);
    AddCameraShot(0.926756, -0.228578, -0.289446, -0.071390, -60.819584, -2.117482, 96.400620);
    AddCameraShot(0.873080, 0.134285, 0.463274, -0.071254, -52.071609, -8.430746, 67.122437);
    AddCameraShot(0.773398, -0.022789, -0.633236, -0.018659, -32.738083, -7.379394, 81.508003);
    AddCameraShot(0.090190, 0.005601, -0.993994, 0.061733, -15.379695, -9.939115, 72.110054);
    AddCameraShot(0.971737, -0.118739, -0.202524, -0.024747, -16.591295, -1.371236, 147.933029);
    AddCameraShot(0.894918, 0.098682, -0.432560, 0.047698, -20.577391, -10.683214, 128.752563);

>>
>> The Camera stats section defines the coordinate for the screenshots that appear in the game using
>> in game coordinates.
>>


end

>>
>> The end of the lua function
>>

Each line and more details about what can and can not be done in a mod can be found in the LUA GUIDE. In that guide mission luas for each era are gone over in detail. Other examples that can be used for reference are in the assets folder.


Munge and Compile
All of the assets and the text files defining how they are used are compiled in a two step process that is collectively called a MUNGE. When a mod is munged numerous batch files are executed in order and compile the assets into the _BUILD_PC folder. The _BUILD_PC folder does not contain the final compiled binaries, but rather pre-compiled assets that are not the raw assets. These precompiled raw assets are needed to build one another, so when all of the pre-compiled assets have been created they are finally compiled into the LVL files that are used by the game. The _LVL_PC directory structure is where the final data is stored to be used by the game as an Add On.

To compile a world, simply run MUNGE.BAT located in the _Build_PC folder for the add on. When the munge is complete, the compiled files will be copied to BFBuilder/Addon/Mod# where mod# is the name specified for the new world. This mod# folder can then be copied to the LucasArts\Star Wars Battlefront\GameData\AddOn and when the game is run the new level will appear on the mission list.

Before every munge it is a good idea to "do a clean" by running CLEAN.BAT. This will delete all of the munged files in _Build_PC and _LVL_PC to ensure they are rebuilt.

Testing With SPTEST.EXE
SPTEXT.EXE can be copied to the same directory that the game executable is located (LucasArts\Star Wars Battlefront\GameData) and run instead of the default game executable. When SPTEST.EXE is run, the game runs in a window with console always open that displays any errors or asserts with the level. If the game does not run a build log is saved in the same directory as SPTEST.EXE so the problem can be fixed. This in combination with the munge log provides debug information needed to get a level up and running error free.
Quote from: Abraham Lincoln. on November 04, 1971, 12:34:40 PM
Don't believe everything you read on the internet

June 11, 2012, 05:17:15 AM #8 Last Edit: June 19, 2012, 08:44:03 PM by SleepKiller
EDITING NEW WORLDS WITH ZEROEDITOR
After following the Quick Start instructions to create a world the new project is opened in BFBuilder automatically. Projects can also be opened from the PROJECT menu. The world created as part of the project can then be opened in the world editor -- Zeroeditor -- by clicking on the Edit <ModID> button.

Viewing in Zeroeditor
When the editor launched it is displayed at a resolution of 1024 x 768 by default. These settings can be changed to a higher resultion by editing the config.ini file located in the Data<ModID> folder for each world created, and/or by editing the master file located in DataTemplate.

A license agreement awaits agreement and there is what appears to be a white background. This is actually a terrain-level view of the world, and the white color is the color used to represent a lack of texture on the terrain. When opened the world is displayed in the editor with the terrain in solid mode. This means the textures on the terrain are visible, but the world was just created with the BFBuilder tool which creates an unpainted terrain that appears as white.

To gain a better view, add a wireframe to the display by toggling the WIRE button under TERRAIN VIEW. This changes the display to show both textures and a wireframe. To display just a wireframe untoggle the SOLID button under TERRAIN VIEW.

Not much more than a line or two will be visible until the camera is moved around.

Hitting the TAB key will unlock the mouselook and allow you to change the position of the camera using:
W and S to zoom in and out;
A and D to pan left and right;
F and V to raise and lower the camera.
These keys are mirrored on the numberpad. Pressing the TAB key locks the camera again and changes the mouse to cursor mode. See the Zeroeditor Reference for complete keyboard controls.

Start by raising the camera above the terrain to get a look at the grid. Each square is 8 meters and the entire terrain by default is 256 squares by 256 squares resulting in a playing field 2048 meters by 2048 meters. Not all of this space is usable though, as you near the edge of the map not only will the edge of the world be visible in the game but it objects are too close to the edge the game will not perform properly.

To get a better look at the world, close the Layers window (Layers will be addressed in other sections) and select ADVANCED: CAMERA at the top right of the screen. This activates the advanced camera controls. In this window select the SET TOP DOWN VIEW button for a satellite view of the world. This may zoom out too far to see anything, so close the advanced camera control window and click on the small grey buttons just beneath the ADVANCED control panel under VISIBILITY. These buttons change the visibility range in 500 meter increments. This allows for a better view or better performance in model heavy worlds when navigating in the editor.

By default a world created with BFBuilder has the minimum requirements needed to function. That means there are only two visible objects in the world, and they are the command posts. Command posts are small and difficult to see, but there are a few ways to quickly locate them. One way is to look for the objects associated with them. This means not looking for the command posts, but for the spawn paths and capture regions always found attached to a command post.

Under SHOW select the PATHS and REGIONS buttons. This will make paths and regions visible at all times, no matter what edit mode is active. Paths appear as lines with nodes while regions appear as shaded polygons that either spheres, cylinders, or boxes. By default you'll see two sets of regions as well as two spawn paths on the map.

In addition to locating the objects associated with a command post every object in the game can be selected where it appears on the map or from a list. To select an object switch to OBJECT EDIT mode. At the bottom of the screen a list of objects will appear. If an object can't be found easily in the world it can be selected from the list. It will appear highlighted when selected, at which time pressing the "O" key will center the camera on the object.

Camera positions that are saved with the world can also be recalled using the 0-9 keys. Camera positions are saved using Ctrl-0 thru nine, and recalled by the same numbers without pressing Ctrl.

Once centered on a command post it's positions can be seen as can the spawn path, capture and control regions. Zoom in very close to the command post in order to get a good look at it. If the camera moves too fast use the < and > keys to adjust it's speed. The command post that is highlight will appear in a blue shaded box surrounded by a spawn path littered with spawn nodes within a blue region.

The nodes represent where units spawn with the green line pointing in the direction the units will be facing. By default the capture regions are spheres and the control regions are boxes. Capture regions are regions that if occupied by an enemy unit will trigger the capture of a command post. Control regions are needed for vehicles or objects that are influence by the command post. By default, no vehicles are in the world but the Control regions are added as a requirement of the command post.

With the command post selected in OBJECT EDIT mode, a control panel appears on the right of the screen that contains the object's instance properties. Each command post has unique defined properties, and it it is these properties that declare what spawn paths are associated with the command post as well as what regions and even more critical data such as the value of the command post to each team. While most of the instance properties are located on the right panel, two important properties are located at the bottom left of the screen. The first is Label. Most objects in the game don't need to be declared with a label, but command posts are a special case.

Labels are used as localization keys. Localization is the process of converting the text that appears on screen into multiple languages. For this reason the actual text that appears in game is not put in the label, but a key name is that is then referenced by a localization tool that can then replace that key name with the real label in the right language. In game, when at the unit selection screen there is a map on the right that allows players to select a command post to spawn at. Below that is displayed the localized name linked to a command posts key name. The key names attached to the command posts in the template are CP1Label and CP2Label. These are used by default so it is understood in the localization tool where the references come from.

The other important property located on the bottom left of the screen is TEAM. This number defines which team owns the command post. By default the template defines the Alliance or CIS as team 1. If each team does not own a command post the level will not run.

After looking at or editing the world, it can be saved in the Data<ModId>\Worlds\<ModID\World1 folder. AFter closing the editor the world can be compiled by clicking the Munge <ModID> button. Once compiled a munge log will appear displaying any potential errors. This can be closed as can the command prompt window . These are presented to let the user know when the process is complete. The compiled world is copied automatically to BFBuilder\AddOn and must be manually copied into the Star Wars Battlefront AddOn folder to be played.

If a compiled world does not seem to be reflecting changes made to it, it's a good idea to use the Clean button. A clean is where the compiled but prepackaged assets are deleted for rebuilding on the next munge. Sometimes files are not updated because they are corrupt or their filesizes have not changed. To ensure everything is rebuilt do a clean. As a world becomes more complex the more assets there are to compile and the longer the munge will take. For this reason performing a clean every time may slow down production.

Refer to the Zeroeditor guide for more deatils about how to use the various modes and features of Zeroeditor to manipulate worlds.
Quote from: Abraham Lincoln. on November 04, 1971, 12:34:40 PM
Don't believe everything you read on the internet

Quick Start
Creating and Running a New World in 10 Easy Steps

1. Doubleclick on BFBuilder\BFBuilder.hta to launch the helper application.
2. Select PROJECT -> NEW PROJECT from the toolbar menus
3. Fill in the fields following the instructions
4. Click the CREATE NEW WORLD button and then Yes to create the new directory
5. Wait for the message box that says "Done"
6. Open the folder named Data* that was just created
7. Double Click Munge.bat to compile the world.
8. Open the BFBuilder\AddOn folder to find the compiled mod folder
9. Copy the compiled mod folder to the Gamedata\AddOn folder where the game is installed
10. Run the game and select your mission from the list


Editing the World

1. Run Zeroeditor.exe from the Data* directory created with the world
2. Select LOAD and the Browse to the Data(whatever)\Worlds\(worldname)\World1\ directory
3. Select the (ModID).WLD file and then Open, where ModID is the name of your mod
4. Edit the world, save, munge, copy the mod from the AddOn folder to the GameData\AddOn folder and run.
Quote from: Abraham Lincoln. on November 04, 1971, 12:34:40 PM
Don't believe everything you read on the internet

June 11, 2012, 05:19:17 AM #10 Last Edit: June 19, 2012, 08:45:50 PM by SleepKiller
EDITING THE SKY
The sky is controlled by the ModID.SKY file located in the DataModID\Worlds\ModID\World1 folder for each project. The sky file is a text file that can be edited with a text editor. Objects in the sky are not restricted to any formal outline; an unlimited number of objects can be placed in the sky in a variety of differet ways. What ultimately is important is objects placed in the sky appear in front of objects that are to appear in the background, and the Geonosis sky used as the template sky is a good demonstration of that.
The default sky file contents appear below.


SkyInfo()
{
    ObjectVisibility(40.000000, 80.000000, 1600.000000);
    FogColor(252, 252, 252);
    FogRange(0.000000, 3000.000000);
    NearSceneRange(50.0, 220.0, 60.0, 300.0);
    FarSceneRange(450.000000, 1000.0);
    AmbientColor(120, 101, 76);
    TopDirectionalAmbientColor(120, 101, 76);
    BottomDirectionalAmbientColor(126, 70, 35);
    CharacterAmbientColor(209,156,73);
    VehicleAmbientColor(189, 136, 53);
    Enable(1559);
    FogRamp(3);
}

SunInfo()
{
    Angle(140.000005, -10.000011);
    Color(120, 120, 120);
    Texture("");
    Degree(90.000011);
    BackAngle(180.000022, 0.000000);
    BackColor(128, 128, 128);
    BackDegree(0.000000);
}


DomeInfo()
{
    Texture("SKY_Geonosis.tga");
    Angle(190.000005);
    Ambient(128.000038, 128.000038, 128.000038);
    Filter(1);
    Threshold(150);
    Intensity(50);

    Softness(1);
    SoftnessParam(60);

    PC()
    {
        TerrainBumpTexture("geo1_bump", 1.0);
    }



    DomeModel()
    {
        Geometry("geo_sky_dome");
    }

    DomeModel()
    {
        Geometry("geo_sky_arena");
        Offset(-20.0);
        MovementScale(0.995);
    }
    DomeModel()
    {
        Geometry("geo_sky_spire");
        Offset(-20.0);
        MovementScale(0.995);
    }
    DomeModel()
    {
        Geometry("geo_sky_dome_rim");
        Offset(10.0);
        MovementScale(0.995);
    }

    LowResTerrain()
    {
        Texture("geo1");
        PatchResolution(7);
        FogNear(300.0);
        FogFar(700.0);
        FogColor(142,82,38, 128);
        DetailTexture("geo1_far_detail");
        DetailTextureScale(0.25);
    }
}


//Big rep flyer
SkyObject()
{
    Geometry("rep_fly_assault_DOME");
    NumObjects(2);
    Height(200, 300);
    VelocityZ(20, 50);
    Distance(1500);
    InDirectionFactor(2);
}

//Rep fighters
SkyObject()
{
    Geometry("rep_fly_gunship_DOME");
    NumObjects(20);
    Height(80, 140);
    VelocityZ(80, 120);
    VelocityY(-10, 10);
    Distance(600);
    InDirectionFactor(0.5);
}

//CIS fighters
SkyObject()
{
    Geometry("cis_fly_droidfighter_DOME");
    NumObjects(20);
    Height(80, 140);
    VelocityZ(80, 100);
    VelocityY(-10, 10);
    Distance(300);
    InDirectionFactor(0.5);
}

//CIS rockets
SkyObject()
{
    Geometry("cis_fly_techounion_DOME");
    NumObjects(8);
    Height(0, 0);
    VelocityY(10, 12);
    Acceleration(0.0, 2.0, 0.0);
    Distance(1000);
    LifeTime(80.0);
}

SKYINFO
The SkyInfo properties define the global sky properties.These are mostly self-explanatory and their settings adjusted to see the effects in game. Again the sky files provided with the assets for the worlds that shipped with the game are a great resource for sky file settings and their effects.

SUNINFO
The SunInfo defines the actual sun object properties. No texture is used for the sun in the template, but one could be.

DOMEINFO
DomeInfo defines the actual dome and objects contained by the dome object. One object is mandatory, and that is the dome itself. The dome geometry shape is not limited to a spherical shape, it could just as easy be a cube. The dome model gemoetry is exported from Softimage XSI. In the template sky there are objects for the arena and the spire in the background. These are separate objects but they could have just as easily been a static part of the sky texture. When lifting off in a flyer, having the objects in front of the sky texture provides a different sense of perspective on the object while rising. If the objects were in the sky texture they would not change as the camera position rose above the world. With them as objects in front of the sky texture their MovementScale can be adjusted to provide a sense of closeness to the object as the camera peers over it.
LowResTerrain is the texture displayed for objects outside of the near visbility range. A good way to create a texture for this is using the ADVANCED IMAGE controls in Zeroeditor. In the Advanced Image Controls panel there is a button labeled Save HiRes Map. This button will save a huge image (4096x4096) of the terrain that can then be scaled down to 512x512 in order to maintain the image quality.

SKYBOJECTS
SkyObjects are objects that appear in the sky and not the dome. Specifically these are the capital ships and fighters that can be seen flying throughout the sky. These make use of special dome models that have less complex geometry and therefore utilize little memory. These objects must be included in the mission lua in order to load.
Quote from: Abraham Lincoln. on November 04, 1971, 12:34:40 PM
Don't believe everything you read on the internet

June 11, 2012, 05:19:45 AM #11 Last Edit: June 19, 2012, 08:46:30 PM by SleepKiller
GETTING STARTED

While the BFBuilder.hta application makes it possible to quickly and easily build a new world, understanding the files created and their contents is important in making any further changes to a map. This guide goes through the creation of Mod1, which was created manually, without the use of BFBuilder.hta.

The map template used to by BFBuilder to create new worlds was designed to meet the minimum in game requirements to run a world with the exception of the sky. The sky template and assets come from Geonosis, which makes use of all of the object type that can exist in the sky.


The template world was created manually without the use of the BFBuilder application. How is was created is detailed in the Mod1 Tutorial. View the Mod1 Tutorial

The Template contains these minimum requirements:
1 Terrain with a base texture (a blank base texture is used)
2 Command Posts, one owned by each team
2 Capture regions, one for each command post
2 Control regions, one for each command post
2 Unit Spawn Paths, one for each command post
1 Properly configured mission lua script for each era (2 luas)


Mod2 expands on the demonstration of minimum functionality by taking default world created by BFBuilder and adding Water, Vehicles, Props, Barriers, Path Plans, Map Boundaries, and global ambient sound.

While these templates and documentation do not detail all of the artistic capabilities, the assets used to make the worlds in the shipped version are provided for use. The objects from the shipped levels are usable in new mod levels and will function if set up correctly.

DATATemplate
All new projects are created by BFBuilder by copying DATATemplate and then making necessary changes to reflect the name of the new project and world.

Since the base template does not add any new sounds to the game some of these files are unused. Other files, such as the mission lua files, need to be edited to match the needs of each new world. How to do this will be detailed later.

Template Sky
Most of the work that is done to the sky is done manually by editing the sky file with a text editor. The assets required by the Geonosis sky are listed within the .sky file and each asset file was copied into the appropriate location in the template folder. To change the sky the new textures and gemoetry need to be copied into the the same folder and the Geonosis assets removed. Depending on the geometry of the sky, it may or may not display properly in the editor. Do not use the editor as a reference for the appearance of the sky, always check that in game. It is also important to note that texture and mesh files typically require .option files. Make sure any sky elements copied from another world include all of these files as well, and any new objects created need these created manually.

Adding Command Posts
Command posts are added in Zeroedit by entering OBJECT mode and then selecting on BROWSE to find the ODF file. ODF files are Object Definition files, text files that define all of an object's properties in the editor and game. Since the Add Ons make use of assets that shipped with the game, the common odf files included in DataMod#\common\odf\ are only present for representing objects in the editor. The common assets that shipped with the game are locked, and no additional ODFs or MSH files can be added to DataModID\common because they would not exist in the compiled files that shipped with the game. Among these common objects are various command posts, the most common of which is called com_bldg_controlzone.odf. This can be found by browsing in object mode to DataModID\common\ODF\ and selecting com_bldg_controlzone.odf.

Objects
Once an object ODF such as a command post is selected the editor returns to select mode. To place the object in the world PLACE mode must be selected before clicking on the terrain where the object is placed. If the terrain is clicked more than once, more than one object will be placed until the mode is returned to SELECT.

Command Post Properties
Two command posts were placed before returning to select mode and selecting one of them. With one of the command posts selected it's properties were configured in the panels on the left and right of the screen.
These include:
Name: used by other objects to reference command post
Label: used for language localization
Team: specifies who owns the command post at mission start
CaptureRegion: specifies name of command post's capture region
ControlRegion: specifies name of command post's control region
SpawnPath: Specifies name of command post's spawn path


Other fields were either blank or filled in with defaults and no other changes were required. Typically command posts are named CP1, CP2, CP3, etc and their label mirrors those names but in the case of mod1 the label was changed to highlight where the information required for localization comes from. For that reason CP1Label and CP2Label were used. Since each level requires a command post be owned by each team, under Team for CP1 team 1 was specified and for CP2 team 2 was specified.

Capture and Control Regions
Capture and Control regions are just two types of regions used in the game. Every command post must have a capture and a control region, and although the control region is not always required it is good practice to always create both. Regions are created in Zeroedit's Region mode. Once entering region mode NEW GROUP is selected and whatever region shape is selected will appear at the tip of the mouse to be placed. The capture and control regions can reside anywhere and be any shape, but typically the capture region surrounds the command post with the control region nearby. The RegionID property is only used to track multiple regions in the editor, and the Properties property is where the command post looks for the region names. For that reason in Mod1 the command post capture region RegionIDs were name CP#Sphere and CP#Box to represent their shape and illustrate where the command post is retrieving the region name. The properties for each were labeled CP#Capture and CP#Control as specified in each command post instance properties.

Spawn Paths
With command posts and capture regions in place, all that is left to add before the mission is playable is Unit Spawn Paths. Spawn paths are added by entering spawn mode and selecting new path. Each path is created a node at a time, each node representing the location a unit can spawn in. By clicking around CP1 several times a path of nodes was created. Right clicking deselected the path and the name of the path was entered into the Path Name input field as CP1Spawn. This naming convention also works well and was applied to the same way to CP2.

Localization
Localization uses base strings such as CP1Label.name and stores them in a file so different language translations can be created. To set it up so the names appear properly in English. Clicking on Localize ModID opens the MultiLanguage tool which contains scopes and keys for game variables to be translated. Inside that file the planet name can be seen and any command posts or other objects that need to be localized. Entries do not appear by default, they must be added as scopes and keys in a heirarchy delimited by periods. For example in the mission lua the mission objectives are listed in the form:

level.mod1.objectives.1 level.mod1.objectives.2
level.mod1.objectives.3


This denotes the localization string within the MultiLanguage tool that appears as the tree:
level
    Mod1
        Objectives
            1
            2
            3

Selecting the keys in the MultiLanguage Tool exposes a text field so the text displayed in game can be edited.

Some present by default are there for example purposes and are not used.

Mission LUAs
Mission lua files, such as ModIDa.lua define all of a level's properties. In setting up the template many lines were commented out in the luas as they were not needed. In addition, the sound files loaded by the level were set to TAT, which shipped with the game. For that reason no sounds were compiled for use in the new level and none of the sound files needed setting up. See the Mission Lua Guide for more information.

Quote from: Abraham Lincoln. on November 04, 1971, 12:34:40 PM
Don't believe everything you read on the internet

June 11, 2012, 05:20:10 AM #12 Last Edit: June 19, 2012, 08:46:45 PM by SleepKiller
FLYTHROUGH MOVIES FOR STAR WARS BATTLEFRONT
VIDEO ASSET DEVELOPMENT AND COMPRESSION:
Star Wars Battlefront flythroughs, the short video clip showcasing the level in the map select screen, are captured and edited as .avi’s and then compressed into .bik’s using Bink Video by RAD Game Tools INC. The flythroughs are titled using the naming convention of “map1fly.bik” where “map1” is the name of the map. The .bik’s are following the recommended compression guidelines listed on the Rad Game Tools website at: http://www.radgametools.com/binkhcwb.htm. These guidelines are a helpful reference, but of course results will vary depending on the content makeup of the video clip. Experimentation to achieve the delicate balance of good image quality at a low file size is the name of the game.

As a starting point, here are the settings used on average for the flythroughs on Star Wars Battlefront:

Overall data rate settings: Compress to a data rate (bytes) of 750000
Keep peak data rate under a multiple of the overall data rate 3.0
No scaling compression
How many frames to preview during bandwidth allocation: 12
Width: 640
Height: 480
Contrast: 8
Smooth %: 3
Deinterlace: On


SCRIPTING TO INCORPORATE INTO THE GAME SHELL:
The next step is to get the .bik file into the shell of the game.

First, go to the folder of where the movie assets are contained:

Downloadable content\DataTAT3\_SOURCE_PC\Shell\Movies

This directory contains the .bik movie and a .mlst text file. For example
Tat3fly.bik
Tat3.mlst

Place the flythrough movie in this directory and create a .mlst text file. The .mlst text file is titled the map name with a .mlst extension, for example, “tat3.mlst”. This is a text file that simply has one line of text:

..\..\_SOURCE_PC\shell\movies\tat3fly.bik

Second, go to another directory that contains the scripting file for how the movie should behave:

Downloadable content\DataTAT3\Shell\Movies

This directory contains .mcfg text files. The .mcfg text file is titled the map name with a .mcfg file extension, for example, “tat3.mcfg”. This is a text file that has a few lines of scripting:


// transition times used by all movies

MovieProperties()
{
    Name("flythrough_template");
    FadeInTime(1.0);
    FadeOutTime(1.0);
}


// Level fly throughs...
// TAT3

MovieProperties()

{
    Name("tat3fly");
    Inherit("flythrough_template");
    Movie("tat3");
    SegmentList()
    {
        Segment("tat3fly", 1.0, -1);
    }

}

These are all the components used in creating and displaying your flythrough to accompany your map in the shell of the map select screen.
Quote from: Abraham Lincoln. on November 04, 1971, 12:34:40 PM
Don't believe everything you read on the internet

June 11, 2012, 05:21:09 AM #13 Last Edit: June 19, 2012, 08:48:04 PM by SleepKiller
ZEROEDIT VERSION ZERO
A Guide to Building Levels for Star Wars Battlefront

This guide will walk through the various modes and mode tools of Zeroedit while explaining how to build levels for Star Wars Battlefront Version 1.11 or later.

Launching Zeroedit
Zeroedit creates an index of every file that exists in the directory structure beneath it each time it is started and as result a copy of the editor and it's config files is included in each datamod# folder and template. This speeds launch times and prevents crashes that result from files Zeroedit does not understand. Zeroedit uses this index when files are referenced during it's use rather than reading the paths in real time. Zeroedit can be launched by double clicking on the executable. By default no world is loaded, and the Lucasarts licensing agreement appears.

Zeroedit Interface
The following image illustrates Zeroedit's global toolbars.
There are five global toolbars, FILE, EDIT, SHOW, EDIT MODE, and ACTIVE LAYER.

File Control
The first is the file control. This bar consists of two buttons, one to load a world and one to save a world. Worlds use the .wld extension for the main file being saved, but many others are saved each time a world is saved, several of which correspond to editor modes while others to specific tools such as the LAYERS control or the terrain file. Worlds are saved in the world folder but assets used in the various edit modes also exist in the MSH and ODF folders.

Edit Control
The edit controls are simple UNDO and REDO buttons. These do not always work in all modes for all object types, and they have corresponding keyboard shortcuts using the standard Ctrl-Z for undo and Ctrl-Y for redo.

Show Control
The Show control is a special control that turns on the visibility of objects even if the editor is not in their normal working mode. For example Paths and Regions are invisible while working in object but a certain object needs to be within a region and not on top of a Unit Spawn Node. By turning on Paths and Regions they can all be seen but only the object can be edited. This comes in handy especially when dealing with object or foliage heavy worlds that take a lot of screen render time. Linked to the SHOW control is a subset of controls just for the vertex map of the terrain entitled Terrain View. These buttons affect how the vertex map is displayed. SOLID and WIRE are linked to one another as toggles while HEIGHT and COLOR and independent toggles. With SOLID toggled on the terrain is displayed as close as possible to how it will appear in game complete with textures and sky properties. With both WIRE and SOLID toggled on the terrain appears solid but there is a bright green wireframe grid overlaying the textures. With just WIRE toggled on just a gray wireframe view of the terrain is visible. HEIGHT mode toggles the vertex map to be displayed as a heightmap colored by topography. COLOR displays the vertex map colors as painted in COLOR MODE.

Edit Mode Control
The Edit Mode control consists of toggles that correspond to each of Zeroedit's edit modes. Zeroedit uses 12 modes for SWBF:
HEIGHT - Edit height properties of the vertex map terrain
COLOR - Edit color of the vertex map
TEXTURE - Edit textures applied to the vertex map terrain
WATER - Add water and edit water texture properties
FOLIAGE - Paint and erase foliage on terrain
OBJECT - Add and edit object location and properties
PATH - Add and edit unit spawn paths
REGIONS - Add and edit region properties
HINTNODE - Add and edit AI hint nodes
BARRIER - Add and edit AI barriers
PLANNING - Add and edit AI path planning connectivity graph
BOUNDARY - Add and edit map boundaries


ACTIVE LAYER
The layer controls were originally designed so multiple people could work on a world at the same time. Each person would work in their own layer which consists of the same set of files saved when there is only one layer known as the BASE layer. Creating a layer is as easy as selecting the CHANGE button and then clicking NEW on the pop up control panel and renaming the layer. During development as more functionality was added to the editor how layers were utilized changed. Several modes adopted multiple purposes so when one person was working in a layer they often had a lot of their own clutter to work around. As a result layers evolved to be created and named by functional purpose, and the base layer was not utilized. A design layer would be created for designers and artists to manipulate objects, paths, capture and control regions, boundaries, and path plans. A separate layer would be created just for Shadow Regions, and the same for SoundSpaces, SoundRegions, and often Trees and Buildings would be separated into their own layers on crowded maps. Objects can be moved from one layer to another and layers deleted to allow for flexibility during development.

ADVANCED
The advanced controls include TERRAIN, for creating a new terrain file; CAMERA, for changing the Fog Range and Sky Visibility as it appears in the editor only and provide a button for snapping the camera to a top down satellite view; IMAGE, for saving pictures of the terrain as a HEIGHTMAP or HIRESMAP for use in creating in game maps and low res terrain textures for use in game, as well as BURN TERRAIN, which utilizes the heightmap to burn shadows into the terrain.

VISIBILITY
The visibility bar provides levels of visibility in 500 meter increments (500-5000 on the 10 bar scale). In solid mode if the visibility range is too high to render all of the object on screen the editor will slow to a crawl or even crash, so it is best to start with the visibility low and increase it as necessary. This is less of a problem when working in WIRE mode since the terrain and it's textures are not being rendered.

ZeroEdit Keyboard / Mouse Commands


Ctrl + S           Save
Ctrl + L           Load
Ctrl + Z           Undo
TAB         Toggle  between Mouselook and Edit
Arrow Up              Rotate view up
Arrow Down      Rotate view down
Arrow Left      Turn view left
Arrow Right      Turn view right
NumPad (8)Arrow Up     Move view forward
NumPad (2)Arrow Down    Move view back
NumPad (4)Arrow Left    Move view left
NumPad (6)Arrow Right   Move view right
NumPad (7) Home      Move view left and forward
NumPad (9) PgUp      Move view right and forward
NumPad (1) End       Move view Left and back
NumPad Arrow Up      Move view right and back
, (<)         slow key and mouse movement
. (>)         speed key and mouse movement

With MOUSELOOK on, cursor disappears and you can not select anything, used to position the camera in the world.
Alt + I      Toggle behavior of Mouselook up and down
Mouse Forward   Look up
Mouse Back   Look down
Mouse Left     Look / Turn Left
Mouse Right    Look / Turn right
W      Move Forward
S      Move Back
A      Strafe to the left
D      Strafe to the right
F      Move up
V      Move down

With MOUSELOOK off, your cursor appears and you can select menus and manipulate the world
Left Click   Select or Place
Right Click   Deselect
Mouse Forward   Move cursor up the screen/Move cursor + item forward in the world
Mouse Back   Move cursor down the screen/Move cursor + item back in the world
Mouse Left   Move cursor left on the screen/Move cursor + item left in the world
Mouse Right   Move cursor right on the screen/Move cursor + item right in the world
Mouse Right   Move cursor right on the screen/Move cursor + item right in the world
F      Move cursor + item up in the world
V      Move cursor + item down in the world

When in OBJECT mode

Left Mouse Button   X axis
Right Mouse Button   Y axis
Middle Mouse Button   Z axis
C + L/R/M Mouse Button   Translate (move)
X + L/R/M Mouse Button   Rotate around Object Center
Z + L/R/M Mouse Button   Rotate around Object Root
O                       Center Camera on Selected Object

When in REGION or BARRIER mode

C + L/R/M Mouse Button      Scale Object in the X axis
X + L/R/M Mouse Button      Scale Object in the Y axis
Z + L/R/M Mouse Button      Scale Object in the Y axis

EDIT MODES
HEIGHT MODE
Height mode allows users to mold the vertex height map of the terrain with a terrain brush. Instead of painting the vertex map with color like a paint brush, the terrain brush applies FOREGROUND and BACKGROUND heights to vertices on the terrain height map. The brush control panel consists of MODE, SIZE, SHAPE, ROTATION, and PRESSURE as well as TERRAIN HEIGHT tools.

MODE
Mode defines the type of brush used to paint terrain. PAINT is the default and adjust terrain height consistently under the brush. SPRAY is akin to a spray can and raises terrain under the brush more erratically. RAISE gradually raises or lowers the vertices under the brush as long as the mouse button is being held down. The left mouse button raises while the right lowers. BLEND takes the foreground height and the background and applies a smoothing gradient between the two in the area under the brush. This is used to smooth out jagged hills and peaks for a more natural look.

SIZE
The size controls affect the width and depth of the brush in the various modes. Values can be typed in or defined using sliders.

SHAPE
Shape controls determine the brush shape. Brush shapes include SQUARE, which produces a solid brush with a hard edge; CIRCLE which produces a solid circle with a hard edge. If a circle is small it may look like a square due to the 8 meter grid tile size of the terrain. CONE looks and functions much like the CIRCLE shape but applies a blend like gradient to the terrain between the foreground height and background height that makes the terrain form a cone. Like circle, the smaller the cone the weaker the effect. BELL is much like CONE but instead of a blend gradient that results in a cone shape one that results in a bell shape is applied. RAMP shape uses the foreground height and background height to generate a rectangular ramp under the terrain brush.

ROTATION AND PRESSURE
Rotation and pressure apply to the brush rotation and "paint" pressure. Brush ROTATION can be edited in degrees while PRESSURE is a percentage. Typically pressure is left at the default of 20 but increasing pressure is useful when manipulating terrain in RAISE mode.

TERRAIN HEIGHT
Terrain height is a subset of controls that affect chosen height settings and allows for the selection of an area of terrain for copying and pasting. Two height settings are stored and attached to the height tools at all times, the foreground height and the background height. The foreground height is attached to the left mouse button and background to the right mouse button when PICK is active under Terrain Height. The height selected using the PICK tool is only for terrain vertices and PICK cannot be used on objects. MARQUEE allows for the selection of a rectangle of terrain that can then be copied using Ctrl-C. When an area of terrain is copied, the copy appears at the tip of the mouse arrow and superimposed over the terrain until the muse is clicked and it is placed in it's new location. Copied terrain can be pasted repeatedly. Right clicking will deselect the terrain. FOREGROUND and BACKGROUND input boxes allow for manually entering values but in coming up with values the world size and scope must be taken into account. While the default map size 256 x 256 meters with an 8 meter grid of squares, it does have max and min height settings in the mission lua that affect units and flyers.

COLOR MODE
Color mode is used to paint heightmap vertices. There are also controls for ambient environment colors, but these are for view in the editor only because the complexity of the sky file exceeds the functionality of the editor and the sky file must be edited manually. Otherwise the changes made in color mode are saved in the terrain file. To view the color changes best, toggle the COLOR button on the TERRAIN VIEW control panel.

PAINT BRUSH
The paint brush edit tools act as paint tools do so they are mostly self-explanatory. The brush controls consist of MODE, SIZE, SHAPE, PRESSURE, and COLORs (FOREGROUND and BACKGROUND attached to the left and right mouse button respectively).

MODE
PAINT applies the color to the vertex map consistently across the vertex map. SPRAY mode applies the paint more like a spray can. PICK mode allows the mouse pointer to be used as an eyedropper to pick a color from the terrain. BLEND mode allows the brush to blend one color with another where different the colored areas meet.

SIZE
Size is self explanatory setting the size of the brush in grid unit (8 meters per grid).

SHAPE
The shape tool works much like it did in HEIGHT EDIT MODE. SQUARE presents a square brush with a solid edge; CIRCLE a circular brush with a solid edge that appears more circular the larger the circle; CONE is designed for painting on cone-shaped vertex maps and fades the paint not far from the center of the brush; BELL functions much like CONE except the fade begins closer to the edge of the brush.

PRESSURE
PRESSURE allows the intensity of the color being applied while the mouse button is being held down to be adjusted. 20% is default.

FOREGROUND AND BACKGROUND
Current FOREGROUND and BACKGROUND color settings are displayed here using RGB values. They can also be set here by typing a new value into each input field and hitting enter.

COLOR FILL
The COLOR FILL button fills the entire vertex map with the FOREGROUND color.

COLOR TABLE
At the bottom of the screen is the COLOR TABLE control panel which contains a default palette and buttons for selecting FOREGROUND and BACKGROUND colors. There is also a LOAD button for loading a custom .ACT palette. Also in the color table are the controls for the editor's ambient colors such as SKY, FOG, and AMBIENT. These colors do light the objects in the world and can be used as reference when setting the color values in the sky file. The values can be set using RGB and HSV values.

TEXTURE EDIT MODE
Texture edit mode is used to apply textures to the grids on the terrain vertex map. The texture brush controls function just as they did for HEIGHT and COLOR with regard to SIZE and SHAPE with the exception of RAISE and BLEND. RAISE is used to bring out a texture that is on a layer below another visible texture. BLEND similarly blends the visibility of two adjacent textures. There is also a SOLO TEXTURE toggle that displays only the selected texture in the terrain view. In TEXTURE EDIT MODE the FOREGROUND and BACKGROUND are single alpha values.

TEXTURE and DETAIL
The TEXTURE input field is where the name of the texture to be applied is typed. The DETAIL input field is for the detailed version of the texture. The SHOW DETAIL button toggles the view of the terrain textures to display the detailed rather than the standard texture. For a guide to creating textures see the ART DESIGN GUIDE.

TILE CONTROLS
The TILE control panel provides visual slots for textures that can be applied to the terrain. When a tile is select the TEXTURE input field on the left side of the screen will display it's name. Every world needs a terrain file with at least one texture for the world to run. TILERANGE and TILEROTATION addresses how an individual texture is applied to the terrain grids being painted with the texture. These are especially useful when painting hillsides and cliffs. RAISE and LOWER move the position of the selected tile in the stack of layers. While it is functionally possible to stack as many textures in layers as desired, after about 4 it visually begins to fall apart.

WATER EDIT MODE
WATER EDIT mode is used to apply water tile in the game. Water tiles are 4 x 4 grids which means they are 24 meters x 24 meters in size minimum. Water tiles can be made up of up to 15 layers each with a different textures as well varying alpha and color values. Few of the water controls are actually used so not all of their functions are documented here.

In additon to painting water on the terrain setting up the water texture requires several text files associated with the project be edited to configure the properties for the water animation. These files are the world req, typically named <ModID>.req located in the Data<ModID>\Worlds\<ModID> folder, and the world FX file, typically named <ModID>.fx located in the Data<ModID>\Worlds\<ModID>\World1 folder.

The FX file is not created by deault and if written contains properties specified in the editor. It is easiest to copy FX files and water texture assets from worlds that shipped with the game and apply them to new worlds. The REQ and FX files for the worlds that shipped with the game server as a great reference.

Below is an example of the section that needs to be added to the ModID.req file. This was used in Mod2 and originally came from Jabba's Palace. It lists all of the textures that need to be included in the water animation. These textures are referred to by the FX file to create the visual effects:

REQN
        {
            "texture"
            "platform=pc"
            "water_bumpmap_0"
            "water_bumpmap_1"
            "water_bumpmap_2"
            "water_bumpmap_3"
            "water_bumpmap_4"
            "water_bumpmap_5"
            "water_bumpmap_6"
            "water_bumpmap_7"
            "water_bumpmap_8"
            "water_bumpmap_9"
            "water_bumpmap_10"
            "water_bumpmap_11"
            "water_bumpmap_12"
            "water_bumpmap_13"
            "water_bumpmap_14"
            "water_bumpmap_15"

            "water_normalmap_0"
            "water_normalmap_1"
            "water_normalmap_2"
            "water_normalmap_3"
            "water_normalmap_4"
            "water_normalmap_5"
            "water_normalmap_6"
            "water_normalmap_7"
            "water_normalmap_8"
            "water_normalmap_9"
            "water_normalmap_10"
            "water_normalmap_11"
            "water_normalmap_12"
            "water_normalmap_13"
            "water_normalmap_14"
            "water_normalmap_15"

            "water_specularmask_0"
            "water_specularmask_1"
            "water_specularmask_2"
            "water_specularmask_3"
            "water_specularmask_4"
            "water_specularmask_5"
            "water_specularmask_6"
            "water_specularmask_7"
            "water_specularmask_8"
            "water_specularmask_9"
            "water_specularmask_10"
            "water_specularmask_11"
            "water_specularmask_12"
            "water_specularmask_13"
            "water_specularmask_14"
            "water_specularmask_15"
            "water_specularmask_16"
            "water_specularmask_17"
            "water_specularmask_18"
            "water_specularmask_19"
            "water_specularmask_20"
            "water_specularmask_21"
            "water_specularmask_22"
            "water_specularmask_23"
            "water_specularmask_24"
        }

Below is an example of the section that needs to be edited or added to the ModID.fx file. The texture and bumpmap file names should be all that need to be edited here to change them,or the entire section can be copied and pasted from a world that shipped with game. Note the properties make use of file prefixes with a range that encompasses the total number of files that make up the animation:
Effect("Water")
{

    // general parameters
    PatchDivisions(8,8);
    Tile(2.0,2.0);

    // ocean parameters
    OceanEnable(0);

    // water event parameters
    WaterRingColor(148, 170, 192,255);
    WaterWakeColor(192, 192, 192,255);
    WaterSplashColor((192, 192, 192,255);
    OscillationEnable(0);

    DisableLowRes();


    // PC parameters
    PC()
    {
        Velocity(0.01,0.02);
        MainTexture("tat3_water.tga");
        LODDecimation(1);

        RefractionColor(101, 136, 140, 255);
        ReflectionColor(150,150,150,150);
        UnderwaterColor(128, 130, 128, 64);
        FresnelMinMax(0.2,0.7)

        NormalMapTextures("water_normalmap_",16,8.0);
        BumpMapTextures("water_bumpmap_",16,8.0);
        SpecularMaskTextures("water_specularmask_",25, 2.0);
        SpecularMaskTile(4.0,4.0);
        SpecularMaskScrollSpeed(0.0,0.0);
    }

}

WIDTH AND HEIGHT
WIDTH and HEIGHT are for the brush size. This brush is always square and 1 unit is equivalent to 4 terrain grid tiles. LAYER is used to change the working layer for the water tile. HEIGHT was not used.

UVEL, VVEL, UREPEAT, VREPEAT
UVel, VVel, URepeat, and VRepeat control the animation of the water texture layers. They control the speed repeat frequency respectively along the x and y axes.

TEXTURE
TEXTURE is where the water texture name is typed in for the specified layer.

COLOR
COLOR specifies the background color of the tile not contained in the water textures. This color would applies to all layers if they are all transparent.

ALPHA
ALPHA sets the alpha values for the layer and GLOW was not used.

FOLIAGE EDIT MODE
Foliage is defined in the PRP file using text editor and subsequently applied using the FOLIAGE BRUSH tools. There are four foliage layers as defined and simple controls for brush SIZE and SHAPE because foliage is applied in an erratic fashion. There are also FILL WORLD and ERASE WORLD buttons that apply and remove foliage across the entire terrain. In the game assets provided some of the foliage is set up to appear in the editor as small white disks, while other foliage is fully rendered. This was done on a case by case basis to make it easier to use the editor by increasing render times and visual clutter to work around.

Foliage properties are written to the prop (prp) file. The format is below for two types, the first utilizes a mesh called editor_grasspatch.msh which appears in the editor as a white disk. The second layer utilizes the most typical type of foliage used is the second example which also has multiple types of foliage in a single layer.

Layer(0)
{
    SpreadFactor(0.1);
    Mesh()
    {
        GrassPatch("nab_prop_grass.odf", 50);
        File("editor_grasspatch.msh", 50);
        Frequency(100);
        Scale(1);
        Stiffness(0.0);
    }
}

Layer(1)
{
    SpreadFactor(0.4);
    Mesh()
    {
        File("end_prop_fern5.msh", 30);
        Frequency(20);
        Scale(1);
        Stiffness(0.0);
        CollisionSound("foliage_collision");
        ColorVariation(0.2);
    }

    Mesh()
    {
        File("end_prop_treeclump_1.msh", 50);
        Frequency(80);
        Scale(1);
        Stiffness(0.0);
        CollisionSound("foliage_collision");
        ColorVariation(0.2);
    }
}

Foliage Properties:
The SpreadFactor determines the density of the foliage on a particular tile. The lower the number the more dense. The number that appears in the File line at the end of the mesh or object specifies the view distance where the foliage fades in or out in meters.
The Frequency represents the percent of that particular layer that is made up of that individual mesh. In the above samples for layer 1, one mesh constitutes 20% percent of the foliage and the other 80% on a given tile when painted.

Scale scales the foliage object.

Stiffness determines how stiff an object is. If set to 0 the foliage tends to tilt with the terrain, but if set higher it becomes more erect and straight pointing straight up, such as when a tree is planted on a hill and you want the tree to be pointed towards the sky rather that at angle.

Collision sound is a sound hook that triggers a sound when something collides with the foliage.

ColorVariation provides a color deviation in the foliage so it does not all appear as the same object.

Hell Bushes
There is another type of foliage in the game that does not utilize the EDIT FOLIAGE mode but rather the PATH EDIT mode but it will be described here. This type of foliage is referred to as Hell Bushes and they are created by defining a path that functions like a string of popcorn where the popcorn are object meshes. The density of the objects along the string are determined by the distance property defined in the PRP file using syntax like that below. Examples of Hell Bushes in the game are the bushes that encircle Yavin 1.

TreeLine()
{
    Path("jungle1")
    {
        Distance(28);
        BorderOdf("end_prop_treebill.odf");
    }
}

OBJECT EDIT MODE
Object edit mode allows for importing and in some cases configuring instance properties of objects created with Softimage XSI and defined using Object Definition Files (ODF). Once an object has been set up and loaded into the world's ODF directory the editor can be launched and the object will be found if it's name is typed into the ODF File input box. Once imported an object can be placed using the ACTION MODE: PLACE. From there the object can be moved and manipulated.

ACTION MODES
Object actions include SELECT, PLACE, and MULTI SELECT. These are self explanatory with the additional sidebar that once an object is selected and being placed, all one has to do to duplicate the object is to continue clicking the mouse on the terrain to add additional copies.

SNAP TO
SNAP TO provides toggles to snap objects to grid squares when moving or a specific degree intervals when rotating. The rotation of an object can be reset to it's default state using RESET ROTATION.

ALIGNMENT
In conjunction with the keyboard controls the alignment controls make used of world and object geometry to align objects.

USE ROOT or ORIGIN is utilized when rotating objects. These settings determine whether what point in an object's geometry is used as an axis of rotation.

GROUND TO TERRAIN and OBJECT determines whether an object snaps to the terrain or another object when the GROUND OBJECT button is selected. Grounding to the terrain or object makes use of the select object's geometry and origin, so depending on the model it's position on the ground may need to be adjusted to prevent it from floating above or being embedded in the terrain. Objects ground to terrain by default when adding them to a world but their height can be set manually as well. To ground an object to another object, simply set the mode to OBJECT with the first object selected. It is assume the first object is located above the object it is being grounded to, so when the GROUND OBJECT is selected the top object snaps to the bottom one rather than dropping through it to the terrain height.

SELECTABILITY
Selectability provides controls for hiding individual objects using the HIDE toggle and disabling objects in the editor from being selected using the ACTIVE toggle. These are used when dealing with cluttered maps and one needs to work around a lot of objects. To change the properties of an object that is no longer ACTIVE as selectable it must be selected from the OBJECT BROWSER at the bottom of the screen.

HEIGHT
Height is specified in meters and LOCK will the height of a selected object or group of objects,

ODF FILE
ODF file specifies the name of the objects ODF file.

NAME
NAME specifies the name of the object for editor purposes only as it appears in the object browser list.

LABEL
LABEL is used to define the key string that referenced in the localization file. This descriptor can then be translated into multiple languages.

TEAM
Some object can make use of the TEAM field, most specifically command posts. This field and those in the OBJECT INSTANCE control panel address instance properties for objects with advanced functionality.

TOGGLE BROWSER
This button toggle the large object browser window at the bottom of the screen.

OBJECT INSTANCE PROPERTIES
This control panel exposes object specific settings that can be applied a case by case basis for each instance of an object in a world. There are typically default settings for these objects defined in common ODFs that are overwritten in the world file when an instance is placed. There are COPY TO and COPY FROM buttons that allow the selecting of one object, copying, selecting a second, and then pasting the properties to another instance. There are PGUP and PGDN controls to page through large collections of properties.

PATH EDIT MODE
PATH EDIT MODE is used for creating UNIT SPAWN Paths. Unit SPAWN PATHS consist of a string of SPAWN nodes that contain color axes that indicate the direction the unit will face when spawned. Spawn paths can be named and that name referenced in object instance properties such as in the case of command posts. PATH nodes can be rotated using the standard keyboard and mouse controls and like objects snap to the terrain first. Nodes and paths can have their heights adjusted and locked using the LOCK HEIGHTS button and/or by holding the shift key.

NEW PATH
In NEW PATH mode a new path name is generated and the mode changes to ADD NODE. In this mode every mouse click on the terrain places a node.

MOVE
Once placed a path can be moved by right clicking on it while nodes can be selected and moved individually if they are selected with the left mouse button.

TAPE MEASURE
PATH EDIT MODE comes with a tape measure that can be used to measure distances in meters.

REGIONS EDIT MODE
There are many types of regions. Examine the assets that came with these tools to examine their properties. In general they are Capture Regions, Control Regions, SoundStream Regions, SoundTrigger Regions, SoundSpace Regions, Shadow Regions, Death Regions... and probably more. Capture and control are explained in the Mod1 tutorial. As an example it explains that the RegionID property is arbitrary for use in the editor only while the Properties field is what defines the effect the region has in game. Capture and Control Regions simply need to be referenced to be functional. Other regions, such as SoundStream regions have properties and parameters that need to be more elaborately defined. Mod2 contains a simple example of how a SoundStream region is set up. The RegionID is arbitrary, but the properties always begins with SoundStream then the name of a SoundStreamProperty, then a number. The number represents a calculated rolloff point (1 over the number is the number of meters the sound rolloff begins) and this understood by the game engine. Similarly SoundTrigger Regions are regions that play a sound when a unit enters them. An example of this is the "Transport One is Away" announcement inside the bunkers and hangar on Hoth. SoundSpace Regions call soundspace properties that affect what kind of reverb and occlusion the sound heard within a region exhibit. Shadow Regions apply lighting properties different from those of the outdoor world. This basically blocks the sun virtually because the sun and ambient light pass through objects and a solution for blocking light in addition to lighting is needed. Death Regions are just regions that kill a unit of entered. These are used to kill units that fall into traps or spaces that cannot be escaped. They are simply named and defined in the mission lua to function. One other is a Rain or No Rain region such as those used on Kamino to block rain from appearing indoors.

REGION ACTIONS
Regions are declared first as groups because they can share properties. To create a region NEW REGION must first be selected in ACTION mode and then the terrain clicked for it to be placed. Once placed, a region can be selected when in SELECT mode and it's properties set and adjusted. Regions can only be BOXes, SPHEREs, and CYLINDERs, in some cases such as sound, must be of a certain shape to function. Regions can also be snapped to grid tiles using the SNAP TO toggle.

HINT NODE EDIT MODE
HINT NODEs are hotspots that when an AI is in range triggers the specified behavior in the unit. There many node and behavior types, some with primary and secondary stances for deeper control over the unit's behavior. Hint nodes should be used in moderation for the best performance and AI behavior. Hint Nodes have indicators that illustrate the hot spot and direction the unit must be facing to perform the behavior.

NEW NODE
Selecting NEW NODE in the ACTION control panel will allow for the placement of a new node with each mouse click.

MOVE
Once placed a node can be select by changing to MOVE mode and it's properties adjusted.

TYPE
The TYPE controls set the node types as well as any subsequent behavior that can be controlled. The node types are SNIPE, PATROL, COVER, ACCESS, JETJUMP, MINE, and LAND. SNIPE affects marksmen, PATROL causes units to hang around an area changing position, COVER causes AI to duck behind the object the node is placed behind, ACCESS is aesthetic and causes a unit to stand in front of an object like a control panel as though they are doing something, JETJUMP targets jet troopers and can be used to control whether or not they leap up to higher levels such as the huts in the tees on Endor, MINE specifies a spot for the AI to place a mine field, and LAND targets Carriers for landing a deploying troops. Some of these have primary and secondary stances that cause a unit to stand, crouch, go prone, or face left or right. A METANODE allows for a behavior to be applied to a greater realm of influence or collection of nodes.

NAME
Hint Nodes can be named for convenience in the editor.

TOGGLE HEIGHT
This toggle controls the ghosted height indicators that appear on objects in the editor such as hint nodes, This is just a visual indicator that can be changed to make it easier to see how this nodes line up in the editor as objects of infinite height. These same controls apply to other edit modes as well and they all have controls to change the height as well as transparency of the height indicators.

BARRIER EDIT MODE
Barriers act as invisible boxes that the AI recognize and calculate the area of in order to plot a course around objects. Each barrier also has a set of filters that determine what AI types can pass through them. AI cannot chart a course to a command post that is within a barrier filtering out that AI type. Barriers are created by selecting NEW from the EDIT BARRIER ACTION mode. When NEW is selected if the terrain is clicked with the left mouse button the first point of the rectangular barrier is placed and the shape begins to grow from the anchored point as the mouse is moved. Clicking a second time anchors the second point, and a third time the third anchor which places a barrier whose shape can be adjusted if the ACTION mode is set to STRETCH. The entire rectangle is selected so the barrier can be moved using MOVE mode. When moving a barrier if the shift key is held the corner of the barrier will snap to the nearest corner of an adjacent barrier. When ROTATE mode is selected if a barrier is clicked on the corner closest to the click point will become an anchor point for rotating the barrier.

BARRIER FILTERS
BAN controls define the filters for each barrier. The ban filters include Solider, Hover, Small, Medium, Huge, and Flyer which apply to an object's ClassLabel as defined in the vehicle or unit's ODF file. Flyers handle barriers differently that other vehicles because they move faster and change course in a different manner. As a result barriers for Flyers should be larger to give them more time to change course before getting too close to an object.

TOGGLE HEIGHT
This button toggles the visibility of the barrier height in the editor. Barriers have infinite height in game and the TOGGLE HEIGHT function makes it possible to extended the barrier shading. HEIGHT and ALPHA display control the actual height of the shaded area as well as it's alpha transparency value.

BARRIER LIST
Barrier names are utilized in the editor only and therefore are arbitrary. Typically the default names are used.

PATH PLANNING AND CONNECTIVITY GRAPHS
PLANNING PATHS are made up of Hubs and Connections forming a Connectivity Graph that defines routes taken by AI as they plot a course to a command post. When an AI unit plans a path to a command post it looks for the closest command post that is not owned by it's team and charts a course. By default, the AI will take the most direct course from it's starting point, a straight line. When a connectivity graph is present the AI looks first for the nearest command post, then the nearest connectivity hub and sets whichever is closer as it's destination.

PLANNING Mode allows for the creation of invisible HUBS and CONNECTIONS that provide paths and areas for artificially intelligent movement by non-player characters. When AI NPCs move about the map they start at a Hub and pick a destination Hub before establishing a path along Connections that link Hubs.

AI NPC MOVEMENT
AI NPCs can only travel from Hub to Hub via Connections. When an AI NPC moves it plots a course from a starting Hub to a final destination Hub. It first identifies the nearest connected Hub along a path that ultimately connects to the final destination Hub, and establishes the nearest Hub as a Primary Destination Hub. Rather than plot a direct course to the hub, secondary destinations along the connection are established to act as waypoints between Hubs. When the AI NPC reaches the Primary Destination Hub, it then revaluates the path to the Final Destination Hub and selects a new Primary Destination Hub that is along the shortest path to the Final Destination Hub and repeats the process moving the NPC one Hub closer to Final Destination Hub. This process is repeated until the NPC reaches the Final Destination Hub. Filters can be applied to connections and hubs that remove them from an AI NPC's destination selection process. Connections between hubs can given Weights in order to create less favorable connections for an AI NPC to choose from when selecting connections as possible paths. By changing the weight of hubs and connections, preferred paths for AI NPC to follow can be created.

HUBS
Hubs are areas that act as primary starting points and destinations as well as secondary waypoints along paths that AI NPCs are allowed to follow. A hub cannot exist by itself, so in creating one Hub a second is required for it to be functional. Hubs can be any size but are circular in shape. The size and shape of connections are created automatically to meet the size and shape of the hubs to which it is connected.

To place a Hub select the NEW HUB option while in Planning mode. With New Hub selected, clicking on the map will create a sticky circle marquee and a transparent white column that changes diameter as the mouse is moved forward and backward. When the mouse is clicked a second time, the circle's size is locked and the Hub is placed. Each Hub can be named by overriding the default Hub name that appears in the Name input field. Typically hub names are not changed.

Once placed, selecting EDIT/MOVE HUB can be used to move a Hub. Hold down the mouse while over a Hub and it will move with the cursor until the mouse button is released.

To delete a Hub select it with the mouse and then press the Delete key on the keyboard.

CONNECTIONS
Connections are areas that act as paths and areas for secondary waypoints between an AI NPC's starting and destination Hubs.

CREATING CONNECTIONS
A Connection can be created between two Hubs by selecting the New Connection option and clicking on a Hub. A rectangle will attach itself and rotate around the hub with the movement of the mouse as well as change in size until a second hub is selected, connecting the two hubs. When the unattached Connection comes near a hub it will snap to the hub's size automatically but will not attach itself until the left mouse button is clicked. To delete an unattached connection click the right mouse button at any time.

EDITING CONNECTIONS
To break a connection with one hub and attach it to another select the Edit Connections option from the menu and click on the connection with the left mouse button to select it. Right click on the attached hub and hold the mouse down to break the connection and the rectangle will once more follow the mouse and snap to hubs until the right mouse button is released. To delete the unattached connection simply release the right mouse button while the connection is not attached to hub.

HUB AND CONNECTION APPEARANCE
When Hubs and Connections are placed in the editor their size and shape as they appear is for editing purposes only. The hubs and connections are represented in the editor by two-dimensional lines that appear on the map vertices surrounded by light shaded columns that provide a sense of path volume, but in reality the height and depth are infinite. The appearance of the light shaded columns map-wide can be toggled on and off by selecting Toggle Hub Height or Toggle Connection Height on the menu accordingly. Using the Height and Alpha input fields can alter the height and transparency of the shaded columns.

FILTERS
Planning filters work on connections and they specify which units are allowed to use a connection. These function similarly to those in BARRIER EDIT MODE making use of toggle that can be changed once a connection is selected.

WEIGHTS
By default each connection from a starting hub to a destination hub has a weight of 100. To change the weight of a connection in the AI's selection process select Edit Weights from the menu and click on a starting hub. The connection will change color to yellow and when the mouse is moved outside the hub a line will be attached to the cursor until a destination hub is selected by clicking on it with the left mouse button. To delete an unattached path weight, click the right mouse button at any time. Once attached to a destination hub, the weight can be changed by entering a new weight in the Weight input field on the menu. WEIGHTS allow for greater control over which connections are used by AI as they move towards their final destination hub next to a command post.

INFINITE HEIGHT
The game has no 3D pathing so like barriers, Planning Paths have infinite height. This must be taken into consideration when constructing maps that involve stacked playing fields. Planning paths cannot overlap but rather must be joined using hubs.

BOUNDARY EDIT MODE
Each map typically has at least one BOUNDARY that when crossed triggers a countdown to death and a message that the unit is leaving the battlefield. Boundaries are required not just to define the playable area on a map but also to control the aesthetic appearance of the battlefield. If a unit moves too close to the edge of the map, the edge of the terrain or sky can become visible.

CREATING A BOUNDARY
A boundary is created by selecting the NEW BOUNDARY button under BOUNDARY ACTION MODE. This automatically generates a circular boundary that can be adjusted with the HEIGHT and DEPTH sliders so clicking the terrain to place a boundary is not necessary. Boundaries are a type of path so clicking on them with the right mouse button will allow them their position to be moved. Multiple boundaries can be used on a map, the death clock is only triggered if a unit is not within a boundary when they exist on a map.

BOUNDARY NAMES
Boundary names are arbitrary but need to be properly declared in the mission lua script to be functional.
Quote from: Abraham Lincoln. on November 04, 1971, 12:34:40 PM
Don't believe everything you read on the internet

June 11, 2012, 05:21:51 AM #14 Last Edit: July 20, 2014, 07:32:03 PM by Led
OBJECT DEFINITION FILES
Object Definition Files (ODFs) are text files the define the properties of every object in the game. All examples were included with the assets of the levels that shipped with the game. ODF files contain information that defines an object's presence in the editor as well as in the game.

File Properties
At the top of every ODF are lines that look like this:


[GameObjectClass]
ClassLabel = "someclasslabel"
GeometryName = "somefilename.msh"

[Properties]

The GAMEOBJECTCLASS section define the properties needed by Zeroedtor to view and manipulate the object.
CLASSLABEL refers to the object's functional class. This is for use in the game primarily, but in some cases it is used to expose an object's properties within the editor.
GEOMETRYNAME is the mesh file reference that ultimately makes an object visible in the editor.
PROPERTIES is where the beginning of the in game properties are defined.

In addition to GAMEOBJECTCLASS there are other classes that are defined in ODFs that are not viewed in the editor. These include WEAPONCLASS and EXPLOSIONCLASS. These headers are applied to ODFs that are typically called by other ODFs as child objects. For example a weapon is always attached to a unit, vehicle or building, and an explosion is always attached to a type of ordnance or an object. An explosion may or may not have an ODF. In many cases as with vehicles there is an exploded vehicle ODF that calls an explosion particle effect.

Particle effects are stored in the effects folder and can be created from textures using a Particle Editor included in the BFBuilder\ToolsFL folder. The Particle Editor is not covered here, but it should be noted that particle effects are saved as text files that refer to textures can also trigger sounds. Some particle effects have sound hooks.

ClassLabels
There are over 60 ClassLabels attached to objects in the game. A list of these can be found below in the appendix but it should be noted that there are redundancies and some are even obsolete. The list was assembled from the ODFs that shipped with the game but not all of the ODFs that shipped with the game are in the game. Most are self explanatory, and a few have been highlighted with notes. When creating new objects and ODFs there is a lot of overlap in the ClassLabels, so use a ClassLabel that provides just the functionality the object needs.

Vehicles and Units
When creating new objects not in the game the most difficult are probably the units and vehicles. This is because they are typically a collection of objects whose features are practically limitless and thus are defined on a case by case basis. The best way to create new units and vehicles to examine those that already exist. For vehicles that did not appear in the game use their ODFs with suspicion as they may not be set up completely and for those that do appear in the game they may have extraneous uneeded data, or obsolete comments. Units are pretty easy to create if all one wants to change is textures, weapons, and weapon strengths. Those require simple texture and property edits before munging the units and vehicles into a new side. What is more complicated is creating all new models with collisions and animations. How to do this in explicit detail is not covered here, but a primer can be found in the Art Design Guide and the Animation Guide.

Appendix
ODF ClassLabels

animatedbuilding
animatedprop
armedbuilding
armedbuildingdynamic
beacon - obsolete? once used for orbital strike
beam - ordnance
binoculars - for binculars as a weapon
bolt - ordnance
building
bullet - ordnance
cannon - weapon
catapult - obsolete, once used on Endor
cloudcluster
commandarmedanimatedbuilding
commandhover - mobile command post
commandpost
commandwalker - mobile command post
destruct
destructablebuilding
detonator - obsolete? Time bomb replaced remote detonator
disguise - weapon
dispenser - weapon
droid
dusteffect
emitterordnance
explosion
fatray
flyer - vehicle class
godray - lighting effect
grapplinghook
grapplinghookweapon
grasspatch
grenade
haywire
hologram
hover - vehicle class
launcher - weapon
leafpatch
Light
melee - used for Jedi melee weapons
mine
missile
powerupitem
prop
remote
repair
rumbleeffect - special, used in Hoth hangar
shell
shield
soldier
SoundAmbienceStatic - used to display speakers in editor when adding ambient emitters
SoundAmbienceStreaming - used to display speakers in editor when adding ambient emitters
sticky
towcable
towcableweapon
trap
vehiclepad - obsolete, once used for LATTE to drop ATTEs
vehiclespawn
walker - vehicle class
walkerdroid
water
weapon

Appendix B


(next post) http://www.swbfgamers.com/index.php?topic=4692.msg45269#msg45269
Quote from: Abraham Lincoln. on November 04, 1971, 12:34:40 PM
Don't believe everything you read on the internet