Here shall be displayed for general use, all of my tutorials, of which I will begin to create. I will also put up any really cool tutorials made by other people, if they're cool enough.

Index:

• Chapter One: Doors - Scroll down
• Chapter Two: The Scene - http://datarealms.com/forum/viewtopic.p ... 74#p202674
  
  • Updated for custom materials.
• Chapter Three: Attachables - http://datarealms.com/forum/viewtopic.p ... 11#p208811
• Chapter Four: New Person Guide - viewtopic.php?p=219542#p219542

Cool stuff:

• List of all Cortex Command Classes: http://cortex.pastebin.com/fd2a93ab
• List of all Cortex Command InstanceNames: http://cortex.pastebin.com/f254e2da6
• List of all Cortex Command variables: http://cortex.pastebin.com/f643cc5de
• List of all Cortex Command "Add" functions: http://cortex.pastebin.com/fe9d6281
• List of all files in Base.rte (In order of load): http://cortex.pastebin.com/f263e3207
• Glow Colors:

All tutorials in .doc format: (Thanks to Yoman987)


Tutorial help:

Variables are those words that hold values in CC. Pretty much all CC modding is changing variables around.
Arguments are what the variables hold. There can be many different kinds of arguments.
Example:

"AddActor" is a special function in CC code that allows you to add new things into the game.
"AHuman" is a CC class that is defined by the variables after it.
"InstanceName" is on a new line with an extra tab, because it is a variable belonging to the new "AHuman". "InstanceName" holds a string value.
"Person" is the string that you are giving to "InstanceName".
"Mass" is another variable for the new "AHuman". "Mass" holds a number value.
"12" is the number that you give to "Mass". The "AHuman" will now have a "Mass" of "12".

Glossary:

• Vectors have an X value and a Y value. They're used to position something in CC's 2D world. Often, they are based off of something else in the world, and so don't always refer to the exact same spot in the world all the time. Also, the direction that postive/negative X/Y sometimes changes.
  
  Code:

  SomeOffset = Vector
     X = -48
     Y = 50
• A Matrix is often used in CC for putting something at an angle. Angles are in degrees, so: 0 is East; 90 is North; 180 is West; 270 is South; 360 is East again. You can also put them in negative to go the opposite direction.
  
  Code:

  SomeAngle = Matrix
     Angle = 90
• "Ints" or integers are whole numbers. 1, 2, 3, 4... etc. You can't use decimals with ints. They can go negative, in most cases, however.
• "Floats" are like integers, but you can use decimals. The advantage of using an int over a float is that ints use less memory.
• Boolean numbers are either 0 or 1. They aren't really ints, because you can only have 0 or 1. They are used to show on (1) or off (0).
• Classes are the actual objects that CC is made of, and are sometimes used in arguments. There are lots of Classes in CC, but here are a few:nestedlistlol
  
  • Attachable is the most common class used as an argument. Attachables can be "attached" to practically any other object.
  • AEmitters are a kind of Effect, and can also be attached, much like Attahcables can, to most objects.
  • TerrainObjects are a kind of object that does not move. It can be placed in scenes, and so is used as an argument somwhat often.

Chapter One: Doors.

Doors are actors. They share some of the same variables as other kinds of actors.
Most doors consist of:

• One Attachable (The moving part)
• One Actor (The motor, or part that the door moves around)
• One Sensor (Attached to the actor, tells when the doors opens)

The ADoor actor has these unique variables:

• Door [Attachable]
• OpenOffset [Vector]
• ClosedOffset [Vector]
• OpenAngle [Matrix]
• ClosedAngle [Matrix]
• OpenClosedAngle [Matrix]
• OpenClosedOffset [Vector]
• DoorMoveTime [Int]
• ClosedByDefault [Boolean]
• ResetDefaultDelay [Int]
• SensorInterval [Int]
• AddSensor [Sensor]
• As well as all variables used by Actors

Most of this is pretty straight forward. I might go more indepth in the basics of offsets in a later tutorial. The most common problem people have with doors, however, is the Sensors.

The Sensor class has these unique variables:

• StartOffset [Vector]
• SensorRay [Vector]
• SkipPixels [Int]

This is how the sensor is created for the "Door Slide Short" ADoor:



This image should help you with figuring out how this stuff works. In the image example, I used the door from my Bridge Door mod (TroubledWaters.rte). The door, on sensing that an actor is on either side, lowers, and allows the actor to cross a gap.



Note: "Actors are only sensed when intersecting this line" That means that an atom from the actor has to physically be on one of the same pixels as the line. As long as an actor is in the line, the door will stay open. Also note that I should have used a straight line, like Data does in his Doors. If the line is at a diagonal like that, then an actor might crawl under the sensor on one side. It won't make much of a difference for small doors, but for big doors, that could be a problem.

Chapter Two: The Scene

Scenes are the places you go in Cortex Command. Cool people, like me, make scenes. Scenes are not made as often as regular mods, so if you make a good one, you're sure to be called "cool" or "amazing". I get that a lot, at least.

Lets go through this line by line. I think that will be helpful. Code tags take up too much space, so I'll just use the list format thing.

• AddScene = Scene

This creates a new Object of the Scene class and adds it to the list of scenes in the game.

• InstanceName = Prom Grounds

Names the scene. In this case, the scene will show up in the list as "Prom Grounds".

• LocationOnPlanet = Vector

This currently doesn't do anything noticable in the game, but probably eventually will correspond to the metagame map or something.

• GlobalAcceleration = Vector

X,Y vector. Most common gravity is positive Y, which is down. But if you're doing something really weird, you could, potentially, make it go in other directions.

• Terrain = SLTerrain

Terrain is a variable of Scene. This creates a new terrain of the SLTerrain class and assigns the Scene's terrain to it.

• InstanceName = Prom Terrain

Names the SLTerrain object. This doesn't show up ingame, it's just for referring back to if you want to use it again.

• BitmapFile = ContentFile
• Path = PromGrounds.rte/Scenes/PromGrounds.bmp

Assigns the BitmapFile variable of the SLTerrain to a ContentFile. Game gets the image for the terrain and converts it from mat palette colors to ingame materials. More on creating these images later.

• WrapX = 1

This means that if you go past the farthest right side of the scene, you'll be at the farthest left side, and vice versa. This is a boolean value.

• WrapY = 0

Same as above, only for the top and bottom.

• ScrollRatio = Vector

Effs stuff up if you mess with it, but if you really have to know, it changes the speed that the terrain scrolls ingame. Set the X to 2 and the ground will move twice as fast as the actors walking on it.

• BackgroundTexture = ContentFile
• Path = Base.rte/Scenes/Textures/DirtDark.bmp

Sets the texture of the background that shows when you dig through dirt.

• AddTerrainFrosting = TerrainFrosting

This adds a TerrainFrosting to the scene's list of terrain frostings.

• TargetMaterial = Material

Sets the material that you want the frosting to "frost" in/over.

• FrostingMaterial = Material

Sets the material that you want the frosting to be made out of.

• MinThickness = 5

Minimum length of the frosting. Straight up from target material. In pixels.

• MaxThickness = 7

Maximum length of the frosting.

• InAirOnly = 1

Allows you to decide whether the frosting will be allowed to be placed when there is another material in the way. Usually looks better with this on.

• AddTerrainDebris = TerrainDebris

Adds a TerrainDebris object to the scene's list of TerrainDebris. I'll show how to create one of these later.

• PlaceTerrainObject = TerrainObject

Adds a TerrainObject object to the scene's list of TerrainObjects. These are the "bunkers" and geology.

• PlaceSceneObject = Any class

This allows you to place any other objects that you want in your scene. Includes AHumans, ACDropships, and the brains.

• AddBackgroundLayer = SceneLayer

Adds a layer of background image to the scene's list of backgrounds. These will be displayed behind the BackgroundTexture, and in order from front to back in the same order that you add them. How to create these is described later.

To finish up, here's how you create a TerrainDebris object:



And a Background Layer:



Now for the Terrain's BitmapFile. This image has to be in the CC Mat palette (unless you're doing custom materials, but that's really hard, and I explain it below, as well).

The colors in the mat palette correspond to the index in Materials.ini, so the first color in the palette is the first material in Materials.ini.
When making a scene, you'll probably only need a few colors.

Here are just a few of the most common materials:

The the "dirt" materials are mostly in order from least strong, to strongest. "Air" is anything Magenta. There isn't really a material there, it just doesn't place anything. Background makes the BackgroundTexture show. Gold places gold pixels. Not nuggets. Test is pretty much invincible. It also doesn't have a texture, and will look weird. Grass that you make will give you textured grass, if you want to do it manually.

Here is how you put a custom material into a scene:

1. Create the code for the material like Data does it in Materials.ini.
2. The color of the material will be what it appears ingame. This has to be an in-palette color.
3. The Index of the material has to be the same as the index in the palette of the color that you want to use to color on the scene image.
So, this means that you have to use a non-palette'd image for the scene's .bmp. You have to use a non-used up Index, and whichever index you choose, will use the color from the regular palette as the material's placement color. I.E. if you choose Index 39 in the material code, you'd go to index 39 in the regular FG palette, and use that color in the scene .bmp to color it. Then ingame, it'd show up as that material's Color = Color part. Unless you use a texture, then it'll be the texture.

And that's about all you need to know for making scenes. The hardest part, really, is thinking up ideas and spriting everything. But it's actually probably even easier that regular modmaking.

Chapter Three: Attaching stuff

You can attach either an "Attachable" object or an "AEmitter."

Attachables:
Here's an example Attachable object.


As you may or may not see, Attachables are pretty much the exact same thing as MOSRotating objects, except for one small difference.



This means that Attachable objects can have a parent object that they attach to. The strength determines how much force it takes to break the Attachable off the parent. The stiffness effects how easily the Attachable will recieve that force. And the offset determines where on the parent object the Attachable will be located.

To attach an Attachable to something you have to have a parent object, say, an AHuman, and an Attachable that you've already made. Then use the simple code in the AHuman's code. somewhere above where you define the gibs.



Here are what Attachables can and cannot do:

• They do not rotate freely. You can't make a dynamic chain.
• They do rotate with their parent object. They will keep the same relative rotation to the parent.
• They cannot be attached in two directions. You can't attach a Dropship to one end of an Attachable and connect it to an AHuman
• They can have gibs just like a MOSRotating and can be wounded just like a MOSRotating
• Attachables can only be Attachables. You cannot attach Actors, Rockets, Guns, Brains using AddAttachable.

Also able to be attached are AEmitters.
AEmitters are attached similarly to Attachables:



Then the emitters function just like they would anywhere else.
The emitters will emit in the direction that they were attached relative to the parent object. If the parent object rotates, then the emitter will rotate with it, and emit in the new direction.


The last way to attach stuff is through TerrainObjects. TerrainObjects are placed in scenes or through the build phase, and can have child objects. The difference between attaching Attachables and using TerrainObjects, is that you can attach anything to a TerrainObject.

To attach a child object to a TerrainObject, use this code:

Chapter 4: Super Duper New Person Guide

The Hello World of Cortex Command.

Here, I will attempt to create a tutorial that will let any new member quickly start on the path of modding greatness, as well as instill a sense of modding that keep them from making boring generic mods. Success ensues. Also, the number one thing I would like for this particular tutorial is criticism. Please tell me how you would like this changed to better help the learning process.

So you want to make a mod?

Well, first thing you're going to have to do is download Cortex Command. Got that? Good.
Now navigate to your Cortex Command folder. In it you will see many files. Most of these are useless to you, but there are a few important ones.

• Cortex Command.exe (Pretty important)
• Base.rte (Super important)
• PromGrounds.rte (A bit important)

If you cannot see the extensions on the files (.exe, .rte, .ini), you need to turn that option on. In Windows, open any folder. Find the "Folder Options" option, switch to the "View" tab, and where it says "Hide extensions for known filetypes", uncheck that box. You want to see the extensions, so that you can edit them later.

Personally, I learn best by example, but this tutorial isn't for me, so I won't tell you to just look at the code until you get it. I'll walk you through the mod creation process. The hardest part for most people is syntax. Syntax is the grammar of the game's language. If you don't make your mods according to a very specific syntax, it will give you lots of errors. If you have really, really bad spelling, turn back now. Also, I'll be comparing your new mod's structure to PromGrounds.rte a lot, because that's how the original modmakers learn how to create mods. Data doesn't like us enough to give us documentation.

I won't go over the exact details of every file in Base.rte. Eventually, all that info will be available on the wiki, but for now, let's just start by creating a fresh modding set up for you to work with. To begin, right click and create a new folder in the Cortex Command folder (Not inside base.rte or promgrounds.rte). You can name your folder whatever you want, but for the game to see it, you'll have to add a ".rte" at the end, just like "PromGrounds.rte". Data has never really told us what "rte" stands for, but I'd guess something like "Run Time Environment" or "Ready To Eat" or something fancy like that. You don't really need to know all the fancy behind-the-scenes info, though.

You have so far:

• MyNewMod.rte folder

If you look inside PromGrounds.rte, you'll see that it has a few files. These are going to be very important to your modmaking career. The first, most important file is the "Index.ini". Without this file, your mod won't run. Don't be frightened of the ".ini" suffix, either. It's really just a text file. Try opening "Index.ini" with a text editor like notepad or my favorite Notepad++. I wouldn't use Word, though. Word saves files kind of weird, so the game probably won't be able to read it.

Once you open Index.ini in PromGrounds.rte, you'll see.. not much:


The DataModule part tells the game that this is infact a CC mod, and it should be included in the game.
The IncludeFile part tells the game which files in your mod to use. In this case, to use the Scenes.ini file.

This gets a bit tricky, because if you're a first time modder/coder you might not understand exactly how this syntax works. There are rules, see.
For just this small file, you have to know all this:

• The file has to be called "Index.ini"
• DataModule has to be spelled exactly that way, captialization counts. IncludeFile, too.
• DataModule has to be the first thing the game sees. No putting stuff in front of it. (Except comments)
• IncludeFile has to be on it's own line.
• IncludeFile has to have a tab infront of it. (Or equivalent whitespace. You can also use 4 spaces, but that's just more work. But not 3 spaces or 5 spaces.)
• After the word IncludeFile, there must be a space and then an "=" sign, and then another space.
• After that, you must have a valid file path. You must use forward slashes ("/"), and correctly spell everything. (Capitalization doesn't count here)
• The file path is always relative to your top folder in the mod. This means that you can't use any files that aren't inculded inside your mod's folder. (MyNewMod.rte)
• You must always include the mod's .rte folder in the path. Or, you can use Base.rte, but you can't use any other .rtes. (I.E. You can't use files in PromGrounds.rte from your MyNewMod.rte.

Intimidating, I know. But other than that, you can do quite a lot. For instance, you can add another "IncludeFile" line, and include more files. So you don't have to put everything in one file.

To make a new .ini file, all you have to do is right click, go to New..., and then choose Text Document. It will give you a New Text Document.txt. Rename this to "Index.ini" (Make sure it doesn't have the ".txt" at the end. Just ".ini". If you don't see the .txt in the first place, go up a bit and make Windows show you the file extensions like I told you to). Windows will tell you that changing the file extension might break things, but in this case, it won't, so just click "Yes".

For now let's just do something like this:

Of course, as you're following this, you can always change the name to something else. But if you do, you have to change it everywhere that it's used.

So, to start off, we're going to make a gun. It is good coding to give each prominent object in your mod it's own file. This way, you can quickly find the object if there's an error. If you start to get up to around 1000-2000 lines of code, you're not going to be able to debug it quickly, and it's best to seperate it into a couple of files.

So, since you've said that there's a MyNewGun.ini in your Index.ini, go ahead and make that file the same way you make the "Index.ini".
Now for the Hello World bit.
Since you can use objects that have already been defined in Base.rte, I'll show you how to make a gun using some of the default objects.

First thing to do when creating a new gun:

Put this as the first line of your "MyNewGun.ini" file. This tells the game that you're creating a new weapon, and you want that weapon to be added to the game's internal list of weapons, so that you can use it later.

On the next line (hit enter once), You want to define some of the properties of your new gun. The way to do this is by adding one (1) more tab than the last line. For instance, since your new gun (The AddDevice line) has no tabs in front of it, all of the properties of that gun will be on the lines with one tab. If your gun had an object as a property (We'll get to this in a sec, hang with me), the properties of that object would have two tabs in front of them.

A good start would be to name your gun.
Add:

Make sure that you have the one (1) tab on that new line.

So far, the code looks like this:


What you've done is created a new weapon (HDFirearm) and set the InstanceName property of that object (Hello World). This means that the game will call the gun "Hello World". I hope this is all clear.

Since this will be the most basic of guns, we'll skip some of the less-needed properties, and just let them be their default values. A great thing about Cortex Command coding is that you don't actually need to set all of the properties of an object. Just that ones that will make your object unique.

However, you do need a few basic properties set if you want to be able to use the gun. For an HDFirearm, you have to have at least:

• InstanceName (needed by all objects)
• GetsHitByMOs (so you can interact with the object)
• SpriteFile (if you want to be able to see your object, I mean you could leave it out, but then you can't see it. And not the cool invisibility kind of not see, I mean like the I can't hit it or pick it up or load it without an error probably kind of not see)
• AtomGroup (this tells the game about the object's collision and how it will hit other objects and the terrain)
• Magazine (to hold the bullets. If you don't have a magazine, the bullets will all fall out.)
• RateOfFire (or else it defaults to 0, which is not a very high rate of fire.)

That's pretty much it. Course, that would be one boring gun. It would have default values for all the cool stuff like RateOfFire and FireSound.

But let's just start out by creating a boring gun. You can add fancyness to it later, if you want.

Next up on the list is the GetsHitByMOs property. This property can either be set to 1 or 0. On or off. If you try to set it to something like 1337, it'll give you an error. Right now, we want to set it to 1, so that way MOs (Moving Objects) will be able to collide. Specifically, we want the actors to be able to collide their hands with it and be able to pick it up.

Add this code right under InstanceName:


Next let's do the SpriteFile property.
You're going to need a .bmp image to assign to the gun.

I'm sure you can find some tutorials around here on the specifics of creating paletted .bmp images for CC, but that takes a long time to explain, and instead, I'll just give you an wholly original image to use.



Download that, and stick it in your mod folder. If you've got your own image, you can use that too. But beware, because the CC palette is a finicky thing, and just any image won't do.

Now that you've got your image, go back to MyNewGun.ini, and add these lines:

Lets explain this a bit, it's easy really. SpriteFile is the property of the HDFirearm that sets what the image will be. The SpriteFile is set to a ContentFile object. Remember back when I told you you could set properties to other objects? Here, setting the SpriteFile to a ContentFile creates a new ContentFile object. ContentFile objects have their own properties that need to be set, so you go to a new line, and add another tab to show that you're setting the ContentFile's properties and not the HDFirearm's properties.

ContentFile has one property that you can set, which is FilePath. FilePath tells the game where to find this sprite. It works a lot like how IncludeFile works from the Index.ini, except now you want it to point to an image. Cortex Command only accepts .bmps in it's special palette, so set the FilePath to the path of the image. Now your gun will show up with that image ingame.

Next you'll need to set an AtomGroup property. These are a bit tricky and complex. Infact, I'm not 100% certain what all of it does, suffice to say, I would just go ahead and copy this stuff:

Technical description is that AtomGroups are groups of "Atoms" that CC uses to calculate collision on a pixel-by-pixel basis somehow fancy. The material is what the atoms are made of, which in turn changes how the pixels collide. Military Stuff is one of the default materials. Resolution is something fancy. Depth is how deep into the sprite the atomgroup starts generating atoms.
But that's all for another tutorial. You don't need to know any of it. AtomGroups are generated automatically by themselves.

Now we need to give the gun a magazine. The Magazine property tells the gun what kind and how many bullets to fire. Magazines are actual objects in CC, but we'll put off making a whole new magazine, and I'll show you a different way to add objects. Instead of creating whole new objects, you can copy the properties of other objects of the same type to save time.

Add this code to the end:

What you've done is set the Magazine property of the HDFirearm to a new Magazine object. Then you set all the properties of the new Magazine to be the same as the properties of the object "Magazine Pistol", which happens to be the magazine used in the pistol's code.

Lastly, set the RateOfFire. You might be able to figure it out yourself even. All you need to do is go to a new line, press tab, type out RateOfFire, use an equals sign, and then give it any number between 1 and 2147483647. I would recommend a nice round number like 500. The rate of fire in CC is actually number of bullets per minute. So setting it to 500 would mean that your gun will fire 500 bullets if you were firing it for a full minute and you had enough ammo. If you don't set RateOfFire, it won't give you an error, but your gun won't fire any bullets either.

And that is it.

Now all you have to do is save your .ini file, make sure everything is in the right place, and start up Cortex Command. While it's loading, you should see your mod zip by quickly at the end. If you don't, then you've probably named the .rte wrong.

Once the game finishes loading, just start up a skirmish on a scene where you can place stuff, go down to "Weapons", and you should see "Hello World" if all went well. Place your gun, pick it up, and be amazed at the power of Cortex Command .ini modification!

Questions/Comments feel free to PM me or post in this thread. Tell me what you'd like me to add or change.

Where to next?

• Try looking at the Wiki (The tutorials area is a bit more filled out right now).
• Download other people's mods and learn from them.
• Ask some of the fancy cool mod makers. Most of them like feeling smart and answering questions. Make sure you use PMs, though. That's the best way to get your question answered.
• Try out the Minor Mod Compendium Thread: viewtopic.php?f=1&t=11394
• Look at the Base.rte code and see how the master himself, Data, created the basic stuff.

This is really handy and people should read it.

Bugs and problems should get PM'd to the OP. OP should PM staff if they need to update.