GBS TUTORIAL - Importing a new or revised unit model

Supreme Cmdr · November 24, 2001

BEGINNER

This is fairly straightforward. Most of the work is in the model and tag creation.

Say you want to replace the BCRUZ MK3 with a model of your choice (e.g. a Macross unit). Or say the ATV with a Leapard Tank.

Create the model in MAX 2.x or 3.x
Export it as a RIGID mesh using one of the plugins included in BCS. See the exporting docs included with BCS
Copy your .3D model and its textures (TGA or BMP) to the relevant folders and use BCS to view the model
Load the BCRUZMK3 model into BCS. Turn on the tags and from the tag list, make a note of EACH and EVERY tag. Since you are replacing and existing model (which as definitions in a GBS-II script file you don't have), you HAVE to ensure that the tags are the same. Only the model will be different.
Now, create those tags* in BCS and name them.
Backup the BCRUZMK3.3D model (or whatever craft model you are replacing) and rename your model to this known filename.
Start BCM and launch with the replaced model.

*These tags are ALL required. Here is a basic description of each. This will let you know where on your ship you want to place a tag.

For example, the BCMK3 has two guns underneath the fore bridge section. You may have a model which places two guns elsewhere. In which case, you need to create two additional /GUN tags for your new model.

The ObjectTags.txt file included with BCM shows all valid tag descriptions. This is for information only!! Don't go messing with stuff if you don't know what you are doing.

ADVANCED

This section shows you how to create a new model and add it to the BCM world. We will be creating a new fighter as an example.

Note that the security check at the top of some these INI files, will be disabled once GBS-2 is released. This will permit the modification of those files without BCM croaking.

Create the unit model and export it as normal
Determine how many tags it needs, create them in BCS and save the model.
Edit DATAASSETS.INI and add a new class
Edit OBJDEFS.SCR and add the model definition
Edit OBJCLASS.SCR and add the model class definition
Create the HUD icon file for the new model
Create the SNG icon files for the new model
Run PREPARE OBJECTS
Run PREPARE on any scripts that use the new model. By default, the new model is available in all existing scripts, as long as the new OBJDEFS.DAT file is in the SCRIPTS folder.
Copy the relevant files (3D model, textures, scripts) to the relevant folders
Start the scenario i.e. ROAM and select the new unit. NPCs will also have access to these new or revised units.

NOTES:

1. You would create the models as per the previous tutorials.

2. This will be based on how many guns, missile launches, contrail vectors etc. e.g. load the lfighter.3d fighter model in BCS. Then activate MODEL/TAGS/PRIMITIVES to see all the tags. You can also go into MODEL/TAGS/TAGS LIST to see their definitions. This fighter has 2 gun vectors, 2 missile vectors, 1 cockpit vector (VERY IMPORTANT!!), and 1 contrail vector.

So, you would need to create similar vectors for your model, depending on its attributes. e.g. if your model has 4 guns, then you need 4 gun vectors (/GUN:0,GUN, /GUN:1,GUN, /GUN:2,GUN, /GUN:3,GUN). The same with missiles vectors.

The contrail vectors are optional; but without them, there won't be any on the models. NOTE : that contrails are already pre-defined in BCMSFX.INI and scaled according to model type/size. So you don't want to mess with them.

e.g. a fighter has 11 particle based (sparks) and 11 bitmap (bitmap) based contrails to choose from. As such, you can use any of the pre-defined ones e.g. /contrail:4 instead of /contrail:3

3. The reason you have to define the class in here, is so that the craft is available for selection in SNG

In the case of our fighter, you would load ASSETS.INI (always backup the originals!!!) in a text editor (e.g. Notepad) and scroll down to line #1304 (it doesn't matter where you put it. I just like to keep my files clean and in organized sections) and clone that class block and copy it after the original.

That entry looks like this:

code:

CLASS

{

        ASSET {FIGHTER, SUPER FIGHTER, LFIGHTER, LFIGHTER.3D, 1}

}

Note that LFIGHTER is the class name of your model (usually it is the same as the model name) and LFIGHTER.3D is actual 3D model name. You would need to change these two to match your actual model class/name e.g. XWING and XWING.3D

Save the file when done

4. This is where you create the actual model's AI, dynamics and other performance related parameters.

In the case of our fighter, go to line 231 or thereabouts and clone the definition for LFIGHTER.

That entry looks like this:

code:

LFIGHTER.3D,L-FIGHTER,SARc,

 ?22,*1500,!15000,%125,A0.1144,L150,C1750,H2000,&600000,j25000,J25000,P25,R30,Y20,[250,]250,^15000,40000,{50000,}150000,(PRYATVGNEW)

For now, you would simply change the model and class name (LFIGHTER and L-FIGHTER) to that of your choice (as indicated previously).

Unless you know what you are doing so far, you do NOT want to mess with anything else. You have plenty of time to come back and tweak each value. Each one is described at the top of that file. So, until then, your new fighter will perform exactly as an LFIGHTER.

5. This is where you create the actual model's class, AI, loadout, crew (if it has them e.g. a station has SFMs) parameters.

In the case of our fighter, go to line 760 or thereabouts and clone the definition for LFIGHTER.

That entry looks like this:

code:

CLASS LFIGHTER:LFIGHTER.3D,fighter

{

   ICON={8,1};

   GUN=[sHOTm4r,SHOTm4r];

   MISSILE={4,ATA_WARRIOR};

   MISSILE={4,ATS_HYPERDYNE};

   MISSILE={4,STS_QUESTOR};

   MISSILE={4,STS_RALIX};

}

GUNS & SHOTS:

As you can see, the model has its 2 gun vectors defined here.

WARNING: Each /GUN vector defined in the .3D model, MUST be matched in this section.

e.g. if your model has 4 gun vectors, then you would have 4 entries (not 2) defined here.

e.g. GUN=[sHOTm4r,SHOTm4r,SHOTm4r,SHOTm4r];

The game engine will enumerate them accordingly. e.g. the first entry in this section, will be fired from the first gun tag (/GUN:0,GUN).

Also, you can mix and match shot types

e.g. GUN=[sHOTm4r,SHOTm5r];

The two SHOTm4r values determine what type of shot it uses.

The parameters for those shots are also defined in OBJECTS.SCR. And in the case of the LFIGHTER, are defined around line 577 and looks like this

code:

SHOTm4r.3D,_SHOTm4r,,A0,L250,C500,H750,~15000,E55,(QLBTA)

This means that each shot fired from either of those vectors, has a damage value of 55. So when that ship fires, a total of (55x2) is given to the target IF the shots hit it. To find out the rate of fire based on damage given, you would need to check the craft's gun recharge value in OBJDEFS.SCR. In the case of this fighter, it has a firing rate of 125ms (%125 parameter). Where 1000ms = 1 sec. This means that these guns can fire 8 times a second - IF - they are fully operational, charged and not damaged. All things being equal, when this fighter fires, the target will be damaged at the rate of 8x(55x2)=880 units per second - IF - all the shots hit the target.

And if you take into account the fact that each shot travels at the rate of 750ms (H750) and a lifetime of 15secs (~15000), you will see that the actual final damage awarded won't necessarily be 880 units because the ship could fire well out of range and the shots could expire before they reach their target. This will happen most often if the target is moving away and the closure rate is constant. e.g. the craft could fire 4 times and only the first voley (2 shots) could hit the target, while the other three voleys expire due to the target going out of range or manoevering outside the shot's dynamics capabilities. Shots are not missiles, so they don't do any tracking. This is why like NPCs who do predicted firing, you the player also have the same firing cues (TLL/TLD) in the HUD.

Like the contrails, the shots are also scaled according to the craft firing them. e.g. the m in SHOTm4r means that this is scaled for a medium sized craft. Use it on a, say, a carrier, and you won't see it when fired. At all.

The r is a designator which determines the type of rendering used for the shot. These different rendering modes were created for performance reasons. e.g. using the R class ones are more efficient than the legacy (used in previous BC titles) versions but are stretched.

The legacy ones (e.g SHOTm4) are more like projecticles. This creates a LOT of shots and which have a high impact during massive battles, though they may look better than the R class since they are more visual.

The P class shots (e.g. SHOTm4p) are used for the beam (aka PAD) type shots used by turrets. You cannot use P type shots for guns; only on turrets. So don't try it. And since nothing is stopping you from mounting turrets on a fighter (or any object for that matter), be my guest.

I don't want to get carried with discussing shots, but the general rule of thumb is, if you don't know what kind of shot to use, then clone values from the defaults and call it a day.

MISSILES:

This determines the type of missile loadouts used by the craft by default. Since the player can override these (in Tactical/Loadout), these values are only adhered to by NPCs. Nevertheless, you need to define defaults.

Unlike guns, the number of missile vectors does not have to match the values in this file. This is because the ship will use whichever missile vector is available when it fires. So for example, even though the LFIGHTER only has 2 missile vectors, there are 4 types of missiles defined here. This just indicates the type of missiles that a newly created fighter of this type, will use. You can even change all those four lines so that they all have different missile classes or numbers.

e.g. The missile loadouts for your new fighter could just have two classes instead of four. When an NPC is created using this fighter, it will only have access to these missiles. This means that if it is sent on a planetary ground strike op, it won't have ATS missiles to use. So it will use guns as best it can. It is always a good idea to have all three (ATA, ATS, STS) types of missile classes defined for crafts.

code:

   MISSILE={16,ATA_WARRIOR};

   MISSILE={16,STS_VAGRANT};

The MINE and OTS params are similar to the MISSILE param, though the MINE params requires an explicit /MINE vector or the unit won't be able to launch any mines.

Since OTS weapons are just special missiles, they are launched from missile vectors.

TURRETS:

Even though the fighter does not contain turrets, I am going to cover these here for completeness.

The turret and its vectors, follow the same principles of gun vectors. You need to name and enumerate them accordingly (load a unit with turrets into BCS e.g. BCRUZMK3.3D or GALCOMHQ.3D and take a look).

Then, in the class definition, you would create the turret class and the shots it uses.

e.g.

code:

  TURRET=[sHOTh3p,SHOTh3p,SHOTh2p,SHOTh2p,SHOTh3p];

To see an example, take a look at the BCRUZMK1 class definition in OBJCLASS.SCR around line 461

code:

CLASS BATTLECRUISER_MK1:BCRUZMK1.3D,carrier

{

   ICON={7,1};

   SHIP={4,INTERCEPTOR_MK1};

   SHIP={4,SHUTTLE_MK1};

   SHIP={20,MARINE_SFORCE_A};

   TURRET=[sHOTl1p,SHOTl1p,SHOTl1p];

   GUN=[sHOTl3r,SHOTl3r];

   MISSILE={15,STS_STARFLASH};

   MISSILE={15,STS_VAGRANT};

   MINE={5,MINE_CRAB};

   MINE={5,MINE_LEECH};

   OTS={5,OTS_TANIX};

   OTS={5,OTS_SKYFLASH};

   POD=[sHUTTLE_MK1];

}

SUPPORT UNITS:

Even though the fighter does not contain support units (crafts, vehicles, personnel), I am going to cover these here for completeness.

The /SHIP vector determines locations from where support units are launched from the primary unit.

They are also enumerated as missile vectors. This means that you can have as many ship vectors as you want, but they don't have to match the SHIP= parameters in the class. The unit will launch its support units from any available /ship vector.

If a unit does not have these vectors, no matter what classes are defined for it, they won't be able to launch. Period.

e.g.

code:

   SHIP={4,INTERCEPTOR_MK1};

   SHIP={4,SHUTTLE_MK1};

   SHIP={20,MARINE_SFORCE_A};

This indicates that the BCRUZMK1 has 4 MK1 intercetor fightes, 4 MK1 shuttles and 20 SFMs

ESCAPE PODS:

Even though the fighter does not contain support units (crafts, vehicles, personnel), I am going to cover these here for completeness.

The /POD vector is also similar to the /SHIP vector but is used exclusively for units (cruisers, carriers, transports and stations) which are able to evacuate personnel during a severe breach or destruction.

To see an example, take a look at the BCRUZMK1 class definition in OBJCLASS.SCR around line 461

Here is the entire class definition for the GALCOMHQ station, a very advanced and sophisticated unit in the game (as are carriers)

code:

CLASS GALCOMHQ:GALCOMHQ.3D,starstation

{

#  Terran/Military

   ICON={10,5};

   DNAME="GALCOMHQ";

   SHIP={5,VANDAL};

   SHIP={5,AURORA};

   SHIP={5,VIPER};

   SHIP={5,STARDRONE};

   SHIP={10,INTERCEPTOR_MK2};

   SHIP={10,INTERCEPTOR_MK1};

   SHIP={2,BATTLECRUISER_MK3};

   SHIP={2,BATTLECRUISER_MK2};

   SHIP={2,BATTLECRUISER_MK1};

   SHIP={2,SENTRY};

   SHIP={2,SOLNAR};

   SHIP={2,LRT10};

   SHIP={2,LRT15};   

   SHIP={2,MRT15};

   SHIP={2,JENSTAR};

   SHIP={2,GENERIS};

   SHIP={4,SHUTTLE_MK1};

   SHIP={4,SHUTTLE_MK2};

   SHIP={4,SHUTTLE_MK3};

   SHIP={15,MARINE_SFORCE_A};

   POD=[sHUTTLE_MK1];

   TURRET=[sHOTh5p,SHOTh5p,SHOTh5p,SHOTh5p,SHOTh5p,SHOTh5p,SHOTh5p,SHOTh5p,SHOTh5p,

HOTh5p,SHOTh5p,SHOTh5p,SHOTh5p];

   MISSILE={100,SDM_DROGUE};

   MISSILE={100,SDM_PIRANHA};

}

6. The icon used in the ICON parameter in the class definition, is just an index into the bitmap used to extract the icon displayed in the HUD and other areas. In the case of the LFIGHTER, the 8,1 parameter corresponds to SFXBCICONS8.TGA (image #8) and the craft image is the second one (cell #1) in the image file.

These are enumerated using programming principles, where the first item is 0, the second is 1 and so on. This is called 'zero based' enumeration.

Anyway, unless you have taken the trouble of creating an icon (it doesn't have to look exactly as these i.e. Yellowish), you can just leave the value as is.

But if you DO want to create your own ICON, then you would create a 256x256 TGA file (BCICONS12.TGA), give it an alpha channel and then put your 64x64 icon of the craft in the file. EACH icon cell should be 64x64 - and thats how come you have a 4x4 grid of icons in a 256x256 bitmap.

7. In order for the new unit to be displayed in SNG when you select an asset (or gear if is a weapon), you have to create a 320x200 BMP image bearing the same name of the unit class as defined in the ASSETS.INI file.

e.g. in GFXFRONTENDASSETS.ZIP you will see the LFIGHTER.BMP file. This is what is loaded when you select this fighter in SNG.

This image can be a MAX render of the model from MAX which is then scaled down to the size requirements or you can use BCS as follows:

Start BCS and change its resolution in VIEW/RESOLUTION to 640x480
Load the model and position it as desired
Use FILE/SCREENSHOT to take a snapshot
Load the shot from the SHOTS folder into a paint program and size it to 320x200 then save it out as a BMP file

Once you have the file, you can either zip it into the GFXFRONTENDASSETS.ZIP file or you can just leave it in the GFXFRONTEND folder (preferable). The system will use it wherever it resides.

8. Once you have done steps 1-6 and checked everything, it is time to parse the new values. This entails using the PREPARE script parser as indicated. This will then create a new OBJDEFS.DAT file containing the new info jammed into the OBJDEFS.SCR and OBJCLASS.SCR files.

Copying this file into the SCRIPTS folder will override the default version in the DATASCENARIOS.ZIP file (since it is newer) and all those values (e.g. if you changed the class values for units, even though you didn't create any new models) will be used by ALL the scenario files.

WARNING: Creating a new OBJDEFS.DAT file or even messing with ANY game unit, IMMEDIATELY invalidates ALL saved games. This means that in order to use the mod, you ALWAYS have to Start New Game (SNG).

9. This step is only required if you created new scripts (or modified existing ones) which either

use the new unit you just created
use units whose definitions you modified in OBJDEFS.SCR or OBJCLASS.SCR

e.g. revising the BCRUZMK1 model in ANY way - or - adding a new unit to the game requires you

copy the new .3D model (saved via BCS) to the MODELS folder.
copy the textures that were modified or are for a new model, to the MODELSTEXTURES folder
parse the object definition files (PREPARE objects)
parse all the user scripts which use this model (e.g. PREPARE bcia0090.scr then PREPARE phrases bcia0090.scr)
copy those script files (e.g. bcia0090.mis, bcia0090.dat, bcia0090.des, objdefs.dat) to the SCRIPTS folder.
Start a new ROAM, ACM, IA, TA scenario

Doing the above ensures that the default and user scripts, have access to this new or modified unit but NOT from previous saved games. However, games saved using this new file set, can be resumed and restore (roam/acm) as normal.

[ 03-06-2002, 13:29: Message edited by: Supreme Cmdr ]

Sign In

GBS TUTORIAL - Importing a new or revised unit model

Recommended Posts

Supreme Cmdr

Link to comment

Share on other sites

Please sign in to comment

Browse

Activity