SupCom Modding Tutorial

By Exavier Macbeth

 

Written Post Patch: 1.1.3251

 

Due to the many requests I have had to assist other modders with their creations I decided that I would just write a tutorial, which saves a lot of trouble when it comes to answering the same questions repeatedly. This tutorial is going to be rather basic if somewhat long but I intend this as both a reference and a tutorial. Also as a forewarning I will probably mention my own mods on a regular basis because most of my knowledge on these things came through developing said mods. I am sure no one will really care but it is just a heads up.

 

Things I plan to cover in this tutorial:

-Basic Mod Setup & Organization

-Modifying Existing Units/Structures & Blueprint Explanations

-Creating a New Unit (Code Aspect only, this is not a Modeling tutorial)

-Creating a New Weapon to mount on your unit (Beam, Missile, Projectile, and ECT)

-Packaging & distributing your mod for others

 

Note: While I intend to provide as much information for each field in the blueprints & basics of the script files as I can. I do not claim to know everything. So there will more than likely be holes when it comes to things that I have yet to look at directly or have never felt the need to change. Other modders are welcome to suggest additions to fill these gaps however this tutorial is mostly aimed toward the newer to modding crowd.

 

I also give warning that this is not written in a professional manner. If I tried to write it from any other viewpoint than my own the project would have probably been abandoned before the first chapter was done 😛

 

Table of Contents

 

-Section 1: The Basics

    Chapter 1: Creating Your Workspace    3

    Chapter 2: Setting Up Your Mod Folder    5

 

-Section 2: Blueprint Breakdown

    Chapter 3: Dissection of the Blueprint File    7

    Chapter 4: Editing Existing Unit & Projectile Blueprints    22

 

-Section 3: Creation of a New Unit

    Chapter 5: Basic Creation for Game Recognition    25

    Chapter 6: Unit Script File Adjustments    29

 

-Section 4: Creation of a New Weapon

    Chapter 7: File Structure Layout    31

    Chapter 8: Projectile Based Weaponry (Projectiles & Missiles)    35

    Chapter 9: Beam Based Weaponry (Continuous & Pulse Beams)    38

 

-Section 5: Packaging & Distributing Your Mod

    Chapter 10: Packaging & Distributing    40

SECTION 1 – Basic Mod Setup & Organization

 

CHAPTER 1 – Creating Your Workspace

 

This chapter is going to be rather basic and is just designed to set the stage for the rest of this tutorial which will probably turn out to be a book by the time I am done. The first thing we need to do is of coarse gather everything up and set up a workspace for us to work out of. Now you don’t need to go to quite the extremes that I do but I prefer an organized workspace so that’s what I will be describing here.

 

Gather the needed supplies:

-Yourself (No Forced Labor Allowed)

-Computer (You better have one of these)

-Supreme Commander Game Installed (Your trying to mod it right?)

-Enough Hard Drive Space (Unpacked game files take about 4GB of space)

-Text Editing Program of Your Choice (Windows Notepad or Notepad++ are common)

-Your Choice of a Weapon of Mass Destruction (Or a box of stress balls)

 

Anyway the first thing I recommend is that we set up a reference workspace. This workspace can be anywhere on your computer that you want it to be though for ease of use I just created a folder “SupCom Mod Workspace” on my D:\ drive (C:\ for those who don’t use petitions). From now on if this tutorial refers to “Mod Workspace” this location is where I am referring to. Now we need to fill the mod workspace.

 

Create another folder in your mod workspace and call it Game Files. You can also add the current patch number to the name if you want (as I did when the most current patch came out so I still have the older files for reference). Then I would like you to open another folder and go to your SupCom root directory. This is going to be wherever you installed Supreme Commander to initially and is also the folder that has folders like gamedata, bin, & mods folder. From now on if this tutorial mentions root supcom folder I will be referring to this location.

 

Now from this root folder we need to create a “mods” folder if one doesn’t already exists. However we will come back to that folder shortly. What we need to do now is go into root/gamedata/ folder where all the games scd files are. I want you to change the extension of every file from *.scd to *.zip so that we can unpack them. I want you to unzip all the files into our mod workspace folder so that we can reference the unpacked version. Do not, and I repeat, do not unpack the mohodata.scd directly. It should go in a mohodata folder due to the fact that several of the files in it will overwrite things in the normal /lua/ folder. However some of it is useful as reference. Once this is complete we need to change the file extensions on the *.zip files back to *.scd to make sure the game runs properly. We will not be touching these SCD files again unless we need updated info due to a patch.

 

NOTE: If you cannot see the file extensions then go to “Tools > Folder Options > View Tab” In that list will be an option “Hide extensions for known file types”. Make sure this is unchecked. Hit Apply & OK. This Note is based on WinXP.

 

Example of Mod Workspace File Structure:


 

Now that we have that taken care of we can go back to the root directory and then into the /mods/ folder we created earlier. In here I would like you to create another folder. The name is up to you but this folder will be the main folder for your mod. I recommend that you do not use any spaces in this name. It’s not mandatory but it makes linking things later less stressful. You can have _ or – in there all you like though. Once that is done go into this folder. From now on this spot is going to be referred to as the mod folder by this tutorial for ease of description.

 

Two more things I would recommend doing before we conclude this chapter. Right click on the SupCom Icon on your desktop (that you use to start the game) and go to properties. In the target field you will see something like this:

“D:\Applications\THQ\Gas Powered Games\Supreme Commander\bin\SupremeCommander.exe”

This example happens to be where I installed the game. Change it to the following:

“D:\Applications\THQ\Gas Powered Games\Supreme Commander\bin\SupremeCommander.exe” /log log.txt

Remember that yours may be a little different then mine but the important thing is getting the log command on the end. What this does is enable the logging of the game which will record most script errors that can and probably will appear when the mod fails to work properly. I say most because I have had some things not shown up, which is when I made heavy use of my choice weapon of mass destruction. Then Right click on your desktop and go to “New > Shortcut” We want to create shortcuts to both the Mod Workspace & the Root SupCom Directory for easy of access later. And you can also create one for your Mod Folder as well but that’s only if you’re too lazy to just open /mods/modfolder from you root directly.

 

CHAPTER 2 – Setting Up Your Mod Folder

 

This chapter will mostly be working from the Mod folder mostly and creating files and folders to allow the game to easily recognize the mod for live testing. The first thing we need to create is a mod_info.lua file. This file is rather simple and strait forward. Check the Tutorial Resources I included with this tutorial for a Blank Slate version you can modify to your needs.

 

I will go over the few sections that are in this file but there isn’t much to say about it. The first and most obvious field is the name. This is the name of your mod. I would keep it rather simple and to the point. You will also notice a v1.0. I find that having the version number in the title helps to determine at a glance if you have the same version as someone you’re trying to play against. The next field is the version. This particular field is used by the game to determine the different versions of the mod. Copywrite is pretty obvious, not that it matters to the modding community much. The description field is a short (maybe double the length of your mods name at most) description of the mod. Essentially a reminder of what it does. The reason it has to be so short is because the box it sits in only holds about 2 lines of text properly. The Author is of course you, unless you invested in forced labor while I wasn’t looking. The URL field is pretty much unneeded but if you have a website dedicated to your mod feel free to put it in there. The Important one is the UID field. This is a unique ID number for your mod and I have provided one of the sites GPG recommended for use in creation of said UID.

 

Example of Mod_Info.lua File:


 

The rest of this file doesn’t matter much to us as we are not making a ui only mod and the other commands that can be placed here deal with restrictions and such I won’t get into. Basically though it’s possible to specify some mods to load before others for stacking purposes. Otherwise they load from top down how they are listed in the Mod Manager. With the last one on the list overwriting everything loaded before it (if 2 mods edit the same units). 🙂

 

Once that file is in place I would like you to create three folders in your mod folder. These won’t necessarily all be used by your mod but it gives us a reference if I need it later as I am not writing this tutorial from a planned sheet. Anyway the folders I would like you to create are “hook”, “units”, “projectiles”, & “lua”. These folders will be used over the course of this tutorial.

 

Example of a Mod Folder:


 

And with that I would have to say that section one of this tutorial is complete. Pretty simple but it sets the stage & folder structure for the rest of this tutorial.

SECTION 2 – Working With Existing Unit Data

 

Terms from Previous Sections:

-Mod Workspace – Folder Created in chapter one to hold unpacked versions of the games scd files.

-Root Directory – Location where SupCom was installed to by default on your computer.

-Mod Folder – Folder created in Root/mods/ that your mod will be run from and created in.

 

CHAPTER 3 – Dissection of the Blueprint File

 

This chapter will be rather long compared to the rest of this tutorial. And if you’re reading this then it means I didn’t abandon this project that this point… Again. Anyway before I dwell on that some more lets get started shall we? This section while long is going to be pretty strait forward. I will be pulling & displaying code from several units so that I can maximize the information I provide. Keep in mind that some units won’t have or won’t need all the information provided here. Though it is provided for easy reference.

 

First of all though I am going to take a moment to explain GPG’s unit naming scheme. As I am sure everyone has looked in the /units/ folder that we unpacked into our mod workspace. Simply put GPG used an odd way of labeling their units. Each folder and the corresponding files in them use this format. Below is an example of the file structure and what each file is for in the unit as well as a description of what the name breaks down to.

 

UEL0001 (UEF ACU)

    UEL0001_*.sca (Animation Files)

    UEL0001_Albedo.dds (Primary texture)

    UEL0001_LOD0.scm (Primary Game Model, Exporters exist for 3DS Max & Blender)

    UEL0001_LOD1.scm (Low Res, Low Poly version of model for when zoomed out)

    UEL0001_lod1_Albedo.dds (Primary texture for Low Poly Model)

    UEL0001_lod1_normalsTS.dds (Bumpmap type texture for minor detail, Low Poly Model)

    UEL0001_lod1_SpecTeam.dds (Reflectivness & Team Color control, Low Poly Model)

    UEL0001_normalsTS.dds (Bumpmap type texture for minor detail)

    UEL0001_SpecTeam.dds (Reflectivness & Team Color control)

    UEL0001_PhaseShield_mesh.bp (Personal Mesh Shield Control)

    UEL0001_script.lua (Special Scripts for this unit, Weapon firing tied here)

    UEL0001_unit.bp (Main Blueprint we are going to be looking at)

 

There are a few extra things but that’s the majority of what you will see. As for the Name breakdown…

 

U?$#### is the format

The breakdown:

U – Unit

? – Side (A: Aeon, E: Earth/UEF, R: Cybran/Recycler)

$ – Type (A: Air, B: Building, C: Civilian/Scenario, L: Land, S: Sea)

#### – Unit Number (There is a pattern of some form and the numbers for one unit will be the same for the other side’s version of the same unit. But I never looked closer then that)

 

Hope that’s understandable but nonetheless it doesn’t really matter. If all else fails just cheat like I do and go here: http://supcom.hacked.in/ it has very nice breakdowns of the unit stats but the main thing is if you click on an item and look in the address bar it actually gives you its Unit ID. Makes it easier to find its folder 😛

 

Anyway now that we are done with that lets get to the stuff inside the BP file. Remember this is not just taken from one unit though some of the type specific things I will probably make comment on. And without further dragging of my heels…

 

Air = {

AutoLandTime = 1,

BankFactor = 7,

BankForward = false,

BreakOffDistance = 2,

BreakOffTrigger = 5,

CanFly = true,

CombatTurnSpeed = 1.6,

EngageDistance = 50,

KLift = 3,

KLiftDamping = 1.8,

KMove = 1,

KMoveDamping = 1,

KRoll = 1,

KRollDamping = 1,

KTurn = 1,

KTurnDamping = 1.5,

LiftFactor = 5,

MaxAirspeed = 19,

MinAirspeed = 15,

StartTurnDistance = 5,

TightTurnMultiplier = 0.3,

TurnSpeed = 1.5,

Winged = true,

},

 

This section of the Blueprint is used exclusively by aircraft. Unfortunately I haven’t edited too much of the stats in this category due to not needing to. The only ones I am sure of are the basics. AutoLandTime is essentially how long the unit hovers in place idle before landing on the ground. LiftFactor is how fast the unit can take off from the ground. Min & MaxAirspeed is their travel speed while flying. TurnSpeed is how fast it can turn. I have not played with it enough to figure out the rest of it unfortunately.

 

Audio = {

 

},

 

The Audio section controls various sound effects used by the unit for things such as ambient movement, landing, exploding, & selection. This section does not contain the weapon’s audio files. Those come later.

 

Buffs = {

{

Add = {

VeteranLevel2 = true,

},

BuffType = ‘MAXHEALTH’,

Value = 5,

},

},

 

Buffs control the bonuses given to the unit when they obtain vetrency statuses. I only show level 2 in this example but there are usually entries up to 5. This particular one provides a 5 health boost to the unit (in this case a T1 Interceptor) when it reaches level 2. The actual kill count for veteran status is handled later by another entry.

 

BuildIconSortPriority = 30,

 

This line in the Blueprint file is actually very simple. It helps the interface determine what order the icons show up in when you open the factory or engineers build list.

 

Categories = {

 

},

 

Now this one is a fun one to lie out as it is one of the bigger sections. So below will be breakdowns of each of the specific things found in it rather than trying to lump them all up.

 

‘SELECTABLE’,

‘RECLAIMABLE’,

‘VISIBLETORECON’,

 

These ones are pretty much mandatory to all units 😛

 

‘BUILTBYTIER1FACTORY’,

‘BUILTBYTIER2FACTORY’,

‘BUILTBYTIER3FACTORY’,

‘BUILTBYTIER1ENGINEER’,

‘BUILTBYTIER2ENGINEER’,

‘BUILTBYTIER3ENGINEER’,

‘BUILTBYCOMMANDER’,

‘BUILTBYTIER2COMMANDER’,

‘BUILTBYTIER3COMMANDER’,

 

These commands delegate what can build this unit. Engineer & Commander ones are usually only found on Structures & Experimentals.

 

‘UEF’,

‘AEON’,

‘CYBRAN’,

 

This determines what side it belongs to. Please note that only ONE of these will be present in the units file.

 

‘MOBILE’,

‘STRUCTURE’,

 

Pretty much what it seems. Is it a building or does it has the ability to move. You CAN give it the mobile attribute with 0 speeds (physics later on) and make it be transportable so it will look like a movable structure.

 

‘TECH1’,

‘TECH2’,

‘TECH3’,

‘EXPERIMENTAL’,

 

These of course designate the Tech Level of the unit in question. While they are not technically required (Except for experimentals) it does have some impact on this like descriptions where the tech level is added automatically.

 

‘AIR’,

‘LAND’,

‘NAVAL’,

 

These markers are used to help the game determine what type of unit its dealing with.

 

‘DIRECTFIRE’,

‘CONSTRUCTION’,

‘COMMAND’,

‘ENGINEER’,

‘ARTILLERY’,

‘INDIRECTFIRE’,

‘ANTIAIR’,

‘RADAR’,

‘COUNTERINTELLIGENCE’,

‘OPERATION’,

‘SHIELD’,

 

These markers are used on most Land & Naval units and it is recommended (and mandatory) that at least one or two of these be in each unit. The reason is the games formation move system directly looks for these on Land units. (Unfortunately Naval Units are hard scripted in the formations.lua file but we will get to that later)

 

‘TRANSPORTATION’,

‘GROUNDATTACK’,

‘BOMBER’,

‘ANTIAIR’,

‘ANTINAVY’,

‘SCOUT’,

‘HIGHALTAIR’,

‘RADAR’,

 

These markers are used on Air units for the same reason as the previous section uses them for Land units. Without these the formation move system will not work properly. Neither will you be able to group move if you have more than one of them selected.

 

‘TACTICAL’,

‘NUKE’,

‘SILO’,

‘SUBMERSIBLE’,

‘INTELLIGENCE’,

‘OMNI’,

‘DRAGBUILD’, # Deals with the ability to drag to queue up multiple of them

‘SIZE4’, # Deals with building footprint size

‘DEFENSE’,

‘ANTIMISSILE’,

‘SONAR’,

‘STRATEGIC’,

 

These are just examples of other categories that you will probably see. I posted most of the mandatory ones and there are probably several that I have not figured out what they are for. But hey if I can get most of them then I am good.

 

That pretty much does it for the Categories section. Told you it would be allot of info but hey at least that’s one of the major categories down. Moving on…

 

CollisionOffsetZ = 0,

CollisionOffsetX = 0,

CollisionOffsetY = 0,

 

This line deals with the unit’s collision box and will allow you to offset it in a specific direction. Normally wouldn’t be modified unless absolutely necessary to get the collision box to line up right.

 

Defense = {

ArmorType = ‘Normal’,

Health = 250,

MaxHealth = 250,

RegenRate = 0,

Shield = {

OwnerShieldMesh = ‘/units/uel0303/UEL0303_PersonalShield_mesh’, # Only Personal Shields

PersonalShield = true, # Only Personal Shields

ShieldEnergyDrainRechargeTime = 3,

ShieldMaxHealth = 9000,

ShieldRechargeTime = 15,

ShieldRegenRate = 1800,

ShieldRegenStartTime = 10,

ShieldSize = 26,

ShieldVerticalOffset = -3,

},

},

 

This section controls the health and defenses of the unit. ArmorType is either one of three types in game. ‘Light’, ‘Normal’, & ‘Heavy’. Pretty simple. Health & MaxHealth are the health of the unit and when it runs out the unit dies. RegenRate is the health per second the unit regains over time as an auto repair.

 

The shields are relatively simple. OwnerShieldMesh & PersonalShield only deal with personal mesh shields. EnergyDrainRechargeTime is how long it takes the shield to try and kick back on if you’re low on Energy. Health is of coarse the shields health. RechargeTime I believe is how long it takes the shield to go to full health if powered down. RegenRate is how much it recharges per second when it’s not taking damage. RegenStartTime is the time delay since the last shot hit the shield before the shield attempts to recharge. Size controls how big of a bubble the shield creates. VerticalOffset allows you to adjust where the center of the shield is, this just helps with centering of the shield on the unit (as the bubble is a sphere).

 

Description = ‘<LOC uea0102_desc>Interceptor’,

 

This is essentially the unit’s description. The link code points to another file where the full in game description is stored.

 

Display = {

Abilities = {

‘<LOC ability_submersible>Submersible’,

‘<LOC ability_manualbuild>Manual Build’,

‘<LOC ability_manuallaunch>Manual Launch’,

},

Mesh = {

IconFadeInZoom = 130,

LODs = {

{

LODCutoff = 100,

ShaderName = ‘Unit’,

},

{

AlbedoName = ‘ues0304_lod1_albedo.dds’,

LODCutoff = 215,

ShaderName = ‘Unit’,

SpecularName = ‘ues0304_lod1_specteam.dds’,

},

},

},

PlaceholderMeshName = ‘UXS0001’,

SpawnRandomRotation = false,

UniformScale = 0.05,

},

 

This section is an irritatingly complex section that I don’t want to go into detail on. So I will present the major items. Abilities section controls the little abilities blurp you get in the lower left of the screen (by default) about what the unit can do. The Mesh section contains the LOD Cutoff and which files to switch to when you zoom out. As you can see this is where LOD1 files are called. The placeholder mesh refers to another unit and I have not ever seen it different between units. I have not seen SpawnRandomRotation as true on any unit so far. UniformScale is a nice and easy way to resize the model. On most units you will see it as a decimal because the original model size is so big it would never fit in game.

 

Economy = {

BuildCostEnergy = 30000,

BuildCostMass = 2400,

BuildTime = 1800,

MaintenanceConsumptionPerSecondEnergy = 2000,

BuildableCategory = {

‘BUILTBYCOMMANDER UEF’,

‘BUILTBYTIER2COMMANDER UEF’,

‘BUILTBYTIER3COMMANDER UEF’,

},

MaxBuildDistance = 10,

MaxEnergyUse = 5000,

MaxMassUse = 500,

NaturalProducer = true,

NeedToFaceTargetToBuild = false,

ProductionPerSecondEnergy = 10,

ProductionPerSecondMass = 1,

StorageEnergy = 2500,

StorageMass = 400,

TeleportEnergyMod = 0.5,

TeleportMassMod = 0.038,

TeleportTimeMod = 0.00005,

RebuildBonusIds = {

‘ueb3104’,

},

},

 

This is a slightly large category but you won’t see most of this on most units. Cost Energy & Mass deal with the units overall cost. BuildTime is a combination of a few things. It is the time in seconds it takes for the unit to be built multiplied by the builder’s build rate that is responsible for constructing it. MaintenanceConsumption is the cost per second in energy the unit uses for things like Stealth, Cloak & Radar.

 

BuildableCatagory refers to the “categories” section above to determine what units can be built. Max Energy/Mass use is the maximum this unit can use per second. You rarely hit this unless you’re working on a large project. ProductionPerSecond refers to the mass or energy this unit can create (Power Gens, Mass Fabricators). Storage is of coarse storage for mass and energy. Teleport is more or less left over script though it is still used, just not by most units so I will not explain the equation used. RebuildBonusIds refer to the bonus resources you get for building this on top of the wreckage of previous structure.

 

Enhancements = {

 

},

 

This section deals with the code for unit upgrades & enhancements. Since I am not going to be dealing with them (as they are a pain in the butt) in this tutorial I will not speak much about them.

 

Footprint = {

SizeX = 1,

SizeZ = 1,

},

 

This section deals with the footprint size of the building when you’re placing it on the ground.

 

General = {

Category = ‘Command’,

Classification = ‘RULEUC_Commander’,

CommandCaps = {

RULEUCC_Attack = true,

RULEUCC_CallTransport = true,

RULEUCC_Capture = true,

RULEUCC_Guard = true,

RULEUCC_Move = true,

RULEUCC_Nuke = false,

RULEUCC_Overcharge = true,

RULEUCC_Patrol = true,

RULEUCC_Pause = true,

RULEUCC_Reclaim = true,

RULEUCC_Repair = true,

RULEUCC_RetaliateToggle = true,

RULEUCC_SiloBuildNuke = false,

RULEUCC_SiloBuildTactical = false,

RULEUCC_Stop = true,

RULEUCC_Tactical = false,

RULEUCC_Teleport = false,

RULEUCC_Transport = false,

},

ToggleCaps = {

RULEUTC_IntelToggle = true,

RULEUTC_CloakToggle = true,

RULEUTC_StealthToggle = true,

RULEUTC_ShieldToggle = true,

RULEUTC_WeaponToggle = true,

},

FactionName = ‘UEF’,

QuickSelectPriority = 1,

TechLevel = ‘RULEUTL_Experimental’,

UnitWeight = 1,

},

 

This is a very large section so I will do the other parts first and then the command & toggle caps. First the Category, Honestly I never looked at this section and just duplicated what was there on similar units. Classification again I duplicated from similar units so I am not sure what it’s used for. FactionName is again what faction this unit belongs to. TechLevel is a rule set of some form for the unit for which I have only really seen Basic, Secret, & Experimental. UnitWeight is the cost to your Population Count this unit requires. While SupCom uses 1 for every unit in the game you could essentially make a unit that takes more than 1 population. Thus restricting how many of these can be built when playing low population limit games.

 

Now the command caps… yay. Most of them are listed in the example which makes it easy. These are the command buttons that show up when you select the unit. The toggleCaps are toggleable commands such as shields and stealth that can be turned on or off. These usually have a power requirement if it is set up in the economy section.

 

Intel = {

OmniRadius = 200,

RadarRadius = 600,

ReactivateTime = 10,

ShowIntelOnSelect = true,

SonarRadius = 75,

VisionRadius = 16,

WaterVisionRadius = 24,

FreeIntel = true,

},

 

The Intel section controls the sight of things. Omni, Radar, Sonar, Vision, Water Vision, Stealth, Sonar Stealth, & Cloak can all have ranges set in this particular section of the blueprint. Cloak & Stealth also have the ability to have a true/false setting so it just affects that unit rather than a range. FreeIntel makes the unit get its Intel for free rather than using the maintenance cost and requiring a togglecap button.

 

Interface = {

HelpText = ‘<LOC uea0102_help>Interceptor’,

},

 

This controls the help information for the unit. Very similar to the description section above.

 

LifeBarHeight = 0.075,

LifeBarOffset = 0.35,

LifeBarSize = 0.65,

 

These sections deal with the units life bar. The Height and Offset deal with positioning and the Size deals with how wide the bar is. Other then that not much to say.

 

Physics = {

BackUpDistance = 0,

BankingSlope = 0,

BuildOnLayerCaps = {

LAYER_Air = false,

LAYER_Land = false,

LAYER_Orbit = false,

LAYER_Seabed = false,

LAYER_Sub = true,

LAYER_Water = false,

},

CatchUpAcc = 10,

DragCoefficient = 0.2,

Elevation = -2,

MaxAcceleration = 0.85,

MaxBrake = 5,

MaxSpeed = 2.55,

MaxSpeedReverse = 0,

MaxSteerForce = 5,

MeshExtentsX = 1,

MeshExtentsY = 0.75,

MeshExtentsZ = 0.45,

MinSpeedPercent = 0,

MotionType = ‘RULEUMT_SurfacingSub’,

TurnRadius = 30,

TurnRate = 25,

},

 

 

The physics section deals with the unit’s movement. I honestly haven’t needed to change much here but nonetheless. BuildOnLayerCaps deals with where this unit can be built. In this case a submarine built underwater. Elevation is used to set the driving elevations while on the surface. Hovercraft will sit higher than land level while naval units will sit lower so they are sitting in the water rather than on it. Max Acceleration is how fast the unit can get up to its Max Speed. And braking is the reverse of that. MeshExtend seems to deal with build effects when a unit is being built. TurnRate is how fast the unit can change direction. MotionType deals with how the unit moves and what restrictions the unit has to its movement. It is also the reason if you spawn a ship on land it slowly dies. Buildings also have a skirt commands that handle the tarmac effects.

 

SelectionSizeX = 0.65,

SelectionSizeZ = 0.8,

SelectionThickness = 0.6,

 

These fields control the size and thickness of the brackets that appear around a unit when you select it.

 

SizeX = 0.2,

SizeY = 2.7,

SizeZ = 0.2,

 

These affect the model size directly. While the previously mentioned Uniformsize essentially modifies all 3 of these at once you can use these to specicily stretch the model in one direction or another.

 

StrategicIconName = ‘icon_structure3_intel’,

StrategicIconSortPriority = 225,

 

These commands deal with the strategic icon that’s created when you zoom out. Unfortunately I have yet to take the time and track down all the files they are tied to so my information on them is very limited.

 

Veteran = {

Level1 = 50,

Level2 = 100,

Level3 = 250,

Level4 = 500,

Level5 = 1000,

},

 

This is the section that determines how many kills are needed before the ventrency buffs are applied. Pretty ridiculous counts considering how long a unit actually lives in this game.

 

Well so far we have gotten through all the basics of the unit’s Blueprint file. Unfortunately now we come to the section that is pretty much as long in itself as all the information previously covered. That’s right, it’s the Weapon Section. Oh joy and shoot me now.

 

Weapon = {

{

 

},

{

 

},

},

 

The nightmare of a section unfortunately. In the following “pages” I will be going over the specific fields of this section of a units blueprint file. The weapon that I am going to be using as an example and breaking down SHOULD NOT be used on anything in game as it is a combination of commands found and used. I will be using the same format that I have used so far in this tutorial. Piece of code followed by description of what it does. Keep in mind that this code is all found inside one of the sets of sub brackets shown above. The reason the above example has 2 sets of sub brackets is to show how multiple weapons would be organized. And without further procrastinating…

 

AimsStraightOnDisable = true,

 

This line tells the weapon to idle strait ahead of it if it is disabled. Turrets will sometimes track even if they have been disabled by a script.

 

Audio = {

 

},

 

Same as the unit’s audio info only this one is for the weapon effects.

 

BallisticArc = ‘RULEUBA_LowArc’,

 

This is the arc that a weapon travels to its target. The only other options are HighArc & None depending on the type of weapons. For examples of that they do. T2 Artillery uses LowArc, T3 Artillery uses HighArc, & Beam/Missile Weapons use none.

 

BeamCollisionDelay = 0.1, # Beam

BeamLifetime = 0, # Beam

 

BeamCollisionDelay is how much of a delay there is between when the beams damage is actually applied to the target. BeamLifeTime is the amount of time the beam exists on the field.

 

Buffs = {

 

},

 

This is exactly the same as the unit’s version but usually handles buffs to damage based on veteran bonuses.

 

CollideFriendly = false,

 

Simply put… Friendly Fire Anyone?

 

ContinuousBeam = true, # Beam

 

This is what causes a beam to remain on when firing when it is pointed at a valid target.

 

Damage = 300,

DamageRadius = 1,

DamageType = ‘Normal’,

 

Damage is how much damage is done to the target when it hits. Damage Radius is the splash damage that is caused. DamageType, well can’t say much I have only seen it as Normal.

 

DisplayName = ‘Gauss Cannon’,

 

Honestly I have not figured out what this references too as it has never really come up.

 

FireTargetLayerCapsTable = {

Air = ‘Land|Water|Air|Seabed|Sub’,

Land = ‘Land|Water|Air|Seabed|Sub’,

Water = ‘Land|Water|Air|Seabed|Sub’,

Seabed = ‘Land|Water|Air|Seabed|Sub’,

Sub = ‘Land|Water|Air|Seabed|Sub’,

},

 

This section determines what the weapon can shoot at. As you can see I expanded it with all the options available even though most weapons can’t’ shoot at everything.

 

FiringRandomness = 0.35,

FiringTolerance = 2,

 

Firing Randomness deals with the inaccuracy of the weapon over longer ranges. FireingTolerance is used as a firing assist system that allows the weapon to fire before it’s perfectly lined up on the target. I believe it is there to assist slower tracking turrets in being able to shoot properly.

 

Label = ‘FrontTurret01’,

 

This is the weapons label and is required for it is referenced by the units script file to determine various firing effects when the weapon shoots. This is how the script file identifies the weapons in the blueprint.

 

MinRadius = 80,

MaxRadius = 80,

 

Min & MaxRadius are used to put a hard cap on the weapons minimum and maximum range. However this game uses rather realistic ballistic systems so make sure the weapon has the velocity to throw the object that far.

 

MuzzleSalvoDelay = 0,

MuzzleSalvoSize = 1,

MuzzleVelocity = 23.5,

 

MuzzleSalvoDelay is the delay between salvo shots. MuzzleSalvoSize is the number of shots that are fired each time the weapon triggers. Between these two you can create shotgun or burst fire weapons using rate of fire as the delay between bursts. MuzzleVelocity is how fast the shell leaves the muzzle. This is used to get the bullet to fly far enough to reach max range.

 

ProjectileId = ‘/projectiles/TDFGauss01/TDFGauss01_proj.bp’,

ProjectilesPerOnFire = 1,

 

The projectile ID points to the blueprint file for the projectile being fired by this weapon. Beams do not have this but every other weapon does. Projectiles have their own sets of stats and their own script files, so replacing them can sometimes have amusing results. The ProjectilesPerOnFire is a useless and unneeded item according to GPG.

 

RackBones = {

{

MuzzleBones = {

‘Front_Turret01_Muzzle01’,

},

RackBone = ‘Front_Turret01_Barrel01’,

},

{

MuzzleBones = {

‘Front_Turret01_Muzzle02’,

},

RackBone = ‘Front_Turret01_Barrel02’,

},

},

 

These are the rack and muzzle bones used by this weapon. I am not going to get into the detailed functionality of how the interact specifically as that is easily available by looking at other blueprints.

 

RackFireTogether = true,

RackRecoilDistance = -1.2,

RackReloadTimeout = 0,

RackSalvoChargeTime = 0,

RackSalvoReloadTime = 0,

RackSalvoSize = 1,

RackSlavedToTurret = true,

 

RackFireTogether basically asks if every muzzlebone on that rack fires as a single volley each time the weapon fires. A Good example is the UEF Battleship’s main guns. RackRecoildDistance is how far back the rack recoils when it fires. RackReloadTimeout is the time before the rack will reset if it didn’t fire all muzzles.

 

RateOfFire = 0.16666666,

TargetCheckInterval = 3,

 

RateofFire is how fast the weapon fires and is displayed as shots per second. The max this can be set to is 10 which is 10/sec. The TargetCheckInterval is how often it checks for a new target.

 

TargetPriorities = {

‘SPECIALHIGHPRI’,

‘COMMAND’,

‘NAVAL MOBILE’,

‘SPECIALLOWPRI’,

‘ALLUNITS’,

},

 

These are the target priorities and which order the unit automatically picks its targets unless given something to specifically shoot at.

 

TargetRestrictDisallow = ‘UNTARGETABLE’,

 

This is where you can put target categories that are not allowed to be shot at.

 

TrackingRadius = 100,

 

This is the radius that the weapon starts to track the target at.

 

TurretBoneMuzzle = ‘Front_Turret01_Muzzle01’,

TurretBonePitch = ‘Front_Turret01_Barrel01’,

TurretBoneYaw = ‘Front_Turret01’,

 

TurretBoneMuzzle is the main muzzle bone that will be used for aiming of the weapon. BonePitch is the bone that is used to rotate the up and down movement of the weapon turret. BoneYaw is the bone that is used for left to right movement of the turret.

 

TurretDualManipulators = false,

 

Does this unit need multiple manipulators? This is used mainly on bots with arm weapons.

 

TurretPitch = 10,

TurretPitchRange = 20,

TurretPitchSpeed = 30,

TurretYaw = 0,

TurretYawRange = 120,

TurretYawSpeed = 45,

 

These lines control the default resting place for the turret, the angle range of movement and the speed of movement the turret can use when aiming.

 

Turreted = true,

 

Simply is this weapon in a turret?

 

That’s about all I am going to cover as it handles most of the basics of the weapons file. There is quite a bit more that is not listed but this should allow you to manipulate most of the weapons information at will. I guess that section wasn’t as bad as I though it would be. Anyway on to the next chapter.

 

 

 

 

CHAPTER 4 – Editing Existing Units

 

SupCom uses a merge system when it comes to editing the existing blueprint files that allows you to merge in new changes to existing units. There are a few ways to do this though they are all pretty much the same. All of these require that you create a blueprint file in your mod folder. The only real difference between the different ways I will show you is organization.

 

Merging Blueprints Type One. This is done by creating a mod_units.bp file inside your mod folder. Basically you just create this file by creating a blank text file and changing the extension to .bp which is probably the quickest. After that you copy in data from the units original blueprint (Use identification steps from section one to locate the original units information in your mod workspace) and make the changes you wish to make. Here is a small sample.

 

UnitBlueprint {

Merge = true,

BlueprintId=”uaa0310″,

 

Defense = {

RegenRate = 1,

Shield = {

OwnerShieldMesh = ‘/mods/ExavierCZAR/units/uaa0310/uaa0310_personalshield_mesh’,

ShieldEnergyDrainRechargeTime = 2,

ShieldMaxHealth = 5000,

ShieldRechargeTime = 90,

ShieldRegenRate = 34,

ShieldRegenStartTime = 60,

ShieldSize = 28,

ShieldVerticalOffset = 0,

PersonalShield = true,

StartOn = true,

},

},

}

 

As you can see this is part of the code from my mod’s CZAR Buff. I didn’t include everything as to keep the example short. The required parts of this file is the Merge & BlueprintId sections near the top. These are required as it tells the game which files to merge this into. The BlueprintId is simply the unit ID for the original unit. After the final closing bracket at the end you can ad multiple entries of UnitBlueprint to this file each targeting changes to a different Unit ID. An Example of this is below.

 

UnitBlueprint {

Merge = true,

BlueprintId=”uab3104″, # Aeon Omni Array

 

Intel = {

OmniRadius = 75,

RadarRadius = 400,

ReactivateTime = 5,

ShowIntelOnSelect = true,

SonarRadius = 0,

VisionRadius = 50,

},

}

UnitBlueprint {

Merge = true,

BlueprintId=”urb3104″, # Cybran Omni Array

 

Intel = {

OmniRadius = 75,

RadarRadius = 400,

ReactivateTime = 5,

ShowIntelOnSelect = true,

SonarRadius = 0,

VisionRadius = 50,

},

}

 

Unfortunately if you use this route for extensive changes to dozens of units this file will get very long and probably become a pain in the butt to search through. To help wit this you can actually use multiple mod_units.bp files and name them something else. Heck you can even name them after the original unit file and as long as the merge & blueprint ID fields are correct it will work fine. This creates several more files in your mod folder but otherwise makes it easier to locate a specific unit if you need to make a correction.

 

Another thing I should note. You do not need to include all the code in a section in order to modify the unit. Take the CZAR Buff code in the first example. The Defense section also contains the Health & MaxHealth values of the unit. Since I am not changing those I did not need to include them in this file. The only thing you have to be careful of is making sure that your opening & closing bracket sets match up. This is where the indentations come in handy (even if they aren’t mandatory).

 

Modding projectile is done pretty much the same way as above the only difference is the commands that are used.

 

ProjectileBlueprint {

Merge = true,

Source = ” /projectiles/TIFMissileNuke01/TIFMissileNuke01_proj.bp”,

 

Economy = {

BuildCostEnergy = 240000,

BuildCostMass = 24000,

BuildTime = 480,

},

}

 

The Source section replaces the BlueprintID because the game doesn’t tie the projectile files to an ID. So instead we have to specify the direct path to the projectile blueprint we want to modify. This example happens to be the Terran (UEF) Strategic Nuclear Missile, land launched. The easiest way to find out what blueprint is used by a unit is to look in the Weapon section of the unit’s blueprint. You will find a projectileID with a path similar to the one in the example.

 

I will note that I strongly disagree with modifying existing projectiles unless it is something simple like the above example. Mainly because in the case of most projectiles (Missiles & Beams mainly) the blueprint file doesn’t handle the important parts. That and Beams don’t use a blueprint file anyway. I prefer to just create my own projectiles and link them up. That will be covered in the following sections.

SECTION 3 – Creation of a New Unit

 

Terms from Previous Sections:

-Mod Workspace – Folder Created in chapter one to hold unpacked versions of the games scd files.

-Root Directory – Location where SupCom was installed to by default on your computer.

-Mod Folder – Folder created in Root/mods/ that your mod will be run from and created in.

 

CHAPTER 5: Basic Creation for Game Recognition

 

This chapter is going to be dedicated to creation of a new unit. Just a heads up that when I refer to “New Unit” I am referring to how the game sees it. This tutorial is in no way going to cover creation of new models, textures, or animations. For this creation we are going to use the Cybran Siren Class Cruiser as our base. If you want to use new models that’s fine as it’s pretty much as simple as replacing the model files with the new ones.

 

First thing we need to do is find our base unit in our Mod Workspace. This is simple really as we can use the naming system or website I provided in Section 2 to find the Unit ID. In this case we are looking for URS0202 in the /units/ folder of our mod workspace. We want to then navigate to our mod folder and copy this entire folder over into the /units/ folder we created back in Chapter 2.

 

Like So:


 

Once this is done we need to decide on a naming scheme for our new content. As you can see in the picture above there was already another unit in that folder. EME30001 is a unit out of my Unit Additions mod which happens to be my UEF Mobile Tactical Defense. I used a naming scheme similar to GPG in that essentially it breaks down to Exavier Macbeth Earth Techlvl UnitNumber(0001). This is not mandatory but it’s what I chose to do. A few pointers, The in game cheat menu (Alt+F2 with cheats enabled) which can be used to spawn units in game without having to build them groups the units into categories based on the first 3 letters of the Unit ID. So for my mod EME (Earth), EMC (Cybran), & EMA (Aeon) will be grouped together. I think this is one reason GPG used such an odd way (URS = Cybran Naval) of naming their units.

 

In truth through the name is totally up to you. I would however recommend ONLY letters & numbers be used for your naming scheme. No Spaces, dashes, or special characters. The reason is that this Unit ID will be used in allot of places and having those extra special characters can lead to some amusing glitches that will make you break a stress ball.

 

For this tutorial & example I am going to simply use the naming system I established for my mod. Partially due to the fact that it’s become a habit after making 30 units lol. So for the purpose of this tutorial the unit ID I intend to use is EMC30010. Now that we have that we need to change the URS0202 folder’s name to our current ID. After that we want to enter that folder.

 

Inside the folder you will see several files. For an idea of what these files do please see the beginning of Section 2 where it is listed. For now I would like you to rename these files with out new Unit ID as shown below.

 

Before:


After:


 

Our next step after that is done is correcting the new IDs in the script and blueprint file. We will do the script first as it is essentially two lines to change. Don’t worry about the other stuff in the script file for now we will get to that shortly. Change these two lines in the script file to match our new unit ID.

 

From:

URS0202 = Class(CSeaUnit) {

TypeClass = URS0202

 

To:

EMC30010 = Class(CSeaUnit) {

TypeClass = EMC30010

 

Then save the file and exit. The next file we need to make changes to is the blueprint file. In this file we need to change several lines however instead of copying the entire blueprint into this tutorial I am just going to copy the line that deals with it (you can pretty much use the find function of notpad to match words if needed).

 

Description = ‘<LOC urs0202_desc>Cruiser’,

Animation = ‘/units/urs0202/urs0202_asink.sca’,

Animation = ‘/units/urs0202/urs0202_asink02.sca’,

Animation = ‘/units/urs0202/urs0202_asink03.sca’,

AlbedoName = ‘urs0202_lod1_albedo.dds’,

SpecularName = ‘urs0202_lod1_specteam.dds’,

UnitName = ‘<LOC urs0202_name>Siren Class’,

HelpText = ‘<LOC urs0202_help>Cruiser’,

 

These lines need to be changed in order for the game to recognize specific aspects of the unit properly. While most of them are strait forward, the Animation ones need to be changed in a slightly different manner to work. Below is how they need to be changed to reflect the new unit.

 

Description = ‘<LOC EMC30010_desc>Cruiser’,

Animation = ‘/mods/<modfolder>/units/EMC30010/EMC30010_asink.sca’,

Animation = ‘/mods/<modfolder>/units/EMC30010/EMC30010_asink02.sca’,

Animation = ‘/mods/<modfolder>/units/EMC30010/EMC30010_asink03.sca’,

AlbedoName = ‘EMC30010_lod1_albedo.dds’,

SpecularName = ‘EMC30010_lod1_specteam.dds’,

UnitName = ‘<LOC EMC30010_name>Siren Class’,

HelpText = ‘<LOC EMC30010_help>Cruiser’,

 

You will notice that in the animation ones we had to change the path to include both the mods folder as well as our mod folder’s name. The reason for this is that if you do not have that on there the game will automatically attempt to find this information inside the units.scd file. Which of coarse means its not going to work correctly? After that is done we can save the blueprint file and exit.

 

Now we need to get four more files to make this unit recognizable in game properly. We need to go back into our mod workspace and then go into the following folders: textures/ui/common/icons/units. In here you will see a lot of icons. What these are for are the build & selection icons that show up in game. Without these you will get a little blue placeholder icon. Now what we need to do is find the four of them that start with URS0202.

 

URS0202_build_btn_down.dds

URS0202_build_btn_over.dds

URS0202_build_btn_up.dds

URS0202_icon.dds

 

We then need to copy them into the same folder that has our unit’s blueprint file (where we just renamed all the other files). We need to rename these four files in the same fashion. So afterwards this is what our unit’s folder will look like.

 


 

Once that has been done we should now be able to boot up the game, Select our mod from the mod manager, & get into the game without any errors. Since all we did is create a duplicate of the unit you will find the above unit in the Cybran Tech 2 Naval Factories build list. You will see two Cybran cruisers, one of them is ours. You can at a later date open the build Icons (last 4 files we changed) in a graphics program such as Photoshop and edit them so they look different then the default cybran cruiser. If you happened to change the UnitName or Description & helptext to something else then the new names would also appear in game when you mouse over them.

 

That pretty much finishes up this chapter. Feel free to go in and adjust specific properties in the units blueprint file to your hearts content. If you need to know what is what then have a look back in Section 2 of this guide as I broke down most of the lines that you will see in the units Blueprint File. Next chapter is going to be a brief look at the script file.

 

Advanced Note: For those trying to use new models & textures you could follow this same process with very little differences. The biggest changes would be deleting the LOD1 files (unless you created a set for your model) and overwriting the LOD1, Albedo, normalsTS, & SpecTeam with your own versions. After that it simply a matter of changing the weapon bones (if your unit had weapons) to match the bones on your custom model. That and changing the UniformScale so that your model shows up the right size in game (trial & error Style).

CHAPTER 6 – Unit Script File Basics

 

This is not going to be a very long chapter as I am starting to get closer & closer to burning out writing this guide. Basically what I am going to do here is show you the script file for the unit we created (or duplicated) in the last chapter and explain what each piece of the script refers to. This will help both for later parts of this tutorial (New weapons) as well as showing you pathing calls for if you decide to write or borrow scripts from other units. May help save you on some of the script errors that are annoyingly common when doing this.

 

So here we begin first with the script file:


 

As you can tell I have highlighted a few things in this file. This is to make it easier to point out what I am referring to. Pretty much all script files in the game are formatted exactly like this. They have the local calls at the top and then the actual script below that. The local calls are basically global variables for this specific script and are used throughout it.

 

So we will start at the top…

 

RED: This is the unit’s class which is pulled from the cybranunits.lua file. Usually this does not mean much for the unit as most units do not have any special properties in that file. But the reference is still there. It also is required in the script files to refer to this unit. I have highlighted al references of it. If you borrow scripts from another unit for extra properties on this one be sure that you change these class calls or the script will crash.

 

PURPLE: This line is essentially a shortcut and nothing more. As you can see in the three lines under it those locals use this one as part of its path calls. Not all units will have a similar setup to this one in that regard as it seems to depend on the original scripts author how many of these references are used. I have seen some units that just use the import command for every weapon.

 

BROWN: This I will touch one a little bit but will reference later on. This is the import path for the cybranweapons.lua file. Essentially without this your weapons have no visual effects. As you can see they are making CybranWeaponsFile a shortcut to this path. So whenever you see that shortcut it is referencing this file.

 

BLUE: This is the the shortcut that was created for a specific weapon inside the CybranWeapons.lua. Highlighted lower shows you where it connects to in order to function. You will notice that the other two shortcuts below this one use the same thing but reference different weapon types.

 

GREEN: This is the AAGun reference for the script. It also references the nanoDartWeapon for its effects package. While not shown this actually ties back into the Blueprint File for the unit, specifically the “Label” line in the weapon section. This is how the game translated from Blueprint, to weapon, to effects package (usually muzzle effects).

 

CYAN: This is the GroundGun entry into the Blueprint file, though that doesn’t exactly describe what this weapon is does it. Honestly the labels do not matter as long as they match between Blueprint & Script.

 

In this case you will see both Green & Cyan appear multiple times in the script. The reason is that this is the script that controls the Cybran Cruisers ability to switch its AA Missiles (AAGun) into AntiGround Missiles (GroundGun). You will also notice that it does so by disabling one and enabling the other. Essentially making it look like it is a single weapon system in game. Rather clever of them hu? 😛

 

For the most part that’s all I am going to touch on for the script file for now. I will probably bring this image back up later when it comes to making new weapons/projectiles work as we will be editing the locals for pathing issues.

SECTION 4 – Creation of New Weapon Systems

 

Terms from Previous Sections:

-Mod Workspace – Folder Created in chapter one to hold unpacked versions of the games scd files.

-Root Directory – Location where SupCom was installed to by default on your computer.

-Mod Folder – Folder created in Root/mods/ that your mod will be run from and created in.

 

CHAPTER 7 – Explanation of the Weapons File Structure

 

Rather than just jump right in and let you figure out how to unravel the weapon annoyances I figured I would give you a quick rundown of all the files we will be touching in the next couple of chapters. The reason for this is I want to make sure you understand how things are linked and what references what before we sit down as start creating things. Though in truth it’s very easy, it doesn’t appear that way to begin with 😛

 

In the previous section I showed you the script file of a unit and showed you how it interacts with itself. In this section we are going to show you how those same commands tie to other files to form a nice web of interaction. For this section we will be working with several files including three blank slate files that are provided with this tutorial.

 

Ok basic rundown of the way things link together.

 

EMC30010 Blueprint:


 

This shows the part of the unit’s blueprint file that holds the weapons information. The red box indicates the part of the file that ties to the units script file (EMC30010_script.lua). The blue box is what points to the projectile file for this weapon. Changing this will change the weapon that is spawned when this is fired. NOTE: Beam Cannons do not have the blue field in the weapons information as they have no Projectile.

 

EMC30010 Script File:


 

This part shows the units script file that deals with weapons. The red box ties back to the label in the previous image. The blue box is a local reference for the weapon. The purple is another local reference for this weapon. The green box is what links to the weapon.lua file. While this one references the cybranweapons.lua file we will be creating out own later. Note that while later images will not show it, this file is looking for a CDFProtonCannonWeapon entry in the cybranweapons.lua file. From this entry is where it pulls muzzle effects.

 

Weapons LUA:


 

This is a look at the top of a weapons file. This one happens to be the blank slate I provided with this tutorial. In red & blue you will see some of the common classes used for the weapons. The red boxed one we won’t worry about because your editing will not likely go any deeper than this. But this one is used for pretty much all cannon based weapons. In green are the ties that link to the collision beam files. These files handle all beam weapons. The CustomCollisionBeamFile (bottom of the 3) refers to my blank slate that I will be using in the beams tutorial later. Note the destination path. You would replace TesTMod with whatever your mod folder is called.

 

DefaultCollisionBeams LUA:


 

This file is at the far end of the linking paths and as such isn’t much to show. I provide it just so you can see what the previous image links to via the green boxes. I will cover this file in much better detail in the beam tutorial.

 

Projectile Script File:


 

We now backtrack a bit. The above image is from a projectile I pulled out of my mod collection just for example. This would be found with the projectiles blueprint so you would look in the path shown in the first image. The red parts are essentially the class identifier to help determine what effects file to use in the projectiles.lua. The blue box is what points to the projectiles.lua file where it can find this projectiles effects information (Bullet trails & such).

 

Projectile LUA:


 

This image shows you the projectiles.lua file. Like the weapons file this will have several references in it and you will see them in the projectiles creation tutorial. The red box is basically a list of the available weapon classes that a projectile can belong to. Essentially this is the last line on the trail from the blueprints file that deals with projectiles.

 

Now the question is did that make any sense to you? I hope so. Anyway from here the next chapter we will be breaking down and creating a projectile and mounting it to our Cybran Cruiser. The chapter after that we will be building a Beam Cannon to mount on it.

CHAPTER 8 – Creation of a Projectile Weapon

 

I well its about time I stop running on and on and just get down to how to create projectiles and weapons. Wouldn’t you agree? Ok then. In truth through we aren’t exactly going to create a new projectile. What I am going to do is walk you through the process with an existing projectile so you know how it’s done. Then you’re free to experiment with the effects files all you like afterward.

 

Well let’s start with the files themselves. Since we are going to use the Cruisers existing weapon as our base we will need to track down its files. We can do this easily by following the BrojectileID field in the blueprint.

 

ProjectileId = ‘/projectiles/CDFProtonCannon02/CDFProtonCannon02_proj.bp’,

 

Now just like we did with the unit originally we want to copy the projectiles entire folder from our mod workspace into our mod folder’s /projectiles/ folder. And just like the units we need to rename them to something else. I tend to still follow my same format. So for this projectile we will call it EMCProtonCannon01. And we will want to rename the files inside the folder to match.

 

The blueprint file is very strait forward in itself so there is no real need for me to go over it. The blueprints script we have to adjust a little. Now this is only my recommendation but it does make sorting things easier. For every projectile add the word “projectile” to the end of its name for the Class. And for every Weapon call (say in unit’s script) we add the word “Weapon” to the end. The following is an example of what we want to change the script file to read.

 

Before:


After:


 

The red parts of the blueprint we just use the projectileID and nothing more. The blue parts we added the “Projectile” to the end of it. Again not mandatory (though all those have to be the same) but preferred when it comes to finding script errors later. The green part I forgot to change before the screenshot but it needs to point to our custom projectiles file which would be located at:

/mods/<modname>/lua/blankprojectiles.lua

 

Some projectiles have other scripts that run in here but not too much. After that we move on to our weapons.lua file. Now if you’re using my Blank Slate file then it’s pretty much empty at the moment. So we need to go track down the information dealing with our base weapon so we will need to open the Cybranweapons.lua file in out mod workspace and find the entry for the CDFProtonCannonProjectile.

 

It will look like this:


 

We just copy that into our weapons file and change the text in the red box to match what we set in the projectile script file which was EMCProtonCannon01Projectile. That finishes that link. The effects are essentially the effects generated when this projectile hits something. The polyTrails are the weapon trails when this projectile flies through the air.

 

After that’s all saved we need to do a similar process for the weapons file. First let’s go to the units script file. Again I drag up an earlier image.

 

And here it is:


 

We will need to change it to represent this:


 

I marked the changes but basically we are changing the Class of the main gun to use our new weapon. We added a CustomWeaponsFile import reference that points to our weapons.lua file and have made sure that they link up correctly. The next thing we need to do is go into our Weapons.lua file as we need to copy something over. I want you to also open the Cybranweapons.lua from our mod workspace’s /lua/ folder. And we will need to look for an entry that says CDFProtonCannonWeapon.

 

It will look like this.


 

And of coarse change the CDFProtonCannonWeapon to EMCProtonCannonWeapon so that it is recognized correctly. After that you can adjust the muzzle flash emitters all you want. But that should give you a working custom weapon in game. Great isn’t it?

CHAPTER 9 – Creation of a Beam Cannon

 

Luckily this weapon system is just a modification of the previous weapon chapter so I will be building off that information. So how should we begin… Since I already have a Point Defense Beam in my test mods folder we will use that for our example.

 

The easiest way is to find a unit with a beam that you want to use. I stole mine off the CZAR which makes it rather easy. The units blueprint code you can probably decipher so I won’t dwell on it. In the script file you need to follow the path into the Aeonweapons.lua file and track down the beam. It will be this section.

 

AQuantumBeamGenerator = Class(DefaultBeamWeapon) {

 

We want to copy that section into our weapons.lua file so that it looks something like this. I highlighted changes I made to it:

 


 

After that we want to change the name (and remember the linking files mentioned in the previous chapter for the unit script this weapon will be mounted on). In this case I used PDLaserGrid. I know I violated my normal “Weapons” added to the end comment I had made earlier, but that’s cause this is still in development. The blue section points to the beam and the collision file. In the blank Slate this would be CustomDefaultCollisionBeamFile rather than ExavierCollisionBeamFile and would point to the blankdefaultcollisionfile.lua rather than exavierdefaultcollisionbeams.lua. You will also notice in the blue box the PDLaserGridCollisionBeam. This is referring to the beam in the default collision beams lua.

 

Also you will need to take the original BeamType link and match it up inside the defaultcollisionbeams.lua file in the /lua/ directory of our mod workspace. That will give you the beams code that will go in our own collisionbeams.lua file as shown below.

 

CollisionBeams File:


 

The red part is what I changed to match up with my Weapons file. The blue part is the code that controls scaling of the beam end effects to allow you to scale those as needed. The purple part points to the emitter I used to generate the beam. These can be found in our mod workspaces /effects/emitters/ folder. You would need to copy one of them to a similar folder structure (like I have done) and then edit its thickness in the file to scale the size of the beam down. Be sure to note when linking to this file. All lowercase letters are mandatory for this path otherwise the beam will fail to load.

 

But having that all set up you should have a working beam in game. I have to apologize if the tutorial seems rushed at this point because in truth it is. This is my second attempt at writing this and it has gotten quite far. Unfortunately I am about burned out but I believe I got all the basics in here so far. The next chapter will be the last and will cover packaging of your mod.

SECTION 5 – Packaging & Deployment

 

Terms from Previous Sections:

-Mod Workspace – Folder Created in chapter one to hold unpacked versions of the games scd files.

-Root Directory – Location where SupCom was installed to by default on your computer.

-Mod Folder – Folder created in Root/mods/ that your mod will be run from and created in.

 

CHAPTER 10: Packaging & Distributing Your Mod to others

 

Once you have your mod working correctly its time to package them up and ship them out. Now this as much as any other has several methods for which a mod can be packaged and distributed. I am only going to cover the two ways for distribution that I know work properly. I realize that the most recent patch is suppose to allow for an “approved” way that uses the My Documents folder. I do not intend to cover this because I personally have not been able to get it to work. Now that that has been said I will go over the other methods that are tried and true.

 

The most basic way is to compress your mod folder and everything in it into a zip file, put it up on a site that allows you to host it. People can then download it and unzip it in their /mods/ folder and it will show up in game in the Mod Manager.

 

The alternative way is a little different but is my preferred way as it prevents tampering of the files unless purposely extracted. To do this you zip up your /mods/ folder and all its contents (minus of course any other mods you don’t plan to include) into an uncompressed zip file. You then change the file extension from .zip to .scd. After that you simply drop the scd file into your game data folder. For distribution you simply zip this scd file up with a readme & instructions to have the person who downloads it dump the scd file in their gamedata folder. This will then allow it to show up in the mod manager.

 

Again these are the two ways through which I know work and since I cannot make the GPG preferred way of packaging them work properly. Nor do I personally agree with the use of My Documents for distribution due to the way I have customized my own computers partitions.

 

Anyway that will conclude this tutorial. I hope you enjoy reading it because I absolutely despised writing it. Seriously, while I can write something like this I have to do it rapidly or I loose interest and move on to other projects. So if this tutorial seems rushed then that would be the reason, it was written in two days.

发表评论

Fill in your details below or click an icon to log in:

WordPress.com 徽标

您正在使用您的 WordPress.com 账号评论。 注销 /  更改 )

Google photo

您正在使用您的 Google 账号评论。 注销 /  更改 )

Twitter picture

您正在使用您的 Twitter 账号评论。 注销 /  更改 )

Facebook photo

您正在使用您的 Facebook 账号评论。 注销 /  更改 )

Connecting to %s

%d 博主赞过: