A Simple Guide to

Cortex RP
By: Starcraft II player name: Kazuo
Character code: 286

About
Most of the people in the Cortex community are not too friendly towards new players.
This could be due to a number of reasons, although I suspect that the main reason for this is that
cortex is considered a complicated game by many due to the number of technical things and
terminologies involved, and people just dont understand how to break all the information down
in a quick, simple, and easy-to-understand manner for new players.
Most often, I see people help new players by just shoving command syntax down their
throats after telling them that the game operates based off of commands, and as such, it is never
quite simple for a new person to learn and comprehend the game. Others try to help new players
by telling them to read the commands guide located in the toolbar at the far left side of the
screen, and upon doing so, the new players are sometimes completely lost due to not
understanding the syntax as is given in the commands guide. Many new players have never
gotten the chance to become experienced cortex players due to having received poor instructions
leading them to give up on trying to learn new things about the game, or some have even simply
outright stopped playing cortex after not being able to understand the game based on the first few
times theyve played it.
This guide was made in order to somewhat remedy this issue, by providing a structured
method of learning the game so that people who read it actually understand what is going on
rather than just being shoved command syntax down their throats. This guide is by no means, a
way of completely mastering Cortex as the game is indeed too complex to be entirely covered
within a simple guide such as this, and in addition, the author of this guide (myself) is not a
complete master of Cortex either, but merely someone with a bit more experience and deeper
understanding of the game compared to the average player.
If there are any parts of this guide that is read and not understood, and/or you have
questions regarding the material covered by the guide or about the guide itself, feel free to add
me in-game. My character name is Kazuo and my character code is 286 as shown in the title.

Section 1: Introduction

Hello, and welcome to the start of this guide. For those of you who are curious as to why
this guide was made and how to contact me for questions, see the About section. Furthermore,
it is important to note that it is not necessary for one to read the entirety of this guide before
being able to enjoy playing cortex. The guide is structured so that even for someone completely
new to the game, only this first introduction section must be read (approximately two-and-a-half
pages long) and he/she can immediately jump into a game and start playing cortex with a good
sense of how it should be played, along with the fundamentals needed to play Cortex correctly.
For those who wish to truly understand more and be able to mess around with the functions of
Cortex more however, further reading of the guide will be needed. The amount of reading you do
will translate to the amount of information you will learn; as such, one who seeks to become
fairly skilled at the game should definitely read the entirety of the guide. With that said, let us
jump straight in!
The question we must start off with is what exactly Cortex RP is. To answer this, Cortex
RP, or Cortex Roleplay, is a game engine in the game Starcraft II, that gives players map editorlike powers and abilities in the form of commands so that they may use them to ROLEPLAY.
The word roleplay is capitalized as that is the main purpose of this game. Intricate knowledge
of commands and technicalities are nice to have, improve roleplay experience, and are covered
by this guide, but are in no way, necessary for one to play Cortex the way it is supposed to be
played: through roleplay.

By now, it should be known that cortex is a game engine that functions with commands.
For those that do not already know, these commands are typed in-game as regular messages
would be, but there are specific symbols and structures that are used when typing commands
(known as command syntax). As the final part of this introductory section, we will cover 3 basic
commands that are vital to just about any roleplay that is done in Cortex: @spawn, @renameall,
and @say.
The first command out of the three listed is @spawn. The @spawn command does
exactly as what it sounds like, it spawns things, with those things being units, structures, some
doodads, and more. The command syntax for @spawn is: @spawn (what you would like to
spawn) (amount). If this is not clear yet, do not worry, as an example is provided below as well
as what the example does when copied exactly as typed (except for the example: part).

Example: @spawn marine 24

Copying that without the Example: into a chat message will spawn 24 marines. The marine
can be replaced with the name of anything you would like to spawn, and the 24 can be
replaced with any given number you want of the thing you want to spawn. It is important to note
that if youre only spawning one of anything, you do not need to type out 1. For example, if
you would like to only spawn 1 marine instead of 24, simply type out (again without the
Example #: part) as shown below:

Example 2: @spawn marine

With that done, now try spawning a few things of your own that does not involve marines
so you get a feel for the command of @spawn. It shouldnt take too long for you to understand
this command once you get the hang of it as it is one of the simpler commands. When you have
done that, continue reading to move onto learning about @renameall which is next.
@renameall is the next command out of the three listed commands vital for any solid,
roleplay done in the cortex engine. @renameall is a command that renames a unit type to the
name specified. In short, it is a way to change the name of your units to fit them properly for
roleplay. It is important to note that unlike @spawn, you must first select a unit or a group of
units before you use @renameall since the @renameall command does have to target something,
otherwise nothing will be renamed. To test this command out, spawn something as shown earlier
with the @spawn command, then select your spawned units/etc. and copy the example below:

Example 3: @renameall Kazuo

This should rename the thing(s) you have selected to Kazuo. You can change the Kazuo part to
any name youd like. Before you go ahead and test this command out, there is one technical issue
about this command that you must be aware of, which is that @renameall, as stated earlier,
renames a UNIT TYPE. In other words, all units of that same type will be renamed to the name
you specify. For example, if you did the @renameall Kazuo on a single marine, all marines that
you spawn from here on out will have the name Kazuo. If you then do @renameall Bob on that
single marine, all marines that you spawn from that point on will have the name Bob. The
name specified in rename all applies to all units of the same unit type. There is a way around this
issue which will be discussed and covered later on in the Basic Commands section (The next
section after the introduction). With that in mind, you may now commence testing and practicing
of the @renameall command before moving onto the @say command, which shall conclude this
section.
We are almost done with this section, yay! The final command of the three that are vital
to roleplays in Cortex, is the @say command. When you have a thing or things selected, typing
@say (message here without parenthesis), will cause the selected thing(s) to say that message.
Try spawning a marine, selecting him, and then following the example below:

Example 4: @say Hello, World!

This will cause your marine to say Hello, World! in the chat. This command is vital for incharacter dialogue during roleplays, and also can be used to denote certain actions done by the
character in the roleplay. If, for example, your character in the roleplay has to grab a cup of
water, you could do: @say *He grabs a cup of water*, where the asterisks denote an action. This
is now going into the style of roleplay you use, which can differ for each person. Some people
like to denote actions regularly with @say, so like: @say He grabs a cup of water, and then
they denote their dialogue using quotation marks within the @say command, like: @say Hello,
World!. Now try messing around and experimenting with @say.

With that done, you should now have mastered the three basic commands needed to
roleplay. If youd like, you may stop reading here and start roleplaying. The rest of this guide is
going to cover things that arent necessary for roleplay, but can improve the roleplay experience
immensely, and also make things a lot more fun and enjoyable. The material covered by the rest
of this guide will go over more commands to modify your units and spawned things to make
your roleplay a lot more immersive, as well as technicalities and implications of the cortex
engine. The last sections of the guide will be for those who wish to acquire a more advanced and
deeper understanding of the game that is essentially on par with what the author (myself)
currently knows as of the time that I am writing this guide.

Section 2: Basic Commands

Important Note (please read entirely before continuing): In this section, @spawn,
@renameall, and @say will not be covered as they have been covered by the previous section. It
is also important to note that this section and the next will be the longest two sections in the
entire guide since there are so many commands that exist in the Cortex Engine, and these two
sections make an attempt to cover most of those commands in a manner that is both
comprehensive and understandable. As such, the different portions of this section along with next
section will be divided into sub-sections that have names that will be bolded in orange to help
readers better navigate through the different commands covered, so that if there are commands
you already know, you can skip those sub-sections and go to one that covers a command you are
not too familiar with yet.
By now, you should have mastery over the basics needed for a roleplay, but the basics by
themselves can get repetitive and boring even for the most imaginative players. You will find that
it is necessary to add a certain level of depth and immersion into your roleplays, and the other
commands really help that a lot. Instead of having to type our descriptions of your characters and
imagining them, some of these commands can make the appearance of your imagined characters
and settings actually take place in-game, and much more.
Sub-Section: @scale
One of the most important basic commands is the @scale command. This command
allows you to change the size of your units. The syntax for @scale is: @scale X Z Y. The
variables X, Y, and Z represent numbers in a direction. To make this simpler to understand, think
back to your low level math class where you deal with graphing and coordinates. X, Y, and Z
each represent an axis, or in simpler terms, a direction. Just like how the X axis in math goes
from left to right, the in-game X variable for the @scale command changes the width of
something you spawn. Likewise, the Y variable number changes how great the height of
something is, or basically, how tall it is. The middle Z variable corresponds to how long an
object is in terms of forwards and backwards. Try the example command below with a select
unit(s):

Example 1: @scale 2 1 3

Copying the above example means that your unit/structure/etc. will scale to be twice as large as it
was in width, the same amount as it was in terms of length, and three times its original height.
Keep in mind that if you want to scale something by the same value across all the dimensions, so
for example, if you want to scale something to be 3 3 3, then you do not need to type out all 3
numbers and may choose to type out just one number as shown in the example below:

Example 2: @scale 3

With that done, try playing around with the scale command. Youll find that you can make
something look entirely different just by playing around with the dimensions sometimes.
Sub-Section: @modelswap and searching
The next command this guide will be going over in this section, is @modelswap. The
@modelswap command does as it sounds; it changes the model of your current actor. This may
sound a bit confusing at first since most of you who are reading this guide will probably have no
idea what an actor is. If you truly wish to learn what an actor is, finish the rest of this section and
move onto the Modeling section where commands such as @attach and @attach+ are covered.
As of right now, simply understand and think of modelswap as a command that changes the
model of your unit to something else. The syntax for this command is: @modelswap (model
name). Try spawning a marine, selecting him, then copying the example shown below:

Example 3: @modelswap barracks

Assuming you did this correctly, your marine is now still a marine in the sense that it moves,
behaves, and fires like a marine, but it has the model of a barracks. You can probably guess that
you change the barracks portion of the command to whatever you want as shown in the syntax.
Earlier, we discussed @renameall and how it had a technical implication in that it
renamed all units of a unit type. It was also mentioned in that same section, that a work-around
exists for this technical implication through the use of modelswap. The idea behind the workaround is that lets say you want to have two marines, one named John, the other named Paul.
Assuming you spawned both marines and renamed one, you would get the same name on both
marines as according to the technical implication of @renameall. You can get around this by
making both units being different types. To understand, lets say you spawned a marine, and then
you spawned a marauder. Next, lets say you select the marauder and modelswap him to a
marine. Even though it looks like you have two marines, you dont. You actually only have 1
marine and 1 marauder that has been modelswapped to a marine. You can now rename one to
John and the other to Paul, with both having different names since they are different unit types. It
is true that the marauder that has been modelswapped to a marine will behave like a marauder in
some ways, such as having a marauder attack, but the animations of the marine model still apply,
so all you really need to do is use commands like @removeweapon and @addweapon to remove
the marauder weapon and give him a marine weapon. You have successfully just worked-around
the @renameall implication, congratulations!
Go ahead and tinker with the modelswap command. One of the most important
commands, one which ties directly with modelswapping, is the search command. The search

command allows you to search for the names of models, actors, doodads, and more. To use the
search command, type out search (category) (name). An example of this is shown below:

Example 4: search model barracks

Typing out the example will bring up search results for any models that have barracks in their
name. You can also search for things like units as shown by the example below:

Example 5: search unit marine

Just like with the model search, the above example searches for a unit this time instead of a
model, and with marine in the units name. Typing search by itself will bring up a list of the
different categories within which you can search. Additionally, typing out search (category)
only without specifying a keyword or key phrase will basically provide a list of the names of all
objects in that category arranged from top to bottom by date added (I believe, not sure on this
one). The whole list of names will obviously be unable to fit, so the search function will only
load a few names at a time. To scroll down further to see more names, simply type search
again without needing to specify category and keyword.
Sub-Section: @tint and parameters
Want your unit(s) to look red, maybe blue, maybe green, maybe white, maybe black? Use
the @tint command! It is also about time that we introduce the term parameter into the scheme
of things so that we dont have to write out what a parameter represents every time we discuss on
commands that have parameters. A parameter, at least in how it will be used in this guide, means
something that represents a variable with a changeable amount. For example, in the @scale
command, we looked at how the command is @scale X Z Y, where X, Z, and Y represent
numbers. In that case, X, Z, and Y are the parameters for the @scale command. They are
variables in which you can specify with a quantity or amount that you choose. It should go
without saying then, that the @scale command has 3 parameters.
So how does that giant tangent of a mess relating to parameters fit in with @tint? Well
the @tint command is also a command that has parameters. In the case of @tint, there are six
different parameter values. Most people are only aware of three to five. Very few people actually
know that a sixth parameter exists for this command. The syntax for the @tint command is:
@tint (red#) (green#) (blue#) (opacity#) (brightness#) (time#). The first parameter, the red#,
represents the amount of redness you want your unit(s) to have. Likewise, the second
parameter represents the amount of greenness you want your unit(s) to have, and the third
being the blueness. The red, green, and blue amounts go from 0 to 255. This means that if you
type in anything greater than 255 for those values, it will just result in 255 being used. Any value
typed in lower than 0 will just result in 0 being used. The fourth parameter is opacity amount or
transparency. In simplest terms, it is how see-through the unit(s) is/are. The opacity

parameter is a bit different in terms of value range from the red, green, and blue parameters. The
opacity parameter goes from 0 to 1 only. 0 Represents invisible, and 1 represents solid. This
means, you will most likely need to be working with decimal values if you want to mess around
with this parameter. Before we move on to the last two parameters, this is good time for you to
reread through this giant block of text to make sure you understand the first four parameters, and
below will be some examples for you to try to see the effects of tinkering with these first four
parameters.

Example 6: @tint 255 1 1

This will make your unit(s) extremely red. It is important to keep in mind that if you dont
specify the other parameters, such as how I didnt specify the opacity, brightness, and time scale
parameters, then the engine will automatically assume they are set at default values (meaning
that opacity will just be 1 AKA solid, and brightness is standard, with no timescale factor
involved).

Example 7: @tint 1 255 1

This will make your unit(s) extremely green!

Example 8: @tint 1 1 255

This will make your unit(s) extremely blue! Keep in mind that a units default, normal color is
255 for red, green, and blue parameters (so 255 255 255).

Example 9: @tint 255 255 255 .3

Is that a ghost? Spooky! After doing the above example, proceed to mess around with these first
four parameters on your own with your own values for the parameters. While you do this, keep
in mind of how coloring works in real life with how red and blue can make purple, and red and
green can make yellow and so forth. This also is true with your tinting. If you specify large
amounts of red and blue while keeping the parameter value for green low, you can get different
shades of purple, violet, pink, and etc. Likewise, you can also combine this with the opacity

value so that your unit(s) with different shades of color is also transparent and see-through on top
of it all.
Now that you are familiar with the first 4 parameters of the @tint command, it is time we
move on to the last two parameters: brightness and timescale. The brightness parameter has a
value range of 0 to 25, with the default brightness of a unit being one. I stated that the maximum
brightness value is 25, but there is a possibility that the brightness value maximum could be even
higher. The reason I listed 25 as the maximum is due to how I, the author of this guide, have
personally never experienced anything with a brightness parameter value greater than 25,
meaning that even if such values exist, they do not look much brighter than 25, which is already
at a blinding-level of brightness. The sixth and final parameter value for the @tint command, is
the timescale value. The number you specify here will be the time in seconds that it takes for a
unit to reach the tint you specified. To get an idea of how this works, let us say you spawned a
marine. By default, that marine is at a default tint of 255 255 255 1 1 as all things normally are.
If you want that marine to be sort of a bright, blue, ghost marine, you could try tinting it to 1 1
255 .3 5. That would instantly tint the marine to that tint you specified; however, if you instead
did 1 1 255 .3 5 3, which has a 6th parameter of 3 seconds, that means it will take the marine 3
seconds to reach that tint of 1 1 255 .3 5. The number you put in will always be in seconds for
the sixth parameter of @tint. All commands that exist with time-scaling/time parameters
involved use seconds and not minutes or hours or any other unit of measurement for time. It is
now time to try out some of the examples which will be shown below:

Example 10: @tint 255 255 255 1 .5

Woah, that looks pretty menacing with how shadowy it is. Im scared!

Example 11: @tint 255 255 255 1 .5 4

Same tint as previous example, just takes 4 seconds to get there. After this example, trying doing
your own tints with your knowledge of all 6 parameters now.

Well done! You have mastered the @tint command fully. The next sub-section will cover
multiple commands at once, but do not worry; the commands covered have been grouped
together into one sub-section due to their simplicity and ease. Youve done well making it this
far, and there are only 3 more sub-sections to go before this entire section is concluded. It is
important to note that not all of the basic commands that exist in the game are covered by this
guide, as some of the commands simply arent that useful (at least I dont think they are). If you
would like to learn more about such commands, you may either attempt to open up the in-game

commands guide and attempt to learn from that, or you may add me in-game and we can go over
them.

Sub-Section: Removing Things

If all you could do was only spawn and modify things in this game, youd end up having
a bunch of units that cover the entire map. As such, commands that remove things seem trivial in
that they arent overly complicated, but they are definitely important to know.
If something you spawn is a unit or a structure, chances are, it can be killed. To kill
something, simply select it and type @kill. Killing things works alright, but sometimes, killing
something will create a stain. A stain is some residual death model, texture, or animation-like
thing that is left behind after a unit dies. This is due to how the starcraft 2 engine was made in
such a way that when something dies, while the main model of the thing will disappear, it may
spawn a death model or something along those lines to take the place of the original, and some of
these death models and such cannot be selected. Knowing this, the @kill command, which
causes a units or structures death, may not be the best thing to use but can still be done on some
units and structures spawned. The safest way to remove something is usually by @remove. To
use @remove, simply select what you wish to remove and type in @remove.
OMG A STAIN! WHAT DO I DO?!!! If someone (either you or someone else) has
indeed created a stain, there is still a chance it can be removed. The thing about stains is that they
are sometimes just objects that are removable but cannot be selected. In situations like these, you
need to use the @removearea command. The removearea command will remove everything that
is not a doodad from a specified area size. The command syntax for removearea is: @removearea
(size of area). An example is shown below:

Example 12: @removearea 15

Following the example above will remove every non-doodad and non-terrain object
within a 15x15 map tile area size. The area that is targeted will be the area that is directly under
your mouse or spawner. Default, standard map boundaries are 256x256 tile size, and as such,
@removearea 256 will remove every non-doodad and non-terrain thing from the map that you
have privileges over if you were to do this with your mouse cursor or spawner at the center of the
map, as the mouse cursor or spawner denotes the center of the area that is to be removed of nondoodad and non-terrain objects. This means that you have to be especially careful with this
command if you are admin or moderator (both of which will be discussed more thoroughly in the
Host Commands section) as admin and moderators have privileges over normal players units
even if they arent in direct ownership of the units.

Sub-Section: Doodads and Regions

Youve probably played a standard starcraft 2 map in multiplayer or single player; if not,
please do so right now (before we murder you). In a standard map, the trees, vegetation, along
with things like walls and objects that are built into the map are all mostly un-selectable, and do
not show up on the minimap. At this point, youve probably tried your hand at making something
like a landscape in cortex, by spawning and modelswapping trees and vegetation and such.
Despite those objects being seen as trees and vegetation, they still appear on the minimap and
selectable, unlike the maps preloaded trees and vegetation. This is where the doodad commands
come into play.
Doodad commands allow you to make trees/vegetation/etc. that behave as if they were
part of the preloaded map (meaning that they wont be selectable, nor will they be seen on the
minimap). Commands that involve doodads will usually differ from the @ commands in that
instead of using an @ in front of the command name, an underscore _ will be used. A list of
the doodad commands has been provided below:

1. _doodad (model name)

2. _removearea (size)
3. _scale (X Y Z)
4. _select
5. _remove
6. _destroy (Size)
7. _tint (Red# Green# Blue# Opacity# Brightness#)
8. _face (degrees)
9. _modelswap (model name)
10. _animspeed (amount#)
11. _height (amount#)

First on the list is the _doodad command, with an example of how to use the command being
provided below:

Example 13: _doodad dynamicgrassendion

Following the above example will cause a highly transparent dynamicgrassendion model to
appear under your cursor. This transparent model will follow your cursor, and when you click on
a location while the model is following your cursor, you will spawn the dynamicgrassendion

model to spawn on the location you clicked, with the model spawning as a doodad., with the
model spawning as a doodad. A doodad, which is spawned using this _doodad command, differs
from something spawned with the @spawn command in that the @spawn command spawns
actors, whereas the _doodad command spawns models as doodads (objects in the map which
arent selectable normally, and do not appear on minimap).

Sub-Section: Host Commands and ??Omega??

Sometimes, you will find yourself as being the creator of a Cortex in-game lobby, putting
you in the position of host. Being the host of a cortex lobby will usually make you the in-game
admin. As admin, you get access to special admin commands when in-game, denoted by the !
at the start of the command(s) unlike the regular @ commands.
Before we continuing going over the many different admin commands, it is necessary to
understand the technical implications of admin, in particular, how one becomes and is qualified
to become admin. Some people, especially the newer and/or more inexperienced players, believe
that admin is granted simply by being the host of a lobby. This is incorrect. Simply because you
are the host of the lobby, does not mean the in-game engine will recognize you as host of the
lobby. The person who creates the lobby however, is guaranteed to become admin. This means
that if you create a cortex lobby, leave the lobby to make someone else host, then rejoin the
lobby, when the game starts, you will retain your status as admin. Likewise, if you create a lobby
and promote someone else to lobby host, when that game starts, you will retain your status as
admin in-game. Now, if the creator of a lobby leaves the lobby and doesnt return, when the
game starts, the person selected to be admin should be random (at least as far as I am aware, not
100% certain however),
As admin, you get access to admin commands and also to higher permissions. Higher
permissions mean that you can control certain things in regards to other players as well. An
example would be the @remove command which removes your selected objects. Normally, as a
normal player, you are allowed to remove things that you own, but not the objects/things owned
by another player. As admin, this is no longer true, and you can apply @remove on everything
that you can select regardless of who owns the selected things. Essentially, all unit modifying
commands (the @ commands) can be done on other players units when you have admin
privileges.
As mentioned before, there are many commands which are only useable by admin. The
first that we will be going through is !seeall. The !seeall command reveals the entire map, and is
done by following the example below:

Example 13: !seeall

Typing this command will reveal the entirety of the map, and re-entering it will hide the
map. In most lobbies, people will expect the host the use this command and reveal the entire map
the moment loading screen finishes and everyone is in-game.
The !secure command is another command that most people in a lobby will expect a host
to do the moment everyone is in-game. Much like with seeall, you simply type !secure
(without quotations of course) to disable secure. The reasoning for doing this command is that
many other commands cannot be used until secure is turned off. Some of the commands which
rely on secure, such as gamesetup commands and replacement commands, are very useful to
have when setting up for a roleplay; as such, secure is usually expected to be turned off right at
the start of the game. Doing !secure again will re-enable secure and once more prevent the
commands that rely on secure being off, to be unusable.
The admin commands are fairly straight forward. Some of the other admin commands not
yet discussed are as listed below:
1.
2.
3.
4.
5.
6.
7.
8.
9.

!remove (color)
!disable (color)
!enable (color)
!promote (color)
!demote (color)
!light (name)
!sound (name)
!ban (color)
!fruit (amount#)

The (color) part in each of the commands in the list refer to the targeted players color. This
means that you put in the color of the player whom you want the command to apply to. The !
remove command will remove all the units belonging to player whose color you specified (no
parenthesis obviously). The !disable command will prevent a player from talking (muting) and
will also remove that players ability to use commands, while the !enable command will do the
opposite by letting a player talk and use commands again. The !promote will allow the admin to
promote players into moderators which have more privileges than a normal player, but not as
much as admin does. A moderator can ban, remove, enable, and disable normal players, and can
also apply the @ commands to the units of other players who arent moderators or the admin. !
demote is the opposite of !promote, and reverts a moderators status to a normal player. The !
light command will change the lighting of the game to the lighting name that you specify. You
can search for lighting through search light (name). !sound plays the soundtracks name that is
specified. The !ban command will allow a host or moderator to kick a player from the game. The
!ban command cannot be used to kick yourself or anyone with moderator privileges unless you
are admin (and admin cant be kicked by anyone). If an admin decides to leave in-game, a
random player will be promoted as the new admin unless there are moderators. If the admin

promoted someone to moderator and leaves game, the moderator will become the new admin. If
there are multiple moderators, one of the moderators are randomly selected to become admin.
The final command in the list above is a fun one. The !fruit command will cover the entire map
in the amount of fruit that you specify (a number value). To completely remove all fruits, simply
do !fruit off.
What the heck is Omega? That is a question a lot of people ask after looking at a list of
in-game commands from the commands guide. This command is more or less, unusable at this
point, so you can more or less skip this final part of this section and move onto the next unless
youre curious. The omega command is a special command that is coded into the engine to be
usable by only a list of people, all of whom (that I am aware of) no longer play cortex, meaning
that it is high unlikely you will see this command being used unless you are playing with the
creator of a map on his own map. Onto what the command actually does, the user who has access
to it and uses the omega command, will become the new admin while demoting the current
admin. You can easily see why this command was only given access to a select list of players.
Map makers who understand coding can code their own profile IDs into the list of people
allowed to use omega, essentially creating a slightly modified version of the engine that is on
their map, allowing them to use omega on their map. The specifics of how to do this are ones that
I, myself, am not too entirely sure of, and is more considered a part of map-making rather than a
part of how to play cortex; hence, it will not be covered in this guide.